Information system, in-vehicle device, and program

Abstract

To safely and surely update a certificate used for authentication for charging in an information processing device such as an on-vehicle device.SOLUTION: The information system includes a management device that distributes certificate data related to charging of the vehicle to the vehicle, and an in-vehicle device that is mounted on the vehicle and controls charging of the vehicle based on the certificate data. The management device gives data identification information identifiable from other certificate data to the certificate data. When updating the certificate data stored in the in-vehicle device, the management device creates a signature based on the data identification information and the certificate data for update. The management device transmits the data identification information, the certificate data for update, and the signature to the on-vehicle device as update data. On the other hand, when receiving the update data, the in-vehicle device verifies the signature, and when the verification is successful, the in-vehicle device updates the certificate data before update, which is identified by the data identification information and stored in the in-vehicle device, with the certificate data for update.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to an information system, an in-vehicle device, and a program. [Background technology]

[0002] Known examples of vehicles (also called electric vehicles) that can be connected to an external power source to charge their driving batteries include battery electric vehicles (BEVs) and plug-in hybrid vehicles (PHVs). For authentication purposes, such as when charging the driving battery, certificates are stored in the computers of business operators involved in the authentication and in the vehicle's onboard equipment. Examples of such certificates include contract certificates and V2G root certificates.

[0003] Certificates have expiration dates, and expired certificates must be replaced with new ones. Even if a certificate has not yet expired, if the certificate becomes invalid, if the corresponding private key is leaked, or if the algorithm is compromised, the corresponding certificate must also be updated with a new one. A common technique for increasing the reliability of vehicle data is to verify data after it is written to a vehicle storage device (see Patent Document 1 below). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2020-106888 Summary of the Invention [Problem to be solved by the invention]

[0005] Incidentally, a vehicle is expected to hold multiple certificates. Therefore, when updating a certificate stored in a vehicle, it is necessary to identify which certificate is to be updated. In other words, when a request is made to write a certificate to a computer or an on-board device, it is necessary to determine whether the request is to update a specific certificate or to add a new certificate.

[0006] This means that when a certificate is renewed, the Subject Name and SerialNumber are the same as those used previously. This is because there is no way to link the old certificate with the new certificate, assuming that the old certificate will be replaced with the new one. Also, from a security perspective, it is necessary to link the old certificate with the new certificate securely.

[0007] RFC4210 specifies a method of cross-signing a new certificate and the previous certificate with their respective private keys. This method is effective when replacing a certificate due to expiration. However, it is not an effective method in the event that the private key of the previous certificate is leaked, because it is used after the private key of the previous certificate has been leaked.

[0008] An aspect of the disclosed embodiment is to enable safe and reliable updating of multiple certificate data used for authentication in an information processing device such as an in-vehicle device. [Means for solving the problem]

[0009] One aspect of the disclosed embodiment is exemplified by an information system including a management device that distributes certificate data related to vehicle charging to a vehicle, and an in-vehicle device that is mounted on the vehicle and controls vehicle charging based on the certificate data. The management device assigns data identification information to the certificate data that can be distinguished from other certificate data. The management device then manages the certificate data stored in the in-vehicle device. When updating certificate data, a signature is created based on the data identification information and the certificate data for update. The management device then transmits the data identification information, the certificate data for update, and the signature to the in-vehicle device as update data. On the other hand, upon receiving the update data, the in-vehicle device verifies the signature, and if the verification is successful, updates the pre-update certificate data identified by the data identification information and stored in the in-vehicle device with the certificate data for update. [Effects of the Invention]

[0010] In this information system, the management device transmits data identification information capable of identifying multiple certificate data, update certificate data, and a signature to the in-vehicle device as update data. If the in-vehicle device successfully verifies the signature, it updates the pre-update certificate data identified by the data identification information and stored in the in-vehicle device with the update certificate data. Therefore, in this information system, the signature is used to confirm that the data identification information and the update certificate data are authentic, and the data identification information is used to manage the relationship between the pre-update certificate data and the update certificate data, thereby updating the certificate. Therefore, this information system can safely and reliably update multiple certificate data used for authentication in an information processing device such as an in-vehicle device. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram illustrating an information system according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of the hardware configuration of a vehicle and a charging facility. [Figure 3] FIG. 3 is a diagram illustrating the data flow between a certificate issuing device that issues a certificate, an intermediate distribution device that distributes the issued certificate, and a recipient device that receives and installs the certificate. [Figure 4] FIG. 4 is a diagram illustrating data in the ID table. [Figure 5] FIG. 5 is a flowchart illustrating a distribution process of the intermediate distribution device. [Figure 6] FIG. 6 is a flowchart illustrating a certificate update process of a recipient device. DETAILED DESCRIPTION OF THE INVENTION

[0012] An information system 100, an in-vehicle device 10, and a computer program executed by the in-vehicle device 10 (hereinafter simply referred to as a program) according to an embodiment will be described below with reference to FIGS.

