WO2013005730A1 - 車載ネットワークシステム - Google Patents

車載ネットワークシステム Download PDF

Info

Publication number
WO2013005730A1
WO2013005730A1 PCT/JP2012/066945 JP2012066945W WO2013005730A1 WO 2013005730 A1 WO2013005730 A1 WO 2013005730A1 JP 2012066945 W JP2012066945 W JP 2012066945W WO 2013005730 A1 WO2013005730 A1 WO 2013005730A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
configuration
configuration management
control device
ecu
Prior art date
Application number
PCT/JP2012/066945
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 US14/127,062 priority Critical patent/US9132790B2/en
Priority to DE112012002836.8T priority patent/DE112012002836B4/de
Publication of WO2013005730A1 publication Critical patent/WO2013005730A1/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
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • 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
    • 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/3271—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 challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user
    • 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 invention relates to an in-vehicle network system.
  • ECUs Electronic Control Units
  • the ECUs are interconnected via an in-vehicle network and cooperate with each other.
  • control program installed in the vehicle-mounted ECU is stored in a storage device such as a flash ROM (Read Only Memory) of a microcomputer built in the vehicle-mounted ECU.
  • a storage device such as a flash ROM (Read Only Memory) of a microcomputer built in the vehicle-mounted ECU.
  • the version of this control program is managed by the manufacturer, and by combining the proper software version, it is intended that the single function and the cooperative function through the vehicle-mounted network operate normally.
  • each in-vehicle ECU proves the authenticity of its own software to the outside, and further proves the authenticity of all related in-vehicle ECUs. If a proof of configuration is obtained, the correct program provided by the manufacturer is combined to confirm that the intended control is being implemented.
  • Patent Document 1 a common key or a common key generation source is shared between a plurality of in-vehicle ECUs, and whether or not encrypted communication is established between ECUs estimated to share this information, A technique for performing the configuration proof is disclosed.
  • Patent Document 2 discloses a KPS (Key Predistribution System) common key distribution method. This method can be used as a common key generation source in Patent Document 1.
  • KPS Key Predistribution System
  • JP 2010-11400 A Japanese Patent Publication No. 5-48980
  • Patent Document 1 an external infrastructure such as a center server is required to share a common key or a common key generation source among a plurality of ECUs.
  • a configuration proof is used, so that a large amount of computer power is required when performing encrypted communication.
  • the center server is an external server in which key information of all vehicles is aggregated, and each in-vehicle ECU constituting the in-vehicle network is connected to the center server to obtain key information.
  • the center server must receive. Since all key information is collected in the center server, communication between the in-vehicle ECU and the center server is interrupted, the center server itself is attacked, or a malicious third party impersonates the center server The whole system can collapse.
  • the common key generation source distributed by the KPS method is used for communication between ECUs participating in the in-vehicle network. Therefore, in order to communicate securely between ECUs, it is necessary to first acquire a common key generation source from the center server as an initialization process. At this time, the encryption key used for each ECU to communicate with the center server is not a unique encryption key for each ECU, but a fixed encryption key must be used. This is because the in-vehicle ECU is mass-produced by the parts manufacturer and delivered to the assembly manufacturer, and the encryption key for the initialization process is inevitably in units of the vehicle type, the same part number, or the lot having the same ID. This is because the variation is fixed to.
  • the encryption key is fixed, it becomes easy for a malicious third party to eavesdrop on the communication between the ECU and the center server, and the initialization key may be illegally obtained using this. If the initialization key is illegally obtained, the information on the center server may be illegally extracted. Moreover, a false common key may be distributed to the vehicle-mounted ECU, and communication with other vehicle-mounted ECUs may be interrupted.
  • the cost strategies of each ECU and its components are accumulated, and the price strategy of the entire vehicle system is compared.
  • an increase in the price of these components is not acceptable at all.
  • the present invention has been made to solve the above-described problems, and provides an in-vehicle network having a function of performing configuration verification while suppressing an increase in processing load (and cost) of each in-vehicle control device. And it aims at improving the security of vehicles.
  • An in-vehicle network system includes a configuration management device that authenticates an in-vehicle control device, and the configuration management device uses a registration device connected to the in-vehicle network to transmit configuration certification data used for performing configuration certification. Delivered to the control device.
  • the configuration management device for authenticating the in-vehicle control device is arranged in the in-vehicle network, it is not necessary to hold the in-vehicle key information outside the vehicle. Therefore, it is not necessary to communicate with the outside of the vehicle using an unsafe communication method, and security is improved.
  • the registration device does not necessarily have to be always connected to the in-vehicle network, and when registering a new in-vehicle control device, the operator can manually connect the registration device to the in-vehicle network.
  • the cost of the in-vehicle network itself does not increase, so that a strong authentication method can be used between the registration device and the configuration management device. Thereby, security can be improved, suppressing the cost as the whole vehicle-mounted network.
  • FIG. 1 is a configuration diagram of an in-vehicle network system 1000 according to Embodiment 1.
  • FIG. FIG. 10 is a diagram for explaining a sequence for the configuration management server 103 to authenticate the network registration device 102. It is a figure which shows the structural example of the vehicle-mounted network described in patent document 1.
  • FIG. It is a figure which shows the structural example of the vehicle-mounted network system 1000 which concerns on Embodiment 2.
  • FIG. It is a figure which shows the form which shares structure certification
  • FIG. 10 is a diagram for explaining an operation example in which the configuration proof method described in the first to third embodiments is applied to uses other than the configuration proof. It is a figure which shows the network topology example of the vehicle-mounted network with which the typical highly functional vehicle of recent years is provided.
  • FIG. 1 is a configuration diagram of an in-vehicle network system 1000 according to Embodiment 1 of the present invention.
  • the in-vehicle network system 1000 is an in-vehicle network that connects an ECU that controls the operation of the vehicle.
  • an ECU that controls the operation of the vehicle.
  • only one target ECU 101 that is the object of configuration certification is illustrated, but the ECU that can be connected to the in-vehicle network system 1000 is not limited to this.
  • the in-vehicle network system 1000 is connected to the target ECU 101 and the configuration management server 103 via the in-vehicle network.
  • the network registration device 102 is connected to the in-vehicle network system 1000 as necessary in order to cause the target ECU 101 to participate in the in-vehicle network.
  • the configuration management server 103 is a device that can communicate with the target ECU 101 and the network registration device 102 via the in-vehicle network.
  • the configuration management server 103 may be configured as one type of ECU, or may be configured as any other communication device.
  • the configuration management server 103 authenticates the target ECU 101 and the network registration device 102.
  • the purpose of authenticating the target ECU 101 is to confirm whether or not the target ECU 101 has the right to participate in the in-vehicle network.
  • the purpose of authenticating the network registration device 102 is to check whether or not the network registration device 102 has the right to join the target ECU 101 to the in-vehicle network.
  • the network registration device 102 is a device that causes the target ECU 101 to participate in the in-vehicle network.
  • the participation in the in-vehicle network means that the target ECU 101 distributes the configuration certification data necessary for communicating with other ECUs via the in-vehicle network to the target ECU 101.
  • the network registration device 102 In order for the network registration device 102 to cause the target ECU 101 to participate in the in-vehicle network, it is necessary to receive authentication by the configuration management server 103 in advance.
  • the network registration device 102 need not always be connected to the in-vehicle network.
  • the network registration device 102 can be manually connected to the in-vehicle network only when the target ECU 101 participates in the in-vehicle network.
  • Step S111 Authentication request
  • the operator operates the network registration device 102 to start work (registration processing) for causing the target ECU 101 to participate in the in-vehicle network.
  • the network registration device 102 requests the configuration management server 103 via the in-vehicle network to authenticate itself.
  • Step S111 Authentication request: supplement
  • the network registration device 102 issues an authentication request to the configuration management server 103 and simultaneously notifies the configuration management server 103 of identification information (details will be described later with reference to FIG. 5) of the target ECU 101 to participate in the in-vehicle network.
  • identification information include ECU-ID (part number), software version, and the like. Such identification information can be given by an operator manually inputting it on the network registration apparatus 102 or the like.
  • Step S112 Distribution of configuration certification key
  • the configuration management server 103 authenticates the network registration device 102 according to a predetermined authentication algorithm (details will be described later with reference to FIG. 2).
  • the configuration management server 103 updates an internal database (details will be described later with reference to FIG. 5) using information received from the network registration device 102 at the time of an authentication request.
  • a configuration proof key (common key) unique to the target ECU 101 (details will be described later with reference to FIG. 6) is generated and distributed to the network registration device 102.
  • Step S113 Key storage command
  • the network registration device 102 relays the configuration certification key (common key) unique to the target ECU 101 distributed from the configuration management server 103 to the target ECU 101 and instructs the target ECU 101 to store it.
  • Step S114 Notification of completion of storage
  • the target ECU 101 stores the configuration certification key (common key) unique to the target ECU 101 received in step S113 in its own memory, and notifies the network registration device 102 that it has successfully joined the in-vehicle network.
  • Step S115 Configuration Proof Request
  • the configuration management server 103 Based on the estimation that the configuration certification key (common key) distributed via the network registration device 102 in step S112 is held in the target ECU 101, the configuration management server 103 sends the configuration management server 103 to the target ECU 101. It asks them to prove their authenticity.
  • Step S116 Answer of configuration proof
  • the target ECU 101 returns an answer based on the shared knowledge of the configuration certification key (common key) to the configuration management server 103 to prove the authenticity of the own station.
  • Step S116 Answer of configuration proof: supplement
  • the configuration certification request and reply in steps S115 to S116 should be made mutually between the configuration management server 103 and the target ECU 101. Therefore, the target ECU 101 may request a configuration certificate from the configuration management server 103 and answer the configuration management server 103 in the opposite direction of the arrows in steps S115 and S116 illustrated in FIG. Further, before the target ECU 101 discloses the configuration certificate to the configuration management server 103 by combining the above two-way exchanges, the target ECU 101 requests the configuration certificate of the configuration management server 103, and the target ECU 101 authenticates the configuration management server 103. It may take the form of a mutual handshake so as to reply to the configuration management server 103 after confirming the characteristics.
  • FIG. 2 is a diagram illustrating a sequence in which the configuration management server 103 authenticates the network registration device 102.
  • the authentication sequence in FIG. 2 shows details of step S111 in FIG.
  • a method of authenticating the network registration apparatus 102 using a digital signature based on a public key cryptosystem is illustrated, but another authentication scheme such as challenge and response authentication may be used. It is assumed that a public key / private key pair of the network registration apparatus 102 is generated in advance and the public key is distributed to the configuration management server 103.
  • each step of FIG. 2 will be described.
  • the network registration device 102 requests the configuration management server 103 to authenticate that it is a legitimate terminal prior to the operation of registering the target ECU 101 on the network, for example, when it is first connected to the in-vehicle network. At this time, the identification code (or similar information) of the network registration apparatus 102 is also transmitted, and information for uniquely identifying itself is made clear to the configuration management server 103.
  • the regular terminal in this step means that the network registration device 102 is authorized by the manufacturer of the vehicle, has not been tampered with, or another device impersonates the regular network registration terminal 102. It is a terminal that is guaranteed not to be. That is, the terminal has a legitimate authority for allowing the target ECU 101 to participate in the in-vehicle network.
  • the configuration management server 103 executes an authentication start process (S202). Specifically, a seed code is generated using a pseudo-random number and returned to the network registration device 102 (S203). In addition, the public key corresponding to the network registration device 102 is specified using the identification code received from the network registration device 102 in step S201.
  • Steps S204 to S205 The network registration device 102 signs the seed code received from the authentication server in step S203 with its own private key (S204), and returns it as a signed code to the configuration management server 103 (S205).
  • the configuration management server 103 reads the public key specified in step S202, and uses this to decrypt the signed code received from the network registration device 102 in step S205.
  • the configuration management server 103 compares the decryption result with the seed code transmitted to the network registration apparatus 102 in step S203, and determines that the network registration apparatus 102 is a legitimate terminal if they match. If they do not match, the network registration device 102 has not been authorized.
  • the configuration management server 103 transmits a confirmation response indicating that the authentication sequence has ended to the network registration device 102 (S207). Thereafter, the network registration device 102 notifies the configuration management server 103 of ⁇ ECU-ID, software version ⁇ of the target ECU 101 that is scheduled to participate in the in-vehicle network (S208).
  • the configuration management server 103 sends a configuration certification key (to the target ECU 101 via the network registration device 102 that can strictly verify authenticity). Distribute the common key. As a result, the target ECU 101 can easily share a configuration proof key (common key) without performing sophisticated calculations as in the KPS method, which consumes a large amount of calculation resources. In addition, the security of the in-vehicle network can be improved.
  • the network registration apparatus 102 does not necessarily need to be always connected to the in-vehicle network system 1000, so that the network registration apparatus is used using a high-performance apparatus independent from the in-vehicle network system 1000. 102 can be configured. Thereby, strong authentication processing can be performed between the configuration management server 103 and the network registration device 102 while suppressing the cost of the ECU configuring the in-vehicle network system 1000. For this authentication process, a technique stronger than the authentication process between the configuration management server 103 and the target ECU 101 can be used. That is, since the performance of the network registration device 102 can be made higher than that of the target ECU 101, a strong authentication process that consumes a great amount of resources can be performed.
  • the configuration management server 103 that authenticates the target ECU 101 and the network registration device 102 is arranged inside the in-vehicle network. This eliminates the need for each device to communicate with the outside of the vehicle in order to perform the authentication process, thereby improving security. Further, by concentrating resources for performing the authentication process in the configuration management server 103, the cost of other ECUs can be suppressed.
  • FIG. 4 the in-vehicle network system 1000 according to the second embodiment (FIG. 4) will be compared with the conventional example (FIG. 3) described in Patent Document 1, and the difference between the configuration and security will be described.
  • FIG. 3 is a diagram illustrating a configuration example of the in-vehicle network described in Patent Document 1, and is described for comparison with the second embodiment.
  • an ECU master 105 exists in the in-vehicle network 202, and this holds an identification number ⁇ vehicle ID ⁇ for each vehicle.
  • the ECU master 105 When executing the initialization process, the ECU master 105 sets ⁇ vehicle ID, ECU-ID, software version ⁇ information as a set to the center server 203 installed outside the in-vehicle network 202, and sets ⁇ common The key generation source ⁇ is requested to be distributed (step S311).
  • the ECU-ID is an identifier of the ECU master 105
  • the software version is a version of software installed in the ECU master 105.
  • the center server 203 distributes ⁇ common key generation source ⁇ in response to the request (step S312). These exchanges are encrypted with an initialization key fixedly set in the ECU master 105 (external communication F221).
  • the ⁇ common key generation source ⁇ distributed from the center server 203 is an “information source for deriving a common key” used only for communication between ECUs belonging to the in-vehicle network 202.
  • the ⁇ common key generation source ⁇ is not used when communicating with the center server 203.
  • Target ECU 101 belonging to the in-vehicle network other than ECU master 105 obtains ⁇ vehicle ID ⁇ from ECU master 105. At this time, the target ECU 101 has not obtained ⁇ common key generation source ⁇ , and therefore the target ECU 101 communicates with the ECU master 105 without performing encryption (step S313).
  • the target ECU 101 assembles a set of ⁇ vehicle ID, ECU-ID, software version ⁇ using ⁇ vehicle ID ⁇ received from the ECU master 105, and distributes ⁇ common key generation source ⁇ to the center server 203. Request is made (step S314).
  • ECU-ID is the identifier of the target ECU 101
  • the software version is the version of software installed in the target ECU 101.
  • the center server 203 distributes ⁇ common key generation source ⁇ in response to the request (step S315). These exchanges are encrypted with an initialization key fixedly set in the target ECU 101 (external communication F222).
  • the center server 203 manages a set of ⁇ vehicle ID, ECU-ID, software version ⁇ and ⁇ common key generation source ⁇ of all vehicles. Therefore, when the center server 203 is illegally invaded, all vehicle keys are leaked. Further, if a failure occurs in the center server 203 regardless of intention or negligence, there is a risk that keys of all vehicles are lost.
  • step S313 The flow of ⁇ vehicle ID ⁇ (step S313) between the ECU master 105 and the target ECU 101 when the initialization process is performed is not encrypted, and is easily captured from outside the in-vehicle network 202. be able to. This is a clue that a malicious third party analogizes the set of ⁇ vehicle ID, ECU-ID, software version ⁇ (used in steps S311 and S314).
  • FIG. 4 is a diagram illustrating a configuration example of the in-vehicle network system 1000 according to the second embodiment.
  • a configuration management server 103 is installed in the in-vehicle network 202.
  • a procedure for causing the new target ECU 101 to participate in the in-vehicle network 202 will be described in detail.
  • the operator connects the network registration device 102 to the connection vehicle connector 104 and communicates with the configuration management server 103 for authentication. At this time, the operator inputs the ECUI-ID or the like of the target ECU 101 that is about to participate in the in-vehicle network 202 on the network registration device 102 and transmits it to the configuration management server 103. This procedure corresponds to step S111 in FIG.
  • the configuration management server 103 strictly examines and verifies the authenticity of the network registration device 102.
  • the configuration management server 103 confirms that the network registration device 102 is authentic, the configuration management server 103 issues a ⁇ common key ⁇ specific to the target ECU 101 (step S112).
  • the network registration device 102 relays and stores this ⁇ common key ⁇ to the target ECU 101 (step S113). With the above procedure, the ⁇ common key ⁇ is securely shared between the configuration management server 103 and the target ECU 101.
  • the key information in the in-vehicle network 202 is managed by the configuration management server 103 built in each vehicle. Therefore, there is no vulnerability due to the central server 203 collecting information on all vehicles. Also, the ⁇ common key ⁇ is unique independently for each vehicle, and even if it is leaked, there is no security concern for other vehicles.
  • the identification information of the ECUs constituting the members of the in-vehicle network 202 is managed only inside the configuration management server 103. Therefore, it is not necessary to disclose these identification information to other ECUs via the in-vehicle network 202. Therefore, it is robust against the risk of leakage of such information.
  • the network registration device 102 may be configured as a simple device having only the function of storing the common key information in a non-volatile memory (EEPROM: Electronically Erasable and Programmable Read-Only Memory) on the target ECU 101, and control software may be provided. You may comprise as a program rewriting apparatus which writes the said common key information directly in flash ROM to memorize
  • EEPROM Electronically Erasable and Programmable Read-Only Memory
  • the dealer collects the vehicle and rewrites the program of the corresponding in-vehicle ECU.
  • the program rewriting device is used to simultaneously update the target ECU software version, update the configuration certification key (common key), and update the configuration management server 103 registration information (ECU-ID, software version, etc.). If it is possible, it is convenient for the operator. Therefore, it can be said that the network registration device 102 preferably has a function as a program rewriting device.
  • the network registration device 102 is illustrated as being directly connected to the in-vehicle network 202, but the network registration device is connected to a communication network outside the vehicle using a signal coupling method other than wired communication such as wireless communication. 102 may be configured as an element of the communication network. Also in this case, authentication between the in-vehicle configuration management server 103 and the network registration device 102 is strictly performed.
  • FIG. 5 is a diagram showing a form (information distribution form) in which the configuration certification information (common key) is shared between the configuration management server 103 and the target ECU 101.
  • a form information distribution form
  • the configuration certification information common key
  • FIG. 5A shows an example of data stored in the database 410 in the configuration management server 103.
  • Identification information ECU-ID, software version, etc.
  • Data 411 is an authentication key of the configuration management server itself, and is distributed equally to all on-vehicle ECUs.
  • Databases 420, 430, and 440 shown in FIGS. 5B to 5D show data examples of configuration proof keys (common keys) stored in the memories of the target ECUs 101a to 101c, respectively.
  • the common key held by each target ECU 101 is issued by the configuration management server 103 and set via the network registration device 102.
  • ECU key information excluding the ECU-ID and the software version in the data 412 of the configuration management server database 410 is transferred to each target ECU 101.
  • This common key is key information used by each target ECU 101 to prove its authenticity to the configuration management server 103.
  • this information is referred to as “ECU key”.
  • the common key information excluding the ECU-ID and the software version in the data 411 of the configuration management server database 410 is also transferred to each target ECU 101.
  • This common key is key information used by the configuration management server 103 to prove its authenticity to the target ECU 101.
  • this information is referred to as “server key”.
  • communication identification information 413 such as a channel number or a message ID used when the configuration management server 103 and each target ECU 101 communicate can be distributed to each target ECU 101.
  • the communication identification information 413 is information for specifying the type of communication data.
  • the configuration management server 103 can use the message ID 0x15 when transmitting the common key to the target ECU 101a, and can use the message ID 0x17 when transmitting the common key to the target ECU 101b.
  • Each target ECU 101 can identify what the received data describes by the value of the message ID.
  • Each target ECU 101 does not grasp the communication channel used in the configuration proof before participating in the in-vehicle network 202. Therefore, a configuration proof key (common key) can be distributed and a message ID can be distributed to each target ECU 101.
  • the message ID is stored as data 421, 431, 441 in the database of each target ECU 101, respectively.
  • attribute information such as ECU-ID and software version stored in the configuration management server database 410 can be distributed to each target ECU 101. These pieces of information are useful information for the network registration device 102 and the target ECU 101.
  • the network registration device 102 may want to investigate what ECU group / software group the vehicle ECU is currently configured.
  • the in-vehicle ECU may want to investigate whether the software version of another in-vehicle ECU that is the counterpart of the cooperative control corresponds to the control software of the local station.
  • the configuration management server 103 may distribute the information held in the database 410 to the network registration device 102 or the target ECU 101.
  • the database 410 shown in FIG. 5 may be configured so that the operator can browse and update the contents using the network registration device 102.
  • the configuration management server 103 authenticates the network registration device 102 prior to browsing or updating, as in the case of configuration certification.
  • FIG. 6 is a diagram illustrating a method by which the configuration management server 103 generates a configuration certification key (common key). The procedure for generating the configuration certification key will be described below with reference to FIG.
  • the vehicle identification number 501 is a number uniquely assigned to each vehicle, and the configuration management server 103 holds information internally.
  • the ECU-ID (part number) 502 and the software version 503 are the ECU-ID (part number) and software version of the target ECU 101 that is going to participate in the in-vehicle network 202.
  • the random number 504 is a random number appropriately generated inside the configuration management server 103. For example, it can be generated using a device that generates a uniform random number with white noise fluctuation of the semiconductor threshold. For simplicity, for example, a numerical sequence obtained by capturing a free-run counter of a microcomputer at an appropriate timing may be adopted as the random number 504.
  • the configuration management server 103 inputs these values to the one-way hash function 505.
  • the one-way hash function 505 outputs a fixed-length ECU-specific common key 506.
  • the common key 506 or a value calculated using the common key 506 can be used as a configuration proof key.
  • the one-way hash function 505 is used to make it impossible to restore information such as the vehicle identification number 501, ECU-ID (part number) 502, and software version 503 from the ECU-specific common key 506. Use. It is also important that the common key 506 changes when the input value changes even a little, the generated values are less likely to collide, and the combination of input values that give the same output value is unpredictable.
  • the vehicle identification number 501 is used as the input value of the one-way hash function 505, even if the target ECU 101 having the same ECU-ID (part number) 502 is registered on the network, the value of the common key 506 differs for each vehicle. . Since the random number 504 is used as the input value of the one-way hash function 505, the same ECU-ID (part number) 502 and the same in-vehicle ECU of the same software version 503 are allowed to participate in the in-vehicle network 202 of the same vehicle. However, the value of the common key 506 is different every time participation is performed.
  • This mechanism can improve the ability to detect ECU tampering and unauthorized ECU replacement.
  • a function other than the one-way hash function 505 may be used as long as the same effect can be exhibited. However, from the viewpoint of preventing the original value from being estimated based on the common key 506, one-way It is desirable to adopt a function.
  • FIG. 7 is a sequence diagram illustrating a procedure by which the configuration management server 103 authenticates the target ECU 101.
  • the server key and the ECU key described above are used as passwords.
  • each step of FIG. 7 will be described.
  • Steps S701 to S702 Start of configuration certification
  • the configuration management server 103 transmits a configuration certification request to the target ECU 101 (S701).
  • This configuration certification request may be performed when the vehicle is in a specific state (immediately after starting, idling, immediately after the ignition is turned off, etc.), or may be performed periodically.
  • the target ECU 101 returns a server authentication request in order to confirm whether or not it is the genuine configuration management server 103 that is requesting the certification (S702).
  • FIG. 7 Steps S701 to S702: Supplement
  • the communication sequence shown in FIG. 7 is performed using the communication channel or message ID stored in each ECU.
  • the configuration management server 103 discloses the server key as a server-side password in order to indicate its authenticity to the target ECU 101 (S703). If this server key matches the server key held in the target ECU 101, it is concluded that the configuration management server 103 is authentic (S704).
  • Steps S705 to S707 ECU side configuration certification
  • the target ECU 101 confirms that the configuration management server 103 is authentic
  • the target ECU 101 transmits the ECU key as an ECU-side password to the configuration management server 103 (S705). If the key held in the database 410 matches the received ECU key, the configuration management server 103 determines that the target ECU 101 has not been tampered with (S706).
  • the configuration certification is completed by the above procedure, and the configuration management server 103 transmits a session end notification to the target ECU 101 (S707).
  • the configuration certification key (common key) directly to the in-vehicle network 202
  • the configuration certification key is used as a common key for challenge and response authentication. You can also. The procedure will be described with reference to FIG.
  • FIG. 8 is a sequence diagram of another method showing a procedure for the configuration management server 103 to authenticate the target ECU 101. Hereinafter, each step of FIG. 8 will be described.
  • Step S801 Request for proof of configuration
  • the configuration management server 103 transmits a configuration certification request to the target ECU 101 (S801).
  • This configuration certification request may be performed when the vehicle is in a specific state (immediately after starting, idling, immediately after the ignition is turned off, etc.), or may be performed periodically.
  • the target ECU 101 starts an authentication process for confirming whether or not it is the genuine configuration management server 103 that is requesting the certification.
  • FIG. 8 Steps S802 to S803
  • the target ECU 101 generates a random number (S802) and transmits it as challenge data for server authentication to the configuration management server 103 (S803).
  • the configuration management server 103 receives the server authentication challenge in step S803, receives this data and the server key as input, and calculates a response using a one-way hash function (S804).
  • the configuration management server 103 transmits the calculated response to the target ECU 101 as a server-side response (S805).
  • Step S806 The target ECU 101 inputs the random number generated in step S802 and the server key shared with the configuration management server 103 to the one-way hash function and returns from the configuration management server 103 as a response. Calculate the expected expected value. Since it is presumed that the configuration management server 103 and the target ECU 101 each adopt the same one-way hash function according to the rules, the output values of the one-way hash function with the same data as input should match. is there.
  • Steps S807 to S808 The target ECU 101 compares the value calculated in step S806 with the value received from the configuration management server 103 (S807). If the two values match, the authenticity of the configuration management server 103 has been proved, so the target ECU 101 sends a configuration certification challenge request to the configuration management server (S808).
  • Steps S809 to S810 Upon receiving the configuration certification challenge request transmitted by the target ECU 101 in step S808, the configuration management server 103 generates a random number (S809) and transmits it to the target ECU 101 as configuration certification challenge data (S810).
  • the means for generating random numbers is the same as that of the target ECU 101.
  • Steps S811 to S813 The configuration management server 103 uses the challenge data and ECU key transmitted in step S810 to calculate an expected response value in the same procedure as in step S806 (S811).
  • the target ECU 101 uses the challenge data and ECU key transmitted by the configuration management server 103 in step S810 to calculate a response in the same procedure as in step S804 (S812), and returns the response to the configuration management server 103 (S813).
  • Steps S814 to S815) The configuration management server 103 compares the configuration proof response returned from the target ECU 101 in step S813 with the expected value calculated in step S811. If they match, the configuration proof of the target ECU 101 is obtained (S814). Thereafter, the configuration management server 103 transmits a session end notification to the target ECU 101 (S815).
  • the configuration management server 103 identifies the identification information (ECU-ID (part number), software version, etc.) of all in-vehicle ECUs connected to the in-vehicle network 202. ).
  • This management form is configured as distributed control in which each vehicle individually holds its own identification information without using an external server that collects information on all vehicles. Therefore, it is robust as an information management form, and even if the configuration management server 103 of an individual vehicle is broken, a security crisis does not spread to all vehicles.
  • the configuration certification key (common key) is securely distributed with the help of the reliable network registration device 102. can do.
  • the configuration management server 103 and the target ECU 101 can authenticate each other and prove the authenticity of each other with simple challenge and response authentication as described above.
  • the in-vehicle network system 1000 when performing configuration certification, advanced encryption communication (general common key encryption or public key encryption) or common key distribution technology (KPS method or the like) is used. There is no need to use it. That is, it is not necessary to waste calculation resources such as CPU / ROM / RAM in the current ECU for the configuration proof, and the mounting cost does not increase. Therefore, it can be said that this method is a method excellent in cost performance as a method for easily adding a configuration proof function to the in-vehicle network system 1000 and combating tampering of the ECU.
  • advanced encryption communication general common key encryption or public key encryption
  • KPS method or the like common key distribution technology
  • FIG. 9 and FIG. 10 disclose the configuration proof procedure of the challenge and response method shown in FIG. 8 as a flowchart from the viewpoint of software implementation. Accordingly, the function is not completely equivalent to the sequence shown in FIG. 8 and includes an abnormal system process and a warning system process at the time of diagnosis NG.
  • FIG. 9 is a flowchart showing processing executed inside the configuration management server 103. Hereinafter, each step of FIG. 9 will be described.
  • Steps S901 to S905 Start of configuration certification
  • the configuration management server 103 reads the common key of the target ECU 101 to be verified from the database 410 and prepares for the configuration certification (S901). Thereafter, a configuration certification request is transmitted to the target ECU 101 (S902), and a timer is initialized in preparation for timeout measurement (S903).
  • the configuration management server 103 waits for server authentication challenge data to arrive (S904). If data arrives, the process proceeds to step S906. If server authentication challenge data does not arrive and it is determined that a timeout has occurred (S905), it is determined that the target ECU 101 is not responding, and the process proceeds to step S917.
  • Steps S906 to S910 Server side authentication
  • the configuration management server 103 Upon receiving the server authentication challenge data, the configuration management server 103 calculates a response using the server key (S906), and returns the response to the target ECU 101 (S907). Thereafter, a timer is initialized in preparation for timeout measurement for waiting for determination on the ECU side (S908).
  • the configuration management server 103 waits for a challenge request for configuration proof from the target ECU 101 (S909), and when the request is received, the target ECU 101 has accepted server authentication, and the process proceeds to step S911.
  • step S910 If the challenge request for proof has not arrived and it is determined that the timeout has occurred (S910), it is determined that there is a possibility that the target ECU 101 has not accepted the server authentication or that the target ECU 101 has been tampered with and does not know the procedure, and step S917. Transition to.
  • Steps S911 to S916 are steps for preparing data for implementing the configuration certification of the target ECU 101.
  • the configuration management server 103 generates a random number (S911) and transmits it to the target ECU 101 as configuration certification challenge data (S912). Thereafter, a timeout measurement timer is initialized (S913), and an expected response value is calculated using the ECU key of the target ECU 101 searched in step S901 (S914).
  • the configuration management server 103 waits for a response for configuration proof from the target ECU 101 (S915), and when there is a response, the process proceeds to step S918. If it is determined that a time-out has not occurred because the response for configuration certification has not arrived (S916), it is determined that the target ECU 101 may have been falsified and the procedure may not be known, and the process proceeds to step S917.
  • Step S917 ECU Fraud Detection & Warning Process
  • the configuration management server 103 outputs a warning signal that the target ECU 101 has been falsified or broadcasts communication data describing the fact to the in-vehicle network 202 via an appropriate interface.
  • Steps S918 to S920: Configuration Proof Result The configuration management server 103 compares the expected value calculated in step S914 with the configuration certification response received from the target ECU 101 (S918). If the two match, the configuration proof has been completed, so a session end notification is transmitted to the target ECU 101 (S919), and notification that the configuration proof has ended is sent. Thereafter, it is checked whether or not configuration certification has been completed for all on-vehicle ECUs to be inspected (S920). If it is completed, the processing in FIG. 9 is terminated. If it is not completed, the process returns to step S901.
  • the target ECU 101 is replaced with that of another vehicle, connected to the in-vehicle network 202 without executing the process of participating in the in-vehicle network 202, etc. It is determined that there has been a possibility of unauthorized tampering, and the process proceeds to step S917.
  • FIG. 10 is a flowchart showing processing executed in the target ECU 101. Hereinafter, each step of FIG. 10 will be described.
  • Steps S1001 to S1007 Server side authentication start
  • the target ECU 101 waits for a configuration certification request from the configuration management server 103, and when the request arrives, the target ECU 101 transitions to step S1002 (S1001).
  • the target ECU 101 generates a random number to confirm whether the configuration management server 103 has been tampered with (not a malicious eavesdropping device) (S1002), and transmits it as server authentication challenge data (S1003).
  • the target ECU 101 initializes a timeout measurement timer (S1004), and calculates an expected value of the response from the configuration management server 103 using the server key (S1005).
  • the target ECU 101 waits for a server authentication response from the configuration management server 103 (S1006), and upon receiving a reply, the target ECU 101 proceeds to step S1008. If the server authentication response does not arrive and it is determined that a timeout has occurred (S1007), it is determined that the configuration management server 103 may have been tampered with or replaced with a malicious eavesdropping device. Transition.
  • Steps S1008 to S1012 ECU side configuration certification start
  • the target ECU 101 compares the expected value calculated in step S1005 with the server authentication response received from the configuration management server 103 (S1008). If the two match, the authenticity of the configuration management server 103 has been confirmed, and the process proceeds to step S1009. If the expected value and the server authentication response do not match, it is determined that there is a possibility that the configuration management server 103 has been replaced with another vehicle, or that unauthorized tampering has occurred, and the process proceeds to step S1018. Transition.
  • the target ECU 101 requests the configuration management server 103 to transmit configuration certification challenge data for proving the authenticity of the local station (S1009).
  • a timer is initialized in preparation for timeout measurement for waiting for configuration certification challenge data from the configuration management server 103 (S1010).
  • the target ECU 101 waits for challenge data for configuration certification from the configuration management server 103, and upon receiving a reply, the target ECU 101 proceeds to step S1013. If the challenge data for configuration certification does not arrive and it is determined that the timeout has occurred (S1012), it is determined that the configuration management server 103 may have been tampered with and the procedure is unknown, and the process proceeds to step S1018.
  • the target ECU 101 calculates a response using the challenge data for configuration certification received from the configuration management server 103 and the ECU key (S1013), and returns the response to the configuration management server (S1014).
  • a timer is initialized in preparation for timeout measurement for monitoring a response from the configuration management server 103 (S1015).
  • the target ECU 101 waits for a session end notification from the configuration management server 103 and receives a reply, it means that the configuration management server 103 has completed the configuration certification, and thus ends the processing of FIG. 10 (S1016).
  • Step S1018 Configuration management server fraud detection & warning process
  • the target ECU 101 outputs a warning signal that the configuration management server 103 has been falsified or broadcasts communication data describing the fact to the in-vehicle network 202 via an appropriate interface.
  • the configuration certification is performed by mutual authentication between the configuration management server 103 and the target ECU 101. Thereby, it can be detected that the configuration management server 103 or the target ECU 101 has been tampered with and a warning to that effect can be transmitted.
  • FIG. 11 is a diagram for explaining an operation example in which the configuration certification method described in the first to third embodiments is applied to uses other than the configuration certification.
  • FIG. 11 there are two ECUs 101 (ECUs 101a and 101b), and an operation of transmitting and receiving a message with a digital signature between these ECUs is assumed.
  • the ECU key is information shared only between a pair of the configuration management server 103 and a specific in-vehicle ECU, but the server key is information shared by a plurality of in-vehicle ECUs. Therefore, it is conceivable that a message authentication code (MAC: Message Authentication Code) is transmitted / received between a plurality of in-vehicle ECUs using a server key to guarantee the authenticity of the message.
  • MAC Message Authentication Code
  • the server key is safely distributed from the configuration management server 103 when the target ECU 101 participates in the in-vehicle network 202, and does not leak to any other than the regular ECU belonging to the in-vehicle network 202. Therefore, if a digital signature (attaching a message authentication code) is implemented using this server key, other ECUs can confirm that the message is from the in-vehicle ECU that has been authenticated by the configuration management server 103. it can.
  • the ECU 101a inputs the message 1011a to be sent and the server key 1012a to the one-way hash function 1013a to generate a message authentication code (MAC) 1014a.
  • the message 1011a and the message authentication code (MAC) 1014a are packed (S1101), stored in the transmission buffer 1015a, and sent to the in-vehicle network 202 (S1102).
  • the ECU 101b receives the signal transmitted by the ECU 101a (S1103), stores it in the reception buffer 1016b, unpacks it according to the contract agreed with the transmission side (S1104), and separates it into a message 1011b and a message authentication code (MAC) 1014b. .
  • the ECU 101b inputs the message 1011b and the server key 1012b (estimated to be equal to the server key 1012a) to the one-way hash function 1013b to create a receiving side message authentication code (MAC) (S1105), and the MAC 1014b and the receiving side
  • the message authentication code (MAC) is compared by the comparator 1017b. If a determination result 1018b indicating that they match each other is obtained, it can be determined that the content of the message 1011b is certainly created by the ECU 101a and has not been altered in the middle.
  • one-way hash functions 1013a and 1013b adopt the same algorithm in accordance with the rules between ECUs.
  • FIG. 11 discloses an embodiment in which a message authentication code (MAC) is realized by using a server key held in common by ECUs that have participated in the in-vehicle network 202 in a regular manner by the network registration device 102, this application is used for message authentication.
  • the present invention is not limited to codes, and may be applied to encrypted communication between in-vehicle ECUs using a common key cryptosystem (for example, a DES system, an AES (Advanced Encryption Standard) system, etc.).
  • a common key cryptosystem for example, a DES system, an AES (Advanced Encryption Standard) system, etc.
  • FIG. 12 is a diagram illustrating an example of a network topology of an in-vehicle network provided in a typical high-performance vehicle in recent years.
  • Configurations and operations of the network registration device (also serving as a software rewriting device) 102, the configuration management server 103, each ECU, and the like are the same as those in the first to fourth embodiments.
  • gateway ECUs gateway ECUs
  • FIG. 12 a star-type network arrangement is adopted with the gateway ECU 201 as the center, but a plurality of stages of gateway ECUs 201 may be provided to adopt a cascade-type connection form.
  • a drive system network 301 includes a drive system network 301, a chassis / safety network 305, a body / electric system network 309, and an AV / information network 313.
  • An engine control ECU 302, an AT (Automatic Transmission) control ECU 303, and a HEV (Hybrid Electric Vehicle) control ECU 304 are connected to the drive system network 301.
  • a brake control ECU 306, a chassis control ECU 307, and a steering control ECU 308 are connected.
  • An instrument display ECU 310, an air conditioner control ECU 311, and an antitheft control ECU 312 are connected under the body / electrical system network 309.
  • a navigation ECU 314, an audio ECU 315, and an ETC / phone ECU 316 are connected under the AV / information network 313.
  • the vehicle outside communication unit 317 is connected to the gateway ECU 201 by the vehicle outside information network 322.
  • An ETC wireless device 318, a VICS (registered trademark) (vehicle information and communication system) wireless device 319, a TV / FM wireless device 320, and a telephone wireless device 321 are connected to the outside communication unit 317.
  • the network registration device 102 is configured to connect as one node of the vehicle information network 322 via the connection vehicle connector 104 provided in the vehicle. Instead, it may be connected to another network (drive network 301, chassis / safety network 305, body / electric system network 309, AV / information network 313) or gateway ECU 201 alone. In other words, the mechanical arrangement is irrelevant, and the electric signal may reach the target ECU directly or via the gateway ECU 201.
  • the function of the network registration device 102 can also be implemented from the external communication network through the telephone wireless device 321 over the network.
  • database search of the configuration management server 103, maintenance of configuration certification data of the target ECU 101, and the like can be considered. Even in this case, the same technique as in the first to fourth embodiments can be used.
  • the method of rewriting the ECU software over the telephone network or over the Internet is an important technology that lowers the implementation cost when dealing with problems such as recall, and is expected to become a common practice in the future.
  • the configuration management server 103 is directly connected under the communication gateway ECU 201, but the location of the configuration management server 103 on the network may be arbitrary. That is, if an electrical signal connection can be ensured, other networks (drive network 301, chassis / safety network 305, body / electric system network 309, AV / information network 313, vehicle information network 322, etc.) ) May be connected directly.
  • other networks drive network 301, chassis / safety network 305, body / electric system network 309, AV / information network 313, vehicle information network 322, etc.
  • the communication gateway ECU 201 also serves as the configuration management server 103 from the following two viewpoints.
  • the communication from the network registration device 102 is communicated with the in-vehicle network (the drive system network 301, the chassis / safety network 305, the body / electric system network 309, AV to which the target ECU 101 belongs. / Can be electrically disconnected from the information system network 313).
  • the firewall firewall
  • each of the above-described configurations, functions, processing units, etc. can be realized as hardware by designing all or a part thereof, for example, with an integrated circuit, or the processor executes a program for realizing each function. By doing so, it can be realized as software.
  • Information such as a program and a table for realizing each function can be stored in a storage device such as a memory or a hard disk, or a storage medium such as an IC card or a DVD.

