WO2022190580A1 - 車載中継装置、管理装置、車載システムおよび通信管理方法 - Google Patents

車載中継装置、管理装置、車載システムおよび通信管理方法 Download PDF

Info

Publication number
WO2022190580A1
WO2022190580A1 PCT/JP2021/048221 JP2021048221W WO2022190580A1 WO 2022190580 A1 WO2022190580 A1 WO 2022190580A1 JP 2021048221 W JP2021048221 W JP 2021048221W WO 2022190580 A1 WO2022190580 A1 WO 2022190580A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
session
message
unit
relay
Prior art date
Application number
PCT/JP2021/048221
Other languages
English (en)
French (fr)
Inventor
礒山芳一
福田國統
Original Assignee
住友電気工業株式会社
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 住友電気工業株式会社 filed Critical 住友電気工業株式会社
Priority to DE112021007272.2T priority Critical patent/DE112021007272T5/de
Priority to US18/281,307 priority patent/US20240157893A1/en
Priority to CN202180093430.0A priority patent/CN116830522A/zh
Priority to JP2023505129A priority patent/JPWO2022190580A1/ja
Publication of WO2022190580A1 publication Critical patent/WO2022190580A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B3/00—Line transmission systems
    • H04B3/02—Details
    • H04B3/36—Repeater circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the present disclosure relates to an in-vehicle relay device, a management device, an in-vehicle system, and a communication management method.
  • This application claims priority based on Japanese Patent Application No. 2021-39794 filed on March 12, 2021 and Japanese Patent Application No. 2021-134479 filed on August 20, 2021. , the entire disclosure of which is incorporated herein.
  • Patent Document 1 Japanese Patent Laid-Open No. 2018-26791 discloses a frame transmission blocking device as follows. That is, the frame transmission blocking device is a frame transmission blocking device connected to a bus in a network system in which a plurality of electronic control units communicate via the bus, and includes a receiving section for receiving frames from the bus, and a receiving section for receiving frames from the bus. A process of switching whether or not to execute a predetermined process for blocking transmission of a frame received by the receiving unit when the frame received by the receiving unit satisfies a predetermined condition, based on management information indicating whether or not transmission blocking is permitted. and a part.
  • An in-vehicle relay device includes: a relay unit that performs relay processing for transmitting a plurality of frames received from a plurality of in-vehicle devices respectively to the in-vehicle device as a destination; and the in-vehicle device as a transmission source of the frame determined by the determining unit to include the start request and a start response to the start request.
  • a generating unit configured to generate, for each session, a common key to be used for each session in which one or more of the in-vehicle devices, which are transmission sources of the frame determined by the determination unit to include the start response, participate; a transmitting unit configured to transmit a common key to each of the vehicle-mounted devices participating in the session via the relay unit.
  • a management device is a management device used in an in-vehicle system including a plurality of in-vehicle devices, and starts a communication session between the plurality of in-vehicle devices that are part or all of the plurality of in-vehicle devices.
  • a receiving unit that receives requests and start responses to the start requests from the plurality of in-vehicle devices, respectively; and a transmitting unit configured to transmit the common key to each of the in-vehicle devices participating in the session.
  • An in-vehicle system includes a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and an in-vehicle relay device.
  • Relay processing is performed to transmit each frame to the in-vehicle device as a destination, and the first in-vehicle device performs a session of communication between the plurality of in-vehicle devices that are part or all of the plurality of in-vehicle devices.
  • a first frame including a start request is transmitted to the in-vehicle relay device, and the second in-vehicle device transmits a second frame including a start response to the start request to the in-vehicle relay device.
  • the common key is generated for each session and transmitted to each vehicle-mounted device participating in the session.
  • An in-vehicle system of the present disclosure includes a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and a management device, wherein the first in-vehicle device is a part of the plurality of in-vehicle devices.
  • a request to start a session of communication between all of the plurality of in-vehicle devices is transmitted to the management device, and the second in-vehicle device transmits a start response to the start request to the management device, and the management device generates a common key unique to the session to be used for the session associated with the received start request and start response, and transmits the generated common key to each of the in-vehicle devices participating in the session.
  • a communication management method of the present disclosure is a communication management method in an in-vehicle relay device that performs relay processing for transmitting a plurality of frames received from a plurality of in-vehicle devices respectively to the destination in-vehicle device, wherein the plurality of frames are , determining that a session start request for communication between the plurality of in-vehicle devices is included, and that a start response to the start request is included; generating, for each session, a common key used in the session in which the device and one or more of the in-vehicle devices that are transmission sources of the frame determined to include the start response participate; and sending to each of the in-vehicle devices participating in the session.
  • a communication management method of the present disclosure is a communication management method in a management device used in an in-vehicle system including a plurality of in-vehicle devices, wherein a step of receiving a communication session start request and a start response to the start request from each of the plurality of in-vehicle devices; generating a common key; and transmitting the generated common key to each vehicle-mounted device participating in the session.
  • a communication management method of the present disclosure transmits a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and a plurality of frames received from the plurality of in-vehicle devices, respectively, to the destination in-vehicle device.
  • a communication management method in an in-vehicle system including an in-vehicle relay device that performs relay processing, wherein the first in-vehicle device is a part or all of the plurality of in-vehicle devices, and communication between a plurality of the in-vehicle devices.
  • a communication management method of the present disclosure is a communication management method in an in-vehicle system including a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and a management device, wherein the first in-vehicle device a step of transmitting a session start request for communication between the plurality of in-vehicle devices, which are part or all of the plurality of in-vehicle devices, to the management device; a step of transmitting a response to the management device; the management device generating a common key unique to the session to be used for the session associated with the received start request and the start response; and sending to each of the in-vehicle devices participating in the session.
  • One aspect of the present disclosure can be implemented not only as an in-vehicle relay device including such a characteristic processing unit, but also as a semiconductor integrated circuit that implements part or all of the in-vehicle relay device, or as an in-vehicle relay device. It can be realized as a program for causing a computer to execute the processing steps in the device, it can be realized as a semiconductor integrated circuit that realizes part or all of an in-vehicle system equipped with an in-vehicle relay device, or it can be realized as a semiconductor integrated circuit that implements the processing steps in the in-vehicle system. It can be implemented as a program to be executed by a computer.
  • One aspect of the present disclosure can be implemented not only as a management device including such a characteristic processing unit, but also as a semiconductor integrated circuit that implements part or all of the management device, can be realized as a program for causing a computer to execute the steps of, or as a semiconductor integrated circuit that realizes part or all of an in-vehicle system equipped with a management device, or causes a computer to execute the processing steps in the in-vehicle system. It can be implemented as a program for
  • FIG. 1 is a diagram showing the configuration of an in-vehicle system according to the first embodiment of the present disclosure.
  • FIG. 2 is a diagram illustrating an example of Ethernet frames transmitted and received in the vehicle-mounted system according to the first embodiment of the present disclosure.
  • FIG. 3 is a diagram showing an example of SOME/IP-SD messages transmitted and received in the vehicle-mounted system according to the first embodiment of the present disclosure.
  • FIG. 4 is a diagram illustrating an example of SOME/IP messages transmitted and received in the in-vehicle system according to the first embodiment of the present disclosure;
  • FIG. 5 is a diagram showing the configuration of an in-vehicle ECU according to the first embodiment of the present disclosure.
  • FIG. 1 is a diagram showing the configuration of an in-vehicle system according to the first embodiment of the present disclosure.
  • FIG. 2 is a diagram illustrating an example of Ethernet frames transmitted and received in the vehicle-mounted system according to the first embodiment of the present disclosure.
  • FIG. 3 is a diagram showing an example
  • FIG. 6 is a diagram illustrating a configuration of a relay device according to the first embodiment of the present disclosure
  • 7 is a diagram illustrating an example of a connection destination list stored in a storage unit in the relay device according to the first embodiment of the present disclosure
  • FIG. FIG. 8 is a diagram illustrating an example of an unauthorized log list in a storage unit in the relay device according to the first embodiment of the present disclosure
  • 9 is a diagram illustrating an example of a session log list in a storage unit in the relay device according to the first embodiment of the present disclosure
  • FIG. FIG. 10 is a diagram illustrating an example of a session between a server and a client in the vehicle-mounted system according to the first embodiment of the present disclosure
  • FIG. 11 is a flowchart that defines an example of an operation procedure when the relay device according to the first embodiment of the present disclosure distributes the session key.
  • FIG. 12 is a flowchart that defines an example of an operation procedure when the relay device according to the first embodiment of the present disclosure distributes the session key.
  • FIG. 13 is a diagram illustrating an example of a communication sequence in the in-vehicle system according to the first embodiment of the present disclosure;
  • FIG. 14 is a diagram illustrating another example of a communication sequence in the vehicle-mounted system according to the first embodiment of the present disclosure;
  • FIG. 15 is a diagram showing the configuration of an in-vehicle system according to the second embodiment of the present disclosure.
  • FIG. 16 is a diagram illustrating the configuration of a management device according to the second embodiment of the present disclosure
  • FIG. 17 is a flowchart defining an example of an operation procedure when the management device according to the second embodiment of the present disclosure distributes session keys.
  • FIG. 18 is a diagram illustrating an example of a communication sequence in an in-vehicle system according to the second embodiment of the present disclosure
  • FIG. 19 is a diagram illustrating another example of the communication sequence in the in-vehicle system according to the second embodiment of the present disclosure;
  • the frame transmission blocking device described in Patent Literature 1 detects an unauthorized message based on the content of a data frame, that is, a message transmitted and received by an ECU (Electronic Control Unit) and the message transmission/reception cycle.
  • ECU Electronic Control Unit
  • the present disclosure has been made to solve the above problems, and its object is to provide an in-vehicle relay device, a management device, an in-vehicle system, and a communication management method that can further improve security in an in-vehicle network. is.
  • An in-vehicle relay device includes: a relay unit that performs relay processing for transmitting a plurality of frames received from a plurality of in-vehicle devices respectively to the in-vehicle device as a destination; includes a session start request for communication between the plurality of in-vehicle devices and includes a start response to the start request; A common key used for each session in which the in-vehicle device that is the transmission source of the frame and one or more of the in-vehicle devices that are the transmission source of the frame determined by the determination unit to include the start response is used for each session. and a transmission unit configured to transmit the common key to each vehicle-mounted device participating in the session via the relay unit.
  • the in-vehicle relay device determines that the received frame includes the start request and that the received frame includes the start response, and determines that the received frame includes the start request and the in-vehicle device as the transmission source of the frame including the start response.
  • a common key used for a session in which one or more in-vehicle devices that transmit frames participate is generated for each session and transmitted to each in-vehicle device, so that individual common keys are used for each session between in-vehicle devices Since communication can be performed, the security of communication between on-vehicle devices can be improved.
  • the in-vehicle relay device further includes a storage unit that stores a unique ID of each of the in-vehicle devices, and the transmission unit receives the common key encrypted using one of the unique IDs as an encryption key. , the transmission may be performed via the relay unit to the in-vehicle device having the unique ID used for encryption.
  • the transmission unit transmits a hash value calculated using the one unique ID and the common key to the in-vehicle device having the unique ID used to calculate the hash value, via the relay unit. Further transmission may be performed.
  • the hash value calculated using its own unique ID and the common key from the in-vehicle relay device and the hash value received from the in-vehicle relay device are combined. By collating , it is possible to confirm whether or not the common key received from the in-vehicle relay device has been tampered with.
  • the in-vehicle relay device may further include a recording unit that records session information related to the session using the common key.
  • the session information recorded by the in-vehicle relay device can be used, for example, for digital forensics.
  • session information about multiple sessions can be aggregated in the in-vehicle relay device without providing each in-vehicle device with a function to store session information. Recording is possible with a simple configuration.
  • the recording unit may record, as the session information, a transmission time of the common key by the relay unit.
  • the in-vehicle relay device can record the start of the session.
  • the determination unit determines that the frame received by the relay unit includes the session termination request, and the recording unit stores the session information of the frame including the termination request.
  • the configuration may be such that the reception time by the relay unit is recorded.
  • the in-vehicle relay device can record the end of the session.
  • the judging unit judges whether the frame received by the relay unit includes the start request or the start response according to a judgment result, and the relay unit performs the judgment.
  • the relay processing or discarding of the frame may be performed according to the determination result of the propriety of the frame by the unit.
  • a management device is a management device used in an in-vehicle system including a plurality of in-vehicle devices, and includes a plurality of in-vehicle devices that are part or all of the plurality of in-vehicle devices.
  • a receiving unit that receives a session start request for communication between devices and a start response to the start request from each of the plurality of in-vehicle devices;
  • a generating unit that generates a unique common key, and a transmitting unit that transmits the common key to each of the in-vehicle devices participating in the session.
  • the management device further includes a storage unit that stores a unique ID of each vehicle-mounted device, and the transmission unit stores the common key encrypted using one of the unique IDs as an encryption key, It may be transmitted to the in-vehicle device having the unique ID used for encryption.
  • the transmitting unit may further transmit a hash value calculated using the one unique ID and the common key to the in-vehicle device having the unique ID used to calculate the hash value. good.
  • the in-vehicle device that receives the common key from the management device compares the hash value calculated using its own unique ID and the common key from the management device with the hash value received from the management device. Accordingly, it is possible to confirm whether or not the common key received from the management apparatus has been tampered with.
  • the receiving unit receives a request to end the session from the in-vehicle device, and the transmitting unit issues a termination instruction to the session to terminate the session based on the reception of the termination request by the receiving unit. It may be transmitted to other participating in-vehicle devices.
  • the management device can be involved in session termination and record the in-vehicle device that sent the termination request and the session termination time, so the recorded information can be used, for example, for digital forensics.
  • the management device may further include a recording unit that records session information relating to the session in which the common key is used.
  • the session information recorded by the management device can be used, for example, for digital forensics.
  • session information about multiple sessions can be aggregated in the management device without giving each in-vehicle device a function to store session information. can be recorded in a simple configuration.
  • the recording unit may record, as the session information, a transmission time of the common key by the transmission unit.
  • the management device can record the start of a session.
  • the management device further includes a recording unit that records session information related to the session using the common key, and the recording unit stores, as the session information, the time when the end request was received by the reception unit. may be recorded.
  • the management device can participate in the termination of the session and record the termination of the session.
  • An in-vehicle system includes a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and an in-vehicle relay device.
  • relay processing for transmitting a plurality of frames received from each of the in-vehicle devices to the destination in-vehicle device, and A first frame including a session start request for communication between in-vehicle devices is transmitted to the in-vehicle relay device, and the second in-vehicle device transmits a second frame including a start response to the start request to the in-vehicle relay device.
  • a common key to be used for the session is generated for each session, and the generated common key is transmitted to each vehicle-mounted device participating in the session.
  • the first in-vehicle device transmits the start request to the in-vehicle relay device
  • the second in-vehicle device transmits the start response to the in-vehicle relay device
  • the in-vehicle relay device transmits the start request to the in-vehicle relay device.
  • the in-vehicle relay device, the first in-vehicle device and the second in-vehicle device may be connected without another relay device.
  • the in-vehicle relay device can receive the frame transmitted by the first in-vehicle device and the frame transmitted by the second in-vehicle device. It is possible to easily generate and transmit a common key for a session in which a device participates.
  • the in-vehicle device When the in-vehicle device detects an abnormality in the in-vehicle system while transmitting information to the plurality of in-vehicle devices by multicast, the in-vehicle device switches to a state of transmitting information to the plurality of in-vehicle devices by unicast. You can switch.
  • the in-vehicle relay device includes a storage unit that stores a unique ID of each in-vehicle device in the in-vehicle system, and the in-vehicle relay device is calculated using one of the unique IDs and the common key.
  • the hash value is further transmitted to the in-vehicle device having the unique ID used to calculate the hash value, and the in-vehicle device uses the common key received from the in-vehicle relay device and the own unique ID.
  • the calculated hash value may be compared with the hash value received from the in-vehicle relay device.
  • the in-vehicle device confirms whether or not the common key received from the in-vehicle relay device has been tampered with based on the result of matching the calculated hash value with the hash value received from the in-vehicle relay device. be able to.
  • An in-vehicle system includes a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and a management device, wherein the first in-vehicle device includes the plurality of to the management device, and the second vehicle-mounted device sends a start response to the start request to the management device.
  • the management device generates a common key unique to the session to be used for the session associated with the received start request and the start response, and uses the generated common key to participate in the session Send to each in-vehicle device.
  • the first in-vehicle device transmits a session start request to the management device
  • the second in-vehicle device transmits a start response to the start request to the management device
  • the management device sends
  • To improve the security of communication between in-vehicle devices by generating a unique common key and transmitting it to each in-vehicle device, so that communication can be performed between in-vehicle devices using an individual common key for each session. can be done.
  • by authenticating the vehicle-mounted device that has transmitted the start request it is possible to detect a start request from an unauthorized device. Therefore, security in the in-vehicle network can be further improved.
  • the in-vehicle device When the in-vehicle device detects an abnormality in the in-vehicle system while transmitting information to the plurality of in-vehicle devices by multicast, the in-vehicle device switches to a state of transmitting information to the plurality of in-vehicle devices by unicast. You can switch.
  • the management device includes a storage unit that stores a unique ID of each vehicle-mounted device in the vehicle-mounted system, and the management device stores a hash value calculated using the single unique ID and the common key. is further transmitted to the in-vehicle device having the unique ID used to calculate the hash value, and the in-vehicle device calculates using the common key received from the management device and the own unique ID A hash value may be compared with the hash value received from the management device.
  • the in-vehicle device to check whether or not the common key received from the management device has been tampered with based on the result of matching the calculated hash value with the hash value received from the management device. can.
  • a communication management method is a communication management method in an in-vehicle relay device that performs relay processing for transmitting a plurality of frames received from a plurality of in-vehicle devices to the destination in-vehicle device. determining that the plurality of frames include a session start request for communication between the plurality of in-vehicle devices and a start response to the start request; and determining that the plurality of frames include the start request.
  • the in-vehicle relay device determines that the received frame includes the start request and that the received frame includes the start response, and determines that the received frame includes the start request and the in-vehicle device as the transmission source of the frame including the start response.
  • a method of generating a common key for each session in which one or more in-vehicle devices that transmit frames participate and transmitting the common key to each in-vehicle device uses an individual common key for each session between in-vehicle devices. Since communication can be performed, the security of communication between on-vehicle devices can be improved.
  • a communication management method is a communication management method in a management device used in an in-vehicle system including a plurality of in-vehicle devices, wherein some or all of the plurality of in-vehicle devices a step of receiving, from the plurality of in-vehicle devices, a session start request for communication between certain in-vehicle devices and a start response to the start request from each of the plurality of in-vehicle devices; and the session linked to the received start request and start response. and transmitting the generated common key to each vehicle-mounted device participating in the session.
  • a communication management method is to send a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and a plurality of frames received from the plurality of in-vehicle devices to a destination.
  • the first in-vehicle device is part or all of the plurality of in-vehicle devices a step of transmitting a first frame including a session initiation request for communication between the plurality of in-vehicle devices to the in-vehicle relay device; and a second in-vehicle device sending a second frame including an initiation response to the initiation request. to the in-vehicle relay device, and the in-vehicle relay device transmits the first frame as a transmission source of the received first frame and the second in-vehicle device as a transmission source of the received second frame. a step of generating a common key used for each of the sessions in which the in-vehicle devices participate in each session, and transmitting the generated common key to each of the in-vehicle devices participating in the session.
  • the first in-vehicle device transmits the start request to the in-vehicle relay device
  • the second in-vehicle device transmits the start response to the in-vehicle relay device
  • the in-vehicle relay device transmits the start request to the in-vehicle relay device.
  • a communication management method is a communication management method in an in-vehicle system including a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and a management device, the first in-vehicle device transmitting a session start request for communication between the plurality of in-vehicle devices, which are part or all of the plurality of in-vehicle devices, to the management device; a step of a device transmitting a start response to the start request to the management device; and a step of the management device generating a common key unique to the session to be used for the session associated with the received start request and the start response. and transmitting the generated common key to each vehicle-mounted device participating in the session.
  • the first in-vehicle device transmits a session start request to the management device
  • the second in-vehicle device transmits a start response to the start request to the management device
  • the management device sends
  • To improve the security of communication between in-vehicle devices by generating a unique common key and transmitting it to each in-vehicle device so that communication can be performed using a separate common key for each session between in-vehicle devices. can be done.
  • by authenticating the vehicle-mounted device that has transmitted the start request it is possible to detect a start request from an unauthorized device. Therefore, security in the in-vehicle network can be further improved.
  • FIG. 1 is a diagram showing the configuration of an in-vehicle system according to the first embodiment of the present disclosure.
  • in-vehicle system 301 includes relay device 101 and multiple in-vehicle ECUs 111 .
  • the relay device 101 is an example of a vehicle-mounted relay device.
  • the in-vehicle ECU 111 is an example of an in-vehicle device.
  • the vehicle-mounted system 301 is mounted on the vehicle 1 .
  • the relay device 101 is used for an in-vehicle system 301 .
  • the relay device 101 is connected to each in-vehicle ECU 111 via the cable 14 .
  • the relay device 101 and the in-vehicle ECU 111 are connected without another relay device.
  • Cable 14 is, for example, an Ethernet (registered trademark) cable.
  • Relay device 101 and in-vehicle ECU 111 constitute an in-vehicle network.
  • the in-vehicle ECU 111 gives instructions to various devices in an electric power steering (EPS), a brake control device, an accelerator control device, a steering control device, and an advanced driver-assistance system (ADAS). It is a driving assistance device, a sensor, or the like.
  • EPS electric power steering
  • ADAS advanced driver-assistance system
  • FIG. 2 is a diagram showing an example of Ethernet frames transmitted and received in the in-vehicle system according to the first embodiment of the present disclosure.
  • an Ethernet frame has an Ethernet header, an IP (Internet Protocol) header, a TCP (Transmission Control Protocol) header, a data field, and an FCS (Frame Check Sequence).
  • the Ethernet header stores a destination MAC (Media Access Control) address, a source MAC address, and a type.
  • the in-vehicle ECU 111 generates an Ethernet frame addressed to another in-vehicle ECU 111 and transmits the generated Ethernet frame to the relay device 101 .
  • the relay device 101 can communicate with the in-vehicle ECU 111 .
  • the relay device 101 performs relay processing for transmitting the Ethernet frame received from the in-vehicle ECU 111 to another in-vehicle ECU 111 .
  • the relay device 101 performs relay processing according to Layer 2.
  • the relay device 101 may be configured to perform relay processing according to Layer 3, which is higher than Layer 2.
  • SOME/IP Scalable service-Oriented Middleware over IP
  • SOME/IP Scalable service-Oriented Middleware over IP
  • the in-vehicle ECU 111 stores a message containing various information in the data field of an Ethernet frame, and transmits the Ethernet frame to another in-vehicle ECU 111 via the relay device 101 according to SOME/IP.
  • the in-vehicle ECU 111 starts a communication session between multiple in-vehicle ECUs 111 .
  • a plurality of in-vehicle ECUs 111 participating in the session transmit and receive messages.
  • the combination of in-vehicle ECUs 111 participating in the session is not fixed but dynamically changes.
  • a session is started between a sensor that is the in-vehicle ECU 111 and a driving support device that is another in-vehicle ECU 111 .
  • the sensor stores sensor information regarding the running state of the vehicle 1 or the surrounding state in a message and transmits the message to the driving support device as a service.
  • the driving support device acquires sensor information provided as a service from the received message, generates various control information regarding driving of the vehicle 1 using the sensor information, and transmits the generated various control information to the brake control device and Send to the steering control device, etc.
  • the in-vehicle ECU 111 that provides services is also referred to as a "server”. Further, the in-vehicle ECU 111 that receives the service is also called a "client”.
  • the in-vehicle ECU 111 may function only as a server, may function only as a client, or may function as a server or a client depending on the content of the service in the session.
  • a server is an example of a first in-vehicle device.
  • a client is an example of a second in-vehicle device.
  • (A) Start of Session In communication conforming to SOME/IP, a session is started by executing Service Discovery. More specifically, the multiple in-vehicle ECUs 111 initiate sessions by transmitting and receiving SOME/IP-SD messages.
  • FIG. 3 is a diagram showing an example of SOME/IP-SD messages transmitted and received in the in-vehicle system according to the first embodiment of the present disclosure.
  • the SOME/IP-SD message has a SOME/IP header and a SOME/IP-SD header.
  • (A-1) Offer Message As an example, the service discovery function allows the server to offer a service, and a session between the client and the server is started.
  • an in-vehicle ECU 111 periodically or irregularly multicasts an Offer message, which is an example of a SOME/IP-SD message. More specifically, the server generates an Offer message in which a service ID corresponding to a service that the server can provide is stored in the SOME/IP-SD header. Then, the server generates an Ethernet frame in which the Offer message is stored in the data field and the multicast address is stored as the destination MAC address, and transmits the generated Ethernet frame to the relay device 101 .
  • the Offer message is an example of a session start request.
  • the in-vehicle ECU 111 that requires the service corresponding to the service ID included in the Offer message is an example of a SOME/IP-SD message as a client.
  • a certain Subscribe message is sent to the server via the relay device 101 . More specifically, the client generates an Ethernet frame in which the Subscribe message is stored in the data field, and transmits the generated Ethernet frame to the server via relay device 101 .
  • the Subscribe message is an example of a start response to a session start request.
  • the server When the server receives the Subscribe message from the client via the relay device 101, it starts providing services to the client.
  • the service discovery function allows the client to search for a server that provides a service, and a communication session between the client and the server is started.
  • an in-vehicle ECU 111 multicasts a Find message, which is an example of a SOME/IP-SD message, periodically or irregularly as a client. More specifically, the client generates a Find message in which the service ID corresponding to the service to be provided is stored in the SOME/IP-SD header. Then, the client generates an Ethernet frame in which the Find message is stored in the data field and the multicast address is stored as the destination MAC address, and transmits the generated Ethernet frame to the relay device 101 .
  • the Find message is an example of a session search request.
  • the in-vehicle ECU 111 that can provide the service corresponding to the service ID included in the Find message is an example of a SOME/IP-SD message as a server.
  • An Offer message is sent to the client via the relay device 101 . More specifically, the server generates an Ethernet frame with an Offer message stored in the data field, and transmits the generated Ethernet frame to the client via relay device 101 .
  • the Offer message is an example of a start request for a session search request.
  • the client When the client receives an Offer message from the server via the relay device 101, it sends a Subscribe message, which is an example of a SOME/IP-SD message, to the server via the relay device 101. More specifically, the client generates an Ethernet frame in which the Subscribe message is stored in the data field, and transmits the generated Ethernet frame to the server via relay device 101 .
  • the Subscribe message is an example of a start response to a session start request.
  • the server When the server receives the Subscribe message from the client via the relay device 101, it starts providing services to the client.
  • FIG. 4 is a diagram showing an example of SOME/IP messages transmitted and received in the in-vehicle system according to the first embodiment of the present disclosure.
  • a SOME/IP message has a SOME/IP header and a payload.
  • the server periodically or irregularly transmits a session message, which is an example of a SOME/IP message, to the client via the relay device 101 . More specifically, the server generates a session message in which information to be provided as a service is stored in the payload. Then, the server generates an Ethernet frame in which the session message is stored in the data field, and transmits the generated Ethernet frame to the client via relay device 101 .
  • a session message which is an example of a SOME/IP message
  • Termination of Session In communication conforming to SOME/IP, a session is terminated by executing Service Discovery. More specifically, the multiple in-vehicle ECUs 111 end the session by transmitting and receiving SOME/IP-SD messages.
  • (C-1) StopOffer message As an example, the service discovery function allows the server to offer to stop providing the service, and the session ends.
  • the server when the server stops providing services, it sends a StopOffer message, which is an example of a SOME/IP-SD message, to the client. More specifically, the server generates a StopOffer message in which the service ID corresponding to the service to stop providing is stored in the SOME/IP-SD header. Then, the server generates an Ethernet frame in which the StopOffer message is stored in the data field, and transmits the generated Ethernet frame to the client via relay device 101 .
  • the StopOffer message is an example of a session termination request.
  • the server After sending the StopOffer message to the client via the relay device 101, the server terminates the provision of services to the client.
  • the service discovery function causes the client to request to stop enjoying the service, and the session ends.
  • a client when a client stops enjoying a service, it sends a StopSubscribe message, which is an example of a SOME/IP-SD message, to the server. More specifically, the client generates a StopSubscribe message in which the service ID corresponding to the service to stop enjoying is stored in the SOME/IP-SD header. Then, the client generates an Ethernet frame in which the StopSubscribe message is stored in the data field, and transmits the generated Ethernet frame to the server via relay device 101 .
  • the StopSubscribe message is an example of a session termination request.
  • the server When the server receives the Subscribe message from the client via the relay device 101, it ends providing services to the client.
  • FIG. 5 is a diagram showing the configuration of an in-vehicle ECU according to the first embodiment of the present disclosure.
  • in-vehicle ECU 111 includes communication unit 11 , processing unit 12 , and storage unit 13 .
  • the communication unit 11 and the processing unit 12 are implemented by processors such as a CPU (Central Processing Unit) and a DSP (Digital Signal Processor).
  • Storage unit 13 is, for example, a non-volatile memory.
  • the storage unit 13 in the in-vehicle ECU 111 stores the unique ID of the in-vehicle ECU 111, the ECU identifier that is the identifier of the in-vehicle ECU 111, the endpoint information of the in-vehicle ECU 111, and the endpoint information of the relay device 101.
  • the unique ID is written into storage unit 13, for example, when vehicle 1 is shipped.
  • the unique ID has higher confidentiality than the ECU identifier.
  • Endpoint information includes IP addresses and logical port numbers.
  • the storage unit 13 also stores a service list indicating the correspondence between the service content provided by the in-vehicle system 301 and the service ID.
  • FIG. 6 is a diagram showing the configuration of the relay device according to the first embodiment of the present disclosure.
  • relay device 101 includes multiple communication ports 21 , relay unit 22 , processing unit 23 , log generation unit 24 and storage unit 25 .
  • the processing unit 23 is an example of a determination unit, an example of a generation unit, and an example of a transmission unit.
  • the log generation unit 24 is an example of a recording unit.
  • the relay unit 22, the processing unit 23, and the log generation unit 24 are realized by processors such as CPU and DSP, for example.
  • Storage unit 25 is, for example, a non-volatile memory.
  • the communication port 21 is a terminal to which the cable 14 can be connected.
  • the communication port 21 is connected to the in-vehicle ECU 111 via the cable 14 .
  • the communication port 21 may be a terminal of an integrated circuit.
  • the storage unit 25 stores an address table Tb1 showing the correspondence between the port number of the communication port 21 and the MAC address of the in-vehicle ECU 111 connected to the communication port 21.
  • the storage unit 25 also stores the unique ID of each in-vehicle ECU 111 in the in-vehicle system 301 .
  • the storage unit 25 stores, for each service ID, a connection destination list indicating endpoint information, ECU identifiers, and unique IDs of servers and clients that may be involved in the service.
  • FIG. 7 is a diagram showing an example of a connection destination list stored in the storage unit in the relay device according to the first embodiment of the present disclosure.
  • the connection destination list includes endpoint information of two servers and two clients that can be involved in the service with the service ID of "0x0001", and information on the service with the service ID of "0x0002". Endpoint information, etc. of one server and two clients that may be involved are registered.
  • a server that can be involved in a service with a service ID of "0x0002” has endpoint information of "AAA", an ECU identifier of "ECU_1", and a unique ID. is registered as the in-vehicle ECU 111 with "ID_A".
  • the numbers starting with "0x” mean that the numbers after "0x" are represented in hexadecimal.
  • the relay unit 22 performs relay processing for transmitting a plurality of Ethernet frames received from the plurality of in-vehicle ECUs 111 respectively to the destination in-vehicle ECUs 111 . As will be described later, the relay unit 22 may discard the received Ethernet frame without relaying it to the destination in-vehicle ECU 111 according to an instruction from the processing unit 23 .
  • the relay unit 22 upon receiving an Ethernet frame from a vehicle-mounted ECU 111 via the corresponding communication port 21 , stores the received Ethernet frame in the storage unit 25 .
  • the processing unit 23 determines whether the Ethernet frame received by the relay unit 22 contains a SOME/IP-SD message. For example, when an Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 checks whether the data field of the Ethernet frame includes a SOME/IP-SD header.
  • the processing unit 23 determines that the Ethernet frame does not include a SOME/IP-SD message. Then, a relay instruction indicating that the Ethernet frame should be relayed is output to the relay unit 22 .
  • the relay unit 22 Upon receiving a relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing for the Ethernet frame. Specifically, the relay unit 22 refers to the address table Tb1 in the storage unit 25, and transmits the Ethernet frame to the destination vehicle-mounted ECU 111 via the communication port 21 having the port number corresponding to the destination MAC address of the Ethernet frame.
  • the processing unit 23 determines that the Ethernet frame includes a SOME/IP-SD message. to decide. Then, the processing unit 23 determines that the Ethernet frame includes an Offer message by referring to the SOME/IP-SD header. Alternatively, the processing unit 23 refers to the SOME/IP-SD header of the Ethernet frame stored in the storage unit 25 by the relay unit 22 to determine that the Ethernet frame includes the Find message. Alternatively, the processing unit 23 refers to the SOME/IP-SD header of the Ethernet frame stored in the storage unit 25 by the relay unit 22 to determine that the Ethernet frame includes the Subscribe message.
  • the processing unit 23 refers to the SOME/IP-SD header of the Ethernet frame stored in the storage unit 25 by the relay unit 22 to determine that the Ethernet frame includes the StopOffer message.
  • the processing unit 23 refers to the SOME/IP-SD header of the Ethernet frame stored in the storage unit 25 by the relay unit 22 to determine that the Ethernet frame includes the StopSubscribe message.
  • the processing unit 23 determines that the Ethernet frame stored in the storage unit 25 by the relay unit 22 includes a SOME/IP-SD message, it determines whether the Ethernet frame is appropriate.
  • the relay unit 22 relays or discards the Ethernet frame according to the determination result of the suitability of the Ethernet frame by the processing unit 23 .
  • the processing unit 23 determines that the Ethernet frame is inappropriate, the processing unit 23 outputs to the relay unit 22 a discard instruction indicating that the Ethernet frame should be discarded.
  • the relay unit 22 Upon receiving a discard instruction from the processing unit 23 , the relay unit 22 discards the Ethernet frame indicated by the relay instruction in the storage unit 25 .
  • the processing unit 23 determines that the Ethernet frame is appropriate, the processing unit 23 outputs to the relay unit 22 a relay instruction indicating that the Ethernet frame should be relayed.
  • the relay unit 22 Upon receiving a relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing for the Ethernet frame.
  • the processing unit 23 includes the in-vehicle ECU 111 that is the transmission source of the Ethernet frame determined to include the start request such as the Offer message, and one or more in-vehicle ECUs 111 that are the transmission source of the Ethernet frame determined to include the start response such as the Subscribe message. generates a session key K to be used for each session in which it participates.
  • the session key K is an example of a common key, and is, for example, a random number with a key length according to the encryption method used.
  • the processing unit 23 generates a session key K with random content for each session.
  • the processing unit 23 transmits the generated session key K to each in-vehicle ECU 111 participating in the session via the relay unit 22 .
  • the log generation unit 24 records session information related to sessions in which the session key K generated by the processing unit 23 is used.
  • (1) Processing example 1 in Service Discovery (1-1) Transmission of Offer Message by Server Referring again to FIG. Get the corresponding service ID.
  • the processing unit 12 also acquires the ECU identifier and the endpoint information of the in-vehicle ECU 111 from the storage unit 13 .
  • the processing unit 12 generates an Offer message including the acquired service ID, ECU identifier, and endpoint information.
  • the processing unit 12 calculates a MAC (Message Authentication Code) value based on the generated Offer message and the unique ID in the storage unit 13 .
  • the processing unit 12 generates an Ethernet frame in which the Offer message and the MAC value are stored in the data field and the multicast address is stored as the destination MAC address.
  • the processing unit 12 outputs the generated Ethernet frame to the communication unit 11 .
  • the communication unit 11 transmits the Ethernet frame received from the processing unit 12 to the relay device 101 .
  • the processing unit 23 When the Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 confirms that the data field of the Ethernet frame includes the SOME/IP-SD header, and stores the SOME/IP-SD header. , it is determined that the Ethernet frame contains an Offer message. Then, the processing unit 23 determines whether the Ethernet frame is appropriate.
  • the processing unit 23 acquires the Offer message, MAC value, and time stamp from the Ethernet frame.
  • the processing unit 23 also acquires the service ID, the endpoint information of the in-vehicle ECU 111, and the ECU identifier from the acquired Offer message.
  • the processing unit 23 refers to the connection destination list in the storage unit 25, and is identified by the endpoint information and the ECU identifier obtained from the Offer message as a server that can participate in the service indicated by the service ID obtained from the Offer message. It is checked whether the in-vehicle ECU 111 is registered in the connection destination list.
  • the processing unit 23 participates in the service indicated by the service ID.
  • the server to be obtained it is determined that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list.
  • the processing unit 23 also refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Offer message.
  • the processing unit 23 calculates a MAC value based on the Offer message and the acquired unique ID. Then, the processing unit 23 compares the MAC value obtained from the Ethernet frame with the MAC value calculated by itself to determine whether the Ethernet frame has been tampered with.
  • the processing unit 23 determines that the in-vehicle ECU 111 specified by the endpoint information or the like obtained from the Offer message is registered in the connection destination list and that the Ethernet frame has not been tampered with, the Ethernet frame received by the relay unit 22 Decide that the Ethernet frame is appropriate. On the other hand, if the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Offer message is not registered in the connection destination list, or if the processing unit 23 determines that the Ethernet frame has been tampered with, the relay unit 22 Determine that the received Ethernet frame is inappropriate.
  • the processing unit 23 determines that the Ethernet frame is appropriate, the processing unit 23 stores the ECU identifier and endpoint information obtained from the Offer message in the storage unit 25 as server information.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate, the processing unit 23 deletes the ECU identifier and the endpoint information from the Offer message included in the Ethernet frame in the storage unit 25 . Then, the processing unit 23 outputs to the relay unit 22 a relay instruction indicating that the Ethernet frame should be relayed.
  • the relay unit 22 Upon receiving a relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing for the Ethernet frame. Specifically, the relay unit 22 transmits the Ethernet frame from which the ECU identifier and the endpoint information have been deleted by the processing unit 23 according to the multicast address, which is the destination MAC address of the Ethernet frame. It transmits to vehicle-mounted ECU111 other than.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs to the relay unit 22 a discard instruction indicating that the Ethernet frame should be discarded.
  • the relay unit 22 Upon receiving a discard instruction from the processing unit 23, the relay unit 22 discards the Ethernet frame indicated by the discard instruction.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs an Offer message and a time stamp to the log generation unit 24 .
  • the log generation unit 24 records information about messages contained in Ethernet frames that are determined to be inappropriate by the processing unit 23 .
  • FIG. 8 is a diagram showing an example of an unauthorized log list in the storage unit of the relay device according to the first embodiment of the present disclosure.
  • storage unit 25 stores a byte string of a message included in an Ethernet frame determined to be inappropriate by processing unit 23, an ECU identifier of in-vehicle ECU 111 that is the transmission source of the Ethernet frame, and a A fraud log list R1, which is a list of fraud logs indicating the reception time of
  • the log generation unit 24 receives an Offer message and a time stamp from the processing unit 23, acquires an ECU identifier included in the received Offer message, and uses the byte string of the Offer message, the acquired ECU identifier, and the reception time as an unauthorized log. It is written to the fraud log list R1 in the storage unit 25.
  • processing unit 12 receives an Ethernet frame from relay device 101 via communication unit 11, and receives the received Ethernet frame. Get the source MAC address and the Offer message from. Also, the processing unit 12 acquires a service ID from the acquired Offer message.
  • the processing unit 12 refers to the service list in the storage unit 13 and determines whether the service indicated by the acquired service ID is necessary. When the processing unit 12 determines that the service is necessary, the processing unit 12 acquires the ECU identifier and the endpoint information of the in-vehicle ECU 111 from the storage unit 13, and stores the service ID corresponding to the service, the acquired ECU identifier, and the acquired end point information. Generate a Subscribe message containing the point information. On the other hand, when the processing unit 12 determines that the service is unnecessary, it does not generate a Subscribe message.
  • the processing unit 12 calculates the MAC value based on the generated Subscribe message and the unique ID in the storage unit 13.
  • the processing unit 12 generates an Ethernet frame in which the Subscribe message and the MAC value are stored in the data field and the MAC address of the server is stored as the destination MAC address.
  • the processing unit 12 outputs the generated Ethernet frame to the communication unit 11 .
  • the communication unit 11 transmits the Ethernet frame received from the processing unit 12 to the relay device 101 .
  • the processing unit 23 When the Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 confirms that the data field of the Ethernet frame includes the SOME/IP-SD header, and stores the SOME/IP-SD header. , it is determined that the Ethernet frame contains the Subscribe message. Then, the processing unit 23 determines whether the Ethernet frame is appropriate.
  • the processing unit 23 acquires the Subscribe message, MAC value, and time stamp from the Ethernet frame. Also, the processing unit 23 acquires the service ID, the endpoint information of the in-vehicle ECU 111, and the ECU identifier from the acquired Subscribe message. Then, the processing unit 23 refers to the connection destination list in the storage unit 25, and is identified by the endpoint information and the ECU identifier acquired from the Subscribe message as a client that can participate in the service indicated by the service ID acquired from the Subscribe message. It is checked whether the in-vehicle ECU 111 is registered in the connection destination list.
  • the processing unit 23 participates in the service indicated by the service ID. It is determined that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list as the client to be obtained.
  • the processing unit 23 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Subscribe message.
  • the processing unit 23 calculates a MAC value based on the Subscribe message and the acquired unique ID. Then, the processing unit 23 compares the MAC value obtained from the Ethernet frame with the MAC value calculated by itself to determine whether the Ethernet frame has been tampered with.
  • the processing unit 23 determines that the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Subscribe message is registered in the connection destination list and that the Ethernet frame has not been tampered with, the Ethernet frame received by the relay unit 22 Decide that the Ethernet frame is appropriate. On the other hand, if the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Subscribe message is not registered in the connection destination list, or if the processing unit 23 determines that the Ethernet frame has been tampered with, the relay unit 22 Determine that the received Ethernet frame is inappropriate.
  • the processing unit 23 determines that the Ethernet frame is appropriate, the processing unit 23 stores the ECU identifier and endpoint information obtained from the Subscribe message in the storage unit 25 as client information.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs to the relay unit 22 a discard instruction indicating that the Ethernet frame should be discarded.
  • the relay unit 22 Upon receiving a discard instruction from the processing unit 23, the relay unit 22 discards the Ethernet frame indicated by the discard instruction.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, the processing unit 23 outputs a subscribe message and a time stamp to the log generation unit 24 .
  • the log generation unit 24 writes information about the message included in the Ethernet frame judged to be inappropriate by the processing unit 23 into the unauthorized log list R1 in the storage unit 25 .
  • the processing unit 23 generates a session key K to be used for the session and a key ID that is the ID of the session key K, and distributes the generated session key K and key ID to the servers and clients participating in the session. .
  • the processing unit 23 also stores the generated session key K and key ID in the storage unit 25 in association with the service ID.
  • the processing unit 23 encrypts the session key K using the unique ID as an encryption key. Also, for example, the processing unit 23 uses the unique ID and the session key K to calculate the hash value HV. Then, the processing unit 23 transmits the encrypted session key K and hash value HV to the in-vehicle ECU 111 having the unique ID used for encrypting the session key K and calculating the hash value HV via the relay unit 22 .
  • the processing unit 23 refers to the connection destination list in the storage unit 25, acquires the unique ID of the server indicated by the server information, and encrypts the session key K using the acquired unique ID as an encryption key.
  • an encryption key KS which is an encrypted session key K for the server, is generated.
  • the processing unit 23 includes the encryption key KS and the corresponding key ID in the subscribe message included in the Ethernet frame in the storage unit 25, and gives the subscribe message and the unique ID of the server to a predetermined hash function. Calculate the value HVS.
  • the processing unit 23 further stores the calculated hash value HVS in the Ethernet frame. Then, the processing unit 23 outputs to the relay unit 22 a relay instruction indicating that the Ethernet frame should be relayed.
  • the relay unit 22 Upon receiving a relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing for the Ethernet frame. Specifically, the relay unit 22 transmits the Ethernet frame in which the encryption key KS, the key ID and the hash value HVS are stored to the server according to the destination MAC address of the Ethernet frame.
  • the processing unit 23 refers to the connection destination list in the storage unit 25, acquires the unique ID of the client indicated by the client information, and encrypts the session key K using the acquired unique ID as an encryption key.
  • An encryption key KC which is an encrypted session key K for the client, is generated.
  • the processing unit 23 generates a start message MC including the endpoint information of the server, the encryption key KC and the corresponding key ID, and gives the generated start message MC and the acquired unique ID to a predetermined hash function. Calculates the hash value HVC.
  • the processing unit 23 generates a client-addressed Ethernet frame including the generated start message MC and the calculated hash value HVC, and transmits the generated Ethernet frame to the client via the relay unit 22 .
  • the processing unit 23 receives the service ID of the service provided in the session to be established, the ECU identifier of the server that is the destination of the subscribe message, the ECU identifier of the client that is the destination of the start message MC, and the output time of the subscribe message and the start message MC.
  • the session information indicating ts is output to the log generation unit 24 .
  • the output time ts indicates the transmission time of the session key K by the relay unit 22 .
  • FIG. 9 is a diagram showing an example of a session log list in the storage unit in the relay device according to the first embodiment of the present disclosure.
  • storage unit 25 stores the service ID of the service provided in the session to be established, the ECU identifiers of the server and client to which session key K is distributed, the session start time, and the session start time.
  • the log generating unit 24 receives the session information from the processing unit 23, and converts the service ID, ECU identifier, and output time ts included in the received session information into the "service ID”, "ECU identifier”, and " start time” in the session log list R2.
  • (1-6) Reception of session key by server Referring again to FIG. Get the hash value HVS.
  • the processing unit 12 collates the hash value calculated using the session key K received from the relay device 101 and its own unique ID with the hash value HVS received from the relay device 101 .
  • the processing unit 12 acquires the unique ID from the storage unit 13, and applies the Subscribe message and the unique ID to a predetermined hash function to calculate a hash value.
  • the processing unit 12 compares the hash value HVS with the hash value calculated by itself to determine whether the Subscribe message has been tampered with.
  • the processing unit 12 determines that the Subscribe message has been tampered with, it discards the Subscribe message. On the other hand, when the processing unit 12 determines that the Subscribe message has not been tampered with, it acquires the client's endpoint information, the encryption key KS, and the key ID from the Subscribe message. Then, the processing unit 12 acquires the session key K by decrypting the encryption key KS using the unique ID.
  • the processing unit 12 compares the key ID in the storage unit 13 with the newly acquired key ID. When the processing unit 12 confirms that the key ID in the storage unit 13 is different from the newly acquired key ID, the processing unit 12 stores the newly acquired endpoint information of the client, the session key K, and the key ID in the storage unit 13. .
  • the processing unit 12 transmits a message requesting retransmission of the session key K to the relay device 101 via the communication unit 11. do.
  • the relay device 101 When receiving the message, the relay device 101 generates a new session key K and transmits it to the server and the client.
  • the same session key K as the session key K used in the past session is distributed to the server and the client, it is possible to prompt the relay device 101 to regenerate the session key K. A reduction in security due to the use of the key K can be avoided.
  • the processing unit 12 receives an Ethernet frame from the relay device 101 via the communication unit 11, and acquires the start message MC and hash value HVC from the received Ethernet frame.
  • the processing unit 12 collates the hash value calculated using the session key K received from the relay device 101 and its own unique ID with the hash value HVC received from the relay device 101 .
  • the processing unit 12 acquires the unique ID from the storage unit 13, and applies the start message MC and the unique ID to a predetermined hash function to calculate a hash value.
  • the processing unit 12 compares the hash value HVC with the hash value calculated by itself to determine whether or not the start message MC has been tampered with.
  • the processing unit 12 determines that the start message MC has been tampered with, it discards the start message MC. On the other hand, when the processing unit 12 determines that the start message MC has not been tampered with, it acquires the endpoint information of the server, the encryption key KC and the key ID from the start message MC. Then, the processing unit 12 acquires the session key K by decrypting the encryption key KC using the unique ID.
  • the processing unit 12 compares the key ID in the storage unit 13 with the newly acquired key ID. When the processing unit 12 confirms that the key ID in the storage unit 13 is different from the newly acquired key ID, the processing unit 12 stores the newly acquired endpoint information of the server, the session key K and the key ID in the storage unit 13. .
  • the processing unit 12 transmits a message requesting retransmission of the session key K to the relay device 101 via the communication unit 11. do.
  • the relay device 101 When receiving the message, the relay device 101 generates a new session key K and transmits it to the server and the client.
  • the relay device 101 waits a sufficient amount of time after distributing a certain session key K to generate a session key that is the same as the session key K. K may be distributed. Therefore, the processing units 12 in the server and the client delete the key ID from the storage unit 13 after a sufficient amount of time has passed since the key ID was stored in the storage unit 13 .
  • the processing unit 12 refers to the service list in the storage unit 13 and acquires the service ID corresponding to the service to be provided.
  • the processing unit 12 also acquires the ECU identifier and the endpoint information of the in-vehicle ECU 111 from the storage unit 13 .
  • the processing unit 12 generates a Find message including the acquired service ID, ECU identifier and endpoint information.
  • the processing unit 12 calculates the MAC value based on the generated Find message and the unique ID in the storage unit 13.
  • the processing unit 12 generates an Ethernet frame in which the Find message and the MAC value are stored in the data field and the multicast address is stored as the destination MAC address.
  • the processing unit 12 outputs the generated Ethernet frame to the communication unit 11 .
  • the communication unit 11 transmits the Ethernet frame received from the processing unit 12 to the relay device 101 .
  • relay unit 22 in relay device 101 receives an Ethernet frame from a server via a corresponding communication port, Add a time stamp and store the Ethernet frame in the storage unit 25 .
  • the processing unit 23 When the Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 confirms that the data field of the Ethernet frame includes the SOME/IP-SD header, and stores the SOME/IP-SD header. , it is determined that the Ethernet frame contains the Find message. Then, the processing unit 23 determines whether the Ethernet frame is appropriate.
  • the processing unit 23 acquires the Find message, MAC value, and time stamp from the Ethernet frame. Also, the processing unit 23 acquires the service ID, the endpoint information of the in-vehicle ECU 111, and the ECU identifier from the acquired Find message. Then, the processing unit 23 refers to the connection destination list in the storage unit 25, and is identified by the endpoint information and the ECU identifier obtained from the Find message as a client that can participate in the service indicated by the service ID obtained from the Find message. It is checked whether the in-vehicle ECU 111 is registered in the connection destination list.
  • the processing unit 23 is involved in the service indicated by the service ID. It is determined that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list as the client to be obtained.
  • the processing unit 23 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Find message. The processing unit 23 calculates the MAC value based on the Find message and the acquired unique ID. Then, the processing unit 23 compares the MAC value obtained from the Ethernet frame with the MAC value calculated by itself to determine whether the Ethernet frame has been tampered with.
  • the relay unit 22 Decide that the Ethernet frame is appropriate.
  • the relay unit 22 Determine that the received Ethernet frame is inappropriate.
  • the processing unit 23 determines that the Ethernet frame is appropriate, it stores the ECU identifier and the endpoint information obtained from the Find message in the storage unit 25 as client information.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate, it deletes the ECU identifier and the endpoint information from the Find message included in the Ethernet frame in the storage unit 25 . Then, the processing unit 23 outputs to the relay unit 22 a relay instruction indicating that the Ethernet frame should be relayed.
  • the relay unit 22 Upon receiving a relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing for the Ethernet frame.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs to the relay unit 22 a discard instruction indicating that the Ethernet frame should be discarded.
  • the relay unit 22 Upon receiving a discard instruction from the processing unit 23, the relay unit 22 discards the Ethernet frame indicated by the discard instruction.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs a Find message and a time stamp to the log generation unit 24 .
  • the log generation unit 24 receives the Find message and the time stamp from the processing unit 23, acquires the ECU identifier included in the received Find message, and uses the byte string of the Find message, the acquired ECU identifier, and the reception time as an unauthorized log. It is written to the fraud log list R1 in the storage unit 25.
  • processing unit 12 receives an Ethernet frame from relay device 101 via communication unit 11, and transmits the received Ethernet frame. Get the source MAC address and Find message from. Also, the processing unit 12 acquires the service ID from the acquired Find message.
  • the processing unit 12 refers to the service list in the storage unit 13 and determines whether the service indicated by the acquired service ID can be provided. If the processing unit 12 determines that the service can be provided, the processing unit 12 acquires the ECU identifier and the endpoint information of the in-vehicle ECU 111 from the storage unit 13, and stores the service ID corresponding to the service, the acquired ECU identifier, and the acquired ECU identifier. Generate an Offer message that includes the endpoint information provided. On the other hand, when the processing unit 12 determines that the service cannot be provided, it does not generate an Offer message.
  • the processing unit 12 calculates the MAC value based on the generated Offer message and the unique ID in the storage unit 13.
  • the processing unit 12 generates an Ethernet frame in which the Offer message and the MAC value are stored in the data field, and the MAC address of the client that sent the Find message is stored as the destination MAC address.
  • the processing unit 12 outputs the generated Ethernet frame to the communication unit 11 .
  • the communication unit 11 transmits the Ethernet frame received from the processing unit 12 to the relay device 101 .
  • relay unit 22 in relay device 101 receives an Ethernet frame from a server via a corresponding communication port, Add a time stamp and store the Ethernet frame in the storage unit 25 .
  • the processing unit 23 determines whether the Ethernet frame received by the relay unit 22 is appropriate in the same manner as in "(1-2) Determining whether the Offer message is appropriate by the relay apparatus". When the processing unit 23 determines that the Ethernet frame is appropriate, the processing unit 23 stores the server information in the storage unit 25 and outputs a relay instruction to the relay unit 22 .
  • the relay unit 22 Upon receiving a relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing for the Ethernet frame.
  • the processing unit 12 performs , generate an Ethernet frame in which the data field stores the Subscribe message and the MAC value, and in which the MAC address of the server that sent the Offer message is stored as the destination MAC address, and transmits the generated Ethernet frame via the communication unit 11 101.
  • the processing unit 23 determines whether the Ethernet frame received by the relay unit 22 is appropriate in the same manner as in "(1-4) Determining whether the Subscribe message is appropriate by the relay device". Then, when the processing unit 23 determines that the Ethernet frame is appropriate, the processing unit 23 stores the ECU identifier and the endpoint information acquired from the Subscribe message in the storage unit 25 as client information.
  • (2-7) Generation and Distribution of Session Key by Relay Device Processing unit 23 in relay device 101 performs session key generation and distribution between the server and the client in the same manner as in “(1-5) Generation and distribution of session key by relay device” described above.
  • session generates a session key K to be used for the session and a key ID that is the ID of the session key K, and sends the generated session key K and key ID to the server and client participating in the session distribute to
  • the processing unit 12 relays A hash value calculated using the session key K received from the device 101 and its own unique ID is compared with the hash value HVS received from the relay device 101 .
  • the processing unit 12 uses the session key K received from the relay device 101 and its own unique ID in the same manner as in "(1-7) Receipt of session key by the client" described above. and the hash value HVC received from the relay device 101 are compared.
  • the processing unit 12 encrypts a session message containing information to be provided as a service using the session key K in the storage unit 13, and includes the encrypted session message in an Ethernet frame. Then, it transmits to the client via the communication unit 11 and the relay device 101 .
  • the processing unit 12 acquires the session message from the Ethernet frame received from the server via the relay device 101 and the communication unit 11, and decrypts the acquired session message using the session key K in the storage unit 13. , to get information from the decrypted session message.
  • the processing unit 12 in the server multicasts an Offer message periodically or irregularly even after starting a session with a certain client.
  • the processing unit 23 in the relay device 101 receives an Ethernet frame in which the Subscribe message is stored from the other client C2 by the relay unit 22, and If it determines that an Ethernet frame is appropriate, it decides to establish a session between the server S1 and the client C2. That is, the processing unit 23 determines to establish a session between the server S1 and the client C2 after distributing the session key K1 to the server S1 and the client C1, for example.
  • the processing unit 23 generates a session key K2 different from the session key K1 distributed to the server S1 and the client C1 as the session key K to be used for the session between the server S1 and the client C2. Distribute K2 to server S1 and client C2.
  • the processing unit 23 generates and distributes a different session key K for each combination of server and client.
  • the server is not limited to unicast session messages to the client.
  • the server may be configured to multicast session messages to multiple clients.
  • the processing unit 23 in the relay device 101 may select the in-vehicle ECU 111 as the transmission source of the Ethernet frame determined to include a start request such as an Offer message and the transmission source of the Ethernet frame determined to include a start response such as a Subscribe message. is generated for each session. More specifically, when the number of clients communicating in a session with one server reaches a predetermined number, the processing unit 23 sets the session key KM which is the session key K used for the session between the server and a plurality of clients. and distributes the generated session key KM to the server and the plurality of clients.
  • the processing unit 23 determines to establish a session between the server S1 and the client C3 in a state in which two sessions between the server S1 and the clients C1 and C2 are respectively established, the server S1 and the client C3 A session key K3 used for a session between the clients C3 is generated and distributed to the server S1 and the client C3. Furthermore, the processing unit 23 further generates a session key KM used for a session between the server S1 and the clients C1, C2, C3 and a multicast address based on the endpoint information of the server S1 and the clients C1, C2, C3. The session key KM and the multicast address are distributed to the server S1 and the clients C1, C2 and C3.
  • the server S1 and the clients C1, C2, and C3 After obtaining the session key KM and the multicast address, the server S1 and the clients C1, C2, and C3 start a communication session using the session key KM and the multicast address.
  • FIG. 10 is a diagram showing an example of a session between a server and a client in the vehicle-mounted system according to the first embodiment of the present disclosure.
  • server S1 has a session key K1 used for a session with client C1, a session key K2 used for a session with client C2, and a session key K2 used for a session with client C3.
  • K3 and a session key KM used for sessions between clients C1, C2, and C3.
  • Client C1 has session keys K1 and KM.
  • Client C2 has session keys K2 and KM.
  • Client C3 has session keys K3 and KM.
  • the processing unit 12 encrypts a session message containing information to be provided as a service using the session key KM, includes the encrypted session message in an Ethernet frame, and sends it to the clients C1, C2, and C3. Multicast.
  • server S1 when server S1 detects an abnormality in in-vehicle system 301 while transmitting information to clients C1, C2, and C3 by multicast, server S1 transmits information to a plurality of clients C1, C2, and C3 by unicast. switch to state.
  • an unauthorized device that hijacks client C1 impersonates server S1 includes a session message encrypted using session key KM in an Ethernet frame, and multicasts it to server S1 and clients C2 and C3.
  • the processing unit 12 in the server S1 receives the session message from the unauthorized device via the communication unit 11, the processing unit 12 receives the session message even though the processing unit 12 is the source of the session message. It is determined that an abnormality has occurred in
  • the processing unit 12 in the server S1 switches transmission of the session message from multicast to unicast. Specifically, the processing unit 12 unicasts a session message encrypted using the session key K1 to the client C1 via the communication unit 11, and transmits a session message encrypted using the session key K2 to the client C1 via the communication unit 11. , and the session message encrypted using the session key K3 is unicast to the client C3 via the communication unit 11 .
  • the processing unit 12 calculates the MAC value based on the generated StopSubscribe message and the unique ID in the storage unit 13. Also, the processing unit 12 encrypts the StopSubscribe message using the session key K in the storage unit 13 . Then, the processing unit 12 generates an Ethernet frame in which the encrypted StopSubscribe message and the MAC value are stored in the data field, and the MAC address of the server is stored as the destination MAC address. It transmits to the relay apparatus 101 via.
  • the processing unit 12 discards the session key K and the endpoint information of the server in the storage unit 13 .
  • the processing unit 23 When the Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 confirms that the data field of the Ethernet frame includes the SOME/IP-SD header, and stores the SOME/IP-SD header. , it is determined that the Ethernet frame contains the StopSubscribe message. Then, the processing unit 23 determines whether the Ethernet frame is appropriate.
  • the processing unit 23 acquires the StopSubscribe message, MAC value, and time stamp from the Ethernet frame. Also, the processing unit 23 acquires the service ID, the endpoint information of the in-vehicle ECU 111, and the ECU identifier from the acquired StopSubscribe message. Then, the processing unit 23 refers to the connection destination list in the storage unit 25 and identifies a server that can participate in the service indicated by the service ID obtained from the StopSubscribe message by the endpoint information and the ECU identifier obtained from the StopSubscribe message. It is checked whether the in-vehicle ECU 111 is registered in the connection destination list.
  • the processing unit 23 also refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the StopSubscribe message.
  • the processing unit 23 calculates a MAC value based on the StopSubscribe message and the acquired unique ID. Then, the processing unit 23 compares the MAC value obtained from the Ethernet frame with the MAC value calculated by itself to determine whether the Ethernet frame has been tampered with.
  • the processing unit 23 determines that the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the StopSubscribe message is registered in the connection destination list and that the Ethernet frame has not been tampered with, the Ethernet frame received by the relay unit 22 Decide that the Ethernet frame is appropriate. On the other hand, when the processing unit 23 determines that the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the StopSubscribe message is not registered in the connection destination list, or determines that the Ethernet frame has been tampered with, the relay unit 22 Determine that the received Ethernet frame is inappropriate.
  • the processing unit 23 determines that the Ethernet frame is appropriate, the processing unit 23 discards the session key K and key ID corresponding to the service ID included in the StopSubscribe message in the storage unit 25 .
  • the processing unit 23 determines that the Ethernet frame is appropriate, the processing unit 23 notifies the log generation unit 24 of the reception time te indicated by the time stamp acquired from the Ethernet frame.
  • the log generation unit 24 records the reception time of the StopSubscribe message by the relay unit 22 as session information. More specifically, the log generation unit 24 receives notification of the reception time te from the processing unit 23, and writes the notified reception time te in the session log list R2 as the "end time" of the session log.
  • the relay unit 22 performs a relay process for an Ethernet frame determined by the processing unit 23 to contain a StopSubscribe message and determined to be appropriate by the processing unit 23 .
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate, the processing unit 23 deletes the ECU identifier and the endpoint information from the StopSubscribe message included in the Ethernet frame in the storage unit 25. Then, the processing unit 23 outputs to the relay unit 22 a relay instruction indicating that the Ethernet frame should be relayed.
  • the relay unit 22 Upon receiving a relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing for the Ethernet frame.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs to the relay unit 22 a discard instruction indicating that the Ethernet frame should be discarded.
  • the relay unit 22 Upon receiving a discard instruction from the processing unit 23, the relay unit 22 discards the Ethernet frame indicated by the discard instruction.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs a StopSubscribe message and a time stamp to the log generation unit 24 .
  • the log generating unit 24 receives the StopSubscribe message and the time stamp, acquires the ECU identifier included in the received StopSubscribe message, and uses the byte string of the StopSubscribe message, the acquired ECU identifier, and the reception time as an illegality log in the storage unit 25. Write to log list R1.
  • the processing unit 12 receives an Ethernet frame from the relay device 101 via the communication unit 11, and transmits a StopSubscribe message from the received Ethernet frame. get.
  • the processing unit 12 decrypts the acquired StopSubscribe message using the session key K in the storage unit 13 .
  • the processing unit 12 discards the session key K and the endpoint information of the client in the storage unit 13 .
  • the processing unit 12 calculates the MAC value based on the generated StopOffer message and the unique ID in the storage unit 13. Also, the processing unit 12 encrypts the StopOffer message using the session key K in the storage unit 13 . Then, the processing unit 12 generates an Ethernet frame in which the encrypted StopOffer message and the MAC value are stored in the data field, and the MAC address of the client is stored as the destination MAC address. It transmits to the relay apparatus 101 via.
  • processing unit 12 discards the session key K and the endpoint information of the client in the storage unit 13.
  • relay unit 22 in relay device 101 receives an Ethernet frame from a server via a corresponding communication port, Add a time stamp and store the Ethernet frame in the storage unit 25 .
  • the processing unit 23 When the Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 confirms that the data field of the Ethernet frame includes the SOME/IP-SD header, and stores the SOME/IP-SD header. , it is determined that the Ethernet frame contains a StopOffer message. Then, the processing unit 23 determines whether the Ethernet frame is appropriate.
  • the processing unit 23 acquires the StopOffer message, MAC value and time stamp from the Ethernet frame. Further, the processing unit 23 acquires the service ID, the endpoint information of the in-vehicle ECU 111, and the ECU identifier from the acquired StopOffer message. Then, the processing unit 23 refers to the connection destination list in the storage unit 25, and is identified by the endpoint information and the ECU identifier obtained from the StopOffer message as a client that can participate in the service indicated by the service ID obtained from the StopOffer message. It is checked whether the in-vehicle ECU 111 is registered in the connection destination list.
  • the processing unit 23 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the StopOffer message. The processing unit 23 calculates the MAC value based on the StopOffer message and the acquired unique ID. Then, the processing unit 23 compares the MAC value obtained from the Ethernet frame with the MAC value calculated by itself to determine whether the Ethernet frame has been tampered with.
  • the relay unit 22 Decide that the Ethernet frame is appropriate. On the other hand, if the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the StopOffer message is not registered in the connection destination list, or if the processing unit 23 determines that the Ethernet frame has been tampered with, the relay unit 22 Determine that the received Ethernet frame is inappropriate.
  • the processing unit 23 determines that the Ethernet frame is appropriate, it discards the session key K and key ID corresponding to the service ID included in the StopOffer message in the storage unit 25 .
  • the processing unit 23 determines that the Ethernet frame is appropriate, the processing unit 23 notifies the log generation unit 24 of the reception time te indicated by the time stamp acquired from the Ethernet frame.
  • the log generation unit 24 records the reception time of the StopOffer message by the relay unit 22 as session information. More specifically, the log generation unit 24 receives notification of the reception time te from the processing unit 23, and writes the notified reception time te in the session log list R2 as the "end time" of the session log.
  • the relay unit 22 performs a relay process for an Ethernet frame that the processing unit 23 determines to include a StopOffer message and that the processing unit 23 determines to be appropriate.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate, it deletes the ECU identifier and the endpoint information from the StopOffer message included in the Ethernet frame in the storage unit 25. Then, the processing unit 23 outputs to the relay unit 22 a relay instruction indicating that the Ethernet frame should be relayed.
  • the relay unit 22 Upon receiving a relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing for the Ethernet frame.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs to the relay unit 22 a discard instruction indicating that the Ethernet frame should be discarded.
  • the relay unit 22 Upon receiving a discard instruction from the processing unit 23, the relay unit 22 discards the Ethernet frame indicated by the discard instruction.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, the processing unit 23 outputs a StopOffer message and a time stamp to the log generation unit 24 .
  • the log generation unit 24 receives the StopOffer message and the time stamp, acquires the ECU identifier included in the received StopOffer message, and uses the byte string of the StopOffer message, the acquired ECU identifier, and the reception time as an illegality log in the storage unit 25 . Write to log list R1.
  • the processing unit 12 receives an Ethernet frame from the relay apparatus 101 via the communication unit 11, and receives a StopOffer message from the received Ethernet frame. get.
  • the processing unit 12 decrypts the acquired StopOffer message using the session key K in the storage unit 13 .
  • the processing unit 12 discards the session key K and the endpoint information of the server in the storage unit 13 .
  • Each device in the in-vehicle system includes a computer including a memory, and an arithmetic processing unit such as a CPU in the computer executes a program including part or all of each step of the following flowcharts and sequences. Read from the memory and execute. Programs for these multiple devices can each be installed from the outside. Programs for these devices are distributed in a state stored in recording media or via communication lines.
  • FIG. 11 is a flow chart defining an example of an operation procedure when the relay device according to the first embodiment of the present disclosure distributes the session key.
  • relay device 101 waits for an Ethernet frame from in-vehicle ECU 111 (NO in step S102), and upon receiving the Ethernet frame (YES in step S102), the received Ethernet frame is sent to the SOME/IP- Judge that it contains an SD message. For example, relay device 101 determines whether the received Ethernet frame includes a SOME/IP-SD message (step S104).
  • step S108 when the relay device 101 determines that the received Ethernet frame does not contain the SOME/IP-SD message (NO in step S106), relay processing of the Ethernet frame is performed (step S108).
  • the relay device 101 waits for a new Ethernet frame from the in-vehicle ECU 111 (NO in step S102).
  • the relay apparatus 101 determines whether the received Ethernet frame contains a SOME/IP-SD message (YES in step S106), it determines whether the Ethernet frame is appropriate (step S110).
  • step S112 when the relay device 101 determines that the received Ethernet frame is appropriate (YES in step S112), it performs relay processing and the like for the Ethernet frame (step S114). Details of step S114 will be described later.
  • the relay device 101 waits for a new Ethernet frame from the in-vehicle ECU 111 (NO in step S102).
  • the relay device 101 determines that the received Ethernet frame is inappropriate (NO in step S112), the byte string of the message included in the Ethernet frame, the ECU identifier included in the message, and the Ethernet frame is written in the fraud log list R1 as the fraud log (step S116).
  • the relay device 101 discards the received Ethernet frame (step S118) and waits for a new Ethernet frame from the in-vehicle ECU 111 (NO in step S102).
  • FIG. 12 is a flow chart defining an example of an operation procedure when the relay device according to the first embodiment of the present disclosure distributes the session key.
  • FIG. 12 shows details of step S114 in FIG.
  • relay apparatus 101 determines that the received Ethernet frame includes an Offer message or a Find message (YES in step S202), it stores server information or client information in storage unit 25. More specifically, when relay device 101 determines that the received Ethernet frame includes an Offer message, relay device 101 saves the ECU identifier and endpoint information obtained from the Offer message in storage unit 25 as server information. On the other hand, when relay device 101 determines that the received Ethernet frame includes a Find message, relay device 101 saves the ECU identifier and endpoint information obtained from the Find message in storage unit 25 as client information (step S204).
  • the relay device 101 relays the received Ethernet frame (step S206).
  • step S210 when relay device 101 determines that the received Ethernet frame includes a Subscribe message (NO in step S202 and YES in step S208), storage unit 25 stores the ECU identifier and endpoint information acquired from the Subscribe message as client information. (step S210).
  • the relay device 101 determines to establish a session between the server and the client, and generates a session key K to be used for the session (step S212).
  • the relay device 101 transmits the generated session key K to the client participating in the session. More specifically, the relay device 101 generates a start message MC including the encryption key KC, and transmits an Ethernet frame including the generated start message MC to the client (step S214).
  • the relay device 101 relays the received Ethernet frame. More specifically, the relay device 101 includes the encryption key KS in the Subscribe message included in the received Ethernet frame, and transmits the Ethernet frame to the server (step S216).
  • the relay device 101 stores the service ID of the service provided in the session to be established, the ECU identifiers of the server and the client that are the destinations of the session key K, and the start time of the session, respectively, in the session log. ”, “ECU identifier” and “start time” are written in the session log list R2 (step S218).
  • the relay device 101 determines that the received Ethernet frame includes the StopSubscribe message or the StopOffer message (NO in step S202 and NO in step S208)
  • the relay device 101 sets the reception time te of the Ethernet frame to the "end time" of the session log. is written in the session log list R2 (step S220).
  • the relay device 101 relays the received Ethernet frame (step S222).
  • FIG. 13 is a diagram showing an example of a communication sequence in the vehicle-mounted system according to the first embodiment of the present disclosure.
  • FIG. 13 shows a communication sequence in an in-vehicle system 301 comprising a server S1 and clients C1 and C2.
  • server S1 transmits an Ethernet frame in which an Offer message is stored in the data field and a multicast address is stored as the destination MAC address to relay device 101 (step S302).
  • the relay device 101 determines that the Ethernet frame received from the server S1 contains an Offer message, and determines whether the Ethernet frame is appropriate. Then, the relay device 101 determines that the Ethernet frame is appropriate, and relays the Ethernet frame (step S304).
  • the client C1 obtains an Offer message from the Ethernet frame received from the server S1 via the relay device 101, and determines that the service provided by the server S1 is necessary. The client C1 then transmits to the relay apparatus 101 an Ethernet frame in which the Subscribe message is stored in the data field and the MAC address of the server S1 is stored as the destination MAC address (step S306).
  • the relay device 101 determines that the Ethernet frame received from the client C1 contains a Subscribe message, and determines whether the Ethernet frame is appropriate.
  • Relay device 101 determines that the Ethernet frame is appropriate, determines to establish a session between server S1 and client C1, and generates session key K1 to be used for the session.
  • the relay apparatus 101 stores the service ID of the service provided in the session to be established, the ECU identifiers of the server S1 and the client C1, and the session start time in the session log as "service ID" and "ECU identifier” and “start time” in the session log list R2 (step S308).
  • the relay device 101 includes the session key K1 in the Subscribe message contained in the Ethernet frame received from the client C1, and transmits the Ethernet frame to the server S1 (step S310).
  • the relay device 101 generates a start message MC including the session key K1, and transmits an Ethernet frame including the generated start message MC to the client C1 (step S312).
  • the server S1 for example, periodically generates an Ethernet frame containing a session message encrypted using the session key K1, and transmits the generated Ethernet frame to the client C1 via the relay device 101 (step S314).
  • client C2 obtains an Offer message from the Ethernet frame received from server S1 via relay device 101, and determines that the service provided by server S1 is necessary. The client C2 then transmits to the relay device 101 an Ethernet frame in which the Subscribe message is stored in the data field and the MAC address of the server S1 is stored as the destination MAC address (step S316).
  • the relay device 101 determines that the Ethernet frame received from the client C2 contains a Subscribe message, and determines whether the Ethernet frame is appropriate.
  • Relay apparatus 101 determines that the Ethernet frame is appropriate, determines to establish a session between server S1 and client C2, and generates session key K2 to be used for the session.
  • the relay apparatus 101 also sets the service ID of the service provided in the session to be established, the ECU identifiers of the server S1 and the client C2, and the start time of the session to the "service ID" and "service ID” of the session log, respectively.
  • ECU identifier” and “start time” are written in the session log list R2 (step S318).
  • the relay device 101 includes the session key K2 in the Subscribe message contained in the Ethernet frame received from the client C2, and transmits the Ethernet frame to the server S1 (step S320).
  • the relay device 101 generates a start message MC including the session key K2, and transmits an Ethernet frame including the generated start message MC to the client C2 (step S322).
  • the server S1 for example, periodically generates an Ethernet frame containing a session message encrypted using the session key K1, and transmits the generated Ethernet frame to the client C1 via the relay device 101 (step S324).
  • the server S1 for example, periodically generates an Ethernet frame in which a session message encrypted using the session key K2 is stored, and transmits the generated Ethernet frame to the client C2 via the relay device 101 (step S326).
  • the client C1 transmits to the relay apparatus 101 an Ethernet frame in which the StopSubscribe message is stored in the data field and the MAC address of the server S1 is stored as the destination MAC address (step S328).
  • the relay device 101 determines that the Ethernet frame received from the client C1 contains the StopSubscribe message, and determines whether the Ethernet frame is appropriate. Then, the relay device 101 determines that the Ethernet frame is appropriate, and relays the Ethernet frame. At this time, the relay device 101 also writes the reception time te of the Ethernet frame to the session log list R2 as the "end time" of the session log (step S330).
  • the client C1 discards the session key K1 and the endpoint information of the server S1 in the storage unit 13 (step S332).
  • the server S1 also discards the session key K1 and the endpoint information of the client C1 in the storage unit 13 (step S334).
  • the server S1 continues sending the Ethernet frame in which the session message is stored to the client C2 (step S336).
  • FIG. 14 is a diagram showing another example of the communication sequence in the vehicle-mounted system according to the first embodiment of the present disclosure.
  • FIG. 14 shows a communication sequence in the in-vehicle system 301 comprising servers S2, S3 and client C1.
  • client C1 transmits an Ethernet frame in which a Find message is stored in the data field and a multicast address is stored as the destination MAC address to relay device 101 (step S402).
  • the relay device 101 determines that the Ethernet frame received from the client C1 contains a Find message, and determines whether the Ethernet frame is appropriate. Then, the relay device 101 determines that the Ethernet frame is appropriate, and performs relay processing for the Ethernet frame (step S404).
  • the server S2 transmits to the relay device 101 an Ethernet frame in which the Offer message is stored in the data field and the MAC address of the client C1 is stored as the destination MAC address (step S406).
  • the relay device 101 determines that the Ethernet frame received from the server S2 contains an Offer message, and determines whether the Ethernet frame is appropriate. The relay device 101 determines that the Ethernet frame is appropriate, and performs relay processing for the Ethernet frame (step S408).
  • the client C1 transmits to the relay apparatus 101 an Ethernet frame in which the Subscribe message is stored in the data field and the MAC address of the server S2 is stored as the destination MAC address (step S410).
  • the relay device 101 determines that the Ethernet frame received from the client C1 contains a Subscribe message, and determines whether the Ethernet frame is appropriate.
  • Relay apparatus 101 determines that the Ethernet frame is appropriate, determines to establish a session between server S2 and client C1, and generates session key K3 to be used for the session.
  • the relay apparatus 101 stores the service ID of the service provided in the session to be established, the ECU identifiers of the server S3 and the client C1, and the session start time in the session log as "service ID" and "ECU identifier” and “start time” in the session log list R2 (step S412).
  • the relay device 101 includes the session key K3 in the Subscribe message contained in the Ethernet frame received from the client C1, and transmits the Ethernet frame to the server S2 (step S414).
  • the relay device 101 generates a start message MC including the session key K3, and transmits an Ethernet frame including the generated start message MC to the client C1 (step S416).
  • server S2 periodically generates an Ethernet frame in which a session message encrypted using session key K3 is stored, and transmits the generated Ethernet frame to client C1 via relay device 101 (step S418).
  • the server S2 transmits to the relay device 101 an Ethernet frame in which the StopOffer message is stored in the data field and the MAC address of the client C1 is stored as the destination MAC address (step S420).
  • the relay device 101 determines that the Ethernet frame received from the server S2 contains a StopOffer message, and determines whether the Ethernet frame is appropriate. Then, the relay device 101 determines that the Ethernet frame is appropriate, and relays the Ethernet frame. At this time, the relay device 101 also writes the reception time te of the Ethernet frame to the session log list R2 as the "end time" of the session log (step S422).
  • the server S2 discards the session key K3 and the endpoint information of the client C1 in the storage unit 13 (step S424).
  • the client C1 also discards the session key K3 and the endpoint information of the server S1 in the storage unit 13 (step S426).
  • the server when the server detects an abnormality in the in-vehicle system 301 while transmitting information to a plurality of clients by multicast, although the configuration has been described as switching to a state of transmitting information by unicast, the present invention is not limited to this.
  • the server may be configured not to switch to a state of transmitting information to a plurality of clients by unicast. Further, the server may be configured to transmit information to a plurality of clients by unicast, but not to transmit information by multicast.
  • the relay device 101 and the in-vehicle ECU 111 are configured to be connected without passing through another relay device. not a thing
  • the relay device 101 and the in-vehicle ECU 111 may be configured to be connected via another relay device.
  • the other relay device relays to relay device 101 all Ethernet frames received from in-vehicle ECU 111 connected to the other relay device.
  • the processing unit 23 transmits the session key K encrypted using the unique ID as an encryption key to the in-vehicle ECU 111 having the unique ID. 22, but the configuration is not limited to this.
  • the processing unit 23 may be configured to transmit the unencrypted session key K to the in-vehicle ECU 111 via the relay unit 22 .
  • the processing unit 23 transmits the hash value HV calculated using the unique ID and the session key K to the in-vehicle ECU 111 having the unique ID. 22, but the configuration is not limited to this.
  • the processing unit 23 may be configured not to transmit the hash value HV to the in-vehicle ECU 111 .
  • the relay device 101 is configured to include the log generation unit 24, the configuration is not limited to this.
  • the relay device 101 may be configured without the log generation unit 24 .
  • the log generation unit 24 is configured to write the start time and end time of the session to the session log list R2, but the configuration is limited to this. is not.
  • the log generation unit 24 writes the service ID of the service provided in the session, the ECU identifier of the server participating in the session, and the ECU identifier of the client participating in the session to the session log list R2, while also writing the start time and end time of the session. At least one of the times may not be written in the session log list R2.
  • the processing unit 23 determines that the Ethernet frame received by the relay unit 22 includes the SOME/IP-SD message, the Ethernet frame Although it is described as a configuration for judging suitability, it is not limited to this.
  • the processing unit 23 may be configured not to judge whether the Ethernet frame including the SOME/IP-SD message is appropriate.
  • the processing unit 23 is configured to generate a session key K with random content for each session, but the configuration is not limited to this. .
  • the processing unit 23 may be configured to generate a session key K having regular contents for each session.
  • a technology that can further improve the security of in-vehicle networks is desired. More specifically, in an in-vehicle system that performs service-oriented communication, for example, a technique that can further improve security in an in-vehicle network is desired.
  • the relay unit 22 performs relay processing for transmitting a plurality of Ethernet frames received from the plurality of in-vehicle ECUs 111 to the destination in-vehicle ECU 111. conduct.
  • the processing unit 23 determines that the plurality of Ethernet frames received by the relay unit 22 contain a start request and a start response.
  • the processing unit 23 provides a session key used for a session in which the in-vehicle ECU 111 that is the transmission source of the Ethernet frame determined to include the start request and one or more in-vehicle ECUs 111 that are the transmission source of the Ethernet frame determined to include the start response participate.
  • Generate K for each session.
  • the processing unit 23 transmits the generated session key K to each in-vehicle ECU 111 participating in the session via the relay unit 22 .
  • the relay device 101 determines that the received frame includes a start request and that the received frame includes a start response, and determines whether the frame including the start request is transmitted from the in-vehicle ECU 111 that includes the start response.
  • a session key K to be used for a session in which one or a plurality of in-vehicle ECUs 111 that transmit frames participate is generated for each session and transmitted to each in-vehicle ECU 111, whereby individual session keys K are generated for each session between the in-vehicle ECUs 111. Since the communication can be performed using the same, the security of the communication between the in-vehicle ECUs 111 can be improved.
  • the in-vehicle ECU 111 that is the transmission source of the start request and the in-vehicle ECU 111 that is the transmission source of the start response are authenticated, and then the common key is generated and transmitted, thereby preventing unauthorized devices from participating in the session. can be done. Therefore, security in the in-vehicle network can be further improved.
  • the processing unit 23 when the number of clients communicating with one server in a session reaches a predetermined number, the processing unit 23 generates a session key KM to be used for a session between the server and a plurality of clients, By distributing the generated session key KM to the server and the plurality of clients, the server and the plurality of clients can perform multicast communication using the session key KM. Therefore, it is possible to improve security in an in-vehicle network in which messages are transmitted and received according to SOME/IP.
  • the relay device 101 due to the configuration in which the relay device 101 generates the session key K, compared to the configuration in which a management device other than the relay device 101 receives the start request and the start response and generates the session key K, existing in-vehicle ECU 111 The session key K can be generated in the relay device 101 while exchanging the initiation request and the initiation response according to the specifications.
  • the hardware configuration can be simplified, and the frame including the start request and the start Communication traffic in the in-vehicle network can be reduced because there is no need to transfer the frame including the response from the relay device to the management device.
  • the present embodiment relates to an in-vehicle system 302 in which a session key K is generated by a management device 201 which is a device different from the relay device 101 compared to the in-vehicle system 301 according to the first embodiment. It is the same as the in-vehicle system 301 according to the first embodiment except for the contents described below.
  • FIG. 15 is a diagram showing the configuration of an in-vehicle system according to the second embodiment of the present disclosure.
  • in-vehicle system 302 includes relay device 102 instead of relay device 101 and further includes management device 201 , unlike in-vehicle system 301 .
  • the in-vehicle ECU 111 and the relay device 102 are examples of in-vehicle devices.
  • the vehicle-mounted system 302 is mounted on the vehicle 1 .
  • a management device 201 is used for an in-vehicle system 302 .
  • the relay device 102 is connected to the management device 201 and each in-vehicle ECU 111 via the cable 14 .
  • Management device 201, in-vehicle ECU 111, and relay device 102 constitute an in-vehicle network.
  • the relay device 102 is, for example, a central gateway (CGW), and can communicate with the management device 201 and the in-vehicle ECU 111 .
  • the relay device 102 performs, for example, relay processing for relaying information exchanged between a plurality of in-vehicle ECUs 111 connected to different cables 14 and information exchanged between the in-vehicle ECU 111 and the management device 201 .
  • communication between the in-vehicle ECUs 111 and communication between the management device 201 and the in-vehicle ECUs 111 are assumed to be performed via the relay device 102 unless otherwise specified.
  • an in-vehicle ECU 111 for example, an in-vehicle ECU 111, as a server, periodically or irregularly transmits an Offer message including a service ID corresponding to a service that it can provide to the management device 201.
  • FIG. The Offer message is an example of a session start request.
  • the management device 201 receives an Offer message from the server and determines whether the received Offer message is appropriate. When the management device 201 determines that the received Offer message is inappropriate, the management device 201 discards the Offer message. On the other hand, when the management device 201 determines that the received Offer message is appropriate, the management device 201 multicasts the Offer message to a plurality of in-vehicle ECUs 111 .
  • the in-vehicle ECU 111 that requires the service corresponding to the service ID included in the Offer message sends a Subscribe message indicating a request for the service as a client to the management device.
  • the Subscribe message is an example of a start response to a session start request.
  • the management device 201 When the management device 201 receives a Subscribe message from the client, it determines to establish a session between the server and the client. Then, the management device 201 generates a session key K unique to the session to be used for the session. That is, the management device 201 generates a session key K to be used for each session.
  • the session key K is an example of a common key, and is, for example, a random number with a key length according to the encryption method used. For example, the management device 201 generates a session key K with random content for each session. The management device 201 transmits the generated session key K to the server and client participating in the session.
  • an in-vehicle ECU 111 as a client periodically or irregularly transmits a Find message including a service ID corresponding to a service to be provided to the management device 201 .
  • the Find message is an example of a session search request.
  • the management device 201 receives a Find message from the client and determines whether the received Find message is appropriate. If the management device 201 determines that the received Find message is inappropriate, it discards the Find message. On the other hand, when the management device 201 determines that the received Find message is appropriate, the management device 201 multicasts the Find message to a plurality of in-vehicle ECUs 111 .
  • the in-vehicle ECU 111 that can provide the service corresponding to the service ID included in the Find message sends an Offer message indicating that the service can be provided as a server. to the management device 201 .
  • the Offer message is an example of a start request for a session search request.
  • the management device 201 receives an Offer message from the server and determines whether the received Offer message is appropriate. When the management device 201 determines that the received Offer message is inappropriate, the management device 201 discards the Offer message. On the other hand, when the management device 201 determines that the received Offer message is appropriate, it transmits the Offer message to the client.
  • a client that receives an Offer message from the management device 201 transmits a Subscribe message to the management device 201 .
  • the Subscribe message is an example of a start response to a session start request.
  • the management device 201 When the management device 201 receives a Subscribe message from the client, it determines to establish a session between the server and the client. Then, the management device 201 generates a session key K unique to the session to be used for the session. The management device 201 transmits the generated session key K to the server and client participating in the session.
  • FIG. 16 is a diagram illustrating the configuration of a management device according to the second embodiment of the present disclosure.
  • management device 201 includes a receiver 31 , a transmitter 32 , a processor 33 , a log generator 34 and a storage 35 .
  • the processing unit 33 is an example of a generating unit.
  • the log generation unit 34 is an example of a recording unit.
  • the receiving unit 31, the transmitting unit 32, the processing unit 33, and the log generating unit 34 are realized by processors such as a CPU and a DSP, for example.
  • Storage unit 35 is, for example, a non-volatile memory.
  • the receiving unit 31 receives session start requests and start responses to the session start requests from the plurality of in-vehicle ECUs 111 respectively.
  • the processing unit 33 generates a session key K unique to the session to be used for the session associated with the start request and the start response received by the receiving unit 31 . That is, the processing unit 33 generates a session key K used for a session in which the in-vehicle ECU 111 that is the transmission source of the start request received by the reception unit 31 and the in-vehicle ECU 111 that is the transmission source of the start response received by the reception unit 31 participates. do. For example, the processing unit 33 generates a session key K with random content for each session.
  • the transmission unit 32 transmits the session key K generated by the processing unit 33 to each in-vehicle ECU 111 participating in the session.
  • the log generation unit 34 records session information related to sessions in which the session key K generated by the processing unit 33 is used.
  • the storage unit 35 stores the unique ID of each in-vehicle ECU 111 in the in-vehicle system 302 .
  • the storage unit 35 stores the connection destination list shown in FIG.
  • the processing unit 12 refers to the service list in the storage unit 13 and corresponds to the service that it can provide. Get the service ID. Further, the processing unit 12 acquires the ECU identifier and the endpoint information of its own in-vehicle ECU 111 from the storage unit 13 . The processing unit 12 generates an Offer message including the acquired service ID, ECU identifier, and endpoint information.
  • the processing unit 12 calculates the MAC value based on the generated Offer message and the unique ID in the storage unit 13.
  • the processing unit 12 outputs the generated Offer message and the calculated MAC value to the communication unit 11 .
  • the communication unit 11 receives the Offer message and MAC value from the processing unit 12 and transmits the received Offer message and MAC value to the management device 201 .
  • the reception unit 31 in the management device 201 receives an Offer message and a MAC value from the server.
  • the receiving unit 31 adds a time stamp to the received Offer message, and outputs the Offer message and the MAC value to the processing unit 33 .
  • the processing unit 33 receives the Offer message and the MAC value from the receiving unit 31 and determines whether the received Offer message is appropriate.
  • the processing unit 33 acquires the service ID, the endpoint information of the in-vehicle ECU 111, and the ECU identifier from the Offer message. Then, the processing unit 33 refers to the connection destination list in the storage unit 35, and is identified by the endpoint information and the ECU identifier obtained from the Offer message as a server that can participate in the service indicated by the service ID obtained from the Offer message. It is checked whether the in-vehicle ECU 111 is registered in the connection destination list.
  • the processing unit 33 participates in the service indicated by the service ID.
  • the server to be obtained it is determined that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list.
  • the processing unit 33 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Offer message.
  • the processing unit 33 calculates a MAC value based on the Offer message and the acquired unique ID. Then, the processing unit 33 compares the MAC value received from the receiving unit 31 with the MAC value calculated by itself to determine whether the Offer message has been tampered with.
  • the processing unit 33 determines that the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Offer message is registered in the connection destination list and that the Offer message has not been tampered with, the receiving unit 31 It determines that the Offer message is appropriate. On the other hand, when the processing unit 33 determines that the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Offer message is not registered in the connection destination list, or determines that the Offer message has been tampered with, the receiving unit 31 It determines that the received Offer message is inappropriate.
  • the processing unit 33 determines that the Offer message received by the receiving unit 31 is appropriate, the processing unit 33 stores the ECU identifier and endpoint information obtained from the Offer message in the storage unit 35 as server information. The processing unit 33 also outputs the Offer message to the transmission unit 32 .
  • the transmission unit 32 multicasts the Offer message received from the processing unit 33 to multiple clients.
  • the transmission unit 32 refers to the connection destination list in the storage unit 35 and multicasts the service with the service ID "0x0001" to multiple clients who may need it.
  • the processing unit 33 determines that the Offer message received by the receiving unit 31 is inappropriate, it outputs the Offer message to the log generating unit 34 .
  • the log generation unit 34 records information about messages determined to be inappropriate by the processing unit 33 .
  • the storage unit 35 stores a fraud log that is a list of fraud logs indicating the byte string of the message determined to be inappropriate by the processing unit 33, the ECU identifier of the in-vehicle ECU 111 that sent the message, and the reception time of the message.
  • a list R11 is stored.
  • the fraud log list R11 is a list having the same contents as the fraud log list R1 shown in FIG.
  • the log generation unit 34 receives an Offer message from the processing unit 33, acquires an ECU identifier included in the received Offer message and a time stamp indicating the reception time, and generates a byte string of the Offer message, the acquired ECU identifier and The reception time is written in the fraud log list R11 in the storage unit 35 as the fraud log. After that, the log generation unit 34 discards the Offer message.
  • the processing unit 12 receives the Offer message from the communication unit 11 and acquires the service ID from the received Offer message.
  • the processing unit 12 refers to the service list in the storage unit 13 and determines whether the service indicated by the acquired service ID is necessary.
  • the processing unit 12 determines that the service is necessary, the processing unit 12 outputs a reply instruction to the communication unit 11 .
  • the processing unit 12 determines that the service is unnecessary, it does not output the reply instruction.
  • the communication unit 11 receives the reply instruction from the processing unit 12 and acquires the ECU identifier and the endpoint information of its own in-vehicle ECU 111 from the storage unit 13 . Then, the communication unit 11 generates a subscribe message including the ECU identifier and the endpoint information, and transmits the generated subscribe message to the management device 201 .
  • the processing unit 33 receives the Subscribe message from the receiving unit 31 and acquires the ECU identifier and endpoint information from the received Subscribe message.
  • the processing unit 33 stores the acquired ECU identifier and endpoint information in the storage unit 35 as client information.
  • the processing unit 33 determines to establish a session between the server and client indicated by the server information and client information stored in the storage unit 35, respectively. When determining to establish a session, the processing unit 33 generates a session key K and distributes it to the server and the client.
  • the processing unit 33 does not receive a Subscribe message from the client via the receiving unit 31 within a predetermined time after transmitting an Offer message to the client via the transmitting unit 32, the processing unit 33 requires the service. A message indicating that the client did not exist is sent to the server via the sending unit 32 .
  • the processing unit 33 generates a session key K to be used for the session that has been determined to be established, and a key ID that is the ID of the session key K. and key ID to servers and clients participating in the session.
  • the processing unit 33 encrypts the session key K using the unique ID as an encryption key. Also, for example, the processing unit 33 calculates a hash value HV calculated using the unique ID and the session key K.
  • the processing unit 33 refers to the connection destination list in the storage unit 35, acquires the unique ID of the server indicated by the server information, and encrypts the session key K using the acquired unique ID as an encryption key.
  • an encryption key KS which is an encrypted session key K for the server, is generated.
  • the processing unit 33 includes the encryption key KS and the corresponding key ID in the Subscribe message received from the client, and gives the Subscribe message and the acquired unique ID to a predetermined hash function to calculate the hash value HVS. do.
  • the processing unit 33 may further include information indicating that there is a client requiring the service in the Subscribe message.
  • the processing unit 33 refers to the connection destination list in the storage unit 35, acquires the unique ID of the client indicated by the client information, and encrypts the session key K using the acquired unique ID as an encryption key.
  • An encryption key KC which is an encrypted session key K for the client, is generated.
  • the processing unit 33 generates a start message MC including the endpoint information of the server, the encryption key KC, and the corresponding key ID, and gives the generated start message MC and the acquired unique ID to a predetermined hash function. Calculates the hash value HVC.
  • the processing unit 33 may include information indicating that there is a server capable of providing services in the start message MC.
  • the processing unit 33 outputs the generated start message MC and Subscribe message, and the calculated hash values HVS and HVC to the transmission unit 32 .
  • the transmission unit 32 transmits the Subscribe message received from the processing unit 33 to the server having the unique ID used to encrypt the encryption key KS. Also, the transmitting unit 32 transmits the start message MC to the client having the unique ID used for encrypting the encryption key KC. Further, the transmission unit 32 transmits the hash value HVS to the server and the hash value HVC to the client.
  • the processing unit 33 receives the service ID of the service provided in the session to be established, the ECU identifier of the server that is the destination of the subscribe message, the ECU identifier of the client that is the destination of the start message MC, and the output time of the subscribe message and the start message MC.
  • the session information indicating ts is output to the log generation unit 34 .
  • the output time ts indicates the time at which the session key K is transmitted by the transmitter 32 .
  • the log generation unit 34 records session information related to sessions in which the session key K generated by the processing unit 33 is used.
  • the storage unit 35 stores a session log indicating the service ID of the service provided in the session to be established, the ECU identifiers of the server and the client to which the session key K is distributed, the session start time, and the session end time.
  • session log list R12 which is a list of The session log list R12 is a list having the same contents as the session log list R12 shown in FIG.
  • the log generation unit 34 receives the session information from the processing unit 33, and converts the service ID, ECU identifier, and output time ts included in the received session information into the "service ID”, "ECU identifier”, and " start time” in the session log list R12.
  • communication unit 11 receives the Subscribe message and hash value HVS from management device 201 and outputs them to processing unit 12 .
  • the processing unit 12 combines a hash value calculated using the session key K received by the communication unit 11 from the management device 201 and its own unique ID, and a hash value received by the communication unit 11 from the management device 201. Match with HVS.
  • the processing unit 12 receives the subscribe message and the hash value HVS from the communication unit 11, acquires the unique ID from the storage unit 13, and converts the received subscribe message and the acquired unique ID into a predetermined hash function.
  • a hash value is calculated by giving The processing unit 12 compares the hash value HVS with the hash value calculated by itself to determine whether the Subscribe message has been tampered with.
  • the processing unit 12 determines that the Subscribe message has been tampered with, it discards the Subscribe message. On the other hand, when the processing unit 12 determines that the Subscribe message has not been tampered with, it acquires the client's endpoint information, the encryption key KS, and the key ID from the Subscribe message. Then, the processing unit 12 acquires the session key K by decrypting the encryption key KS using the unique ID.
  • the processing unit 12 compares the key ID in the storage unit 13 with the newly acquired key ID. When the processing unit 12 confirms that the key ID in the storage unit 13 is different from the newly acquired key ID, the processing unit 12 stores the newly acquired endpoint information of the client, the session key K, and the key ID in the storage unit 13. .
  • the processing unit 12 transmits a message requesting retransmission of the session key K to the management device 201 via the communication unit 11. do.
  • the management device 201 When receiving the message, the management device 201 generates a new session key K and transmits it to the server and the client.
  • the management device 201 when the same session key K as the session key K used in the past session is distributed to the server and the client, it is possible to prompt the management device 201 to regenerate the session key K. A reduction in security due to the use of the key K can be avoided.
  • the communication unit 11 receives the start message MC and the hash value HVC from the management device 201 and outputs them to the processing unit 12 .
  • the processing unit 12 combines the hash value HVC received from the management device 201 by the communication unit 11 with the hash value calculated using the session key K from the management device 201 received by the communication unit 11 and its own unique ID. Match with
  • the processing unit 12 receives the start message MC and the hash value HVC from the communication unit 11, acquires the unique ID from the storage unit 13, and converts the received start message MC and the acquired unique ID into a predetermined hash value.
  • a hash value is calculated by giving it to a function.
  • the processing unit 12 compares the hash value HVC with the hash value calculated by itself to determine whether or not the start message MC has been tampered with.
  • the processing unit 12 determines that the start message MC has been tampered with, it discards the start message MC. On the other hand, when the processing unit 12 determines that the start message MC has not been tampered with, it acquires the endpoint information of the server, the encryption key KC and the key ID from the start message MC. Then, the processing unit 12 acquires the session key K by decrypting the encryption key KC using the unique ID.
  • the processing unit 12 compares the key ID in the storage unit 13 with the newly acquired key ID. When the processing unit 12 confirms that the key ID in the storage unit 13 is different from the newly acquired key ID, the processing unit 12 stores the newly acquired endpoint information of the server, the session key K and the key ID in the storage unit 13. .
  • the processing unit 12 transmits a message requesting retransmission of the session key K to the management device 201 via the communication unit 11. do.
  • the management device 201 When receiving the message, the management device 201 generates a new session key K and transmits it to the server and the client.
  • the management device 201 waits for a sufficient amount of time to generate the same session key as the session key K. K may be distributed. Therefore, the processing units 12 in the server and the client delete the key ID from the storage unit 13 after a sufficient amount of time has passed since the key ID was stored in the storage unit 13 .
  • the processing unit 12 calculates the MAC value based on the generated Find message and the unique ID in the storage unit 13.
  • the processing unit 12 outputs the generated Find message and the calculated MAC value to the communication unit 11 .
  • the communication unit 11 receives the Find message and MAC value from the processing unit 12 and transmits the received Find message and MAC value to the management device 201 .
  • the receiving unit 31 in the management device 201 receives the Find message and the MAC value from the client.
  • the receiving unit 31 adds a time stamp to the received Find message and outputs the Find message and MAC value to the processing unit 33 .
  • the processing unit 33 receives the Find message and the MAC value from the receiving unit 31 and determines whether the received Find message is appropriate.
  • the processing unit 33 acquires the service ID, the endpoint information of the in-vehicle ECU 111, and the ECU identifier from the Find message. Then, the processing unit 33 refers to the connection destination list in the storage unit 35, and is identified by the endpoint information and the ECU identifier obtained from the Find message as a client that can participate in the service indicated by the service ID obtained from the Find message. It is checked whether the in-vehicle ECU 111 is registered in the connection destination list.
  • the processing unit 33 is involved in the service indicated by the service ID. It is determined that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list as the client to be obtained.
  • the processing unit 33 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Find message.
  • the processing unit 33 calculates the MAC value based on the Find message and the acquired unique ID. Then, the processing unit 33 compares the MAC value received from the receiving unit 31 with the MAC value calculated by itself to determine whether the Find message has been tampered with.
  • the processing unit 33 determines that the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Find message is registered in the connection destination list and that the Find message has not been tampered with, the receiving unit 31 A Find message is deemed appropriate.
  • the processing unit 33 determines that the in-vehicle ECU 111 specified by the endpoint information or the like acquired from the Find message is not registered in the connection destination list, or determines that the Find message has been tampered with, the receiving unit 31 Determine that the received Find message is inappropriate.
  • the processing unit 33 determines that the Find message received by the receiving unit 31 is appropriate, the processing unit 33 saves the ECU identifier and endpoint information obtained from the Find message in the storage unit 35 as client information. The processing unit 33 also outputs the Find message to the transmission unit 32 .
  • the transmission unit 32 multicasts the Find message received from the processing unit 33 to multiple servers.
  • the transmission unit 32 refers to the connection destination list in the storage unit 35 and multicasts to a plurality of servers that can provide the service with the service ID "0x0001".
  • the processing unit 33 determines that the Find message received by the receiving unit 31 is inappropriate, it outputs the Find message to the log generating unit 34 .
  • the log generation unit 34 receives a Find message from the processing unit 33, acquires an ECU identifier included in the received Find message and a time stamp indicating the reception time, and obtains the byte string of the Find message, the acquired ECU identifier and The reception time is written in the fraud log list R11 in the storage unit 35 as the fraud log. After that, the log generator 34 discards the Find message.
  • the processing unit 12 receives the Find message from the communication unit 11 and acquires the service ID from the received Find message.
  • the processing unit 12 refers to the service list in the storage unit 13 and determines whether the service indicated by the acquired service ID can be provided.
  • the processing unit 12 determines that the service can be provided, the processing unit 12 outputs a reply instruction to the communication unit 11 .
  • the processing unit 12 determines that the service cannot be provided, the processing unit 12 does not output the reply instruction.
  • the communication unit 11 receives the reply instruction from the processing unit 12 and acquires the ECU identifier and the endpoint information of its own in-vehicle ECU 111 from the storage unit 13 .
  • the communication unit 11 then generates an Offer message including the ECU identifier and the endpoint information, and transmits the generated Offer message to the management device 201 .
  • the management device 201 determines the propriety of the Offer message received from the server in the same manner as "(1-2) Judgment of propriety of the Offer message by the management device". to judge. Then, when the management device 201 determines that the Offer message is appropriate, it transmits the Offer message to the client.
  • the management device 201 determines to establish a session in the same manner as in “(1-4) Determination of session establishment by the management device” described above, and sets the session key K generated and distributed to servers and clients.
  • the management device 201 participates in the session with the session key K and the key ID in the same manner as in "(1-5) Distribution of session key by the management device" described above. Distribute to servers and clients.
  • the server and the client acquire the session key K in the same manner as in “(1-5) Distributing the session key by the management device" described above.
  • the processing unit 12 encrypts a session message containing information to be provided as a service using the session key K in the storage unit 13, and sends the encrypted session message to the communication unit 11. Output.
  • the communication unit 11 unicasts the session message received from the processing unit 12 to the client indicated by the endpoint information in the storage unit 13 .
  • the processing unit 12 decrypts the session message received from the server via the communication unit 11 using the session key K in the storage unit 13, and acquires information from the decrypted session message.
  • the processing unit 12 in the server periodically or irregularly transmits an Offer message to the management device 201 via the communication unit 11 even after starting a session with a certain client.
  • the processing unit 33 in the management device 201 receives, via the receiving unit 31, a Subscribe message from another client in response to the Offer message of the server. decide to establish a session between the server and the client.
  • the processing unit 33 receives, via the receiving unit 31, a Subscribe message from the client C2 in response to the Offer message of the server S1. decides to establish a session for
  • the processing unit 33 generates a session key K2 different from the session key K1 distributed to the server S1 and the client C1 as the session key K to be used for the session between the server S1 and the client C2. Distribute K2 to server S1 and client C2.
  • the processing unit 33 generates and distributes a different session key K for each combination of server and client.
  • the server is not limited to unicast session messages to the client.
  • the server may be configured to multicast session messages to multiple clients.
  • the processing unit 33 in the management device 201 uses the session key K to be used for the session between the server and a plurality of clients.
  • a certain session key KM is generated, and the generated session key KM is distributed to the server and the plurality of clients.
  • the processing unit 33 receives, via the receiving unit 31, the Subscribe message from the client C3 in response to the Offer message of the server S1 in a state in which two sessions are respectively established between the server S1 and the clients C1 and C2.
  • a session key K3 used for the session between server S1 and client C3 is generated and distributed to server S1 and client C3.
  • the processing unit 33 further generates a session key KM used for a session between the server S1 and the clients C1, C2, C3 and a multicast address based on the endpoint information of the server S1 and the clients C1, C2, C3.
  • the session key KM and the multicast address are distributed to the server S1 and the clients C1, C2 and C3.
  • the server S1 and the clients C1, C2, and C3 After obtaining the session key KM and the multicast address, the server S1 and the clients C1, C2, and C3 start a communication session using the session key KM and the multicast address.
  • the server S1 stores a session key K1 used for the session with the client C1, a session key K2 used for the session with the client C2, and a session key K2 used for the session with the client C3. It has a key K3 and a session key KM used for sessions between clients C1, C2, and C3.
  • Client C1 has session keys K1 and KM.
  • Client C2 has session keys K2 and KM.
  • Client C3 has session keys K3 and KM.
  • the processing unit 12 encrypts a session message containing information to be provided as a service using the session key KM, and sends the encrypted session message to the clients C1, C2, and C3 via the communication unit 11. Multicast.
  • server S1 when server S1 detects an abnormality in in-vehicle system 302 while transmitting information to clients C1, C2, and C3 by multicast, server S1 transmits information to a plurality of clients C1, C2, and C3 by unicast. switch to state.
  • the processing unit 12 in the server S1 receives the session message from the unauthorized device via the communication unit 11, the processing unit 12 receives the session message even though the processing unit 12 is the source of the session message. It is determined that an abnormality has occurred in
  • the processing unit 12 in the server S1 switches transmission of the session message from multicast to unicast. Specifically, the processing unit 12 unicasts a session message encrypted using the session key K1 to the client C1 via the communication unit 11, and transmits a session message encrypted using the session key K2 to the client C1 via the communication unit 11. , and the session message encrypted using the session key K3 is unicast to the client C3 via the communication unit 11 .
  • the processing unit 12 encrypts a StopSubscribe message including the service ID using the session key K in the storage unit 13 and transmits the message to the management device 201 via the communication unit 11. do. Also, the processing unit 12 discards the session key K and the endpoint information of the server in the storage unit 13 .
  • the reception unit 31 receives the StopSubscribe message from the client.
  • the receiving unit 31 adds a time stamp to the received StopSubscribe message and outputs the message to the processing unit 33 .
  • a StopSubscribe message from a client received by the receiving unit 31 is an example of a termination request.
  • the processing unit 33 receives the StopSubscribe message from the receiving unit 31 and outputs the received StopSubscribe message to the transmitting unit 32 .
  • the processing unit 33 also notifies the log generation unit 34 of the reception time te indicated by the time stamp attached to the StopSubscribe message.
  • the transmitting unit 32 Based on the reception of the Stop Subscribe message by the receiving unit 31, the transmitting unit 32 transmits a Stop Subscribe message for terminating the session to the other in-vehicle ECUs 111 participating in the session, that is, the server. More specifically, the transmission unit 32 transmits the StopSubscribe message received from the processing unit 33 to the server.
  • the StopSubscribe message to the server sent by the sending unit 32 is an example of a termination instruction.
  • the log generation unit 34 receives notification of the reception time te from the processing unit 33, and writes the notified reception time te as the "end time" of the session log to the session log list R12.
  • the processing unit 12 receives the StopSubscribe message from the management device 201 via the communication unit 11 and decrypts the received StopSubscribe message using the session key K in the storage unit 13 .
  • the processing unit 12 discards the session key K and the endpoint information of the client in the storage unit 13 .
  • the processing unit 12 when stopping the provision of the service, the processing unit 12 encrypts a StopOffer message including the service ID using the session key K in the storage unit 13 and transmits the encrypted StopOffer message to the management device 201 via the communication unit 11 . Also, the processing unit 12 discards the session key K and the endpoint information of the client in the storage unit 13 .
  • the reception unit 31 receives the StopOffer message from the client.
  • the receiving unit 31 attaches a time stamp to the received StopOffer message and outputs the received StopOffer message to the processing unit 33 .
  • a StopOffer message from the server received by the receiver 31 is an example of a termination request.
  • the processing unit 33 receives the StopOffer message from the receiving unit 31 and outputs the received StopOffer message to the transmitting unit 32 .
  • the processing unit 33 also notifies the log generation unit 34 of the reception time te indicated by the time stamp attached to the StopOffer message.
  • the transmitting unit 32 Upon receipt of the StopOffer message by the receiving unit 31, the transmitting unit 32 transmits a StopOffer message indicating that the session should be terminated to the other in-vehicle ECUs 111 participating in the session, that is, the client. More specifically, the transmission unit 32 transmits the StopOffer message received from the processing unit 33 to the client.
  • a StopOffer message to the client sent by the sending unit 32 is an example of a termination instruction.
  • the log generation unit 34 receives notification of the reception time te from the processing unit 33, and writes the notified reception time te in the session log list R12 as the "end time" of the session log.
  • the processing unit 12 receives the StopOffer message from the management device 201 via the communication unit 11 and decrypts the received StopOffer message using the session key K in the storage unit 13 .
  • the processing unit 12 discards the session key K and the endpoint information of the server in the storage unit 13 .
  • FIG. 17 is a flowchart defining an example of an operation procedure when the management device according to the second embodiment of the present disclosure distributes session keys.
  • the management device 201 first waits for an Offer message from the server, a Find message from the client, or a Subscribe message from the client (NO in step S502).
  • the management device 201 when the management device 201 receives an Offer message from the server or a Find message from the client (YES in step S502 and YES in step S504), it determines whether the received message is appropriate (step S506).
  • the management device 201 determines that the received message is inappropriate (NO in step S508), the management device 201 acquires the ECU identifier included in the message and the time stamp indicating the reception time, and The byte string, the acquired ECU identifier and the reception time are written as the fraud log in the fraud log list R11 (step S510).
  • the management device 201 discards the message (step S512) and waits for a new message from the server or client (NO in step S502).
  • the management device 201 determines that the received message is appropriate (YES in step S508), it multicasts the message. More specifically, if the message is an Offer message, the management device 201 multicasts the message to a plurality of clients, and if the message is a Find message, multicasts the message to a plurality of servers (step S512). ).
  • the management device 201 when the management device 201 receives a Subscribe message from the client (YES in step S502 and NO in step S504), it determines to establish a session between the server and the client, and the session key K and A key ID is generated (step S516).
  • the management device 201 encrypts the session key K. More specifically, the management device 201 generates an encrypted key KS by encrypting the session key K using the unique ID of the server as an encryption key. The management device 201 also generates an encryption key KC by encrypting the session key K using the client's unique ID as an encryption key (step S518).
  • the management device 201 calculates a hash value (step S520).
  • the management device 201 calculates the hash value HVS by including the encryption key KS in the Subscribe message and giving the Subscribe message and the unique ID of the server to a predetermined hash function.
  • the management device 201 also generates a start message MC including the encryption key KC, and applies the generated start message MC and the unique ID of the client to a predetermined hash function to calculate a hash value HVC.
  • the management device 201 transmits the session key K and hash value. More specifically, the management device 201 transmits a Subscribe message containing the encryption key KS and the hash value HVS to the server, and transmits a start message MC containing the encryption key KC and the hash value HVC to the client (step S522).
  • the management device 201 stores the service ID of the service provided in the session to be established, the ECU identifiers of the server and the client that are the destinations of the session key K, and the start time of the session, respectively, in the session log. , ⁇ ECU identifier'' and ⁇ start time'' in the session log list R12 (step S524).
  • the management device 201 waits for a new Offer message from the server, a new Find message from the client, or a new Subscribe message from the client (NO in step S502).
  • FIG. 18 is a diagram showing an example of a communication sequence in an in-vehicle system according to the second embodiment of the present disclosure.
  • server S1 transmits an Offer message to management device 201 (step S602).
  • the management device 201 determines whether the Offer message received from the server S1 is appropriate (step S604).
  • the management device 201 determines that the Offer message is appropriate, it multicasts the Offer message to the clients C1 and C2 (step S606).
  • the client C1 acquires a service ID from the Offer message received from the management device 201, determines that the service indicated by the acquired service ID is necessary, and transmits a Subscribe message to the management device 201 (step S608).
  • the management device 201 receives the Subscribe message from the client C1, determines to establish a session between the server S1 and the client C1, and generates a session key K1 to be used for the session (step S610). Also, at this time, the management device 201 stores the service ID of the service provided in the session to be established, the ECU identifiers of the server S1 and the client C1, and the session start time in the session log as "service ID” and "ECU identifier” and “start time” in the session log list R12.
  • the management device 201 includes the generated session key K1 in a Subscribe message and distributes it to the server S1 (step S612).
  • the management device 201 also includes the generated session key K1 in the start message MC and distributes it to the client C1 (step S614).
  • the server S1 for example, periodically unicasts a session message encrypted using the session key K1 to the client C1 (step S616).
  • client C2 acquires a service ID from the Offer message received from management device 201, determines that the service indicated by the acquired service ID is necessary, and transmits a Subscribe message to management device 201 (step S618).
  • the management device 201 receives the Subscribe message from the client C2, determines to establish a session between the server S1 and the client C2, and generates a session key K2 to be used for the session (step S620). At this time, the management device 201 also sets the service ID of the service provided in the session to be established, the ECU identifiers of the server S1 and the client C2, and the session start time to the session log "service ID", " ECU identifier” and “start time” are written in the session log list R12.
  • the management device 201 includes the generated session key K2 in a Subscribe message and distributes it to the server S1 (step S622).
  • the management device 201 also includes the generated session key K2 in the start message MC and distributes it to the client C2 (step S624).
  • the server S1 for example, periodically unicasts a session message encrypted using the session key K1 to the client C1 (step S626).
  • the server S1 periodically unicasts a session message encrypted using the session key K2 to the client C2 (step S628).
  • client C1 transmits a StopSubscribe message to management device 201 in order to stop receiving the service (step S630).
  • the management device 201 receives the StopSubscribe message from the client C1 and transmits the StopSubscribe message to the server S1 (step S632). At this time, the management device 201 also writes the end time of the session into the session log list R12 as the "end time" of the session log.
  • the client C1 discards the session key K1 and the endpoint information of the server S1 in the storage unit 13 (step S634).
  • the server S1 also discards the session key K1 and the endpoint information of the client C1 in the storage unit 13 (step S636).
  • the server S1 continues unicasting the session message to the client C2 (step S638).
  • FIG. 19 is a diagram showing another example of the communication sequence in the vehicle-mounted system according to the second embodiment of the present disclosure.
  • client C1 first transmits a Find message to management device 201 (step S702).
  • the management device 201 determines whether the Find message received from the client C1 is appropriate (step S704).
  • the management device 201 determines that the Find message is appropriate, it multicasts the Find message to the servers S1 and S2 (step S706).
  • the server S1 acquires the service ID from the Find message received from the management apparatus 201, determines that the service indicated by the acquired service ID can be provided, and transmits an Offer message to the management apparatus 201. (Step S708).
  • the management device 201 determines whether the Offer message received from the server S1 is appropriate (step S710).
  • the management device 201 determines that the Offer message is appropriate, it transmits the Offer message to the client C1 (step S712).
  • the client C1 receives an Offer message from the management device 201 and transmits a Subscribe message to the management device 201 (step S714).
  • the management device 201 receives the Subscribe message from the client C1, determines to establish a session between the server S1 and the client C1, and generates a session key K3 to be used for the session (step S716). At this time, the management device 201 also sets the service ID of the service provided in the session to be established, the ECU identifiers of the server S1 and the client C1, and the start time of the session to the "service ID" and "service ID” of the session log, respectively. ECU identifier” and “start time” are written in the session log list R12.
  • the management device 201 includes the generated session key K1 in the start message MC and distributes it to the client C1 (step S718).
  • the management device 201 includes the generated session key K3 in the Subscribe message and distributes it to the server S1 (step S720).
  • the server S1 periodically unicasts a session message encrypted using the session key K3 to the client C1 (step S722).
  • the server S1 transmits a StopOffer message to the management device 201 to stop providing the service (step S724).
  • the management device 201 receives the StopOffer message from the server S1 and transmits the StopOffer message to the client C1 (step S726). At this time, the management device 201 also writes the end time of the session into the session log list R12 as the "end time" of the session log.
  • the server S1 discards the session key K3 and the endpoint information of the client C1 in the storage unit 13 (step S728).
  • the client C1 also discards the session key K3 and the endpoint information of the server S1 in the storage unit 13 (step S730).
  • the client C1 may transmit a StopSubscribe message to the management device 201 instead of the server S1 transmitting the StopOffer message to the management device 201 in step S724 in FIG. 18, the server S1 may transmit a StopOffer message to the management apparatus 201 instead of the client C1 transmitting the StopSubscribe message to the management apparatus 201 in step S630 of FIG. In this case, the management device 201 transmits a StopOffer message to the clients C1 and C2.
  • the server when the server detects an abnormality in the in-vehicle system 302 while transmitting information to a plurality of clients by multicast, although the configuration has been described as switching to a state of transmitting information by unicast, the present invention is not limited to this.
  • the server may be configured not to switch to a state of transmitting information to a plurality of clients by unicast. Further, the server may be configured to transmit information to a plurality of clients by unicast, but not to transmit information by multicast.
  • the processing unit 33 is configured to output to the transmission unit 32 a Subscribe message including the encryption key KS and a start message MC including the encryption key KC.
  • the processing unit 33 may be configured to output a Subscribe message and a start message MC including the unencrypted session key K to the transmitting unit 32 .
  • the transmission unit 32 transmits the Subscribe to the server and the start message MC to the client.
  • the transmission unit 32 is configured to transmit the hash value HVS to the server and the hash value HVC to the client. not something to do.
  • the transmission unit 32 may be configured not to transmit the hash value HVS while transmitting the Subscribe message to the server. Further, the transmission unit 32 may be configured to transmit the start message MC to the client but not to transmit the hash value HVC.
  • the receiving unit 31 is configured to receive a StopSubscribe message from the client and a StopOffer message from the server, but the present invention is limited to this. is not.
  • the receiving unit 31 may be configured not to receive the StopSubscribe message and the StopOffer message.
  • the client transmits the StopSubscribe message to the server instead of transmitting the StopSubscribe message to the management device 201 .
  • the server sends the StopOffer message to the client.
  • management device 201 is configured to include the log generation unit 34, the configuration is not limited to this.
  • the management device 201 may be configured without the log generation unit 34 .
  • the log generation unit 34 is configured to write the start time and end time of the session in the session log list R12, but the configuration is limited to this. is not.
  • the log generation unit 34 writes the service ID of the service provided in the session, the ECU identifier of the server that is the destination of the Subscribe message, and the ECU identifier of the client that is the destination of the start message MC in the session log list R12. may be configured such that the start time and end time of the session are not written in the session log list R12.
  • the processing unit 33 is configured to generate a session key K with random content for each session, but is not limited to this.
  • the processing unit 33 may be configured to generate a session key K having regular contents for each session.
  • the processing unit 33 further determines whether the Subscribe message is appropriate, similar to the processing unit 23 in the relay device 101 according to the first embodiment. It may be configured to further determine whether the StopSubscribe message is appropriate, or may be configured to further determine whether the StopOffer message is appropriate.
  • a technology that can further improve the security of in-vehicle networks is desired. More specifically, in an in-vehicle system that performs service-oriented communication, for example, a technique that can further improve security in an in-vehicle network is desired.
  • the reception unit 31 receives the Offer message from the server. Also, the receiving unit 31 receives a Subscribe message from the client.
  • the processing unit 33 generates a session key K unique to the session to be used for the session associated with the Offer message and Subscribe message received by the receiving unit 31 .
  • the transmission unit 32 transmits the session key generated by the processing unit 33 to the server and client participating in the session.
  • an Offer message is received from the server, a Subscribe message is received from the client, and a session key K unique to the session is generated and transmitted to the server and client. Since communication using the session key K can be performed, the security of communication between the server and the client can be improved. Also, for example, by authenticating the server that sent the Offer message and the client that sent the Find message, it is possible to detect Offer messages and Find messages from unauthorized devices. Therefore, security in the in-vehicle network can be further improved.
  • the processing unit 33 when the number of clients communicating with one server in a session reaches a predetermined number, the processing unit 33 generates a session key KM to be used for a session between the server and a plurality of clients, By distributing the generated session key KM to the server and the plurality of clients, the server and the plurality of clients can perform multicast communication using the session key KM. Therefore, it is possible to improve security in an in-vehicle network in which messages are transmitted and received according to SOME/IP.
  • [Appendix 1] a relay unit that performs a relay process of transmitting a plurality of frames received from a plurality of in-vehicle devices respectively to a destination in-vehicle device; a determination unit that determines that the plurality of frames include a session start request for communication between the plurality of in-vehicle devices and a start response to the start request; The in-vehicle device as a transmission source of the frame determined by the determination unit to include the start request, and one or more of the in-vehicle devices as a transmission source of the frame determined by the determination unit to include the start response.
  • the relay unit receives the first frame including a service ID, endpoint information of the in-vehicle device that has transmitted the start request, and an ECU identifier of the in-vehicle device that has transmitted the start request, The generation unit determines suitability of the first frame based on the service ID, the endpoint information, and the ECU identifier, The relay unit receives the second frame including a service ID, endpoint information of the in-vehicle device as a transmission source of the start response, and an ECU identifier of the in-vehicle device as a transmission source of the start response, The in-vehicle relay device, wherein the generator determines whether the second frame is appropriate based on the service ID, the endpoint information, and the ECU identifier.
  • the in-vehicle relay device is used for the session in which the first in-vehicle device as a transmission source of the received first frame and the second in-vehicle device as a transmission source of the received second frame participate.
  • the in-vehicle relay device determines suitability of the first frame based on the service ID, the endpoint information, and the ECU identifier;
  • said second in-vehicle device transmitting said second frame including a service ID, endpoint information of said second in-vehicle device, and an ECU identifier of said second in-vehicle device to said in-vehicle relay device;
  • the in-vehicle system wherein the in-vehicle relay device determines whether the second frame is appropriate based on the service ID, the endpoint information, and the ECU identifier.
  • a management device used in an in-vehicle system comprising a plurality of in-vehicle devices, a receiving unit that receives from the in-vehicle device a session start request for communication between the plurality of in-vehicle devices that are part or all of the plurality of in-vehicle devices; a generation unit that generates a common key unique to the session, which is used for the session associated with the start request; a transmission unit that transmits the common key to each of the in-vehicle devices participating in the session; The receiving unit receives the start request including a service ID, endpoint information of the in-vehicle device that transmitted the start request, and an ECU identifier of the in-vehicle device that transmitted the start request, The management device, wherein the generation unit determines whether the start request is appropriate based on the service ID, the endpoint information, and the ECU identifier.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Mechanical Engineering (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Small-Scale Networks (AREA)

Abstract

車載中継装置は、複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う中継部と、前記複数のフレームが、前記複数の車載装置間の通信のセッションの開始要求を含むこと、および前記開始要求に対する開始応答を含むことを判断する判断部と、前記判断部により前記開始要求を含むと判断された前記フレームの送信元の前記車載装置と、前記判断部により前記開始応答を含むと判断された前記フレームの送信元の１または複数の前記車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成する生成部と、前記共通鍵を、前記セッションに参加する前記各車載装置へ前記中継部経由で送信する送信部とを備える。

Description

車載中継装置、管理装置、車載システムおよび通信管理方法
　本開示は、車載中継装置、管理装置、車載システムおよび通信管理方法に関する。
　この出願は、２０２１年３月１２日に出願された日本出願特願２０２１－３９７９４号および２０２１年８月２０日に出願された日本出願特願２０２１－１３４４７９号を基礎とする優先権を主張し、その開示のすべてをここに取り込む。
　特許文献１（特開２０１８－２６７９１号公報）には、以下のようなフレーム伝送阻止装置が開示されている。すなわち、フレーム伝送阻止装置は、複数の電子制御ユニットがバスを介して通信するネットワークシステムにおける当該バスに接続されるフレーム伝送阻止装置であって、前記バスからフレームを受信する受信部と、フレームの伝送の阻止を許容するか否かを示す管理情報に基づいて、前記受信部により受信されたフレームが所定条件を満たす場合に当該フレームの伝送を阻止する所定処理を実行するか否かを切り替える処理部とを備える。
特開２０１８－２６７９１号公報
　本開示の車載中継装置は、複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う中継部と、前記複数のフレームが、前記複数の車載装置間の通信のセッションの開始要求を含むこと、および前記開始要求に対する開始応答を含むことを判断する判断部と、前記判断部により前記開始要求を含むと判断された前記フレームの送信元の前記車載装置と、前記判断部により前記開始応答を含むと判断された前記フレームの送信元の１または複数の前記車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成する生成部と、前記共通鍵を、前記セッションに参加する前記各車載装置へ前記中継部経由で送信する送信部とを備える。
　本開示の管理装置は、複数の車載装置を備える車載システムに用いられる管理装置であって、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求、および前記開始要求に対する開始応答を、複数の前記車載装置からそれぞれ受信する受信部と、前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成する生成部と、前記共通鍵を前記セッションに参加する前記各車載装置へ送信する送信部とを備える。
　本開示の車載システムは、第１の車載装置および第２の車載装置を含む複数の車載装置と、車載中継装置とを備え、前記車載中継装置は、前記複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行い、前記第１の車載装置は、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を含む第１のフレームを前記車載中継装置へ送信し、前記第２の車載装置は、前記開始要求に対する開始応答を含む第２のフレームを前記車載中継装置へ送信し、前記車載中継装置は、受信した前記第１のフレームの送信元の前記第１の車載装置と、受信した前記第２のフレームの送信元の前記第２の車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信する。
　本開示の車載システムは、第１の車載装置および第２の車載装置を含む複数の車載装置と、管理装置とを備え、前記第１の車載装置は、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を前記管理装置へ送信し、前記第２の車載装置は、前記開始要求に対する開始応答を前記管理装置へ送信し、前記管理装置は、受信した前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信する。
　本開示の通信管理方法は、複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う車載中継装置における通信管理方法であって、前記複数のフレームが、前記複数の車載装置間の通信のセッションの開始要求を含むこと、および前記開始要求に対する開始応答を含むことを判断するステップと、前記開始要求を含むと判断した前記フレームの送信元の前記車載装置と、前記開始応答を含むと判断した前記フレームの送信元の１または複数の前記車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成するステップと、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む。
　本開示の通信管理方法は、複数の車載装置を備える車載システムに用いられる管理装置における通信管理方法であって、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求、および前記開始要求に対する開始応答を、複数の前記車載装置からそれぞれ受信するステップと、受信した前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成するステップと、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む。
　本開示の通信管理方法は、第１の車載装置および第２の車載装置を含む複数の車載装置と、前記複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う車載中継装置とを備える車載システムにおける通信管理方法であって、前記第１の車載装置が、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を含む第１のフレームを前記車載中継装置へ送信するステップと、前記第２の車載装置が、前記開始要求に対する開始応答を含む第２のフレームを前記車載中継装置へ送信するステップと、前記車載中継装置が、受信した前記第１のフレームの送信元の前記第１の車載装置と、受信した前記第２のフレームの送信元の前記第２の車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む。
　本開示の通信管理方法は、第１の車載装置および第２の車載装置を含む複数の車載装置と、管理装置とを備える車載システムにおける通信管理方法であって、前記第１の車載装置が、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を前記管理装置へ送信するステップと、前記第２の車載装置が、前記開始要求に対する開始応答を前記管理装置へ送信するステップと、前記管理装置が、受信した前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む。
　本開示の一態様は、このような特徴的な処理部を備える車載中継装置として実現され得るだけでなく、車載中継装置の一部または全部を実現する半導体集積回路として実現され得たり、車載中継装置における処理のステップをコンピュータに実行させるためのプログラムとして実現され得たり、車載中継装置を備える車載システムの一部または全部を実現する半導体集積回路として実現され得たり、車載システムにおける処理のステップをコンピュータに実行させるためのプログラムとして実現され得る。
　本開示の一態様は、このような特徴的な処理部を備える管理装置として実現され得るだけでなく、管理装置の一部または全部を実現する半導体集積回路として実現され得たり、管理装置における処理のステップをコンピュータに実行させるためのプログラムとして実現され得たり、管理装置を備える車載システムの一部または全部を実現する半導体集積回路として実現され得たり、車載システムにおける処理のステップをコンピュータに実行させるためのプログラムとして実現され得る。
図１は、本開示の第１の実施の形態に係る車載システムの構成を示す図である。 図２は、本開示の第１の実施の形態に係る車載システムにおいて送受信されるイーサネットフレームの一例を示す図である。 図３は、本開示の第１の実施の形態に係る車載システムにおいて送受信されるＳＯＭＥ／ＩＰ－ＳＤメッセージの一例を示す図である。 図４は、本開示の第１の実施の形態に係る車載システムにおいて送受信されるＳＯＭＥ／ＩＰメッセージの一例を示す図である。 図５は、本開示の第１の実施の形態に係る車載ＥＣＵの構成を示す図である。 図６は、本開示の第１の実施の形態に係る中継装置の構成を示す図である。 図７は、本開示の第１の実施の形態に係る中継装置における記憶部が記憶する接続先リストの一例を示す図である。 図８は、本開示の第１の実施の形態に係る中継装置における記憶部における不正ログリストの一例を示す図である。 図９は、本開示の第１の実施の形態に係る中継装置における記憶部におけるセッションログリストの一例を示す図である。 図１０は、本開示の第１の実施の形態に係る車載システムにおけるサーバおよびクライアント間のセッションの一例を示す図である。 図１１は、本開示の第１の実施の形態に係る中継装置がセッション鍵を配布する際の動作手順の一例を定めたフローチャートである。 図１２は、本開示の第１の実施の形態に係る中継装置がセッション鍵を配布する際の動作手順の一例を定めたフローチャートである。 図１３は、本開示の第１の実施の形態に係る車載システムにおける通信のシーケンスの一例を示す図である。 図１４は、本開示の第１の実施の形態に係る車載システムにおける通信のシーケンスの他の例を示す図である。 図１５は、本開示の第２の実施の形態に係る車載システムの構成を示す図である。 図１６は、本開示の第２の実施の形態に係る管理装置の構成を示す図である。 図１７は、本開示の第２の実施の形態に係る管理装置がセッション鍵を配布する際の動作手順の一例を定めたフローチャートである。 図１８は、本開示の第２の実施の形態に係る車載システムにおける通信のシーケンスの一例を示す図である。 図１９は、本開示の第２の実施の形態に係る車載システムにおける通信のシーケンスの他の例を示す図である。
　従来、車載ネットワークにおけるセキュリティを向上させるための技術が開発されている。
　［本開示が解決しようとする課題］
　特許文献１に記載のフレーム伝送阻止装置では、ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）において送受信されるデータフレームすなわちメッセージの内容、およびメッセージの送受信周期に基づいて、不正メッセージを検知する。
　ところで、近年、サービス指向型の通信を行う車載システムの開発が進んでいる。このような車載システムでは、突発的なメッセージ、およびペイロードを含まないメッセージが送受信される。特許文献１に記載のフレーム伝送阻止装置では、突発的なメッセージ、およびペイロードを含まないメッセージが送受信される車載システムにおいて、不正メッセージを検知することが困難であるという問題があった。
　本開示は、上述の課題を解決するためになされたもので、その目的は、車載ネットワークにおけるセキュリティをより向上させることが可能な車載中継装置、管理装置、車載システムおよび通信管理方法を提供することである。
　［本開示の効果］
　本開示によれば、車載ネットワークにおけるセキュリティをより向上させることができる。
　［本開示の実施形態の説明］
　最初に、本開示の実施形態の内容を列記して説明する。
　（１）本開示の実施の形態に係る車載中継装置は、複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う中継部と、前記複数のフレームが、前記複数の車載装置間の通信のセッションの開始要求を含むこと、および前記開始要求に対する開始応答を含むことを判断する判断部と、前記判断部により前記開始要求を含むと判断された前記フレームの送信元の前記車載装置と、前記判断部により前記開始応答を含むと判断された前記フレームの送信元の１または複数の前記車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成する生成部と、前記共通鍵を、前記セッションに参加する前記各車載装置へ前記中継部経由で送信する送信部とを備える。
　このように、車載中継装置において、受信したフレームが開始要求を含むこと、および受信したフレームが開始応答を含むことを判断し、開始要求を含むフレームの送信元の車載装置と、開始応答を含むフレームの送信元の１または複数の車載装置とが参加するセッションに用いる共通鍵をセッションごとに生成して各車載装置へ送信する構成により、車載装置間においてセッションごとに個別の共通鍵を用いた通信を行うことができるので、車載装置間の通信のセキュリティを向上することができる。また、たとえば、開始要求の送信元の車載装置および開始応答の送信元の車載装置の認証を行った上で共通鍵の生成および送信を行うことにより、不正機器によるセッションへの参加を防止することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　（２）前記車載中継装置は、さらに、前記各車載装置の固有ＩＤを記憶する記憶部を備え、前記送信部は、１つの前記固有ＩＤを暗号鍵として用いて暗号化された前記共通鍵を、暗号化に用いた前記固有ＩＤを有する前記車載装置へ前記中継部経由で送信する構成であってもよい。
　このような構成により、セッションに参加することができる正当な車載装置のみが共通鍵を復号することができるので、たとえば不正な車載装置への共通鍵の漏洩を防止することができる。
　（３）前記送信部は、１つの前記固有ＩＤと前記共通鍵とを用いて算出されたハッシュ値を、前記ハッシュ値の算出に用いた前記固有ＩＤを有する前記車載装置へ前記中継部経由でさらに送信する構成であってもよい。
　このような構成により、車載中継装置から共通鍵を受信した車載装置において、自己の固有ＩＤと車載中継装置からの共通鍵とを用いて算出したハッシュ値と、車載中継装置から受信したハッシュ値とを照合することにより、車載中継装置から受信した共通鍵が改ざんされているか否かを確認することができる。
　（４）前記車載中継装置は、さらに、前記共通鍵が用いられる前記セッションに関するセッション情報を記録する記録部を備える構成であってもよい。
　このような構成により、車載中継装置が記録したセッション情報をたとえばデジタルフォレンジックに用いることができる。また、各車載装置にセッション情報を記憶する機能を付与することなく、複数のセッションに関するセッション情報を車載中継装置に集約することができるので、たとえば車載システムにおいて開始されたすべてのセッションに関するセッション情報を簡易な構成で記録することができる。
　（５）前記記録部は、前記セッション情報として、前記共通鍵の前記中継部による送信時刻を記録する構成であってもよい。
　このような構成により、車載中継装置がセッションの開始を記録することができる。
　（６）前記判断部は、前記中継部により受信された前記フレームが、前記セッションの終了要求を含むことを判断し、前記記録部は、前記セッション情報として、前記終了要求を含む前記フレームの前記中継部による受信時刻を記録する構成であってもよい。
　このような構成により、車載中継装置がセッションの終了を記録することができる。
　（７）前記判断部は、前記中継部により受信された前記フレームが前記開始要求または前記開始応答を含むとの判断結果に応じて、前記フレームの適否を判断し、前記中継部は、前記判断部による前記フレームの適否の判断結果に応じて、前記フレームの前記中継処理または破棄を行う構成であってもよい。
　このような構成により、不正機器からの開始要求および開始応答を検知し、不正機器によるセッションへの参加を防止することができる。
　（８）本開示の実施の形態に係る管理装置は、複数の車載装置を備える車載システムに用いられる管理装置であって、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求、および前記開始要求に対する開始応答を、複数の前記車載装置からそれぞれ受信する受信部と、前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成する生成部と、前記共通鍵を前記セッションに参加する前記各車載装置へ送信する送信部とを備える。
　このように、セッションの開始要求および開始応答を車載装置から受信し、セッションに用いる、セッションに固有の共通鍵を生成して各車載装置へ送信する構成により、車載装置間においてセッションごとに個別の共通鍵を用いた通信を行うことができるので、車載装置間の通信のセキュリティを向上することができる。また、たとえば、開始要求の送信元の車載装置の認証を行うことにより、不正機器からの開始要求を検知することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　（９）前記管理装置は、さらに、前記各車載装置の固有ＩＤを記憶する記憶部を備え、前記送信部は、１つの前記固有ＩＤを暗号鍵として用いて暗号化された前記共通鍵を、暗号化に用いた前記固有ＩＤを有する前記車載装置へ送信してもよい。
　このような構成により、セッションに参加することができる正当な車載装置のみが共通鍵を復号することができるので、たとえば不正な車載装置への共通鍵の漏洩を防止することができる。
　（１０）前記送信部は、１つの前記固有ＩＤと前記共通鍵とを用いて算出されたハッシュ値を、前記ハッシュ値の算出に用いた前記固有ＩＤを有する前記車載装置へさらに送信してもよい。
　このような構成により、管理装置から共通鍵を受信した車載装置において、自己の固有ＩＤと管理装置からの共通鍵とを用いて算出したハッシュ値と、管理装置から受信したハッシュ値とを照合することにより、管理装置から受信した共通鍵が改ざんされているか否かを確認することができる。
　（１１）前記受信部は、前記セッションの終了要求を前記車載装置から受信し、前記送信部は、前記受信部による前記終了要求の受信に基づいて、前記セッションを終了させる終了指示を前記セッションに参加している他の前記車載装置へ送信してもよい。
　このような構成により、管理装置がセッションの終了に関与し、終了要求の送信元の車載装置およびセッションの終了時刻を記録することができるので、記録した情報をたとえばデジタルフォレンジックに用いることができる。
　（１２）前記管理装置は、さらに、前記共通鍵が用いられる前記セッションに関するセッション情報を記録する記録部を備える構成であってもよい。
　このような構成により、管理装置が記録したセッション情報をたとえばデジタルフォレンジックに用いることができる。また、各車載装置にセッション情報を記憶する機能を付与することなく、複数のセッションに関するセッション情報を管理装置に集約することができるので、たとえば車載システムにおいて開始されたすべてのセッションに関するセッション情報を簡易な構成で記録することができる。
　（１３）前記記録部は、前記セッション情報として、前記共通鍵の前記送信部による送信時刻を記録してもよい。
　このような構成により、管理装置がセッションの開始を記録することができる。
　（１４）前記管理装置は、さらに、前記共通鍵が用いられる前記セッションに関するセッション情報を記録する記録部を備え、前記記録部は、前記セッション情報として、前記終了要求の前記受信部による受信時刻を記録してもよい。
　このような構成により、管理装置がセッションの終了に関与し、セッションの終了を記録することができる。
　（１５）本開示の実施の形態に係る車載システムは、第１の車載装置および第２の車載装置を含む複数の車載装置と、車載中継装置とを備え、前記車載中継装置は、前記複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行い、前記第１の車載装置は、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を含む第１のフレームを前記車載中継装置へ送信し、前記第２の車載装置は、前記開始要求に対する開始応答を含む第２のフレームを前記車載中継装置へ送信し、前記車載中継装置は、受信した前記第１のフレームの送信元の前記第１の車載装置と、受信した前記第２のフレームの送信元の前記第２の車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信する。
　このように、第１の車載装置が開始要求を車載中継装置へ送信し、第２の車載装置が開始応答を車載中継装置へ送信し、車載中継装置が、第１の車載装置および第２の車載装置が参加するセッションに用いる共通鍵をセッションごとに生成して各車載装置へ送信する構成により、車載装置間においてセッションごとに個別の共通鍵を用いた通信を行うことができるので、車載装置間の通信のセキュリティを向上することができる。また、たとえば、開始要求の送信元の車載装置および開始応答の送信元の車載装置の認証を行った上で共通鍵の生成および送信を行うことにより、不正機器によるセッションへの参加を防止することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　（１６）前記車載中継装置と、前記第１の車載装置および前記第２の車載装置とは、他の中継装置を介さずに接続される構成であってもよい。
　このような構成により、車載中継装置において、第１の車載装置により送信されるフレームおよび第２の車載装置により送信されるフレームを受信することができるので、第１の車載装置および第２の車載装置が参加するセッションの共通鍵の生成および送信を簡単に行うことができる。
　（１７）前記車載装置は、複数の前記車載装置へマルチキャストにより情報を送信している状態において、前記車載システムにおける異常を検知した場合、複数の前記車載装置へユニキャストにより情報を送信する状態に切り替えてもよい。
　このような構成により、車載システムにおいて、たとえば不正機器に侵入される等の異常が生じた場合において、少なくとも正当な車載装置間における安全な通信が可能な状態を維持することができる。
　（１８）前記車載中継装置は、前記車載システムにおける前記各車載装置の固有ＩＤを記憶する記憶部を備え、前記車載中継装置は、１つの前記固有ＩＤと前記共通鍵とを用いて算出されたハッシュ値を、前記ハッシュ値の算出に用いた前記固有ＩＤを有する前記車載装置へさらに送信し、前記車載装置は、前記車載中継装置から受信した前記共通鍵と自己の前記固有ＩＤとを用いて算出されるハッシュ値と、前記車載中継装置から受信した前記ハッシュ値とを照合してもよい。
　このような構成により、車載装置において、算出したハッシュ値と、車載中継装置から受信したハッシュ値との照合結果に基づいて、車載中継装置から受信した共通鍵が改ざんされているか否かを確認することができる。
　（１９）本開示の実施の形態に係る車載システムは、第１の車載装置および第２の車載装置を含む複数の車載装置と、管理装置とを備え、前記第１の車載装置は、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を前記管理装置へ送信し、前記第２の車載装置は、前記開始要求に対する開始応答を前記管理装置へ送信し、前記管理装置は、受信した前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信する。
　このように、第１の車載装置がセッションの開始要求を管理装置へ送信し、第２の車載装置が、開始要求に対する開始応答を管理装置へ送信し、管理装置が、セッションに用いる、セッションに固有の共通鍵を生成して各車載装置へ送信する構成により、車載装置間においてセッションごとに個別の共通鍵を用いた通信を行うことができるので、車載装置間の通信のセキュリティを向上することができる。また、たとえば、開始要求の送信元の車載装置の認証を行うことにより、不正機器からの開始要求を検知することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　（２０）前記車載装置は、複数の前記車載装置へマルチキャストにより情報を送信している状態において、前記車載システムにおける異常を検知した場合、複数の前記車載装置へユニキャストにより情報を送信する状態に切り替えてもよい。
　このような構成により、車載システムにおいて、たとえば不正機器に侵入される等の異常が生じた場合において、少なくとも正当な車載装置間における安全な通信が可能な状態を維持することができる。
　（２１）前記管理装置は、前記車載システムにおける前記各車載装置の固有ＩＤを記憶する記憶部を備え、前記管理装置は、１つの前記固有ＩＤと前記共通鍵とを用いて算出されたハッシュ値を、前記ハッシュ値の算出に用いた前記固有ＩＤを有する前記車載装置へさらに送信し、前記車載装置は、前記管理装置から受信した前記共通鍵と自己の前記固有ＩＤとを用いて算出されるハッシュ値と、前記管理装置から受信した前記ハッシュ値とを照合してもよい。
　このような構成により、車載装置において、算出したハッシュ値と、管理装置から受信したハッシュ値との照合結果に基づいて、管理装置から受信した共通鍵が改ざんされているか否かを確認することができる。
　（２２）本開示の実施の形態に係る通信管理方法は、複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う車載中継装置における通信管理方法であって、前記複数のフレームが、前記複数の車載装置間の通信のセッションの開始要求を含むこと、および前記開始要求に対する開始応答を含むことを判断するステップと、前記開始要求を含むと判断した前記フレームの送信元の前記車載装置と、前記開始応答を含むと判断した前記フレームの送信元の１または複数の前記車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成するステップと、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む。
　このように、車載中継装置において、受信したフレームが開始要求を含むこと、および受信したフレームが開始応答を含むことを判断し、開始要求を含むフレームの送信元の車載装置と、開始応答を含むフレームの送信元の１または複数の車載装置とが参加するセッションに用いる共通鍵をセッションごとに生成して各車載装置へ送信する方法により、車載装置間においてセッションごとに個別の共通鍵を用いた通信を行うことができるので、車載装置間の通信のセキュリティを向上することができる。また、たとえば、開始要求の送信元の車載装置および開始応答の送信元の車載装置の認証を行った上で共通鍵の生成および送信を行うことにより、不正機器によるセッションへの参加を防止することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　（２３）本開示の実施の形態に係る通信管理方法は、複数の車載装置を備える車載システムに用いられる管理装置における通信管理方法であって、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求、および前記開始要求に対する開始応答を、複数の前記車載装置からそれぞれ受信するステップと、受信した前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成するステップと、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む。
　このように、セッションの開始要求および開始応答を車載装置から受信し、セッションに用いる、セッションに固有の共通鍵を生成して各車載装置へ送信する方法により、車載装置間においてセッションごとに個別の共通鍵を用いた通信を行うことができるので、車載装置間の通信のセキュリティを向上することができる。また、たとえば、開始要求の送信元の車載装置の認証を行うことにより、不正機器からの開始要求を検知することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　（２４）本開示の実施の形態に係る通信管理方法は、第１の車載装置および第２の車載装置を含む複数の車載装置と、前記複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う車載中継装置とを備える車載システムにおける通信管理方法であって、前記第１の車載装置が、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を含む第１のフレームを前記車載中継装置へ送信するステップと、前記第２の車載装置が、前記開始要求に対する開始応答を含む第２のフレームを前記車載中継装置へ送信するステップと、前記車載中継装置が、受信した前記第１のフレームの送信元の前記第１の車載装置と、受信した前記第２のフレームの送信元の前記第２の車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む。
　このように、第１の車載装置が開始要求を車載中継装置へ送信し、第２の車載装置が開始応答を車載中継装置へ送信し、車載中継装置が、第１の車載装置および第２の車載装置が参加するセッションに用いる共通鍵をセッションごとに生成して各車載装置へ送信する方法により、車載装置間においてセッションごとに個別の共通鍵を用いた通信を行うことができるので、車載装置間の通信のセキュリティを向上することができる。また、たとえば、開始要求の送信元の車載装置および開始応答の送信元の車載装置の認証を行った上で共通鍵の生成および送信を行うことにより、不正機器によるセッションへの参加を防止することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　（２５）本開示の実施の形態に係る通信管理方法は、第１の車載装置および第２の車載装置を含む複数の車載装置と、管理装置とを備える車載システムにおける通信管理方法であって、前記第１の車載装置が、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を前記管理装置へ送信するステップと、前記第２の車載装置が、前記開始要求に対する開始応答を前記管理装置へ送信するステップと、前記管理装置が、受信した前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む。
　このように、第１の車載装置がセッションの開始要求を管理装置へ送信し、第２の車載装置が、開始要求に対する開始応答を管理装置へ送信し、管理装置が、セッションに用いる、セッションに固有の共通鍵を生成して各車載装置へ送信する方法により、車載装置間においてセッションごとに個別の共通鍵を用いた通信を行うことができるので、車載装置間の通信のセキュリティを向上することができる。また、たとえば、開始要求の送信元の車載装置の認証を行うことにより、不正機器からの開始要求を検知することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　以下、本開示の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。また、以下に記載する実施の形態の少なくとも一部を任意に組み合わせてもよい。
　〔第１の実施の形態〕
　［構成および基本動作］
　＜車載システム＞
　図１は、本開示の第１の実施の形態に係る車載システムの構成を示す図である。図１を参照して、車載システム３０１は、中継装置１０１と、複数の車載ＥＣＵ１１１とを備える。中継装置１０１は、車載中継装置の一例である。車載ＥＣＵ１１１は、車載装置の一例である。車載システム３０１は、車両１に搭載される。中継装置１０１は、車載システム３０１に用いられる。
　中継装置１０１は、ケーブル１４を介して各車載ＥＣＵ１１１と接続される。たとえば、中継装置１０１と、車載ＥＣＵ１１１とは、他の中継装置を介さずに接続される。ケーブル１４は、たとえば、イーサネット（登録商標）ケーブルである。中継装置１０１および車載ＥＣＵ１１１は、車載ネットワークを構成する。
　車載ＥＣＵ１１１は、たとえば、電動パワーステアリング（Ｅｌｅｃｔｒｉｃ　Ｐｏｗｅｒ　Ｓｔｅｅｒｉｎｇ：ＥＰＳ）、ブレーキ制御装置、アクセル制御装置、ステアリング制御装置、運転支援システム（Ａｄｖａｎｃｅｄ　Ｄｒｉｖｅｒ－Ａｓｓｉｓｔａｎｃｅ　Ｓｙｓｔｅｍ：ＡＤＡＳ）における各種装置への指示等を行う運転支援装置、またはセンサ等である。
　図２は、本開示の第１の実施の形態に係る車載システムにおいて送受信されるイーサネットフレームの一例を示す図である。図２を参照して、イーサネットフレームは、イーサネットヘッダと、ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）ヘッダと、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）ヘッダと、データフィールドと、ＦＣＳ（Ｆｒａｍｅ　Ｃｈｅｃｋ　Ｓｅｑｕｅｎｃｅ）とを有する。イーサネットヘッダには、宛先ＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスと、送信元ＭＡＣアドレスと、タイプとが格納される。
　車載ＥＣＵ１１１は、他の車載ＥＣＵ１１１宛のイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１へ送信する。
　中継装置１０１は、車載ＥＣＵ１１１と通信を行うことが可能である。中継装置１０１は、車載ＥＣＵ１１１から受信したイーサネットフレームを他の車載ＥＣＵ１１１へ送信する中継処理を行う。たとえば、中継装置１０１は、レイヤ２に従って中継処理を行う。なお、中継装置１０１は、レイヤ２よりも上位のレイヤ３に従って中継処理を行う構成であってもよい。
　（ＳＯＭＥ／ＩＰ）
　車載システム３０１においては、たとえば、インターネットプロトコル群におけるセッション層以上の層のプロトコルであるＳＯＭＥ／ＩＰ（Ｓｃａｌａｂｌｅ　ｓｅｒｖｉｃｅ－Ｏｒｉｅｎｔｅｄ　ＭｉｄｄｌｅｗａｒＥ　ｏｖｅｒ　ＩＰ）に従って、メッセージの送受信が行われる。より詳細には、車載ＥＣＵ１１１は、各種情報が格納されたメッセージをイーサネットフレームのデータフィールドに格納し、当該イーサネットフレームを、ＳＯＭＥ／ＩＰに従って中継装置１０１経由で他の車載ＥＣＵ１１１へ送信する。
　たとえば、車載ＥＣＵ１１１は、複数の車載ＥＣＵ１１１間の通信のセッションを開始する。そして、当該セッションに参加する複数の車載ＥＣＵ１１１は、メッセージの送受信を行う。セッションに参加する車載ＥＣＵ１１１の組み合わせは、固定的ではなく、動的に変化する。
　一例として、車載ＥＣＵ１１１であるセンサと、他の車載ＥＣＵ１１１である運転支援装置とがセッションを開始する。この場合、当該センサは、サービスの提供として、車両１の走行状態または周囲の状態に関するセンサ情報をメッセージに格納して当該運転支援装置へ送信する。運転支援装置は、受信したメッセージから、サービスとして提供されたセンサ情報を取得し、当該センサ情報を用いて、車両１の運転に関する各種制御情報を生成し、生成した各種制御情報をブレーキ制御装置およびステアリング制御装置等へ送信する。
　以下、サービスの提供を行う側の車載ＥＣＵ１１１を「サーバ」とも称する。また、サービスの提供を受ける側の車載ＥＣＵ１１１を「クライアント」とも称する。車載ＥＣＵ１１１は、サーバとしてのみ機能してもよいし、クライアントとしてのみ機能してもよいし、セッションにおけるサービスの内容に応じてサーバまたはクライアントとして機能してもよい。サーバは、第１の車載装置の一例である。クライアントは、第２の車載装置の一例である。
　（Ａ）セッションの開始
　ＳＯＭＥ／ＩＰに従う通信では、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙが実行されることにより、セッションが開始する。より詳細には、複数の車載ＥＣＵ１１１は、ＳＯＭＥ／ＩＰ－ＳＤメッセージを送受信することにより、セッションを開始する。
　図３は、本開示の第１の実施の形態に係る車載システムにおいて送受信されるＳＯＭＥ／ＩＰ－ＳＤメッセージの一例を示す図である。図３を参照して、ＳＯＭＥ／ＩＰ－ＳＤメッセージは、ＳＯＭＥ／ＩＰヘッダと、ＳＯＭＥ／ＩＰ－ＳＤヘッダとを有する。
　（Ａ－１）Ｏｆｆｅｒメッセージ
　一例として、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの機能により、サーバがサービスの提供を申し出て、クライアントとサーバとの間のセッションが開始する。
　たとえば、ある車載ＥＣＵ１１１は、サーバとして、定期的または不定期に、ＳＯＭＥ／ＩＰ－ＳＤメッセージの一例であるＯｆｆｅｒメッセージをマルチキャストする。より詳細には、サーバは、当該サーバが提供可能なサービスに対応するサービスＩＤがＳＯＭＥ／ＩＰ－ＳＤヘッダに格納されたＯｆｆｅｒメッセージを生成する。そして、サーバは、データフィールドにＯｆｆｅｒメッセージが格納され、かつ宛先ＭＡＣアドレスとしてマルチキャストアドレスが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１へ送信する。当該Ｏｆｆｅｒメッセージは、セッションの開始要求の一例である。
　中継装置１０１経由でサーバからＯｆｆｅｒメッセージを受信した複数の車載ＥＣＵ１１１のうち、Ｏｆｆｅｒメッセージに含まれるサービスＩＤに対応するサービスを必要とする車載ＥＣＵ１１１は、クライアントとして、ＳＯＭＥ／ＩＰ－ＳＤメッセージの一例であるＳｕｂｓｃｒｉｂｅメッセージを中継装置１０１経由でサーバへ送信する。より詳細には、クライアントは、データフィールドにＳｕｂｓｃｒｉｂｅメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でサーバへ送信する。当該Ｓｕｂｓｃｒｉｂｅメッセージは、セッションの開始要求に対する開始応答の一例である。
　サーバは、中継装置１０１経由でクライアントからＳｕｂｓｃｒｉｂｅメッセージを受信すると、クライアントへのサービスの提供を開始する。
　（Ａ－２）Ｆｉｎｄメッセージ
　他の例として、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの機能により、クライアントがサービスの提供元であるサーバを探索して、クライアントとサーバとの間の通信のセッションが開始する。
　たとえば、ある車載ＥＣＵ１１１は、クライアントとして、定期的または不定期に、ＳＯＭＥ／ＩＰ－ＳＤメッセージの一例であるＦｉｎｄメッセージをマルチキャストする。より詳細には、クライアントは、提供を受けようとするサービスに対応するサービスＩＤがＳＯＭＥ／ＩＰ－ＳＤヘッダに格納されたＦｉｎｄメッセージを生成する。そして、クライアントは、データフィールドにＦｉｎｄメッセージが格納され、かつ宛先ＭＡＣアドレスとしてマルチキャストアドレスが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１へ送信する。当該Ｆｉｎｄメッセージは、セッションの探索要求の一例である。
　中継装置１０１経由でクライアントからＦｉｎｄメッセージを受信した複数の車載ＥＣＵ１１１のうち、Ｆｉｎｄメッセージに含まれるサービスＩＤに対応するサービスを提供可能な車載ＥＣＵ１１１は、サーバとして、ＳＯＭＥ／ＩＰ－ＳＤメッセージの一例であるＯｆｆｅｒメッセージを中継装置１０１経由でクライアントへ送信する。より詳細には、サーバは、データフィールドにＯｆｆｅｒメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でクライアントへ送信する。当該Ｏｆｆｅｒメッセージは、セッションの探索要求に対する開始要求の一例である。
　クライアントは、中継装置１０１経由でサーバからＯｆｆｅｒメッセージを受信すると、ＳＯＭＥ／ＩＰ－ＳＤメッセージの一例であるＳｕｂｓｃｒｉｂｅメッセージを中継装置１０１経由でサーバへ送信する。より詳細には、クライアントは、データフィールドにＳｕｂｓｃｒｉｂｅメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でサーバへ送信する。当該Ｓｕｂｓｃｒｉｂｅメッセージは、セッションの開始要求に対する開始応答の一例である。
　サーバは、中継装置１０１経由でクライアントからＳｕｂｓｃｒｉｂｅメッセージを受信すると、クライアントへのサービスの提供を開始する。
　（Ｂ）セッションにおける通信
　ＳＯＭＥ／ＩＰに従う通信では、サーバおよびクライアントのセッションにおいて、当該サーバから当該クライアントへのＳＯＭＥ／ＩＰメッセージの送信が行われる。
　図４は、本開示の第１の実施の形態に係る車載システムにおいて送受信されるＳＯＭＥ／ＩＰメッセージの一例を示す図である。図４を参照して、ＳＯＭＥ／ＩＰメッセージは、ＳＯＭＥ／ＩＰヘッダと、ペイロードとを有する。
　たとえば、サーバは、定期的または不定期に、ＳＯＭＥ／ＩＰメッセージの一例であるセッションメッセージを中継装置１０１経由でクライアントへ送信する。より詳細には、サーバは、サービスとして提供すべき情報がペイロードに格納されたセッションメッセージを生成する。そして、サーバは、データフィールドにセッションメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でクライアントへ送信する。
　（Ｃ）セッションの終了
　ＳＯＭＥ／ＩＰに従う通信では、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙが実行されることにより、セッションが終了する。より詳細には、複数の車載ＥＣＵ１１１は、ＳＯＭＥ／ＩＰ－ＳＤメッセージを送受信することにより、セッションを終了する。
　（Ｃ－１）ＳｔｏｐＯｆｆｅｒメッセージ
　一例として、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの機能により、サーバがサービスの提供の停止を申し出て、セッションが終了する。
　たとえば、サーバは、サービスの提供を停止する場合、ＳＯＭＥ／ＩＰ－ＳＤメッセージの一例であるＳｔｏｐＯｆｆｅｒメッセージをクライアントへ送信する。より詳細には、サーバは、提供を停止するサービスに対応するサービスＩＤがＳＯＭＥ／ＩＰ－ＳＤヘッダに格納されたＳｔｏｐＯｆｆｅｒメッセージを生成する。そして、サーバは、データフィールドにＳｔｏｐＯｆｆｅｒメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でクライアントへ送信する。当該ＳｔｏｐＯｆｆｅｒメッセージは、セッションの終了要求の一例である。
　サーバは、中継装置１０１経由でクライアントへＳｔｏｐＯｆｆｅｒメッセージを送信した後、クライアントへのサービスの提供を終了する。
　（Ｃ－２）ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージ
　他の例として、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの機能により、クライアントがサービスの享受の停止を申し出て、セッションが終了する。
　たとえば、クライアントは、サービスの享受を停止する場合、ＳＯＭＥ／ＩＰ－ＳＤメッセージの一例であるＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージをサーバへ送信する。より詳細には、クライアントは、享受を停止するサービスに対応するサービスＩＤがＳＯＭＥ／ＩＰ－ＳＤヘッダに格納されたＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを生成する。そして、クライアントは、データフィールドにＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でサーバへ送信する。当該ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージは、セッションの終了要求の一例である。
　サーバは、中継装置１０１経由でクライアントからＳｕｂｓｃｒｉｂｅメッセージを受信すると、クライアントへのサービスの提供を終了する。
　＜車載ＥＣＵおよび中継装置における処理の概要＞
　図５は、本開示の第１の実施の形態に係る車載ＥＣＵの構成を示す図である。図５を参照して、車載ＥＣＵ１１１は、通信部１１と、処理部１２と、記憶部１３とを備える。通信部１１および処理部１２は、たとえば、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）およびＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）等のプロセッサにより実現される。記憶部１３は、たとえば不揮発性メモリである。
　車載ＥＣＵ１１１における記憶部１３は、当該車載ＥＣＵ１１１の固有ＩＤと、当該車載ＥＣＵ１１１の識別子であるＥＣＵ識別子と、当該車載ＥＣＵ１１１のエンドポイント情報と、中継装置１０１のエンドポイント情報とを記憶している。固有ＩＤは、たとえば車両１の出荷時に記憶部１３に書き込まれる。固有ＩＤは、ＥＣＵ識別子と比べて秘匿性が高い。エンドポイント情報は、ＩＰアドレスと論理ポート番号とを含む。
　また、記憶部１３は、車載システム３０１において提供されるサービスの内容と、サービスＩＤとの対応関係を示すサービスリストを記憶している。
　図６は、本開示の第１の実施の形態に係る中継装置の構成を示す図である。図６を参照して、中継装置１０１は、複数の通信ポート２１と、中継部２２と、処理部２３と、ログ生成部２４と、記憶部２５とを備える。処理部２３は、判断部の一例であり、生成部の一例であり、かつ送信部の一例である。ログ生成部２４は、記録部の一例である。中継部２２、処理部２３およびログ生成部２４は、たとえば、ＣＰＵおよびＤＳＰ等のプロセッサにより実現される。記憶部２５は、たとえば不揮発性メモリである。
　通信ポート２１は、ケーブル１４を接続可能な端子である。通信ポート２１は、ケーブル１４を介して車載ＥＣＵ１１１に接続されている。なお、通信ポート２１は、集積回路の端子であってもよい。
　記憶部２５は、通信ポート２１のポート番号と、通信ポート２１に接続された車載ＥＣＵ１１１のＭＡＣアドレスとの対応関係を示すアドレステーブルＴｂ１を記憶する。
　また、記憶部２５は、車載システム３０１における各車載ＥＣＵ１１１の固有ＩＤを記憶する。たとえば、記憶部２５は、サービスＩＤごとに、サービスに関与し得るサーバおよびクライアントの、エンドポイント情報と、ＥＣＵ識別子と、固有ＩＤとを示す接続先リストを記憶する。
　図７は、本開示の第１の実施の形態に係る中継装置における記憶部が記憶する接続先リストの一例を示す図である。図７を参照して、接続先リストには、サービスＩＤが「０ｘ０００１」であるサービスに関与し得る２つのサーバおよび２つのクライアントのエンドポイント情報等、ならびにサービスＩＤが「０ｘ０００２」であるサービスに関与し得る１つのサーバおよび２つのクライアントのエンドポイント情報等が登録されている。具体的には、接続先リストには、たとえばサービスＩＤが「０ｘ０００２」であるサービスに関与し得るサーバとして、エンドポイント情報が「ＡＡＡ」であり、ＥＣＵ識別子が「ＥＣＵ＿１」であり、かつ固有ＩＤが「ＩＤ＿Ａ」である車載ＥＣＵ１１１が登録されている。ここで、「０ｘ」で始まる数字は、「０ｘ」以降の数字が１６進数で表されていることを意味する。
　中継部２２は、複数の車載ＥＣＵ１１１からそれぞれ受信した複数のイーサネットフレームを、宛先の車載ＥＣＵ１１１へそれぞれ送信する中継処理を行う。後述するように、中継部２２は、処理部２３からの指示により、受信したイーサネットフレームを宛先の車載ＥＣＵ１１１へ中継することなく破棄する場合がある。
　より詳細には、中継部２２は、ある車載ＥＣＵ１１１から対応の通信ポート２１経由でイーサネットフレームを受信すると、受信したイーサネットフレームを記憶部２５に保存する。
　処理部２３は、中継部２２により受信されたイーサネットフレームがＳＯＭＥ／ＩＰ－ＳＤメッセージを含むか否かを判断する。たとえば、処理部２３は、中継部２２により記憶部２５にイーサネットフレームが保存されると、当該イーサネットフレームのデータフィールドにＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれているか否かを確認する。
　処理部２３は、中継部２２により記憶部２５に保存されたイーサネットフレームのデータフィールドにＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれていない場合、当該イーサネットフレームはＳＯＭＥ／ＩＰ－ＳＤメッセージを含まないと判断し、当該イーサネットフレームの中継処理を行うべき旨を示す中継指示を中継部２２へ出力する。
　中継部２２は、処理部２３から中継指示を受けた場合、中継指示が示すイーサネットフレームを記憶部２５から取得し、当該イーサネットフレームの中継処理を行う。具体的には、中継部２２は、記憶部２５におけるアドレステーブルＴｂ１を参照し、イーサネットフレームの宛先ＭＡＣアドレスに対応するポート番号の通信ポート２１経由で当該イーサネットフレームを宛先の車載ＥＣＵ１１１へ送信する。
　一方、処理部２３は、中継部２２により記憶部２５に保存されたイーサネットフレームのデータフィールドにＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれている場合、当該イーサネットフレームはＳＯＭＥ／ＩＰ－ＳＤメッセージを含むと判断する。そして、処理部２３は、ＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームがＯｆｆｅｒメッセージを含むことを判断する。あるいは、処理部２３は、中継部２２により記憶部２５に保存されたイーサネットフレームのＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームがＦｉｎｄメッセージを含むことを判断する。あるいは、処理部２３は、中継部２２により記憶部２５に保存されたイーサネットフレームのＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームがＳｕｂｓｃｒｉｂｅメッセージを含むことを判断する。あるいは、処理部２３は、中継部２２により記憶部２５に保存されたイーサネットフレームのＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームがＳｔｏｐＯｆｆｅｒメッセージを含むことを判断する。あるいは、処理部２３は、中継部２２により記憶部２５に保存されたイーサネットフレームのＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームがＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを含むことを判断する。
　また、処理部２３は、中継部２２により記憶部２５に保存されたイーサネットフレームがＳＯＭＥ／ＩＰ－ＳＤメッセージを含むと判断した場合、当該イーサネットフレームの適否を判断する。
　中継部２２は、処理部２３による当該イーサネットフレームの適否の判断結果に応じて、当該イーサネットフレームの中継処理または破棄を行う。
　より詳細には、処理部２３は、当該イーサネットフレームが不適切であると判断した場合、当該イーサネットフレームを破棄すべき旨を示す破棄指示を中継部２２へ出力する。
　中継部２２は、処理部２３から破棄指示を受けた場合、記憶部２５における、中継指示が示すイーサネットフレームを破棄する。
　一方、処理部２３は、当該イーサネットフレームが適切であると判断した場合、当該イーサネットフレームの中継処理を行うべき旨を示す中継指示を中継部２２へ出力する。
　中継部２２は、処理部２３から中継指示を受けた場合、中継指示が示すイーサネットフレームを記憶部２５から取得し、当該イーサネットフレームの中継処理を行う。
　処理部２３は、Ｏｆｆｅｒメッセージ等の開始要求を含むと判断したイーサネットフレームの送信元の車載ＥＣＵ１１１と、Ｓｕｂｓｃｒｉｂｅメッセージ等の開始応答を含むと判断したイーサネットフレームの送信元の１または複数の車載ＥＣＵ１１１とが参加するセッションに用いるセッション鍵Ｋをセッションごとに生成する。セッション鍵Ｋは、共通鍵の一例であり、たとえば使用する暗号方式に従った鍵長の乱数である。たとえば、処理部２３は、セッションごとにランダムな内容のセッション鍵Ｋを生成する。
　処理部２３は、生成したセッション鍵Ｋを当該セッションに参加する各車載ＥＣＵ１１１へ中継部２２経由で送信する。ログ生成部２４は、処理部２３により生成されたセッション鍵Ｋが用いられるセッションに関するセッション情報を記録する。
　（１）Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙにおける処理例１
　（１－１）サーバによるＯｆｆｅｒメッセージの送信
　再び図５を参照して、サーバである車載ＥＣＵ１１１において、処理部１２は、記憶部１３におけるサービスリストを参照し、当該車載ＥＣＵ１１１が提供可能なサービスに対応するサービスＩＤを取得する。また、処理部１２は、記憶部１３からＥＣＵ識別子および当該車載ＥＣＵ１１１のエンドポイント情報を取得する。処理部１２は、取得したサービスＩＤ、ＥＣＵ識別子およびエンドポイント情報を含むＯｆｆｅｒメッセージを生成する。
　処理部１２は、生成したＯｆｆｅｒメッセージおよび記憶部１３における固有ＩＤに基づいてＭＡＣ（Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）値を算出する。処理部１２は、データフィールドに当該Ｏｆｆｅｒメッセージおよび当該ＭＡＣ値が格納され、かつ宛先ＭＡＣアドレスとしてマルチキャストアドレスが格納されたイーサネットフレームを生成する。処理部１２は、生成したイーサネットフレームを通信部１１へ出力する。
　通信部１１は、処理部１２から受けたイーサネットフレームを中継装置１０１へ送信する。
　（１－２）中継装置によるＯｆｆｅｒメッセージの適否の判断
　再び図６を参照して、中継装置１０１における中継部２２は、サーバから対応の通信ポート経由でイーサネットフレームを受信し、受信したイーサネットフレームにタイムスタンプを付し、イーサネットフレームを記憶部２５に保存する。
　処理部２３は、中継部２２により記憶部２５にイーサネットフレームが保存されると、当該イーサネットフレームのデータフィールドにＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれていることを確認し、ＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームはＯｆｆｅｒメッセージを含むと判断する。そして、処理部２３は、当該イーサネットフレームの適否を判断する。
　より詳細には、処理部２３は、当該イーサネットフレームからＯｆｆｅｒメッセージ、ＭＡＣ値およびタイムスタンプを取得する。また、処理部２３は、取得したＯｆｆｅｒメッセージからサービスＩＤ、車載ＥＣＵ１１１のエンドポイント情報およびＥＣＵ識別子を取得する。そして、処理部２３は、記憶部２５における接続先リストを参照し、Ｏｆｆｅｒメッセージから取得したサービスＩＤが示すサービスに関与し得るサーバとして、Ｏｆｆｅｒメッセージから取得したエンドポイント情報およびＥＣＵ識別子により特定される車載ＥＣＵ１１１が接続先リストに登録されているか否かを確認する。
　一例として、処理部２３は、Ｏｆｆｅｒメッセージから取得したサービスＩＤ、エンドポイント情報およびＥＣＵ識別子が、それぞれ、「０ｘ０００１」、「ＢＢＢ」および「ＥＣＵ＿２」である場合、当該サービスＩＤが示すサービスに関与し得るサーバとして、当該ＥＣＵ識別子および当該エンドポイント情報により特定される車載ＥＣＵ１１１が接続先リストに登録されていると判断する。
　また、処理部２３は、接続先リストを参照し、Ｏｆｆｅｒメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１の固有ＩＤを取得する。処理部２３は、Ｏｆｆｅｒメッセージおよび取得した固有ＩＤに基づいてＭＡＣ値を算出する。そして、処理部２３は、イーサネットフレームから取得したＭＡＣ値と、自己が算出したＭＡＣ値とを照合することにより、当該イーサネットフレームが改ざんされているか否かを判断する。
　処理部２３は、Ｏｆｆｅｒメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されており、かつイーサネットフレームが改ざんされていないと判断した場合、中継部２２により受信されたイーサネットフレームは適切であると判断する。一方、処理部２３は、Ｏｆｆｅｒメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されていない場合、またはイーサネットフレームが改ざんされていると判断した場合、中継部２２により受信されたイーサネットフレームは不適切であると判断する。
　処理部２３は、イーサネットフレームが適切であると判断した場合、Ｏｆｆｅｒメッセージから取得したＥＣＵ識別子およびエンドポイント情報をサーバ情報として記憶部２５に保存する。
　また、処理部２３は、中継部２２により受信されたイーサネットフレームが適切であると判断した場合、記憶部２５におけるイーサネットフレームに含まれるＯｆｆｅｒメッセージからＥＣＵ識別子およびエンドポイント情報を消去する。そして、処理部２３は、当該イーサネットフレームの中継処理を行うべき旨を示す中継指示を中継部２２へ出力する。
　中継部２２は、処理部２３から中継指示を受けた場合、中継指示が示すイーサネットフレームを記憶部２５から取得し、当該イーサネットフレームの中継処理を行う。具体的には、中継部２２は、処理部２３によりＥＣＵ識別子およびエンドポイント情報が消去されたイーサネットフレームを、当該イーサネットフレームの宛先ＭＡＣアドレスであるマルチキャストアドレスに従って、当該イーサネットフレームの送信元の車載ＥＣＵ１１１以外の車載ＥＣＵ１１１へ送信する。
　一方、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、当該イーサネットフレームを破棄すべき旨を示す破棄指示を中継部２２へ出力する。
　中継部２２は、処理部２３から破棄指示を受けた場合、破棄指示が示すイーサネットフレームを破棄する。
　また、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、Ｏｆｆｅｒメッセージおよびタイムスタンプをログ生成部２４へ出力する。ログ生成部２４は、処理部２３により不適切であると判断されたイーサネットフレームに含まれるメッセージに関する情報を記録する。
　図８は、本開示の第１の実施の形態に係る中継装置における記憶部における不正ログリストの一例を示す図である。図８を参照して、記憶部２５は、処理部２３により不適切と判断されたイーサネットフレームに含まれるメッセージのバイト列と、当該イーサネットフレームの送信元の車載ＥＣＵ１１１のＥＣＵ識別子と、当該イーサネットフレームの受信時刻とを示す不正ログのリストである不正ログリストＲ１を記憶している。
　ログ生成部２４は、処理部２３からＯｆｆｅｒメッセージおよびタイムスタンプを受けて、受けたＯｆｆｅｒメッセージに含まれるＥＣＵ識別子を取得し、当該Ｏｆｆｅｒメッセージのバイト列、取得したＥＣＵ識別子および受信時刻を不正ログとして記憶部２５における不正ログリストＲ１に書き込む。
　（１－３）クライアントによるＳｕｂｓｃｒｉｂｅメッセージの送信
　再び図５を参照して、クライアントである車載ＥＣＵ１１１において、処理部１２は、通信部１１経由で中継装置１０１からイーサネットフレームを受信し、受信したイーサネットフレームから送信元ＭＡＣアドレスおよびＯｆｆｅｒメッセージを取得する。また、処理部１２は、取得したＯｆｆｅｒメッセージからサービスＩＤを取得する。
　処理部１２は、記憶部１３におけるサービスリストを参照し、取得したサービスＩＤが示すサービスの要否を判断する。処理部１２は、当該サービスが必要であると判断した場合、記憶部１３からＥＣＵ識別子および当該車載ＥＣＵ１１１のエンドポイント情報を取得し、当該サービスに対応するサービスＩＤ、取得したＥＣＵ識別子および取得したエンドポイント情報を含むＳｕｂｓｃｒｉｂｅメッセージを生成する。一方、処理部１２は、当該サービスが不要であると判断した場合、Ｓｕｂｓｃｒｉｂｅメッセージの生成を行わない。
　処理部１２は、生成したＳｕｂｓｃｒｉｂｅメッセージおよび記憶部１３における固有ＩＤに基づいてＭＡＣ値を算出する。処理部１２は、データフィールドに当該Ｓｕｂｓｃｒｉｂｅメッセージおよび当該ＭＡＣ値が格納され、かつ宛先ＭＡＣアドレスとしてサーバのＭＡＣアドレスが格納されたイーサネットフレームを生成する。処理部１２は、生成したイーサネットフレームを通信部１１へ出力する。
　通信部１１は、処理部１２から受けたイーサネットフレームを中継装置１０１へ送信する。
　（１－４）中継装置によるＳｕｂｓｃｒｉｂｅメッセージの適否の判断
　再び図６を参照して、中継装置１０１における中継部２２は、クライアントから対応の通信ポート経由でイーサネットフレームを受信し、受信したイーサネットフレームにタイムスタンプを付し、イーサネットフレームを記憶部２５に保存する。
　処理部２３は、中継部２２により記憶部２５にイーサネットフレームが保存されると、当該イーサネットフレームのデータフィールドにＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれていることを確認し、ＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームはＳｕｂｓｃｒｉｂｅメッセージを含むと判断する。そして、処理部２３は、当該イーサネットフレームの適否を判断する。
　より詳細には、処理部２３は、当該イーサネットフレームからＳｕｂｓｃｒｉｂｅメッセージ、ＭＡＣ値およびタイムスタンプを取得する。また、処理部２３は、取得したＳｕｂｓｃｒｉｂｅメッセージからサービスＩＤ、車載ＥＣＵ１１１のエンドポイント情報およびＥＣＵ識別子を取得する。そして、処理部２３は、記憶部２５における接続先リストを参照し、Ｓｕｂｓｃｒｉｂｅメッセージから取得したサービスＩＤが示すサービスに関与し得るクライアントとして、Ｓｕｂｓｃｒｉｂｅメッセージから取得したエンドポイント情報およびＥＣＵ識別子により特定される車載ＥＣＵ１１１が接続先リストに登録されているか否かを確認する。
　一例として、処理部２３は、Ｓｕｂｓｃｒｉｂｅメッセージから取得したサービスＩＤ、エンドポイント情報およびＥＣＵ識別子が、それぞれ、「０ｘ０００１」、「ＣＣＣ」および「ＥＣＵ＿３」である場合、当該サービスＩＤが示すサービスに関与し得るクライアントとして、当該ＥＣＵ識別子および当該エンドポイント情報により特定される車載ＥＣＵ１１１が接続先リストに登録されていると判断する。
　また、処理部２３は、接続先リストを参照し、Ｓｕｂｓｃｒｉｂｅメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１の固有ＩＤを取得する。処理部２３は、Ｓｕｂｓｃｒｉｂｅメッセージおよび取得した固有ＩＤに基づいてＭＡＣ値を算出する。そして、処理部２３は、イーサネットフレームから取得したＭＡＣ値と、自己が算出したＭＡＣ値とを照合することにより、当該イーサネットフレームが改ざんされているか否かを判断する。
　処理部２３は、Ｓｕｂｓｃｒｉｂｅメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されており、かつイーサネットフレームが改ざんされていないと判断した場合、中継部２２により受信されたイーサネットフレームは適切であると判断する。一方、処理部２３は、Ｓｕｂｓｃｒｉｂｅメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されていない場合、またはイーサネットフレームが改ざんされていると判断した場合、中継部２２により受信されたイーサネットフレームは不適切であると判断する。
　処理部２３は、イーサネットフレームが適切であると判断した場合、Ｓｕｂｓｃｒｉｂｅメッセージから取得したＥＣＵ識別子およびエンドポイント情報をクライアント情報として記憶部２５に保存する。
　一方、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、当該イーサネットフレームを破棄すべき旨を示す破棄指示を中継部２２へ出力する。
　中継部２２は、処理部２３から破棄指示を受けた場合、破棄指示が示すイーサネットフレームを破棄する。
　また、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、Ｓｕｂｓｃｒｉｂｅメッセージおよびタイムスタンプをログ生成部２４へ出力する。ログ生成部２４は、処理部２３により不適切であると判断されたイーサネットフレームに含まれるメッセージに関する情報を記憶部２５における不正ログリストＲ１に書き込む。
　（１－５）中継装置によるセッション鍵の生成および配布
　中継装置１０１における処理部２３は、Ｓｕｂｓｃｒｉｂｅメッセージが格納されたイーサネットフレームが適切であると判断し、クライアント情報を記憶部２５に保存すると、記憶部２５に保存したサーバ情報およびクライアント情報がそれぞれ示すサーバおよびクライアント間のセッションを確立することを決定する。
　そして、処理部２３は、当該セッションに用いるセッション鍵Ｋと、セッション鍵ＫのＩＤである鍵ＩＤとを生成し、生成したセッション鍵Ｋおよび鍵ＩＤを当該セッションに参加するサーバおよびクライアントへ配布する。また、処理部２３は、生成したセッション鍵Ｋおよび鍵ＩＤを、サービスＩＤに対応付けて記憶部２５に保存する。
　たとえば、処理部２３は、固有ＩＤを暗号鍵として用いてセッション鍵Ｋを暗号化する。また、たとえば、処理部２３は、固有ＩＤとセッション鍵Ｋとを用いてハッシュ値ＨＶを算出する。そして、処理部２３は、暗号化したセッション鍵Ｋおよびハッシュ値ＨＶを、セッション鍵Ｋの暗号化およびハッシュ値ＨＶの算出に用いた固有ＩＤを有する車載ＥＣＵ１１１へ中継部２２経由で送信する。
　より詳細には、処理部２３は、記憶部２５における接続先リストを参照し、サーバ情報が示すサーバの固有ＩＤを取得し、取得した固有ＩＤを暗号鍵として用いてセッション鍵Ｋを暗号化することにより、暗号化されたサーバ用のセッション鍵Ｋである暗号化鍵ＫＳを生成する。そして、処理部２３は、記憶部２５におけるイーサネットフレームに含まれるＳｕｂｓｃｒｉｂｅメッセージに暗号化鍵ＫＳおよび対応の鍵ＩＤを含め、当該Ｓｕｂｓｃｒｉｂｅメッセージとサーバの固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値ＨＶＳを算出する。処理部２３は、当該イーサネットフレームに、算出したハッシュ値ＨＶＳをさらに格納する。そして、処理部２３は、当該イーサネットフレームの中継処理を行うべき旨を示す中継指示を中継部２２へ出力する。
　中継部２２は、処理部２３から中継指示を受けた場合、中継指示が示すイーサネットフレームを記憶部２５から取得し、当該イーサネットフレームの中継処理を行う。具体的には、中継部２２は、暗号化鍵ＫＳ、鍵ＩＤおよびハッシュ値ＨＶＳが格納されたイーサネットフレームを、当該イーサネットフレームの宛先ＭＡＣアドレスに従ってサーバへ送信する。
　また、処理部２３は、記憶部２５における接続先リストを参照し、クライアント情報が示すクライアントの固有ＩＤを取得し、取得した固有ＩＤを暗号鍵として用いてセッション鍵Ｋを暗号化することにより、暗号化されたクライアント用のセッション鍵Ｋである暗号化鍵ＫＣを生成する。そして、処理部２３は、サーバのエンドポイント情報、暗号化鍵ＫＣおよび対応の鍵ＩＤを含む開始メッセージＭＣを生成し、生成した開始メッセージＭＣと取得した固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値ＨＶＣを算出する。処理部２３は、生成した開始メッセージＭＣおよび算出したハッシュ値ＨＶＣを含むクライアント宛のイーサネットフレームを生成し、生成したイーサネットフレームを中継部２２経由でクライアントへ送信する。
　処理部２３は、確立するセッションにおいて提供されるサービスのサービスＩＤ、Ｓｕｂｓｃｒｉｂｅメッセージの宛先であるサーバのＥＣＵ識別子、開始メッセージＭＣの宛先であるクライアントのＥＣＵ識別子、ならびにＳｕｂｓｃｒｉｂｅメッセージおよび開始メッセージＭＣの出力時刻ｔｓを示すセッション情報をログ生成部２４へ出力する。出力時刻ｔｓは、セッション鍵Ｋの中継部２２による送信時刻を示す。
　図９は、本開示の第１の実施の形態に係る中継装置における記憶部におけるセッションログリストの一例を示す図である。図９を参照して、記憶部２５は、確立するセッションにおいて提供されるサービスのサービスＩＤと、セッション鍵Ｋの配布先であるサーバおよびクライアントの各ＥＣＵ識別子と、セッションの開始時刻と、セッションの終了時刻とを示すセッションログのリストであるセッションログリストＲ２を記憶している。
　ログ生成部２４は、処理部２３からセッション情報を受けて、受けたセッション情報に含まれるサービスＩＤ、ＥＣＵ識別子および出力時刻ｔｓを、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ２に書き込む。
　（１－６）サーバによるセッション鍵の受信
　再び図５を参照して、サーバにおいて、処理部１２は、通信部１１経由で中継装置１０１からイーサネットフレームを受信し、受信したイーサネットフレームからＳｕｂｓｃｒｉｂｅメッセージおよびハッシュ値ＨＶＳを取得する。処理部１２は、中継装置１０１から受信したセッション鍵Ｋと自己の固有ＩＤとを用いて算出されるハッシュ値と、中継装置１０１から受信したハッシュ値ＨＶＳとを照合する。
　より詳細には、処理部１２は、記憶部１３から固有ＩＤを取得し、Ｓｕｂｓｃｒｉｂｅメッセージおよび固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値を算出する。処理部１２は、ハッシュ値ＨＶＳと、自己が算出したハッシュ値とを照合することにより、Ｓｕｂｓｃｒｉｂｅメッセージが改ざんされているか否かを判断する。
　処理部１２は、Ｓｕｂｓｃｒｉｂｅメッセージが改ざんされていると判断した場合、当該Ｓｕｂｓｃｒｉｂｅメッセージを破棄する。一方、処理部１２は、Ｓｕｂｓｃｒｉｂｅメッセージが改ざんされていないと判断した場合、当該Ｓｕｂｓｃｒｉｂｅメッセージから、クライアントのエンドポイント情報、暗号化鍵ＫＳおよび鍵ＩＤを取得する。そして、処理部１２は、固有ＩＤを用いて当該暗号化鍵ＫＳを復号することによりセッション鍵Ｋを取得する。
　処理部１２は、過去に取得したセッション鍵Ｋの鍵ＩＤが記憶部１３に保存されている場合、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとを比較する。処理部１２は、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとが異なることを確認すると、新たに取得したクライアントのエンドポイント情報、セッション鍵Ｋおよび鍵ＩＤを記憶部１３に保存する。
　一方、処理部１２は、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとが一致する場合、セッション鍵Ｋの再送信を要求する旨のメッセージを通信部１１経由で中継装置１０１へ送信する。中継装置１０１は、当該メッセージを受信した場合、新たなセッション鍵Ｋを生成してサーバおよびクライアントへ送信する。これにより、過去のセッションにおいて用いられたセッション鍵Ｋと同じセッション鍵Ｋがサーバおよびクライアントへ配布された場合、中継装置１０１にセッション鍵Ｋの再生成を促すことができるので、異なるセッションにおいて同じセッション鍵Ｋが用いられることによるセキュリティの低下を回避することができる。
　（１－７）クライアントによるセッション鍵の受信
　クライアントにおいて、処理部１２は、通信部１１経由で中継装置１０１からイーサネットフレームを受信し、受信したイーサネットフレームから開始メッセージＭＣおよびハッシュ値ＨＶＣを取得する。処理部１２は、中継装置１０１から受信したセッション鍵Ｋと自己の固有ＩＤとを用いて算出されるハッシュ値と、中継装置１０１から受信したハッシュ値ＨＶＣとを照合する。
　より詳細には、処理部１２は、記憶部１３から固有ＩＤを取得し、開始メッセージＭＣおよび固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値を算出する。処理部１２は、ハッシュ値ＨＶＣと、自己が算出したハッシュ値とを照合することにより、開始メッセージＭＣが改ざんされているか否かを判断する。
　処理部１２は、開始メッセージＭＣが改ざんされていると判断した場合、当該開始メッセージＭＣを破棄する。一方、処理部１２は、開始メッセージＭＣが改ざんされていないと判断した場合、当該開始メッセージＭＣから、サーバのエンドポイント情報、暗号化鍵ＫＣおよび鍵ＩＤを取得する。そして、処理部１２は、固有ＩＤを用いて当該暗号化鍵ＫＣを復号することによりセッション鍵Ｋを取得する。
　処理部１２は、過去に取得したセッション鍵Ｋの鍵ＩＤが記憶部１３に保存されている場合、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとを比較する。処理部１２は、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとが異なることを確認すると、新たに取得したサーバのエンドポイント情報、セッション鍵Ｋおよび鍵ＩＤを記憶部１３に保存する。
　一方、処理部１２は、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとが一致する場合、セッション鍵Ｋの再送信を要求する旨のメッセージを通信部１１経由で中継装置１０１へ送信する。中継装置１０１は、当該メッセージを受信した場合、新たなセッション鍵Ｋを生成してサーバおよびクライアントへ送信する。
　ここで、中継装置１０１において生成可能な、異なるセッション鍵Ｋの数は有限であるので、中継装置１０１は、あるセッション鍵Ｋの配布後、十分な時間を開けて当該セッション鍵Ｋと同じセッション鍵Ｋを配布する場合がある。そのため、サーバおよびクライアントにおける処理部１２は、記憶部１３に鍵ＩＤを保存してから十分な時間が経過した後、当該鍵ＩＤを記憶部１３から削除する。
　（２）Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙにおける処理例２
　（２－１）クライアントによるＦｉｎｄメッセージの送信
　クライアントである車載ＥＣＵ１１１において、処理部１２は、記憶部１３におけるサービスリストを参照し、提供を受けようとするサービスに対応するサービスＩＤを取得する。また、処理部１２は、記憶部１３からＥＣＵ識別子および当該車載ＥＣＵ１１１のエンドポイント情報を取得する。処理部１２は、取得したサービスＩＤ、ＥＣＵ識別子およびエンドポイント情報を含むＦｉｎｄメッセージを生成する。
　処理部１２は、生成したＦｉｎｄメッセージおよび記憶部１３における固有ＩＤに基づいてＭＡＣ値を算出する。処理部１２は、データフィールドに当該Ｆｉｎｄメッセージおよび当該ＭＡＣ値が格納され、かつ宛先ＭＡＣアドレスとしてマルチキャストアドレスが格納されたイーサネットフレームを生成する。処理部１２は、生成したイーサネットフレームを通信部１１へ出力する。
　通信部１１は、処理部１２から受けたイーサネットフレームを中継装置１０１へ送信する。
　（２－２）中継装置によるＦｉｎｄメッセージの適否の判定
　再び図６を参照して、中継装置１０１における中継部２２は、サーバから対応の通信ポート経由でイーサネットフレームを受信し、受信したイーサネットフレームにタイムスタンプを付し、イーサネットフレームを記憶部２５に保存する。
　処理部２３は、中継部２２により記憶部２５にイーサネットフレームが保存されると、当該イーサネットフレームのデータフィールドにＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれていることを確認し、ＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームはＦｉｎｄメッセージを含むと判断する。そして、処理部２３は、当該イーサネットフレームの適否を判断する。
　より詳細には、処理部２３は、当該イーサネットフレームからＦｉｎｄメッセージ、ＭＡＣ値およびタイムスタンプを取得する。また、処理部２３は、取得したＦｉｎｄメッセージからサービスＩＤ、車載ＥＣＵ１１１のエンドポイント情報およびＥＣＵ識別子を取得する。そして、処理部２３は、記憶部２５における接続先リストを参照し、Ｆｉｎｄメッセージから取得したサービスＩＤが示すサービスに関与し得るクライアントとして、Ｆｉｎｄメッセージから取得したエンドポイント情報およびＥＣＵ識別子により特定される車載ＥＣＵ１１１が接続先リストに登録されているか否かを確認する。
　一例として、処理部２３は、Ｆｉｎｄメッセージから取得したサービスＩＤ、エンドポイント情報およびＥＣＵ識別子が、それぞれ、「０ｘ０００１」、「ＣＣＣ」および「ＥＣＵ＿３」である場合、当該サービスＩＤが示すサービスに関与し得るクライアントとして、当該ＥＣＵ識別子および当該エンドポイント情報により特定される車載ＥＣＵ１１１が接続先リストに登録されていると判断する。
　また、処理部２３は、接続先リストを参照し、Ｆｉｎｄメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１の固有ＩＤを取得する。処理部２３は、Ｆｉｎｄメッセージおよび取得した固有ＩＤに基づいてＭＡＣ値を算出する。そして、処理部２３は、イーサネットフレームから取得したＭＡＣ値と、自己が算出したＭＡＣ値とを照合することにより、イーサネットフレームが改ざんされているか否かを判断する。
　処理部２３は、Ｆｉｎｄメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されており、かつイーサネットフレームが改ざんされていないと判断した場合、中継部２２により受信されたイーサネットフレームは適切であると判断する。一方、処理部２３は、Ｆｉｎｄメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されていない場合、またはイーサネットフレームが改ざんされていると判断した場合、中継部２２により受信されたイーサネットフレームは不適切であると判断する。
　処理部２３は、イーサネットフレームが適切であると判断した場合、Ｆｉｎｄメッセージから取得したＥＣＵ識別子およびエンドポイント情報をクライアント情報として記憶部２５に保存する。
　また、処理部２３は、中継部２２により受信されたイーサネットフレームが適切であると判断した場合、記憶部２５におけるイーサネットフレームに含まれるＦｉｎｄメッセージからＥＣＵ識別子およびエンドポイント情報を消去する。そして、処理部２３は、当該イーサネットフレームの中継処理を行うべき旨を示す中継指示を中継部２２へ出力する。
　中継部２２は、処理部２３から中継指示を受けた場合、中継指示が示すイーサネットフレームを記憶部２５から取得し、当該イーサネットフレームの中継処理を行う。
　一方、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、当該イーサネットフレームを破棄すべき旨を示す破棄指示を中継部２２へ出力する。
　中継部２２は、処理部２３から破棄指示を受けた場合、破棄指示が示すイーサネットフレームを破棄する。
　また、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、Ｆｉｎｄメッセージおよびタイムスタンプをログ生成部２４へ出力する。
　ログ生成部２４は、処理部２３からＦｉｎｄメッセージおよびタイムスタンプを受けて、受けたＦｉｎｄメッセージに含まれるＥＣＵ識別子を取得し、当該Ｆｉｎｄメッセージのバイト列、取得したＥＣＵ識別子および受信時刻を不正ログとして記憶部２５における不正ログリストＲ１に書き込む。
　（２－３）サーバによるＯｆｆｅｒメッセージの送信
　再び図５を参照して、サーバである車載ＥＣＵ１１１において、処理部１２は、通信部１１経由で中継装置１０１からイーサネットフレームを受信し、受信したイーサネットフレームから送信元ＭＡＣアドレスおよびＦｉｎｄメッセージを取得する。また、処理部１２は、取得したＦｉｎｄメッセージからサービスＩＤを取得する。
　処理部１２は、記憶部１３におけるサービスリストを参照し、取得したサービスＩＤが示すサービスの提供の可否を判断する。処理部１２は、当該サービスの提供が可能であると判断した場合、記憶部１３からＥＣＵ識別子および当該車載ＥＣＵ１１１のエンドポイント情報を取得し、当該サービスに対応するサービスＩＤ、取得したＥＣＵ識別子および取得したエンドポイント情報を含むＯｆｆｅｒメッセージを生成する。一方、処理部１２は、当該サービスの提供が不可能であると判断した場合、Ｏｆｆｅｒメッセージの生成を行わない。
　処理部１２は、生成したＯｆｆｅｒメッセージおよび記憶部１３における固有ＩＤに基づいてＭＡＣ値を算出する。処理部１２は、データフィールドに当該Ｏｆｆｅｒメッセージおよび当該ＭＡＣ値が格納され、かつ宛先ＭＡＣアドレスとしてＦｉｎｄメッセージの送信元のクライアントのＭＡＣアドレスが格納されたイーサネットフレームを生成する。処理部１２は、生成したイーサネットフレームを通信部１１へ出力する。
　通信部１１は、処理部１２から受けたイーサネットフレームを中継装置１０１へ送信する。
　（２－４）中継装置によるＯｆｆｅｒメッセージの適否の判断
　再び図６を参照して、中継装置１０１における中継部２２は、サーバから対応の通信ポート経由でイーサネットフレームを受信し、受信したイーサネットフレームにタイムスタンプを付し、イーサネットフレームを記憶部２５に保存する。
　処理部２３は、上述した「（１－２）中継装置によるＯｆｆｅｒメッセージの適否の判断」と同様にして、中継部２２により受信されたイーサネットフレームの適否を判断する。そして、処理部２３は、当該イーサネットフレームが適切であると判断した場合、記憶部２５へのサーバ情報の保存、および中継部２２への中継指示の出力を行う。
　中継部２２は、処理部２３から中継指示を受けた場合、中継指示が示すイーサネットフレームを記憶部２５から取得し、当該イーサネットフレームの中継処理を行う。
　（２－５）クライアントによるＳｕｂｓｃｒｉｂｅメッセージの送信
　再び図５を参照して、クライアントである車載ＥＣＵ１１１において、処理部１２は、上述した「（１－３）クライアントによるＳｕｂｓｃｒｉｂｅメッセージの送信」と同様にして、データフィールドにＳｕｂｓｃｒｉｂｅメッセージおよびＭＡＣ値が格納され、かつ宛先ＭＡＣアドレスとしてＯｆｆｅｒメッセージの送信元のサーバのＭＡＣアドレスが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを通信部１１経由で中継装置１０１へ送信する。
　（２－６）中継装置によるＳｕｂｓｃｒｉｂｅメッセージの適否の判断
　再び図６を参照して、中継装置１０１における中継部２２は、クライアントから対応の通信ポート経由でイーサネットフレームを受信し、受信したイーサネットフレームにタイムスタンプを付し、イーサネットフレームを記憶部２５に保存する。
　処理部２３は、上述した「（１－４）中継装置によるＳｕｂｓｃｒｉｂｅメッセージの適否の判断」と同様にして、中継部２２により受信されたイーサネットフレームの適否を判断する。そして、処理部２３は、当該イーサネットフレームが適切であると判断した場合、Ｓｕｂｓｃｒｉｂｅメッセージから取得したＥＣＵ識別子およびエンドポイント情報をクライアント情報として記憶部２５に保存する。
　（２－７）中継装置によるセッション鍵の生成および配布
　中継装置１０１における処理部２３は、上述した「（１－５）中継装置によるセッション鍵の生成および配布」と同様にして、サーバおよびクライアント間のセッションを確立することを決定し、当該セッションに用いるセッション鍵Ｋと、セッション鍵ＫのＩＤである鍵ＩＤとを生成し、生成したセッション鍵Ｋおよび鍵ＩＤを当該セッションに参加するサーバおよびクライアントへ配布する。
　（２－８）サーバおよびクライアントによるセッション鍵の受信
　再び図５を参照して、サーバにおいて、処理部１２は、上述した「（１－６）サーバによるセッション鍵の受信」と同様にして、中継装置１０１から受信したセッション鍵Ｋと自己の固有ＩＤとを用いて算出されるハッシュ値と、中継装置１０１から受信したハッシュ値ＨＶＳとを照合する。
　また、クライアントにおいて、処理部１２は、上述した「（１－７）クライアントによるセッション鍵の受信」と同様にして、中継装置１０１から受信したセッション鍵Ｋと自己の固有ＩＤとを用いて算出されるハッシュ値と、中継装置１０１から受信したハッシュ値ＨＶＣとを照合する。
　（セッションにおける通信）
　サーバおよびクライアントは、セッション鍵Ｋを取得すると、当該セッション鍵Ｋを用いた通信のセッションを開始する。
　具体的には、サーバにおいて、処理部１２は、サービスとして提供すべき情報が格納されたセッションメッセージを、記憶部１３におけるセッション鍵Ｋを用いて暗号化し、暗号化したセッションメッセージをイーサネットフレームに含めて通信部１１および中継装置１０１経由でクライアントへ送信する。
　また、クライアントにおいて、処理部１２は、中継装置１０１および通信部１１経由でサーバから受信したイーサネットフレームからセッションメッセージを取得し、取得したセッションメッセージを、記憶部１３におけるセッション鍵Ｋを用いて復号し、復号したセッションメッセージから情報を取得する。
　（既存セッションへの参加）
　たとえば、サーバにおける処理部１２は、あるクライアントとのセッションの開始後においても、定期的または不定期にＯｆｆｅｒメッセージをマルチキャストする。
　より詳細には、中継装置１０１における処理部２３は、サーバＳ１およびクライアントＣ１間のセッションの確立後において、中継部２２により他のクライアントＣ２からのＳｕｂｓｃｒｉｂｅメッセージが格納されたイーサネットフレームが受信され、当該イーサネットフレームが適切であると判断した場合、当該サーバＳ１およびクライアントＣ２間のセッションを確立することを決定する。すなわち、処理部２３は、たとえばサーバＳ１およびクライアントＣ１へセッション鍵Ｋ１を配布した後、サーバＳ１およびクライアントＣ２間のセッションを確立することを決定する。
　この場合、たとえば、処理部２３は、サーバＳ１およびクライアントＣ２間のセッションに用いるセッション鍵Ｋとして、サーバＳ１およびクライアントＣ１へ配布したセッション鍵Ｋ１とは異なるセッション鍵Ｋ２を生成し、生成したセッション鍵Ｋ２をサーバＳ１およびクライアントＣ２へ配布する。
　すなわち、処理部２３は、サーバとクライアントとの組み合わせごとに異なるセッション鍵Ｋを生成して配布する。
　（サーバからクライアントへのマルチキャスト）
　車載システム３０１では、サーバは、セッションメッセージをクライアントへユニキャストする構成に限定されない。サーバは、セッションメッセージを複数のクライアントへマルチキャストする構成であってもよい。
　たとえば、中継装置１０１における処理部２３は、Ｏｆｆｅｒメッセージ等の開始要求を含むと判断したイーサネットフレームの送信元の車載ＥＣＵ１１１と、Ｓｕｂｓｃｒｉｂｅメッセージ等の開始応答を含むと判断したイーサネットフレームの送信元の複数の車載ＥＣＵ１１１とが参加するセッションに用いるセッション鍵Ｋをセッションごとに生成する。より詳細には、処理部２３は、１つのサーバとのセッションにおける通信を行うクライアントの数が所定数となった場合、当該サーバおよび複数のクライアント間のセッションに用いるセッション鍵Ｋであるセッション鍵ＫＭを生成し、生成したセッション鍵ＫＭを当該サーバおよび当該複数のクライアントへ配布する。
　すなわち、処理部２３は、たとえば、サーバＳ１とクライアントＣ１，Ｃ２との間の２つのセッションをそれぞれ確立した状態において、サーバＳ１およびクライアントＣ３間のセッションを確立することを決定した場合、サーバＳ１およびクライアントＣ３間のセッションに用いるセッション鍵Ｋ３を生成してサーバＳ１およびクライアントＣ３へ配布する。さらに、処理部２３は、サーバＳ１およびクライアントＣ１，Ｃ２，Ｃ３間のセッションに用いるセッション鍵ＫＭと、サーバＳ１およびクライアントＣ１，Ｃ２，Ｃ３のエンドポイント情報に基づくマルチキャストアドレスとをさらに生成し、生成したセッション鍵ＫＭおよびマルチキャストアドレスをサーバＳ１およびクライアントＣ１，Ｃ２，Ｃ３へ配布する。
　サーバＳ１およびクライアントＣ１，Ｃ２，Ｃ３は、セッション鍵ＫＭおよびマルチキャストアドレスを取得すると、セッション鍵ＫＭおよびマルチキャストアドレスを用いた通信のセッションを開始する。
　図１０は、本開示の第１の実施の形態に係る車載システムにおけるサーバおよびクライアント間のセッションの一例を示す図である。図１０を参照して、サーバＳ１は、クライアントＣ１との間のセッションに用いるセッション鍵Ｋ１と、クライアントＣ２との間のセッションに用いるセッション鍵Ｋ２と、クライアントＣ３との間のセッションに用いるセッション鍵Ｋ３と、クライアントＣ１，Ｃ２，Ｃ３との間のセッションに用いるセッション鍵ＫＭとを有している。クライアントＣ１は、セッション鍵Ｋ１，ＫＭを有している。クライアントＣ２は、セッション鍵Ｋ２，ＫＭを有している。クライアントＣ３は、セッション鍵Ｋ３，ＫＭを有している。
　サーバＳ１において、処理部１２は、サービスとして提供すべき情報が格納されたセッションメッセージを、セッション鍵ＫＭを用いて暗号化し、暗号化したセッションメッセージをイーサネットフレームに含めてクライアントＣ１，Ｃ２，Ｃ３へマルチキャストする。
　たとえば、サーバＳ１は、クライアントＣ１，Ｃ２，Ｃ３へマルチキャストにより情報を送信している状態において、車載システム３０１における異常を検知した場合、複数のクライアントＣ１，Ｃ２，Ｃ３へユニキャストにより情報を送信する状態に切り替える。
　一例として、クライアントＣ１を乗っ取った不正機器が、サーバＳ１になりすまし、セッション鍵ＫＭを用いて暗号化されたセッションメッセージをイーサネットフレームに含めてサーバＳ１およびクライアントＣ２，Ｃ３へマルチキャストする場合を考える。
　サーバＳ１における処理部１２は、通信部１１経由で当該不正機器からセッションメッセージを受信した場合、自己がセッションメッセージの送信元であるにも関わらず自己がセッションメッセージを受信したことから、車載システム３０１において異常が発生したと判断する。
　この場合、サーバＳ１における処理部１２は、セッションメッセージの送信をマルチキャストからユニキャストへ切り替える。具体的には、処理部１２は、セッション鍵Ｋ１を用いて暗号化したセッションメッセージを通信部１１経由でクライアントＣ１へユニキャストし、セッション鍵Ｋ２を用いて暗号化したセッションメッセージを通信部１１経由でクライアントＣ２へユニキャストし、セッション鍵Ｋ３を用いて暗号化したセッションメッセージを通信部１１経由でクライアントＣ３へユニキャストする。
　（３）Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙにおける処理例３
　（３－１）クライアントによるＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージの送信
　再び図５を参照して、クライアントにおいて、処理部１２は、サービスの享受を停止する場合、当該サービスに対応するサービスＩＤ、ＥＣＵ識別子およびエンドポイント情報を含むＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを生成する。
　処理部１２は、生成したＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージおよび記憶部１３における固有ＩＤに基づいてＭＡＣ値を算出する。また、処理部１２は、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを、記憶部１３におけるセッション鍵Ｋを用いて暗号化する。そして、処理部１２は、データフィールドに暗号化したＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージおよび当該ＭＡＣ値が格納され、かつ宛先ＭＡＣアドレスとしてサーバのＭＡＣアドレスが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを通信部１１経由で中継装置１０１へ送信する。
　また、処理部１２は、記憶部１３におけるセッション鍵Ｋおよびサーバのエンドポイント情報を破棄する。
　（３－２）中継装置によるＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージの適否の判断
　再び図６を参照して、中継装置１０１における中継部２２は、クライアントから対応の通信ポート経由でイーサネットフレームを受信し、受信したイーサネットフレームにタイムスタンプを付し、イーサネットフレームを記憶部２５に保存する。
　処理部２３は、中継部２２により記憶部２５にイーサネットフレームが保存されると、当該イーサネットフレームのデータフィールドにＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれていることを確認し、ＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームはＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを含むと判断する。そして、処理部２３は、当該イーサネットフレームの適否を判断する。
　より詳細には、処理部２３は、当該イーサネットフレームからＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージ、ＭＡＣ値およびタイムスタンプを取得する。また、処理部２３は、取得したＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージからサービスＩＤ、車載ＥＣＵ１１１のエンドポイント情報およびＥＣＵ識別子を取得する。そして、処理部２３は、記憶部２５における接続先リストを参照し、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージから取得したサービスＩＤが示すサービスに関与し得るサーバとして、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージから取得したエンドポイント情報およびＥＣＵ識別子により特定される車載ＥＣＵ１１１が接続先リストに登録されているか否かを確認する。
　また、処理部２３は、接続先リストを参照し、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１の固有ＩＤを取得する。処理部２３は、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージおよび取得した固有ＩＤに基づいてＭＡＣ値を算出する。そして、処理部２３は、イーサネットフレームから取得したＭＡＣ値と、自己が算出したＭＡＣ値とを照合することにより、当該イーサネットフレームが改ざんされているか否かを判断する。
　処理部２３は、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されており、かつイーサネットフレームが改ざんされていないと判断した場合、中継部２２により受信されたイーサネットフレームは適切であると判断する。一方、処理部２３は、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されていない場合、またはイーサネットフレームが改ざんされていると判断した場合、中継部２２により受信されたイーサネットフレームは不適切であると判断する。
　処理部２３は、イーサネットフレームが適切であると判断した場合、記憶部２５における、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージに含まれるサービスＩＤに対応するセッション鍵Ｋおよび鍵ＩＤを破棄する。
　また、処理部２３は、イーサネットフレームが適切であると判断した場合、当該イーサネットフレームから取得したタイムスタンプが示す受信時刻ｔｅをログ生成部２４へ通知する。
　ログ生成部２４は、セッション情報として、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージの中継部２２による受信時刻を記録する。より詳細には、ログ生成部２４は、処理部２３から受信時刻ｔｅの通知を受けて、通知された受信時刻ｔｅをセッションログの「終了時刻」としてセッションログリストＲ２に書き込む。
　たとえば、中継部２２は、処理部２３によりＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを含むと判断されたイーサネットフレームであって、処理部２３により適切と判断されたイーサネットフレームについての中継処理を行う。
　より詳細には、処理部２３は、中継部２２により受信されたイーサネットフレームが適切であると判断した場合、記憶部２５におけるイーサネットフレームに含まれるＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージからＥＣＵ識別子およびエンドポイント情報を消去する。そして、処理部２３は、当該イーサネットフレームの中継処理を行うべき旨を示す中継指示を中継部２２へ出力する。
　中継部２２は、処理部２３から中継指示を受けた場合、中継指示が示すイーサネットフレームを記憶部２５から取得し、当該イーサネットフレームの中継処理を行う。
　一方、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、当該イーサネットフレームを破棄すべき旨を示す破棄指示を中継部２２へ出力する。
　中継部２２は、処理部２３から破棄指示を受けた場合、破棄指示が示すイーサネットフレームを破棄する。
　また、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージおよびタイムスタンプをログ生成部２４へ出力する。
　ログ生成部２４は、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージおよびタイムスタンプ受けて、受けたＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージに含まれるＥＣＵ識別子を取得し、当該ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージのバイト列、取得したＥＣＵ識別子および受信時刻を不正ログとして記憶部２５における不正ログリストＲ１に書き込む。
　（３－３）サーバによるＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージの受信
　再び図５を参照して、サーバにおいて、処理部１２は、通信部１１経由で中継装置１０１からイーサネットフレームを受信し、受信したイーサネットフレームからＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを取得する。処理部１２は、取得したＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを、記憶部１３におけるセッション鍵Ｋを用いて復号する。処理部１２は、記憶部１３におけるセッション鍵Ｋおよびクライアントのエンドポイント情報を破棄する。
　（４）Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙにおける処理例４
　（４－１）サーバによるＳｔｏｐＯｆｆｅｒメッセージの送信
　サーバにおいて、処理部１２は、サービスの提供を停止する場合、当該サービスに対応するサービスＩＤ、ＥＣＵ識別子およびエンドポイント情報を含むＳｔｏｐＯｆｆｅｒメッセージを生成する。
　処理部１２は、生成したＳｔｏｐＯｆｆｅｒメッセージおよび記憶部１３における固有ＩＤに基づいてＭＡＣ値を算出する。また、処理部１２は、ＳｔｏｐＯｆｆｅｒメッセージを、記憶部１３におけるセッション鍵Ｋを用いて暗号化する。そして、処理部１２は、データフィールドに暗号化したＳｔｏｐＯｆｆｅｒメッセージおよび当該ＭＡＣ値が格納され、かつ宛先ＭＡＣアドレスとしてクライアントのＭＡＣアドレスが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを通信部１１経由で中継装置１０１へ送信する。
　また、処理部１２は、記憶部１３におけるセッション鍵Ｋおよびクライアントのエンドポイント情報を破棄する。
　（４－２）中継装置によるＳｔｏｐＯｆｆｅｒメッセージの適否の判断
　再び図６を参照して、中継装置１０１における中継部２２は、サーバから対応の通信ポート経由でイーサネットフレームを受信し、受信したイーサネットフレームにタイムスタンプを付し、イーサネットフレームを記憶部２５に保存する。
　処理部２３は、中継部２２により記憶部２５にイーサネットフレームが保存されると、当該イーサネットフレームのデータフィールドにＳＯＭＥ／ＩＰ－ＳＤヘッダが含まれていることを確認し、ＳＯＭＥ／ＩＰ－ＳＤヘッダを参照することにより、当該イーサネットフレームはＳｔｏｐＯｆｆｅｒメッセージを含むと判断する。そして、処理部２３は、当該イーサネットフレームの適否を判断する。
　より詳細には、処理部２３は、当該イーサネットフレームからＳｔｏｐＯｆｆｅｒメッセージ、ＭＡＣ値およびタイムスタンプを取得する。また、処理部２３は、取得したＳｔｏｐＯｆｆｅｒメッセージからサービスＩＤ、車載ＥＣＵ１１１のエンドポイント情報およびＥＣＵ識別子を取得する。そして、処理部２３は、記憶部２５における接続先リストを参照し、ＳｔｏｐＯｆｆｅｒメッセージから取得したサービスＩＤが示すサービスに関与し得るクライアントとして、ＳｔｏｐＯｆｆｅｒメッセージから取得したエンドポイント情報およびＥＣＵ識別子により特定される車載ＥＣＵ１１１が接続先リストに登録されているか否かを確認する。
　また、処理部２３は、接続先リストを参照し、ＳｔｏｐＯｆｆｅｒメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１の固有ＩＤを取得する。処理部２３は、ＳｔｏｐＯｆｆｅｒメッセージおよび取得した固有ＩＤに基づいてＭＡＣ値を算出する。そして、処理部２３は、イーサネットフレームから取得したＭＡＣ値と、自己が算出したＭＡＣ値とを照合することにより、当該イーサネットフレームが改ざんされているか否かを判断する。
　処理部２３は、ＳｔｏｐＯｆｆｅｒメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されており、かつイーサネットフレームが改ざんされていないと判断した場合、中継部２２により受信されたイーサネットフレームは適切であると判断する。一方、処理部２３は、ＳｔｏｐＯｆｆｅｒメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されていない場合、またはイーサネットフレームが改ざんされていると判断した場合、中継部２２により受信されたイーサネットフレームは不適切であると判断する。
　処理部２３は、イーサネットフレームが適切であると判断した場合、記憶部２５における、ＳｔｏｐＯｆｆｅｒメッセージに含まれるサービスＩＤに対応するセッション鍵Ｋおよび鍵ＩＤを破棄する。
　また、処理部２３は、イーサネットフレームが適切であると判断した場合、当該イーサネットフレームから取得したタイムスタンプが示す受信時刻ｔｅをログ生成部２４へ通知する。
　ログ生成部２４は、セッション情報として、ＳｔｏｐＯｆｆｅｒメッセージの中継部２２による受信時刻を記録する。より詳細には、ログ生成部２４は、処理部２３から受信時刻ｔｅの通知を受けて、通知された受信時刻ｔｅをセッションログの「終了時刻」としてセッションログリストＲ２に書き込む。
　たとえば、中継部２２は、処理部２３によりＳｔｏｐＯｆｆｅｒメッセージを含むと判断されたイーサネットフレームであって、処理部２３により適切と判断されたイーサネットフレームについての中継処理を行う。
　より詳細には、処理部２３は、中継部２２により受信されたイーサネットフレームが適切であると判断した場合、記憶部２５におけるイーサネットフレームに含まれるＳｔｏｐＯｆｆｅｒメッセージからＥＣＵ識別子およびエンドポイント情報を消去する。そして、処理部２３は、当該イーサネットフレームの中継処理を行うべき旨を示す中継指示を中継部２２へ出力する。
　中継部２２は、処理部２３から中継指示を受けた場合、中継指示が示すイーサネットフレームを記憶部２５から取得し、当該イーサネットフレームの中継処理を行う。
　一方、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、当該イーサネットフレームを破棄すべき旨を示す破棄指示を中継部２２へ出力する。
　中継部２２は、処理部２３から破棄指示を受けた場合、破棄指示が示すイーサネットフレームを破棄する。
　また、処理部２３は、中継部２２により受信されたイーサネットフレームが不適切であると判断した場合、ＳｔｏｐＯｆｆｅｒメッセージおよびタイムスタンプをログ生成部２４へ出力する。
　ログ生成部２４は、ＳｔｏｐＯｆｆｅｒメッセージおよびタイムスタンプ受けて、受けたＳｔｏｐＯｆｆｅｒメッセージに含まれるＥＣＵ識別子を取得し、当該ＳｔｏｐＯｆｆｅｒメッセージのバイト列、取得したＥＣＵ識別子および受信時刻を不正ログとして記憶部２５における不正ログリストＲ１に書き込む。
　（４－３）クライアントよるＳｔｏｐＯｆｆｅｒメッセージの受信
　再び図５を参照して、クライアントにおいて、処理部１２は、通信部１１経由で中継装置１０１からイーサネットフレームを受信し、受信したイーサネットフレームからＳｔｏｐＯｆｆｅｒメッセージを取得する。処理部１２は、取得したＳｔｏｐＯｆｆｅｒメッセージを、記憶部１３におけるセッション鍵Ｋを用いて復号する。処理部１２は、記憶部１３におけるセッション鍵Ｋおよびサーバのエンドポイント情報を破棄する。
　［動作の流れ］
　本開示の実施の形態に係る車載システムにおける各装置は、メモリを含むコンピュータを備え、当該コンピュータにおけるＣＰＵ等の演算処理部は、以下のフローチャートおよびシーケンスの各ステップの一部または全部を含むプログラムを当該メモリから読み出して実行する。これら複数の装置のプログラムは、それぞれ、外部からインストールすることができる。これら複数の装置のプログラムは、それぞれ、記録媒体に格納された状態でまたは通信回線を介して流通する。
　図１１は、本開示の第１の実施の形態に係る中継装置がセッション鍵を配布する際の動作手順の一例を定めたフローチャートである。
　図１１を参照して、まず、中継装置１０１は、車載ＥＣＵ１１１からのイーサネットフレームを待ち受け（ステップＳ１０２でＮＯ）、イーサネットフレームを受信すると（ステップＳ１０２でＹＥＳ）、受信したイーサネットフレームがＳＯＭＥ／ＩＰ－ＳＤメッセージを含むことを判断する。たとえば、中継装置１０１は、受信したイーサネットフレームがＳＯＭＥ／ＩＰ－ＳＤメッセージを含むか否かを判断する（ステップＳ１０４）。
　次に、中継装置１０１は、受信したイーサネットフレームがＳＯＭＥ／ＩＰ－ＳＤメッセージを含まないと判断した場合（ステップＳ１０６でＮＯ）、当該イーサネットフレームの中継処理を行う（ステップＳ１０８）。
　次に、中継装置１０１は、車載ＥＣＵ１１１からの新たなイーサネットフレームを待ち受ける（ステップＳ１０２でＮＯ）。
　一方、中継装置１０１は、受信したイーサネットフレームがＳＯＭＥ／ＩＰ－ＳＤメッセージを含むと判断した場合（ステップＳ１０６でＹＥＳ）、当該イーサネットフレームの適否を判断する（ステップＳ１１０）。
　次に、中継装置１０１は、受信したイーサネットフレームが適切であると判断した場合（ステップＳ１１２でＹＥＳ）、当該イーサネットフレームの中継処理等を行う（ステップＳ１１４）。ステップＳ１１４の詳細については、後述する。
　次に、中継装置１０１は、車載ＥＣＵ１１１からの新たなイーサネットフレームを待ち受ける（ステップＳ１０２でＮＯ）。
　一方、中継装置１０１は、受信したイーサネットフレームが不適切であると判断した場合（ステップＳ１１２でＮＯ）、当該イーサネットフレームに含まれるメッセージのバイト列、当該メッセージに含まれるＥＣＵ識別子、および当該イーサネットフレームの受信時刻を不正ログとして不正ログリストＲ１に書き込む（ステップＳ１１６）。
　次に、中継装置１０１は、受信したイーサネットフレームを破棄し（ステップＳ１１８）、車載ＥＣＵ１１１からの新たなイーサネットフレームを待ち受ける（ステップＳ１０２でＮＯ）。
　図１２は、本開示の第１の実施の形態に係る中継装置がセッション鍵を配布する際の動作手順の一例を定めたフローチャートである。図１２は、図１１におけるステップＳ１１４の詳細を示している。
　図１２を参照して、まず、中継装置１０１は、受信したイーサネットフレームがＯｆｆｅｒメッセージまたはＦｉｎｄメッセージを含むと判断した場合（ステップＳ２０２でＹＥＳ）、サーバ情報またはクライアント情報を記憶部２５に保存する。より詳細には、中継装置１０１は、受信したイーサネットフレームがＯｆｆｅｒメッセージを含むと判断した場合、Ｏｆｆｅｒメッセージから取得したＥＣＵ識別子およびエンドポイント情報をサーバ情報として記憶部２５に保存する。一方、中継装置１０１は、受信したイーサネットフレームがＦｉｎｄメッセージを含むと判断した場合、Ｆｉｎｄメッセージから取得したＥＣＵ識別子およびエンドポイント情報をクライアント情報として記憶部２５に保存する（ステップＳ２０４）。
　次に、中継装置１０１は、受信したイーサネットフレームの中継処理を行う（ステップＳ２０６）。
　一方、中継装置１０１は、受信したイーサネットフレームがＳｕｂｓｃｒｉｂｅメッセージを含むと判断した場合（ステップＳ２０２でＮＯかつステップＳ２０８でＹＥＳ）、Ｓｕｂｓｃｒｉｂｅメッセージから取得したＥＣＵ識別子およびエンドポイント情報をクライアント情報として記憶部２５に保存する（ステップＳ２１０）。
　次に、中継装置１０１は、サーバおよびクライアント間のセッションを確立することを決定し、当該セッションに用いるセッション鍵Ｋを生成する（ステップＳ２１２）。
　次に、中継装置１０１は、生成したセッション鍵Ｋを当該セッションに参加するクライアントへ送信する。より詳細には、中継装置１０１は、暗号化鍵ＫＣを含む開始メッセージＭＣを生成し、生成した開始メッセージＭＣを含むイーサネットフレームをクライアントへ送信する（ステップＳ２１４）。
　次に、中継装置１０１は、受信したイーサネットフレームの中継処理を行う。より詳細には、中継装置１０１は、受信したイーサネットフレームに含まれるＳｕｂｓｃｒｉｂｅメッセージに暗号化鍵ＫＳを含めて、当該イーサネットフレームをサーバへ送信する（ステップＳ２１６）。
　次に、中継装置１０１は、確立するセッションにおいて提供されるサービスのサービスＩＤ、セッション鍵Ｋの宛先であるサーバおよびクライアントの各ＥＣＵ識別子、ならびにセッションの開始時刻を、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ２に書き込む（ステップＳ２１８）。
　一方、中継装置１０１は、受信したイーサネットフレームがＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージまたはＳｔｏｐＯｆｆｅｒメッセージを含むと判断した場合（ステップＳ２０２でＮＯかつステップＳ２０８でＮＯ）、当該イーサネットフレームの受信時刻ｔｅをセッションログの「終了時刻」としてセッションログリストＲ２に書き込む（ステップＳ２２０）。
　次に、中継装置１０１は、受信したイーサネットフレームの中継処理を行う（ステップＳ２２２）。
　図１３は、本開示の第１の実施の形態に係る車載システムにおける通信のシーケンスの一例を示す図である。図１３は、サーバＳ１およびクライアントＣ１，Ｃ２を備える車載システム３０１における通信のシーケンスを示している。
　図１３を参照して、まず、サーバＳ１は、データフィールドにＯｆｆｅｒメッセージが格納され、かつ宛先ＭＡＣアドレスとしてマルチキャストアドレスが格納されたイーサネットフレームを中継装置１０１へ送信する（ステップＳ３０２）。
　次に、中継装置１０１は、サーバＳ１から受信したイーサネットフレームがＯｆｆｅｒメッセージを含むと判断し、当該イーサネットフレームの適否を判断する。そして、中継装置１０１は、当該イーサネットフレームは適切であると判断し、当該イーサネットフレームの中継処理を行う（ステップＳ３０４）。
　次に、たとえば、クライアントＣ１は、中継装置１０１経由でサーバＳ１から受信したイーサネットフレームからＯｆｆｅｒメッセージを取得し、サーバＳ１により提供されるサービスが必要であると判断する。そして、クライアントＣ１は、データフィールドにＳｕｂｓｃｒｉｂｅメッセージが格納され、かつ宛先ＭＡＣアドレスとしてサーバＳ１のＭＡＣアドレスが格納されたイーサネットフレームを中継装置１０１へ送信する（ステップＳ３０６）。
　次に、中継装置１０１は、クライアントＣ１から受信したイーサネットフレームがＳｕｂｓｃｒｉｂｅメッセージを含むと判断し、当該イーサネットフレームの適否を判断する。そして、中継装置１０１は、当該イーサネットフレームは適切であると判断し、サーバＳ１およびクライアントＣ１間のセッションを確立することを決定し、当該セッションに用いるセッション鍵Ｋ１を生成する。また、このとき、中継装置１０１は、確立するセッションにおいて提供されるサービスのサービスＩＤ、サーバＳ１およびクライアントＣ１の各ＥＣＵ識別子、セッションの開始時刻を、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ２に書き込む（ステップＳ３０８）。
　次に、中継装置１０１は、クライアントＣ１から受信したイーサネットフレームに含まれるＳｕｂｓｃｒｉｂｅメッセージにセッション鍵Ｋ１を含めて、当該イーサネットフレームをサーバＳ１へ送信する（ステップＳ３１０）。
　また、中継装置１０１は、セッション鍵Ｋ１を含む開始メッセージＭＣを生成し、生成した開始メッセージＭＣを含むイーサネットフレームをクライアントＣ１へ送信する（ステップＳ３１２）。
　次に、サーバＳ１は、たとえば定期的に、セッション鍵Ｋ１を用いて暗号化されたセッションメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でクライアントＣ１へ送信する（ステップＳ３１４）。
　次に、たとえば、クライアントＣ２は、中継装置１０１経由でサーバＳ１から受信したイーサネットフレームからＯｆｆｅｒメッセージを取得し、サーバＳ１により提供されるサービスが必要であると判断する。そして、クライアントＣ２は、データフィールドにＳｕｂｓｃｒｉｂｅメッセージが格納され、かつ宛先ＭＡＣアドレスとしてサーバＳ１のＭＡＣアドレスが格納されたイーサネットフレームを中継装置１０１へ送信する（ステップＳ３１６）。
　次に、中継装置１０１は、クライアントＣ２から受信したイーサネットフレームがＳｕｂｓｃｒｉｂｅメッセージを含むと判断し、当該イーサネットフレームの適否を判断する。そして、中継装置１０１は、当該イーサネットフレームは適切であると判断し、サーバＳ１およびクライアントＣ２間のセッションを確立することを決定し、当該セッションに用いるセッション鍵Ｋ２を生成する。また、このとき、中継装置１０１は、確立するセッションにおいて提供されるサービスのサービスＩＤ、サーバＳ１およびクライアントＣ２の各ＥＣＵ識別子、ならびにセッションの開始時刻を、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ２に書き込む（ステップＳ３１８）。
　次に、中継装置１０１は、クライアントＣ２から受信したイーサネットフレームに含まれるＳｕｂｓｃｒｉｂｅメッセージにセッション鍵Ｋ２を含めて、当該イーサネットフレームをサーバＳ１へ送信する（ステップＳ３２０）。
　また、中継装置１０１は、セッション鍵Ｋ２を含む開始メッセージＭＣを生成し、生成した開始メッセージＭＣを含むイーサネットフレームをクライアントＣ２へ送信する（ステップＳ３２２）。
　次に、サーバＳ１は、たとえば定期的に、セッション鍵Ｋ１を用いて暗号化されたセッションメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でクライアントＣ１へ送信する（ステップＳ３２４）。
　また、サーバＳ１は、たとえば定期的に、セッション鍵Ｋ２を用いて暗号化されたセッションメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でクライアントＣ２へ送信する（ステップＳ３２６）。
　次に、たとえば、クライアントＣ１は、データフィールドにＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージが格納され、かつ宛先ＭＡＣアドレスとしてサーバＳ１のＭＡＣアドレスが格納されたイーサネットフレームを中継装置１０１へ送信する（ステップＳ３２８）。
　次に、中継装置１０１は、クライアントＣ１から受信したイーサネットフレームがＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを含むと判断し、当該イーサネットフレームの適否を判断する。そして、中継装置１０１は、当該イーサネットフレームは適切であると判断し、当該イーサネットフレームの中継処理を行う。また、このとき、中継装置１０１は、当該イーサネットフレームの受信時刻ｔｅをセッションログの「終了時刻」としてセッションログリストＲ２に書き込む（ステップＳ３３０）。
　次に、クライアントＣ１は、記憶部１３におけるセッション鍵Ｋ１およびサーバＳ１のエンドポイント情報を破棄する（ステップＳ３３２）。
　また、サーバＳ１は、記憶部１３におけるセッション鍵Ｋ１およびクライアントＣ１のエンドポイント情報を破棄する（ステップＳ３３４）。
　次に、サーバＳ１は、セッションメッセージが格納されたイーサネットフレームのクライアントＣ２への送信を継続する（ステップＳ３３６）。
　図１４は、本開示の第１の実施の形態に係る車載システムにおける通信のシーケンスの他の例を示す図である。図１４は、サーバＳ２，Ｓ３およびクライアントＣ１を備える車載システム３０１における通信のシーケンスを示している。
　図１４を参照して、まず、クライアントＣ１は、データフィールドにＦｉｎｄメッセージが格納され、かつ宛先ＭＡＣアドレスとしてマルチキャストアドレスが格納されたイーサネットフレームを中継装置１０１へ送信する（ステップＳ４０２）。
　次に、中継装置１０１は、クライアントＣ１から受信したイーサネットフレームがＦｉｎｄメッセージを含むと判断し、当該イーサネットフレームの適否を判断する。そして、中継装置１０１は、当該イーサネットフレームは適切であると判断し、当該イーサネットフレームの中継処理を行う（ステップＳ４０４）。
　次に、たとえば、サーバＳ２は、データフィールドにＯｆｆｅｒメッセージが格納され、かつ宛先ＭＡＣアドレスとしてクライアントＣ１のＭＡＣアドレスが格納されたイーサネットフレームを中継装置１０１へ送信する（ステップＳ４０６）。
　次に、中継装置１０１は、サーバＳ２から受信したイーサネットフレームがＯｆｆｅｒメッセージを含むと判断し、当該イーサネットフレームの適否を判断する。そして、中継装置１０１は、当該イーサネットフレームは適切であると判断し、当該イーサネットフレームの中継処理を行う（ステップＳ４０８）。
　次に、クライアントＣ１は、データフィールドにＳｕｂｓｃｒｉｂｅメッセージが格納され、かつ宛先ＭＡＣアドレスとしてサーバＳ２のＭＡＣアドレスが格納されたイーサネットフレームを中継装置１０１へ送信する（ステップＳ４１０）。
　次に、中継装置１０１は、クライアントＣ１から受信したイーサネットフレームがＳｕｂｓｃｒｉｂｅメッセージを含むと判断し、当該イーサネットフレームの適否を判断する。そして、中継装置１０１は、当該イーサネットフレームは適切であると判断し、サーバＳ２およびクライアントＣ１間のセッションを確立することを決定し、当該セッションに用いるセッション鍵Ｋ３を生成する。また、このとき、中継装置１０１は、確立するセッションにおいて提供されるサービスのサービスＩＤ、サーバＳ３およびクライアントＣ１の各ＥＣＵ識別子、セッションの開始時刻を、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ２に書き込む（ステップＳ４１２）。
　次に、中継装置１０１は、クライアントＣ１から受信したイーサネットフレームに含まれるＳｕｂｓｃｒｉｂｅメッセージにセッション鍵Ｋ３を含めて、当該イーサネットフレームをサーバＳ２へ送信する（ステップＳ４１４）。
　また、中継装置１０１は、セッション鍵Ｋ３を含む開始メッセージＭＣを生成し、生成した開始メッセージＭＣを含むイーサネットフレームをクライアントＣ１へ送信する（ステップＳ４１６）。
　次に、サーバＳ２は、たとえば定期的に、セッション鍵Ｋ３を用いて暗号化されたセッションメッセージが格納されたイーサネットフレームを生成し、生成したイーサネットフレームを中継装置１０１経由でクライアントＣ１へ送信する（ステップＳ４１８）。
　次に、たとえば、サーバＳ２は、データフィールドにＳｔｏｐＯｆｆｅｒメッセージが格納され、かつ宛先ＭＡＣアドレスとしてクライアントＣ１のＭＡＣアドレスが格納されたイーサネットフレームを中継装置１０１へ送信する（ステップＳ４２０）。
　次に、中継装置１０１は、サーバＳ２から受信したイーサネットフレームがＳｔｏｐＯｆｆｅｒメッセージを含むと判断し、当該イーサネットフレームの適否を判断する。そして、中継装置１０１は、当該イーサネットフレームは適切であると判断し、当該イーサネットフレームの中継処理を行う。また、このとき、中継装置１０１は、当該イーサネットフレームの受信時刻ｔｅをセッションログの「終了時刻」としてセッションログリストＲ２に書き込む（ステップＳ４２２）。
　次に、サーバＳ２は、記憶部１３におけるセッション鍵Ｋ３およびクライアントＣ１のエンドポイント情報を破棄する（ステップＳ４２４）。
　また、クライアントＣ１は、記憶部１３におけるセッション鍵Ｋ３およびサーバＳ１のエンドポイント情報を破棄する（ステップＳ４２６）。
　なお、本開示の第１の実施の形態に係る車載システム３０１では、サーバは、複数のクライアントへマルチキャストにより情報を送信している状態において、車載システム３０１における異常を検知した場合、複数のクライアントへユニキャストにより情報を送信する状態に切り替える構成であるとしたが、これに限定するものではない。サーバは、複数のクライアントへユニキャストにより情報を送信する状態に切り替えない構成であってもよい。また、サーバは、複数のクライアントへユニキャストにより情報を送信する一方で、マルチキャストにより情報を送信することができない構成であってもよい。
　また、本開示の第１の実施の形態に係る車載システム３０１では、中継装置１０１と、車載ＥＣＵ１１１とは、他の中継装置を介さずに接続される構成であるとしたが、これに限定するものではない。中継装置１０１と、車載ＥＣＵ１１１とは、他の中継装置を介して接続される構成であってもよい。この場合、たとえば、当該他の中継装置は、当該他の中継装置に接続された車載ＥＣＵ１１１から受信したすべてのイーサネットフレームを中継装置１０１へ中継する。
　また、本開示の第１の実施の形態に係る中継装置１０１では、処理部２３は、固有ＩＤを暗号鍵として用いて暗号化されたセッション鍵Ｋを、当該固有ＩＤを有する車載ＥＣＵ１１１へ中継部２２経由で送信する構成であるとしたが、これに限定するものではない。処理部２３は、暗号化されていないセッション鍵Ｋを車載ＥＣＵ１１１へ中継部２２経由で送信する構成であってもよい。
　また、本開示の第１の実施の形態に係る中継装置１０１では、処理部２３は、固有ＩＤとセッション鍵Ｋとを用いて算出したハッシュ値ＨＶを、当該固有ＩＤを有する車載ＥＣＵ１１１へ中継部２２経由で送信する構成であるとしたが、これに限定するものではない。処理部２３は、ハッシュ値ＨＶを車載ＥＣＵ１１１へ送信しない構成であってもよい。
　また、本開示の第１の実施の形態に係る中継装置１０１は、ログ生成部２４を備える構成であるとしたが、これに限定するものではない。中継装置１０１は、ログ生成部２４を備えない構成であってもよい。
　また、本開示の第１の実施の形態に係る中継装置１０１では、ログ生成部２４は、セッションの開始時刻および終了時刻をセッションログリストＲ２に書き込む構成であるとしたが、これに限定するものではない。ログ生成部２４は、セッションにおいて提供されるサービスのサービスＩＤ、セッションに参加するサーバのＥＣＵ識別子、およびセッションに参加するクライアントのＥＣＵ識別子をセッションログリストＲ２に書き込む一方で、セッションの開始時刻および終了時刻の少なくともいずれか一方をセッションログリストＲ２に書き込まない構成であってもよい。
　また、本開示の第１の実施の形態に係る中継装置１０１では、処理部２３は、中継部２２により受信されたイーサネットフレームがＳＯＭＥ／ＩＰ－ＳＤメッセージを含むと判断した場合、当該イーサネットフレームの適否を判断する構成であるとしたが、これに限定するものではない。処理部２３は、ＳＯＭＥ／ＩＰ－ＳＤメッセージを含むイーサネットフレームの適否の判断を行わない構成であってもよい。
　また、本開示の第１の実施の形態に係る中継装置１０１では、処理部２３は、セッションごとにランダムな内容のセッション鍵Ｋを生成する構成であるとしたが、これに限定するものではない。処理部２３は、セッションごとに規則的な内容のセッション鍵Ｋを生成する構成であってもよい。
　ところで、車載ネットワークにおけるセキュリティをより向上させることが可能な技術が望まれる。より詳細には、たとえばサービス指向型の通信を行う車載システムにおいて、車載ネットワークにおけるセキュリティをより向上させることが可能な技術が望まれる。
　これに対して、本開示の第１の実施の形態に係る中継装置１０１では、中継部２２は、複数の車載ＥＣＵ１１１からそれぞれ受信した複数のイーサネットフレームを、宛先の車載ＥＣＵ１１１へ送信する中継処理を行う。処理部２３は、中継部２２により受信された複数のイーサネットフレームが、開始要求を含むことおよび開始応答を含むことを判断する。処理部２３は、開始要求を含むと判断したイーサネットフレームの送信元の車載ＥＣＵ１１１と、開始応答を含むと判断したイーサネットフレームの送信元の１または複数の車載ＥＣＵ１１１とが参加するセッションに用いるセッション鍵Ｋをセッションごとに生成する。処理部２３は、生成したセッション鍵Ｋを、セッションに参加する各車載ＥＣＵ１１１へ中継部２２経由で送信する。
　このように、中継装置１０１において、受信したフレームが開始要求を含むこと、および受信したフレームが開始応答を含むことを判断し、開始要求を含むフレームの送信元の車載ＥＣＵ１１１と、開始応答を含むフレームの送信元の１または複数の車載ＥＣＵ１１１とが参加するセッションに用いるセッション鍵Ｋをセッションごとに生成して各車載ＥＣＵ１１１へ送信する構成により、車載ＥＣＵ１１１間においてセッションごとに個別のセッション鍵Ｋを用いた通信を行うことができるので、車載ＥＣＵ１１１間の通信のセキュリティを向上することができる。また、たとえば、開始要求の送信元の車載ＥＣＵ１１１および開始応答の送信元の車載ＥＣＵ１１１の認証を行った上で共通鍵の生成および送信を行うことにより、不正機器によるセッションへの参加を防止することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　また、中継装置１０１では、処理部２３が、１つのサーバとセッションにおける通信を行うクライアントの数が所定数となった場合、当該サーバおよび複数のクライアント間のセッションに用いるセッション鍵ＫＭを生成し、生成したセッション鍵ＫＭを当該サーバおよび当該複数のクライアントへ配布する構成により、当該サーバおよび当該複数のクライアントにおいて、セッション鍵ＫＭを用いたマルチキャスト通信を行うことができる。したがって、ＳＯＭＥ／ＩＰに従うメッセージの送受信が行われる車載ネットワークにおけるセキュリティを向上させることができる。
　また、中継装置１０１がセッション鍵Ｋを生成する構成により、中継装置１０１以外の管理装置が開始要求および開始応答を受信してセッション鍵Ｋの生成を行う構成と比べて、車載ＥＣＵ１１１間において既存の仕様に従って開始要求および開始応答のやり取りを行いながら、中継装置１０１においてセッション鍵Ｋを生成することができる。また、中継装置１０１以外の管理装置が開始要求および開始応答を受信してセッション鍵Ｋの生成を行う構成と比べて、ハードウェア構成を簡略化することができるとともに、開始要求を含むフレームおよび開始応答を含むフレームを中継装置から管理装置へ転送する必要がないので車載ネットワークにおける通信トラフィックを低減することができる。
　次に、本開示の他の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。
　〔第２の実施の形態〕
　本実施の形態は、第１の実施の形態に係る車載システム３０１と比べて、中継装置１０１とは別の装置である管理装置２０１がセッション鍵Ｋを生成する車載システム３０２に関する。以下で説明する内容以外は第１の実施の形態に係る車載システム３０１と同様である。
　＜車載システム＞
　図１５は、本開示の第２の実施の形態に係る車載システムの構成を示す図である。図１５を参照して、車載システム３０２は、車載システム３０１と比べて、中継装置１０１の代わりに中継装置１０２を備え、管理装置２０１をさらに備える。車載ＥＣＵ１１１および中継装置１０２は、車載装置の一例である。車載システム３０２は、車両１に搭載される。管理装置２０１は、車載システム３０２に用いられる。
　中継装置１０２は、ケーブル１４を介して管理装置２０１および各車載ＥＣＵ１１１と接続されている。管理装置２０１、車載ＥＣＵ１１１および中継装置１０２は、車載ネットワークを構成する。
　中継装置１０２は、たとえば、セントラルゲートウェイ（Ｃｅｎｔｒａｌ　Ｇａｔｅｗａｙ：ＣＧＷ）であり、管理装置２０１および車載ＥＣＵ１１１と通信を行うことが可能である。中継装置１０２は、たとえば、異なるケーブル１４に接続された複数の車載ＥＣＵ１１１間でやり取りされる情報、車載ＥＣＵ１１１と管理装置２０１との間でやり取りされる情報を中継する中継処理を行う。以下、車載ＥＣＵ１１１間の通信、および管理装置２０１と車載ＥＣＵ１１１との間の通信は、特に断りがない限り中継装置１０２経由で行われるものとする。
　（Ｏｆｆｅｒメッセージ）
　たとえば、ある車載ＥＣＵ１１１は、サーバとして、定期的または不定期に、自己が提供可能なサービスに対応するサービスＩＤを含むＯｆｆｅｒメッセージを管理装置２０１へ送信する。当該Ｏｆｆｅｒメッセージは、セッションの開始要求の一例である。
　管理装置２０１は、サーバからＯｆｆｅｒメッセージを受信し、受信したＯｆｆｅｒメッセージの適否を判断する。管理装置２０１は、受信したＯｆｆｅｒメッセージが不適切であると判断した場合、当該Ｏｆｆｅｒメッセージを破棄する。一方、管理装置２０１は、受信したＯｆｆｅｒメッセージが適切であると判断した場合、Ｏｆｆｅｒメッセージを複数の車載ＥＣＵ１１１へマルチキャストする。
　管理装置２０１からＯｆｆｅｒメッセージを受信した複数の車載ＥＣＵ１１１のうち、Ｏｆｆｅｒメッセージに含まれるサービスＩＤに対応するサービスを必要とする車載ＥＣＵ１１１は、クライアントとして、サービスを要求することを示すＳｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する。当該Ｓｕｂｓｃｒｉｂｅメッセージは、セッションの開始要求に対する開始応答の一例である。
　管理装置２０１は、クライアントからＳｕｂｓｃｒｉｂｅメッセージを受信した場合、サーバおよびクライアント間のセッションを確立することを決定する。そして、管理装置２０１は、当該セッションに用いる、当該セッションに固有のセッション鍵Ｋを生成する。すなわち、管理装置２０１は、当該セッションに用いるセッション鍵Ｋをセッションごとに生成する。セッション鍵Ｋは、共通鍵の一例であり、たとえば使用する暗号方式に従った鍵長の乱数である。たとえば、管理装置２０１は、セッションごとにランダムな内容のセッション鍵Ｋを生成する。管理装置２０１は、生成したセッション鍵Ｋをセッションに参加するサーバおよびクライアントへ送信する。
　（Ｆｉｎｄメッセージ）
　たとえば、ある車載ＥＣＵ１１１は、クライアントとして、定期的または不定期に、提供を受けようとするサービスに対応するサービスＩＤを含むＦｉｎｄメッセージを管理装置２０１へ送信する。当該Ｆｉｎｄメッセージは、セッションの探索要求の一例である。
　管理装置２０１は、クライアントからＦｉｎｄメッセージを受信し、受信したＦｉｎｄメッセージの適否を判断する。管理装置２０１は、受信したＦｉｎｄメッセージが不適切であると判断した場合、当該Ｆｉｎｄメッセージを破棄する。一方、管理装置２０１は、受信したＦｉｎｄメッセージが適切であると判断した場合、Ｆｉｎｄメッセージを複数の車載ＥＣＵ１１１へマルチキャストする。
　管理装置２０１からＦｉｎｄメッセージを受信した複数の車載ＥＣＵ１１１のうち、Ｆｉｎｄメッセージに含まれるサービスＩＤに対応するサービスを提供可能な車載ＥＣＵ１１１は、サーバとして、サービスの提供が可能であることを示すＯｆｆｅｒメッセージを管理装置２０１へ送信する。当該Ｏｆｆｅｒメッセージは、セッションの探索要求に対する開始要求の一例である。
　管理装置２０１は、サーバからＯｆｆｅｒメッセージを受信し、受信したＯｆｆｅｒメッセージの適否を判断する。管理装置２０１は、受信したＯｆｆｅｒメッセージが不適切であると判断した場合、当該Ｏｆｆｅｒメッセージを破棄する。一方、管理装置２０１は、受信したＯｆｆｅｒメッセージが適切であると判断した場合、Ｏｆｆｅｒメッセージをクライアントへ送信する。
　管理装置２０１からＯｆｆｅｒメッセージを受信したクライアントは、Ｓｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する。当該Ｓｕｂｓｃｒｉｂｅメッセージは、セッションの開始要求に対する開始応答の一例である。
　管理装置２０１は、クライアントからＳｕｂｓｃｒｉｂｅメッセージを受信した場合、サーバおよびクライアント間のセッションを確立することを決定する。そして、管理装置２０１は、当該セッションに用いる、当該セッションに固有のセッション鍵Ｋを生成する。管理装置２０１は、生成したセッション鍵Ｋをセッションに参加するサーバおよびクライアントへ送信する。
　＜車載ＥＣＵおよび管理装置における処理＞
　図１６は、本開示の第２の実施の形態に係る管理装置の構成を示す図である。図１６を参照して、管理装置２０１は、受信部３１と、送信部３２と、処理部３３と、ログ生成部３４と、記憶部３５とを備える。処理部３３は、生成部の一例である。ログ生成部３４は、記録部の一例である。受信部３１、送信部３２、処理部３３およびログ生成部３４は、たとえば、ＣＰＵおよびＤＳＰ等のプロセッサにより実現される。記憶部３５は、たとえば不揮発性メモリである。
　受信部３１は、セッションの開始要求および当該開始要求に対する開始応答を、複数の車載ＥＣＵ１１１からそれぞれ受信する。処理部３３は、受信部３１により受信された開始要求および開始応答に紐づくセッションに用いる、当該セッションに固有のセッション鍵Ｋを生成する。すなわち、処理部３３は、受信部３１により受信された開始要求の送信元の車載ＥＣＵ１１１、および受信部３１により受信された開始応答の送信元の車載ＥＣＵ１１１が参加するセッションに用いるセッション鍵Ｋを生成する。たとえば、処理部３３は、セッションごとにランダムな内容のセッション鍵Ｋを生成する。送信部３２は、処理部３３により生成されたセッション鍵Ｋを当該セッションに参加する各車載ＥＣＵ１１１へ送信する。ログ生成部３４は、処理部３３により生成されたセッション鍵Ｋが用いられるセッションに関するセッション情報を記録する。
　記憶部３５は、車載システム３０２における各車載ＥＣＵ１１１の固有ＩＤを記憶する。たとえば、記憶部３５は、図７に示す接続先リストを記憶する。
　（１）Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙにおける処理例１
　（１－１）サーバによるＯｆｆｅｒメッセージの送信
　再び図５を参照して、サーバである車載ＥＣＵ１１１において、処理部１２は、記憶部１３におけるサービスリストを参照し、自己が提供可能なサービスに対応するサービスＩＤを取得する。また、処理部１２は、記憶部１３からＥＣＵ識別子および自己の車載ＥＣＵ１１１のエンドポイント情報を取得する。処理部１２は、取得したサービスＩＤ、ＥＣＵ識別子およびエンドポイント情報を含むＯｆｆｅｒメッセージを生成する。
　処理部１２は、生成したＯｆｆｅｒメッセージおよび記憶部１３における固有ＩＤに基づいてＭＡＣ値を算出する。処理部１２は、生成したＯｆｆｅｒメッセージおよび算出したＭＡＣ値を通信部１１へ出力する。
　通信部１１は、処理部１２からＯｆｆｅｒメッセージおよびＭＡＣ値を受けて、受けたＯｆｆｅｒメッセージおよびＭＡＣ値を管理装置２０１へ送信する。
　（１－２）管理装置によるＯｆｆｅｒメッセージの適否の判断
　再び図１６を参照して、管理装置２０１における受信部３１は、サーバからＯｆｆｅｒメッセージおよびＭＡＣ値を受信する。受信部３１は、受信したＯｆｆｅｒメッセージにタイムスタンプを付し、ＯｆｆｅｒメッセージおよびＭＡＣ値を処理部３３へ出力する。
　処理部３３は、受信部３１からＯｆｆｅｒメッセージおよびＭＡＣ値を受けて、受けたＯｆｆｅｒメッセージの適否を判断する。
　より詳細には、処理部３３は、ＯｆｆｅｒメッセージからサービスＩＤ、車載ＥＣＵ１１１のエンドポイント情報およびＥＣＵ識別子を取得する。そして、処理部３３は、記憶部３５における接続先リストを参照し、Ｏｆｆｅｒメッセージから取得したサービスＩＤが示すサービスに関与し得るサーバとして、Ｏｆｆｅｒメッセージから取得したエンドポイント情報およびＥＣＵ識別子により特定される車載ＥＣＵ１１１が接続先リストに登録されているか否かを確認する。
　一例として、処理部３３は、Ｏｆｆｅｒメッセージから取得したサービスＩＤ、エンドポイント情報およびＥＣＵ識別子が、それぞれ、「０ｘ０００１」、「ＢＢＢ」および「ＥＣＵ＿２」である場合、当該サービスＩＤが示すサービスに関与し得るサーバとして、当該ＥＣＵ識別子および当該エンドポイント情報により特定される車載ＥＣＵ１１１が接続先リストに登録されていると判断する。
　また、処理部３３は、接続先リストを参照し、Ｏｆｆｅｒメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１の固有ＩＤを取得する。処理部３３は、Ｏｆｆｅｒメッセージおよび取得した固有ＩＤに基づいてＭＡＣ値を算出する。そして、処理部３３は、受信部３１から受けたＭＡＣ値と、自己が算出したＭＡＣ値とを照合することにより、Ｏｆｆｅｒメッセージが改ざんされているか否かを判断する。
　処理部３３は、Ｏｆｆｅｒメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されており、かつＯｆｆｅｒメッセージが改ざんされていないと判断した場合、受信部３１により受信されたＯｆｆｅｒメッセージは適切であると判断する。一方、処理部３３は、Ｏｆｆｅｒメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されていない場合、またはＯｆｆｅｒメッセージが改ざんされていると判断した場合、受信部３１により受信されたＯｆｆｅｒメッセージは不適切であると判断する。
　処理部３３は、受信部３１により受信されたＯｆｆｅｒメッセージが適切であると判断した場合、Ｏｆｆｅｒメッセージから取得したＥＣＵ識別子およびエンドポイント情報をサーバ情報として記憶部３５に保存する。また、処理部３３は、Ｏｆｆｅｒメッセージを送信部３２へ出力する。
　送信部３２は、処理部３３から受けたＯｆｆｅｒメッセージを複数のクライアントへマルチキャストする。たとえば、送信部３２は、記憶部３５における接続先リストを参照し、サービスＩＤが「０ｘ０００１」であるサービスを必要とし得る複数のクライアントへマルチキャストする。
　一方、処理部３３は、受信部３１により受信されたＯｆｆｅｒメッセージが不適切であると判断した場合、Ｏｆｆｅｒメッセージをログ生成部３４へ出力する。ログ生成部３４は、処理部３３により不適切であると判断されたメッセージに関する情報を記録する。
　記憶部３５は、処理部３３により不適切と判断されたメッセージのバイト列と、当該メッセージの送信元の車載ＥＣＵ１１１のＥＣＵ識別子と、当該メッセージの受信時刻とを示す不正ログのリストである不正ログリストＲ１１を記憶している。不正ログリストＲ１１は、図８に示す不正ログリストＲ１と同じ内容のリストである。
　ログ生成部３４は、処理部３３からＯｆｆｅｒメッセージを受けて、受けたＯｆｆｅｒメッセージに含まれるＥＣＵ識別子と、受信時刻を示すタイムスタンプとを取得し、当該Ｏｆｆｅｒメッセージのバイト列ならびに取得したＥＣＵ識別子および受信時刻を不正ログとして記憶部３５における不正ログリストＲ１１に書き込む。その後、ログ生成部３４は、Ｏｆｆｅｒメッセージを破棄する。
　（１－３）クライアントによるＳｕｂｓｃｒｉｂｅメッセージの送信
　再び図５を参照して、クライアントである車載ＥＣＵ１１１において、通信部１１は、管理装置２０１からＯｆｆｅｒメッセージを受信し、受信したＯｆｆｅｒメッセージを処理部１２へ出力する。
　処理部１２は、通信部１１からＯｆｆｅｒメッセージを受けて、受けたＯｆｆｅｒメッセージからサービスＩＤを取得する。処理部１２は、記憶部１３におけるサービスリストを参照し、取得したサービスＩＤが示すサービスの要否を判断する。処理部１２は、当該サービスが必要であると判断した場合、返信指示を通信部１１へ出力する。一方、処理部１２は、当該サービスが不要であると判断した場合、返信指示の出力を行わない。
　通信部１１は、処理部１２から返信指示を受けて、記憶部１３からＥＣＵ識別子、および自己の車載ＥＣＵ１１１のエンドポイント情報を取得する。そして、通信部１１は、ＥＣＵ識別子およびエンドポイント情報を含むＳｕｂｓｃｒｉｂｅメッセージを生成し、生成したＳｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する。
　（１－４）管理装置によるセッション確立の決定
　再び図１６を参照して、管理装置２０１における受信部３１は、クライアントからＳｕｂｓｃｒｉｂｅメッセージを受信し、受信したＳｕｂｓｃｒｉｂｅメッセージを処理部３３へ出力する。
　処理部３３は、受信部３１からＳｕｂｓｃｒｉｂｅメッセージを受けて、受けたＳｕｂｓｃｒｉｂｅメッセージからＥＣＵ識別子およびエンドポイント情報を取得する。処理部３３は、取得したＥＣＵ識別子およびエンドポイント情報をクライアント情報として記憶部３５に保存する。
　処理部３３は、記憶部３５に保存したサーバ情報およびクライアント情報がそれぞれ示すサーバおよびクライアント間のセッションを確立することを決定する。処理部３３は、セッションを確立することを決定した場合、セッション鍵Ｋを生成してサーバおよびクライアントへ配布する。
　たとえば、処理部３３は、送信部３２経由でＯｆｆｅｒメッセージをクライアントへ送信してから所定時間が経過するまでに、受信部３１経由でクライアントからＳｕｂｓｃｒｉｂｅメッセージを受信しなかった場合、サービスを必要とするクライアントが存在しなかった旨を示すメッセージを送信部３２経由でサーバへ送信する。
　（１－５）管理装置によるセッション鍵の配布
　処理部３３は、確立することを決定したセッションに用いるセッション鍵Ｋと、セッション鍵ＫのＩＤである鍵ＩＤとを生成し、生成したセッション鍵Ｋおよび鍵ＩＤを当該セッションに参加するサーバおよびクライアントへ配布する。
　たとえば、処理部３３は、固有ＩＤを暗号鍵として用いてセッション鍵Ｋを暗号化する。また、たとえば、処理部３３は、固有ＩＤとセッション鍵Ｋとを用いて算出されたハッシュ値ＨＶを算出する。
　より詳細には、処理部３３は、記憶部３５における接続先リストを参照し、サーバ情報が示すサーバの固有ＩＤを取得し、取得した固有ＩＤを暗号鍵として用いてセッション鍵Ｋを暗号化することにより、暗号化されたサーバ用のセッション鍵Ｋである暗号化鍵ＫＳを生成する。そして、処理部３３は、暗号化鍵ＫＳおよび対応の鍵ＩＤを、クライアントから受信したＳｕｂｓｃｒｉｂｅメッセージに含め、当該Ｓｕｂｓｃｒｉｂｅメッセージと取得した固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値ＨＶＳを算出する。なお、処理部３３は、サービスを必要とするクライアントが存在した旨を示す情報を当該Ｓｕｂｓｃｒｉｂｅメッセージにさらに含めてもよい。
　また、処理部３３は、記憶部３５における接続先リストを参照し、クライアント情報が示すクライアントの固有ＩＤを取得し、取得した固有ＩＤを暗号鍵として用いてセッション鍵Ｋを暗号化することにより、暗号化されたクライアント用のセッション鍵Ｋである暗号化鍵ＫＣを生成する。そして、処理部３３は、サーバのエンドポイント情報、暗号化鍵ＫＣおよび対応の鍵ＩＤを含む開始メッセージＭＣを生成し、生成した開始メッセージＭＣと取得した固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値ＨＶＣを算出する。なお、処理部３３は、サービスを提供可能なサーバが存在した旨を示す情報を開始メッセージＭＣに含めてもよい。
　処理部３３は、生成した開始メッセージＭＣおよびＳｕｂｓｃｒｉｂｅメッセージ、ならびに算出したハッシュ値ＨＶＳ，ＨＶＣを送信部３２へ出力する。
　送信部３２は、処理部３３から受けたＳｕｂｓｃｒｉｂｅメッセージを、暗号化鍵ＫＳの暗号化に用いた固有ＩＤを有するサーバへ送信する。また、送信部３２は、開始メッセージＭＣを、暗号化鍵ＫＣの暗号化に用いた固有ＩＤを有するクライアントへ送信する。また、送信部３２は、ハッシュ値ＨＶＳを当該サーバへ送信し、ハッシュ値ＨＶＣを当該クライアントへ送信する。
　処理部３３は、確立するセッションにおいて提供されるサービスのサービスＩＤ、Ｓｕｂｓｃｒｉｂｅメッセージの宛先であるサーバのＥＣＵ識別子、開始メッセージＭＣの宛先であるクライアントのＥＣＵ識別子、ならびにＳｕｂｓｃｒｉｂｅメッセージおよび開始メッセージＭＣの出力時刻ｔｓを示すセッション情報をログ生成部３４へ出力する。出力時刻ｔｓは、セッション鍵Ｋの送信部３２による送信時刻を示す。
　ログ生成部３４は、処理部３３により生成されたセッション鍵Ｋが用いられるセッションに関するセッション情報を記録する。
　記憶部３５は、確立するセッションにおいて提供されるサービスのサービスＩＤと、セッション鍵Ｋの配布先であるサーバおよびクライアントの各ＥＣＵ識別子と、セッションの開始時刻と、セッションの終了時刻とを示すセッションログのリストであるセッションログリストＲ１２を記憶している。セッションログリストＲ１２は、図９に示すセッションログリストＲ１２と同じ内容のリストである。
　ログ生成部３４は、処理部３３からセッション情報を受けて、受けたセッション情報に含まれるサービスＩＤ、ＥＣＵ識別子および出力時刻ｔｓを、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ１２に書き込む。
　再び図５を参照して、サーバにおいて、通信部１１は、管理装置２０１からＳｕｂｓｃｒｉｂｅメッセージおよびハッシュ値ＨＶＳを受信して処理部１２へ出力する。処理部１２は、通信部１１により受信された管理装置２０１からのセッション鍵Ｋと自己の固有ＩＤとを用いて算出されるハッシュ値と、通信部１１により受信された管理装置２０１からのハッシュ値ＨＶＳとを照合する。
　より詳細には、処理部１２は、通信部１１からＳｕｂｓｃｒｉｂｅメッセージおよびハッシュ値ＨＶＳを受けて、記憶部１３から固有ＩＤを取得し、受けたＳｕｂｓｃｒｉｂｅメッセージおよび取得した固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値を算出する。処理部１２は、ハッシュ値ＨＶＳと、自己が算出したハッシュ値とを照合することにより、Ｓｕｂｓｃｒｉｂｅメッセージが改ざんされているか否かを判断する。
　処理部１２は、Ｓｕｂｓｃｒｉｂｅメッセージが改ざんされていると判断した場合、当該Ｓｕｂｓｃｒｉｂｅメッセージを破棄する。一方、処理部１２は、Ｓｕｂｓｃｒｉｂｅメッセージが改ざんされていないと判断した場合、当該Ｓｕｂｓｃｒｉｂｅメッセージから、クライアントのエンドポイント情報、暗号化鍵ＫＳおよび鍵ＩＤを取得する。そして、処理部１２は、固有ＩＤを用いて当該暗号化鍵ＫＳを復号することによりセッション鍵Ｋを取得する。
　処理部１２は、過去に取得したセッション鍵Ｋの鍵ＩＤが記憶部１３に保存されている場合、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとを比較する。処理部１２は、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとが異なることを確認すると、新たに取得したクライアントのエンドポイント情報、セッション鍵Ｋおよび鍵ＩＤを記憶部１３に保存する。
　一方、処理部１２は、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとが一致する場合、セッション鍵Ｋの再送信を要求する旨のメッセージを通信部１１経由で管理装置２０１へ送信する。管理装置２０１は、当該メッセージを受信した場合、新たなセッション鍵Ｋを生成してサーバおよびクライアントへ送信する。これにより、過去のセッションにおいて用いられたセッション鍵Ｋと同じセッション鍵Ｋがサーバおよびクライアントへ配布された場合、管理装置２０１にセッション鍵Ｋの再生成を促すことができるので、異なるセッションにおいて同じセッション鍵Ｋが用いられることによるセキュリティの低下を回避することができる。
　また、クライアントにおいて、通信部１１は、管理装置２０１から開始メッセージＭＣおよびハッシュ値ＨＶＣを受信して処理部１２へ出力する。処理部１２は、通信部１１により受信された管理装置２０１からのセッション鍵Ｋと自己の固有ＩＤとを用いて算出されるハッシュ値と、通信部１１により管理装置２０１から受信されたハッシュ値ＨＶＣとを照合する。
　より詳細には、処理部１２は、通信部１１から開始メッセージＭＣおよびハッシュ値ＨＶＣを受けて、記憶部１３から固有ＩＤを取得し、受けた開始メッセージＭＣおよび取得した固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値を算出する。処理部１２は、ハッシュ値ＨＶＣと、自己が算出したハッシュ値とを照合することにより、開始メッセージＭＣが改ざんされているか否かを判断する。
　処理部１２は、開始メッセージＭＣが改ざんされていると判断した場合、当該開始メッセージＭＣを破棄する。一方、処理部１２は、開始メッセージＭＣが改ざんされていないと判断した場合、当該開始メッセージＭＣから、サーバのエンドポイント情報、暗号化鍵ＫＣおよび鍵ＩＤを取得する。そして、処理部１２は、固有ＩＤを用いて当該暗号化鍵ＫＣを復号することによりセッション鍵Ｋを取得する。
　処理部１２は、過去に取得したセッション鍵Ｋの鍵ＩＤが記憶部１３に保存されている場合、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとを比較する。処理部１２は、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとが異なることを確認すると、新たに取得したサーバのエンドポイント情報、セッション鍵Ｋおよび鍵ＩＤを記憶部１３に保存する。
　一方、処理部１２は、記憶部１３における鍵ＩＤと、新たに取得した鍵ＩＤとが一致する場合、セッション鍵Ｋの再送信を要求する旨のメッセージを通信部１１経由で管理装置２０１へ送信する。管理装置２０１は、当該メッセージを受信した場合、新たなセッション鍵Ｋを生成してサーバおよびクライアントへ送信する。
　ここで、管理装置２０１において生成可能な、異なるセッション鍵Ｋの数は有限であるので、管理装置２０１は、あるセッション鍵Ｋの配布後、十分な時間を開けて当該セッション鍵Ｋと同じセッション鍵Ｋを配布する場合がある。そのため、サーバおよびクライアントにおける処理部１２は、記憶部１３に鍵ＩＤを保存してから十分な時間が経過した後、当該鍵ＩＤを記憶部１３から削除する。
　（２）Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙにおける処理例２
　（２－１）クライアントによるＦｉｎｄメッセージの送信
　再び図５を参照して、クライアントである車載ＥＣＵ１１１において、処理部１２は、記憶部１３におけるサービスリストを参照し、自己が提供を受けようとするサービスに対応するサービスＩＤを取得する。また、処理部１２は、記憶部１３からＥＣＵ識別子および自己の車載ＥＣＵ１１１のエンドポイント情報を取得する。処理部１２は、取得したサービスＩＤ、ＥＣＵ識別子およびエンドポイント情報を含むＦｉｎｄメッセージを生成する。
　処理部１２は、生成したＦｉｎｄメッセージおよび記憶部１３における固有ＩＤに基づいてＭＡＣ値を算出する。処理部１２は、生成したＦｉｎｄメッセージおよび算出したＭＡＣ値を通信部１１へ出力する。
　通信部１１は、処理部１２からＦｉｎｄメッセージおよびＭＡＣ値を受けて、受けたＦｉｎｄメッセージおよびＭＡＣ値を管理装置２０１へ送信する。
　（２－２）管理装置によるＦｉｎｄメッセージの適否の判定
　再び図１６を参照して、管理装置２０１における受信部３１は、クライアントからＦｉｎｄメッセージおよびＭＡＣ値を受信する。受信部３１は、受信したＦｉｎｄメッセージにタイムスタンプを付し、ＦｉｎｄメッセージおよびＭＡＣ値を処理部３３へ出力する。
　処理部３３は、受信部３１からＦｉｎｄメッセージおよびＭＡＣ値を受けて、受けたＦｉｎｄメッセージの適否を判断する。
　より詳細には、処理部３３は、ＦｉｎｄメッセージからサービスＩＤ、車載ＥＣＵ１１１のエンドポイント情報およびＥＣＵ識別子を取得する。そして、処理部３３は、記憶部３５における接続先リストを参照し、Ｆｉｎｄメッセージから取得したサービスＩＤが示すサービスに関与し得るクライアントとして、Ｆｉｎｄメッセージから取得したエンドポイント情報およびＥＣＵ識別子により特定される車載ＥＣＵ１１１が接続先リストに登録されているか否かを確認する。
　一例として、処理部３３は、Ｆｉｎｄメッセージから取得したサービスＩＤ、エンドポイント情報およびＥＣＵ識別子が、それぞれ、「０ｘ０００１」、「ＣＣＣ」および「ＥＣＵ＿３」である場合、当該サービスＩＤが示すサービスに関与し得るクライアントとして、当該ＥＣＵ識別子および当該エンドポイント情報により特定される車載ＥＣＵ１１１が接続先リストに登録されていると判断する。
　また、処理部３３は、接続先リストを参照し、Ｆｉｎｄメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１の固有ＩＤを取得する。処理部３３は、Ｆｉｎｄメッセージおよび取得した固有ＩＤに基づいてＭＡＣ値を算出する。そして、処理部３３は、受信部３１から受けたＭＡＣ値と、自己が算出したＭＡＣ値とを照合することにより、Ｆｉｎｄメッセージが改ざんされているか否かを判断する。
　処理部３３は、Ｆｉｎｄメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されており、かつＦｉｎｄメッセージが改ざんされていないと判断した場合、受信部３１により受信されたＦｉｎｄメッセージは適切であると判断する。一方、処理部３３は、Ｆｉｎｄメッセージから取得したエンドポイント情報等により特定される車載ＥＣＵ１１１が接続先リストに登録されていない場合、またはＦｉｎｄメッセージが改ざんされていると判断した場合、受信部３１により受信されたＦｉｎｄメッセージは不適切であると判断する。
　処理部３３は、受信部３１により受信されたＦｉｎｄメッセージが適切であると判断した場合、Ｆｉｎｄメッセージから取得したＥＣＵ識別子およびエンドポイント情報をクライアント情報として記憶部３５に保存する。また、処理部３３は、Ｆｉｎｄメッセージを送信部３２へ出力する。
　送信部３２は、処理部３３から受けたＦｉｎｄメッセージを複数のサーバへマルチキャストする。たとえば、送信部３２は、記憶部３５における接続先リストを参照し、サービスＩＤが「０ｘ０００１」であるサービスを提供し得る複数のサーバへマルチキャストする。
　一方、処理部３３は、受信部３１により受信されたＦｉｎｄメッセージが不適切であると判断した場合、Ｆｉｎｄメッセージをログ生成部３４へ出力する。
　ログ生成部３４は、処理部３３からＦｉｎｄメッセージを受けて、受けたＦｉｎｄメッセージに含まれるＥＣＵ識別子と、受信時刻を示すタイムスタンプとを取得し、当該Ｆｉｎｄメッセージのバイト列ならびに取得したＥＣＵ識別子および受信時刻を不正ログとして記憶部３５における不正ログリストＲ１１に書き込む。その後、ログ生成部３４は、Ｆｉｎｄメッセージを破棄する。
　（２－３）サーバによるＯｆｆｅｒメッセージの送信
　再び図５を参照して、サーバである車載ＥＣＵ１１１において、通信部１１は、管理装置２０１からＦｉｎｄメッセージを受信し、受信したＦｉｎｄメッセージを処理部１２へ出力する。
　処理部１２は、通信部１１からＦｉｎｄメッセージを受けて、受けたＦｉｎｄメッセージからサービスＩＤを取得する。処理部１２は、記憶部１３におけるサービスリストを参照し、取得したサービスＩＤが示すサービスの提供の可否を判断する。処理部１２は、当該サービスの提供が可能であると判断した場合、返信指示を通信部１１へ出力する。一方、処理部１２は、当該サービスの提供が不可能であると判断した場合、返信指示の出力を行わない。
　通信部１１は、処理部１２から返信指示を受けて、記憶部１３からＥＣＵ識別子、および自己の車載ＥＣＵ１１１のエンドポイント情報を取得する。そして、通信部１１は、ＥＣＵ識別子およびエンドポイント情報を含むＯｆｆｅｒメッセージを生成し、生成したＯｆｆｅｒメッセージを管理装置２０１へ送信する。
　（２－４）管理装置によるＯｆｆｅｒメッセージの適否の判断
　管理装置２０１は、上述した「（１－２）管理装置によるＯｆｆｅｒメッセージの適否の判断」と同様にして、サーバから受信したＯｆｆｅｒメッセージの適否を判断する。そして、管理装置２０１は、当該Ｏｆｆｅｒメッセージが適切であると判断した場合、当該Ｏｆｆｅｒメッセージをクライアントへ送信する。
　（２－５）クライアントによるＳｕｂｓｃｒｉｂｅメッセージの送信
　再び図５を参照して、クライアントである車載ＥＣＵ１１１は、上述した「（１－３）クライアントによるＳｕｂｓｃｒｉｂｅメッセージの送信」と同様にして、Ｓｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する。
　（２－６）管理装置によるセッション確立の決定
　管理装置２０１は、上述した「（１－４）管理装置によるセッション確立の決定」と同様にして、セッションを確立することを決定し、セッション鍵Ｋを生成してサーバおよびクライアントへ配布する。
　（２－７）管理装置によるセッション鍵の配布
　管理装置２０１は、上述した「（１－５）管理装置によるセッション鍵の配布」と同様にして、セッション鍵Ｋおよび鍵ＩＤを当該セッションに参加するサーバおよびクライアントへ配布する。
　また、サーバおよびクライアントは、上述した「（１－５）管理装置によるセッション鍵の配布」と同様にして、セッション鍵Ｋを取得する。
　（セッションにおける通信）
　サーバおよびクライアントは、セッション鍵Ｋを用いた通信のセッションを開始する。
　具体的には、サーバにおいて、処理部１２は、サービスとして提供すべき情報が格納されたセッションメッセージを、記憶部１３におけるセッション鍵Ｋを用いて暗号化し、暗号化したセッションメッセージを通信部１１へ出力する。通信部１１は、処理部１２から受けたセッションメッセージを、記憶部１３におけるエンドポイント情報が示すクライアントへユニキャストする。
　また、クライアントにおいて、処理部１２は、通信部１１経由でサーバから受信したセッションメッセージを、記憶部１３におけるセッション鍵Ｋを用いて復号し、復号したセッションメッセージから情報を取得する。
　（既存セッションへの参加）
　たとえば、サーバにおける処理部１２は、あるクライアントとのセッションの開始後においても、定期的または不定期にＯｆｆｅｒメッセージを通信部１１経由で管理装置２０１へ送信する。
　管理装置２０１における処理部３３は、サーバおよびクライアント間のセッションの確立後において、当該サーバのＯｆｆｅｒメッセージに対する他のクライアントからのＳｕｂｓｃｒｉｂｅメッセージを受信部３１経由で受信した場合、当該サーバおよび当該他のクライアント間のセッションを確立することを決定する。
　すなわち、処理部３３は、たとえばサーバＳ１およびクライアントＣ１へセッション鍵Ｋ１を配布した後、サーバＳ１のＯｆｆｅｒメッセージに対するクライアントＣ２からのＳｕｂｓｃｒｉｂｅメッセージを受信部３１経由で受信した場合、サーバＳ１およびクライアントＣ２間のセッションを確立することを決定する。
　この場合、たとえば、処理部３３は、サーバＳ１およびクライアントＣ２間のセッションに用いるセッション鍵Ｋとして、サーバＳ１およびクライアントＣ１へ配布したセッション鍵Ｋ１とは異なるセッション鍵Ｋ２を生成し、生成したセッション鍵Ｋ２をサーバＳ１およびクライアントＣ２へ配布する。
　すなわち、処理部３３は、サーバとクライアントとの組み合わせごとに異なるセッション鍵Ｋを生成して配布する。
　（サーバからクライアントへのマルチキャスト）
　車載システム３０２では、サーバは、セッションメッセージをクライアントへユニキャストする構成に限定されない。サーバは、セッションメッセージを複数のクライアントへマルチキャストする構成であってもよい。
　より詳細には、管理装置２０１における処理部３３は、１つのサーバとのセッションにおける通信を行うクライアントの数が所定数となった場合、当該サーバおよび複数のクライアント間のセッションに用いるセッション鍵Ｋであるセッション鍵ＫＭを生成し、生成したセッション鍵ＫＭを当該サーバおよび当該複数のクライアントへ配布する。
　すなわち、処理部３３は、たとえば、サーバＳ１とクライアントＣ１，Ｃ２との間の２つのセッションをそれぞれ確立した状態において、サーバＳ１のＯｆｆｅｒメッセージに対するクライアントＣ３からのＳｕｂｓｃｒｉｂｅメッセージを受信部３１経由で受信した場合、サーバＳ１およびクライアントＣ３間のセッションに用いるセッション鍵Ｋ３を生成してサーバＳ１およびクライアントＣ３へ配布する。さらに、処理部３３は、サーバＳ１およびクライアントＣ１，Ｃ２，Ｃ３間のセッションに用いるセッション鍵ＫＭと、サーバＳ１およびクライアントＣ１，Ｃ２，Ｃ３のエンドポイント情報に基づくマルチキャストアドレスとをさらに生成し、生成したセッション鍵ＫＭおよびマルチキャストアドレスをサーバＳ１およびクライアントＣ１，Ｃ２，Ｃ３へ配布する。
　サーバＳ１およびクライアントＣ１，Ｃ２，Ｃ３は、セッション鍵ＫＭおよびマルチキャストアドレスを取得すると、セッション鍵ＫＭおよびマルチキャストアドレスを用いた通信のセッションを開始する。
　再び図７を参照して、サーバＳ１は、クライアントＣ１との間のセッションに用いるセッション鍵Ｋ１と、クライアントＣ２との間のセッションに用いるセッション鍵Ｋ２と、クライアントＣ３との間のセッションに用いるセッション鍵Ｋ３と、クライアントＣ１，Ｃ２，Ｃ３との間のセッションに用いるセッション鍵ＫＭとを有している。クライアントＣ１は、セッション鍵Ｋ１，ＫＭを備えている。クライアントＣ２は、セッション鍵Ｋ２，ＫＭを有している。クライアントＣ３は、セッション鍵Ｋ３，ＫＭを有している。
　サーバＳ１において、処理部１２は、サービスとして提供すべき情報が格納されたセッションメッセージを、セッション鍵ＫＭを用いて暗号化し、暗号化したセッションメッセージを通信部１１経由でクライアントＣ１，Ｃ２，Ｃ３へマルチキャストする。
　たとえば、サーバＳ１は、クライアントＣ１，Ｃ２，Ｃ３へマルチキャストにより情報を送信している状態において、車載システム３０２における異常を検知した場合、複数のクライアントＣ１，Ｃ２，Ｃ３へユニキャストにより情報を送信する状態に切り替える。
　一例として、クライアントＣ１を乗っ取った不正機器が、サーバＳ１になりすまし、セッション鍵ＫＭを用いて暗号化されたセッションメッセージをサーバＳ１およびクライアントＣ２，Ｃ３へマルチキャストする場合を考える。
　サーバＳ１における処理部１２は、通信部１１経由で当該不正機器からセッションメッセージを受信した場合、自己がセッションメッセージの送信元であるにも関わらず自己がセッションメッセージを受信したことから、車載システム３０２において異常が発生したと判断する。
　この場合、サーバＳ１における処理部１２は、セッションメッセージの送信をマルチキャストからユニキャストへ切り替える。具体的には、処理部１２は、セッション鍵Ｋ１を用いて暗号化したセッションメッセージを通信部１１経由でクライアントＣ１へユニキャストし、セッション鍵Ｋ２を用いて暗号化したセッションメッセージを通信部１１経由でクライアントＣ２へユニキャストし、セッション鍵Ｋ３を用いて暗号化したセッションメッセージを通信部１１経由でクライアントＣ３へユニキャストする。
　（クライアント側からのセッションの終了）
　クライアントにおいて、処理部１２は、サービスの提供を受けることを停止する場合、サービスＩＤを含むＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを、記憶部１３におけるセッション鍵Ｋを用いて暗号化して通信部１１経由で管理装置２０１へ送信する。また、処理部１２は、記憶部１３におけるセッション鍵Ｋおよびサーバのエンドポイント情報を破棄する。
　再び図１６を参照して、管理装置２０１において、受信部３１は、クライアントからＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを受信する。受信部３１は、受信したＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージにタイムスタンプを付して処理部３３へ出力する。受信部３１により受信されるクライアントからのＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージは、終了要求の一例である。
　処理部３３は、受信部３１からＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを受けて、受けたＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを送信部３２へ出力する。また、処理部３３は、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージに付されたタイムスタンプが示す受信時刻ｔｅをログ生成部３４へ通知する。
　送信部３２は、受信部３１によるＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージの受信に基づいて、セッションを終了させるＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージをセッションに参加している他の車載ＥＣＵ１１１すなわちサーバへ送信する。より詳細には、送信部３２は、処理部３３から受けたＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージをサーバへ送信する。送信部３２により送信されるサーバへのＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージは、終了指示の一例である。
　再び図１６を参照して、ログ生成部３４は、処理部３３から受信時刻ｔｅの通知を受けて、通知された受信時刻ｔｅをセッションログの「終了時刻」としてセッションログリストＲ１２に書き込む。
　サーバにおいて、処理部１２は、管理装置２０１から通信部１１経由でＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを受信し、受信したＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを、記憶部１３におけるセッション鍵Ｋを用いて復号する。処理部１２は、記憶部１３におけるセッション鍵Ｋおよびクライアントのエンドポイント情報を破棄する。
　（サーバ側からのセッションの終了）
　サーバにおいて、処理部１２は、サービスの提供を停止する場合、サービスＩＤを含むＳｔｏｐＯｆｆｅｒメッセージを、記憶部１３におけるセッション鍵Ｋを用いて暗号化して通信部１１経由で管理装置２０１へ送信する。また、処理部１２は、記憶部１３におけるセッション鍵Ｋおよびクライアントのエンドポイント情報を破棄する。
　再び図１６を参照して、管理装置２０１において、受信部３１は、クライアントからＳｔｏｐＯｆｆｅｒメッセージを受信する。受信部３１は、受信したＳｔｏｐＯｆｆｅｒメッセージにタイムスタンプを付して処理部３３へ出力する。受信部３１により受信されるサーバからのＳｔｏｐＯｆｆｅｒメッセージは、終了要求の一例である。
　処理部３３は、受信部３１からＳｔｏｐＯｆｆｅｒメッセージを受けて、受けたＳｔｏｐＯｆｆｅｒメッセージを送信部３２へ出力する。また、処理部３３は、ＳｔｏｐＯｆｆｅｒメッセージに付されたタイムスタンプが示す受信時刻ｔｅをログ生成部３４へ通知する。
　送信部３２は、受信部３１によりＳｔｏｐＯｆｆｅｒメッセージが受信されたことに伴い、セッションを終了すべき旨のＳｔｏｐＯｆｆｅｒメッセージをセッションに参加している他の車載ＥＣＵ１１１すなわちクライアントへ送信する。より詳細には、送信部３２は、処理部３３から受けたＳｔｏｐＯｆｆｅｒメッセージをクライアントへ送信する。送信部３２により送信されるクライアントへのＳｔｏｐＯｆｆｅｒメッセージは、終了指示の一例である。
　再び図６を参照して、ログ生成部３４は、処理部３３から受信時刻ｔｅの通知を受けて、通知された受信時刻ｔｅをセッションログの「終了時刻」としてセッションログリストＲ１２に書き込む。
　クライアントにおいて、処理部１２は、管理装置２０１から通信部１１経由でＳｔｏｐＯｆｆｅｒメッセージを受信し、受信したＳｔｏｐＯｆｆｅｒメッセージを、記憶部１３におけるセッション鍵Ｋを用いて復号する。処理部１２は、記憶部１３におけるセッション鍵Ｋおよびサーバのエンドポイント情報を破棄する。
　［動作の流れ］
　図１７は、本開示の第２の実施の形態に係る管理装置がセッション鍵を配布する際の動作手順の一例を定めたフローチャートである。
　図１７を参照して、まず、管理装置２０１は、サーバからのＯｆｆｅｒメッセージ、クライアントからのＦｉｎｄメッセージ、またはクライアントからのＳｕｂｓｃｒｉｂｅメッセージを待ち受ける（ステップＳ５０２でＮＯ）。
　次に、管理装置２０１は、サーバからのＯｆｆｅｒメッセージまたはクライアントからのＦｉｎｄメッセージを受信した場合（ステップＳ５０２でＹＥＳかつステップＳ５０４でＹＥＳ）、受信したメッセージの適否を判断する（ステップＳ５０６）。
　次に、管理装置２０１は、受信したメッセージは不適切であると判断した場合（ステップＳ５０８でＮＯ）、当該メッセージに含まれるＥＣＵ識別子と、受信時刻を示すタイムスタンプとを取得し、当該メッセージのバイト列ならびに取得したＥＣＵ識別子および受信時刻を不正ログとして不正ログリストＲ１１に書き込む（ステップＳ５１０）。
　次に、管理装置２０１は、当該メッセージを破棄し（ステップＳ５１２）、サーバまたはクライアントからの新たなメッセージを待ち受ける（ステップＳ５０２でＮＯ）。
　一方、管理装置２０１は、受信したメッセージは適切であると判断した場合（ステップＳ５０８でＹＥＳ）、当該メッセージをマルチキャストする。より詳細には、管理装置２０１は、当該メッセージがＯｆｆｅｒメッセージである場合、当該メッセージを複数のクライアントへマルチキャストし、当該メッセージがＦｉｎｄメッセージである場合、当該メッセージを複数のサーバへマルチキャストする（ステップＳ５１２）。
　一方、管理装置２０１は、クライアントからのＳｕｂｓｃｒｉｂｅメッセージを受信した場合（ステップＳ５０２でＹＥＳかつステップＳ５０４でＮＯ）、サーバおよびクライアント間のセッションを確立することを決定し、当該セッションに用いるセッション鍵Ｋおよび鍵ＩＤを生成する（ステップＳ５１６）。
　次に、管理装置２０１は、セッション鍵Ｋを暗号化する。より詳細には、管理装置２０１は、サーバの固有ＩＤを暗号鍵として用いてセッション鍵Ｋを暗号化することにより暗号化鍵ＫＳを生成する。また、管理装置２０１は、クライアントの固有ＩＤを暗号鍵として用いてセッション鍵Ｋを暗号化することにより暗号化鍵ＫＣを生成する（ステップＳ５１８）。
　次に、管理装置２０１は、ハッシュ値を算出する（ステップＳ５２０）。
　より詳細には、管理装置２０１は、暗号化鍵ＫＳをＳｕｂｓｃｒｉｂｅメッセージに含め、当該Ｓｕｂｓｃｒｉｂｅメッセージとサーバの固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値ＨＶＳを算出する。また、管理装置２０１は、暗号化鍵ＫＣを含む開始メッセージＭＣを生成し、生成した開始メッセージＭＣとクライアントの固有ＩＤとを所定のハッシュ関数に与えることによりハッシュ値ＨＶＣを算出する。
　次に、管理装置２０１は、セッション鍵Ｋおよびハッシュ値を送信する。より詳細には、管理装置２０１は、暗号化鍵ＫＳを含むＳｕｂｓｃｒｉｂｅメッセージ、およびハッシュ値ＨＶＳをサーバへ送信し、暗号化鍵ＫＣを含む開始メッセージＭＣ、およびハッシュ値ＨＶＣをクライアントへ送信する（ステップＳ５２２）。
　次に、管理装置２０１は、確立するセッションにおいて提供されるサービスのサービスＩＤ、セッション鍵Ｋの宛先であるサーバおよびクライアントの各ＥＣＵ識別子、ならびにセッションの開始時刻を、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ１２に書き込む（ステップＳ５２４）。
　次に、管理装置２０１は、サーバからの新たなＯｆｆｅｒメッセージ、クライアントからの新たなＦｉｎｄメッセージ、またはクライアントからの新たなＳｕｂｓｃｒｉｂｅメッセージを待ち受ける（ステップＳ５０２でＮＯ）。
　図１８は、本開示の第２の実施の形態に係る車載システムにおける通信のシーケンスの一例を示す図である。
　図１８を参照して、まず、サーバＳ１は、Ｏｆｆｅｒメッセージを管理装置２０１へ送信する（ステップＳ６０２）。
　次に、管理装置２０１は、サーバＳ１から受信したＯｆｆｅｒメッセージの適否を判断する（ステップＳ６０４）。
　次に、管理装置２０１は、Ｏｆｆｅｒメッセージは適切であると判断した場合、ＯｆｆｅｒメッセージをクライアントＣ１，Ｃ２へマルチキャストする（ステップＳ６０６）。
　次に、たとえば、クライアントＣ１は、管理装置２０１から受信したＯｆｆｅｒメッセージからサービスＩＤを取得し、取得したサービスＩＤが示すサービスが必要であると判断し、Ｓｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する（ステップＳ６０８）。
　次に、管理装置２０１は、クライアントＣ１からのＳｕｂｓｃｒｉｂｅメッセージを受信し、サーバＳ１およびクライアントＣ１間のセッションを確立することを決定し、当該セッションに用いるセッション鍵Ｋ１を生成する（ステップＳ６１０）。また、このとき、管理装置２０１は、確立するセッションにおいて提供されるサービスのサービスＩＤ、サーバＳ１およびクライアントＣ１の各ＥＣＵ識別子、セッションの開始時刻を、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ１２に書き込む。
　次に、管理装置２０１は、生成したセッション鍵Ｋ１をＳｕｂｓｃｒｉｂｅメッセージに含めてサーバＳ１へ配布する（ステップＳ６１２）。また、管理装置２０１は、生成したセッション鍵Ｋ１を開始メッセージＭＣに含めてクライアントＣ１へ配布する（ステップＳ６１４）。
　次に、サーバＳ１は、たとえば定期的に、セッション鍵Ｋ１を用いて暗号化したセッションメッセージをクライアントＣ１へユニキャストする（ステップＳ６１６）。
　次に、たとえば、クライアントＣ２は、管理装置２０１から受信したＯｆｆｅｒメッセージからサービスＩＤを取得し、取得したサービスＩＤが示すサービスが必要であると判断し、Ｓｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する（ステップＳ６１８）。
　次に、管理装置２０１は、クライアントＣ２からのＳｕｂｓｃｒｉｂｅメッセージを受信し、サーバＳ１およびクライアントＣ２間のセッションを確立することを決定し、当該セッションに用いるセッション鍵Ｋ２を生成する（ステップＳ６２０）。また、このとき、管理装置２０１は、確立するセッションにおいて提供されるサービスのサービスＩＤ、サーバＳ１およびクライアントＣ２の各ＥＣＵ識別子、ならびにセッションの開始時刻を、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ１２に書き込む。
　次に、管理装置２０１は、生成したセッション鍵Ｋ２をＳｕｂｓｃｒｉｂｅメッセージに含めてサーバＳ１へ配布する（ステップＳ６２２）。また、管理装置２０１は、生成したセッション鍵Ｋ２を開始メッセージＭＣに含めてクライアントＣ２へ配布する（ステップＳ６２４）。
　次に、サーバＳ１は、たとえば定期的に、セッション鍵Ｋ１を用いて暗号化したセッションメッセージをクライアントＣ１へユニキャストする（ステップＳ６２６）。
　また、サーバＳ１は、たとえば定期的に、セッション鍵Ｋ２を用いて暗号化したセッションメッセージをクライアントＣ２へユニキャストする（ステップＳ６２８）。
　次に、たとえば、クライアントＣ１は、サービスの提供を受けることを停止するために、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する（ステップＳ６３０）。
　次に、管理装置２０１は、クライアントＣ１からＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを受信し、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージをサーバＳ１へ送信する（ステップＳ６３２）。また、このとき、管理装置２０１は、セッションの終了時刻をセッションログの「終了時刻」としてセッションログリストＲ１２に書き込む。
　次に、クライアントＣ１は、記憶部１３におけるセッション鍵Ｋ１およびサーバＳ１のエンドポイント情報を破棄する（ステップＳ６３４）。
　また、サーバＳ１は、記憶部１３におけるセッション鍵Ｋ１およびクライアントＣ１のエンドポイント情報を破棄する（ステップＳ６３６）。
　次に、サーバＳ１は、クライアントＣ２へのセッションメッセージのユニキャストを継続する（ステップＳ６３８）。
　図１９は、本開示の第２の実施の形態に係る車載システムにおける通信のシーケンスの他の例を示す図である。
　図１９を参照して、まず、クライアントＣ１は、Ｆｉｎｄメッセージを管理装置２０１へ送信する（ステップＳ７０２）。
　次に、管理装置２０１は、クライアントＣ１から受信したＦｉｎｄメッセージの適否を判断する（ステップＳ７０４）。
　次に、管理装置２０１は、Ｆｉｎｄメッセージは適切であると判断した場合、ＦｉｎｄメッセージをサーバＳ１，Ｓ２へマルチキャストする（ステップＳ７０６）。
　次に、たとえば、サーバＳ１は、管理装置２０１から受信したＦｉｎｄメッセージからサービスＩＤを取得し、取得したサービスＩＤが示すサービスの提供が可能であると判断し、Ｏｆｆｅｒメッセージを管理装置２０１へ送信する（ステップＳ７０８）。
　次に、管理装置２０１は、サーバＳ１から受信したＯｆｆｅｒメッセージの適否を判断する（ステップＳ７１０）。
　次に、管理装置２０１は、Ｏｆｆｅｒメッセージは適切であると判断した場合、ＯｆｆｅｒメッセージをクライアントＣ１へ送信する（ステップＳ７１２）。
　次に、クライアントＣ１は、管理装置２０１からＯｆｆｅｒメッセージを受信し、Ｓｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する（ステップＳ７１４）。
　次に、管理装置２０１は、クライアントＣ１からのＳｕｂｓｃｒｉｂｅメッセージを受信し、サーバＳ１およびクライアントＣ１間のセッションを確立することを決定し、当該セッションに用いるセッション鍵Ｋ３を生成する（ステップＳ７１６）。また、このとき、管理装置２０１は、確立するセッションにおいて提供されるサービスのサービスＩＤ、サーバＳ１およびクライアントＣ１の各ＥＣＵ識別子、ならびにセッションの開始時刻を、それぞれ、セッションログの「サービスＩＤ」、「ＥＣＵ識別子」および「開始時刻」としてセッションログリストＲ１２に書き込む。
　次に、管理装置２０１は、生成したセッション鍵Ｋ１を開始メッセージＭＣに含めてクライアントＣ１へ配布する（ステップＳ７１８）。また、管理装置２０１は、生成したセッション鍵Ｋ３をＳｕｂｓｃｒｉｂｅメッセージに含めてサーバＳ１へ配布する（ステップＳ７２０）。
　次に、サーバＳ１は、たとえば定期的に、セッション鍵Ｋ３を用いて暗号化したセッションメッセージをクライアントＣ１へユニキャストする（ステップＳ７２２）。
　次に、たとえば、サーバＳ１は、サービスの提供を停止するために、ＳｔｏｐＯｆｆｅｒメッセージを管理装置２０１へ送信する（ステップＳ７２４）。
　次に、管理装置２０１は、サーバＳ１からＳｔｏｐＯｆｆｅｒメッセージを受信し、ＳｔｏｐＯｆｆｅｒメッセージをクライアントＣ１へ送信する（ステップＳ７２６）。また、このとき、管理装置２０１は、セッションの終了時刻をセッションログの「終了時刻」としてセッションログリストＲ１２に書き込む。
　次に、サーバＳ１は、記憶部１３におけるセッション鍵Ｋ３およびクライアントＣ１のエンドポイント情報を破棄する（ステップＳ７２８）。
　また、クライアントＣ１は、記憶部１３におけるセッション鍵Ｋ３およびサーバＳ１のエンドポイント情報を破棄する（ステップＳ７３０）。
　なお、図１９におけるステップＳ７２４においてサーバＳ１がＳｔｏｐＯｆｆｅｒメッセージを管理装置２０１へ送信する代わりに、クライアントＣ１がＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信してもよい。また、図１８におけるステップＳ６３０においてクライアントＣ１がＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する代わりに、サーバＳ１がＳｔｏｐＯｆｆｅｒメッセージを管理装置２０１へ送信してもよい。この場合、管理装置２０１は、ＳｔｏｐＯｆｆｅｒメッセージをクライアントＣ１，Ｃ２へ送信する。
　なお、本開示の第２の実施の形態に係る車載システム３０２では、サーバは、複数のクライアントへマルチキャストにより情報を送信している状態において、車載システム３０２における異常を検知した場合、複数のクライアントへユニキャストにより情報を送信する状態に切り替える構成であるとしたが、これに限定するものではない。サーバは、複数のクライアントへユニキャストにより情報を送信する状態に切り替えない構成であってもよい。また、サーバは、複数のクライアントへユニキャストにより情報を送信する一方で、マルチキャストにより情報を送信することができない構成であってもよい。
　また、本開示の第２の実施の形態に係る管理装置２０１では、処理部３３は、暗号化鍵ＫＳを含むＳｕｂｓｃｒｉｂｅメッセージおよび暗号化鍵ＫＣを含む開始メッセージＭＣを送信部３２へ出力する構成であるとしたが、これに限定するものではない。処理部３３は、暗号化されていないセッション鍵Ｋを含む、Ｓｕｂｓｃｒｉｂｅメッセージおよび開始メッセージＭＣを送信部３２へ出力する構成であってもよい。この場合、送信部３２は、当該Ｓｕｂｓｃｒｉｂｅをサーバへ送信し、当該開始メッセージＭＣをクライアントへ送信する。
　また、本開示の第２の実施の形態に係る管理装置２０１では、送信部３２は、ハッシュ値ＨＶＳをサーバへ送信し、ハッシュ値ＨＶＣをクライアントへ送信する構成であるとしたが、これに限定するものではない。送信部３２は、Ｓｕｂｓｃｒｉｂｅメッセージをサーバへ送信する一方で、ハッシュ値ＨＶＳを送信しない構成であってもよい。また、送信部３２は、開始メッセージＭＣをクライアントへ送信する一方で、ハッシュ値ＨＶＣを送信しない構成であってもよい。
　また、本開示の第２の実施の形態に係る管理装置２０１では、受信部３１は、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージをクライアントから受信し、ＳｔｏｐＯｆｆｅｒメッセージをサーバから受信する構成であるとしたが、これに限定するものではない。受信部３１は、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージおよびＳｔｏｐＯｆｆｅｒメッセージを受信しない構成であってもよい。この場合、たとえば、車載システム３０２では、クライアントは、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージを管理装置２０１へ送信する代わりに、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージをサーバへ送信する。また、サーバは、ＳｔｏｐＯｆｆｅｒメッセージを管理装置２０１へ送信する代わりに、ＳｔｏｐＯｆｆｅｒメッセージをクライアントへ送信する。
　また、本開示の第２の実施の形態に係る管理装置２０１は、ログ生成部３４を備える構成であるとしたが、これに限定するものではない。管理装置２０１は、ログ生成部３４を備えない構成であってもよい。
　また、本開示の第２の実施の形態に係る管理装置２０１では、ログ生成部３４は、セッションの開始時刻および終了時刻をセッションログリストＲ１２に書き込む構成であるとしたが、これに限定するものではない。ログ生成部３４は、セッションにおいて提供されるサービスのサービスＩＤ、Ｓｕｂｓｃｒｉｂｅメッセージの宛先であるサーバのＥＣＵ識別子、および開始メッセージＭＣの宛先であるクライアントのＥＣＵ識別子をセッションログリストＲ１２に書き込む一方で、セッションの開始時刻および終了時刻をセッションログリストＲ１２に書き込まない構成であってもよい。
　また、本開示の第２の実施の形態に係る管理装置２０１では、処理部３３は、セッションごとにランダムな内容のセッション鍵Ｋを生成する構成であるとしたが、これに限定されない。処理部３３は、セッションごとに規則的な内容のセッション鍵Ｋを生成する構成であってもよい。
　また、本開示の第２の実施の形態に係る管理装置２０１では、処理部３３は、第１の実施の形態に係る中継装置１０１における処理部２３と同様に、Ｓｕｂｓｃｒｉｂｅメッセージの適否の判断をさらに行う構成であってもよいし、ＳｔｏｐＳｕｂｓｃｒｉｂｅメッセージの適否の判断をさらに行う構成であってもよいし、ＳｔｏｐＯｆｆｅｒメッセージの適否の判断をさらに行う構成であってもよい。
　ところで、車載ネットワークにおけるセキュリティをより向上させることが可能な技術が望まれる。より詳細には、たとえばサービス指向型の通信を行う車載システムにおいて、車載ネットワークにおけるセキュリティをより向上させることが可能な技術が望まれる。
　これに対して、本開示の第２の実施の形態に係る管理装置２０１では、受信部３１は、Ｏｆｆｅｒメッセージをサーバから受信する。また、受信部３１は、Ｓｕｂｓｃｒｉｂｅメッセージをクライアントから受信する。処理部３３は、受信部３１により受信されたＯｆｆｅｒメッセージおよびＳｕｂｓｃｒｉｂｅメッセージに紐づくセッションに用いる、当該セッションに固有のセッション鍵Ｋを生成する。送信部３２は、処理部３３により生成されたセッション鍵をセッションに参加するサーバおよびクライアントへ送信する。
　このように、Ｏｆｆｅｒメッセージをサーバから受信し、Ｓｕｂｓｃｒｉｂｅメッセージをクライアントから受信し、セッションに固有のセッション鍵Ｋを生成してサーバおよびクライアントへ送信する構成により、サーバおよびクライアント間においてセッションごとに個別のセッション鍵Ｋを用いた通信を行うことができるので、サーバおよびクライアント間の通信のセキュリティを向上することができる。また、たとえば、Ｏｆｆｅｒメッセージの送信元のサーバおよびＦｉｎｄメッセージの送信元のクライアントの認証を行うことにより、不正機器からのＯｆｆｅｒメッセージおよびＦｉｎｄメッセージを検知することができる。したがって、車載ネットワークにおけるセキュリティをより向上させることができる。
　また、管理装置２０１では、処理部３３が、１つのサーバとセッションにおける通信を行うクライアントの数が所定数となった場合、当該サーバおよび複数のクライアント間のセッションに用いるセッション鍵ＫＭを生成し、生成したセッション鍵ＫＭを当該サーバおよび当該複数のクライアントへ配布する構成により、当該サーバおよび当該複数のクライアントにおいて、セッション鍵ＫＭを用いたマルチキャスト通信を行うことができる。したがって、ＳＯＭＥ／ＩＰに従うメッセージの送受信が行われる車載ネットワークにおけるセキュリティを向上させることができる。
　上記実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記説明ではなく請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
　以上の説明は、以下に付記する特徴を含む。
　［付記１］
　複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う中継部と、
　前記複数のフレームが、前記複数の車載装置間の通信のセッションの開始要求を含むこと、および前記開始要求に対する開始応答を含むことを判断する判断部と、
　前記判断部により前記開始要求を含むと判断された前記フレームの送信元の前記車載装置と、前記判断部により前記開始応答を含むと判断された前記フレームの送信元の１または複数の前記車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成する生成部と、
　前記共通鍵を、前記セッションに参加する前記各車載装置へ前記中継部経由で送信する送信部とを備え、
　前記中継部は、サービスＩＤと、前記開始要求の送信元の前記車載装置のエンドポイント情報と、前記開始要求の送信元の前記車載装置のＥＣＵ識別子とを含む第１の前記フレームを受信し、
　前記生成部は、前記サービスＩＤ、前記エンドポイント情報および前記ＥＣＵ識別子に基づいて、前記第１のフレームの適否を判断し、
　前記中継部は、サービスＩＤと、前記開始応答の送信元の前記車載装置のエンドポイント情報と、前記開始応答の送信元の前記車載装置のＥＣＵ識別子とを含む第２の前記フレームを受信し、
　前記生成部は、前記サービスＩＤ、前記エンドポイント情報および前記ＥＣＵ識別子に基づいて、前記第２のフレームの適否を判断する、車載中継装置。
　［付記２］
　複数の車載装置と、
　車載中継装置とを備え、
　前記車載中継装置は、前記複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行い、
　前記複数の車載装置の１つである第１の車載装置は、複数の前記車載装置間の通信のセッションの開始要求を含む第１のフレームを前記車載中継装置へ送信し、
　前記複数の車載装置の１つである第２の車載装置は、前記開始要求に対する開始応答を含む第２のフレームを前記車載中継装置へ送信し、
　前記車載中継装置は、受信した前記第１のフレームの送信元の前記第１の車載装置と、受信した前記第２のフレームの送信元の前記第２の車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信し、
　前記第１の車載装置は、サービスＩＤと、前記第１の車載装置のエンドポイント情報と、前記第１の車載装置のＥＣＵ識別子とを含む前記第１のフレームを前記車載中継装置へ送信し、
　前記車載中継装置は、前記サービスＩＤ、前記エンドポイント情報および前記ＥＣＵ識別子に基づいて、前記第１のフレームの適否を判断し、
　前記第２の車載装置は、サービスＩＤと、前記第２の車載装置のエンドポイント情報と、前記第２の車載装置のＥＣＵ識別子とを含む前記第２のフレームを前記車載中継装置へ送信し、
　前記車載中継装置は、前記サービスＩＤ、前記エンドポイント情報および前記ＥＣＵ識別子に基づいて、前記第２のフレームの適否を判断する、車載システム。
　［付記３］
　複数の車載装置を備える車載システムに用いられる管理装置であって、
　前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を前記車載装置から受信する受信部と、
　前記開始要求に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成する生成部と、
　前記共通鍵を前記セッションに参加する前記各車載装置へ送信する送信部とを備え、
　前記受信部は、サービスＩＤと、前記開始要求の送信元の前記車載装置のエンドポイント情報と、前記開始要求の送信元の前記車載装置のＥＣＵ識別子とを含む前記開始要求を受信し、
　前記生成部は、前記サービスＩＤ、前記エンドポイント情報および前記ＥＣＵ識別子に基づいて、前記開始要求の適否を判断する、管理装置。
　［付記４］
　複数の車載装置と、
　管理装置とを備え、
　前記車載装置は、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を前記管理装置へ送信し、
　前記管理装置は、受信した前記開始要求に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信し、
　前記車載装置は、サービスＩＤと、自己のエンドポイント情報と、自己のＥＣＵ識別子とを含む前記開始要求を前記管理装置へ送信し、
　前記管理装置は、前記サービスＩＤ、前記エンドポイント情報および前記ＥＣＵ識別子に基づいて、前記開始要求の適否を判断する、車載システム。
　１　　　車両
　１１　　通信部
　１２　　処理部
　１３　　記憶部
　１４　　ケーブル
　２１　　通信ポート
　２２　　中継部
　２３　　処理部（判断部、生成部、送信部）
　２４　　ログ生成部（記録部）
　２５　　記憶部
　３１　　受信部
　３２　　送信部
　３３　　処理部
　３４　　ログ生成部
　３５　　記憶部
　１０１　中継装置（車載中継装置）
　１０２　中継装置
　１１１　車載ＥＣＵ（車載装置）
　２０１　管理装置
　３０１，３０２　車載システム
　Ｒ１，Ｒ１１　　不正ログリスト
　Ｒ２，Ｒ１２　　セッションログリスト
　Ｓ１　サーバ
　Ｃ１，Ｃ２，Ｃ３　クライアント

Claims (25)

  1. 　複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う中継部と、
    　前記複数のフレームが、前記複数の車載装置間の通信のセッションの開始要求を含むこと、および前記開始要求に対する開始応答を含むことを判断する判断部と、
    　前記判断部により前記開始要求を含むと判断された前記フレームの送信元の前記車載装置と、前記判断部により前記開始応答を含むと判断された前記フレームの送信元の１または複数の前記車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成する生成部と、
    　前記共通鍵を、前記セッションに参加する前記各車載装置へ前記中継部経由で送信する送信部とを備える、車載中継装置。
  2. 　前記車載中継装置は、さらに、
    　前記各車載装置の固有ＩＤを記憶する記憶部を備え、
    　前記送信部は、１つの前記固有ＩＤを暗号鍵として用いて暗号化された前記共通鍵を、暗号化に用いた前記固有ＩＤを有する前記車載装置へ前記中継部経由で送信する、請求項１に記載の車載中継装置。
  3. 　前記送信部は、１つの前記固有ＩＤと前記共通鍵とを用いて算出されたハッシュ値を、前記ハッシュ値の算出に用いた前記固有ＩＤを有する前記車載装置へ前記中継部経由でさらに送信する、請求項２に記載の車載中継装置。
  4. 　前記車載中継装置は、さらに、
    　前記共通鍵が用いられる前記セッションに関するセッション情報を記録する記録部を備える、請求項１から請求項３のいずれか１項に記載の車載中継装置。
  5. 　前記記録部は、前記セッション情報として、前記共通鍵の前記中継部による送信時刻を記録する、請求項４に記載の車載中継装置。
  6. 　前記判断部は、前記中継部により受信された前記フレームが、前記セッションの終了要求を含むことを判断し、
    　前記記録部は、前記セッション情報として、前記終了要求を含む前記フレームの前記中継部による受信時刻を記録する、請求項４または請求項５に記載の車載中継装置。
  7. 　前記判断部は、前記中継部により受信された前記フレームが前記開始要求または前記開始応答を含むとの判断結果に応じて、前記フレームの適否を判断し、
    　前記中継部は、前記判断部による前記フレームの適否の判断結果に応じて、前記フレームの前記中継処理または破棄を行う、請求項１から請求項６のいずれか１項に記載の車載中継装置。
  8. 　複数の車載装置を備える車載システムに用いられる管理装置であって、
    　前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求、および前記開始要求に対する開始応答を、複数の前記車載装置からそれぞれ受信する受信部と、
    　前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成する生成部と、
    　前記共通鍵を前記セッションに参加する前記各車載装置へ送信する送信部とを備える、管理装置。
  9. 　前記管理装置は、さらに、
    　前記各車載装置の固有ＩＤを記憶する記憶部を備え、
    　前記送信部は、１つの前記固有ＩＤを暗号鍵として用いて暗号化された前記共通鍵を、暗号化に用いた前記固有ＩＤを有する前記車載装置へ送信する、請求項８に記載の管理装置。
  10. 　前記送信部は、１つの前記固有ＩＤと前記共通鍵とを用いて算出されたハッシュ値を、前記ハッシュ値の算出に用いた前記固有ＩＤを有する前記車載装置へさらに送信する、請求項９に記載の管理装置。
  11. 　前記受信部は、前記セッションの終了要求を前記車載装置から受信し、
    　前記送信部は、前記受信部による前記終了要求の受信に基づいて、前記セッションを終了させる終了指示を前記セッションに参加している他の前記車載装置へ送信する、請求項８から請求項１０のいずれか１項に記載の管理装置。
  12. 　前記管理装置は、さらに、
    　前記共通鍵が用いられる前記セッションに関するセッション情報を記録する記録部を備える、請求項８から請求項１１のいずれか１項に記載の管理装置。
  13. 　前記記録部は、前記セッション情報として、前記共通鍵の前記送信部による送信時刻を記録する、請求項１２に記載の管理装置。
  14. 　前記管理装置は、さらに、
    　前記共通鍵が用いられる前記セッションに関するセッション情報を記録する記録部を備え、
    　前記記録部は、前記セッション情報として、前記終了要求の前記受信部による受信時刻を記録する、請求項１１に記載の管理装置。
  15. 　第１の車載装置および第２の車載装置を含む複数の車載装置と、
    　車載中継装置とを備え、
    　前記車載中継装置は、前記複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行い、
    　前記第１の車載装置は、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を含む第１のフレームを前記車載中継装置へ送信し、
    　前記第２の車載装置は、前記開始要求に対する開始応答を含む第２のフレームを前記車載中継装置へ送信し、
    　前記車載中継装置は、受信した前記第１のフレームの送信元の前記第１の車載装置と、受信した前記第２のフレームの送信元の前記第２の車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信する、車載システム。
  16. 　前記車載中継装置と、前記第１の車載装置および前記第２の車載装置とは、他の中継装置を介さずに接続される、請求項１５に記載の車載システム。
  17. 　前記車載装置は、複数の前記車載装置へマルチキャストにより情報を送信している状態において、前記車載システムにおける異常を検知した場合、複数の前記車載装置へユニキャストにより情報を送信する状態に切り替える、請求項１５または請求項１６に記載の車載システム。
  18. 　前記車載中継装置は、前記車載システムにおける前記各車載装置の固有ＩＤを記憶する記憶部を備え、
    　前記車載中継装置は、１つの前記固有ＩＤと前記共通鍵とを用いて算出されたハッシュ値を、前記ハッシュ値の算出に用いた前記固有ＩＤを有する前記車載装置へさらに送信し、
    　前記車載装置は、前記車載中継装置から受信した前記共通鍵と自己の前記固有ＩＤとを用いて算出されるハッシュ値と、前記車載中継装置から受信した前記ハッシュ値とを照合する、請求項１５から請求項１７のいずれか１項に記載の車載システム。
  19. 　第１の車載装置および第２の車載装置を含む複数の車載装置と、
    　管理装置とを備え、
    　前記第１の車載装置は、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を前記管理装置へ送信し、
    　前記第２の車載装置は、前記開始要求に対する開始応答を前記管理装置へ送信し、
    　前記管理装置は、受信した前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信する、車載システム。
  20. 　前記車載装置は、複数の前記車載装置へマルチキャストにより情報を送信している状態において、前記車載システムにおける異常を検知した場合、複数の前記車載装置へユニキャストにより情報を送信する状態に切り替える、請求項１９に記載の車載システム。
  21. 　前記管理装置は、前記車載システムにおける前記各車載装置の固有ＩＤを記憶する記憶部を備え、
    　前記管理装置は、１つの前記固有ＩＤと前記共通鍵とを用いて算出されたハッシュ値を、前記ハッシュ値の算出に用いた前記固有ＩＤを有する前記車載装置へさらに送信し、
    　前記車載装置は、前記管理装置から受信した前記共通鍵と自己の前記固有ＩＤとを用いて算出されるハッシュ値と、前記管理装置から受信した前記ハッシュ値とを照合する、請求項１９または請求項２０に記載の車載システム。
  22. 　複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う車載中継装置における通信管理方法であって、
    　前記複数のフレームが、前記複数の車載装置間の通信のセッションの開始要求を含むこと、および前記開始要求に対する開始応答を含むことを判断するステップと、
    　前記開始要求を含むと判断した前記フレームの送信元の前記車載装置と、前記開始応答を含むと判断した前記フレームの送信元の１または複数の前記車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成するステップと、
    　生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む、通信管理方法。
  23. 　複数の車載装置を備える車載システムに用いられる管理装置における通信管理方法であって、
    　前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求、および前記開始要求に対する開始応答を、複数の前記車載装置からそれぞれ受信するステップと、
    　受信した前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成するステップと、
    　生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む、通信管理方法。
  24. 　第１の車載装置および第２の車載装置を含む複数の車載装置と、前記複数の車載装置からそれぞれ受信した複数のフレームを、宛先の前記車載装置へそれぞれ送信する中継処理を行う車載中継装置とを備える車載システムにおける通信管理方法であって、
    　前記第１の車載装置が、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を含む第１のフレームを前記車載中継装置へ送信するステップと、
    　前記第２の車載装置が、前記開始要求に対する開始応答を含む第２のフレームを前記車載中継装置へ送信するステップと、
    　前記車載中継装置が、受信した前記第１のフレームの送信元の前記第１の車載装置と、受信した前記第２のフレームの送信元の前記第２の車載装置とが参加する前記セッションに用いる共通鍵を前記セッションごとに生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む、通信管理方法。
  25. 　第１の車載装置および第２の車載装置を含む複数の車載装置と、管理装置とを備える車載システムにおける通信管理方法であって、
    　前記第１の車載装置が、前記複数の車載装置のうちの一部または全部である複数の前記車載装置間の通信のセッションの開始要求を前記管理装置へ送信するステップと、
    　前記第２の車載装置が、前記開始要求に対する開始応答を前記管理装置へ送信するステップと、
    　前記管理装置が、受信した前記開始要求および前記開始応答に紐づく前記セッションに用いる、前記セッションに固有の共通鍵を生成し、生成した前記共通鍵を前記セッションに参加する前記各車載装置へ送信するステップとを含む、通信管理方法。
     
     
     
     
     
     
     
     
     
PCT/JP2021/048221 2021-03-12 2021-12-24 車載中継装置、管理装置、車載システムおよび通信管理方法 WO2022190580A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE112021007272.2T DE112021007272T5 (de) 2021-03-12 2021-12-24 Fahrzeuggebundene weiterleitungsvorrichtung, verwaltungsvorrichtung, fahrzeuggebundenes system und kommunikationsverwaltungsverfahren
US18/281,307 US20240157893A1 (en) 2021-03-12 2021-12-24 Vehicle-mounted relay device, management device, vehicle-mounted system, and communication management method
CN202180093430.0A CN116830522A (zh) 2021-03-12 2021-12-24 车载中继装置、管理装置、车载系统及通信管理方法
JP2023505129A JPWO2022190580A1 (ja) 2021-03-12 2021-12-24

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2021-039794 2021-03-12
JP2021039794 2021-03-12
JP2021-134479 2021-08-20
JP2021134479 2021-08-20

Publications (1)

Publication Number Publication Date
WO2022190580A1 true WO2022190580A1 (ja) 2022-09-15

Family

ID=83226591

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/048221 WO2022190580A1 (ja) 2021-03-12 2021-12-24 車載中継装置、管理装置、車載システムおよび通信管理方法

Country Status (4)

Country Link
US (1) US20240157893A1 (ja)
JP (1) JPWO2022190580A1 (ja)
DE (1) DE112021007272T5 (ja)
WO (1) WO2022190580A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230292201A1 (en) * 2022-03-08 2023-09-14 Sharp Kabushiki Kaisha Vehicle information for vehicle mounted relays
US20230396431A1 (en) * 2022-06-02 2023-12-07 Micron Technology, Inc. Error reduction during cryptographic key updates in secure memory devices

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017092807A (ja) * 2015-11-13 2017-05-25 株式会社東芝 検査装置、通信システム、移動体および検査方法
US20180084412A1 (en) * 2016-09-20 2018-03-22 2236008 Ontario Inc. In-vehicle networking
JP2018186486A (ja) * 2017-04-25 2018-11-22 株式会社東芝 情報処理装置、情報処理システム、および情報処理方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017027572A (ja) 2014-12-14 2017-02-02 鍵和田　芳光 電子商取引システム、方法及びプログラム
JP6849528B2 (ja) 2016-07-28 2021-03-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ フレーム伝送阻止装置、フレーム伝送阻止方法及び車載ネットワークシステム
JP7390924B2 (ja) 2020-02-21 2023-12-04 日鉄建材株式会社 ライナープレートの連結方法及び締結金具

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017092807A (ja) * 2015-11-13 2017-05-25 株式会社東芝 検査装置、通信システム、移動体および検査方法
US20180084412A1 (en) * 2016-09-20 2018-03-22 2236008 Ontario Inc. In-vehicle networking
JP2018186486A (ja) * 2017-04-25 2018-11-22 株式会社東芝 情報処理装置、情報処理システム、および情報処理方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
IORIO MARCO; REINERI MASSIMO; RISSO FULVIO; SISTO RICCARDO; VALENZA FULVIO: "Securing SOME/IP for In-Vehicle Service Protection", IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, IEEE, USA, vol. 69, no. 11, 6 October 2020 (2020-10-06), USA, pages 13450 - 13466, XP011819972, ISSN: 0018-9545, DOI: 10.1109/TVT.2020.3028880 *
KUNITO FUKUDA; TAKAHITO YASUNAGA; YOSHIKAZU ISOYAMA: "A study on session management server for SOME/IP cybersecurity", IPSJ SIG NOTES, SLDM, INFORMATION PROCESSING SOCIETY OF JAPAN, JP, vol. 2021-SLDM-194, no. 25, 18 March 2021 (2021-03-18), JP, pages 1 - 8, XP009539453, ISSN: 2188-8639 *
XIAO YANG XIAOY@VT.EDU; SHI SHANGHAO SHANGHAOS@VT.EDU; ZHANG NING ZHANG.NING@WUSTL.EDU; LOU WENJING WJLOU@VT.EDU; HOU Y. THOMAS TH: "Session Key Distribution Made Practical for CAN and CAN-FD Message Authentication", 2021 THE 4TH INTERNATIONAL CONFERENCE ON COMPUTERS IN MANAGEMENT AND BUSINESS, ACMPUB27, NEW YORK, NY, USA, 7 December 2020 (2020-12-07) - 2 April 2021 (2021-04-02), New York, NY, USA, pages 681 - 693, XP058877294, ISBN: 978-1-4503-8871-9, DOI: 10.1145/3427228.3427278 *

Also Published As

Publication number Publication date
JPWO2022190580A1 (ja) 2022-09-15
US20240157893A1 (en) 2024-05-16
DE112021007272T5 (de) 2024-01-25

Similar Documents

Publication Publication Date Title
EP1482682B1 (en) Content distribution system
US8364772B1 (en) System, device and method for dynamically securing instant messages
US7987359B2 (en) Information communication system, information communication apparatus and method, and computer program
US7587591B2 (en) Secure transport of multicast traffic
JP3343064B2 (ja) フレームを捕獲、カプセル化及び暗号化するための擬似ネットワークアダプタ
CA2703719C (en) Method and system for secure session establishment using identity-based encryption (vdtls)
WO2022190580A1 (ja) 車載中継装置、管理装置、車載システムおよび通信管理方法
US11350277B2 (en) Lattice mesh
US20080298592A1 (en) Technique for changing group member reachability information
US20130227660A1 (en) Registration server, gateway apparatus and method for providing a secret value to devices
Zelle et al. Analyzing and securing SOME/IP automotive services with formal and practical methods
JP2001265729A (ja) マルチキャストシステム、認証サーバ端末、マルチキャスト受信者端末管理方法、並びに記録媒体
CN110832806B (zh) 针对面向身份的网络的基于id的数据面安全
CN108924157B (zh) 一种基于IPSec VPN的报文转发方法及装置
JP2005236728A (ja) サーバ装置、要求発行機器、要求受諾機器、通信システム及び通信方法
Tiloca Efficient protection of response messages in DTLS-based secure multicast communication
CN116830522A (zh) 车载中继装置、管理装置、车载系统及通信管理方法
JP2004304754A (ja) コンテンツ配信システム
JP2005210555A (ja) 情報処理装置
Dudani Virtual Private Networks for Peer-to-Peer Infrastructures
Kumar DICE Working Group M. Tiloca Internet-Draft S. Raza Intended Status: Standards Track SICS Swedish ICT AB Expires: April 16, 2016 K. Nikitin EPFL
JP2005303784A (ja) サーバ装置、要求発行機器、要求受諾機器、通信システム、通信方法及びプログラム
KR20070017329A (ko) 프록시에 의한 안전한 단말간 ｔｃｐ/ｉｐ 통신 방법 및통신 시스템
Mueller Automotive Group Key Agreement and Client Authentication with DANCE
JP2005311747A (ja) サーバ装置、要求発行機器、要求受諾機器、通信システム及びプログラム

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: 21930424

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180093430.0

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2023505129

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18281307

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 112021007272

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21930424

Country of ref document: EP

Kind code of ref document: A1