Information systems, transmitter equipment, in-vehicle equipment, and programs

Abstract

This invention provides a method and system for securely and reliably updating multiple certificate data used for authentication in information processing devices such as in-vehicle devices. [Solution] When the sender device 5A updates certificate data stored in the receiver device 1A, which is an in-vehicle device, it sends a first hash value based on at least the certificate data before the update and the certificate data for the update, the certificate data before the update, and the certificate data for the update as update data to the in-vehicle device. The in-vehicle device receives the update data from the sender device, calculates a second hash value based on the certificate data before the update and the certificate data for the update, and if the first hash value and the second hash value match, and the certificate data before the update included in the update data matches the certificate data before the update stored in the in-vehicle device, the in-vehicle device updates the certificate data before the update stored in the in-vehicle device with the certificate data for the update included in the update data.

Description

Technical Field

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

Background Art

[0002] As vehicles (also referred to as electric vehicles) that can be charged from an external power source to a driving battery, battery electric vehicles (BEV vehicles), plug-in hybrids (PHV) vehicles, etc. are known. Also, for authentication in charging the driving battery, certificates are stored in the computers of operators involved in authentication and the in-vehicle devices of vehicles. Examples of certificates include Contract certificates and V2G route certificates.

[0003] Certificates have an expiration date, and certificates with an expired expiration date need to be replaced with new ones. Also, even if the expiration date has not expired, if the certificate has become invalid, the corresponding secret key has been leaked, or the algorithm has been endangered, the corresponding certificate needs to be updated to a new one as well. As a general technique for enhancing the reliability of vehicle data, for example, it has been proposed to verify data after writing the data to the storage device of the vehicle (see Patent Document 1 below).

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] Incidentally, vehicles are expected to hold multiple certificates. Therefore, when updating certificates 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 in-vehicle device, it is necessary to determine whether the intention is to update a specific certificate or to add a new certificate.

[0006] This is because when a certificate is renewed, its Subject name and Serial Number are used in the previous version. This issue stems from the lack of a way to link the old certificate with the new certificate, given that the certificate will inevitably change. Furthermore, from a security standpoint, a secure method for linking the old and new certificates is necessary.

[0007] RFC 4210 specifies a method of cross-signing a new certificate and an old certificate using their respective private keys. This method is effective when replacing a certificate due to expiration. However, it is not effective when the private key is compromised, as it is used after the private key of the old certificate has been compromised.

[0008] One aspect of the disclosed embodiment is to enable secure and reliable updating of multiple certificate data used for authentication in an in-vehicle device. [Means for solving the problem]

[0009] One aspect of the embodiment of the disclosure is illustrated by an information system. This information system comprises a sender device that delivers certificate data relating to vehicle charging to a vehicle, and an on-board device installed in the vehicle that controls the vehicle's charging. The sender device delivers certificate data stored in the on-board device. When updating data, a first hash value based on at least the certificate data before the update and the certificate data for the update, along with the certificate data before the update and the certificate data for the update, are sent to the in-vehicle device as update data. Meanwhile, the in-vehicle device receives the update data from the sending device and calculates a second hash value based on the certificate data before the update and the certificate data for the update. The in-vehicle device then determines whether the first hash value and the second hash value match, and whether the certificate data before the update included in the update data matches the certificate data before the update stored in the in-vehicle device. If both of these determinations result in a match, the in-vehicle device updates the certificate data before the update stored in the in-vehicle device with the certificate data for the update included in the update data. [Effects of the Invention]

[0010] In this information system, the update data transmitted by the sender device includes a first hash value based on the pre-update certificate data and the update certificate data, the pre-update certificate data, and the update certificate data. The in-vehicle device that receives the update data first calculates a second hash value based on the pre-update certificate data and the update certificate data, and determines whether it matches the first hash value. Furthermore, the in-vehicle device determines whether the pre-update certificate data included in the update data matches the pre-update certificate data stored in the in-vehicle device. By determining whether the first and second hash values ​​match, the in-vehicle device can confirm that the pre-update certificate data and the update certificate data are valid. Next, the in-vehicle device can confirm the certificate data to be updated by determining whether the pre-update certificate data included in the update data matches the pre-update certificate data stored in the in-vehicle device. In other words, after confirming the certificate data to be updated, the in-vehicle device can update the pre-update certificate data with the valid update certificate data. Therefore, this information system allows the in-vehicle device to safely and reliably update multiple certificate data used for authentication. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a diagram illustrating an information system of the first embodiment. [Figure 2] Figure 2 illustrates the hardware configuration of the vehicle and charging equipment. [Figure 3] Figure 3 is an example of a certificate chain. [Figure 4] Figure 4 is a data flow diagram illustrating the procedure by which a sender device that issues a certificate distributes the certificate to a recipient device that updates the certificate. [Figure 5] Figure 5 is a data flow diagram illustrating the procedure by which, in the second embodiment, a sender device distributes a certificate to a receiver device that is updating the certificate. [Modes for carrying out the invention]