Abstract

　各車載制御装置の処理負荷（およびコスト）の上昇を抑えつつ、構成証明を実施する機能を備えた車載ネットワークを提供し、車両のセキュリティを向上させる。　本発明に係る車載ネットワークシステムは、車載制御装置を認証する構成管理装置を備え、構成管理装置は、構成証明を実施するために用いる構成証明データを、車載ネットワークに接続する登録装置を介して車載制御装置に配信する（図１参照）。

Description

車載ネットワークシステム
　本発明は、車載ネットワークシステムに関する。
　近年、乗用車、トラック、バス等には、各機能部を制御する車載ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）が多数搭載されている。各ＥＣＵは車載ネットワークを介して相互接続し、協調動作する。
　通常、車載ＥＣＵが搭載している制御プログラムは、車載ＥＣＵに内蔵されているマイクロコンピュータのフラッシュＲＯＭ（Ｒｅａｄ　Ｏｎｌｅ　Ｍｅｍｏｒｙ）などの記憶装置に格納されている。この制御プログラムのバージョンは、製造者によって管理されており、正規のソフトウェアバージョンを組み合わせることにより、単独機能および車載ネットワークを通じての協調機能が正常に動作するように意図されている。
　したがって、意図しないソフトウェアを搭載した車載ＥＣＵ、または意図的に改竄された車載ＥＣＵが車載ネットワークに接続されることは、車両のセキュリティの観点から看過できない。
　各車載ＥＣＵが自局のソフトウェアの真正性を外部に証明すること、さらには全ての関連する車載ＥＣＵの真正性を証明することを、構成証明と呼ぶ。構成証明が得られた場合は、製造者によって提供された正しいプログラムを組み合わせ、意図した制御が実施されているという確証となる。
　下記特許文献１には、共通鍵または共通鍵生成源を複数の車載ＥＣＵ間で共有し、この情報を共有していると推定されているＥＣＵ間で暗号化通信が成立するか否かにより、上記構成証明を実施する手法が開示されている。
　下記特許文献２には、ＫＰＳ（Ｋｅｙ　Ｐｒｅｄｉｓｔｒｉｂｕｔｉｏｎ　Ｓｙｓｔｅｍ）方式の共通鍵配信手法が開示されている。同方式は、特許文献１において共通鍵生成源として利用することができる。
特開２０１０－１１４００号公報 特公平５－４８９８０号公報
　上記特許文献１では、共通鍵または共通鍵生成源を複数のＥＣＵ間で共有させるため、センターサーバなどの外部インフラが必要である。また、車載ＥＣＵ間で暗号化通信が成立することをもって構成証明に代えるため、暗号化通信を実施する際に多大な計算機パワーが必要となる。以下、これら２点の課題について詳述する。
（１）センターサーバについて
（１．１）情報集約について
　センターサーバは、全車の鍵情報が集約されている外部サーバであり、車載ネットワークを構成する各車載ＥＣＵはそれぞれセンターサーバに接続して鍵情報を受け取らなければならない。鍵情報の全てがセンターサーバに集約されているため、車載ＥＣＵとセンターサーバとの間の通信が妨害されたり、センターサーバ自体が攻撃されたり、悪意の第３者がセンターサーバになりすましたりした場合は、システム全体が崩壊しかねない。
（１．２）センターサーバとの間の通信について
　ＫＰＳ方式によって配信する共通鍵生成源は、車載ネットワークに参加しているＥＣＵ間で通信するために用いるものである。したがって、ＥＣＵ間で安全に通信するためには、まず初期化処理としてセンターサーバから共通鍵生成源を取得する必要がある。このとき各ＥＣＵがセンターサーバと通信するために用いる暗号化鍵は、ＥＣＵ毎に固有の暗号化鍵ではなく、固定の暗号化鍵を使わざるを得ない。なぜなら、車載ＥＣＵは、部品メーカにより量産され組み立てメーカに納入されるものであり、初期化処理のための暗号化鍵は、車種単位、同一部品番号単位、またはＩＤの等しいロット単位で、必然的にバリエーションが固定されるためである。暗号化鍵が固定であると、悪意の第３者にとってはＥＣＵとセンターサーバの間の通信を盗聴しやすくなるので、これを利用して初期化鍵を不正入手される可能性がある。初期化鍵が不正入手されると、センターサーバの情報が不正に引き出される可能性がある。また、車載ＥＣＵに対して偽りの共通鍵を配信し、他の車載ＥＣＵとの間の通信を妨害される可能性もある。
（２）暗号化通信について
　特許文献１に記載されている技術では、ＫＰＳ方式に基づいて通信相手方の鍵を復元する計算資源と、その鍵を用いて暗号化通信するための共通鍵暗号処理（例えば、ＤＥＳ：Ｄａｔａ　Ｅｎｃｒｙｐｔｉｏｎ　Ｓｔａｎｄａｒｄ方式の暗号処理）を実行する計算資源とが必要になる。これらの処理は、現状の車載ＥＣＵの能力（ＣＰＵの計算能力、ＲＯＭ／ＲＡＭの容量など）にとって非常に大きなリソースを要求する。したがって、特許文献１に記載されている暗号化通信を実現するためには、車載ＥＣＵのコスト上昇が避けられない。
　現状の車載ＥＣＵを設計する際には、各ＥＣＵおよびその構成部品の原価低減を積み上げて、車両システム全体の価格戦略を摺り合わせている。車載ＥＣＵの構成証明という目的に対して、これら構成部品の価格が上昇することは、到底許容できるものではない。
　本発明は、上記のような課題を解決するためになされたものであり、各車載制御装置の処理負荷（およびコスト）の上昇を抑えつつ、構成証明を実施する機能を備えた車載ネットワークを提供し、車両のセキュリティを向上させることを目的とする。
　本発明に係る車載ネットワークシステムは、車載制御装置を認証する構成管理装置を備え、構成管理装置は、構成証明を実施するために用いる構成証明データを、車載ネットワークに接続する登録装置を介して車載制御装置に配信する。
　本発明に係る車載ネットワークシステムは、車載制御装置を認証する構成管理装置が車載ネットワーク内に配置されているため、車内の鍵情報を車両外で保持する必要がない。したがって、安全でない通信方式を用いて車外と通信する必要がなくなり、セキュリティが向上する。また、登録装置は必ずしも車載ネットワークに常時接続されている必要はなく、車載制御装置を新規に登録する際に、オペレータが手作業で登録装置を車載ネットワークに接続させることができる。そのため、登録装置の処理能力を高めても、車載ネットワーク自体のコストは増加しないので、登録装置と構成管理装置の間では強固な認証方式を用いることができる。これにより、車載ネットワーク全体としてのコストを抑えつつセキュリティを向上させることができる。
実施形態１に係る車載ネットワークシステム１０００の構成図である。 構成管理サーバ１０３がネットワーク登録装置１０２を認証するシーケンスを説明する図である。 特許文献１に記載されている車載ネットワークの構成例を示す図である。 実施形態２に係る車載ネットワークシステム１０００の構成例を示す図である。 構成管理サーバ１０３と目標ＥＣＵ１０１の間で構成証明情報（共通鍵）を共有する形態を示す図である。 構成管理サーバ１０３が構成証明用鍵（共通鍵）を生成する方法を示す図である。 構成管理サーバ１０３が目標ＥＣＵ１０１を認証する手順を説明するシーケンス図である。 構成管理サーバ１０３が目標ＥＣＵ１０１を認証する手順を示す別方式のシーケンス図である。 構成管理サーバ１０３の内部で実行される処理を示すフローチャートである。 目標ＥＣＵ１０１の内部で実行される処理を示すフローチャートである。 実施形態１～３で説明した構成証明手法を、構成証明以外の用途に応用した動作例を説明する図である。 近年の代表的な高機能車両が備えている車載ネットワークのネットワークトポロジー例を示す図である。
＜実施の形態１＞
　図１は、本発明の実施形態１に係る車載ネットワークシステム１０００の構成図である。車載ネットワークシステム１０００は、車両の動作を制御するＥＣＵを接続する車内ネットワークである。ここでは、構成証明の対象である目標ＥＣＵ１０１を１台のみ例示したが、車載ネットワークシステム１０００に接続することができるＥＣＵは、これに限られるものではない。
　車載ネットワークシステム１０００には、目標ＥＣＵ１０１と構成管理サーバ１０３が車載ネットワークを介して接続されている。また、目標ＥＣＵ１０１を車載ネットワークに参加させるため、必要に応じてネットワーク登録装置１０２が車載ネットワークシステム１０００に接続される。
　構成管理サーバ１０３は、車載ネットワークを介して目標ＥＣＵ１０１およびネットワーク登録装置１０２と通信することのできる装置である。構成管理サーバ１０３は、ＥＣＵの１種として構成してもよいし、その他任意の通信装置として構成してもよい。構成管理サーバ１０３は、目標ＥＣＵ１０１とネットワーク登録装置１０２を認証する。目標ＥＣＵ１０１を認証する目的は、目標ＥＣＵ１０１が車載ネットワークに参加する正当権限を有しているか否かを確認することである。ネットワーク登録装置１０２を認証する目的は、ネットワーク登録装置１０２が目標ＥＣＵ１０１を車載ネットワークに参加させる正当権限を有しているか否かを確認することである。
　ネットワーク登録装置１０２は、目標ＥＣＵ１０１を車載ネットワークに参加させる装置である。車載ネットワークに参加させるとは、目標ＥＣＵ１０１が車載ネットワークを介して他のＥＣＵと通信するために必要な構成証明データを目標ＥＣＵ１０１に配信することである。ネットワーク登録装置１０２が目標ＥＣＵ１０１を車載ネットワークに参加させるためには、あらかじめ構成管理サーバ１０３による認証を受ける必要がある。
　ネットワーク登録装置１０２は、必ずしも車載ネットワークに常時接続されている必要はない。例えば、車両の製造工程において車載ネットワークシステム１０００を構築する際に、目標ＥＣＵ１０１を車載ネットワークに参加させる作業を実施するときのみ、ネットワーク登録装置１０２を手作業で車載ネットワークに接続することができる。
　以下、図１にしたがって、ネットワーク登録装置１０２が目標ＥＣＵ１０１を車載ネットワークに参加させる手順を説明する。
（図１：ステップＳ１１１：認証要求）
　オペレータは、ネットワーク登録装置１０２を操作して、目標ＥＣＵ１０１を車載ネットワークに参加させる作業（登録処理）を開始する。ネットワーク登録装置１０２は、登録処理を開始すると、構成管理サーバ１０３に対し、自己を認証するように車載ネットワークを介して要求する。
（図１：ステップＳ１１１：認証要求：補足）
　ネットワーク登録装置１０２は、構成管理サーバ１０３に認証要求を出すと同時に、車載ネットワークに参加させる目標ＥＣＵ１０１の識別情報（詳細は後述の図５で説明）を構成管理サーバ１０３に通知する。この識別情報としては、例えばＥＣＵ－ＩＤ（部品番号）、ソフトウェアバージョンなどが挙げられる。これらの識別情報は、オペレータがネットワーク登録装置１０２上で手動入力するなどして与えることができる。
（図１：ステップＳ１１２：構成証明鍵の配布）
　構成管理サーバ１０３は、ネットワーク登録装置１０２から認証要求を受け取ると、所定の認証アルゴリズム（詳細は後述の図２で説明）にしたがってネットワーク登録装置１０２を認証する。構成管理サーバ１０３は、ネットワーク登録装置１０２の真正性を確認した場合は、認証要求時にネットワーク登録装置１０２から受け取った情報を用いて内部のデータベース（詳細は後述の図５で説明）を更新し、目標ＥＣＵ１０１固有の構成証明用鍵（共通鍵）（詳細は後述の図６で説明）を生成して、ネットワーク登録装置１０２に配信する。
（図１：ステップＳ１１３：鍵格納指令）
　ネットワーク登録装置１０２は、目標ＥＣＵ１０１に対して、構成管理サーバ１０３から配信された目標ＥＣＵ１０１固有の構成証明用鍵（共通鍵）を中継し、目標ＥＣＵ１０１にこれを格納するよう指示する。
（図１：ステップＳ１１４：格納完了通知）
　目標ＥＣＵ１０１は、ステップＳ１１３で受け取った目標ＥＣＵ１０１固有の構成証明用鍵（共通鍵）を自局のメモリに格納し、車載ネットワークに正常に参加した旨をネットワーク登録装置１０２に通知する。
（図１：ステップＳ１１５：構成証明要求）
　構成管理サーバ１０３は、ステップＳ１１２でネットワーク登録装置１０２を経由して配布しておいた構成証明用鍵（共通鍵）が目標ＥＣＵ１０１内に保持されている、との推定に基づいて、目標ＥＣＵ１０１に対して自局の真正性を証明するよう要求する。
（図１：ステップＳ１１６：構成証明回答）
　目標ＥＣＵ１０１は、構成管理サーバ１０３に対して構成証明用鍵（共通鍵）の共有知識に基づいた回答を返信し、自局の真正性を証明する。
（図１：ステップＳ１１６：構成証明回答：補足）
　ステップＳ１１５～Ｓ１１６における構成証明要求と回答は、構成管理サーバ１０３と目標ＥＣＵ１０１の間で相互になされるべきものである。したがって、図１に図示するステップＳ１１５とステップＳ１１６の矢印方向とは逆に、目標ＥＣＵ１０１が構成管理サーバ１０３に対して構成証明を要求し、構成管理サーバ１０３が回答してもよい。また、上記双方向のやり取りを合成して、目標ＥＣＵ１０１が構成管理サーバ１０３に対して構成証明を開示する前に、構成管理サーバ１０３の構成証明を要求し、目標ＥＣＵ１０１が構成管理サーバ１０３の真正性を確認しておいてから構成管理サーバ１０３に対して回答するように、相互的なハンドシェイクの形態を取ってもよい。
＜実施の形態１：ネットワーク登録装置の認証＞
　図２は、構成管理サーバ１０３がネットワーク登録装置１０２を認証するシーケンスを説明する図である。図２の認証シーケンスは、図１のステップＳ１１１の詳細を示すものである。ここでは、公開鍵暗号方式に基づくデジタル署名を用いてネットワーク登録装置１０２を認証する手法を例示するが、チャレンジ＆レスポンス認証など別の認証方式を用いることもできる。なお、あらかじめネットワーク登録装置１０２の公開鍵と秘密鍵のペアを生成し、公開鍵を構成管理サーバ１０３に配信しておくものとする。以下、図２の各ステップについて説明する。
（図２：ステップＳ２０１）
　ネットワーク登録装置１０２は、例えば車載ネットワークに最初に接続した時点など、目標ＥＣＵ１０１をネットワーク登録する動作に先立って、構成管理サーバ１０３に対し自己が正規端末であることを認証するように要求する。このとき、ネットワーク登録装置１０２の識別コード（またはそれに類する情報）を併せて送信し、自身を固有に識別する情報を構成管理サーバ１０３に対して明らかにする。
（図２：ステップＳ２０１：補足）
　本ステップでいう正規端末とは、ネットワーク登録装置１０２が当該車両のメーカによって認定された正規のものであること、改竄されたものでないこと、別の装置が正規のネットワーク登録端末１０２になりすましたものでないこと、などを保証された端末のことである。すなわち、目標ＥＣＵ１０１を車載ネットワークに参加させる正当権限を有する端末である。
（図２：ステップＳ２０２～Ｓ２０３）
　構成管理サーバ１０３は、認証開始処理を実行する（Ｓ２０２）。具体的には、疑似乱数を用いて種コードを生成し、ネットワーク登録装置１０２に返送する（Ｓ２０３）。また、ステップＳ２０１でネットワーク登録装置１０２から受け取った識別コードを用いて、ネットワーク登録装置１０２に対応する公開鍵を特定しておく。
（図２：ステップＳ２０４～Ｓ２０５）
　ネットワーク登録装置１０２は、ステップＳ２０３で認証サーバから受け取った種コードを自身の秘密鍵で署名し（Ｓ２０４）、署名済みコードとして構成管理サーバ１０３に返送する（Ｓ２０５）。
（図２：ステップＳ２０６）
　構成管理サーバ１０３は、ステップＳ２０２で特定しておいた公開鍵を読み出し、これを用いてステップＳ２０５でネットワーク登録装置１０２から受け取った署名済みコードを復号する。構成管理サーバ１０３は、その復号結果とステップＳ２０３でネットワーク登録装置１０２に送信した種コードを比較し、両者が一致すればネットワーク登録装置１０２が正規端末であると判断する。両者が一致しなければ、ネットワーク登録装置１０２は認証許可されなかったことになる。
（図２：ステップＳ２０７～Ｓ２０８）
　構成管理サーバ１０３は、認証シーケンスが終了した旨を、確認応答としてネットワーク登録装置１０２に対して送信する（Ｓ２０７）。その後、ネットワーク登録装置１０２は、これから車載ネットワークに参加させる予定の目標ＥＣＵ１０１の｛ＥＣＵ－ＩＤ，ソフトウェアバージョン｝を構成管理サーバ１０３に通知する（Ｓ２０８）。
＜実施の形態１：まとめ＞
　以上のように、本実施形態１に係る車載ネットワークシステム１０００において、構成管理サーバ１０３は、厳密に真正性を検証することができるネットワーク登録装置１０２を経由して、目標ＥＣＵ１０１に構成証明用鍵（共通鍵）を配布する。これにより、目標ＥＣＵ１０１は、多大な計算資源を消費するＫＰＳ方式のように高度な計算を実施することなく、簡便に構成証明用鍵（共通鍵）を共有することができるので、ＥＣＵコストを抑えつつ車載ネットワークのセキュリティを向上させることができる。
　また、本実施形態１に係る車載ネットワークシステム１０００において、ネットワーク登録装置１０２は必ずしも車載ネットワークシステム１０００に常時接続する必要はないので、車載ネットワークシステム１０００から独立した高性能な装置を用いてネットワーク登録装置１０２を構成することができる。これにより、車載ネットワークシステム１０００を構成するＥＣＵのコストを抑えつつ、構成管理サーバ１０３とネットワーク登録装置１０２の間で強固な認証処理を実施することができる。この認証処理には、構成管理サーバ１０３と目標ＥＣＵ１０１の間の認証処理よりも強固な手法を用いることができる。すなわち、ネットワーク登録装置１０２の性能を目標ＥＣＵ１０１よりも高くすることができるので、多大なリソースを消費する強固な認証処理を実施することができる。
　また、本実施形態１に係る車載ネットワークシステム１０００において、目標ＥＣＵ１０１およびネットワーク登録装置１０２を認証する構成管理サーバ１０３は、車載ネットワーク内部に配置されている。これにより、各装置は認証処理を実施するために車外と通信する必要がなくなり、セキュリティを向上させることができる。また、認証処理を実施するためのリソースを構成管理サーバ１０３に集約させることにより、他のＥＣＵのコストを抑えることができる。
＜実施の形態２＞
　本発明の実施形態２では、実施形態１で説明した車載ネットワークシステム１０００の具体的な構成例について説明する。
　以下、本実施形態２に係る車載ネットワークシステム１０００（図４）と、特許文献１に記載されている従来例（図３）とを比較し、両者の構成とセキュリティに関する違いを説明する。
＜実施の形態２：従来例の説明＞
　図３は、特許文献１に記載されている車載ネットワークの構成例を示す図であり、本実施形態２と対比するために記載したものである。図３において、車載ネットワーク２０２の中にＥＣＵマスタ１０５が存在しており、これが車両ごとの識別番号｛車両ＩＤ｝を保持している。
　ＥＣＵマスタ１０５は、初期化処理を実施するとき、車載ネットワーク２０２の外部に設置されているセンターサーバ２０３に対して、｛車両ＩＤ，ＥＣＵ－ＩＤ，ソフトウェアバージョン｝の情報をセットにして、｛共通鍵生成源｝を配信するよう要求する（ステップＳ３１１）。ＥＣＵ－ＩＤはＥＣＵマスタ１０５の識別子であり、ソフトウェアバージョンはＥＣＵマスタ１０５が搭載しているソフトウェアのバージョンである。
　センターサーバ２０３は、その要求に応じて｛共通鍵生成源｝を配布する（ステップＳ３１２）。これらのやり取りは、ＥＣＵマスタ１０５内部に固定的に設定された初期化鍵によって暗号化されている（外部通信Ｆ２２１）。
　センターサーバ２０３より配布される｛共通鍵生成源｝は、車載ネットワーク２０２に属するＥＣＵ間の通信のみに使われる「共通鍵を導出する情報源」である。｛共通鍵生成源｝は、センターサーバ２０３と通信する際には用いられない。
　ＥＣＵマスタ１０５以外の車載ネットワークに属する目標ＥＣＵ１０１は、ＥＣＵマスタ１０５より｛車両ＩＤ｝を入手する。この時点では、目標ＥＣＵ１０１は｛共通鍵生成源｝を入手していないので、目標ＥＣＵ１０１は暗号化を実施せずにＥＣＵマスタ１０５と通信する（ステップＳ３１３）。
　目標ＥＣＵ１０１は、ＥＣＵマスタ１０５より受け取った｛車両ＩＤ｝を用いて、｛車両ＩＤ，ＥＣＵ－ＩＤ，ソフトウェアバージョン｝のセットを組み立て、センターサーバ２０３に対して、｛共通鍵生成源｝を配信するよう要求する（ステップＳ３１４）。ＥＣＵ－ＩＤは目標ＥＣＵ１０１の識別子であり、ソフトウェアバージョンは目標ＥＣＵ１０１が搭載しているソフトウェアのバージョンである。
　センターサーバ２０３は、その要求に応じて｛共通鍵生成源｝を配布する（ステップＳ３１５）。これらのやり取りは、目標ＥＣＵ１０１内部に固定的に設定された初期化鍵によって暗号化されている（外部通信Ｆ２２２）。
　以上の構成より、特許文献１における方式には次のような脆弱性が存在することが明らかとなる。
（脆弱性１）車載ネットワーク２０２に属する全てのＥＣＵは、初期化処理を実施するとき、車載ネットワーク２０２の外部に配置されているセンターサーバ２０３と接続して｛共通鍵生成源｝の配布を受ける。そのため、初期化処理中にセンターサーバ２０３との間の接続が断たれた場合は、有効な車載ネットワークを構成することができない。
（脆弱性２）センターサーバ２０３は、全ての車両の｛車両ＩＤ，ＥＣＵ－ＩＤ，ソフトウェアバージョン｝と｛共通鍵生成源｝のセットを管理している。そのため、センターサーバ２０３が不正に侵入されると、全ての車両の鍵が流出する。また、故意・過失を問わずセンターサーバ２０３に障害が発生すると、全ての車両の鍵が紛失する危険を伴う。
（脆弱性３）初期化処理を実施するときの暗号化通信（外部通信Ｆ２２１および外部通信Ｆ２２２）が脆弱である。そのため、｛共通鍵生成源｝の配布をうける際に、ＥＣＵとセンターサーバ２０３との間の相互認証がセキュアではない。これは、部品として量産されるＥＣＵハードウェアの制約上、固定的でバリエーションの少ない暗号化鍵を使わざるを得ない特性に起因する。したがって、この暗号化鍵が破られると、センターサーバ２０３については特定車両の鍵情報が流出するおそれがあり、車載ＥＣＵについては悪意の第３者が偽りの鍵情報を配布することにより車載ネットワークへの妨害などが発生し得る。
（脆弱性４）初期化処理を実施するときのＥＣＵマスタ１０５から目標ＥＣＵ１０１の間の｛車両ＩＤ｝の流れ（ステップＳ３１３）は暗号化されていないので、車載ネットワーク２０２の外部から容易にキャプチャすることができる。これは、｛車両ＩＤ，ＥＣＵ－ＩＤ，ソフトウェアバージョン｝のセット（ステップＳ３１１およびステップＳ３１４で使用）を悪意の第３者が類推する糸口になる。
＜実施の形態２：本発明の説明＞
　図４は、本実施形態２に係る車載ネットワークシステム１０００の構成例を示す図である。車載ネットワーク２０２に、構成管理サーバ１０３が設置されている。この車載ネットワーク２０２に新たな目標ＥＣＵ１０１を参加させる手順を詳述する。
　オペレータは、ネットワーク登録装置１０２を接続用車両コネクタ１０４に接続し、構成管理サーバ１０３と通信して認証を受ける。このときオペレータは、これから車載ネットワーク２０２に参加させようとしている目標ＥＣＵ１０１のＥＣＵＩ－ＩＤなどをネットワーク登録装置１０２上で入力し、構成管理サーバ１０３に送信する。この手順は、図１のステップＳ１１１に相当する。
　構成管理サーバ１０３は、ネットワーク登録装置１０２の真正性を厳密に審査・検証する。構成管理サーバ１０３は、ネットワーク登録装置１０２が正規のものであることを確認した場合は、目標ＥＣＵ１０１固有の｛共通鍵｝を発行する（ステップＳ１１２）。
　ネットワーク登録装置１０２は、この｛共通鍵｝を目標ＥＣＵ１０１に中継して格納させる（ステップＳ１１３）。以上の手順により、構成管理サーバ１０３と目標ＥＣＵ１０１の間で｛共通鍵｝が安全に共有される。
　以上説明した本発明のメカニズムにより、先に説明した従来例における脆弱性は、以下に示すように改善される。先に説明した脆弱性に対応する改善点を、脆弱性と同じ順番で説明する。
（改善点１）各ＥＣＵが実施する通信は、車載ネットワーク２０２内部でクローズしており、車両外部との間の通信は実施されない。したがって、車載ネットワーク２０２に対して不正侵入を受ける機会も、情報漏洩を発生させる機会も少ない。
（改善点２）車載ネットワーク２０２内の鍵情報は、車両ごとに内蔵されている構成管理サーバ１０３が管理する。したがって、センターサーバ２０３に全車両の情報を集約させることによる脆弱性は存在しない。また、｛共通鍵｝は車両ごとに独立してユニークであり、これが流出しても他車両に対するセキュリティ上の懸案事項は発生しない。
（改善点３）初期化処理を実施するときの｛共通鍵｝の発行および中継は、厳密に相互認証を実施した構成管理サーバ１０３とネットワーク登録装置１０２の間で実施される。したがって、悪意の第３者による妨害などのセキュリティリスクは少ない。
（改善点４）車載ネットワーク２０２のメンバを構成するＥＣＵの識別情報、例えば｛車両ＩＤ，ＥＣＵ－ＩＤ，ソフトウェアバージョン｝は、構成管理サーバ１０３の内部のみで管理されている。そのため、車載ネットワーク２０２を介して他ＥＣＵにこれら識別情報を開示する必要がない。したがって、これら情報の漏洩リスクに対して頑健である。
＜実施の形態２：共通鍵の共有形態＞
　ネットワーク登録装置１０２は、目標ＥＣＵ１０１上の不揮発性メモリ（ＥＥＰＲＯＭ：Ｅｌｅｃｔｒｏｎｉｃａｌｌｙ　Ｅｒａｓａｂｌｅ　ａｎｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｒｅａｄ－Ｏｎｌｙ　Ｍｅｍｏｒｙ）に上記共通鍵情報を記憶させる機能のみを有する簡易装置として構成してもよいし、制御ソフトウェアを記憶するフラッシュＲＯＭに上記共通鍵情報を直接書き込むプログラム書換装置として構成してもよい。
　車両が市場に出た後に制御プログラムの不具合が発覚した場合、ディーラーは車両を回収して該当車載ＥＣＵのプログラムを書き換える。このとき、このプログラム書換装置を用いて、目標ＥＣＵのソフトバージョンアップ、構成証明用鍵（共通鍵）の更新、構成管理サーバ１０３の登録情報（ＥＣＵ－ＩＤ，ソフトウェアバージョンなど）の更新が同時に実施できるようにしておけば、作業者にとって便宜である。そのため、ネットワーク登録装置１０２はプログラム書換装置としての機能を兼ね備えていることが望ましいといえる。
　なお図４において、ネットワーク登録装置１０２は、車載ネットワーク２０２に直接接続するように図示されているが、無線通信などの有線以外の信号結合方式を用いて車外の通信網と接続し、ネットワーク登録装置１０２をその通信網の一要素として構成してもよい。この場合も、車内の構成管理サーバ１０３とネットワーク登録装置１０２との間の認証は厳密に実行される。
　図５は、構成管理サーバ１０３と目標ＥＣＵ１０１の間で構成証明情報（共通鍵）を共有する形態（情報分布形態）を示す図である。ここでは目標ＥＣＵ１０１が複数存在する例を示した。
　図５（ａ）は、構成管理サーバ１０３内のデータベース４１０が格納しているデータ例を示す。各車載ＥＣＵの識別情報（ＥＣＵ－ＩＤ，ソフトウェアバージョンなど）がデータ４１２で示すように保持されている。データ４１１は、構成管理サーバ自体の認証鍵であり、車載ＥＣＵ全てに等しく配布される。
　図５（ｂ）～（ｄ）に示すデータベース４２０、４３０、４４０は、目標ＥＣＵ１０１ａ～１０１ｃのメモリ上にそれぞれ記憶されている構成証明用鍵（共通鍵）のデータ例を示す。各目標ＥＣＵ１０１が保持している共通鍵は、構成管理サーバ１０３が発行し、ネットワーク登録装置１０２を経由して設定されたものである。
　すなわち、構成管理サーバ内データベース４１０のデータ４１２のうちＥＣＵ－ＩＤとソフトウェアバージョンを除いた情報が、各目標ＥＣＵ１０１に転写される。この共通鍵は、各目標ＥＣＵ１０１が構成管理サーバ１０３に対して自己の真正性を証明するために用いる鍵情報である。以降、この情報を「ＥＣＵ鍵」と呼ぶ。
　また、構成管理サーバ内データベース４１０のデータ４１１のうちＥＣＵ－ＩＤとソフトウェアバージョンを除いた共通鍵情報も、各目標ＥＣＵ１０１に転写される。この共通鍵は、構成管理サーバ１０３が目標ＥＣＵ１０１に対して自己の真正性を証明するために用いる鍵情報である。以降、この情報を「サーバ鍵」と呼ぶ。
　上述したＥＣＵ鍵とサーバ鍵に加えて、構成管理サーバ１０３と各目標ＥＣＵ１０１とが通信する際に用いるチャンネル番号またはメッセージＩＤなどの通信識別情報４１３を各目標ＥＣＵ１０１に配信することもできる。
　通信識別情報４１３は、通信データの種別を指定する情報である。例えば、構成管理サーバ１０３が目標ＥＣＵ１０１ａに共通鍵を送信するときはメッセージＩＤ０ｘ１５を用い、目標ＥＣＵ１０１ｂに共通鍵を送信するときはメッセージＩＤ０ｘ１７を用いる、といった使い分けをすることができる。各目標ＥＣＵ１０１は、受信したデータが何を記述しているのかを、メッセージＩＤの値によって識別することができる。
　各目標ＥＣＵ１０１は、車載ネットワーク２０２に参加する前は、構成証明において用いられる通信チャンネルを把握していない。そこで、構成証明用鍵（共通鍵）を配布するとともに各目標ＥＣＵ１０１にメッセージＩＤを配布することができる。メッセージＩＤは、各目標ＥＣＵ１０１のデータベース内に、それぞれデータ４２１、４３１、４４１として格納される。
　通信データの種別毎にメッセージＩＤを変えることにより、通信の秘匿性がより一層高まる。すなわち、悪意の第３者はどのメッセージＩＤを用いて共通鍵が配信されているかを知らないため、通信データのなかから共通鍵を抽出することが困難である。
　上述の各情報の他、構成管理サーバ内データベース４１０が格納している、ＥＣＵ－ＩＤ、ソフトウェアバージョンなどの属性情報を、各目標ＥＣＵ１０１に配信することもできる。これら情報は、ネットワーク登録装置１０２や目標ＥＣＵ１０１にとって有用な情報である。
　ネットワーク登録装置１０２は、車両のＥＣＵが現在どのようなＥＣＵ群・ソフトウェア群で構成されているのかを調査したい場合がある。また、車載ＥＣＵは、協調制御の相手方となる他の車載ＥＣＵのソフトウェアバージョンが自局の制御ソフトと対応しているのかを調査したい場合がある。このような要求に答えるため、構成管理サーバ１０３は、データベース４１０が保持しているこれら情報を、ネットワーク登録装置１０２や目標ＥＣＵ１０１に配信してもよい。
　ただしセキュリティの観点から、これら情報の開示は、ネットワーク登録装置１０２については前述の認証が厳密に実施された後、車載ＥＣＵについては当該ＥＣＵの構成証明が厳密に実施された後になされる。
　図５に示すデータベース４１０は、オペレータがネットワーク登録装置１０２を用いて内容を閲覧し、更新することができるように構成してもよい。閲覧または更新に先立って構成管理サーバ１０３がネットワーク登録装置１０２を認証するのは、構成証明の場合と同様である。
＜実施の形態２：共通鍵の生成手段＞
　図６は、構成管理サーバ１０３が構成証明用鍵（共通鍵）を生成する方法を示す図である。以下図６にしたがって、構成証明用鍵を生成する手順を説明する。
　車両識別番号５０１は、車両個々にユニークに付けられる番号であり、構成管理サーバ１０３が内部的に情報を保持している。ＥＣＵ－ＩＤ（部品番号）５０２とソフトウェアバージョン５０３は、車載ネットワーク２０２に参加させようとしている目標ＥＣＵ１０１のＥＣＵ－ＩＤ（部品番号）とソフトウェアバージョンである。乱数５０４は、構成管理サーバ１０３内部で適宜発生させた乱数である。例えば、半導体閾値のホワイトノイズ的な揺らぎで一様乱数を生成するデバイスを用いて生成することができる。簡易的には、例えばマイコンのフリーランカウンタなどを適当なタイミングでキャプチャした数値列を乱数５０４として採用してもよい。
　構成管理サーバ１０３は、これらの値を一方向性ハッシュ関数５０５に入力する。一方向性ハッシュ関数５０５は、固定長のＥＣＵ固有の共通鍵５０６を出力する。この共通鍵５０６またはこれを用いて算出した値を、構成証明用鍵として用いることができる。
　一方向性ハッシュ関数５０５は、ＥＣＵ固有の共通鍵５０６から、車両識別番号５０１、ＥＣＵ－ＩＤ（部品番号）５０２、ソフトウェアバージョン５０３などの情報を復元することが不可能となるようにするために用いる。また、入力値が少しでも変わると共通鍵５０６も変化し、生成値が衝突しにくく、同一の出力値を与える入力値の組み合わせが予見不可能であることも重要である。
　一方向性ハッシュ関数５０５の入力値として、車両識別番号５０１を用いているので、同じＥＣＵ－ＩＤ（部品番号）５０２の目標ＥＣＵ１０１をネットワーク登録しても、車両ごとに共通鍵５０６の値は異なる。また、一方向性ハッシュ関数５０５の入力値として乱数５０４を用いているので、同一車両の車載ネットワーク２０２に、同一のＥＣＵ－ＩＤ（部品番号）５０２および同一のソフトウェアバージョン５０３の車載ＥＣＵを参加させても、参加を実施する毎に共通鍵５０６の値は異なる。
　この仕組みにより、ＥＣＵ改竄やＥＣＵ不正入れ換えを検出する能力を向上させることができる。同様の効果を発揮することができれば、一方向性ハッシュ関数５０５以外の関数を用いてもよいが、共通鍵５０６に基づき元の値を推測することができないようにする観点からは、一方向性関数を採用することが望ましい。
＜実施の形態２：構成証明の手順＞
　図７は、構成管理サーバ１０３が目標ＥＣＵ１０１を認証する手順を説明するシーケンス図である。ここでは上述のサーバ鍵とＥＣＵ鍵をパスワードとして用いる例を示した。以下、図７の各ステップについて説明する。
（図７：ステップＳ７０１～Ｓ７０２：構成証明の開始）
　構成管理サーバ１０３は、目標ＥＣＵ１０１に対して、構成証明要求を送信する（Ｓ７０１）。この構成証明要求は、車両が特定の状態時（始動直後、アイドリング時、イグニッションオフ直後など）に実施してもよいし、定期的に実施してもよい。目標ＥＣＵ１０１は、証明を要求しているのが本当に正規の構成管理サーバ１０３であるかを確かめるため、サーバ認証要求を返信する（Ｓ７０２）。
（図７：ステップＳ７０１～Ｓ７０２：補足）
　前述の構成証明用鍵（共通鍵）とともに通信識別情報４１３を配布する場合は、図７に示す通信シーケンスは、各ＥＣＵが記憶している通信チャンネルまたはメッセージＩＤを用いて実施される。
（図７：ステップＳ７０３～Ｓ７０４：サーバ側認証）
　構成管理サーバ１０３は、自分の真正性を目標ＥＣＵ１０１に示すため、サーバ鍵をサーバ側パスワードとして開示する（Ｓ７０３）。このサーバ鍵と、目標ＥＣＵ１０１が内部に保持しているサーバ鍵とが一致した場合、構成管理サーバ１０３が真正であると結論付けられる（Ｓ７０４）。
（図７：ステップＳ７０５～Ｓ７０７：ＥＣＵ側構成証明）
　構成管理サーバ１０３が真正である旨を目標ＥＣＵ１０１が確認した場合、目標ＥＣＵ１０１は、ＥＣＵ鍵をＥＣＵ側パスワードとして構成管理サーバ１０３に送信する（Ｓ７０５）。構成管理サーバ１０３は、データベース４１０が保持している鍵と受信したＥＣＵ鍵が一致した場合、目標ＥＣＵ１０１は改竄されていないと判断する（Ｓ７０６）。以上の手順によって構成証明が完了し、構成管理サーバ１０３はセッション終了通知を目標ＥＣＵ１０１に送信する（Ｓ７０７）。
＜実施の形態２：構成証明の手順その２＞
　図７で説明した手順によれば、サーバ認証とＥＣＵ構成証明を簡便に実行することができる。ただし、サーバ鍵とＥＣＵ鍵が直接車載ネットワーク２０２上に流れるので、これをキャプチャすれば、改竄された目標ＥＣＵ１０１（もしくは構成管理サーバ１０３）を作成して車載ネットワーク２０２に接続することができる。
　このような状況を防止し、セキュリティ性能を向上させるため、構成証明用鍵（共通鍵）を直接車載ネットワーク２０２に流すことに代えて、チャレンジ＆レスポンス認証の共通鍵として構成証明用鍵を用いることもできる。図８を用いてその手順を説明する。
　図８は、構成管理サーバ１０３が目標ＥＣＵ１０１を認証する手順を示す別方式のシーケンス図である。以下、図８の各ステップについて説明する。
（図８：ステップＳ８０１：構成証明要求）
　構成管理サーバ１０３は、目標ＥＣＵ１０１に対して、構成証明要求を送信する（Ｓ８０１）。この構成証明要求は、車両が特定の状態時（始動直後、アイドリング時、イグニッションオフ直後など）に実施してもよいし、定期的に実施してもよい。目標ＥＣＵ１０１は、証明を要求しているのが本当に正規の構成管理サーバ１０３であるかを確かめる認証処理を開始する。
（図８：ステップＳ８０２～Ｓ８０３）
　目標ＥＣＵ１０１は、乱数を発生させ（Ｓ８０２）、サーバ認証用のチャレンジデータとして構成管理サーバ１０３に送信する（Ｓ８０３）。
（図８：ステップＳ８０４～Ｓ８０５）
　構成管理サーバ１０３は、ステップＳ８０３のサーバ認証用チャレンジを受け取り、このデータとサーバ鍵を入力として、一方向性ハッシュ関数を用いてレスポンスを計算する（Ｓ８０４）。構成管理サーバ１０３は、算出したレスポンスをサーバ側レスポンスとして目標ＥＣＵ１０１に送信する（Ｓ８０５）。
（図８：ステップＳ８０６）
　目標ＥＣＵ１０１は、ステップＳ８０２で生成した乱数と、構成管理サーバ１０３との間で共有しているサーバ鍵とを一方向性ハッシュ関数に入力し、レスポンスとして構成管理サーバ１０３から帰ってくるであろうと予測される期待値を計算する。構成管理サーバ１０３と目標ＥＣＵ１０１は、規約によりそれぞれ同じアルゴリズムの一方向性ハッシュ関数を採用していると推定されるので、同じデータを入力とする一方向性ハッシュ関数の出力値は一致するはずである。
（図８：ステップＳ８０７～Ｓ８０８）
　目標ＥＣＵ１０１は、ステップＳ８０６で計算した値と、構成管理サーバ１０３から受け取った値とを比較する（Ｓ８０７）。両者の値が一致すれば、構成管理サーバ１０３の真正性が証明されたことになるので、目標ＥＣＵ１０１は構成証明用チャレンジ要求を構成管理サーバに送信する（Ｓ８０８）。
（図８：ステップＳ８０９～Ｓ８１０）
　構成管理サーバ１０３は、ステップＳ８０８で目標ＥＣＵ１０１が送信した構成証明用チャレンジ要求を受信すると、乱数を発生させ（Ｓ８０９）、目標ＥＣＵ１０１に対して構成証明用チャレンジデータとして送信する（Ｓ８１０）。乱数発生の手段は、目標ＥＣＵ１０１と同様である。
（図８：ステップＳ８１１～Ｓ８１３）
　構成管理サーバ１０３は、ステップＳ８１０で送信したチャレンジデータとＥＣＵ鍵を用いて、ステップＳ８０６と同様の手順でレスポンスの期待値を計算しておく（Ｓ８１１）。目標ＥＣＵ１０１は、ステップＳ８１０で構成管理サーバ１０３が送信したチャレンジデータとＥＣＵ鍵を用いて、ステップＳ８０４と同様の手順でレスポンスを計算し（Ｓ８１２）、構成管理サーバ１０３に返信する（Ｓ８１３）。
（図８：ステップＳ８１４～Ｓ８１５）
　構成管理サーバ１０３は、ステップＳ８１３で目標ＥＣＵ１０１から返信された構成証明用レスポンスとステップＳ８１１で計算した期待値を比較する。両者が一致すれば、目標ＥＣＵ１０１の構成証明が得られたことになる（Ｓ８１４）。その後、構成管理サーバ１０３は、目標ＥＣＵ１０１に対してセッション終了通知を送信する（Ｓ８１５）。
＜実施の形態２：まとめ＞
　以上のように、本実施形態２に係る車載ネットワークシステム１０００において、構成管理サーバ１０３は、車載ネットワークに２０２に接続される全ての車載ＥＣＵの識別情報（ＥＣＵ－ＩＤ（部品番号）、ソフトウェアバージョン等）を管理する。この管理形態は、全車両の情報を集約する外部サーバなどを用いず、各車両が自己の識別情報を個別に保持する分散制御として構成される。したがって、情報管理形態としてロバストであり、個別車両の構成管理サーバ１０３が破られても、セキュリティ危機が全車両に波及することがない。
　また、本実施形態２に係る車載ネットワークシステム１０００において、目標ＥＣＵ１０１を車載ネットワーク２０２に参加させる際に、信頼できるネットワーク登録装置１０２の力を借りて、安全に構成証明用鍵（共通鍵）を配信することができる。これにより、上述のように簡単なチャレンジ＆レスポンス認証で、構成管理サーバ１０３と目標ＥＣＵ１０１が互いに相手方を認証し、構成の真正性を互いに証明し合うことができる。
　また、本実施形態２に係る車載ネットワークシステム１０００においては、構成証明を実施する際に、高度な暗号化通信（一般の共通鍵暗号や公開鍵暗号）や共通鍵配信技術（ＫＰＳ方式など）を使う必要がない。すなわち、現状のＥＣＵにおけるＣＰＵ／ＲＯＭ／ＲＡＭ等の計算リソースを構成証明のために浪費する必要がなくなり、ひいては実装コストが増加しない。したがって本手法は、構成証明機能を車載ネットワークシステム１０００に簡便に付加し、ＥＣＵの改竄に対抗する手法として、非常にコストパフォーマンスに優れた方式であると言える。
＜実施の形態３＞
　本発明の実施形態３では、実施形態２で開示した車載ネットワークシステム１０００の具体的なソフトウェア実装例について説明する。図９と図１０は、図８で示したチャレンジ＆レスポンス方式の構成証明手順を、ソフトウェア実装の観点でフローチャートとして開示したものである。したがって、機能として図８のシーケンスとは完全に等価というわけではなく、異常系処理と診断ＮＧ時の警告系処理を含んでいる。
　図９は、構成管理サーバ１０３の内部で実行される処理を示すフローチャートである。以下、図９の各ステップについて説明する。
（図９：ステップＳ９０１～Ｓ９０５：構成証明開始）
　構成管理サーバ１０３は、データベース４１０より、検証すべき目標ＥＣＵ１０１の共通鍵を読み出し、構成証明に備える（Ｓ９０１）。その後、該当する目標ＥＣＵ１０１に対して構成証明要求を送信し（Ｓ９０２）、タイムアウト計測に備えてタイマを初期化する（Ｓ９０３）。構成管理サーバ１０３は、サーバ認証用チャレンジデータの到来を待ち受け（Ｓ９０４）、データが到来すればステップＳ９０６に遷移する。サーバ認証用チャレンジデータが到来せずタイムアウトと判定された場合は（Ｓ９０５）、目標ＥＣＵ１０１が反応していないと判断し、ステップＳ９１７に遷移する。
（図９：ステップＳ９０６～Ｓ９１０：サーバ側認証）
　構成管理サーバ１０３は、サーバ認証用チャレンジデータを受信すると、サーバ鍵を用いてレスポンスを計算し（Ｓ９０６）、目標ＥＣＵ１０１にレスポンスを返信する（Ｓ９０７）。その後、ＥＣＵ側の判定を待ち受けるためのタイムアウト計測に備えてタイマを初期化する（Ｓ９０８）。構成管理サーバ１０３は、目標ＥＣＵ１０１から構成証明用チャレンジ要求を待ち受け（Ｓ９０９）、要求を受信すると、目標ＥＣＵ１０１がサーバ認証を受け入れたということなので、ステップＳ９１１に遷移する。構成証明用チャレンジ要求が到来せずタイムアウトと判定された場合は（Ｓ９１０）、目標ＥＣＵ１０１がサーバ認証を受け入れなかったか、または目標ＥＣＵ１０１が改竄され手続きを知らない可能性があると判断し、ステップＳ９１７に遷移する。
（図９：ステップＳ９１１～Ｓ９１６：ＥＣＵ側証明要求）
　ステップＳ９１１～Ｓ９１６は、目標ＥＣＵ１０１の構成証明を実施するためのデータを準備するステップである。構成管理サーバ１０３は、乱数を発生させ（Ｓ９１１）、構成証明用チャレンジデータとして目標ＥＣＵ１０１に送信する（Ｓ９１２）。その後、タイムアウト計測用タイマを初期化し（Ｓ９１３）、ステップＳ９０１で検索済みの目標ＥＣＵ１０１のＥＣＵ鍵を用いて、レスポンスの期待値を計算する（Ｓ９１４）。構成管理サーバ１０３は、目標ＥＣＵ１０１から構成証明用レスポンスを待ち受け（Ｓ９１５）、レスポンスがあった場合はステップＳ９１８に遷移する。構成証明用レスポンスが到来せずタイムアウトと判定された場合は（Ｓ９１６）、目標ＥＣＵ１０１が改竄され手続きを知らない可能性があると判断し、ステップＳ９１７に遷移する。
（図９：ステップＳ９１７：ＥＣＵ不正検出＆警告処理）
　構成管理サーバ１０３は、適当なインターフェースを介して、目標ＥＣＵ１０１が改竄されている旨の警告信号を出力するか、またはその旨を記述した通信データを車載ネットワーク２０２に対してブロードキャストする。
（図９：ステップＳ９１８～Ｓ９２０：構成証明結果）
　構成管理サーバ１０３は、ステップＳ９１４で計算した期待値と、目標ＥＣＵ１０１から受信した構成証明用レスポンスとを比較する（Ｓ９１８）。両者が一致すれば構成証明が完了したということなので、目標ＥＣＵ１０１にセッション終了通知を送信し（Ｓ９１９）、構成証明が終了したことを通知する。その後、全ての検査すべき車載ＥＣＵについて構成証明が完了したか否かをチェックする（Ｓ９２０）。完了している場合は図９の処理を終了し、未完である場合はステップＳ９０１に戻る。期待値と構成証明用レスポンスとが一致しなかった場合は、目標ＥＣＵ１０１が他の車両のものと取り換えられたり、車載ネットワーク２０２に参加する処理を実行しないまま車載ネットワーク２０２に接続されたりするなど、不正な改竄が行われた可能性があると判断し、ステップＳ９１７に遷移する。
　図１０は、目標ＥＣＵ１０１の内部で実行される処理を示すフローチャートである。以下、図１０の各ステップについて説明する。
（図１０：ステップＳ１００１～Ｓ１００７：サーバ側認証開始）
　目標ＥＣＵ１０１は、構成管理サーバ１０３からの構成証明要求を待ち受け、要求が到着するとステップＳ１００２に遷移する（Ｓ１００１）。目標ＥＣＵ１０１は、構成管理サーバ１０３が改竄されていないか（悪意の盗聴装置ではないか）を確認するために乱数を発生し（Ｓ１００２）、サーバ認証用チャレンジデータとして送信する（Ｓ１００３）。目標ＥＣＵ１０１は、タイムアウト計測用タイマを初期化し（Ｓ１００４）、サーバ鍵を用いて構成管理サーバ１０３からのレスポンスの期待値を計算する（Ｓ１００５）。目標ＥＣＵ１０１は、構成管理サーバ１０３からのサーバ認証用レスポンスを待ち受け（Ｓ１００６）、返信を受け取るとステップＳ１００８に遷移する。サーバ認証用レスポンスが到来せずタイムアウトと判定された場合は（Ｓ１００７）、構成管理サーバ１０３が改竄されるか、または悪意の盗聴装置と交換されている可能性があると判断し、ステップＳ１０１８に遷移する。
（図１０：ステップＳ１００８～Ｓ１０１２：ＥＣＵ側構成証明開始）
　目標ＥＣＵ１０１は、ステップＳ１００５で計算した期待値と、構成管理サーバ１０３から受信したサーバ認証用レスポンスとを比較する（Ｓ１００８）。両者が一致すれば、構成管理サーバ１０３の真正性が確認されたということなので、ステップＳ１００９に遷移する。期待値とサーバ認証用レスポンスとが一致しなかった場合は、構成管理サーバ１０３が他の車両のものと取り換えられるか、または不正な改竄が行われた可能性があると判断し、ステップＳ１０１８に遷移する。目標ＥＣＵ１０１は、構成管理サーバ１０３に対して、自局の真正性を証明するための構成証明用チャレンジデータを送信するよう要求する（Ｓ１００９）。その後、構成管理サーバ１０３から構成証明用チャレンジデータを待ち受けるためのタイムアウト計測に備えてタイマを初期化する（Ｓ１０１０）。目標ＥＣＵ１０１は、構成管理サーバ１０３から構成証明用チャレンジデータを待ち受け、返信を受け取るとステップＳ１０１３に遷移する。構成証明用チャレンジデータが到来せずタイムアウトと判定された場合は（Ｓ１０１２）、構成管理サーバ１０３が改竄され手続きを知らない可能性があると判断し、ステップＳ１０１８に遷移する。
（図１０：ステップＳ１０１３～Ｓ１０１７：構成証明結果）
　目標ＥＣＵ１０１は、構成管理サーバ１０３から受信した構成証明用チャレンジデータとＥＣＵ鍵を用いてレスポンスを計算し（Ｓ１０１３）、構成管理サーバに返信する（Ｓ１０１４）。また、構成管理サーバ１０３からの応答を監視するためのタイムアウト計測に備えてタイマを初期化する（Ｓ１０１５）。目標ＥＣＵ１０１は、構成管理サーバ１０３からセッション終了通知を待ち受け、返信を受け取ると、構成管理サーバ１０３が構成証明を完了したことを意味しているので、図１０の処理を終了する（Ｓ１０１６）。構成証明用チャレンジデータが到来せずタイムアウトと判定された場合は（Ｓ１０１７）、構成管理サーバ１０３が他の車両のものと取り換えられるか、または不正な改竄が行われた可能性があると判断し、ステップＳ１０１８に遷移する。
（図１０：ステップＳ１０１８：構成管理サーバ不正検出＆警告処理）
　目標ＥＣＵ１０１は、適当なインターフェースを介して、構成管理サーバ１０３が改竄されている旨の警告信号を出力するか、またはその旨を記述した通信データを車載ネットワーク２０２に対してブロードキャストする。
＜実施の形態３：まとめ＞
　以上のように、本実施形態３に係る車載ネットワークシステム１０００において、構成証明は、構成管理サーバ１０３と目標ＥＣＵ１０１の間の相互認証によって実施される。これにより、構成管理サーバ１０３または目標ＥＣＵ１０１が改竄されたことを検知し、その旨の警告を発信することができる。
＜実施の形態４＞
　図１１は、実施形態１～３で説明した構成証明手法を、構成証明以外の用途に応用した動作例を説明する図である。図１１では、ＥＣＵ１０１が２台存在し（ＥＣＵ１０１ａと１０１ｂ）、これらＥＣＵの間でデジタル署名付きのメッセージを送受信する動作を想定する。
　ＥＣＵ鍵は、構成管理サーバ１０３と特定の車載ＥＣＵのペア間のみで共有される情報であるが、サーバ鍵は複数の車載ＥＣＵが共有する情報である。したがって、サーバ鍵を用いて複数の車載ＥＣＵ間でメッセージ認証符号（ＭＡＣ：Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ）を送受信し、メッセージの真正性を保証することが考えられる。
　サーバ鍵は、目標ＥＣＵ１０１が車載ネットワーク２０２に参加するときに、構成管理サーバ１０３から安全に配布されたものであり、車載ネットワーク２０２に属する正規ＥＣＵ以外には流出しない。よって、このサーバ鍵を用いてデジタル署名（メッセージ認証符号を添付すること）を実施すれば、構成管理サーバ１０３により認証を受けた車載ＥＣＵからのメッセージであることを、他ＥＣＵが確認することができる。
　ＥＣＵ１０１ａは、送りたいメッセージ１０１１ａとサーバ鍵１０１２ａを一方向性ハッシュ関数１０１３ａに入力してメッセージ認証符号（ＭＡＣ）１０１４ａを生成する。メッセージ１０１１ａとメッセージ認証符号（ＭＡＣ）１０１４ａをパッキング（Ｓ１１０１）して送信バッファ１０１５ａに格納し、車載ネットワーク２０２に送り出す（Ｓ１１０２）。
　ＥＣＵ１０１ｂは、ＥＣＵ１０１ａが送信した信号を受信（Ｓ１１０３）して受信バッファ１０１６ｂに格納し、送信側と申し合わせた規約によりアンパック（Ｓ１１０４）して、メッセージ１０１１ｂとメッセージ認証符号（ＭＡＣ）１０１４ｂとに分離する。
　ＥＣＵ１０１ｂは、メッセージ１０１１ｂとサーバ鍵１０１２ｂ（サーバ鍵１０１２ａと等しいと推定される）を一方向性ハッシュ関数１０１３ｂに入力して受信側メッセージ認証符号（ＭＡＣ）を作成し（Ｓ１１０５）、ＭＡＣ１０１４ｂと受信側メッセージ認証符号（ＭＡＣ）を比較器１０１７ｂにより比較する。両者が一致する旨の判定結果１０１８ｂが得られれば、メッセージ１０１１ｂの内容が確かにＥＣＵ１０１ａによって作成されたものであり、途中で改竄されていないと判断できる。
　なお、一方向性ハッシュ関数１０１３ａと１０１３ｂは、ＥＣＵ間の規約にしたがって同一のアルゴリズムを採用するものとする。
　図１１では、ネットワーク登録装置１０２により正規に車載ネットワーク２０２へ参加したＥＣＵが共通して保持するサーバ鍵を用いてメッセージ認証符号（ＭＡＣ）を実現する実施例を開示したが、この用途はメッセージ認証符号に限られるものではなく、共通鍵暗号方式（例えば、ＤＥＳ方式、ＡＥＳ（Ａｄｖａｎｃｅｄ　Ｅｎｃｒｙｐｔｉｏｎ　Ｓｔａｎｄａｒｄ）方式など）による車載ＥＣＵ間の暗号化通信に応用してもよい。
＜実施の形態４：まとめ＞
　以上のように、本発明による車載ＥＣＵ間で共通鍵を共有する手法は、構成証明用途のみならず、任意の車載ＥＣＵ間での高信頼度通信についても有効であることが分かる。
＜実施の形態５＞
　図１２は、近年の代表的な高機能車両が備えている車載ネットワークのネットワークトポロジー例を示す図である。ネットワーク登録装置（ソフトウェア書換装置が兼任）１０２、構成管理サーバ１０３、各ＥＣＵなどの構成および動作は、実施形態１～４と同様である。
　図１２において、４群のネットワークが搭載されており、各々通信ゲートウェイ（ゲートウェイＥＣＵ）２０１によってネットワークが束ねられている。図１２では、ゲートウェイＥＣＵ２０１を中心にしてスター型のネットワーク配置を採用しているが、ゲートウェイＥＣＵ２０１を複数段設けてカスケード型の接続形態を採用してもよい。
　図１２に示す車載ネットワークには、駆動系ネットワーク３０１、シャーシ／安全系ネットワーク３０５、ボディ／電装系ネットワーク３０９、ＡＶ／情報系ネットワーク３１３が搭載されている。
　駆動系ネットワーク３０１の配下には、エンジン制御ＥＣＵ３０２、ＡＴ（Ａｕｔｏｍａｔｉｃ　Ｔｒａｎｓｍｉｓｓｉｏｎ）制御ＥＣＵ３０３、ＨＥＶ（Ｈｙｂｒｉｄ　Ｅｌｅｃｔｒｉｃ　Ｖｅｈｉｃｌｅ）制御ＥＣＵ３０４が接続されている。シャーシ／安全系ネットワーク３０５の配下には、ブレーキ制御ＥＣＵ３０６、シャーシ制御ＥＣＵ３０７、ステアリング制御ＥＣＵ３０８が接続されている。ボディ／電装系ネットワーク３０９の配下には、計器表示ＥＣＵ３１０、エアコン制御ＥＣＵ３１１、盗難防止制御ＥＣＵ３１２が接続されている。ＡＶ／情報系ネットワーク３１３の配下には、ナビゲーションＥＣＵ３１４、オーディオＥＣＵ３１５、ＥＴＣ／電話ＥＣＵ３１６が接続されている。
　また、車両と外部との間で情報を送受信するため、車外通信部３１７が車外情報用ネットワーク３２２によってゲートウェイＥＣＵ２０１に接続されている。車外通信部３１７には、ＥＴＣ無線機３１８、ＶＩＣＳ（登録商標）（Ｖｅｈｉｃｌｅ　Ｉｎｆｏｒｍａｔｉｏｎ　ａｎｄ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ｓｙｓｔｅｍ）無線機３１９、ＴＶ／ＦＭ無線機３２０、電話用無線機３２１が接続されている。
　ネットワーク登録装置１０２は、車両が備えている接続用車両コネクタ１０４を介して、車外情報用ネットワーク３２２の１ノードとして接続するように構成されている。これに代えて、他のネットワーク（駆動系ネットワーク３０１、シャーシ／安全系ネットワーク３０５、ボディ／電装系ネットワーク３０９、ＡＶ／情報系ネットワーク３１３）またはゲートウェイＥＣＵ２０１に単独で接続してもよい。すなわち、機械的な配置は無関係であって、直接もしくはゲートウェイＥＣＵ２０１を介して目標ＥＣＵに対して電気信号が到達すればよい。
　電話用無線機３２１を通じてネットワーク越しに車外通信網からネットワーク登録装置１０２の機能を実施することもできる。例えば、構成管理サーバ１０３のデータベース検索や目標ＥＣＵ１０１の構成証明用データのメンテナンスなどが考えられる。この場合においても、上述の実施形態１～４と同様の手法を用いることができる。
　電話網越しやインターネット越しにＥＣＵのソフトウェアを書き換える手法は、リコールなどの不具合対応に際してその実施コストを下げる重要技術であって、将来的にありふれた行為になることが予想される。
　したがって、本発明で開示する技術を用いることによって、このソフトウェア書き換え後に引き続いて、リモートで構成管理サーバ１０３のデータベース内容を更新し、リモートでソフトウェア書き換え後の車載ＥＣＵを正しくネットワークに再登録することができる。
　図１２では、構成管理サーバ１０３を通信ゲートウェイＥＣＵ２０１の配下に直接接続したが、構成管理サーバ１０３のネットワーク上の位置は任意でよい。すなわち、電気信号的な接続が確保できるのであれば、他のネットワーク（駆動系ネットワーク３０１、シャーシ／安全系ネットワーク３０５、ボディ／電装系ネットワーク３０９、ＡＶ／情報系ネットワーク３１３、車外情報用ネットワーク３２２など）に直接接続してもよい。
　ただし、以下の２つの観点で通信ゲートウェイＥＣＵ２０１が構成管理サーバ１０３の役割を兼ねることが望ましい。
（１）図１の認証シーケンスＳ１１１が失敗したとき、ネットワーク登録装置１０２からの通信を、目標ＥＣＵ１０１が属する車載ネットワーク（駆動系ネットワーク３０１、シャーシ／安全系ネットワーク３０５、ボディ／電装系ネットワーク３０９、ＡＶ／情報系ネットワーク３１３）から電気的に切り離すことができる。この構成を用いることによって、いわゆるファイヤーウォール（防火壁）機能を通信ゲートウェイ２０１に付与することになるので、車載ネットワークに対する外部からの侵入リスクを低下させ、セキュリティをさらに向上させることができる。
（２）車両の不正改造・特定車載ＥＣＵの改竄などの目的で、構成管理サーバ１０３が車載ネットワークから除去される行為を防がなければならない。その目的では、通信ゲートウェイＥＣＵ２０１と構成管理サーバ１０３が機能統合されており、１つのＥＣＵであることは望ましい。なぜなら、構成管理サーバ１０３を除去すると、複数の車載ネットワークにまたがる相互の通信が実施できなくなるからである。
　以上、本発明者によってなされた発明を実施形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
　また、上記各構成、機能、処理部などは、それらの全部または一部を、例えば集積回路で設計することによりハードウェアとして実現することもできるし、プロセッサがそれぞれの機能を実現するプログラムを実行することによりソフトウェアとして実現することもできる。各機能を実現するプログラム、テーブルなどの情報は、メモリやハードディスクなどの記憶装置、ＩＣカード、ＤＶＤなどの記憶媒体に格納することができる。
　１０１：目標ＥＣＵ、１０２：ネットワーク登録装置、１０３：構成管理サーバ、１０４：接続用車両コネクタ、２０１：通信ゲートウェイ、２０２：車載ネットワーク、３０１：駆動系ネットワーク、３０２：エンジン制御ＥＣＵ、３０３：ＡＴ制御ＥＣＵ、３０４：ＨＥＶ制御ＥＣＵ、３０５：シャーシ／安全系ネットワーク、３０６：ブレーキ制御ＥＣＵ、３０７：シャーシ制御ＥＣＵ、３０８：ステアリング制御ＥＣＵ、３０９：ボディ／電装系ネットワーク、３１０：計器表示ＥＣＵ、３１１：エアコン制御ＥＣＵ、３１２：盗難防止制御ＥＣＵ、３１３：ＡＶ／情報系ネットワーク、３１４：ナビゲーションＥＣＵ、３１５：オーディオＥＣＵ、３１６：ＥＴＣ／電話ＥＣＵ、３１７：車外通信部、３１８：ＥＴＣ無線機、３１９：ＶＩＣＳ無線機、３２０：ＴＶ／ＦＭ無線機、３２１：電話用無線機、３２２：車外情報用ネットワーク、１０００：車載ネットワークシステム。

