JP6588863B2 - Key management system, server, and key management method - Google Patents

Description

  The present invention relates to a key management system, a server, and a key management method.

  In recent years, in response to the spread of M2M (Machine To Machine) and IoT (Internet of Things), various terminals such as in-vehicle systems and sensor nodes are connected to various service servers via various networks. In order for these terminals to communicate securely with the service server, the key management server needs to issue a secret key for communication and the like and deploy it to a device unit inside the terminal.

  As background art of this technical field, there is JP-A-2005-341528 (Patent Document 1). This publication states that “when the system is activated, the gateway ECU (GW) generates an encryption key and encrypts the encrypted data using the seed key in a batch format to all ECUs (ECU1 to ECUN). Each ECU decrypts the received encrypted data using a seed key, and uses the decryption result as an encryption key for subsequent encryption and decryption of communication data. A response (key confirmation) is generated, and the encrypted data encrypted using the encryption key is returned to the gateway ECU. The gateway ECU determines the validity of each ECU based on the response. (See summary).

JP 2005-341528 A

  The secret key deployed in the device unit inside the terminal needs to be deleted appropriately, for example, when the owner of the terminal is changed or when the terminal is destroyed, but the key management server deletes the key Even if the unit is instructed, the key may not be deleted due to unauthorized operation or failure of the device unit. Therefore, it is difficult for the key management server to confirm whether or not the key has been properly deleted.

  The technology described in Patent Document 1 updates the key of an ECU (Electronic Control Unit), which is an in-vehicle device unit, from the ECU serving as a gateway, but a method for confirming that the key in the ECU has been deleted is described in Patent Document 1. Is not disclosed. In view of the above, an object of one embodiment of the present invention is to highly accurately determine whether or not a key has been deleted from a terminal on which the key is provided, and thus enhance security.

  In order to solve the above problems, one embodiment of the present invention employs the following configuration. A key management system including a first system, a first server, and a second server, wherein the first system holds a first authentication key for authenticating the first system by the second server And the first server transmits an instruction to overwrite the first authentication key using an update key that cannot authenticate the first system to the second server, and If the first system does not follow the overwrite instruction, the first system attempts to authenticate with the second server using the first authentication key, and overwrites the first authentication key using the update key according to the overwrite instruction. If so, it attempts to authenticate with the second server using the update key, and at least one of the first server and the second server monitors whether the first system has followed the overwrite instruction, The first system and the second system If the authentication process between the first system and the second server fails and the first system determines that the overwriting instruction is followed, the first system A key management system that outputs a determination result indicating that the first authentication key has been deleted from.

  According to one embodiment of the present invention, it is possible to determine with high accuracy whether or not a key has been deleted from a terminal on which the key is deployed, thereby enhancing security.