[0012] <First Embodiment> The information system 100, the in-vehicle device 10, and the computer program executed by the in-vehicle device 10 (hereinafter simply referred to as "the program") according to the first embodiment will be described below with reference to Figures 1 to 4. (composition) Figure 1 illustrates an information system 100 of this embodiment. The information system 100 includes a vehicle 1 equipped with an in-vehicle device 10 and equipment involved in supplying power to the vehicle 1. For example, in Figure 1, the equipment includes a charging system (EVSE) 2 that supplies power to the vehicle 1's battery 19 (see Figure 2, also called a secondary battery or storage battery). This equipment also includes a Mobility Operator (MO) service that exchanges information with the vehicle 1 directly or indirectly through other devices. This includes devices such as server 5, OEM server 6, Charge Point Operator (CPO) server 7, Certificate Provisioning Service (CPS) server 8, and certificate pool 9. The computers involved in charging vehicle 1 can be described as: B5, OEM server 6, CPO server 7, CPS server 8, and certificate pool 9.

[0013] Each device in Figure 1 can be connected by network N1. Network N1 is, for example, Long Term Evolution (LTE), 5th Generation Mobile Communication System ( This includes wireless networks such as 5G and 6th Generation Mobile Communication System (6G), as well as wired public networks such as the Internet. The wireless network may also include the wireless access network provided by base stations and the core network (wired).

[0014] Vehicle 1 is called an electric vehicle and can charge its traction battery 19 (see Figure 2). Vehicle 1 has an on-board device 10 that performs charging, discharging, or charge / discharge control in relation to the charging equipment 2. The owner or driver of Vehicle 1 (hereinafter also referred to as the user) enters into a contract with a service provider (e.g., MO) in advance to perform charging and discharging between the charging equipment 2 and the battery 19 of Vehicle 1. Under this contract, a contract certificate and an encryption key (referred to as the contract private key) are issued from the MO server 5 and installed in Vehicle 1, for example, via the OEM server 6. The contract certificate and 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 Vehicle 1, for example, via the charging equipment 2.

[0015] In the charging process, as part of the PnC procedure, the on-board device 10 of vehicle 1 creates a signature based on a Contract certificate and Contract private key, which is then verified by the charging equipment 2. If the verification is successful, vehicle 1 performs charging or discharging with the charging equipment 2. Such a PnC procedure is initiated, for example, when a plug for supplying power from the charging equipment 2 is connected to the power receiving section of vehicle 1.

[0016] In addition, in the charging of the vehicle 1, in addition to the procedure by PnC as described above, a procedure of an external authentication method (External Identification Means; EIM) by presenting a Radio Frequency Identification (RFID) card or the like is also possible. For this reason, the charging facility 2 has an EIM reader 2A (see FIG. 2). The external authentication method is, for example, an authentication method based on user information obtained from a credit card, a QR code (registered trademark), an RFID card, etc. via the EIM reader 2A.

[0017] The charging facility 2 may, for example, transfer the signature transmitted from the vehicle 1 to the MO server 5 and request authentication of the user of the vehicle 1. Then, when the authentication at the MO server 5 is successful, the charging facility 2 may charge the battery 19 of the vehicle 1 and charge the user of the vehicle 1.

[0018] Also, when receiving charging, the vehicle 1 can also request installation of a Contract certificate or the like from the charging facility 2. In this case, the vehicle 1 presents a certificate (such as an OEM provisioning certificate) issued by the OEM, which is the manufacturer and seller of the vehicle 1, to the charging facility 2. The charging facility 2 can provide the Contract certificate or the like to the vehicle 1 when it has a valid Contract certificate or the like associated with the OEM provisioning certificate or the like notified from the vehicle 1 and a Contract private key.

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

[0020] The CPO server 7 is a computer that supports the processing of the CPO. The CPO includes the charging facility 2. Also, the CPO includes the enterprise responsible for the management of the charging facility 2 and the service to the vehicle 1 by the charging facility 2. The main business of the CPO is an Information Technology (IT) system This includes managing the charging equipment 2, directly billing the owner or user of vehicle 1, or billing the MO (Ministry of Transportation).

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

[0022] MO Server 5 is a computer that assists with MO processing. MO is an organization that authenticates and pays for charging sessions, or provides charging-related backend services. MO enters into a contract (also called an e-mobility contract) with the owner or driver of Vehicle 1. To conclude.

[0023] The owner or driver of Vehicle 1 shall provide the MO with the unique Provisioning Certificate ID (PCID) of Vehicle 1 at the time of contract signing, and the MO shall use this to obtain a certificate from the certificate pool 9 for OEM Receive the lobbying certificate. The PCID for Vehicle 1 will be used to identify Vehicle 1 when signing the contract.

[0024] As the 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 PnC's authentication of vehicle 1 at charging station 2 refers to the valid contract with the MO. The EMAID, representing the charging contract number, is used when referring to the contract.

[0025] In the second stage, the MO creates certificate data as 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 vehicle 1 can verify its authenticity and integrity.

[0026] CPS Server 8 performs the contract data signing process. During the signing process, 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.

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

[0028] Furthermore, the CPS SUB CA1 certificate is issued by the V2G root certificate issued by the highest-level certification authority, the V2G root Certification Authority (CA), using its corresponding private key. The certificate is signed. That is, the certificate can be signed in the form of a kind of chain. For example, CPS server 8 sends a certificate signing request to the V2G root CA, and the V2G root CA provides the signed CPS SUB CA1 certificate to CPS server 8. Then, CPS server 8 signs the CPS SUB CA2 certificate with the private key paired with the CPS SUB CA1 certificate, and this signing is done hierarchically, signing the CPS leaf certificate. Then, some of the message parameters of CertificateInstallationRes are signed by the CPS leaf certificate. Verification of the CPS leaf certificate is performed to guarantee the correctness of this signature. Since this verification is performed by traversing the hierarchical certificate chain, vehicle 1 must possess the V2G root certificate, which is the trust anchor (the highest level of certificate) of the CPS leaf certificate.

[0029] Therefore, the V2G root certificate is pre-installed on Vehicle 1. Vehicle 1 verifies the signature of the CPS SUB CA1 certificate using the V2G root certificate. Furthermore, Vehicle 1 verifies the signature of the CPS SUB CA2 certificate using the verified CPS SUB CA1 certificate. Furthermore, Vehicle 1 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.

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

[0031] Figure 2 illustrates the hardware configuration of vehicle 1 and charging equipment 2. Vehicle 1 includes an on-board device 10 and a battery 19 whose charging is controlled by the on-board device 10.

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

[0033] The CPU 11 executes the computer program deployed in the main memory 12 to provide the functions of the in-vehicle device 10. The CPU 11 is a processor, MCU (Microcontroller). Also called a Unit. The main memory unit 12 is where the computer programs executed by the CPU 11 are stored. It stores data and other information that CPU 11 will process.

[0034] The main memory unit 12 includes Dynamic Random Access Memory (DRAM) and Static Random Access Memory. These include Memory (SRAM), Read Only Memory (ROM), etc. ROM, for example, can be used in batches. It includes erasable and writable flash memory. SRAM and ROM provide examples of non-volatile areas, while DRAM provides an example of a RAM area.

[0035] The external storage unit 13 is used, for example, as a storage area that assists the main memory 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.

[0036] The display unit 14 is, for example, a liquid crystal display, an electroluminescent 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 that has a user interface that can be used by the user.

[0037] The external communication unit 16A exchanges data with other devices on a public network such as network N1 (see Figure 1) (e.g., the OEM server 6 in Figure 1). For example, the CPU 11 communicates with a carrier's computer on the public network through the external communication unit 16A. The external communication unit 16A may also be a wireless communication device that accesses a mobile phone network. This may 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 is part of the network N It may also be a system that performs communication known as telematics via 1.

[0038] The charging communication unit 16B transmits and receives signals with the charging communication unit 26B. That is, the charging communication unit 16B communicates with the charging equipment 2, for example, based on PLC (Power Line Communications). or a communication method similar to PLC is used for communication. However, the charging communication unit 16B does not use CAN (Controller Area Network), wireless LAN, Ethernet, etc. with the charging communication unit 26B. Communication may be performed using the following communication methods or communication procedures based thereon. The charging communication unit 16B may also have a CPU, a main memory unit, an input / output interface, a communication interface, etc., internally. In this embodiment, the in-vehicle device 10 communicates with the charging equipment 2 via the external communication unit 16A or the charging communication unit 16B and performs charging or discharging requests and authentication processing (also called verification processing).

[0039] The charging equipment 2 includes a CPU 21, a main memory unit 22, and external devices connected to an external interface (I / F), and performs information processing by program. Examples of 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. Furthermore, the charging equipment 2 has a power supply circuit 29. The configuration of the charging equipment 2, excluding 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, so its description is omitted.

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

[0041] MO Server 5, OEM Server 6, CPO Server 7, CPS Server 8, and Certificate Pool 9 have the same configuration as CPUs 11 and 21, main memory units 12 and 22, external storage units 13 and 23, display units 14 and 24, operation units 15 and 25, and external communication units 16A and 26A. MO Server 5, OEM Server 6, CPO Server 7, CPS Server 8, and Certificate Pool 9 are general-purpose computers. Alternatively, MO Server 5, OEM Server 6, CPO Server 7, CPS Server 8, and Certificate Pool 9 may be a collection of multiple computers known as a cloud.

[0042] (certificate chain) Figure 3 illustrates a certificate chain. In Figure 3, rectangles represent certificate and private key pairs, including the public key. For example, the rectangle labeled "V2G_ROOT_CA" represents a V2G certificate. Figure 3 illustrates a certificate chain by connecting each certificate-private key pair with a dotted line. The certificate chain forms a hierarchy of certificate-private key pairs.

[0043] In Figure 3, the V2G root certificate and V2G root private key pair branches into five branches. Each branch contains the following hierarchy of pairs: "CPO_SUB1 CA", "PROV_SUB1 CA", "MO_SUB1 CA", "OEM_SUB1_CA", and "VCL_SUB1 CA".

[0044] In Figure 3, for example, the "MO_SUB1 CA" branch sequentially illustrates the pairs "MO_SUB2 CA" and "CONTRACT_LEAF". The "CONTRACT_LEAF" pair consists of a contract certificate and a contract private key. In a certificate chain, lower-level certificates are signed with the private key of the higher-level pair.

[0045] For example, a Contract certificate is signed with the private key of "MO_SUB2 CA". The certificate of "MO_SUB2 CA" is signed with the private key of "MO_SUB1 CA". Furthermore, the certificate of "MO_SUB1 CA" is signed with the V2G root private key. In this case, the recipient of the Contract certificate, by holding the V2G root certificate, can verify the signature of the "MO_SUB1 CA" certificate using the V2G root public key contained in the V2G root certificate. If this recipient successfully verifies the signature of the "MO_SUB1 CA" certificate, they can then verify the signature of the "MO_SUB2 CA" certificate using the public key contained in the "MO_SUB1 CA" certificate. Finally, if this recipient successfully verifies the signature of the "MO_SUB2 CA" certificate, they can then verify the signature of the "CONTRACT_LEAF" Contract certificate using the public key contained in the "MO_SUB2 CA" certificate.

[0046] In this embodiment, a temporary public key and its corresponding signature are exchanged between the sender (sender device 5A in Figure 4) and the receiver (receiver device 1A in Figure 4). In this embodiment, the hierarchical relationship in the certificate chain is utilized, signatures are exchanged between the sender and receiver, and the sender's legitimacy is verified by the receiver. That is, the sender of the certificate to be renewed (Cx) has a private key (Ct Priv Key) corresponding to the certificate (Ct) that acts as a trusted trust anchor, The system utilizes the fact that the recipient of the certificate to be renewed (Cx) possesses a certificate (Ct) containing the public key. For example, if the certificate to be renewed (Cx) is a contract certificate, the trust anchor certificate (Ct) can be any certificate from the V2G root certificate to the "MO_SUB2 CA" certificate. If the sender possesses the private key of the trust anchor certificate (Ct), the sender can sign the certificate using the private key. If the sender does not possess the private key of the trust anchor certificate (Ct), they can request a signature from the Certificate Authority that possesses the private key. The recipient can verify the signature using the public key of their own certificate (Ct).

[0047] In Figure 3, the branch starting with the "CPO_SUB1 CA" pair is the EVSE LEAF, or Supply Equipment Communication Controllers (SECC) certificate chain. The SECC certificate is used for authentication of the charging equipment 2 with the on-board device 10 of vehicle 1. The certificate chain of the branch starting with the "PROV_SUB1 CA" pair is the PROV LEAF, or CPS certificate chain. The certificate chain of the branch starting with the "OEM_SUB1 CA" pair This is an OEM LEAF, i.e., a chain of OEM provisioning certificates. Furthermore, the certificate chain of branches starting with the "VCL_SUB1 CA" pair is a VCL LEAF, i.e., a VEHICLE certificate. It is a chain. Therefore, when renewing any of the certificates exemplified in Figure 3, the sender only needs to set one of the higher-level certificates (Ct) in the certificate chain as a trust anchor for the certificate to be renewed (Cx). The sender then creates a signature using that private key, and the recipient verifies the signature with the public key contained in the certificate (Ct).

[0048] Furthermore, in Figure 3, "MO_ROOT CA" illustrates the MO root certificate and private key pair used as a trust anchor when MO does not use a V2G root certificate. Similarly, "OEM_ROOT CA" illustrates the trust anchor when OEM does not use a V2G root certificate. An example of an OEM root certificate and private key pair used as such is shown. When a V2G root certificate, MO root certificate, or OEM root certificate is subject to renewal, there is no certificate that serves as its trust anchor. In this embodiment, in such cases, the sender and receiver exchange a temporary public key over a different communication path than the one used to send and receive the certificate to be renewed.

[0049] (Processing procedure) Figure 4 is a data flow diagram illustrating the procedure by which a sender device 5A, which issues a certificate, distributes the certificate to a receiver device 1A, which updates the certificate. In Figure 4, the procedure for distributing Contract certificate C1 is illustrated.

[0050] As shown in Figure 4, if the certificate is Contract Certificate C1, the sender device 5A will be MO Server In this case, the recipient device 1A is either the in-vehicle device 10 or the OEM server 6. Furthermore, for example, if the certificate is a V2G root certificate, the sender device 5A is the server provided by the V2G root CA. In this case, the recipient device 1A is exemplified by one of the following: the MO server 5, the OEM server 6, the CPO server 7, the charging equipment 2, and the in-vehicle device 10. Also, for example, if the certificate is an MO Root certificate, the sender device 5A is the MO server 5. In this case, the recipient device 1A is exemplified by one of the following: the OEM server 6, the CPO server 7, the charging equipment 2, and the in-vehicle device 10. Furthermore, for example, if the certificate is an OEM Root certificate, the sender device 5A is the OEM server 6. In this case, the recipient device 1A is exemplified by one of the following: the MO server 5, the CPO server 7, the charging equipment 2, and the in-vehicle device 10. Furthermore, for example, if the certificate is an OEM provisioning certificate, the sender device 5A is the OEM server 6, and the receiver device 1A is exemplified by the MO server 5 or the in-vehicle device 10, etc. Also, for example, if the certificate is a Vehicle certificate, the sender device 5A is the OEM server 6, and the receiver device 1A is exemplified by an in-vehicle device 10, etc. Furthermore, for example, if the certificate is an SECC certificate, the sender device 5A is the CPO server 7, and the receiver device 1A is exemplified by a charging device 2, etc. However, in this embodiment, the certificate is not limited to those described above. The sender device 5A can be said to be an example of a device that distributes certificate data related to the charging of the vehicle 1 to the vehicle 1.

[0051] This section provides an example of the procedure for when sender device 5A updates Contract certificate C1(OLD) installed on receiver device 1A to Contract certificate C1(NEW). Note that the update from the original Contract certificate C1(OLD) to the updated Contract certificate C1(NEW) may be initiated by an update request from sender device 5A to receiver device 1A. Alternatively, this update may be initiated by an update request from receiver device 1A to sender device 5A.

[0052] The receiver device 1A has, for example, a certificate storage 12A built on the main memory unit 12 or external storage unit 13 as illustrated in Figure 2. Furthermore, the receiver device 1A is assumed to have the pre-update Contract certificate C1(OLD) as the most recently installed certificate.

[0053] In this embodiment, the sender device 5A delivers an update certificate to the receiver device 1A in the following distribution data format. Here, the distribution data is the update data that the sender device 5A delivers to the receiver device 1A when the old certificate (oldCert) installed on the receiver device 1A is updated with a new update certificate (newCert).

[0054] (Distribution data format) {HMAC value, old certificate (oldCert), new certificate (newCert), temporary public key (DHPubKey)} Here, the curly braces ("{" and "}") are used merely to illustrate the start and end of the format, and the format is not limited to using curly braces ("{" and "}"). Similarly, the commas (,) used to separate elements in the format are used merely for illustrative purposes, and the format is not limited to using commas (,); any symbol can be used as a delimiter. In this format, the HMAC value is calculated by the following formula 1.

[0055] HMAC value = HMAC(private key (HMACKey), old certificate (oldCert), new certificate (newCert), bits) (Equation 1) Here, HMAC is a Hash-based Message Authentication Code or keyed-Hash Message Authentication Code, which is a message authentication code calculated based on a hash function. HMAC (Message Authentication Code) is the code used to generate an HMAC. Let's illustrate the algorithm. The structure of Equation 1 used in the HMAC algorithm is explained below.

[0056] The private key (HMACKey) is a private key (shared key) shared by the sender device 5A and the receiver device 1A. In this embodiment, the sender device 5A and the receiver device 1A share a common key via elliptic curve Diffie-Hellman key exchange (ECDH).

[0057] The old certificate (oldCert) and the new certificate (newCert) are messages authenticated by their HMAC values. The old certificate (oldCert) and the new certificate (newCert) can simply be concatenated bits. `bits` is the length of the HMAC value.

[0058] As described above, the sender device 5A and the receiver device 1A first share a common key (HMACKey) using the ECDH protocol, for example. To create a shared key, the public key (OEMProvPubKey) of the OEM provisioning certificate C2 and It is agreed that the private key (OEMProvPrivKey) will be used. Note that the public and private keys for creating the shared key are not limited to the public key (OEMProvPubKey) and private key (OEMProvPrivKey) of the OEM provisioning certificate C2. In short, sender device 5A and receiver device 1A All that is required is to agree on the public and private keys. The public key of the OEM provisioning certificate C2 (OEMProvPubKey) is an example of an authentication public key. The private key (OEMProvPrivKey) of certificate C2 is an example of a private key used for authentication.

[0059] Then, sender device 5A creates a pair of temporary private keys (DHPrivKey) and temporary public keys (DHPubKey) using an algorithm common to the algorithm (including elliptic curves) used to create the agreed public and private keys (T0). Then, sender device 5A sends an OEM provisioning certificate. Using the public key (OEMProvPubKey) from document C2 and the created temporary private key (DHPrivKey), a shared key (HMACKey) is created to be shared with receiver device 1A (T1).

[0060] Next, the sender device 5A installs the created shared key (HMACKey) into the receiver device 1A. The sender device 5A calculates an HMAC value (HMAC) from the pre-update Contract certificate C1(OLD) and the updated Contract certificate C1(NEW), which are stored in the sender device 5A (T2). Then, the sender device 5A sets the calculated HMAC value into the distribution data.

[0061] Next, the sender device 5A sets the installed pre-update Contract certificate C1(OLD) and the updated Contract certificate C1(NEW) in the distribution data. Furthermore, the sender device 5A creates a signature on the created temporary public key (DHPubKey) with the private key of a trusted Certificate Authority's certificate. Here, a trusted Certificate Authority means that the receiver device 1A that receives the distribution data is trusted. In this embodiment, the sender device 5A creates a signature using the private key (MOSub2PrivKey) used for signing when distributing the Contract certificate C1 to be updated. The MOSUB2 certificate corresponding to the private key (MOSub2PrivKey) is V2G, as illustrated in Figure 3. This is because the recipient device 1A can verify its trustworthiness by tracing the certificate chain from the root certificate.

[0062] However, in this case, the signature can be created by any certificate included in the certificate chain from the starting V2G root certificate to the MOSUB2 certificate. In short, it is sufficient for the sender device 5A and the receiver device 1A to agree on which certificate in the certificate chain will be used for signing and signature verification. The sender device 5A then sets the temporary public key (DHPubKey) with the created signature in the distribution data. The sender device 5A then sends the created distribution data to the receiver device 1A.

[0063] Then, the receiver device 1A first responds to the private key (MOSub2PrivKey) used for signing. The signature attached to the temporary public key (DHPubKey) is verified using the public key (MOSub2PubKey) contained in the MOSUB2 certificate (R1). If the signature verification is successful, the receiver device 1A can determine that the sender device 5A is trustworthy. Then, the receiver device 1A creates a shared key (HMACKey) using the private key (OEMProvPrivKey) of the OEM provisioning certificate C2 agreed upon with the sender device 5A and the temporary public key (DHPubKey) received in the distribution data (R 2) In R2 as well, a shared key (HMACKey) is created using the ECDH protocol.

[0064] Then, the receiver device 1A hashed the created common key (HMACKey), the old Contract certificate C1 (OLD) in the distribution data, and the new Contract certificate C1 (NEW). The HMAC value, which is a metric value, is calculated (R3). Then, the receiver device 1A performs HMAC verification to determine whether the calculated HMAC value matches the HMAC value in the distributed data (R4).

[0065] If HMAC verification is successful, the receiver device 1A determines whether the pre-update Contract certificate C1(OLD) in the distribution data matches the currently installed Contract certificate C1(OLD) stored in the certificate storage 12A (R5). If they match, the receiver device 1A updates the currently installed Contract certificate C1(OLD) stored in the certificate storage 12A with the updated Contract certificate C1(NEW) in the distribution data (R6). For example, the receiver device 1A changes its settings so that Contract certificate C1(NEW) will be used in future PnC authentication.

[0066] Furthermore, in step R3 above, the receiver device 1A may use the currently installed Contract certificate C1(OLD) stored in certificate storage 12A instead of the pre-update Contract certificate C1(OLD) in the distribution data. In other words, the receiver device 1A may calculate the HMAC value using the currently installed Contract certificate C1(OLD). By calculating the HMAC value using the currently installed Contract certificate C1(OLD), the receiver device 1A can omit the processing in R5. That is, the receiver device 1A can omit the determination of whether the installed Contract certificate C1(OLD) matches in the distribution data and in certificate storage 12A. This is because if the HMAC values ​​match as determined by the HMAC verification in R4, then the installed Contract certificate C1(OLD) matches in the distribution data and in certificate storage 12A.

[0067] Furthermore, if the signature verification of R1 fails, the receiver device 1A should interrupt processing and perform error handling. This is because, in this case, the sender device 5A may not be trustworthy. Also, if the HMAC verification of R4 fails, the receiver device 1A should interrupt processing and perform error handling. This is because, in this case, at least one of the pre-update Contract certificate C1(OLD) or the updated Contract certificate C1(NEW) in the distribution data may not be trustworthy.

[0068] Furthermore, in processing R5, recipient device 1A may interrupt the process if the pre-update Contract certificate C1(OLD) in the distribution data does not match the currently installed Contract certificate C1(OLD) stored in certificate storage 12A. Then, recipient device 1A may perform error handling. In this case, the renewal Contract certificate C1(NEW) is not the certificate for updating the currently installed Contract certificate C1(OLD) stored in certificate storage 12A.

[0069] (Effects of the embodiment) As described above, in this embodiment, when the sender device 5A updates the certificate (OLD) stored in the receiver device 1A, for example in the in-vehicle device 10, the first hash The value (HMAC value) is calculated (T2). The first hash value is the hash value (HMAC value) based on the pre-renewal certificate (OLD) and the renewal certificate (NEW) installed on the receiver device 1A. The sender device 5A then sends at least the first hash value (HMAC value), the pre-renewal certificate (OLD), and the renewal certificate (NEW) to the receiver device 1A as renewal distribution data.

[0070] The receiver device 1A receives update distribution data from the sender device 5A. The receiver device 1A then calculates a second hash value (HMAC value) based on the certificate before update (OLD) and the certificate for update (NEW) (R3). The receiver device 1A then determines whether the first hash value in the update distribution data matches the second hash value calculated in R3. The receiver device 1A also determines whether the certificate before update (OLD) included in the distribution data matches the certificate before update (OLD) stored in the receiver device 1A. If a match is determined in both cases, the receiver device 1A updates the certificate before update (OLD) stored in the certificate storage 12A with the certificate for update (NEW) included in the distribution data. As a result, in this information system, even when multiple certificates are used, the sender device 5A and the receiver device 1A can accurately identify the certificate to be updated and update the certificate to be updated safely and reliably.

[0071] Furthermore, the sender device 5A has a pair of temporary private keys (DHPrivKey) and temporary public keys (DHPubKey) The sender device 5A then creates the temporary public key (DHPubKey) and sends it to the receiver device 1A (for example, the in-vehicle device 10) in the update distribution data. Furthermore, the sender device 5A creates a shared key using the authentication public key (OEMProvPubKey) and temporary private key (DHPrivKey) that correspond to the authentication private key used by the receiver device 1A when creating the signature. That is, the sender device 5A creates a shared key (HMACKey) to be shared with the receiver device 1A using the authentication public key (OEMProvPubKey) and temporary private key (DHPrivKey) that correspond to the private key (OEMProvPrivKey) of the OEM provisioning certificate C2. Then, the sender device 5A Then, using the created shared key (HMACKey), calculate the first hash value (HMAC value) and distribute Include it in the fabric data.

[0072] On the other hand, receiver device 1A uses the temporary public key (DHPubKey) and authentication private key (OEMProvPrivKey) included in the update distribution data to create a shared key (HMACKey) with sender device 5A. ) is created. Then, receiver device 1A uses the created common key (HMACKey) to send a second The hash value (HMAC value) is calculated. The receiver device 1A can then verify that the first hash value (HMAC value) contained in the distributed data matches the second hash value (HMAC value) it calculated. As a result, in this information system 100, the sender device 5A and the receiver device 1A can securely and reliably exchange the certificate before renewal (OLD) and the certificate for renewal (NEW) using a message authentication code calculated based on the hash function.