Claims (14)

  1. 　車両の動作を制御する車載制御装置と、
    　前記車載制御装置が前記車両の車載ネットワークに参加する正当権限を有するか否かを認証する構成管理装置と、
    　を備え、
    　前記構成管理装置は、
    　　前記車載制御装置を前記車載ネットワークに参加させる登録装置から、前記車載制御装置を前記車載ネットワークに参加させるよう要求する登録要求を受け取ると、前記登録装置に対する認証を実施した上で、前記車載制御装置に固有の構成証明データを作成して前記登録装置に返信し、
    　前記登録装置は、
    　　前記構成管理装置から前記構成証明データを受け取って前記車載制御装置に中継し、
    　前記車載制御装置は、
    　　前記登録装置から前記構成証明データを受け取ってメモリ内に格納する
    　ことを特徴とする車載ネットワークシステム。
  2. 　前記構成管理装置は、
    　　前記構成証明データを用いて前記車載制御装置を認証し、
    　　前記車載制御装置を認証する認証手順とは異なる認証手順によって前記登録装置を認証する
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  3. 　前記構成証明データは、
    　　前記構成管理装置が前記車載制御装置を認証する際のパスワード、または
    　　前記構成管理装置が前記車載制御装置を認証する際に実施するチャレンジ＆レスポンス認証において前記車載制御装置がレスポンスを生成する際に用いる共通鍵
    　のうち少なくともいずれかを含む
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  4. 　前記構成証明データは、
    　　前記車載制御装置が前記車載ネットワーク上でメッセージ認証符号を送受信する際に、メッセージからデジタル署名を作成するために用いる共通鍵、または
    　　前記車載制御装置が前記車載ネットワーク上で暗号化通信を実施するために用いる共通鍵
    　のうち少なくともいずれかを含む
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  5. 　前記構成管理装置は、
    　　前記車載制御装置毎、前記車載制御装置が備えるソフトウェアのバージョン毎、前記車両の車種毎、または前記車両を個体毎に識別する車両識別番号毎に異なる値を出力する一方向性関数を用いて、前記構成証明データを生成する
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  6. 　前記構成管理装置は、
    　　前記車載ネットワークに参加している前記車載制御装置から、前記構成証明データまたは前記構成証明データを用いて生成された認証データを受信することにより、前記車載ネットワークに参加している前記車載制御装置を認証し、
    　　前記車載ネットワークに参加している前記車載制御装置に対して前記構成証明データまたは前記認証データを送信するように要求してもその応答として前記構成証明データまたは前記認証データを受信することができない場合、前記車載ネットワークに参加している前記車載制御装置から定期的に前記構成証明データまたは前記認証データを受信することができない場合、または前記車載制御装置の認証に失敗した場合は、
    　　前記車載制御装置が改竄された旨を示す警告信号を出力するか、または前記車載制御装置が改竄された旨を記述した通信パケットを前記車載ネットワークに対してブロードキャストする
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  7. 　前記車載制御装置は、前記構成証明データまたは前記構成証明データを用いて生成された認証データを用いて前記構成管理装置を認証する
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  8. 　前記車載制御装置は、
    　　前記構成管理装置から前記構成証明データまたは前記認証データを受信することにより、前記構成管理装置を認証し、
    　　前記構成管理装置に対して前記構成証明データまたは前記認証データを送信するように要求してもその応答として前記構成証明データまたは前記認証データを受信することができない場合、前記構成管理装置から定期的に前記構成証明データまたは前記認証データを受信することができない場合、または前記構成管理装置の認証に失敗した場合は、
    　　前記構成管理装置が改竄された旨を示す警告信号を出力するか、または前記構成管理装置が改竄された旨を記述した通信パケットを前記車載ネットワークに対してブロードキャストするか、または以後の前記構成管理装置からの指示に従わない
    　ことを特徴とする請求項７記載の車載ネットワークシステム。
  9. 　前記構成証明データは、前記構成管理装置と前記車載制御装置の間で送受信する通信データの種別を記述した識別番号を含み、
    　前記構成管理装置と前記車載制御装置は、前記識別番号を指定した通信データによって前記構成証明データを送受信する
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  10. 　前記構成管理装置は、
    　　前記車載ネットワークに接続する装置間の通信を中継する通信ゲートウェイとして動作し、
    　　前記登録装置の認証に失敗した場合は、前記登録装置と前記車載制御装置との間の通信を遮断する
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  11. 　前記登録装置は、前記車載制御装置が搭載しているソフトウェアを書き換える書換装置としての機能を備える
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  12. 　前記登録装置は、前記車載ネットワークに一時的に接続する通信装置である
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  13. 　前記登録装置は、前記車両の外部に配置され、前記車載ネットワークを経由して前記構成管理装置または前記車載制御装置と通信する
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
  14. 　前記構成管理装置は、
    　　前記車載ネットワークに接続する前記車載制御装置の種別および搭載しているソフトウェアのバージョンを管理するデータベースを備え、
    　　前記登録装置からの要求に応じて前記データベースが格納しているデータを更新し、
    　　前記登録装置または前記車載制御装置から前記データベースが格納しているデータに対する問い合わせを受け取って前記データベースが格納しているデータを返信する
    　ことを特徴とする請求項１記載の車載ネットワークシステム。
