Charging control device and program

Abstract

To determine whether or not a certificate and a secret key are properly installed in a vehicle after installing the certificate used for authentication of the vehicle or a user of the vehicle and the secret key corresponding to the certificate.SOLUTION: When certificate data including a public key used in an authentication procedure by a charging facility and a secret key corresponding to the certificate data are installed during charging control, a charging control device for controlling charging between the charging facility and a vehicle performs confirmation processing for confirming that the certificate data and the secret key properly correspond to each other at a predetermined timing.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to a charging control device and a program. [Background technology]

[0002] Battery electric vehicles (BEVs) and plug-in hybrid vehicles (PHVs) are well known as vehicles (also called electric vehicles) that can be connected to an external power source to charge the driving battery. There are two main authentication methods for charging the driving battery: External Identification Means (EIM) and Plug & Play. Plug and Charge (PnC) has been proposed (see, for example, Patent Document 1 below). PnC is a procedure based on ISO15118, a standard for the communication interface between a power grid (also called a power grid or power system) and vehicles.

[0003] Regardless of the authentication method, the vehicle or charging equipment (Electric Vehicle Supply Equipment, When authentication of the EVSE is required, after the vehicle and EVSE connect, a certificate (e.g., a Vehicle certificate) is notified to the EVSE, and the EVSE's certificate (e.g., a SECC certificate) is notified to the vehicle. Then, each certificate is authenticated by the operator's certificate (e.g., a V2G ROOT certificate or an OEM ROOT certificate) stored on the peer (the vehicle for the EVSE, and the EVSE for the vehicle). This authentication procedure is called Transport Layer Security (TLS) client and server authentication.

[0004] Furthermore, with PnC, a Contract certificate is stored in the vehicle in advance, and user authentication is performed using an encryption key paired with the Contract certificate. In other words, when using PnC, the Contract certificate and the corresponding Contract private key must be installed in the EV. Also, according to the ISO15118 standard, in order to install the Contract certificate and private key, the OEMProvisioning certificate and the corresponding OEMProvisioning private key must be stored in the EV in advance. Also, ISO15118-20 requires that the Vehicle certificate and The corresponding Vehicle private key must be held in the EV. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2023-180314 Summary of the Invention [Problem to be solved by the invention]

[0006] However, when installing a pair of certificate and private key, there may be cases where saving of at least one of them fails due to factors such as a power outage. For example, if the certificate is successfully written but a power outage occurs while writing the private key, the private key fails to be written and reverts to the value before writing.

[0007] If such a case occurs, for example, the Contract certificate sent by the vehicle to the charging equipment will not match the Contract private key used to generate the signature, signature verification will fail, and charging using PnC will fail. In addition to power outages, for example, in cases where the Contract certificate chain and the Contract private key are stored in separate memory devices, an internal abnormality may occur in one of the memory devices, causing writing to only one of them to fail. An aspect of the disclosed embodiment is that after installing a certificate and a private key corresponding to the certificate used to authenticate the vehicle or the vehicle user, the vehicle will be notified as to whether the certificate and private key have been properly installed. The purpose is to be able to make judgments based on the results. [Means for solving the problem]

[0008] According to one aspect of the disclosed embodiment, there is provided a charging control device including a controller, which controls charging between a charging facility and a vehicle. When certificate data including a public key used in an authentication procedure by the charging facility and a private key corresponding to the certificate data are installed, the controller performs a verification process at a predetermined timing to verify that the certificate data and the private key properly correspond to each other. [Effects of the Invention]

[0009] As described above, when the charging control device installs certificate data including a public key used in an authentication procedure by the charging facility during charging control and a private key corresponding to the certificate data, the charging control device verifies that the certificate data and the private key properly correspond to each other at a predetermined timing. Here, the predetermined timing may be any timing from immediately after installation to before the authentication procedure by the charging facility is performed. The verification process may, for example, be performed by authenticating a signature created using the private key with the public key. Because the charging control device performs such a verification process, even if the installation of the certificate data and the private key corresponding to the certificate data appears to have been successful, the vehicle can more reliably determine whether the certificate and the private key have been properly installed. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram illustrating a vehicle equipped with a charge control device according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating an application (use case) of the charge control device of this embodiment. [Figure 3] FIG. 3 is a diagram illustrating modules included in the vehicle charging control device, the back-end server of the charging facility, the MO server, the OEM server, and the certificate pool, and data flows between the modules. [Figure 4] FIG. 4 is a diagram illustrating an example of the hardware configuration of a vehicle, a charging facility, and a back-end server. [Figure 5] FIG. 5 is a flowchart of the write verification process A. [Figure 6] FIG. 6 is a flowchart of the write verification process B. [Figure 7] FIG. 7 is a flowchart illustrating a protocol selection process performed by the protocol selection unit of the charge control device. [Figure 8] FIG. 8 is a flowchart illustrating a process of determining whether or not a contract certificate needs to be installed, which is performed by the installation necessity determining unit of the charging control device. [Figure 9] FIG. 9 is a flowchart illustrating a process of determining whether or not a contract certificate can be installed by the installation determination unit of the charging control device. [Figure 10] FIG. 10 is a flowchart illustrating a payment method selection process performed by the payment method selection unit of the charging control device. [Figure 11] FIG. 11 is a diagram illustrating the processing of the charge control device 10 according to the modified example. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, a charge control device 10 according to one embodiment and a computer program executed by the charge control device 10 (hereinafter simply referred to as a program) will be described with reference to FIGS.

[0012] <Embodiment> (Configuration) 1 is a diagram illustrating a vehicle 1 equipped with a charge control device 10 according to the present embodiment. In FIG. 1, there are a charging facility 2 that supplies power to a battery 19 (also referred to as a secondary battery or a storage battery in FIG. 4) of the vehicle 1, a back-end server 3 that supports processing of the charging facility 2, a mobility operator (MO) server 5 that exchanges information with the vehicle 1, an original equipment manufacturer (OEM) server 6, and a charging system. Also shown are a server 6, a certificate pool 7, and a commercial power grid provided by a power company or the like. The charging control device 10 is also called an Electric Vehicle Communication Controller (EVCC). The equipment control device 20 is also called a Supply Equipment Communication Controller (SECC).

[0013] Vehicle 1 is called an electric vehicle, and can charge a battery 19 for driving. Vehicle 1 has a charge control device 10, and executes a process of charging battery 19 from charging equipment 2. When the ISO15118-20 standard is applied, charge control device 10 of vehicle 1 executes a process of discharging power from battery 19 to a commercial power grid, a domestic load, or the like via charging equipment 2. In this embodiment, the charging process and discharging process are called a process of transferring power.

[0014] The charging facility 2 has an facility control device 20, and when connected to the charging control device 10 of the vehicle 1, communicates with the charging control device 10 in accordance with a procedure compliant with ISO15118. More specifically, the facility control device 20 establishes a TLS session with the vehicle 1 as necessary and supplies power to or receives power from the vehicle 1. After establishing the TLS session, the charging facility 2 executes authentication processing using PnC or EIM via V2G communication and performs payment processing after authentication. In this embodiment, "payment processing" includes two-way payments between a user and a business operator. The first is payment (billing) from the user's account or the like to the business operator's account for charging the battery 19 from the charging facility 2. The second is payment (settlement for selling electricity) from the business operator's account to the user's account for discharging from the battery 19 to the charging facility 2.

[0015] At least some of the functions of the facility control device 20 may be provided by a backend server 3. The backend server 3 establishes a TLS session with the vehicle 1, for example, via the charging facility 2. After the TLS session is established, the backend server 3 executes authentication processing by PnC or EIM through V2G communication, and performs payment processing after authentication. Furthermore, the backend server 3 communicates with the MO server 5, the certificate pool 7, etc. via the network N1, and acquires, for example, the SECC certificate of the charging facility 2, the Contract certificate of the vehicle 1, the business operator certificate, etc. The business operator certificate may be, for example, the Vehicle certificate ( It is used to authenticate contract certificates, etc. (when the ISO15118-20 standard is applied). Contract certificates and vehicle certificates are examples of certificate data.

[0016] Charging facility 2 is managed by a company called a CPO (Charge Point Operator) in addition to the MO. The charging equipment 2 may be installed in a parking lot where the vehicle 1 is parked, in a facility managed by a CPO, MO, OEM, or the like, or on the premises of a user's home. The charging equipment 2 is connected to, for example, a commercial power grid, a load in the home, or the like, and serves as an interface for sending and receiving power between the vehicle 1 and the power grid, and between the vehicle 1 and the load in the home, or the like.

[0017] The user of the vehicle 1 concludes a contract in advance with a service provider (such as an MO) in order to execute the process of transferring power via the charging facility 2. According to this contract, a contract certificate and an encryption key are issued from the MO server 5 and installed in the vehicle 1 via, for example, the OEM server 6. Note that certificate data such as the contract certificate may also be installed in the vehicle 1 via, for example, the charging facility 2.

[0018] The OEM server 6 can be said to be a computer of a business operator involved in the manufacture or sale of the vehicle 1. The certificate pool 7 is the main storage point for signed contract data that is accessible from the OEM server 6, the charging equipment 2, and the back-end server 3. In this embodiment, there are two main possibilities for providing signed contract data: via the charging equipment 2 and via the OEM server 6. After a successful TLS handshake between the vehicle 1 and the charging equipment 2, the vehicle 1 creates a signed CertificateInstallationReq (defined in ISO15118). This request is forwarded from the charging equipment 2 or the back-end server 3 to the certificate pool 7. This In response, the certificate pool 7 responds with available signed contract data as CertificateInstallationRes.

[0019] However, when the OEM server 6 is used, the certificate pool 7 automatically sends the signed contract data to the OEM server 6. In this case, even if the vehicle 1 does not send a CertificateInstallationReq, the certificate pool 7 automatically sends the signed contract data to the OEM server 6. Then, the OEM server 6 (or its back-end server) simply forwards the signed contract data to the vehicle 1.

[0020] As described above, in the charging control process, a TLS session is first established. For example, after the charging equipment 2 and the vehicle 1 are connected via the plug 2B, the SECC certificate of the charging equipment 2 is notified to the vehicle 1. The SECC certificate is then authenticated by the V2G ROOT certificate stored on the vehicle 1 side. In the procedure according to ISO15118-20, the Vehicle certificate of the vehicle 1 is then notified to the charging equipment 2. The Vehicle certificate is then authenticated by the V2G ROOT certificate or the OEM ROOT certificate stored on the charging equipment 2 side. However, the charging equipment 2 does not need to hold these certificates, and may obtain them from the backend server 3. Here, the SECC certificate includes a hierarchical certificate chain of the operator associated with the V2G ROOT certificate, and the Vehicle certificate includes the V2G ROOT certificate. It includes a ROOT certificate or a hierarchical certificate chain of an operator associated with an OEM ROOT certificate.

[0021] A certificate chain corresponds to a hierarchy of Certificate Authorities (CAs). A higher-level CA can have a lower-level CA called an intermediate CA (also called a sub-CA). The top-level CA is called a ROOT CA and issues V2G ROOT certificates and OEM ROOT certificates for each domain. The CA certificates (sub-certificates) of the lower-level intermediate CAs are signed by the higher-level CA.

[0022] Vehicle 1 authenticates the certificate chain from top to bottom based on the V2G ROOT certificate, and is ultimately able to authenticate the EVSE Leaf certificate (SECC certificate). If vehicle 1 successfully authenticates the SECC certificate, it can obtain a shared key to use for communication with charging equipment 2, and subsequent communications are encrypted using the shared key. This establishes a TLS session.

[0023] After the TLS session is established, V2G communication is performed. In V2G communication, a request from the vehicle 1 and a response from the charging equipment 2 are transmitted to each other, and charging or, in the case of a procedure according to ISO15118-20, discharging is performed. In this V2G communication, external authentication is performed using, for example, PnC or an RFID card.

[0024] As the PnC, which is the first authentication procedure after the establishment of a TLS session, the charging control device 10 of the vehicle 1 creates a signature using a private key, and transfers the signature and a contract certificate including the public key to the charging facility 2, and the charging facility 2 authenticates the signature using the public key. If the authentication is successful, the vehicle 1 executes a power transfer process with the charging facility 2 according to the PnC procedure.

[0025] In addition to the PnC procedure described above, the process of transferring power between the vehicle 1 and the charging facility 2 also allows for a second authentication procedure, that is, an external authentication method (EIM) procedure in which an RFID card or the like is presented. For this reason, the charging facility 2 has an EIM reader 2A. The external authentication method is an authentication method using user information acquired from a credit card, a QR code (registered trademark), RFID (Radio Frequency Identification), or the like via the EIM reader 2A. The external authentication method also includes a method in which authentication is performed from a mobile app or the like without using the EIM reader 2A.

[0026] The charging control device 10 (or the back-end server 3) can be connected to the MO server 5, the OEM server 6, and the like via a network N1. The network N1 is, for example, a Long Term Evolution (LTE) or a 5th Generation Mobile Communication System (5G) , a wireless network such as a 6th Generation Mobile Communication System (6G), and a wired public network such as the Internet. Network N1 may also include a wireless network or a private network, for example, a wireless local area network (LAN).

[0027] For example, the charging facility 2 may transfer the signature sent from the vehicle 1 to the MO server 5 and request user authentication of the vehicle 1. Then, when the user authentication by the MO server 5 is successful, the charging facility 2 may execute a process of sending and receiving power between the charging facility 2 and the battery 19 of the vehicle 1, and may execute a payment process (billing or settlement) between the charging facility 2 and the user of the vehicle 1.

[0028] Furthermore, when executing the power transfer process, the vehicle 1 can also request the charging facility 2 to install a contract certificate or the like. In this case, the vehicle 1 can request the charging facility 2 to install a certificate (such as an OEM Provisioning certificate) issued by the OEM, which is the manufacturer and distributor of the vehicle 1. The OEM Provisioning certificate is an example of certificate data. A valid Contract Certificate, etc. associated with the OEM Provisioning Certificate, etc. notified by 1 If the charging facility 2 has the encryption key, it can provide the Contract certificate etc. to the vehicle 1. In addition, the charging facility 2 can access the MO server 5 or the certificate pool 7 to obtain the OEM Provisioning certificate. A corresponding valid Contract certificate and encryption key may be acquired and installed in the vehicle 1. Note that instead of the charging facility 2, or in cooperation with the charging facility 2, the back-end server 3 may authenticate the signature sent from the vehicle 1 and install the valid Contract certificate and the like in the vehicle 1.

[0029] FIG. 2 is a diagram illustrating an application (use case) of the charging control device 10 of this embodiment. As described above, when installing a Contract certificate in the vehicle 1, for example, a message called CertificateInstallationRes is transmitted from the equipment control device 20 (or the backend server 3) of the charging facility 2 to the vehicle 1 (S501). CertificateInstallationRes is called contract data and includes a signature by a certification authority, a Contract certificate chain, and an encrypted Contract private key. Also, as described above, the Contract certificate in the Contract certificate chain includes a Contract public key. Also, the OEM server 6, rather than the charging facility 2, may transmit CertificateInstallationRes to the vehicle 1.

[0030] When the charging control device 10 of the vehicle 1 receives CertificateInstallationRes, it verifies the signature included in CertificateInstallationRes using the certificate public key of the certification authority that can be verified using the V2G ROOT certificate stored in the nonvolatile memory (S502). If the signature verification is successful (OK in S503), the charging control device 10 writes the Contract certificate chain included in CertificateInstallationRes to the nonvolatile memory (S504).

[0031] Next, the charging control device 10 decrypts the encrypted Contract private key included in CertificateInstallationRes (S505). Then, the charging control device 10 writes the Contract private key to the nonvolatile memory (S506). In this way, the Contract certificate chain and the corresponding paired Contract private key are written to the nonvolatile memory of the charging control device 10, and are used in subsequent charging. In this embodiment, the "pair" refers to a Contract certificate chain including a Contract public key and a Contract private key that properly correspond to each other. Also, the "pair" refers to a signature created with the Contract private key that is successfully verified by the Contract public key. Note that if the signature verification fails (NG in S503), the charging control device 10 If so, some kind of error handling should be performed (S507).

[0032] However, during the write process in S504 or S506, a memory error such as a power outage to the charging control device 10 may occur. For example, if a power outage or other error occurs while writing the Contract private key to the non-volatile memory, the Contract certificate chain is updated, but the Contract private key is not updated, and the old one remains. In this case, the Contract certificate chain and the Contract private key do not form a properly corresponding pair.

[0033] FIG. 2 illustrates an example in which the vehicle 1 executes PnC with the charging facility 2 in this state. That is, the charging control device 10 generates a signature using the Contract private key and passes it to the charging facility 2 together with the Contract certificate chain. Then, the equipment control device 20 of the charging facility 2 verifies the signature using the Contract public key included in the Contract certificate chain received from the charging control device 10. However, the Contract public key included in the Contract certificate chain and the Contract private key used by the charging control device 10 for the signature are not a corresponding pair. As a result, the equipment control device 20 fails to verify the signature, the PnC session is stopped, and charging becomes impossible.

[0034] In addition to power outages, there may be cases where the contract certificate chain and the contract private key are stored in separate memory devices. In such cases, an internal error may occur in one of the memories, causing a write failure in only one of them.

[0035] FIG. 3 is a diagram illustrating modules and data flows between modules included in the charging control device 10 of the vehicle 1, the equipment control device 20 of the charging equipment 2, the OEM server 6, and the certificate pool 7, all of which comply with ISO 15118. In each module of the charging control device 10 and the equipment control device 20 in FIG. 3, the CPUs 11 and 21 illustrated in FIG. 4 execute processing according to computer programs executablely loaded in the memories 12 and 22, respectively. The OEM server 6 and the certificate pool 7 have the same hardware configuration as the charging control device 10 or the equipment control device 20, and execute processing according to computer programs. Note that at least some of the components of the equipment control device 20 may be provided in the backend server 3. Therefore, in FIG. 3, the reference numeral 3 is enclosed in parentheses along with the reference numeral 20.

[0036] <Installing the certificate and corresponding private key> For example, before the vehicle 1 and the charging facility 2 are connected, the OEM communication control unit 113 of the vehicle 1 communicates with the OEM communication control unit 613 of the OEM server 6 to acquire a certificate. More specifically, the OEM communication control unit 113 notifies the certificate acquisition unit 602 via the OEM communication control unit 613 of a request to acquire a certificate for acquiring an OEM Provisioning certificate, a Vehicle certificate, a Contract certificate, etc. (M30, M31).

[0037] Of the certificates, keys, etc., the Vehicle certificate and its corresponding paired Vehicle private key, and the OEMProvisioning certificate and its corresponding OEMProvisioning private key may be issued by the certificate issuing unit 601 of the OEM server 6. In this case, these certificates and private keys are delivered by the certificate acquiring unit 602 to the OEM communication control unit 113 via the OEM communication control unit 613 (M32, M35, M36). The Vehicle private key paired with the Vehicle certificate and the OEMProvisioning private key corresponding to the OEMProvisioning certificate may be generated inside the charging control device 10 before each certificate is issued. In this case, only each certificate is delivered by the certificate acquiring unit 602 to the OEM communication control unit 113 via the OEM communication control unit 613 (M32, M35, M36). The Vehicle certificate is issued by the OEM or The le issued to the charging control device 10 (EVCC) by a V2G certification authority (sub-CA, etc.) It is an af certificate.

[0038] Furthermore, the Contract certificate is stored in the certificate storage unit 712 in the certificate pool 7. The Contract certificate is issued by the mobility service provider to the user of the vehicle 1. The certificate acquisition unit 602 then notifies the certificate storage unit 712 of the certificate pool 7 of a Contract certificate request (M33), and acquires the Contract certificate and the encrypted Contract private key (M34). In this way, the certificate acquisition unit 602 passes the Contract certificate and the encrypted Contract private key to the OEM communication control unit 113 via the OEM communication control unit 613 (M35, M36).

[0039] The OEM communication control unit 113 stores the acquired Vehicle certificate, OEM Provisioning certificate, and Contract certificate in the certificate storage unit 112 (M1). The OEM communication control unit 113 also stores the Vehicle private key, OEM Provisioning private key, and the decrypted Contract private key in the key storage unit 111 (M1).

[0040] When the plug 2B of the charging facility 2 is connected to a connection part including a terminal of the power receiving part of the power circuit and the charging communication part 16B (see FIG. 4) in the vehicle 1 that charges the battery 19 (see FIG. 4), the charging control device 10 and the equipment control device 20 (or the backend server 3) communicate with each other. That is, the charging control device 10 and the equipment control device 20 (or the backend server 3) perform TLS authentication and V2G communication. First, the charging control device 10 notifies the equipment control device 20 (or the backend server 3) of a Client Hello message, for example, and the equipment control device 20 (or the backend server 3) notifies the charging control device 10 of a Server Hello message. In the following embodiment, the processing is described as being executed between the charging control device 10 and the equipment control device 20. However, at least a part of the processing of the equipment control device 20 may be executed in the backend server 3.

[0041] Here, for example, in a procedure according to ISO15118-20, the charging control device 10 notifies the equipment control device 20 of the vehicle certificate. As described above, the vehicle certificate is stored, for example, in the certificate storage unit 112. The charging control device 10 reads the vehicle certificate from the certificate storage unit 112 and notifies the equipment control device 20 of the vehicle certificate.

[0042] The facility control device 20 uses the vehicle certificate to authenticate the charging control device 10 in TLS communication. The vehicle certificate is used in the same V2G session by the equipment control device 20. It may also be used to bind different TLS sessions belonging to the same vehicle. However, vehicle certificates are not used in procedures specified in standards prior to ISO 15118-20.

[0043] Meanwhile, the equipment control device 20 transmits an SECC certificate to the charging control device 10 in the procedures of both ISO15118-20 and standards earlier than ISO15118-20. The SECC certificate is a certificate issued so that the charging control device 10 can verify the authenticity of the equipment control device 20 (SECC) or the backend server 3. In this embodiment, the SECC certificate is issued to the charging equipment 2, the equipment control device 20, or the backend server 3 by either the V2G root CA or a sub-CA.

[0044] The charging control device 10 and the equipment control device 20 communicate with each other to complete a TLS handshake and start a TLS session. Here, for example, the charging control device 10 authenticates the charging facility 2 or the equipment control device 20 (and the backend server 3) using the SECC certificate received from the equipment control device 20.

[0045] Certification of vehicle certificate for charging facility 2 (in the case of ISO15118-20) If the authentication of the SECC certificate in vehicle 1 is successful, the V2G communication control unit 104, 04 negotiates the V2G communication protocol and authentication method. The V2G communication protocol (ISO15118-2) is negotiated. 0, ISO15118-2, etc.) is determined, and the payment is The authentication method (PnC, EIM, etc.) is determined.

[0046] Furthermore, the V2G communication control unit 104 reads out the Contract certificate from the certificate storage unit 112 (M16) via the certificate selection unit 105 (M7). Furthermore, the V2G communication control unit 104 acquires a signature created with the Contract private key corresponding to the Contract certificate from the key storage unit 111 (M16) via the certificate selection unit 105 (M15). Then, the V2G communication control unit 104 transmits the acquired signature and Contract certificate to the V2G communication control unit 204. The V2G communication control unit 204 authenticates the Contract certificate by verifying the signature using the public key included in the Contract certificate received from the V2G communication control unit 104. Thereafter, the equipment control device 20 charges the battery 19 of the vehicle 1.

[0047] However, if the charging control device 10 does not store a valid Contract certificate in the certificate storage unit 112, the charging control device 10 executes a process for acquiring a valid Contract certificate when connecting to the charging facility 2. That is, the V2G communication control unit 104 of the charging control device 10 transmits a Contract certificate request together with an OEM Provisioning certificate issued by the manufacturer and distributor of the vehicle 1 to the facility control device 2. 0 to the V2G communication control unit 204 (M11).

[0048] The equipment control device 20 receives the OEM Provisioning certificate associated with the OEM Provisioning certificate notified from the vehicle 1. If a valid Contract certificate is available, the Contract certificate can be provided to the vehicle 1. However, if the equipment control device 20 or a business's computer that can be referenced by the equipment control device 20 does not hold a valid Contract certificate associated with the OEM Provisioning certificate, In this case, a valid Contract certificate is acquired from the certificate pool 7. For example, the V2G communication control unit 204 acquires the Contract certificate together with the OEM Provisioning certificate via the certificate acquisition unit 212. The certificate request is sent to the certificate storage unit 712 of the certificate pool 7 (M21, M37).

[0049] When the certificate storage unit 712 receives the Contract certificate request, it stores the OEM Provisioning certificate. The V2G communication control unit 204 notifies the certificate acquisition unit 212 of the associated valid Contract certificate and the encrypted Contract private key (M38). Then, the V2G communication control unit 204 transmits the Contract certificate and the encrypted Contract private key acquired via the certificate acquisition unit 212 to the V2G communication control unit 104 (M22, M12). The V2G communication control unit 104 stores the acquired Contract certificate in the certificate storage unit 112 (M2). Furthermore, the V2G communication control unit 104 decrypts the encrypted Contract private key and stores it in the key storage unit 111. In this way, the charging control device 10 can acquire a valid contract certificate from the charging facility 2.

[0050] <Pair verification> In this embodiment, the charging control device 10 verifies whether each certificate and private key stored in association with each other in the certificate storage unit 112 and the key storage unit 111 are properly corresponding pairs. First, the charging control device 10 determines whether writing to the certificate storage unit 112 and the key storage unit 111 has been performed normally. For example, the V2G communication control unit 104 and the OEM communication control unit 113 may determine whether writing has failed (whether the writing is normal) when writing each certificate and private key to the certificate storage unit 112 and the key storage unit 111, which have nonvolatile memories, respectively.

[0051] Furthermore, in this embodiment, the pair verification unit 103 reads out each certificate and private key stored in association with each other in the certificate storage unit 112 and the key storage unit 111 (M3, M4). Then, the pair verification unit 103 creates a signature using the read private key and verifies the signature using the public key included in the read certificate. If the signature verification is successful, the pair verification unit 103 can determine that the certificate and private key are a pair that properly correspond to each other. In this embodiment, The control device 10 can perform the verification at the following two timings.

[0052] <<Verification when writing certificates and private keys>> The V2G communication control unit 104 or the OEM communication control unit 113 determines whether or not a write failure of at least one of the certificate and the private key is detected in the nonvolatile memory when writing the certificate and the private key. If a write failure is detected in the nonvolatile memory, the V2G communication control unit 104 or the OEM communication control unit 113 may, for example, recover both the certificate and the private key to the certificate and private key before they were written. In this embodiment, certificates and private keys spanning multiple generations, both old and new, are stored in the certificate storage unit 112 and the key storage unit 111 in association with each other.

[0053] Furthermore, at the end of the writing process, the pair verification unit 103 generates a signature using the private key after writing and verifies the signature using the public key included in the certificate after writing, and verifies that they are a pair (M3, M4). If this signature verification fails, the pair verification unit 103 may determine that writing of either the certificate or the private key has failed, as in the determination made at the time of writing described above. In other words, the pair verification unit 103 may recover both the certificate and the private key to the state they were in at the time of the previous installation, or may discard the new pair.

[0054] In this case, at the start of the next charging session, the charging control device 10 may perform charging by PnC using the private key pair corresponding to the recovered previous certificate. However, the recovered previous certificate may be invalid. A certificate may be invalid if the certificate format is incorrect, if the certificate has expired, or if the signature attached to the certificate is incorrect. Even if the certificate is invalid, if another valid certificate and private key pair exists, the charging control device 10 may switch to the other pair and perform authentication and charging by PnC. However, if the certificate is invalid and another valid certificate and private key pair does not exist, the charging control device 10 may perform charging by EIM.

[0055] <<Verification at the start of a charging session>> The verification of the certificate and the private key when they are written may not be performed immediately in the event of a power outage, etc. However, the charge control device 10 can verify the certificate and the private key at a time after they are written.

[0056] For example, when a connection between the vehicle 1 and the charging facility 2 is detected, the charging control device 10 can verify the certificate and the private key before the start of a charging session. That is, the charging control device 10 generates a signature using the private key that was written last and verifies the signature using the public key included in the certificate that was written last before the start of a charging session, and verifies that the certificate and the private key are a properly corresponding pair.

[0057] If the signature verification fails when the vehicle 1 is connected to the charging facility 2, the charging control device 10 determines that writing of either the certificate or the private key has failed. In this case, the charging control device 10 can either recover both the certificate and the private key to the pair that was previously installed, or discard the pair that was last written.

[0058] When the charging control device 10 recovers to the previous pair, it may perform charging by PnC using the recovered previous certificate and private key. However, if the previous certificate and private key are invalid but another valid certificate and private key exist, the charging control device 10 may switch to the other pair and perform authentication and charging by PnC. Furthermore, if the certificate is invalid and another valid certificate and private key pair does not exist, the charging control device 10 may perform charging by EIM.

[0059] Note that if the verification of the OEM Provisioning certificate and the corresponding private key, and the Vehicle certificate and the corresponding private key fails and authentication by PnC is possible even if they do not exist, the charging control device 10 may perform authentication and charging by PnC. In other words, if a pair of a Contract certificate and the corresponding private key exists, the charging control device 10 may perform authentication and charging by PnC.

[0060] In addition, the charging control device 10 first generates a pair of a private key and a public key inside the charging control device 10, and sends a Certificate Signing Request (CSR) to the OEM server 6, the charging equipment 2, the back Even in a case where a CSR is sent to the end server 3 or the like to request creation of a certificate, pair verification is possible. That is, the charging control device 10 may similarly verify the pair for the certificate received from the OEM server 6 or the like after sending the CSR.

[0061] <Installation necessity determination and other processes> The pair verification unit 103 notifies the verification result to the certificate selection unit 105, the payment method selection unit 106, the installation necessity determination unit 107, the installation permission determination unit 108, and the protocol selection unit 109 (M5, M6).

[0062] The certificate selection unit 105 passes the certificate that has been successfully verified by the pair verification unit 103 and the signature created with the private key in the key storage unit 111 to the V2G communication control unit 104 (M16). Then, the V2G communication control unit 104 executes charging by PnC as described above. The installation necessity determination unit 107 receives the result of verification of the pair of certificate and private key from the pair verification unit 103, determines whether or not installation of the pair of certificate and private key is required, and notifies the payment method selection unit 106 (M8). The processing of the installation necessity determination unit 107 will be described separately with reference to FIG. 8.

[0063] The installation possibility determination unit 108 receives the result of verification of the pair of certificate and private key from the pair verification unit 103, determines whether or not the pair of certificate and private key can be installed, and notifies the payment method selection unit 106 (M9). The processing of the installation possibility determination unit 108 will be described separately with reference to FIG. 9.

[0064] The protocol selection unit 109 receives EVSE standard compliance information from the V2G communication control unit 204 via the V2G communication control unit 104 (M17). The EVSE standard compliance information is information indicating whether or not the equipment control device 20 of the charging equipment 2 (EVSE) is compatible with PnC. The protocol selection unit 109 determines whether or not the equipment control device 20 is compatible with PnC from the EVSE standard compliance information. If the equipment control device 20 is compatible with PnC, the protocol selection unit 109 selects PnC. If the equipment control device 20 is not compatible with PnC, the protocol selection unit 109 selects EIM (see FIG. 10).

[0065] Furthermore, the protocol selection unit 109 receives the verification result of the pair of the Vehicle certificate and the Vehicle private key from the pair verification unit 103 and determines whether or not authentication according to ISO15118-20 is possible. That is, if the pair verification unit 103 fails to verify the Vehicle certificate and the Vehicle private key, the protocol selection unit 109 determines that authentication according to ISO15118-20 is not possible. In this case, the protocol selection unit 109 selects a protocol earlier than ISO15118-20, for example, the ISO15118-2 protocol.

[0066] On the other hand, if the pair verification unit 103 successfully verifies the Vehicle certificate and the Vehicle private key, the protocol selection unit 109 selects the ISO15118-20 protocol. The protocol selection unit 109 notifies the V2G communication control unit 104 of the selected protocol (M10). The V2G communication control unit 104 performs PnC authentication or EIM processing in accordance with the notified protocol.

[0067] The payment method selection unit 106 receives notifications from the installation necessity determination unit 107 and the installation feasibility determination unit 108 and determines the payment method (authentication method). The payment method is either authentication and payment by PnC or authentication and payment by EIM. The payment method selection unit 106 notifies the V2G communication control unit 104 of the determined payment method. The V2G communication control unit 104 executes charging in accordance with the notified payment method. The processing of the payment method selection unit 106 will be described separately with reference to FIG. 10.

[0068] 4 is a diagram illustrating an example of the hardware configuration of a vehicle 1, a charging facility 2, and a back-end server 3. A charging system is made up of a charging control device 10 of the vehicle 1, a charging facility 2 that charges a battery 19 mounted on the vehicle 1, and the back-end server 3. The vehicle 1 has the charging control device 10 and a battery 19 whose charging and discharging are controlled by the charging control device 10.

[0069] The charge control device 10 has a CPU 11, a memory 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 storage unit 13, a display unit 14, an operation unit 15, an external communication unit 16A, and a charge communication unit 16B. The CPU 11 and the memory 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.

[0070] The CPU 11 executes a computer program deployed in an executable manner in the memory 12, and provides the functions of the charging control device 10. The CPU 11 is also called a processor. The CPU 11 is not limited to a single processor. The CPU 11 may be a plurality of processors of the same type operating in parallel. The CPU 11 may also include one or more dedicated processors suitable for calculations according to the processing target, such as a GPU (Graphics Processing Unit) or a DSP (Digital Signal Processor). The CPU 11 may also execute processing in cooperation with other processors of the same type, GPUs, DSPs, etc.

[0071] The memory 12 stores computer programs executed by the CPU 11, data processed by the CPU 11, etc. The memory 12 is a dynamic random access memory (DRAM), a static random access memory (SRAM), a read only memory (ROM), etc. ROM is an example of a non-volatile memory. The external storage unit 13 is used, for example, as a storage area that supplements the memory 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. The external storage unit 13 can also be said to be an example of a non-volatile memory. do.

[0072] 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.

[0073] 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 LAN (Local Area Network). The external communication unit 16A is called a TCU (Telematics Control Unit), and is used to communicate with the network N1. It may also be a device that performs communication called telematics via the Internet.

[0074] 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 charging communication unit 16B may communicate with the charging facility 2 using the external communication unit 16A or the charging communication unit 16B, and may execute communication using a communication procedure based on the external communication unit 16A or the charging communication unit 16B. In this embodiment, the charging control device 10 communicates with the charging facility 2 using the external communication unit 16A or the charging communication unit 16B, and executes a request for charging, a payment (authentication) process for charging, a request for discharging, a payment (authentication) process for discharging, etc.

[0075] The charging equipment 2 has a CPU 21, a memory 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 storage unit 23, 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 charging control device 10 of the vehicle 1, and therefore a description thereof will be omitted. The CPU 21, the memory 22, the external storage unit 23, and the external communication unit 26A correspond to the equipment control device 20 in FIG. 1.

[0076] The EIM reader 2A is a card reader that reads information from an IC card such as a credit card by contact or contactless means, an image reader that reads a QR code (registered trademark), an RFID reader, or the like.

[0077] As described above, the charging control device 10 and the equipment control device 20 communicate with each other when the plug 2B of the power supply circuit 29 is connected to a connection portion including the terminals of the power receiving unit and the charging communication unit 16B of the power circuit in the vehicle 1 that charges the battery 19. The charging control device 10 and the equipment control device 20 communicate with each other, for example, via the charging communication units 16B and 26B, and perform PnC using TLS authentication and V2G communication. That is, the charging control device 10 and the equipment control device 20 authenticate each other using TLS authentication and V2G communication. The charging control device 10 and the equipment control device 20 then charge the battery 19 of the vehicle 1, perform authentication processing and payment for the charging (charging billing), discharge from the battery 19 via the charging equipment 2, and perform authentication processing and payment for the discharge (setting aside for selling electricity). However, the charging control device 10 and the equipment control device 20 may also communicate with each other via the external communication units 16A and 26A when the plug 2B of the power supply circuit 29 is connected to the power circuit that charges the battery 19.

[0078] The power supply circuit 29 is connected to a commercial power grid and charges and discharges the battery 19. For example, the power supply circuit 29 converts AC power to DC power and charges the battery 19. However, if the vehicle 1 has a rectifier circuit, a DC-AC converter, or the like, the power supply circuit 29 may supply AC power to the vehicle 1. Furthermore, for example, the power supply circuit 29 converts DC power from the battery 19 to AC power and transmits it to the power grid. However, if the vehicle 1 has a DC-AC conversion circuit, or the like, the power supply circuit 29 may receive AC power from the vehicle 1 and transmit it to the power grid.

[0079] The back-end server 3 has a CPU 31, a memory 32, 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 storage unit 33, a display unit 34, an operation unit 35, and an external communication unit 36A. The CPU 31, the memory 32, the external storage unit 33, the display unit 34, the operation unit 35, and the external communication unit 36A are similar to the CPU 11, the memory 12, the external storage unit 13, the display unit 14, the operation unit 15, and the external communication unit 16A. The external communication unit 36A of the back-end server 3 communicates with the external communication unit 26A of the charging facility 2 via the network N2. The vehicle server 3 cooperates with the charging facility 2 to manage charging of the battery 19 of the vehicle 1 from the power grid and, according to the ISO15118-20 procedure, discharging of the battery 19 to the power grid. The network N2 is, for example, a LAN. The network N2 can be connected to the network N1 in FIG. 1 via, for example, a communication device called a gateway.

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

[0081] (Processing Procedure) 5 to 10 are flowcharts illustrating the processing of the charging control device 10. FIG. 5 is a flowchart of the write verification processing A. The charging control device 10 executes the write verification processing A when it writes a certificate to the certificate storage unit 112 and writes a private key pair corresponding to the certificate to the key storage unit 111. There are no limitations on the certificate and private key that are the processing targets of the write verification processing A. The processing targets include, for example, a Vehicle certificate and the corresponding Vehicle private key, an OEMProvisioning certificate and the corresponding OEMProvisioning private key, a Contract certificate and the corresponding Contract private key, etc.

[0082] Note that the certificate storage unit 112 and the key storage unit 111 each have a nonvolatile memory. Therefore, in Fig. 5, it is assumed that a writing error occurs in the nonvolatile memory. Furthermore, the certificate storage unit 112 and the key storage unit 111 may store data in a common nonvolatile memory, or may store data in different nonvolatile memories. Such a nonvolatile memory configuration is also applicable to the processes in Fig. 6 and subsequent figures.

[0083] First, the charge control device 10 determines whether an error has been detected in the nonvolatile memory in which the certificate and private key have been written (S51). If the charge control device 10 does not detect an error during writing to the nonvolatile memory, it reads the latest private key from the nonvolatile memory of the key storage unit 111 and generates a signature (S52). There are no limitations on the data that is encrypted with the private key when creating the signature.

[0084] Next, the charging control device 10 reads the certificate of the pair corresponding to the latest private key from the nonvolatile memory of the certificate storage unit 112, and verifies the signature created in S52 using the public key included in the certificate (S53).The charging control device 10 then determines the result of the signature verification (S54).

[0085] If the signature verification is successful, the charging control device 10 determines that writing of the certificate to the certificate storage unit 112 and writing of the private key to the key storage unit 111 have been completed successfully, and notifies the relevant units (S55). The relevant units include, for example, the certificate selection unit 105, the installation necessity determination unit 107, the installation feasibility determination unit 108, and the protocol selection unit 109 shown in FIG. 3 . On the other hand, if the determination in S54 indicates that the signature verification has failed, the charging control device 10 executes error processing and processing for restoring the certificate and private key to their previous values ​​(S56). That is, the charging control device 10 sets the previously installed certificate and private key as the latest certificate data and private key, instead of the certificate and private key whose signature verification has failed. Here, the previous installation refers to the time of installation before the certificate and private key whose signature verification has failed were installed. Note that if the signature verification has failed, the charging control device 10 may delete the certificate data and private key whose signature verification has failed.

[0086] 6 is a flowchart of the write verification process B. When the plug 2B of the charging facility 2 is connected to the connection part of the vehicle 1, the charging control device 10 executes the write verification process B before executing authentication by PnC or EIM. There are no limitations on the certificates and private keys that are processed in the write verification process B. The processing targets include, for example, a Vehicle certificate and its corresponding Vehicle private key, an OEMProvisioning certificate and its corresponding OEMProvisioning private key, a Contract certificate and its corresponding Contract private key, etc.

[0087] In this process, the charging control device 10 reads the latest Contract private key from the nonvolatile memory of the key storage unit 111 and generates a signature (S62). Next, the charging control device 10 reads the Contract certificate corresponding to the Contract private key used in S62 from the nonvolatile memory of the certificate storage unit 112. Then, the charging control device 10 verifies the signature created in S62 using the public key included in the Contract certificate (S63). Then, the charging control device 10 determines the result of signature verification (S64). If the signature verification is successful, the charging control device 10 ends the process.

[0088] On the other hand, if the determination in S64 indicates that the signature verification has failed, the charging control device 10 executes error processing and processing for restoring the certificate and private key to their previous values ​​(S66). That is, the charging control device 10 sets the previously installed certificate and private key as the latest certificate data and private key in place of the certificate and private key for which the signature verification has failed.

[0089] FIG. 7 is a flowchart illustrating a protocol selection process by the protocol selection unit 109 of the charging control device 10. The protocol selection process is a process for selecting either the ISO15118-20 protocol or a protocol earlier than ISO15118-20. Hereinafter, there are one or more Vehicle certificates and one or more Vehicle private keys, and the Vehicle certificate [i ] (array element number i is an integer equal to or greater than 0). Also, the Vehicle private key is stored in the Vehicle private key[i] array.

[0090] In this process, the charging control device 10 initializes the array element number i to, for example, an initial value of 0 (S71). Next, the charging control device 10 determines whether or not there is an update history of at least one of the Vehicle certificate [i] and the Vehicle private key [i] (S72). If there is at least one of the update history of the document [i] or the update history of the vehicle private key [i] Then, the charging control device 10 proceeds to step S73. That is, the charging control device 10 determines whether the pair verification is successful in the write verification process A (FIG. 5) or the write verification process B (FIG. 6) by the pair verification unit 103 (S73).

[0091] If it is determined in S73 that the pair verification has failed, the charging control device 10 [i] and the previous value before Vehicle private key [i] is written are stored in non-volatile memory. The charging control device 10 determines whether the previous Vehicle certificate[i] and Vehicle private key[i] are stored in the non-volatile memory (S74). If it is determined in S74 that the previous Vehicle certificate[i] and Vehicle private key[i] are stored in the non-volatile memory, the charging control device 10 proceeds to S75. That is, the charging control device 10 executes recovery processing using the previous Vehicle certificate[i] and Vehicle private key[i]. In the recovery processing, the charging control device 10 rewrites the current (latest) Vehicle certificate[i] and Vehicle private key[i] with the previous Vehicle certificate[i] and Vehicle private key[i], and sets a pair (S75). Thereafter, the charging control device 10 proceeds to S76.

[0092] If the determination in S72 is NO, i.e., if there is no update history of either the Vehicle certificate[i] or the Vehicle private key[i], the charging control device 10 also proceeds to S76. Also, if the determination in S73 is YES, i.e., if the pair verification of the Vehicle certificate[i] and the Vehicle private key[i] is successful, the charging control device 10 also proceeds to S76.

[0093] Then, the charging control device 10 verifies the validity of the vehicle certificate [i] (S76). If the vehicle certificate [i] is valid, the charging control device 10 includes ISO15118-20 in the provision protocol (S77). On the other hand, if the vehicle certificate [i] is invalid, the charging control device 10 The electric control device 10 advances the process to S78 and determines whether there is another Vehicle certificate ( S78).

[0094] Furthermore, if it is determined in S74 that the previous Vehicle certificate[i] and Vehicle private key[i] are not stored in the non-volatile memory, the charging control device 10 also proceeds to S78 and determines whether or not there are other Vehicle certificates (S78). If there are other Vehicle certificates, the charging control device 10 increments the array element number i by 1 (S79) and stores the next Vehicle certificate[i]. and Vehicle private key [i], the processes from S72 onwards are executed.

[0095] If there is no other vehicle certificate as determined by S78, the charging control device 10 In this manner, the charging control device 10 notifies the V2G communication control unit 104 whether authentication based on ISO15118-20 is possible or not, and ends the processing. The V2G communication control unit 104 executes processing based on PnC within the range of protocols that can be used.

[0096] 8 is a flowchart illustrating the process of determining whether or not a Contract certificate needs to be installed by the installation necessity determining unit 107 of the charging control device 10. Hereinafter, it is assumed that there are one or more Contract certificates and one or more Contract private keys, and that these are stored in an array of Contract certificates[i] (array element number i is an integer equal to or greater than 0). It is also assumed that the Contract private key is stored in an array of Contract private keys[i].

[0097] In this process, the charging control device 10 initializes the array element number i to, for example, an initial value of 0 (S81). Next, the charging control device 10 determines whether or not there is an update history of at least one of the Contract certificate [i] and the Contract private key [i] (S82). If there is an update history of at least one of the Contract certificate [i] and the Contract private key [i], the charging control device 10 proceeds to S83. That is, the charging control device 10 determines whether or not the pair verification is successful in the write verification process A (FIG. 5) or the write verification process B (FIG. 6) by the pair verification unit 103 (S83).

[0098] If it is determined in S83 that the pair verification has failed, the charging control device 10 determines whether the previous Contract certificate[i] and Contract private key[i] before they were written are stored in the non-volatile memory (S84). If it is determined in S84 that the previous Contract certificate[i] and Contract private key[i] are stored in the non-volatile memory, the charging control device 10 proceeds to S85. Then, the charging control device 10 executes recovery processing using the previous Contract certificate[i] and Contract private key[i]. That is, the charging control device 10 rewrites the current (latest) Contract certificate[i] and Contract private key[i] with the previous Contract certificate[i] and Contract private key[i], and sets the pair (S85). Thereafter, the charging control device 10 proceeds to S86.

[0099] If the determination in S82 is NO, i.e., if there is no update history of either the Contract certificate[i] or the Contract private key[i], the charging control device 10 also proceeds to the process in S86. Also, if the determination in S83 is YES, i.e., if the pair verification of the Contract certificate[i] and the Contract private key[i] is successful, the charging control device 10 also proceeds to the process in S86.

[0100] Then, the charging control device 10 verifies the validity of the Contract certificate [i] (S86). If the Contract certificate [i] is valid, the charging control device 10 sets the Contract certificate installation necessity flag to "No" (S87). On the other hand, if the Contract certificate [i] is invalid, In this case, the charging control device 10 advances the process to S88 and determines whether there is another Contract (S88).

[0101] Furthermore, if it is determined in S84 that the previous Contract certificate[i] and Contract private key[i] are not stored in the non-volatile memory, the charging control device 10 also proceeds to the process in S88 and determines whether or not there are other Contract certificates (S88). If there are other Contract certificates, the charging control device 10 increments the array element number i by 1 (S89) and executes the process from S82 onwards for the next Contract certificate[i] and Contract private key[i].

[0102] If it is determined in S88 that there is no other Contract certificate, the charging control device 10 sets the flag indicating whether or not a Contract certificate needs to be installed to "needed" (S8A). In this manner, the charging control device 10 notifies the V2G communication control unit 104 of the determination result regarding whether or not installation is needed, and ends the process.

[0103] 9 is a flowchart illustrating a Contract certificate installation availability determination process performed by the installation availability determination unit 108 of the charging control device 10. In the Contract certificate installation availability determination process, the processing target is the OEMProvisioning certificate. Hereinafter, it is assumed that there are one or more OEMProvisioning certificates and one or more OEMProvisioning private keys, and that these are stored in an array of OEMProv.Certificate[i] (array element number i is an integer equal to or greater than 0). It is also assumed that the OEMProv.PrivateKey[i] is stored in an array of OEMProv.PrivateKey[i]. In FIG. 9, the OEMProvisioning certificate is abbreviated to OEMProv.Certificate.

[0104] In this process, the charge control device 10 initializes the array element number i to, for example, an initial value of 0 (S91). Next, the charge control device 10 checks the update history of the OEMProv. certificate [i] or the OEM MProv. Determine whether or not there is at least one update history for the private key [i] (S92). If there is at least one of the update history of the EMProv. certificate and the update history of the OEMProv. private key [i], the charging control device 10 proceeds to step S93. That is, the charging control device 10 determines whether the pair verification is successful in the write verification process A (FIG. 5) or the write verification process B (FIG. 6) by the pair verification unit 103 (S93).

[0105] If it is determined in S93 that the pair verification has failed, the charge control device 10 The previous certificate[i] and OEMProv. Private Key[i] before being written are stored in non-volatile memory. If it is determined in S94 that the previous OEMProv. certificate is stored in the nonvolatile memory, the charging control device 10 proceeds to S95. Then, the charging control device 10 executes the recovery process using the previous OEMProv. certificate[i] and OEMProv. private key[i]. That is, the charging control device 10 executes the recovery process using the current (latest) OEMProv. certificate[i] and OEMProv. private key[i]. Certificate[i] and OEMProv. Private Key[i] are used to create the previous OEMProv. Certificate[i] and OEMProv. The secret key [i] is rewritten and set as a pair (S95). After that, the charging control device 10 advances the process to S96.

[0106] If the result of S92 is NO, that is, if the update history of the OEMProv. certificate [i] If neither the update history of the OEMProv. private key[i] nor the update history of the OEMProv. private key[i] is available, the charging control device 10 Proceed to S96. Also, if the answer to S93 is YES, that is, if the OEMProv. certificate [i] is Even if the pair verification is successful for the OEMProv. private key [i], the charging control device 10 Then, proceed to S96.

[0107] Then, the charging control device 10 verifies the validity of the OEMProv. certificate [i] (S96 If the OEMProv. certificate [i] is valid, the charging control device 10 The installation flag is set to "Yes" (S97). Meanwhile, OEMProv. Certificate [i] is invalid, the charging control device 10 proceeds to step S98 and checks whether the OEMProv. certificate is invalid. It is determined whether or not there is a

[0108] Furthermore, if it is determined in S94 that the previous OEMProv. certificate[i] and OEMProv. private key[i] are not stored in the non-volatile memory, the charging control device 10 also proceeds to S98 and determines whether or not there are other OEMProv. certificates (S98). If there are other OEMProv. certificates, the charging control device 10 increments the array element number i by 1 (S99) and executes the processes from S92 onwards for the next OEMProv. certificate[i] and OEMProv. private key[i].

[0109] If it is determined in step S98 that there is no other OEMProv. certificate, the charging control device 10 The flag indicating whether or not the certificate can be installed is set to "No" (S9A). In this manner, the charging control device 10 notifies the V2G communication control unit 104 of the determination result as to whether or not the Contract certificate can be installed, and ends the processing. If the installation of the Contract certificate is necessary and installation is possible, the V2G communication control unit 104 may install the Contract certificate.

[0110] 10 is a flowchart illustrating a payment method selection process performed by the payment method selection unit 106 of the charging control device 10. When the charging control device 10 confirms that it is connected to the charging facility 2 (S101), it determines whether the Contract certificate installation necessity flag is set to "necessary" (S102).

[0111] If the Contract certificate installation necessity flag is "yes," the charging control device 10 determines whether the Contract certificate installation possibility flag is "yes" (S103). If the determination in S103 shows that the Contract certificate installation possibility flag is "no," that is, if installation is both "yes" and "no," the charging control device 10 proceeds to S106 and sets the payment method in EIM (S106).

[0112] On the other hand, if the determination in S102 is that installation is not required or the determination in S103 is that installation is possible, the charging control device 10 determines whether the equipment control device 20 supports PnC from the EVSE standard information (see FIG. 3 ) received from the V2G communication control unit 204 via the V2G communication control unit 104 (S104). If the equipment control device 20 supports PnC, the charging control device 10 sets the payment method to PnC (S105). Also, if the equipment control device 20 does not support PnC, the charging control device 10 proceeds to the process in S106 and sets the payment method to EIM (S106). The payment method selection unit 106 of the charging control device 10 notifies the V2G communication control unit 104 of the payment method determined by the above process. The V2G communication control unit 104 performs authentication and charging according to the notified payment method.

[0113] (Effects of the embodiment) As described above, the charging control device 10 executes a confirmation process when certificate data including a public key used in an authentication procedure by the charging facility 2 during charging control and a private key corresponding to the certificate data are installed. That is, the charging control device 10 executes a confirmation process at a predetermined timing to confirm that the certificate data and the private key properly correspond to each other. Therefore, after installing the certificate data and the private key corresponding to the certificate data used to authenticate the vehicle 1 or the user of the vehicle 1, the charging control device 10 can determine in the vehicle 1 whether the certificate data and the private key have been properly installed.

[0114] In the verification process, the charging control device 10 generates a signature using the installed private key and verifies the generated signature using the public key included in the certificate data. Therefore, the charging control device 10 can accurately perform the verification process by actually using the installed private key and certificate data.

[0115] The charge control device 10 executes the confirmation process immediately after installing the certificate data and the private key at a predetermined timing, and can determine in the vehicle 1 whether the certificate data and the private key have been properly installed.

[0116] The charging control device 10 performs a confirmation process before an authentication process when connecting to the charging facility 2 after installing the certificate data and the private key at a predetermined timing, thereby preventing omission of confirmation.

[0117] If the charging control device 10 determines as a result of the confirmation process that the certificate data and the private key do not properly correspond, it deletes the confirmed certificate data and private key, thereby preventing errors from occurring during the authentication process with the charging equipment 2.

[0118] If the confirmation process determines that the certificate data and the private key do not properly correspond to each other, the charging control device 10 can take the next best measure. That is, the charging control device 10 can execute a recovery process to set the latest certificate data and private key to the certificate data and private key that were installed before the confirmed certificate data and private key.

[0119] When the latest certificate data set as a result of the recovery process is invalid certificate data, the charge control device 10 performs charge control according to an external authentication method without using the certificate data, so that at least charging of the battery 19 of the vehicle 1 can be performed.

[0120] (Variation) In the above embodiment, the pair verification unit 103 of the charging control device 10 generates a signature using the installed private key as verification processing, and verifies the generated signature using the public key included in the certificate data (FIGS. 5 and 6). However, the verification processing method of the pair verification unit 103 is not limited to this signature verification.

[0121] FIG. 11 is a diagram illustrating processing of the charging control device 10 according to a modified example. As in this example, in the charging control device 10, for example, a key agreement algorithm may be executed between the pair verification unit 103 and the certificate storage unit 112 and key storage unit 111, and it may be confirmed whether the encryption and decryption processes are successful using the derived key. The charging control device 10 can also execute pair verification using this method. Here, it is assumed that the charging control device 10 recognizes a key agreement algorithm for generating a common key from the public key and private key to be verified. The key agreement algorithm may be, for example, an elliptic curve Diffie-Hellman key agreement algorithm. The Diffie-Hellman key exchange (ECDH) protocol is used. The pair verification unit 103, the certificate storage unit 112, and the key storage unit 111 share elliptic curve parameters. However, the key agreement algorithm is not limited to the ECDH protocol.

[0122] In this process, for example, the pair verification unit 103 reads the public key to be verified from the certificate storage unit 112 (S110). Next, the pair verification unit 103 generates a temporary private key and a temporary public key (S111). Furthermore, the pair verification unit 103 generates a common key using the public key to be verified and the created temporary private key using a recognized key agreement algorithm (S112).

[0123] Next, the pair verification unit 103 encrypts the verification data with the generated common key (S113). Then, the pair verification unit 103 passes the encrypted verification data to the key storage unit 111 and requests decryption (S114). At this time, the pair verification unit 103 also passes the generated temporary public key to the key storage unit 111 (S115).

[0124] The key storage unit 111 stores the temporary public key and the private key to be verified, which are delivered from the pair verification unit 103. A common key is generated using a recognized key agreement algorithm (S116). If the key agreement algorithm of the pair of private key and public key to be verified matches that of the pair of temporary private key and temporary public key, and if the pair of private key and public key to be verified is a valid pair, the common keys generated in S112 and S116 will match.

[0125] Next, the key storage unit 111 decrypts the verification data encrypted with the generated common key (S117). Then, the key storage unit 111 passes the decrypted verification data to the pair verification unit 103 and requests comparison and confirmation. The pair verification unit 103 compares the decrypted verification data with the verification data it holds and confirms it.

[0126] If the verification data decrypted by key storage unit 111 matches the verification data held in pair verification unit 103, pair verification unit 103 can verify that the pair of the private key and public key to be verified is a valid pair. Note that instead of pair verification unit 103, key storage unit 111 may compare the decrypted verification data with the verification data held in pair verification unit 103.

[0127] (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.

[0128] 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]

[0129] 1 vehicle 2 Charging equipment 3 Backend Server 5 MO Server 6 OEM Servers 7 Certificate Pool 10. Charging control device 11, 21, 31 CPUs 12, 22, 32 memory 13, 23, 33 External memory unit 14, 34 Display section 15, 35 Operation section 16A, 26A, 36A External communication section 16B, 26B Charging communication section 19 Battery 20 Equipment control device 29 Power supply circuit 2A EIM Reader 2B plug

Claims

1. A charging control device that controls charging between a charging facility and a vehicle, and a controller that, when certificate data including a public key used in an authentication procedure by the charging facility during charging control and a private key corresponding to the certificate data are installed, performs a confirmation process at a predetermined timing to confirm that the certificate data and the private key properly correspond to each other. Charging control device.

2. 2. The method according to claim 1, wherein the controller generates a signature using the installed private key in the verification process and verifies the signature using the public key included in the certificate data. Charging control device.

3. 2. The method according to claim 1, wherein the predetermined timing is immediately after the installation of the certificate data and the private key. Charging control device.

4. 2. The method according to claim 1, wherein the controller executes the confirmation process at the predetermined timing when the controller connects to the charging facility after the certificate data and the private key are installed. Charging control device.

5. 2. The method according to claim 1, wherein the controller deletes the confirmed certificate data and the confirmed private key when the confirmation process determines that the certificate data and the private key do not properly correspond to each other. Charging control device.

6. If the controller determines as a result of the verification process that the certificate data and the private key do not properly correspond to each other, it executes a recovery process to set the certificate data and the private key that were installed before the verified certificate data and the private key as the latest certificate data and the private key instead of the verified certificate data and the private key. The method according to claim 1 Charging control device.

7. When the latest certificate data set as a result of the recovery process is invalid certificate data, the controller performs the charging control according to an external authentication method without using the certificate data. The method according to claim 6 Charging control device.

8. On the computer, A program for performing a confirmation process at a predetermined timing to confirm that the certificate data and the private key properly correspond to each other when certificate data including a public key used in authentication procedures by charging equipment during charging control and a private key corresponding to the certificate data are installed.

Images