[0073] Furthermore, this embodiment illustrates the process when, for example, there is a MOSUB2 certificate, which is an authentication certificate that authenticates the Contract certificate. Alternatively, it illustrates the process when there is a certificate chain that includes the authentication certificate as the lowest-level certificate in a hierarchical certificate group, and sequentially authenticates certificates below each certificate from the top-level V2G root certificate that serves as the starting point down to the MOSUB2 certificate. Here, the certificate chain is an example of a certificate group. When such an authentication certificate or certificate group exists, the sender device 5A creates a signature for a temporary public key (DHPubKey) using the private key (e.g., MOSub2PubKey) corresponding to one of the certificates in the authentication certificate or certificate group, includes it in the update distribution data, and sends it to the receiver device 1A. On the other hand, the receiver device 1A verifies the signature using the public key (e.g., MOSub2PrivKey) corresponding to the private key corresponding to one of the certificates in the authentication certificate or certificate group. The receiver device 1A can verify the signature and authenticity of the sender device 5A based on a trusted trust anchor, and securely obtain the distribution data for the update.

[0074] <Second Embodiment> In the first embodiment described above, the signature of the sender device 5A and its legitimacy were verified based on a trust anchor, which is a higher-level certificate in the certificate chain that authenticates the certificate to be renewed (e.g., a Contract certificate). In this embodiment, an example of processing is given for cases where there is no higher-level certificate that serves as a trust anchor for authenticating the certificate to be renewed, such as when the certificate to be renewed is a V2G root certificate, MO root certificate, OEM root certificate, etc.