1 is a block diagram illustrating a configuration example of an information system in Embodiment 1. FIG. 3 is a block diagram illustrating a configuration example of a key management server in Embodiment 1. FIG. It is a block diagram which shows the structural example of the vehicle-mounted system in Example 1. FIG. 1 is a block diagram illustrating a configuration example of a service server in Embodiment 1. FIG. 6 is an example of a deletion state in the first embodiment. 3 is an example of an incident notification format according to the first embodiment. FIG. 7 is a sequence diagram illustrating a key update process using a deletion key and a deletion completion confirmation process in the first embodiment. 6 is a flowchart illustrating an example of an incident notification determination process according to the first embodiment. FIG. 9 is a sequence diagram illustrating an example of processing in the first embodiment when an update completion notification is transmitted even though the ECU has not updated the key or has not updated the key. 10 is a block diagram illustrating a configuration example of a key management server in Embodiment 2. FIG. It is a block diagram which shows the structural example of the service server in Example 2. FIG. It is an example of the deletion state which the key management server in Example 2 hold | maintains. It is a figure which shows an example of the deletion state which the service server in Example 2 hold | maintains. FIG. 10 is a sequence diagram illustrating a key update process using a deletion key and a deletion completion confirmation process in the second embodiment. FIG. 10 is a sequence diagram illustrating an example of processing when an update completion notification is transmitted although the ECU has not updated the key or has not updated the key in the second embodiment.

  Embodiments of the present invention will be described below with reference to the accompanying drawings. It should be noted that this embodiment is merely an example for realizing the present invention, and does not limit the technical scope of the present invention. In each figure, the same reference numerals are given to common configurations.

  This embodiment improves security by determining whether or not the key has been deleted even if the key may not be properly deleted due to an unauthorized operation or failure of the ECU that is the in-vehicle device unit. An example of the information system will be described.

  FIG. 1 is a block diagram illustrating a configuration example of an information system that is an example of a key management system. The information system includes, for example, a key management server 1, an in-vehicle system 2, and a service server 3 that can communicate with each other. The information system further includes, for example, a service manager terminal 4 that can communicate with the key management server 1.

  Each component included in the information system may be connected by a route not shown in FIG. For example, the service manager terminal 4 may be connected to the service server 3 and the in-vehicle system 2. In addition, a configuration in the information system may include other configurations. For example, the service manager terminal 4 may include the service server 3.

  The key management server 1 is a server that communicates with the in-vehicle system 2, the service server 3, the service manager terminal 4 and the like via a network or the like. The key management server 1 is a server that securely stores a public key certificate of PKI (Public Key Infrastructure), a secret key, or a common key for common key encryption.

  In the key management server 1, other applications may operate. Further, the function of the key management server 1 may be divided into a plurality of cases such as servers and storages, and these may be combined. Moreover, the information apparatus etc. which can perform the same process may be sufficient not only as a server. The same applies to the service server 3.

  The in-vehicle system 2 is an automobile having a function of communicating with the key management server 1 and the in-vehicle system 2 through a network or the like. The in-vehicle system 2 includes a plurality of ECUs that are in-vehicle devices, and each ECU is connected by a network in the vehicle.

  In the present embodiment, an example in which the information system includes the in-vehicle system 2 will be described, but another M2M / IoT system may be included instead of the in-vehicle system 2. The information system is, for example, an agricultural monitoring system, a HEMS (Home Energy Management System), a BEMS (Building Energy Management System), a factory management system, a smart grid system, a medical system, or a location information providing system instead of the in-vehicle system. A system may be included.

  When the information system includes any of the above-described systems instead of the in-vehicle system 2, in the following description, a main ECU described later is replaced with a gateway device of the system, and the ECU is replaced with a terminal of a terminal node of the system. Good. In this case, the gateway device and the terminal of the terminal node are connected by wire or wireless.

  The service server 3 is a server that communicates with the in-vehicle system 2 and the key management server 1 through a network or the like. The service server 3 may communicate with the service manager terminal 4. Further, the service server 3 and the service manager terminal 4 may be the same element.

  The service server 3 communicates with the ECU of the in-vehicle system 2 to provide a service for the in-vehicle system 2 or an external system. The service server 3 is a server that holds a key for safely communicating with the ECU of the in-vehicle system 2. Further, the service server 3 detects that an abnormality has occurred in processing or the like as an incident, and notifies the key management server 1 of the detected incident.

  The service manager terminal 4 instructs the key management server 1 to delete the key held by the ECU. The service manager terminal 4 is constituted by a computer including a processor, a memory, an auxiliary storage device, a communication interface, and an input / output interface, for example.

  The service manager terminal 4 may further include a function for instructing the key management service to issue, update, and revoked keys. The service manager terminal 4 may be a terminal including a display device or the like, or may be a server that communicates with the key management server 1 through a network or the like. The communication between the key management server 1 and the service server 3 and the communication between the key management server 1 and the service administrator terminal 4 which is the server are, for example, LTE (Long Term Evolution), 3G (3rd Generation), Wireless communication such as WiMAX (World Wide Interoperability for Microwave Access), wireless LAN (Local Area Network), or WAN (Wide Area Network), or a wired LAN, the Internet, or a dedicated line.

  The communication between the key management server 1 and the in-vehicle system 2 and the communication between the service server 3 and the in-vehicle system 2 are wireless communication such as LTE, 3G, WiMAX, wireless LAN, or WAN, for example. The communication between the components in the information system may be another network or the same network.

  FIG. 2 is a block diagram illustrating a configuration example of the key management server 1. The key management server 1 includes, for example, a control unit 10, a storage unit 11, and a communication unit 12, which are connected to each other by a bus line or the like. The key management server 1 may further include, for example, an encryption processing unit that speeds up encryption processing.

  Each unit in the key management server 1 is not necessarily connected by a bus line, and may be electrically connected by other methods. In the key management server 1, parts that need to be connected to each other may be connected. Moreover, the part in a separate housing | casing may be connected by electrical or optical wiring. The same applies to the configuration of other devices included in the information system.

  The control unit 10 includes, for example, a processor (CPU, MPU, or DSP) and executes a program stored in the storage unit 11 or the like. The storage unit 11 stores a program executed by the control unit 10 and data used when the program is executed. The storage unit 11 includes, for example, a large-capacity and non-volatile storage device such as a magnetic disk, an SSD (Solid State Drive), an EEPROM, or a flash memory.

  The storage unit 11 may include a memory including a ROM that is a nonvolatile storage element and a RAM that is a volatile storage element. The ROM stores an immutable program (for example, BIOS). The RAM is a high-speed and volatile storage element such as a DRAM (Dynamic Random Access Memory), and temporarily stores a program executed by the control unit 10 and data used when the program is executed.

  The storage unit 11 may include an HSM (Hardware security module) that securely holds information such as a key. The storage unit 11 may be composed of a plurality of storage devices, and each program and each data may be stored separately in the plurality of storage devices.

  The communication unit 12 includes a network interface device that controls communication with other components included in the information system according to a predetermined protocol, and is a module that performs the above-described wireless communication and wired communication.

  The key management server 1 may include a plurality of communication units 12 according to communication methods, for example. Moreover, the communication part 12 may be shared with the module which implements other communication. The communication unit 12 may include an antenna and a modem circuit used for wireless communication. The communication unit 12 may include a connector and a modem circuit used for wired communication.

  The program executed by the control unit 10 is provided to the key management server 1 via a removable medium (CD-ROM, flash memory, etc.) or a network, and is, for example, a non-volatile storage medium included in the storage unit 11 Stored in the auxiliary storage device. For this reason, the key management server 1 may have an interface for reading data from a removable medium.

  The key management server 1 may further include an input interface and an output interface. The input interface is an interface that is connected to a keyboard, a mouse, and the like and receives input from an operator. The output interface is an interface that is connected to a display device, a printer, and the like and outputs the execution result of the program in a form that can be visually recognized by the operator.

  The key management server 1 is a computer system configured on a single computer, or a plurality of computers configured logically or physically, and operates on separate threads on the same computer. It may be possible to operate on a virtual machine constructed on a plurality of physical computer resources.

  The storage unit 11 stores control software 110 and a key management table 111. The control software 110 describes software for controlling the key management server 1. The control software 110 is software that executes a processing flow using, for example, communication from the communication unit 12, a predetermined timer, or other interrupt processing as a start trigger.

  The control software 110 may be a composite of a plurality of software. It should be noted that the description that the key management server 1 or the control software 110 executes the process without particular notice indicates that the control unit 10 executes the process physically in accordance with the description of the program of the control software 110. . The above description of the control software 110 and the relationship between the control software 110 and the control unit 10 are the same for the control software and the control unit included in other devices.

  The control software 110 includes, for example, a key management function 1101, an incident notification processing function 1102, a deletion key generation function 1103, a deletion state management function 1104, a main ECU authentication function 1105, and a service server authentication function 1106, which are programs. The control software 110 is realized by a combination of these functions.

  The key management function 1101 instructs to update the key distributed to the in-vehicle system 2 with a predetermined key. The key management function 1101 may instruct key distribution, revocation, or deletion. The key management function 1101 may update the key management table 111. The incident notification processing function 1102 performs processing according to the content of the incident notification received from the service server 3.

  The deletion key generation function 1103 generates a deletion key. The key value for deletion is different from the key value used in normal operation. The deletion state management function 1104 manages a series of processes relating to key deletion as states by reading and writing the key management table 111.

  The main ECU authentication function 1105 is a function for mutual authentication with the main ECU of the in-vehicle system 2 described later, and describes an ID and an authentication key for authenticating with the main ECU. The service server authentication function 1106 is a function for mutual authentication with the service server 3 described later, and includes an ID and an authentication key for authenticating with the service server 3. The ID and authentication key for authenticating with the main ECU and the ID and authentication key for authenticating with the service server may be stored in the storage unit 11 in a table format.

  The key management table 111 stores authentication key information distributed by the key management server 1 between the in-vehicle system 2 and the service server 3. The key management table 111 is generated in advance according to information transmitted from the service manager terminal 4 or the like, for example. The key management table 111 is composed of, for example, a database or a hash table.

  The key management table 111 includes, for example, a terminal ID column 1111, an application ID column 1112, a key value column 1113, a key state column 1114, a deletion state column 1115, and a state change date / time column 1116. The terminal ID column 1111 stores a terminal ID that identifies an ECU included in the in-vehicle system 2. The application ID column 1112 stores an application ID for identifying an ECU application included in the in-vehicle system 2. The terminal ID and application ID are, for example, a numerical string or a character string. In the present embodiment, it is assumed that the key is uniquely identified by the combination of the terminal ID and the application ID. The key management table 111 may further hold a key ID that uniquely identifies the key.

  The key value column 1113 stores a key value. The key value is, for example, a pair of a public key encryption private key and public key certificate, or a common key encryption private key. The key status column 1114 stores information indicating the key status. For example, “deleting” indicates that the corresponding key is being deleted. In addition, the key status column 1114 may hold values such as “valid” indicating that the key is valid and “revocation” indicating that the key has been revoked.

  The deletion state column 1115 stores a key deletion state. Details of the deletion state will be described later. Note that the deletion state column 1115 of the record whose key state column 1114 is “deleting” stores the deletion state, and the deletion state column 1115 of the record whose key state column 1114 is not “deleting” stores, for example, a null value. To do.

  The state change date / time column 1116 holds, for example, the date / time when the deletion state or the key state was last changed. The date and time stored in the status change date / time column 1116 may be acquired from the inside of the key management server 1, for example, or may be acquired from time information included in external communication that triggers the status change.

  In this embodiment, an example in which information used by the information system is represented in a table format will be described. However, the information used by the information system is expressed in any data structure regardless of the data structure. Also good. For example, a data structure appropriately selected from a table, list, database or queue can store the information. Information used by the information storage system is stored in a corresponding data storage area in the data storage device.

  FIG. 3 is a block diagram illustrating a configuration example of the in-vehicle system 2. The in-vehicle system 2 includes a server communication ECU 20, a main ECU 21, and one or more ECUs 22 that are connected to each other by, for example, a CAN (Control Area Network). The server communication ECU 20, the main ECU 21, and the ECU 22 may be connected by, for example, CAN FD (CAN with Flexible Data Rate), Ethernet (registered trademark, hereinafter the same), FlexRay, etc. (registered trademark, the same hereinafter).

  The server communication ECU 20 communicates with other components such as the key management server 1 and the service server 3. The server communication ECU 20 is a module for performing wireless communication such as LTE, 3G, WiMAX, wireless LAN, and WAN. When the in-vehicle system 2 is an IoT system other than an automobile, the server communication ECU 20 may be a module that performs wired communication.

  The server communication ECU 20 may be included in the main ECU 21 or the ECU 22. Further, the in-vehicle system 2 may include a plurality of server communication ECUs 20 according to applications and communication methods. Also, it may be shared with other modules that perform communication. The server communication ECU 20 may include an antenna, a modulation / demodulation circuit, and the like in the case of wireless communication. In the case of wired communication, a connector and a modem circuit may be included.

  For example, the main ECU 21 including the control unit 210, the storage unit 211, and the communication unit 212 that are connected to each other by a bus line or the like may further include, for example, a cryptographic processing unit that speeds up cryptographic processing. . The main ECU 21 may be a central gateway unit, for example.

  In the communication unit 212, the main ECU 21 communicates with other components of the in-vehicle system 2. The communication unit 212 is a module for performing communication by CAN, CAN FD, Ethernet, FlexRay, or the like, for example. When the in-vehicle system 2 is an IoT system other than an automobile, the communication unit 212 is a module for performing wireless or wired communication, for example. The main ECU 21 may include a plurality of communication units 212 corresponding to applications and communication methods. The communication unit 212 may be shared with a module that performs other communication. Note that the communication unit 212 may include an antenna and a modem circuit when performing wireless communication. The communication unit 212 may include a connector and a modem circuit when performing wired communication.

  Hereinafter, differences between each of the control unit 210 and the storage unit 211 and each of the control unit 10 and the storage unit 11 will be described, and description of similar points will be omitted. The storage unit 211 includes, for example, control software 2110 in which software for controlling the main ECU 21 is described.

  The control software 2110 includes, for example, a key management function 2111 and a key management server authentication function 2115, which are programs. The key management function 2111 receives an instruction from the key management server 1 and delivers a designated key to a predetermined ECU to update the key of the ECU. The key management function 2111 may deliver, revoke, and delete a key to a predetermined ECU in response to an instruction from the key management server 1.

  The key management server authentication function 2115 performs mutual authentication with the key management server 1. The key management server authentication function 2115 describes an ID for authenticating with the key management server 1 and an authentication key. The ECU 22 includes, for example, a control unit 220, a storage unit 221, and a communication unit 222 that are connected to each other by a bus line or the like. The ECU 22 may further include, for example, a cryptographic processing unit that speeds up the cryptographic processing. Since the description of the communication unit 222 is the same as the description of the communication unit 212, a description thereof will be omitted.

  Hereinafter, differences between each of the control unit 220 and the storage unit 221 and each of the control unit 10 and the storage unit 11 will be described, and description of similar points will be omitted. The storage unit 221 stores control software 2210 in which software for controlling the ECU 22 is described, and a terminal ID 2211.

  The control software 2210 includes one or more applications 2212. Other components may be provided. The application 2212 is software that executes a service linked to the service server 3, and communicates with the service server 3. The components included in the application 2212 will be described later. The terminal ID 2211 is an ID for identifying the ECU 22, and is, for example, a numerical string or a character string.

  The application 2212 holds, for example, an application ID 2213 and a service server communication authentication key 2214. The application ID 2213 is an ID for identifying the application 2212 and is, for example, a numerical string or a character string.

  The service server communication authentication key 2214 is a key for performing mutual authentication when communicating with an application of the service server 3 described later, and is distributed or updated from the key management server 1 via the main ECU 21. The service server communication authentication key 2214 needs to be appropriately deleted when the owner of the in-vehicle system 2 is changed or when the in-vehicle system 2 is discarded.

  FIG. 4 is a block diagram illustrating a configuration example of the service server 3. The service server 3 includes a control unit 30, a storage unit 31, and a communication unit 32 that are connected to each other by, for example, a bus line. The service server 3 may further include, for example, a cryptographic processing unit that speeds up cryptographic processing.

  Hereinafter, differences between the control unit 30, the storage unit 31, and the communication unit 32, and the control unit 10, the storage unit 11, and the communication unit 32 will be described, and description of similar points will be omitted. The storage unit 31 includes control software 310 in which software for controlling the service server 3 is described, and a key table 311.

  The control software 310 includes, for example, a key management function 3101, an incident notification function 3102, an application 3103, and a key management server authentication function 3106, which are programs. The key management function 3101 deletes the key in the key table 311 in response to an instruction from the key management server 1. Further, the key management function 3101 may hold, update, and revoke a key in response to an instruction from the key management server 1.

  The incident notification function 3102 detects that an abnormality has occurred in the processing of the service server 3 as an incident, and notifies the key management server 1 of it. That mutual authentication with the ECU 22 of the in-vehicle system 2 has failed is an example of an incident.

  The application 3103 is software that executes a service linked to the ECU 22, and communicates with the ECU 22. The key management server authentication function 3106 performs mutual authentication with the key management server 1. In the key management server authentication function 3106, for example, an ID for authenticating with the key management server 1 and an authentication key are described.

  The key table 311 stores authentication key information distributed by the key management server 1. The key table 311 is generated in advance, for example, according to information transmitted from the key management server 1. The key table 311 is composed of, for example, a database or a hash table.

  The key table 311 includes, for example, a terminal ID column 3111, an application ID column 3112, and a key value column 3113. The terminal ID column 3111 stores a terminal ID that identifies an ECU included in the in-vehicle system 2. The application ID column 3112 stores application ID information for identifying an ECU application included in the in-vehicle system 2. The key table 311 may further hold a key ID that uniquely identifies the key.

  The key value column 3113 stores the key value of the terminal communication authentication key held in the storage unit 31 in association with the terminal ID column 1111 and the application ID column 1112. The key value is, for example, a pair of a public key encryption private key and public key certificate, or a common key encryption private key. The terminal communication authentication key is a key for performing mutual authentication in combination with the service server communication authentication key 2214 of the ECU 22.

  FIG. 5A is an example of the deletion state stored in the deletion state column 1115. The deletion state column 1115 stores, for example, any one of the deletion states 1 to 7 or a null value. The transition of the deletion state is shown in the processing flow described later.

  The deletion state 1 indicates that the key management server 1 has received a deletion request from the service manager terminal 4. The deletion state 2 indicates that the key management server 1 is instructing to update the terminal communication authentication key with the deletion dedicated key. The deletion state 3 indicates that an update completion report using a communication authentication key deletion-dedicated key has been received. The deletion state 4 indicates that the key management server 1 has received a communication authentication failure report from the service server 3.

  The deletion state 5 indicates that the key management server 1 is instructing the service server 3 to delete the terminal communication authentication key. The deletion state 6 indicates that a deletion completion report has been sent from the service server 3 to the key management server 1. The deletion state 7 indicates that the key management server 1 has notified the service manager terminal 4 of the completion of deletion.

  FIG. 5B shows an example of an incident notification format notified by the incident notification function 3102. The incident notification in FIG. 5B indicates that mutual authentication between the ECU 22 and the service server 3 has failed.

  The incident notification includes, for example, a terminal ID, an application ID, an occurrence date and time, an incident content, and a detailed log. The terminal ID in the incident notification indicates the terminal ID of the ECU 22 with which the service server 3 has performed mutual authentication.

  The application ID in the incident notification indicates the application ID of the ECU 22 with which the service server 3 has attempted mutual authentication. The occurrence date and time in the incident notification indicates the time when the mutual authentication failure occurs. The incident content in the incident notification indicates the content of the incident that occurred in the service server 3, and the example of FIG. 5B indicates that the mutual authentication has failed. The detailed log in the incident notification indicates a log that reaches the incident indicated by the incident content. In the example of FIG. 5B, the detailed log indicates details of the log that has resulted in the authentication failure, and includes, for example, communication contents related to mutual authentication.

  Hereinafter, an example of processing of the information system will be described with reference to FIGS. FIG. 6 is a sequence diagram showing the update processing of the service server communication authentication key 2214 using the deletion key and the deletion completion confirmation processing. Hereinafter, the communication between the key management server 1 or the service server 3 and the main ECU 21 or the ECU 22 may be relayed by the server communication ECU 20 as necessary, unless otherwise specified.

  First, the service manager terminal 4 transmits a key deletion instruction to the key management server (S101). The key deletion instruction includes information for specifying a service server communication authentication key 2214 (hereinafter referred to as a deletion target key) that is a deletion target. The combination of the terminal ID and the application ID, the key ID, and the key value are all examples of information for specifying the deletion target key.

  Subsequently, the deletion state management function 1104 updates the value of the key state column 1114 of the key to be deleted to “deleting” and the value of the deletion state column 1115 to the deletion state 1, respectively, and sets the value in the state change date / time column 1116. The current date and time are stored (S102). The deletion state management function 3104 updates the change date / time of the state change date / time column 1116 corresponding to the delete state column 1115 every time the value of the delete state column 1115 is changed. The description of the update process of the change date in the column 1116 is omitted.

  Subsequently, the deletion key generation function 1103 generates a deletion key (S103). Note that the deletion key generation function 1103 generates a deletion key using, for example, a pseudo-random number generator. Further, the deletion key generation function 1103 may generate, for example, a key having a predetermined value as a deletion key.

  Subsequently, the key management function 1101 instructs the main ECU 21 to update the deletion target key with the deletion key generated in S103, and the deletion state management function 1104 sets the value in the deletion state column 1115 of the deletion target key to the deletion state 2. (S104). The update instruction includes a deletion target key, information for specifying the ECU 22 that holds the deletion target key, and a deletion key. In addition, before the process of step S104 is implemented, it is desirable that the main ECU authentication function 1105 and the key management server authentication function 2115 perform mutual authentication and establish a cryptographic session or the like.

  Subsequently, the key management function 2111 of the main ECU 21 specifies the ECU 22 that holds the deletion target key with reference to the update instruction, and instructs the ECU 22 that has specified the key update with the deletion key (S105). That is, the key management function 2111 transfers the received update instruction to the identified ECU 22.

  The application 2212 that holds the deletion target key of the ECU 22 that has received the update instruction updates the service server communication authentication key 2214 that is the deletion target key by overwriting with the received deletion key (S106), and updates the update to the main ECU 21. (S107). The update completion notification includes information for specifying the deletion target key. The key management function 2111 of the main ECU 21 transfers an update completion notification to the key management server 1 (S108).

  The deletion state management function 1104 updates the value in the deletion state column 1115 of the deletion target key to the deletion state 3 (S109), and waits for an incident notification from the service server 3 (S110). Note that the processing from step S103 to step S109 may be repeated a predetermined number of times. Further, the key management server 1 may perform other processing during the standby in step S110.

  Subsequently, the application 2212 that has updated the service server communication authentication key 2214 in step S106 uses the terminal ID 2211, the application ID 2213, and the updated service server communication authentication key 2214 to perform communication with the service server 3. A mutual authentication with the application 3103 is attempted (S111).

  Here, the process of step S111 may be performed immediately after step S107 or after a certain period of time, or triggered by communication or notification from the service server 3, the key management server 1, the service manager terminal 4, or the main ECU 21. May be executed. The attempt of mutual authentication in step S111 is processed by the application 3103 of the service server 3.

  Since the value of the key value column 3113 corresponding to the terminal ID and application ID received by the service server 3 from the ECU 22 does not match the key value of the service server communication authentication key 2214 overwritten with the deletion key in S106, mutual authentication is performed. It fails (S112).

  The incident notification function 3102 notifies the key management server 1 of the authentication failure incident shown in FIG. 5B, for example (S113). In addition, before the process of step S113 is implemented, it is desirable that the service server authentication function 1106 and the key management server authentication function 3106 perform mutual authentication and establish an encryption session or the like.

  Subsequently, the incident notification processing function 1102 determines whether or not the incident indicated by the received incident notification is an authentication failure incident related to the deletion target key (S114). If the incident notification processing function 1102 determines that the incident indicated by the received incident notification is not an authentication failure incident related to the key to be deleted (S114: No), the incident notification processing function 1102 performs appropriate incident processing and transitions to S110.

  When the incident notification processing function 1102 determines that the incident indicated by the received incident notification is an authentication failure incident related to the deletion target key (S114: Yes), the deletion state management function 1104 displays the deletion state column 1115 of the deletion target key. The value is updated to delete state 4 (S115).

  Subsequently, the key management function 1101 of the key management server 1 instructs the service server 3 to delete the terminal communication authentication key that is the deletion target key, and the deletion state management function 1104 sets the value in the deletion state column 1115 of the deletion target key. Update to the deletion state 5 (S116). It is desirable that the service server authentication function 1106 and the key management server authentication function 3106 perform mutual authentication and establish an encryption session or the like before performing the process of step S116.

  Subsequently, the key management function 3101 of the service server 3 deletes the terminal communication authentication key that is the key to be deleted, and notifies the key management server 1 that it has been deleted (S117). The deletion state management function 1104 updates the value in the deletion state column 1115 of the deletion target key to the deletion state 6 (S118). Note that the deletion state management function 1104 may change the value in the key state column 1114 of the deletion target key to “deleted” in step S118.

  Subsequently, the key management function 1101 notifies the service administrator terminal 4 of the completion of deletion, and the deletion state management function 1104 updates the value of the deletion state column 1115 of the deletion target key to the deletion state 7 (S119), and FIG. The series of processes ends.

  Note that the key management function 3101 does not have to delete the deletion target key in step S117. In this case, it is desirable that the incident notification function 3102 does not notify the key management server 1 of the incident even if an authentication failure incident corresponding to the deletion target key occurs after receiving the instruction in step S116. Since the service server 3 does not notify the incident, the processing load on the service server 3 and the key management server 1 is reduced.

  Also, the key management function 1101 instructs the ECU 22 having the deletion target key, for example, after the process of step S114, to not attempt to authenticate the application corresponding to the deletion target key in the future. May be. Note that the key management function may execute the instruction after the process of step S117, for example. By this instruction, the processing load on the ECU 22 and the service server 3 is reduced.

  With the processing shown in FIG. 6, the key management server 1 and the service administrator terminal 4 can confirm that the deletion target key has been overwritten and updated with the deletion key, that is, has been deleted from the ECU 22.

  FIG. 7 is a flowchart illustrating an example of the incident notification determination process in step S114. First, the incident notification processing function 1102 determines whether the incident notification content in the acquired incident notification indicates an authentication failure (S114a). The incident notification processing function 1102 transitions to step S114b when the incident notification content indicates authentication failure (S114a: Yes), and transitions to step S114e when the incident notification content does not indicate authentication failure (S114a: No).

  The incident notification processing function 1102 determines whether the combination of the terminal ID and application ID in the incident notification matches the combination of the value in the terminal ID column 1111 and the value in the application ID column 1112 of any record in the key management table 111. Determine (S114b).

  If the incident notification processing function 1102 determines that there is a record that matches the combination (S114b: Yes), the process proceeds to step S114c. If the incident notification processing function 1102 determines that there is no record (S114a: No), the process proceeds to step S114e.

  The incident notification processing function 1102 determines whether or not the value in the deletion state column 1115 of the matched record is the deletion state 3 (S114c). When the incident notification processing function 1102 determines that the state is the deletion state 3 (S114c: Yes), the process proceeds to step S114d, and when it is determined that the state is not the deletion state 3 (S114c: No), the process proceeds to step S114e.

  The incident notification processing function 1102 determines whether or not the occurrence date and time in the incident notification is later than the date and time in the status change date and time column 1116 of the record. When the incident notification processing function 1102 determines that the occurrence date and time in the incident notification is later than the date and time in the status change date and time column 1116 of the record (S114d: Yes), the process proceeds to step S115 and determines that it is not later (S114d: No), the process proceeds to step S114e. The incident notification processing function 1102 may perform determination processing using a detailed log in incident notification in the processing from step S114a to step S114d.

  In step S114e, the incident notification processing function 1102 determines that the acquired incident notification content is not an incident notification indicating that the deletion target key has failed to be authenticated, executes appropriate processing according to the incident notification, and proceeds to S110. Transition. 7, the incident notification processing function 1102 can update the value of the deletion state column 1115 of the deletion target key only when the acquired incident notification content is an incident notification of authentication failure of the deletion target key. it can.

  FIG. 8 shows a case where the service manager terminal 4 has instructed to update the key with the deletion key, but the ECU 22 has not updated the key or has transmitted an update completion notification even though it has not been updated. It is a sequence diagram which shows an example of a process. Hereinafter, differences from the sequence diagram of FIG. 6 will be described.

  As in FIG. 6, in step S <b> 105, the ECU 22 receives a key update instruction from the deletion key. However, the application 2212 that holds the deletion target key of the ECU 22 that has received the update instruction does not update the service server communication authentication key 2214 that is the deletion target key, or notifies the completion of the update even though the update has failed (S201). ). Note that the processing of step S108 and step S109 is performed only when update completion is notified in step S201.

  Since the service server communication authentication key 2214 has not been updated, the authentication between the ECU 22 and the service server 3 in step S111 is successful (S202). Therefore, the incident notification function 3102 does not execute the incident notification in step S113. Subsequent to step S110, the incident notification processing function 1102 determines whether or not a certain time has passed since the date / time in the state change date / time column 1116 of the deletion target key, that is, the value in the deletion state column 1115 of the deletion target key is in the deletion state 3. It is determined whether or not a certain time has elapsed since the change (S203).

  If the incident notification processing function 1102 determines that a certain time has elapsed (S203: Yes), the key management function 1101 notifies the service manager terminal 4 that the deletion of the deletion target key has not been completed (S204). With the processing in FIG. 8, the key management server 1 and the service administrator terminal 4 can confirm that there is a possibility that the deletion target key has not been deleted from the ECU 22.

  The service server 3 in the information system of the present embodiment has a deletion state management function. As a result, even if the service server 3 does not have an incident notification mechanism, the key management server 1 and the service manager terminal 4 can confirm that the key has been deleted.

  FIG. 9 is a block diagram illustrating a configuration example of the key management server 1. The control software 110 according to the present embodiment is different from the control software 110 according to the first embodiment in that the incident notification processing function 1102 is not included. Further, the deletion state stored in the deletion state column 1115 is different from that in the first embodiment, and details will be described later.

  FIG. 10 is a block diagram illustrating a configuration example of the service server 3. The control software 310 of the present embodiment is different from the control software 310 of the first embodiment in that an incident processing function 3102a and a deletion state management function 3104 are included instead of the incident notification function 3102.

  The incident processing function 3102a detects that an abnormality has occurred in the processing of the service server 3 as an incident, and the deletion state management function 3104 that performs processing according to the detected incident reads and writes the key table 311 to A series of processes related to deletion is managed as a state.

  The key table 311 of this embodiment is different from the key table 311 of the first embodiment in that it further includes a key state column 3114, a deletion state column 3115, and a state change date / time column 3116. The description of the key status column 3114, the deletion state column 3115, and the status change date / time column 3116 is the same as the description of the key status column 1114, the deletion status column 1115, and the status change date / time column 1116, and will be omitted.

  FIG. 11A is an example of a deletion state stored in the deletion state column 1115. The deletion state column 1115 of this embodiment is different from that of the first embodiment in that the deletion state 4 and the deletion state 5 are not stored, but the deletion state 4a is stored. The deletion state 4a indicates that the key management server 1 has already reported to the service server 3 that the key has been deleted (that is, the deletion target key has been updated with the deletion key).

  FIG. 11B is an example of a deletion state stored in the deletion state column 3115. The deletion state column 3115 stores, for example, a deletion state 1b and a deletion state 2b. The deletion state 1b indicates, for example, that the key management server 1 has received a key deletion report (that is, the deletion target key has been updated with the deletion key). The deletion state 2b indicates, for example, that the service manager terminal 4 has been notified of the completion of deletion of the terminal communication authentication key.

  FIG. 12 is a sequence diagram showing the update process of the service server communication authentication key 2214 using the deletion key and the deletion completion confirmation process. Hereinafter, differences from FIG. 6 will be described, and descriptions similar to those in FIG. 6 will be omitted.

  Following the processing in step S109, the key management function 1101 notifies the service server 3 that the deletion target key has been deleted from the ECU 22, and the deletion state management function 1104 updates the value of the deletion state column 1115 to the deletion state 4a. (S301). At this time, the key management function 1101 may explicitly instruct the service server 3 to delete the deletion target key. Note that it is desirable that the service server authentication function 1106 and the key management server authentication function 3106 perform mutual authentication and establish an encryption session or the like before the process of step S304 is performed.

  Subsequently, the deletion state management function 3104 updates the value of the deletion state column 3115 corresponding to the deletion target key to the deletion state 1b (S302), and waits for mutual authentication from the ECU 22 (S303).

  The incident processing function 3102a receives the authentication result in step S112, and determines whether or not the value in the deletion state column 3115 corresponding to the terminal communication authentication key that has failed in authentication is the deletion state 1b (S304). If the incident processing function 3102a determines that the value of the deletion state column 3115 is not the deletion state 1b (S304: No), the incident processing corresponding to the incident is performed, and the process proceeds to step S303.

  When the incident processing function 3102a determines that the value of the deletion state column 3115 is the deletion state 1b (S304: Yes), the key management function 3101 deletes the deletion target key from the storage unit 31 (S305). At this time, the key management function 3101 may change the value of the key status column 3114 of the deletion target key to “deleted”. As a result of the processing in step S304, the service server 3 can delete the deletion target key from the service server 3 only when the authentication failure is related to the key being deleted.

  Subsequently, the key management function 3101 notifies the key management server 1 of the completion of deletion of the deletion target key, and the deletion state management function 3104 updates the value of the deletion state column 3115 of the deletion target key to the deletion state 2b (S306). The process proceeds to step S118. Note that it is desirable that the service server authentication function 1106 and the key management server authentication function 3106 perform mutual authentication and establish an encryption session or the like before performing the process of step S118. With the processing in FIG. 12, the key management server 1 and the service administrator terminal 4 can confirm that the deletion target key has been deleted from the ECU 22 without the service server 3 notifying the incident.

  FIG. 13 shows a case where the service manager terminal 4 has instructed to update the key with the deletion key, but the ECU 22 has not updated the key or transmitted an update completion notification even though it has not been updated. It is a sequence diagram which shows an example of a process. Hereinafter, the description of the steps described in FIGS. 6, 8, and 12 is omitted.

  The incident processing function 3102a receives the result of the successful authentication in step S202, and determines whether or not the value of the successful authentication key deletion state column 3115 is the deletion state 1b (S401). If the incident processing function 3102a determines that the value of the key deletion state column 3115 is not the deletion state 1b (S401: No), the process proceeds to step S306.

  When the incident processing function 3102a determines that the value of the key deletion state column 3115 is the deletion state 1b (S401: Yes), the key management function 3101 determines that the key to be deleted has not been deleted from the ECU 22. The management server 1 is notified (S402). The key management function 1101 notifies the service manager terminal 4 that deletion of the deletion target key has not been completed (S403). It is desirable that the service server authentication function 1106 and the key management server authentication function 3106 perform mutual authentication and establish an encryption session or the like before the process of step S402 is performed. The process of FIG. 13 allows the key management server 1 and the service administrator terminal 4 to confirm that the deletion target key has not been deleted from the ECU 22 even if the service server 3 does not carry out the incident notification.

  Note that if an error occurs while the steps described in this embodiment are being performed, the error may be notified to the control unit of each component of the information system.

  In addition, each program included in the control software 110, the control software 2110, the control software 2210, and the control software 310 may display information indicating the process being executed on a display device or the like as necessary. It is desirable for each program to display information indicating the completion of a series of processing and the occurrence of branch processing on the display device. The determination in the branch process may be executed by a user via the input device.

  In the present embodiment, the exchange of information between the steps may be omitted, but in reality, there may be a pair of responses to the command. Even when information exchange between steps is indicated by a pair of bidirectional arrows, the exchange may include a plurality of commands and responses. In addition, even when the content of transmitting and receiving data between entities is described, the actual communication is performed through the command and response of one entity acting as a client and the other entity serving as a server. As a result, data transmission as described above may be realized.

  In addition, this invention is not limited to each above-mentioned Example, Various modifications are included. Each of the above-described embodiments has been described in detail for easy understanding of the present invention, and is not necessarily limited to one having all the configurations described. Further, a part of the configuration of a certain embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of a certain embodiment. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.

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

  Further, the control lines and information lines are those that are considered necessary for the explanation, and not all the control lines and information lines on the product are necessarily shown. In practice, it may be considered that almost all the components are connected to each other.