[0013] <Embodiment> (Configuration) FIG. 1 is a diagram illustrating an information system 100 according to this embodiment. The information system 100 includes a vehicle 1 equipped with an on-board device 10 and equipment involved in supplying power to the vehicle 1. For example, in FIG. 1, the equipment includes a charging equipment (EVSE) 2 that supplies power to a battery 19 (see FIG. 2, also called a secondary battery or storage battery) of the vehicle 1. This equipment also includes a Mobility Operator (MO) service that exchanges information with the vehicle 1 directly or indirectly via other devices. The MO server includes devices such as a charge point operator (CPO) server 5, an OEM server 6, a charge point operator (CPO) server 7, a certificate provisioning service (CPS) server 8, and a certificate pool 9. The server 5, the OEM server 6, the CPO server 7, the CPS server 8, and the certificate pool 9 can be said to be computers involved in charging the vehicle 1.

[0014] The devices in FIG. 1 may be connected by a network N1. The network N1 may be, for example, a Long Term Evolution (LTE) or 5th Generation Mobile Communication System ( This includes wireless networks such as 5G, 6th Generation Mobile Communication System (6G), and wired public networks such as the Internet. Note that the wireless network may include a wireless access network provided by a base station and a core network (wired).

[0015] The vehicle 1 is called an electric vehicle and can charge a battery 19 (see FIG. 2 ) for driving. The vehicle 1 has an on-board device 10 and performs charging, discharging, or charge / discharge control between the vehicle 1 and the charging facility 2. The owner or driver of the vehicle 1 (hereinafter also referred to as the user) enters into a contract with a service provider (e.g., an MO) in advance to charge / discharge between the charging facility 2 and the battery 19 of the vehicle 1. According to this contract, a contract certificate, which is an example of a first certificate, and an encryption key (referred to as a contract private key) are issued from the MO server 5 and installed in the vehicle 1 via, for example, the OEM server 6. The contract certificate and the contract private key can also be referred to as certificate data. Note that certificate data such as the contract certificate may also be installed in the vehicle 1 via, for example, the charging facility 2.

[0016] In the charging process, as the first authentication procedure, PnC, the on-board device 10 of the vehicle 1 creates a signature based on the Contract certificate and the like and the Contract private key, and the charging facility 2 verifies this. If the verification is successful, the vehicle 1 performs charging or discharging between the vehicle 1 and the charging facility 2. Such a PnC procedure is started, for example, when a plug for supplying power from the charging facility 2 is connected to the power receiving unit of the vehicle 1.

[0017] In addition to the PnC procedure described above, charging the vehicle 1 can also use an external authentication method (External Identification Means; EIM) procedure as a second authentication procedure by presenting a Radio Frequency Identification (RFID) card or the like. For this purpose, the charging equipment 2 has an EIM reader 2A (see FIG. 2). The external authentication method is an authentication method using user information acquired from a credit card, a QR code (registered trademark), an RFID card, or the like via the EIM reader 2A.

[0018] For example, the charging facility 2 may transfer the signature sent from the vehicle 1 to the MO server 5 and request authentication of the user of the vehicle 1. Then, when authentication by the MO server 5 is successful, the charging facility 2 may charge the battery 19 of the vehicle 1 and bill the user of the vehicle 1.

[0019] Furthermore, when receiving charging, the vehicle 1 can request the charging facility 2 to install a Contract certificate, etc. In this case, the vehicle 1 presents to the charging facility 2 a certificate (such as an OEM provisioning certificate) issued by the OEM, which is the manufacturer and distributor of the vehicle 1. If the charging facility 2 has a valid Contract certificate, etc. and Contract private key associated with the OEM provisioning certificate, etc. notified by the vehicle 1, it can provide the Contract certificate, etc. to the vehicle 1.

[0020] In addition, the charging facility 2 may access the MO server 5 or the certificate pool 9 to obtain a valid contract certificate and a contract private key corresponding to the OEM provisioning certificate, and install them in the vehicle 1.

[0021] The CPO server 7 is a computer that supports the processing of CPO. The CPO includes the charging equipment 2. The CPO also includes a company that manages the charging equipment 2 and provides services to the vehicle 1 using the charging equipment 2. The main business of the CPO is to manage the charging equipment 2 using an information technology (IT) system, and to bill the owner or user of the vehicle 1 directly or to bill the MO.

[0022] The OEM server 6 is a computer that supports the processing of the OEM. In the field of electric vehicles such as the vehicle 1, the OEM is exemplified by an electric vehicle manufacturer.

[0023] The MO server 5 is a computer that supports the processing of the MO. The MO is an organization that searches and finds charging facilities 2, authorizes and pays for charging sessions, and provides charging-related services. The MO enters into a contract (also known as an e-mobility contract) with the owner or driver of the vehicle. The following is concluded.

[0024] At the time of contract signing, the owner or operator of Vehicle 1 provides the MO with Vehicle 1's unique Provisioning Certificate ID (PCID), which the MO uses to select an OEM Provisioning Certificate from Certificate Pool 9. Receive the Provisioning Certificate. Vehicle 1's PCID will be used to identify Vehicle 1 when signing the contract.

[0025] In a first step, after the contract is signed, the MO generates an e-mobility account identifier (EMAID) unique to this contract and also generates a Contract Certificate. The authentication of vehicle 1 at charging facility 2 by PnC references the valid contract with the MO. The EMAID, which represents the charging contract number, is used to reference the contract.

[0026] In the second stage, the MO creates contract data defined in ISO 15118-2:2014. The contract data includes the generated contract certificate and contract private key. The created contract data is signed by the Certificate Provisioning Service (CPS) server 8 so that the vehicle 1 can verify its authenticity and integrity.

[0027] The CPS server 8 executes the signing process for the contract data. In the signing process, the CPS server 8 adds the provisioning sub-CA certificates (CPS SUB CA1 certificate and CPS SUB CA2 certificate) and the CPS leaf certificate to the contract data.

[0028] The CPS then creates a CertificateInstallationRes message, which is the signed contract data, as defined in ISO 15118-2:2014. After creating the contract data, the signed contract data is stored in the certificate pool 9 (arrow A1) for provision to the CPO server 7 and the OEM server 6.

[0029] The CPS SUB CA1 certificate is issued by the V2G root Certification Authority (CA), which is the top-level certification authority, and is paired with the private key of the V2G root certificate. The certificate is signed. That is, the certificate can be signed in a kind of chain format. For example, the CPS server 8 sends a certificate signing request to the V2G root CA, and the V2G root CA provides the CPS server 8 with a signed CPS SUB CA1 certificate. The CPS server 8 then signs the CPS SUB CA2 certificate with the private key paired with the CPS SUB CA1 certificate, and this signature is performed hierarchically to sign the CPS leaf certificate. Some of the message parameters of CertificateInstallationRes are then signed by the CPS leaf certificate. The CPS leaf certificate is verified to ensure the authenticity of this signature. Because this verification is performed by tracing the hierarchical certificate chain, the vehicle 1 needs to have the V2G root certificate, which is the trust anchor (the highest certificate) of the CPS leaf certificate.

[0030] For this reason, a V2G root certificate is installed in vehicle 1 in advance. Vehicle 1 verifies the signature of the CPS SUB CA1 certificate using the V2G root certificate. Vehicle 1 then verifies the signature of the CPS SUB CA2 certificate using the verified CPS SUB CA1 certificate. Vehicle 1 then verifies the signature of the CPS leaf certificate using the verified CPS SUB CA2 certificate, and finally verifies the CertificateInstallationRes message, which is the contract data.

[0031] The certificate pool 9 is the main repository of signed contract data for the MO server 5, OEM server 6, and CPO server 7. Two methods of providing signed contract data are assumed: via the charging equipment 2 and via the OEM server 6. The TLS handshake between the vehicle 1 and the charging equipment 2 After the successful transfer, vehicle 1 creates a signed CertificateInstallationReq, a request defined in ISO15118-2:2014. This request is forwarded from the CPO server 7 to the certificate pool 9. The certificate pool 9 then responds to vehicle 1 via the CPO server 7 with the available signed contract data as a CertificateInstallationRes message (arrow A2). The signed contract data can also be provided to vehicle 1 via the OEM server 6 (arrow A3).

[0032] 2 is a diagram illustrating an example of the hardware configuration of the vehicle 1 and the charging facility 2. The vehicle 1 has an on-board device 10 and a battery 19 whose charging is controlled by the on-board device 10.

[0033] The in-vehicle device 10 has a CPU 11, a main memory unit 12, and external devices connected to an external interface (I / F), and executes information processing by a program. Examples of the external devices include an external memory unit 13, a display unit 14, an operation unit 15, an external communication unit 16A, and a charging and communication unit 16B. The CPU 11 and the main memory unit 12 can be collectively referred to as a control unit. The control unit is also called an Electronic Control Unit (ECU). The control unit is an example of a controller. is.

[0034] The CPU 11 executes a computer program that is deployed in an executable manner in the main storage unit 12, and provides the functions of the in-vehicle device 10. The CPU 11 includes a processor, an MCU (Micro Controller The main memory 12 stores the computer program executed by the CPU 11. , and stores data to be processed by the CPU 11.

[0035] The main memory unit 12 is a memory device that includes a dynamic random access memory (DRAM) and a static random access memory (SRAM). ROM is a memory that can be used for storing data in a single file. This includes flash main memory, which is erasable and writable. SRAM and ROM provide examples of non-volatile storage, while DRAM provides an example of a RAM storage area.

[0036] The external storage unit 13 is used, for example, as a storage area that supplements the main storage unit 12, and stores computer programs executed by the CPU 11, data processed by the CPU 11, etc. The external storage unit 13 is a hard disk drive, a solid state drive (SSD), etc.

[0037] The display unit 14 is, for example, a liquid crystal display, an electroluminescence panel, etc. The operation unit 15 is, for example, a keyboard, a pointing device, etc. In this embodiment, a touch panel equipped with a touch sensor is exemplified as the pointing device. The display unit 14 and the operation unit 15 act as a user interface that can be used by the user. Therefore, the in-vehicle device 10 is an example of a device having a user interface that can be used by the user.

[0038] The external communication unit 16A exchanges data with other devices (such as the OEM server 6 in FIG. 1) on a public network such as the network N1 (see FIG. 1). For example, the CPU 11 communicates with a computer of a carrier on the public network through the external communication unit 16A. The external communication unit 16A may be a wireless communication device that accesses a mobile phone network. The external communication unit 16A may also be a communication device that accesses a wireless local area network (LAN). The external communication unit 16A is called a Telematics Control Unit (TCU), and controls the network N1. 1 may be used to carry out communication called telematics.

[0039] The charging communication unit 16B transmits and receives signals to and from the charging communication unit 26B. That is, the charging communication unit 16B communicates with the charging facility 2 using, for example, a PLC (Power Line Communications)-based However, the charging communication unit 16B may communicate with the charging communication unit 26B via a CAN (Controller Area Network), a wireless LAN, an Ethernet, or the like. The communication may be performed according to the external communication unit 16A or a communication procedure based on the external communication unit 16A. The charging communication unit 16B may have a CPU, a main memory unit, an input / output interface, a communication interface, etc. In this embodiment, the in-vehicle device 10 communicates with the charging facility 2 via the external communication unit 16A or the charging communication unit 16B, and executes a charging or discharging request and an authentication process (also referred to as a verification process).

[0040] The charging equipment 2 has a CPU 21, a main memory unit 22, and external devices connected to an external interface (I / F), and executes information processing using a program. Examples of the external devices include an external memory unit 23, a display unit 24, an operation unit 25, an external communication unit 26A, a charging communication unit 26B, and an EIM reader 2A. The charging equipment 2 also has a power supply circuit 29. The configuration of the charging equipment 2, other than the EIM reader 2A and the power supply circuit 29, is the same as that of the on-board device 10 of the vehicle 1, and therefore a description thereof will be omitted.

[0041] The EIM reader 2A is a card reader that reads information from an IC card such as a credit card by contact or contactless, an image reader that reads a QR code (registered trademark), an RFID reader, etc. The power supply circuit 29 supplies power to the battery 19 and charges the battery 19.

[0042] The MO server 5, OEM server 6, CPO server 7, CPS server 8, and certificate pool 9 have the same configuration as CPUs 11, 21, main memories 12, 22, external memories 13, 23, display units 14, 24, operation units 15, 25, external communication units 16A, 26A, etc. The MO server 5, OEM server 6, CPO server 7, CPS server 8, and certificate pool 9 are general-purpose computers. Note that the MO server 5, OEM server 6, CPO server 7, CPS server 8, and certificate pool 9 may be a collection of multiple computers called a cloud.

[0043] (Certificate renewal procedure) FIG. 3 is a diagram illustrating an example of data flow between a certificate issuing device 5A that issues a certificate, an intermediate distribution device 6A that distributes the issued certificate, and a recipient device 1A that receives and installs the certificate.

[0044] Here, for example, if the certificate is a Contract certificate, the certificate issuing device 5A is the MO server 5 or the certificate pool 9, the intermediate distribution device 6A is the OEM server 6 or the CPO server 7, and the recipient device 1A is the in-vehicle device 10. Also, for example, if the certificate is a V2G root certificate, the certificate issuing device 5A is a server provided by the V2G root CA. Also, if the certificate is a V2G root certificate, the intermediate distribution device 6A is the OEM server 6 or the CPO server 7. Furthermore, in this case, the recipient device 1A is exemplified by any one of the MO server 5, the OEM server 6, the CPO server 7, the CPS server 8, the charging facility 2, the in-vehicle device 10, etc.

[0045] Furthermore, the certificate issuing device 5A is an example of an issuing device. Furthermore, the intermediate distribution device 6A is an example of a management device that distributes certificate data related to charging of the vehicle 1 to the vehicle 1. In this embodiment, the receiver device 1A is described as an in-vehicle device 10. As shown in FIG. 2 , the in-vehicle device 10 cooperates with the intermediate distribution device 6A as the receiver device 1A, is mounted on the vehicle 1, and controls charging of the vehicle 1 based on the certificate data.

[0046] In updating a certificate, a user or administrator (hereinafter simply referred to as a user) of the receiver device 1A requests a certificate update via a user interface to the intermediate distribution device 6A (S1). The user interface is, for example, a website provided by the intermediate distribution device 6A. In the process of S1, the intermediate distribution device 6A, which is an example of a management device, updates the certificate data before the update. This is an example of receiving a request from the user of the vehicle 1.

[0047] For example, a user may access the website of the intermediate distribution device 6A using a user interface (UIF) device including the display unit 14 and operation unit 15 of the in-vehicle device 10. A user may also access the website of the intermediate distribution device 6A using a smartphone or the like. Even when the intermediate distribution device 6A is the OEM server 6 and the receiver device 1A is the MO server 5, the CPO server 7, the CPS server 8, or the charging facility 2, the procedure for requesting the intermediate distribution device 6A to update the certificate is the same as above.

[0048] Through user operations on the website, the intermediate distribution device 6A receives inputs of user identification information that identifies the user, vehicle identification information that identifies the vehicle, issuer identification information that identifies the certificate issuing device 5A, type information that specifies the type of certificate to be updated, etc. Hereinafter, the user identification information, vehicle identification information, issuer identification information, type information, etc. will be referred to as specific information.

[0049] Then, the intermediate distribution device 6A identifies a certificate based on the identification information and notifies the certificate issuing device 5A of a certificate request (S2). The processing of S2 is an example of requesting the certificate issuing device 5A to issue updated certificate data based on the identification information. In response to the certificate request of S2, the certificate issuing device 5A issues updated certificate data (e.g., D1) (S3). Note that in FIG. 3, the certificate data is simply written as "certificate D1" or the like.

[0050] The intermediate distribution device 6A references the identification information (ID) of the certificate data (D1) from the ID table based on the specific information input by user operation (S4). When newly installing certificate data (D1, etc.), the intermediate distribution device 6A generates a unique ID for the specific information and records it in the ID table. The process of recording in the ID table is an example of storing the correspondence between the ID, which is data identification information assigned to the certificate data for renewal issued by specifying the specific information, and the specific information. The ID table will be described separately with reference to FIG. 4.

[0051] The ID is an example of data identification information that can distinguish the certificate data from other certificate data. Then, the intermediate distribution device 6A assigns an ID to the renewal certificate data (D1) through the processing of S4. The processing of S4 is an example of determining the data identification information (ID) of the renewal certificate data that is the target of the request, according to an ID table that is an example of a correspondence relationship. In FIG. 3, Certificate D1.ID is an example of the ID of the renewal certificate data (D1).

[0052] Furthermore, when the intermediate distribution device 6A newly installs certificate data (e.g., D0) in the receiver device 1A, it stores the installed certificate data (D0) as a distributed certificate in a non-volatile area of ​​a storage device similar to the main memories 12 and 22. The intermediate distribution device 6A reads the previously installed pre-update certificate data (D0) from the non-volatile area of ​​the storage device, concatenates it with the update certificate data (D1), and calculates a hash value. The intermediate distribution device 6A then stores the hash value and information indicating the algorithm of the hash value as history information (S4). The hash value calculated in S4 is an example of a first hash value. In FIG. 3, certificate D1.HISTORY exemplifies history information based on the pre-update certificate data (D0) and the update certificate data (D1).

[0053] The history information is, for example, History Information.Hash Value=Hashalg(OldContractCert·NewContractCert); History Information.Algorithm=alg; where the dot "·" indicates a bit pattern. OldContractCert and NewContractCert are the certificate data before and after the update, respectively. Also, alg is information that specifies the algorithm. Also, Hashalg is information that specifies the algorithm. It is a hash function calculated using the algorithm alg.

[0054] The intermediate distribution device 6A then creates and assigns a signature AU1 to the generated ID, history information, and update certificate data (D1) using the signature private key (S5). Note that the certificate D1.DATA represents the update certificate data (D1) being processed by the intermediate distribution device 6A. The intermediate distribution device 6A then transmits the ID, history information, and certificate data (D1) with the assigned signature AU1 to the recipient device 1A. Here, the data including the ID as data identification information, the update certificate data, and the signature is called update data.

[0055] That is, through the processes of S4 and S5, the intermediate distribution device 6A creates a signature based on an ID as an example of data identification information and the certificate data for update (D1), and transmits the data identification information, the certificate data for update (D1), and the signature as update data to the in-vehicle device 10. Furthermore, through the processes of S4 and S5, the intermediate distribution device 6A calculates a first hash value based on the certificate data before update and the certificate data for update, includes the first hash value in the update data, and transmits it to the in-vehicle device 10.

[0056] When the recipient device 1A receives these data, it first verifies the signature AU1 with the signature public key corresponding to the signature private key (S6). If the signature verification is successful and the recipient device 1A can verify that the update certificate data (D1) is correct, it updates the pre-update certificate data (e.g., D0) identified from the ID with the update certificate data (D1). The pre-update certificate data (D0) is certificate data stored in the recipient device 1A.

[0057] Furthermore, the recipient device 1A compares the history information (or hash value) received together with the renewal certificate data (D1) with the history information (or hash value) stored together with the existing certificate data before renewal. Note that the recipient device 1A may compare only the hash values, or may compare both the hash value and the information specifying the algorithm included in the history information. The hash value received together with the renewal certificate data (D1) is an example of a first hash value included in the renewal data. The hash value stored together with the existing certificate data before renewal is an example of a second hash value.

[0058] If the received history information (or hash value) matches the history information (or hash value) stored in the receiver device 1A, this means that the update certificate data D1 has already been installed in the receiver device 1A via another route. Here, if the intermediate distribution device 6A is the OEM server 6, the other route is, for example, a route that passes through the charging facility 2. If the two pieces of history information (or hash values) match, the receiver device 1A does not perform the update. In other words, the receiver device 1A maintains the certificate data before the update and cancels the update with the update certificate data.

[0059] (Example data) FIG. 4 is a diagram illustrating data in an ID table. The ID table is, for example, data in a tabular format. Each row in the ID table has the following elements: user identification information, vehicle identification information, issuer identification information, contract information, and ID. Each row in the ID table can be said to be specific information that identifies at least one of a user and a vehicle. The user identification information is information that identifies the user of the receiver device 1A. The user identification information may be user management information assigned to the user by the intermediate distribution device 6A. The user identification information may be a user ID used when the user logs in to the intermediate distribution device 6A. The user identification information may be associated with an EMAID that is generated by the MO when the contract is concluded and that identifies the contract.

[0060] The vehicle identification information may be information for identifying the vehicle 1 of the user managed by the OEM. The vehicle identification information may be a PCID for identifying the vehicle 1 in the contract data. The issuer identification information is information that identifies the certificate issuing device 5A. The issuer identification information may be, for example, the domain name or Internet Protocol (IP) address of the certificate issuing device 5A. , a unique identifier for identifying the provider, or the like.

[0061] Furthermore, for example, in the case of a Contact certificate, the type information is information that identifies the contract corresponding to the Contact certificate. For example, the type information specifies the type of contract and information that identifies the contract, such as "Contract Certificate Contract A" or "Contract Certificate Contract B." Furthermore, for example, in the case of a V2G root certificate, the type information is information that specifies the type of certificate and the type and purpose of the certificate, such as "V2G root certificate for Europe" or "V2G root certificate for USA." The ID is identification information generated by the intermediate distribution device 6A and is a unique character string.

[0062] FIG. 5 is a flowchart illustrating a distribution process of the intermediate distribution device 6A. In this process, first, the user of the receiver device 1A logs in to the website of the intermediate distribution device 6A (S11). Through the user's login, the intermediate distribution device 6A recognizes user identification information. Then, the intermediate distribution device 6A accepts input of vehicle identification information, issuer identification information, and type information from the user (S12). Alternatively, the intermediate distribution device 6A may initiate the process of FIG. 5 through its own independent processing without accepting input from the user. For example, the intermediate distribution device 6A may search a database for information about a certificate that requires distribution (such as the user identification information (certificate distribution destination), vehicle identification information, issuer identification information, and type information in FIG. 4). Then, the intermediate distribution device 6A distributes the certificate that requires distribution to the searched distribution destination. If there are multiple certificate distribution destinations, the intermediate distribution device 6A may repeatedly execute the same process as FIG. 5 for the multiple distribution destinations. Note that the distribution of a certificate through the proactive processing on the part of the intermediate distribution device 6A may be limited to when the certificate is renewed, because when a certificate is renewed, the user identification information, vehicle identification information, issuer identification information, type information, etc., of the certificate that was initially distributed are stored.

[0063] Next, the intermediate distribution device 6A acquires certificate data (e.g., D1) from the certificate issuing device 5A corresponding to the issuer identification information of the accepted certificate (S13). Next, the intermediate distribution device 6A accepts from the user whether the certificate is to be newly issued or renewed, and determines the result of the acceptance (S14). If the result of the determination in S14 is a new certificate issuance, the intermediate distribution device 6A acquires a new unique ID and registers the ID in the ID table in association with the user identification information, vehicle identification information, issuer identification information, and type information (S15). Furthermore, the intermediate distribution device 6A creates history information (S16). In the process of S16, since there is no certificate data before renewal, the history information may be empty data. In this case, the history information may be created only from the received certificate data for renewal (D1).

[0064] On the other hand, if the determination result in S14 is update, the intermediate distribution device 6A refers to the ID table based on the user identification information, vehicle identification information, issuer identification information, and type information, and acquires the corresponding ID (S17). Next, the intermediate distribution device 6A reads the pre-update certificate data (e.g., D0) from the distributed certificate in the non-volatile area of ​​the storage device, concatenates it with the update certificate data (e.g., D1), and calculates a hash value using a hash function. Then, the intermediate distribution device 6A creates history information from the calculated hash value and the algorithm used for the calculation (S18).

[0065] Next, the intermediate distribution device 6A assigns a signature to the ID, history information, and certificate data obtained in the processes from S14 to S18 (S19). For example, the intermediate distribution device 6A calculates a hash value by concatenating the ID, history information, and certificate data (D1) obtained in the processes from S14 to S18, and encrypts the hash value with a signature private key to create a signature.

[0066] The intermediate distribution device 6A then transmits the signed ID, history information, and certificate data (D1) to the recipient device 1A (S20). The signed ID, history information, and certificate data are referred to as update data. The intermediate distribution device 6A then stores the certificate data (D1) that was included in the update data and transmitted to the recipient device 1A this time in the distributed certificate in the non-volatile area of ​​the storage device (S21).

[0067] FIG. 6 is a flowchart illustrating a certificate update process of the recipient device 1A. This process is executed by the recipient device 1A when the user requests an update from the intermediate distribution device 6A. When the intermediate distribution device 6A transmits update data to the recipient device 1A, it may notify the recipient device 1A whether the certificate data is to be newly issued or updated. As described in FIG. 5, the intermediate distribution device 6A may initiate the process of FIG. 5 by its own initiative without receiving input from the user. In this case, in the process of FIG. 6, the recipient device 1A receives update data from the intermediate distribution device 6A without the user requesting an update from the intermediate distribution device 6A.

[0068] In the process of Figure 6, the recipient device 1A first receives update data for installing a certificate (S31). Then, the recipient device 1A performs signature verification (S32). There are no limitations on the method of signature verification. For example, the signature verification may be performed by decrypting the signature with an encryption key and comparing the decrypted hash value with the hash values ​​of the ID, history information, and certificate data obtained from the update data to check whether they match.

[0069] Then, the recipient device 1A determines whether the signature verification is successful (S33). If the signature verification is successful, the recipient device 1A compares the history information in the received update data with the existing history information stored together with the pre-update certificate data (e.g., D0) (S34). Then, the recipient device 1A determines whether the received history information matches the existing history information (S35).

[0070] If the received history information does not match the existing history information, the recipient device 1A updates the existing certificate data (e.g., D0) with the certificate data (e.g., D1) in the received update data (S36). Thereafter, the recipient device 1A ends the process.

[0071] On the other hand, if the signature verification fails in S33, the recipient device 1A executes error processing for the signature verification (S37). The error processing is, for example, displaying an error. Then, the recipient device 1A ends the processing. Also, if it is determined in S35 that the received history information matches the existing history information, the recipient device 1A executes duplication error processing because the certificate data for update is the same as the existing certificate data. The duplication error processing is, for example, displaying a message that the certificate data for update has already been installed. Then, the recipient device 1A ends the processing.

[0072] (Variation) In the above embodiment, the intermediate distribution device 6A includes the ID and history information in the update data and transmits it to the receiver device 1A, as shown in S4 of FIG. 3 and S17 to S19 of FIG. 5. However, both the ID and history information are not essential in the information system 100. For example, the intermediate distribution device 6A may exclude the history information from the update data. The history information prevents the certificate data from being installed multiple times. Therefore, even if the certificate data is installed multiple times due to the absence of history information, no problems with security or the like will arise.

[0073] (Effects of the embodiment) The intermediate distribution device 6A, which serves as a management device, performs the following process when updating certificate data stored in the receiver device 1A, exemplified by the in-vehicle device 10. That is, the intermediate distribution device 6A assigns an ID, which is data identification information that enables the certificate data to be distinguished from other certificate data, to the certificate data. In particular, in the above-described modified example, the intermediate distribution device 6A omits the history information and creates a signature based on the data identification information (ID) and the certificate data for update. Furthermore, the intermediate distribution device 6A transmits the data identification information, the certificate data for update, and the signature to the receiver device 1A as update data.

[0074] On the other hand, upon receiving the update data, the recipient device 1A verifies the signature. If the verification is successful, the recipient device 1A is identified by an ID, which is data identification information, and updates the pre-update certificate data (e.g., D0) stored in the recipient device 1A with the update certificate data (e.g., D1). Therefore, the information system 100 including the intermediate distribution device 6A and the recipient device 1A can safely and reliably update the certificate data used for authentication for charging.

[0075] 3, 5, and 6, the intermediate distribution device 6A, acting as a management device, calculates a first hash value based on the pre-update certificate data and the update certificate data stored in the intermediate distribution device 6A, includes the first hash value in the update data, and transmits the calculated value to the receiver device 1A. If the second hash value stored with the pre-update certificate data matches the first hash value included in the update data, the receiver device 1A maintains the pre-update certificate data. That is, the receiver device 1A cancels updating using the update certificate data. Therefore, the information system 100 can avoid duplicate updates by using the hash value calculated by the intermediate distribution device 6A based on the pre-update certificate data and the update certificate data. That is, the receiver device 1A can prevent repeated updates using already updated certificate data by comparing the history information received from the intermediate distribution device 6A with the history information already stored in the receiver device 1A.

[0076] Furthermore, the intermediate distribution device 6A, which serves as a management device, receives a request from a user to update the pre-update certificate data. Here, the request includes specific information that identifies at least one of the user and the vehicle. Then, based on the specific information, the intermediate distribution device 6A requests the certificate issuing device 5A, which serves as the certificate data issuer, to issue updated certificate data. Therefore, the intermediate distribution device 6A can identify the updated certificate data based on information related to the user or the vehicle and request it from the certificate issuing device 5A.

[0077] Furthermore, the intermediate distribution device 6A, which serves as a management device, stores in an ID table the correspondence between the data identification information assigned to the certificate data for renewal issued with the specified identification information and the specified information.The intermediate distribution device 6A then determines the ID, which is the data identification information of the certificate data for renewal that is the target of the request, according to the correspondence in the ID table.Therefore, the intermediate distribution device 6A can identify the certificate data for renewal based on information related to the user or vehicle.

[0078] A receiver device 1A, exemplified by an in-vehicle device 10, receives update data from an intermediate distribution device 6A. The update data includes an ID and update certificate data, to which a signature created based on the ID, which is data identification information that enables the certificate data to be distinguished from other certificate data, and the update certificate data is attached. The receiver device 1A then verifies the signature, and if the verification is successful, updates the pre-update certificate data, which is identified by the ID and stored in the receiver device 1A, with the update certificate data. Therefore, the receiver device 1A can safely and reliably update the certificate used for authentication for charging using the signature and ID.

[0079] (Computer-readable recording medium) A program that causes a computer or other machine or device (hereinafter referred to as a computer, etc.) to realize any of the above functions can be recorded on a computer-readable recording medium. Then, by having the computer, etc. read and execute the program from this recording medium, the function can be provided.

[0080] Here, a computer-readable recording medium refers to a recording medium that stores information such as data and programs electrically, magnetically, optically, mechanically, or chemically and can be read by a computer. Among such recording media, those that can be removed from a computer include, for example, flexible disks, magneto-optical disks, CD-ROMs, CD-R / Ws, DVDs, Blu-ray disks, and memory cards such as flash memory. Furthermore, recording media that are fixed to a computer include hard disks and ROMs (read-only memories). Furthermore, SSDs (Solid State Drives) are The recording medium can be used as a recording medium that can be removed from a computer or the like, or as a recording medium that is fixed to a computer or the like. [Explanation of symbols]

[0081] 1 vehicle 2 Charging equipment 5 MO Server 6 OEM Servers 7 CPO Server 8 CPS Server 9 Certificate Pools 10 Onboard equipment 11, 21 CPUs 12, 22 Main memory 13, 23 External memory unit 14, 24 Display section 15, 25 Operation section 16A, 26A external communication section 16B, 26B Charging communication section 19 Battery 29 Power circuit

Claims

1. a management device that distributes certificate data related to charging of a vehicle to the vehicle; an on-board device that is mounted on the vehicle and controls charging of the vehicle based on the certificate data, The management device assigning data identification information to the certificate data that can be distinguished from other certificate data, and when updating the certificate data stored in the in-vehicle device, creating a signature based on the data identification information and the certificate data for update, and transmitting the data identification information, the certificate data for update, and the signature to the in-vehicle device as update data; The in-vehicle device When the update data is received, the signature is verified, and if the verification is successful, the pre-update certificate data identified by the data identification information and stored in the in-vehicle device is updated with the update certificate data. Information systems.

2. the management device calculates a first hash value based on the pre-update certificate data stored in the management device and the update certificate data, includes the first hash value in the update data, and transmits the update data to the in-vehicle device; 2. The in-vehicle device according to claim 1, wherein, when a second hash value stored in the in-vehicle device together with the certificate data before the update matches the first hash value included in the update data, the in-vehicle device maintains the certificate data before the update and cancels updating with the certificate data for update. Information systems.

3. 2. The management device according to claim 1, wherein the management device receives a request from a user to update the certificate data before the update, the request having specific information that identifies at least one of the user and the vehicle, and requests an issuer of the certificate data to issue the certificate data for the update based on the specific information. Information systems.

4. 4. The management device according to claim 3, wherein the management device stores a correspondence relationship between the data identification information assigned to the certificate data for update issued by specifying the identification information and the identification information, and determines the data identification information of the certificate data for update that is the target of the request according to the correspondence relationship. Information systems.

5. An on-board device that cooperates with a management device that distributes certificate data related to charging of a vehicle to the vehicle, is mounted on the vehicle, and controls charging of the vehicle based on the certificate data, When update data including data identification information and the certificate data for update, to which a signature created based on data identification information that can identify the certificate data from other certificate data and the certificate data for update is attached, is received from the management device, the signature is verified, and if the verification is successful, the certificate data before update, which is identified by the data identification information and stored in the in-vehicle device, is updated with the certificate data for update. In-vehicle device.

6. an on-board device that is mounted on the vehicle and cooperates with a management device that distributes certificate data related to charging of the vehicle to the vehicle, and controls charging of the vehicle based on the certificate data; the data identification information from the management device, to which a signature created based on data identification information that can distinguish the certificate data from other certificate data and the certificate data for update has been added; and the certificate data for update, verifying the signature, and if the verification is successful, updating the certificate data before update, which is identified by the data identification information and stored in the in-vehicle device, with the certificate data for update. program.

Images