[0075] Figure 5 is a data flow diagram illustrating the procedure by which a sender device 5A distributes a certificate to a receiver device 1A that is to update the certificate in the second embodiment. In Figure 5, the procedure for distributing the V2G root certificate C3 as the certificate to be updated is illustrated. As shown in Figure 5, when the certificate to be updated is the V2G root certificate C3, the sender device 5A is a server of the V2G root certification authority, and the receiver device 1A is the MO server 5, OEM server 6, CPO server 7, charging equipment 2, or in-vehicle device 10.

[0076] In the process shown in Figure 5, the common key (HMACKey) is generated by the sender device 5A (T1) and then HM The process up to the calculation of the AC value (T2) is the same as in Figure 4. Also, in the process shown in Figure 5, the process of setting the HMAC value by the sender device 5A, the V2G root certificate C3 (OLD) before the update, and the V2G root certificate C3 (NEW) for the update into the distribution data is the same as in Figure 4.

[0077] However, in this embodiment, there is no certificate acting as a trust anchor for signing the temporary public key (DHPubKey), i.e., no higher-level certificate authenticating the V2G root certificate C3. Furthermore, it is assumed here that the communication path from sender device 5A to receiver device 1A for sending distribution data is an untrusted communication path.

[0078] In this case, the sender device 5A delivers a temporary public key (DHPubKey) to the receiver device 1A via an out-of-band communication path, which is different from the communication path used to transmit the distribution data (T7). Out-of-band communication refers to communication via, for example, a smartphone carried by the user, a personal computer available to the user, or a removable recording medium, and is a different communication path from network N1 in Figure 1.