1 key management server, 2 in-vehicle system, 3 service server, 4 service manager terminal, 111 key table, 311 key management table, 1101 key management function, 1102 incident notification processing function, 1104 deletion state management function, 2111 key management function, 2212 application, 2214 service server communication authentication key, 3101 key management function, 3102 incident notification function, 3102a incident processing function, 3103 application

Claims (12)

A key management system including a first system, a first server, and a second server,
The first system holds a first authentication key for the second server to authenticate the first system;
The first server transmits an instruction to overwrite the first authentication key using an update key that cannot be used to authenticate the first system to the first system .
The first system includes:
If the overwriting instruction is not followed, the authentication with the second server is attempted using the first authentication key,
In accordance with the overwriting instruction, when the first authentication key is overwritten using the update key, the authentication with the second server is attempted using the update key,
At least one of the first server and the second server is
Monitoring whether the first system complies with the overwrite instruction;
Monitoring the authentication process between the first system and the second server;
If the authentication between the first system and the second server has failed and it is determined that the first system has followed the overwrite instruction, the first authentication key has been deleted from the first system. A key management system that outputs the result of determination. The key management system according to claim 1,
The second server holds a second authentication key for the first system to authenticate the second server,
The at least one includes the first server;
When the first server determines that the first authentication key has been deleted from the first system, the first server transmits an instruction to delete the second authentication key to the second server;
The key management system, wherein the second server deletes the second authentication key from the second server in accordance with the deletion instruction. The key management system according to claim 1,
The at least one includes the first server;
When the first system follows the overwrite instruction, it sends an update completion notification to the first server,
When the first server receives the update completion notification, the first server determines that the first system has followed the overwrite instruction. The key management system according to claim 1,
The at least one includes the first server;
If the authentication with the first system fails, the second server sends an authentication failure notification to the first server,
When the first server receives the authentication failure notification, the first server determines that authentication between the first system and the second server has failed. The key management system according to claim 4,
The first system has a plurality of terminals,
The second server executes a plurality of applications with the first system,
The first server holds management information indicating correspondence between the plurality of applications and a terminal that executes the plurality of applications,
When the first terminal included in the plurality of terminals executes the first application included in the plurality of applications with the second server, the first server includes the first authentication key. A key for authenticating the first terminal,
When the authentication for executing the first application with the first terminal fails, the second server includes information indicating the correspondence between the first terminal and the first application in the authentication failure notification. ,
When the management information includes a correspondence included in the authentication failure notification, the first server determines that the authentication between the first system and the second server has failed. The key management system according to claim 4,
When the first system follows the overwrite instruction, it sends an update completion notification to the first server,
The first server acquires a first time when the update completion notification is received,
The second server includes the second time when authentication with the first system failed in the authentication failure notification, and transmits the second time to the first server,
The first server determines that authentication between the first system and the second server has failed, the first system follows the overwrite instruction, and the second time is later than the first time And a key management system that outputs the determination result. The key management system according to claim 4 ,
If one even without prior Kisukuna is, wherein the first system authentication between the second server fails, and determines that the first system in accordance with the override instruction,
The key management system, wherein the second server stops transmitting the authentication failure notification. The key management system according to claim 1,
When the at least one of the first system and the second server fails to authenticate and the first system determines that the overwriting instruction has been followed, the second system A key management system that instructs not to attempt to authenticate with the server. The key management system according to claim 1,
The at least one includes the second server;
When the first system overwrites the first authentication key using the update key, the first system sends an update completion notification to the first server,
When the first server receives the update completion notification, the first server transmits the update completion notification to the second server,
When the second server receives the update completion notification, the second server determines that the first system has followed the overwrite instruction. The key management system according to claim 9,
The second server holds a second authentication key for the first system to authenticate the second server,
When the second server determines that the first authentication key has been deleted from the first system, the second server deletes the second authentication key from the second server. A server connected to the first system,
A processor that executes a program; and a storage device that is accessed by the processor;
The first system holds a first authentication key for authenticating the first system by one of the first server or the server connected to the first system,
The processor is
Monitoring whether the first system complies with the overwriting instruction of the first authentication key using an update key that cannot authenticate the first system by the first server;
Monitoring the authentication process between the first system and the one;
A determination indicating that the first authentication key has been deleted from the first system when authentication between the first system and the one fails and the first system determines that the overwriting instruction has been followed; The server that outputs the result. A method for performing key management by a server connected to a first system, comprising:
The first system holds a first authentication key for authenticating the first system by one of the first server or the server connected to the first system,
In the method, the server
Monitoring whether the first system complies with the overwriting instruction of the first authentication key using an update key that cannot authenticate the first system;
Monitoring the authentication process between the first system and the one;
A determination indicating that the first authentication key has been deleted from the first system when authentication between the first system and the one fails and the first system determines that the overwriting instruction has been followed; How to output the result.

Images