PCT/JP2012/066945 2011-07-06 2012-07-03 車載ネットワークシステム WO2013005730A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/127,062 US9132790B2 (en) 2011-07-06 2012-07-03 In-vehicle network system
DE112012002836.8T DE112012002836B4 (de) 2011-07-06 2012-07-03 Fahrzeugbasiertes Netzwerksystem

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011150357A JP5479408B2 (ja) 2011-07-06 2011-07-06 車載ネットワークシステム
JP2011-150357 2011-07-06

Publications (1)

Publication Number Publication Date
WO2013005730A1 true WO2013005730A1 (ja) 2013-01-10

Family

ID=47437078

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/066945 WO2013005730A1 (ja) 2011-07-06 2012-07-03 車載ネットワークシステム

Country Status (4)

Country Link
US (1) US9132790B2 (ja)
JP (1) JP5479408B2 (ja)
DE (1) DE112012002836B4 (ja)
WO (1) WO2013005730A1 (ja)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104079456A (zh) * 2013-03-28 2014-10-01 株式会社自动网络技术研究所 车载通信系统以及车载中继装置
JP2016116075A (ja) * 2014-12-15 2016-06-23 トヨタ自動車株式会社 車載通信システム
CN105959249A (zh) * 2015-09-11 2016-09-21 天地融科技股份有限公司 电子设备的管理方法及系统
WO2017002405A1 (ja) * 2015-06-29 2017-01-05 クラリオン株式会社 車載情報通信システム及び認証方法
JPWO2014199779A1 (ja) * 2013-06-12 2017-02-23 ボッシュ株式会社 車両の乗員又は歩行者を保護するための保護装置を制御する制御装置、及び制御システム
JP2017130908A (ja) * 2016-01-18 2017-07-27 Kddi株式会社 車載コンピュータシステム、車両、鍵生成装置、管理方法、鍵生成方法、及びコンピュータプログラム
WO2017126322A1 (ja) * 2016-01-18 2017-07-27 Kddi株式会社 車載コンピュータシステム、車両、鍵生成装置、管理方法、鍵生成方法、及びコンピュータプログラム
JP6218914B1 (ja) * 2016-11-30 2017-10-25 Kddi株式会社 配信システム、データ保安装置、配信方法、及びコンピュータプログラム
CN107729757A (zh) * 2016-08-10 2018-02-23 福特全球技术公司 软件更新之前的软件认证
JP6288219B1 (ja) * 2016-11-18 2018-03-07 Kddi株式会社 通信システム
CN108259484A (zh) * 2018-01-09 2018-07-06 北京汽车股份有限公司 车载控制器的安全访问方法及系统
JP2020074574A (ja) * 2015-12-14 2020-05-14 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ装置、ネットワークシステム及び攻撃検知方法