[0079] Meanwhile, receiver device 1A obtains a temporary public key (DHPubKey) via an out-of-band communication path. Subsequently, receiver device 1A generates a common key (HMACKey) (R2) and places the certificate. The process up to replacement (R6) is the same as in Figure 4. In this way, even when there is no higher-level certificate acting as a trust anchor to authenticate the certificate to be renewed (V2G root certificate C3 in Figure 5), such as the V2G root certificate C3, the sender device 5A performs the same processing as in the first embodiment via an out-of-band communication path different from the communication path (for example, network N1 in Figure 1) used to send distribution data to the receiver device 1A. That is, by the sender device 5A handing over a temporary public key (DHPubKey) to the receiver device 1A, the receiver device 1A can perform authentication using the HMAC value and update with the new certificate after confirming a match with the certificate before renewal (OLD).

[0080] (A computer-readable recording medium) A program that enables a computer or other machine or device (hereinafter referred to as "computer, etc.") to perform any of the above functions can be recorded on a recording medium that the computer, etc. can read. By having the computer, etc. read and execute the program on this recording medium, it can be made to provide that function.

[0081] Here, a recording medium that can be read by a computer, etc., is a recording medium that stores information such as data and programs through electrical, magnetic, optical, mechanical, or chemical processes, and is read by a computer, etc. This refers to a recording medium that can be read from a computer. Examples of such recording media that are removable from a computer include flexible disks, magneto-optical disks, CD-ROMs, CD-R / Ws, DVDs, Blu-ray discs, and memory cards such as flash memory. Furthermore, recording media fixed to a computer include hard disks and ROMs (read-only memory). In addition, SSDs (Solid State Drives) are... It can be used as a removable recording medium from computers, etc., or as a recording medium fixed to a computer, etc. [Explanation of Symbols]

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

Claims

1. A transmitting device that distributes certificate data regarding vehicle charging to the vehicle, An information system comprising an on-board device mounted on the vehicle and controlling the charging of the vehicle, When the transmitting device updates the certificate data stored in the in-vehicle device, it transmits to the in-vehicle device, at least a first hash value based on the certificate data before the update and the certificate data for the update, the certificate data before the update, and the certificate data for the update as update data. The in-vehicle device receives the update data from the sender device, calculates a second hash value based on the certificate data before the update and the certificate data for the update, and when the first hash value and the second hash value match, and the certificate data before the update included in the update data matches the certificate data before the update stored in the in-vehicle device, the in-vehicle device updates the certificate data before the update stored in the in-vehicle device with the certificate data for the update included in the update data. Information systems.

2. The sender device creates a pair of temporary private and temporary public keys, includes the temporary public key in the update data and transmits it to the in-vehicle device, creates a shared key to be shared with the in-vehicle device using the authentication public key corresponding to the authentication private key used by the in-vehicle device when creating a signature and the temporary private key, and calculates the first hash value using the created shared key. The in-vehicle device creates a shared key to be shared with the sender device using the temporary public key and the authentication secret key included in the update data, and calculates the second hash value using the created shared key, as described in claim 1. Information systems.

3. If an authentication certificate exists that authenticates the aforementioned certificate data, or if the authentication certificate is included as the lowest-level certificate in a hierarchical certificate group, and the certificate group exists that sequentially authenticates certificates below each certificate from the top-level starting certificate down to the authentication certificate, the sender device creates the signature of the temporary public key with the private key corresponding to either the authentication certificate or one of the certificates in the certificate group, includes it in the update data, and transmits it to the in-vehicle device. The in-vehicle device verifies the signature using the public key corresponding to the private key corresponding to any of the certificates in the authentication certificate or the certificate group, as described in claim 2. Information systems.