Families Citing this family (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5479408B2 (ja) 2011-07-06 2014-04-23 日立オートモティブシステムズ株式会社 車載ネットワークシステム
JP5651615B2 (ja) * 2012-02-16 2015-01-14 日立オートモティブシステムズ株式会社 車載ネットワークシステム
JP6011379B2 (ja) * 2013-02-06 2016-10-19 トヨタ自動車株式会社 改竄検知システム、電子制御ユニット
JP6181493B2 (ja) 2013-09-20 2017-08-16 国立大学法人名古屋大学 書換検出システム、書換検出装置及び情報処理装置
US9374355B2 (en) 2013-10-28 2016-06-21 GM Global Technology Operations LLC Programming vehicle modules from remote devices and related methods and systems
US9253200B2 (en) * 2013-10-28 2016-02-02 GM Global Technology Operations LLC Programming vehicle modules from remote devices and related methods and systems
KR101519777B1 (ko) * 2014-01-29 2015-05-12 현대자동차주식회사 차량 네트워크 내의 제어기간의 데이터 송신 방법 및 수신 방법
WO2015129352A1 (ja) * 2014-02-28 2015-09-03 日立オートモティブシステムズ株式会社 認証システム、車載制御装置
CN110610092B (zh) * 2014-04-17 2023-06-06 松下电器（美国）知识产权公司 车载网络系统、网关装置以及不正常检测方法
WO2015170452A1 (ja) * 2014-05-08 2015-11-12 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車載ネットワークシステム、電子制御ユニット及び更新処理方法
CN105594156B (zh) * 2014-05-08 2020-01-21 松下电器（美国）知识产权公司 车载网络系统、电子控制单元及不正常检测方法
KR101535588B1 (ko) * 2014-05-09 2015-07-10 현대오트론 주식회사 차량 네트워크와 외부 네트워크 사이의 데이터 통신 제어 방법 및 장치
CN106462443B (zh) * 2014-06-13 2020-01-07 柏思科技有限公司 用于管理节点的方法和系统
US10211990B2 (en) * 2014-07-25 2019-02-19 GM Global Technology Operations LLC Authenticating messages sent over a vehicle bus that include message authentication codes
JP2016086353A (ja) * 2014-10-28 2016-05-19 株式会社デンソー 通信装置
US10158966B2 (en) 2014-11-05 2018-12-18 At&T Intellectual Property I, L.P. Connected car data links aggregator
DE102014118042A1 (de) 2014-12-05 2016-06-09 Schneider Electric Automation Gmbh Verfahren zur nachverfolgbaren Programmierung und Konfigurierung eines Geräts
FR3031268B1 (fr) * 2014-12-30 2017-01-13 Valeo Comfort & Driving Assistance Procede d’inscription d’un utilisateur a un service de commande d’une fonctionnalite d’un vehicule au moyen d’un terminal utilisateur
US10608818B2 (en) * 2015-01-16 2020-03-31 Autonetworks Technologies, Ltd. In-vehicle communication system having a comparison means for verifying data and a comparison method for verifying data
JP6216730B2 (ja) * 2015-03-16 2017-10-18 日立オートモティブシステムズ株式会社 ソフト更新装置、ソフト更新方法
JP6262681B2 (ja) 2015-03-26 2018-01-17 Kddi株式会社 管理装置、車両、管理方法、及びコンピュータプログラム
JP6387908B2 (ja) * 2015-06-22 2018-09-12 トヨタ自動車株式会社 認証システム
EP3318448B1 (en) * 2015-06-30 2023-12-06 Hitachi Astemo, Ltd. Vehicle data rewrite control device and vehicle data rewrite authentication system
JP6197000B2 (ja) * 2015-07-03 2017-09-13 Kddi株式会社 システム、車両及びソフトウェア配布処理方法
JP6178390B2 (ja) * 2015-08-05 2017-08-09 Kddi株式会社 管理装置、管理システム、車両、管理方法、及びコンピュータプログラム
WO2017022821A1 (ja) * 2015-08-05 2017-02-09 Kddi株式会社 管理装置、管理システム、鍵生成装置、鍵生成システム、鍵管理システム、車両、管理方法、鍵生成方法、及びコンピュータプログラム
JP6675271B2 (ja) * 2015-09-14 2020-04-01 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
US10200371B2 (en) 2015-11-09 2019-02-05 Silvercar, Inc. Vehicle access systems and methods
JP6523143B2 (ja) * 2015-11-13 2019-05-29 株式会社東芝 データ配布装置、通信システム、移動体およびデータ配布方法
JP2017108212A (ja) * 2015-12-07 2017-06-15 Kddi株式会社 鍵生成方法、鍵生成システム、及びコンピュータプログラム
DE102016124352A1 (de) * 2015-12-18 2017-06-22 Toyota Jidosha Kabushiki Kaisha Kommunikationssystem und ein in dem Kommunikationssystem ausgeführtes Informationssammelverfahren
JP6551239B2 (ja) 2016-01-06 2019-07-31 株式会社デンソー 車両用制御システム
JP6223484B2 (ja) * 2016-02-29 2017-11-01 Kddi株式会社 車載制御システム、車両、鍵配信装置、制御装置、鍵配信方法、及びコンピュータプログラム
EP3433791B1 (en) * 2016-03-25 2022-01-12 T-Central, Inc. System and method for internet of things (iot) security and management
CN106101111B (zh) * 2016-06-24 2019-10-25 郑州信大捷安信息技术股份有限公司 车载电子安全通信系统及通信方法
JP6641241B2 (ja) * 2016-07-04 2020-02-05 株式会社日立製作所 情報共有システム、計算機、及び、情報共有方法
US10285051B2 (en) * 2016-09-20 2019-05-07 2236008 Ontario Inc. In-vehicle networking
EP3532926A1 (en) * 2016-10-31 2019-09-04 Harman Becker Automotive Systems GmbH Software update mechanism for safety critical systems
JP6485429B2 (ja) * 2016-11-04 2019-03-20 トヨタ自動車株式会社 車載ネットワークシステム
JP6683588B2 (ja) 2016-11-10 2020-04-22 Kddi株式会社 再利用システム、サーバ装置、再利用方法、及びコンピュータプログラム
KR102642924B1 (ko) * 2016-12-07 2024-03-04 삼성전자주식회사 차량의 동작하는 방법 및 장치.
JP7094670B2 (ja) * 2017-07-03 2022-07-04 矢崎総業株式会社 設定装置及びコンピュータ
JP6766766B2 (ja) * 2017-07-10 2020-10-14 住友電気工業株式会社 認証制御装置、認証制御方法および認証制御プログラム
US10402192B2 (en) * 2017-07-25 2019-09-03 Aurora Labs Ltd. Constructing software delta updates for vehicle ECU software and abnormality detection based on toolchain
US10796500B2 (en) * 2017-08-01 2020-10-06 Ford Global Technologies, Llc Electronic communication modules provisioning for smart connectivity
US10652742B2 (en) * 2017-11-20 2020-05-12 Valeo Comfort And Driving Assistance Hybrid authentication of vehicle devices and/or mobile user devices
JP6519060B2 (ja) * 2017-12-13 2019-05-29 Kddi株式会社 管理装置、車両、管理方法、及びコンピュータプログラム
FR3076645A1 (fr) * 2018-01-08 2019-07-12 Psa Automobiles Sa Procede de controle de la conformite de calculateur(s) d’un vehicule par comparaison d’identifiants, et systeme de controle associe
US11178158B2 (en) * 2018-01-29 2021-11-16 Nagravision S.A. Secure communication between in-vehicle electronic control units
US10826706B1 (en) 2018-01-30 2020-11-03 State Farm Mutual Automobile Insurance Company Systems and methods for vehicle configuration verification with failsafe code
JP7031374B2 (ja) 2018-03-01 2022-03-08 株式会社デンソー 検証端末、検証システム
JP6552674B1 (ja) * 2018-04-27 2019-07-31 三菱電機株式会社 検査システム
US10592231B2 (en) * 2018-08-10 2020-03-17 Denso Corporation Vehicle information communication system
US11579865B2 (en) 2018-08-10 2023-02-14 Denso Corporation Vehicle information communication system
US11163549B2 (en) 2018-08-10 2021-11-02 Denso Corporation Vehicle information communication system
US11178712B2 (en) 2018-10-02 2021-11-16 Deere & Company Systems and methods to establish secure vehicle networks
KR102450811B1 (ko) * 2018-11-26 2022-10-05 한국전자통신연구원 차량 내부 네트워크의 키 관리 시스템
US10991175B2 (en) * 2018-12-27 2021-04-27 Beijing Voyager Technology Co., Ltd. Repair management system for autonomous vehicle in a trusted platform
US11290437B2 (en) * 2018-12-27 2022-03-29 Beijing Voyager Technology Co., Ltd. Trusted platform protection in an autonomous vehicle
WO2020170926A1 (ja) * 2019-02-18 2020-08-27 株式会社オートネットワーク技術研究所 車載通信装置、プログラム及び、通信方法
KR20200102213A (ko) 2019-02-21 2020-08-31 현대자동차주식회사 차량 내 네트워크에서 보안을 제공하는 방법 및 시스템
US11329983B2 (en) 2019-03-25 2022-05-10 Micron Technology, Inc. Validating an electronic control unit of a vehicle
US11101984B2 (en) * 2019-04-04 2021-08-24 Micron Technology, Inc. Onboarding software on secure devices to generate device identities for authentication with remote servers
JP7008661B2 (ja) * 2019-05-31 2022-01-25 本田技研工業株式会社 認証システム
CN112153646B (zh) * 2019-06-28 2022-03-08 华为技术有限公司 认证方法、设备及系统
CN112422595B (zh) * 2019-08-20 2022-10-11 华为技术有限公司 车载系统安全保护方法及设备
CN112702374B (zh) * 2019-10-23 2022-04-12 北京新能源汽车股份有限公司 一种车辆信息的处理方法、装置及车辆
CN111356114B (zh) * 2020-02-19 2023-06-20 阿波罗智联(北京)科技有限公司 车内电子控制单元升级方法、装置、设备和车辆系统
DE102020111450A1 (de) 2020-04-27 2021-10-28 Bayerische Motoren Werke Aktiengesellschaft Erkennen von Fehlern in einem Computernetzwerk
US20220345886A1 (en) * 2021-04-22 2022-10-27 Ford Global Technologies, Llc Unauthorized device resource drain prevention
EP4329240A1 (en) * 2021-04-30 2024-02-28 Huawei Technologies Co., Ltd. Key updating method and related device thereof
US20230087521A1 (en) * 2021-09-20 2023-03-23 Ford Global Technologies, Llc Computing device verification
WO2024036435A1 (zh) * 2022-08-15 2024-02-22 华为技术有限公司 通信方法、装置和系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06195024A (ja) * 1991-09-13 1994-07-15 American Teleph & Telegr Co <Att> 通信チャネル開設方法および顧客装置
JP2005341528A (ja) * 2004-04-28 2005-12-08 Denso Corp 通信システム、鍵配信装置、暗号処理装置、盗難防止装置
JP2006025298A (ja) * 2004-07-09 2006-01-26 Oki Electric Ind Co Ltd 相互認証方法、相互認証装置、及び相互認証システム
JP2007153021A (ja) * 2005-12-01 2007-06-21 Jtekt Corp 通信方法
JP2007214696A (ja) * 2006-02-07 2007-08-23 Hitachi Ltd 車両制御装置間ネットワーク
JP2010103693A (ja) * 2008-10-22 2010-05-06 Canon Inc 通信装置、通信装置の制御方法、プログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3789769T2 (de) 1986-07-31 1994-08-11 Advance Kk System zur erzeugung eines gemeinsamen geheimübertragungsschlüssels und kommunikationssystem unter verwendung des gemeinsamen geheimübertragungsschlüssels.
JPS6336634A (ja) 1986-07-31 1988-02-17 Advance Co Ltd 暗号鍵共有方式
WO2009147734A1 (ja) * 2008-06-04 2009-12-10 株式会社ルネサステクノロジ 車両、メンテナンス装置、メンテナンスサービスシステム及びメンテナンスサービス方法
JP2010011400A (ja) * 2008-06-30 2010-01-14 National Institute Of Advanced Industrial & Technology 共通鍵方式の暗号通信システム
JP5395036B2 (ja) 2010-11-12 2014-01-22 日立オートモティブシステムズ株式会社 車載ネットワークシステム
JP5479408B2 (ja) 2011-07-06 2014-04-23 日立オートモティブシステムズ株式会社 車載ネットワークシステム
JP5651615B2 (ja) 2012-02-16 2015-01-14 日立オートモティブシステムズ株式会社 車載ネットワークシステム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06195024A (ja) * 1991-09-13 1994-07-15 American Teleph & Telegr Co <Att> 通信チャネル開設方法および顧客装置
JP2005341528A (ja) * 2004-04-28 2005-12-08 Denso Corp 通信システム、鍵配信装置、暗号処理装置、盗難防止装置
JP2006025298A (ja) * 2004-07-09 2006-01-26 Oki Electric Ind Co Ltd 相互認証方法、相互認証装置、及び相互認証システム
JP2007153021A (ja) * 2005-12-01 2007-06-21 Jtekt Corp 通信方法
JP2007214696A (ja) * 2006-02-07 2007-08-23 Hitachi Ltd 車両制御装置間ネットワーク
JP2010103693A (ja) * 2008-10-22 2010-05-06 Canon Inc 通信装置、通信装置の制御方法、プログラム

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104079456A (zh) * 2013-03-28 2014-10-01 株式会社自动网络技术研究所 车载通信系统以及车载中继装置
CN104079456B (zh) * 2013-03-28 2017-08-18 株式会社自动网络技术研究所 车载通信系统以及车载中继装置
JP6086459B2 (ja) * 2013-06-12 2017-03-01 ボッシュ株式会社 車両の乗員又は歩行者を保護するための保護装置を制御する制御装置、及び制御システム
JPWO2014199779A1 (ja) * 2013-06-12 2017-02-23 ボッシュ株式会社 車両の乗員又は歩行者を保護するための保護装置を制御する制御装置、及び制御システム
JP2016116075A (ja) * 2014-12-15 2016-06-23 トヨタ自動車株式会社 車載通信システム
WO2017002405A1 (ja) * 2015-06-29 2017-01-05 クラリオン株式会社 車載情報通信システム及び認証方法
JP2017017443A (ja) * 2015-06-29 2017-01-19 クラリオン株式会社 車載情報通信システム及び認証方法
CN107683583B (zh) * 2015-06-29 2020-12-11 歌乐株式会社 车载信息通信系统以及认证方法
US10708062B2 (en) 2015-06-29 2020-07-07 Clarion Co., Ltd. In-vehicle information communication system and authentication method
CN107683583A (zh) * 2015-06-29 2018-02-09 歌乐株式会社 车载信息通信系统以及认证方法
CN105959249B (zh) * 2015-09-11 2019-03-29 天地融科技股份有限公司 电子设备的管理方法及系统
CN105959249A (zh) * 2015-09-11 2016-09-21 天地融科技股份有限公司 电子设备的管理方法及系统
JP2020074574A (ja) * 2015-12-14 2020-05-14 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ装置、ネットワークシステム及び攻撃検知方法
JP2017130908A (ja) * 2016-01-18 2017-07-27 Kddi株式会社 車載コンピュータシステム、車両、鍵生成装置、管理方法、鍵生成方法、及びコンピュータプログラム
CN108496322A (zh) * 2016-01-18 2018-09-04 Kddi株式会社 车载计算机系统、车辆、密钥生成装置、管理方法、密钥生成方法以及计算机程序
CN108496322B (zh) * 2016-01-18 2021-04-23 Kddi株式会社 车载计算机系统、车辆、密钥生成装置、管理方法、密钥生成方法以及计算机可读取的记录介质
WO2017126322A1 (ja) * 2016-01-18 2017-07-27 Kddi株式会社 車載コンピュータシステム、車両、鍵生成装置、管理方法、鍵生成方法、及びコンピュータプログラム
US10855460B2 (en) 2016-01-18 2020-12-01 Kddi Corporation In-vehicle computer system, vehicle, key generation device, management method, key generation method, and computer program
JP2018023162A (ja) * 2016-01-18 2018-02-08 Kddi株式会社 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム
CN107729757A (zh) * 2016-08-10 2018-02-23 福特全球技术公司 软件更新之前的软件认证
JP6288219B1 (ja) * 2016-11-18 2018-03-07 Kddi株式会社 通信システム
WO2018092356A1 (ja) * 2016-11-18 2018-05-24 Kddi株式会社 通信システム、車両、サーバ装置、通信方法、及びコンピュータプログラム
JP2018082373A (ja) * 2016-11-18 2018-05-24 Kddi株式会社 通信システム
US11212080B2 (en) 2016-11-18 2021-12-28 Kddi Corporation Communication system, vehicle, server device, communication method, and computer program
JP6218914B1 (ja) * 2016-11-30 2017-10-25 Kddi株式会社 配信システム、データ保安装置、配信方法、及びコンピュータプログラム
JP2018093285A (ja) * 2016-11-30 2018-06-14 Kddi株式会社 配信システム、データ保安装置、配信方法、及びコンピュータプログラム
CN108259484A (zh) * 2018-01-09 2018-07-06 北京汽车股份有限公司 车载控制器的安全访问方法及系统
CN108259484B (zh) * 2018-01-09 2021-03-19 北京汽车股份有限公司 车载控制器的安全访问方法及系统

Also Published As

Publication number Publication date
US20140114497A1 (en) 2014-04-24
DE112012002836B4 (de) 2021-07-01
JP2013017140A (ja) 2013-01-24
JP5479408B2 (ja) 2014-04-23
DE112012002836T5 (de) 2014-04-17
US9132790B2 (en) 2015-09-15

Similar Documents

Publication Publication Date Title
JP5479408B2 (ja) 車載ネットワークシステム
JP5395036B2 (ja) 車載ネットワークシステム
US10965450B2 (en) In-vehicle networking
JP5651615B2 (ja) 車載ネットワークシステム
Bernardini et al. Security and privacy in vehicular communications: Challenges and opportunities
JP6454918B2 (ja) 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム
Radu et al. Leia: Al ightweight auth e nticat i on protocol for can
JP5310761B2 (ja) 車両ネットワークシステム
WO2020020184A1 (en) Systems and methods for managing wireless communications by a vehicle
CN105827587B (zh) 中继设备、终端设备和通信方法
US10279775B2 (en) Unauthorized access event notification for vehicle electronic control units
Palaniswamy et al. An efficient authentication scheme for intra-vehicular controller area network
CN111131313B (zh) 智能网联汽车更换ecu的安全保障方法及系统
CN104429042A (zh) 基于证书的控制单元遥控钥匙配对
JP5772692B2 (ja) 車載制御装置の認証システム及び車載制御装置の認証方法
Alam Securing vehicle Electronic Control Unit (ECU) communications and stored data
Stabili et al. Analyses of secure automotive communication protocols and their impact on vehicles life-cycle
KR102215212B1 (ko) 적어도 2개의 통신 파트너 사이에서 인증된 접속을 제공하는 방법
WO2017126322A1 (ja) 車載コンピュータシステム、車両、鍵生成装置、管理方法、鍵生成方法、及びコンピュータプログラム
CN113839782A (zh) 基于puf的车内网络can总线轻量级安全通信方法
US20160330194A1 (en) Method for excluding a participant from a group having authorized communication
Wei et al. Authenticated can communications using standardized cryptographic techniques
JP2017208731A (ja) 管理システム、管理装置、車載コンピュータ、管理方法、及びコンピュータプログラム
CN116346398A (zh) 安全汽车系统
CN117439740A (zh) 一种车内网络身份认证与密钥协商方法、系统及终端

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14127062

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1120120028368

Country of ref document: DE

Ref document number: 112012002836

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12806984

Country of ref document: EP

Kind code of ref document: A1