4. If no authentication certificate exists to authenticate the certificate data, the sender device delivers the temporary public key to the in-vehicle device via a communication path different from the communication path used to transmit the certificate data to the in-vehicle device, as described in claim 2. Information systems.

5. A transmitting device that distributes certificate data relating to vehicle charging to an on-board device installed in the vehicle and controlling the vehicle's charging, A transmitting device comprising a controller that, when updating the certificate data stored in the in-vehicle device, transmits to the in-vehicle device, at least a hash value based on the certificate data before the update and the certificate data for the update, and the certificate data before the update and the certificate data for the update as update data.

6. An on-board device mounted in a vehicle that controls the charging of the vehicle, From the sender's device, based on at least the certificate data before the update and the certificate data for the update. The system includes a controller that receives update data containing a first hash value, the certificate data before the update, and the certificate data for the update; calculates a second hash value based on the certificate data before the update and the certificate data for the update; and updates the certificate data before the update stored in the in-vehicle device with the certificate data for the update included in the update data when the first hash value and the second hash value match and the certificate data before the update included in the update data match the certificate data before the update stored in the in-vehicle device. In-vehicle device.

7. To the sender's device, A program for causing a vehicle to update certificate data stored in an on-board device installed in a vehicle that controls the charging of the vehicle, by transmitting at least a hash value based on the certificate data before the update and the certificate data for the update, the certificate data before the update and the certificate data for the update to the on-board device.

8. An on-board device installed in a vehicle that controls the charging of the vehicle, A program for receiving update data from a sender device, which includes a first hash value based on at least the pre-update certificate data and the update certificate data, the pre-update certificate data and the update certificate data, calculates a second hash value based on the pre-update certificate data and the update certificate data, and updates the pre-update certificate data stored in the in-vehicle device with the update certificate data included in the update data when the first hash value and the second hash value match and the pre-update certificate data included in the update data match the pre-update certificate data stored in the in-vehicle device.

Images