Charging control device and program

Abstract

To prevent charging using an authentication system of a PnC by unauthorized use of an information processing device in which a certificate and key information are stored.SOLUTION: The controller receives identification information of a user and stores first data based on the identification information together with contract information related to charging of the vehicle. When the vehicle is connected to the charging facility, the controller receives the identification information of the user again, and when second data based on the identification information received again matches the stored first data, the controller creates a signature for charging the vehicle from the charging facility.SELECTED DRAWING: Figure 6

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. PnC is a system that connects the grid This procedure complies with ISO15118, a standard for the communication interface between vehicles and the power grid (also called the power grid or power system).

[0003] When charging using the PnC authentication method, certificates and key information are installed in the vehicle in advance, and the user connects a plug between the vehicle and the charging equipment, allowing the user to approve the charge and charge the vehicle (see, for example, Patent Document 1 below). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Special Publication No. 2023-514170 Summary of the Invention [Problem to be solved by the invention]

[0005] However, it is conceivable that the certificate and key information are stored and that the charging control device installed in the vehicle is stolen and installed in another vehicle. It is also conceivable that the charging control device installed in the vehicle is stolen along with the vehicle. In such a case, there is a concern that the certificate and key information may be fraudulently used to perform fraudulent charging.

[0006] An aspect of the disclosed embodiment is to prevent charging using the PnC authentication method through unauthorized use of a charging control device in which certificates and key information are stored. [Means for solving the problem]

[0007] One aspect of the disclosed embodiment is exemplified by a charging control device including a controller. The controller accepts identification information of a user and stores first data based on the identification information together with contract information regarding charging of the vehicle. When the vehicle is connected to the charging facility, the controller accepts the user's identification information again, and if second data based on the reaccepted identification information matches the stored first data, creates a signature for charging the vehicle from the charging facility based on the contract information. [Effects of the Invention]

[0008] Therefore, even if a charging control device in which the certificate and key information are stored and which is mounted on a vehicle is stolen by an attacker and installed in another vehicle, or even if the entire charging control device is stolen, the attacker cannot input the user's identification information into the controller or cause the controller to create second data that matches the first data. In other words, even if the controller receives the attacker's identification information during fraudulent use, it can determine that the second data based on the attacker's identification information does not match the stored first data. Therefore, the controller does not create a signature for charging from the charging facility to the vehicle based on the attacker's identification information. Therefore, the charging control device This can prevent an attacker other than a legitimate user from illegally using a charging control device in which certificates and key information are stored to charge using the PnC authentication method. [Brief explanation of the drawings]

[0009] [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 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 3] FIG. 3 is a diagram illustrating an example of the hardware configuration of a vehicle, a charging facility, and a back-end server. [Figure 4] FIG. 4 is a diagram illustrating an example of a data flow when registering an authentication policy. [Figure 5] FIG. 5 is a diagram illustrating an example of a data flow when registering an authentication policy. [Figure 6] FIG. 6 is a diagram illustrating the data flow between the MCU and the TPM when the vehicle is connected to a charging facility. [Figure 7] FIG. 7 is a sequence diagram illustrating an example of a registration process of an authentication policy. [Figure 8] FIG. 8 is a sequence diagram illustrating an example of a registration process of an authentication policy. [Figure 9] FIG. 9 is a sequence diagram illustrating a process for determining whether or not a signature can be executed based on an authentication policy. [Figure 10] FIG. 10 is a sequence diagram illustrating a process for determining whether or not a signature can be executed based on an authentication policy. [Figure 11] FIG. 11 is a diagram illustrating an example of a data flow between an MCU in which multiple pieces of user identification information are registered and a TPM in the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] First Embodiment Hereinafter, a charge control device 10 according to a first 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.

[0011] (Charging system configuration) FIG. 1 is a diagram illustrating a vehicle 1 equipped with a charging control device 10 according to this embodiment. Also shown in FIG. 1 are a charging facility 2 that supplies power to a battery 19 (also referred to as a secondary battery or storage battery in FIG. 3 ) 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, a certificate pool 7, and a commercial power grid provided by a power company or the like. The charging control device 10 is also referred to as an electric vehicle communication controller (EVCC). The equipment control device 20 is also referred to as a supply equipment communication controller (SECC). In this embodiment, the charging facility 2, the back-end server 3, the MO server 5, the OEM server 6, the certificate pool 7, and a commercial power grid provided by a power company or the like are called a charging system. The charging control device 10, the charging facility 2, the back-end server 3, the MO server 5, the OEM server 6, the certificate pool 7, and the like can be connected via a network N1. The network N1 is, for example, a Long Term Evolution (LTE), a 5th Generation Mobile Communication System (5G), a 6th Generation Mobile Communication System (6G), or the like. G) and wired public networks such as the Internet.

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

[0013] 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 Transport Layer Security (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 also performs authentication processing using PnC or EIM via V2G communication, and performs payment processing after authentication.

[0014] 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 establishing the TLS session, the backend server 3 performs authentication processing using PnC or EIM via V2G communication, and performs payment processing after authentication. Furthermore, the backend server 3 communicates with the MO server 5, OEM server 6, certificate pool 7, etc. via the network N1, and obtains, for example, a contract certificate for the vehicle 1.

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

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

[0017] The OEM server 6 can be considered 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 the signed contract data to the vehicle 1: via the charging equipment 2 or 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. In response, the certificate pool 7 replies with available signed contract data as CertificateInstallationRes. In this embodiment, the signed contract data is also referred to as Certificate Installation data. The signed contract data or Certificate Installation data can also be considered an example of contract information.

[0018] However, when the OEM server 6 is used, the certificate pool 7 automatically transmits the signed contract data to the OEM server 6. In this case, even if the vehicle 1 does not transmit a CertificateInstallationReq, the certificate pool 7 automatically transmits the signed contract data to the OEM server 6. Then, the OEM server 6 simply forwards the signed contract data to the vehicle 1.

[0019] (Processing overview) ((Assumptions for charging vehicle 1 using the charging system)) In this charging system, the charging control device 10 has an MCU 10A including a CPU 11 and a memory 12, and a Trusted Platform Module (TPM) 18 connected to and cooperating with the MCU 10A. (See Figure 3.) The MCU 10A then stores the Contract private key used for authentication in a security module such as the TPM 18. A signature is generated using the intract private key, and the signature is verified by the charging facility 2, backend server 3, MO server 5, etc. If this verification is successful, it is considered that the user authentication has been successful.

[0020] Here, a security module such as the TPM 18 that cooperates with the MCU 10A performs the signature generation operation. This is performed when a host microcomputer such as the CPU 11 in the MCU 10A executes a signature generation command for the security module. The security module may be built into the MCU 10A or may be externally attached to the MCU 10A. The following description will be given taking the TPM 18 as an example of a security module.

[0021] In this embodiment, the MCU 10A executes a policy command required for authentication, and after obtaining execution authority based on the authentication policy, executes a signature generation command. The TPM 18 determines whether its own pre-stored authentication value (the authentication policy value) matches the authentication value (the authentication policy value) obtained from the authentication policy command executed by the MCU 10A. If the two match, the MCU 10A can execute the signature generation command. However, with this method, if the entire vehicle 1 is stolen, it becomes difficult to prevent unauthorized use of the MCU 10A, TPM 18, etc.

[0022] ((Outline of Processing by the Charging Control Device 10)) The user registers his / her own user identification information in advance in the MCU 10A when purchasing the vehicle 1, etc. The user identification information may be, for example, a password, fingerprint authentication, or face authentication, or may be smart key information. The MCU 10A stores this user identification information for each user in the non-volatile memory 12A. Then, when the MCU 10A receives a Contract certificate issued based on a contract between the user and the MO, etc., it calculates the authentication policy value (AuthPolicy value). The authentication policy value (AuthPolicy value) is calculated using the PolicyRef parameter of the policy command. The AuthPolicy value is calculated using the user identification information. Then, the MCU 10A stores the AuthPolicy value together with the contract data such as the Contract private key in the TPM 18. At this time, the TPM 18 returns the Contract identification information for identifying the contract data to the MCU 10A. The MCU 10A associates the Contract identification information returned from the TPM 18 with the value of PolicyRef (user identification information) and The data is stored in the nonvolatile memory 12A (see FIG. 4).

[0023] Then, when the vehicle 1 is connected to the charging facility 2, the MCU 10A accepts the input of the user identification information again. This is the same as the method used at the time of registration. The MCU 10A sets the user identification information in the PolicyRef parameter of the policy command and executes it. Meanwhile, the MCU 10A The MCU 10A verifies that the input user identification information matches the user identification information stored in the non-volatile memory 12A. Then, the MCU 10A sets the Contract identification information associated with the user identification information stored in the non-volatile memory 12A that matches the input user identification information in the signature generation command, and causes the TPM 18 to execute the command. In this embodiment, the TPM 18 determines whether the authentication policy value (AuthPolicy value) calculated when executing the process based on the signature generation command matches the authentication policy value (AuthPolicy value) stored for each contract data. If the two do not match, the TPM 18 does not execute the signature generation operation. Therefore, even in cases where the entire vehicle 1 is stolen, an attacker cannot pass the authentication.

[0024] (Detailed configuration of the charging system) FIG. 2 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 (SECC in FIG. 2) of the charging equipment 2, the MO server 5, the OEM server 6, and the certificate pool 7, all of which comply with ISO15118. In each module of the charging control device 10 and the equipment control device 20 in FIG. 2, the CPU 11 and the CPU 21 illustrated in FIG. 3 execute the executable programs stored in the memory 12 and the memory 22, respectively. The MO server 5, the OEM server 6, and the certificate pool 7 each have the same hardware configuration as the charging control device 10 or the equipment control device 20, and each executes processing according to a computer program. 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. 2, the reference numeral 3 is enclosed in parentheses along with the reference numeral 20.

[0025] ((Issuing OEM Provisioning Certificate to MO Server 5)) Before receiving the issuance of the Contract certificate, the user first requests the OEM server 6 to notify the certificate pool 7 of the OEM Provisioning certificate. At this time, the user: User identification information (UID) is input to the user identification information input unit 110 of the charge control device 10. The user identification information (UID) input to the user identification information input unit 110 is used as a PolicyRef. The user identification information (UID) is set to a variable called "user ID" and input to the AuthPolicy calculation unit 111 (M1). There is no limitation on the user identification information (UID). The user identification information (UID) may be, for example, fingerprint information captured from a user's finger, face authentication information captured from a user's face, a password, or identification information of the smart key of the vehicle 1.

[0026] The AuthPolicy calculation unit 111 calculates a DIGEST value using a hash function from information in a policy command for calculating an authentication policy value (AuthPolicy). Then, the AuthPolicy calculation unit 111 notifies the OEM communication control unit 113 of the calculated DIGEST value. The AuthPolicy calculation unit 111 may include the DIGEST value in a certificate request (Certificate Signing Request; CSR) and notify the OEM communication control unit 113. The AuthPolicy calculation unit 111 generates the authentication policy value (AuthPolicy) using a hash function based on the calculated DIGEST value and user identification information (UID).

[0027] AuthPolicy is data for authenticating that the executor of the signature generation command, i.e., the MCU 10A of the vehicle 1, is legitimate when charging the battery 19 of the vehicle 1 is authenticated by PnC. The role of AuthPolicy will be described in detail later with reference to Figs. 4 to 6.

[0028] The OEM communication control unit 113 issues an OEM Provisioning certificate including the above DIGEST value, and The OEM server 6 requests the OEM communication control unit 613 of the OEM server 6 to notify the certificate pool 7 of the DIGEST value (M30). The OEM communication control unit 613 then notifies the certificate issuing unit 601 of the DIGEST value and requests the certificate issuing unit 601 to issue an OEM Provisioning certificate and notify the certificate pool 7 (M31). M32). The certificate issuing unit 601 issues the OEM Provisioning certificate containing the DIGEST value to the certificate pool. 2 and subsequent figures, the OEMProvisioning certificate is abbreviated as OEMProv. certificate. Instead of including a DIGEST value in the OEMProvisioning certificate, an AuthPolicy value may be included.

[0029] The certificate pool 7 functions as an interface between the MO server 5, the OEM server 6, and the charging equipment 2 (backend server 3). The certificate pool 7 notifies the certificate acquisition unit 51 of the MO server 5 of the OEMProvisioning certificate including the DIGEST value (M51).

[0030] The certificate acquisition unit 51 of the MO server 5 acquires the DIGEST value from the OEMProvisioning certificate and inputs it to the AuthPolicy calculation unit 52 (M53). Note that if the OEMProvisioning certificate includes AuthPolicy instead of DIGEST, the certificate acquisition unit 51 may acquire the value of AuthPolicy and input it to the AuthPolicy calculation unit 52.

[0031] ((Issuance of Contract certificate and corresponding private key, storage in certificate pool 7)) For example, the user inputs user identification information (UID) to the user identification information input unit 50 of the MO server 5 via the network N1 using the charge control device 10 or another user device. (M52). The user identification information input unit 50 sets the user identification information (UID) in the variable PolicyRef and notifies the AuthPolicy calculation unit 52 (M54). As a result, the MO server 5 is now in a state where a Contract certificate can be issued.

[0032] The AuthPolicy calculation unit 52 generates an AuthPolicy based on the user identification information (UID) and the DIGEST value, and notifies the CertificateInstallation data generation unit 54 (M55). Note that if the AuthPolicy value is directly acquired from the OEMProvisioning certificate by the certificate acquisition unit 51, the AuthPolicy calculation unit 52 notifies the CertificateInstallation data generation unit 54 of the acquired value. The CertificateInstallation data generation unit 54 generates CertificateInstallation data and stores it in the certificate storage unit 712 of the certificate pool 7 (M56). The CertificateInstallation data includes a Contract certificate including a Contract public key and an encrypted Contract secret. The AuthPolicy entered at this time is used as one of the inputs when calculating the encryption key used to encrypt the Contract private key (processing by the common key generation unit 503 in FIG. 4).

[0033] ((Installing the Contract Certificate and the corresponding Private Key)) There are several methods for installing the CertificateInstallation data stored in the certificate storage unit 712 into the charging control device 10 of the vehicle 1. The first method is a method of installing the device 20 into the charge control device 10. The user connects the vehicle 1 to the charging facility 2 and connects the charging control device 10 and the facility control device 20 so that they can communicate with each other.

[0034] Then, the user installs the CertificateInstallation data in the charge control device 10. Then, the V2G communication control unit 104 of the charging control device 10 notifies the V2G communication control unit 204 of the equipment control device 20 of a request to install the CertificateInstallation data. (M60) When a request to install CertificateInstallation data is received, V2 The V2G communication control unit 204 acquires CertificateInstallation data from the certificate storage unit 712 of the certificate pool 7 via the certificate acquisition unit 212 (M61, M62). The control unit 204 transmits the acquired Certificate Installation data to the charging control device 10 via V2G communication. The communication control unit 104 is notified (M63).

[0035] The V2G communication control unit 104 stores the notified CertificateInstallation data in the TPM controller. The command execution unit 112 requests the installation of the CertificateInstallation data. The TPM command execution unit 112 executes the installation of the CertificateInstallation data (M76). When installation is requested, the CertificateInstallation data is passed to the TPM18, The TPM18 requests the installation to be performed. The TPM18 executes the CertificateInstallation The TPM 18 decrypts the encrypted Contract private key in the data. Then, the TPM 18 stores the decrypted Contract private key in the private key storage unit 181. At this time, the TPM 18 also stores the Contract certificate including the Contract public key in the CertificateInstallation data and the AuthPolicy plan. The AuthPolicy generated by the calculation unit 111 is also stored in the TPM 18 in association with the Contract private key.

[0036] The second method is to install the CertificateInstallation data in the charging control device 10 from the OEM server 6. In the second method, the user connects the charging control device 10 of the vehicle 1 to the OEM server 6 via the network N1. Then, the user requests the charging control device 10 to install the CertificateInstallation data. Then, the OEM communication control unit of the charging control device 10 113 notifies the OEM communication control unit 613 of the OEM server 6 of a Contract certificate installation request ("certificate request" in FIG. 2) (M70).

[0037] Then, the OEM communication control unit 613 receives the certificate via the certificate acquisition unit 602 (M71). Obtain CertificateInstallation data from the certificate storage unit 712 of pool 7 (M72 , M73). The OEM communication control unit 613 transmits the acquired Certificate Installation data to the OEM. The OEM communication control unit 113 is notified (M74). Even if the certificate request is not received in M70, the OEM server 6 may use the CertificateInstallation data acquired at any time. may be notified to the OEM communication control unit 113.

[0038] The OEM communication control unit 113 transmits the notified CertificateInstallation data to the TPM controller. The OEM communication control unit 113 then passes the notified CertificateInstallation data to the command execution unit 112 and requests installation. The TPM command execution unit 112 may then pass the command to the TPM command execution unit 112 (M75, M76). The subsequent processing by the TPM command execution unit 112 is the same as in the first method.

[0039] The third method is a method in which the charging control device 10 installs Certificate Installation data from the certificate pool 7 or the MO server 5 via the network N1, for example. In the third method, the user connects the charging control device 10 of the vehicle 1 to the certificate pool 7 or the MO server 5 via the network N1. Then, the user requests the charging control device 10 to acquire CertificateInstallation data. The same procedures as those in Methods 1 and 2 are executed between the certificate pool 7 or the MO server 5 to obtain the CertificateInstallation data and pass it to the TPM 18 .

[0040] ((Signature Generation)) When the CertificateInstallation data is installed, the charging control device 10 can generate a signature using the Contract private key. The apparatus 10 again acquires the user identification information (UID) from the user identification information input unit 110. Then, the TPM command execution unit 112 inputs the user identification information (UID) along with a signature request to the TPM 18. The AuthPolicy calculation unit 182 of the TPM 18 generates an AuthPolicy based on the user identification information (UID) input from the TPM command execution unit 112, and inputs the generated AuthPolicy to the AuthPolicy verification unit 183 (M83). The AuthPolicy verification unit 183 compares the AuthPolicy value calculated by the AuthPolicy calculation unit 182 with the AuthPolicy value stored in association with the Contract private key. Then, if the two AuthPolicy values ​​match, the AuthPolicy verification unit 183 instructs the signature generation unit 184 to grant signature permission (M84). Upon receiving the signature permission, the signature generation unit 184 generates a signature using the Contract private key stored in association with the AuthPolicy. The signature is notified (M87) to the V2G communication control unit 204 of the equipment control device 20 (backend server 3) of the charging equipment 2 via the TPM command execution unit 112 and the V2G communication control unit 104 (M85, M86). The V2G communication control unit 204 passes the notified signature to the signature verification unit 205 (M88), causing signature verification to be performed.

[0041] (Hardware configuration) 3 is a diagram illustrating an example of the hardware configuration of the vehicle 1, the charging facility 2, and the back-end server 3. The vehicle 1 has a charging control device 10 and a battery 19 whose charging and discharging are controlled by the charging control device 10.

[0042] The charge control device 10 has a CPU 11, a memory 12, a TPM 18, 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.

[0043] The CPU 11 executes a computer program that is executable and deployed 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 implemented by a plurality of processors of the same type. The CPU 11 may operate in parallel. The CPU 11 may 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, such as a GPU or a DSP.

[0044] The memory 12 stores computer programs executed by the CPU 11, data processed by the CPU 11, etc. The memory 12 may be a dynamic random access memory (DRAM), a static random access memory (SRAM), a read only memory (ROM), a flash memory, etc. Electrically Erasable and Programmable Read Only Memory (EEPROM) In this embodiment, the memory 12 includes a nonvolatile memory 12A such as a flash memory or an EEPROM.

[0045] 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 storage unit 13 can also be considered a non-volatile memory.

[0046] The CPU 11 and memory 12 constitute an Electronic Control Unit (hereinafter referred to as MCU 10A). The MCU 10A is connected to the TPM 18 via a communication interface such as a Controller Area Network (CAN), a Serial Peripheral Interface (SPI), or an Inter Integrated Circuit (I2C). The MCU 10A is an example of a first processing unit.

[0047] The TPM 18 is a device that executes security-related processes. The TPM 18 has an internal processor similar to the CPU 11 and a storage device similar to the memory 12, and executes processes such as data encryption / decryption, key pair generation, hash value calculation, and digital signature generation / verification. The TPM 18 is an example of a second processing unit. Therefore, the MCU 10A and the TPM 18 are examples of a controller.

[0048] 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 UIF that can be used by the user.

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

[0050] 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 internally include a CPU, a memory, an input / output interface, a communication interface, etc. In this embodiment, the charging control device 10 includes the external communication unit 16A. Alternatively, the charge communication unit 16B communicates with the charging facility 2 to request charging, process payment (authentication) for charging, request discharge, process payment (authentication) for discharging, and the like.

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

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

[0053] 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 a power receiving portion of a power circuit in the vehicle 1 that charges the battery 19 and a terminal of the charging communication unit 16B. The charging control device 10 and the equipment control device 20 communicate with each other, for example, using the charging communication units 16B and 26B, and execute 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 and execute authentication processing and payment for the charging (billing for charging).

[0054] Furthermore, when the charging control device 10 and the facility control device 20 comply with the ISO15118-20 standard, they perform discharge from the battery 19 via the charging facility 2, authentication processing for the discharge, and payment (settlement for selling electricity). The power supply circuit 29 is connected to a commercial power system (grid) and charges and discharges the battery 19.

[0055] 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 using 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, memory 32, external storage unit 33, display unit 34, operation unit 35, and external communication unit 36A are similar to the CPU 11, memory 12, external storage unit 13, display unit 14, operation unit 15, and 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. In cooperation with the charging facility 2, the back-end server 3 manages charging of the vehicle 1's battery 19 from the power grid and discharging of the battery 19 to the power grid according to the ISO 15118-20 procedure. The network N2 is, for example, a LAN. The network N2 can be connected to the network N1 in FIG. 1 via a communication device called a gateway, for example.

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

[0057] (Authentication policy registration) 4 and 5 are diagrams illustrating an example of a data flow when registering an authentication policy. 4 is a diagram illustrating an example of a data flow between the MCU 10A of the charging control device 10 and the MO server 5 when registering an authentication policy. Note that FIG. 4 also illustrates the TPM 18. As described above, the authentication policy is registered, for example, when the user purchases the vehicle 1.

[0058] When registering an authentication policy, the MCU 10 creates an import command and notifies the TPM 18 of the import command, thereby setting the parameters included in the import command in the TPM 18. The import command includes the Contract public domain P1, AuthPolicy, Contract public key KP1, and encrypted Contract private key PS1. Note that the import command does not need to include all parameters in a single command; multiple commands may be used.

[0059] The Contract public area P1 is set with the same content as the Contract public area P2 of the MO server 5. That is, the data in the Contract public area P1 that differs for each user are the AuthPolicy and the Contract public key. Therefore, the MCU 10A simply sets the AuthPolicy and the Contract public key to match the data in the Contract public area P2 of the MO server 5. In this way, the Contract public area P1 is generated to match the Contract public area P2. The MCU 10A also receives the Contract certificate from the MO server 5 via the network N1, either directly or via the charging equipment 2, and acquires the Contract public key KP1 included in the certificate. When the MCU 10A inputs an import command to the TPM 18, the TPM 18 uses the data in the Contract public area P1 and a private key (called a Storage private key) held by the TPM 18 to create a common key that is the same as that of the MO server 5 using a Key Derivation Function (KDF function). .

[0060] The AuthPolicy is data used to authenticate the authenticity of the MCU 10A and TPM 18 of the vehicle 1 when the battery 19 of the vehicle 1 is charged by PnC, and is called an authentication policy value. As described above, when a user concludes a PnC contract, the charging control device 10 (MCU 10A) receives input of user identification information (UID) and calculates the AuthPolicy value. Then, the MCU 10A stores the Contract private key and AuthPolicy as a set in the TPM 18 using an import command.

[0061] When the charging facility 2 and the vehicle 1 are connected, that is, when the user charges the vehicle 1 using PnC, the user inputs the user identification information (UID) to the MCU 10A again. The MCU 10A receives the user identification information (UID) via the user interface UIF and sets it as an input parameter (PolicyRef) in the policy command to the TPM 18. .

[0062] Then, the TPM18 calculates the AuthPolicy based on the entered user identification information (PolicyRef). The TPM18 then verifies whether the calculated AuthPolicy matches the AuthPolicy stored when the Contract private key was registered. Only if the verification results show a match will the TPM18 allow the signature generation command to be executed using the Contract private key stored together with the AuthPolicy. As a result, signature generation is only possible when an authorized user is using the PnC, and only authorized users can use the PnC.

[0063] The CPU 11 of the MCU 10A creates modules such as a DIGEST generation unit 101 and an AuthPolicy generation unit 102 using a program on the memory 12, and calculates an authentication policy value (AuthPolicy value). The DIGEST generation unit 101 and the AuthPolicy generation unit 102 correspond to the AuthPolicy calculation unit 111 in Fig. 2. The DIGEST generation unit 101 calculates a hash value (DIGEST value, PolicyDigestNew) using, for example, the following Equation 1:

[0064]

number

[0065] Then, the AuthPolicy generating unit 102 calculates a hash value using, for example, the following formula 2, and sets the calculated value as the AuthPolicy value.

[0066]

number

[0067] The MCU 10A sets the calculated AuthPolicy value to the AuthPolicy of the import command. Furthermore, the MCU 10A extracts the Contract public key from the Contract certificate obtained from the MO server 5 and sets it in the import command. Furthermore, the MCU 10A sets the encrypted Contract private key obtained from the MO server 5 in the import command.

[0068] Meanwhile, the MCU 10A embeds the Storage public key corresponding to the Storage private key stored in the TPM 18 and the hash value (PolicyDigestNew) generated by the DIGEST generation unit 101 into the OEMProvisioning certificate. Then, the MCU 10A notifies the MO server 5 of the OEMProvisioning certificate via, for example, the OEM server 6. Note that in FIG. 4, "OEMProv. Certificate (DIGEST)" and "OEMProv. Certificate (Storage Public Key)" are listed separately. These may be notified together from the MCU 10A to the MO server 5. The MCU 10A sends the OEM Provisioning certificate in which the Storage public key and the hash value (PolicyDigestNew) are embedded. The OEM server creates the OEM Provisioning certificate and notifies the MO server 5 of the created OEM Provisioning certificate. 6. If the MCU 10A already has an OEM Provisioning certificate, In this case, the MCU 10A may notify the MO server 5 of the OEMProvisioning certificate in which the Storage public key and the hash value (PolicyDigestNew) are embedded.

[0069] The user also notifies the MO server 5 of the user identification information (UID) via a different route than the communication route between the MCU 10A and the MO server 5. Here, the different route is, for example, a communication route for accessing the website of the MO server 5 from the user's smartphone or personal computer.

[0070] The processor of the MO server 5 creates modules such as an AuthPolicy generation unit 502, a shared key generation unit 503, and an encryption unit 504 using a program on the main storage device. The MO server 5 then uses these modules to provide the MCU 10A of the vehicle 1 with a Contract certificate including the Contract public key and an encrypted Contract private key. As described in FIG. 2, the MO server 5 may also provide the MCU 10A with the Contract certificate and the encrypted Contract private key via the certificate pool 7.

[0071] That is, the AuthPolicy generation unit 502 acquires user identification information (UID) from the user. Also, the AuthPolicy generation unit 502 generates the OEMProvisioning certificate from the DIGEST generation unit 101. Get the hash value (PolicyDigestNew, DIGEST value) generated by M The O server 5 calculates a hash value using the AuthPolicy generation unit 502 in accordance with Equation 2, similar to the AuthPolicy generation unit 102 of the MCU 10A, and sets the hash value as the authentication policy value (AuthPolicy value).

[0072] The MO server 5 sets the Contract public key and the authentication policy value (AuthPolicy value) included in the Contract certificate in the Contract public area. Then, the MO server 5 authenticates the MC using the Diffie-Hellman (DH) key exchange protocol. The MO server 5 then shares a common key with the MCU 10. The MO server 5 then passes the Contract private key encrypted with the common key to the TPM 18 via the MCU 10. That is, the MO server 5 uses the common key generation unit 503 to generate the data in the Contract public area P2 (including the Storage public key). The MO server 5 then uses the generated common key to encrypt the Contract private key in the encryption unit 504. More specifically, the common key generation unit 503 generates a common key embedded in the OEM Provisioning certificate and transmitted from the MCU 10. The first common key is generated using the Storage public key notified by the MO server and the DH private key held by the MO server. The MO server 5 generates a DH public key. The symmetric key generation unit 503 then generates a second symmetric key from the first symmetric key and the data in the Contract public domain P2 using a KDF function. The encryption unit 504 then encrypts the Contract private key using the second symmetric key. The MO server 5 transmits the encrypted Contract private key and Contract certificate to the MCU 10A of the vehicle 1 via, for example, the charging facility 2, the OEM server 6, the certificate pool 7, or the network N1. The DH public key corresponding to the DH private key is notified in advance to the TPM 18 from the MO server 5 via the MCU 10.

[0073] An import command is created through the above process. The MCU 10A inputs the created import command to the TPM 18. When the TPM 18 receives the input of the import command, it returns contract identification information to the MCU 10A as a response. The contract identification information is information that specifies the storage location in the non-volatile memory 1812 where the contract certificate, etc., is registered by the import command. When the MCU 10A receives the contract identification information from the TPM 18, it associates the user identification information (UID) with the contract identification information and stores them in the non-volatile memory 12A.

[0074] Fig. 5 is a diagram illustrating an example of a data flow between the MCU 10A of the charge control device 10 and the TPM 18 when registering an authentication policy. The MCU 10A creates an import command through the process of Fig. 4, and inputs the import command to the TPM 10 and executes it through the process of Fig. 5. Note that the import command may be realized by multiple commands.

[0075] The processor of the TPM 18 creates modules such as a shared key generation unit 185, a decryption unit 186, and a Contract identification information generation unit 187 using a program on the main storage device. Then, the TPM 18 obtains the encrypted Contract private key from the import command. The processing of the shared key generation unit 185 is the same as that of the shared key generation unit 503 of the MO server 5. In other words, the shared key generation unit 185 generates the Contract public key using an algorithm common to that of the shared key generation unit 503. The data in the storage area P1 (including the DH public key) and the storage private key held by the The shared key generating unit 185 generates a shared key that is the same as the shared key generated by the shared key generating unit 503. More specifically, the shared key generating unit 185 generates a shared key that is the same as the shared key generated by the shared key generating unit 503. A first common key is generated using the private key. Then, the common key generation unit 185 generates a second common key using a KDF function from the first common key and the data in the Contract public domain P1. Then, the decryption unit 186 uses the second common key created by the common key generation unit 185 to decrypt the Contract private key encrypted by the encryption unit 504 of the MO server 5.

[0076] The TPM 18 then stores the decrypted Contract private key and other parameters set in the import command in the non-volatile memory 1812. The other parameters set in the import command are the contents of the Contract public domain P1, the authentication policy value (AuthPolicy value), and the Contract public key. The Contract certificate installed from the MO server 5 is stored in at least one of the non-volatile memory 12A of the MCU 10A and the non-volatile memory 1812 of the TPM 18. The Contract private key, the Contract contract, and other parameters set in the import command can be considered to be examples of contract information. Therefore, the TPM 18 can be said to store first data (AuthPolicy value) based on the user's identification information together with contract information regarding charging the vehicle 1.

[0077] Furthermore, the TPM 18 is an example of a second processing unit. Therefore, it can be said that the MCU 10A, as an example of a first processing unit, stores the contract information together with the created first data (AuthPolicy value) in the TPM 18, as an example of a second processing unit. Here, the contract information includes the Contract private key as well as other parameters set in the import command.

[0078] The TPM 18 generates contract identification information using the contract identification information generation unit 187 from information specifying the address of the nonvolatile memory 1812 that stores the contract private key and other parameters set in the import command. The contract identification information may be the address of the nonvolatile memory 1812. Alternatively, the contract identification information may be an index such as a serial number associated with the address of the nonvolatile memory 1812.

[0079] The TPM 18 passes the created Contract identification information to the MCU 10A as a return value when executing the import command. The Contract identification information is an example of contract identification information that identifies the stored first data and contract information. In other words, when the TPM 18 as the second processing unit stores the first data (AuthPolicy value) and contract information, it passes the contract identification information that identifies the stored first data and contract information to the first processing unit. As already mentioned, the MCU 10A associates the Contract identification information returned from the TPM 18 with the user identification information (UID) and stores them in the non-volatile memory 12A.

[0080] (Authentication policy validation) Fig. 6 is a diagram illustrating an example of the data flow between the MCU 10A and the TPM 8 when the vehicle 1 is connected to the charging facility 2, for example, via the plug 2B in Fig. 1. Note that Fig. 6 also illustrates the charging facility 2.

[0081] ((overview)) When the vehicle 1 is connected to the charging facility 2, the MCU 10A first receives user identification information (fingerprint information, face authentication information, password, identification information of the smart key of the vehicle 1, etc.) from the user interface UIF. Here, if the user identification information in Fig. 4 is the first reception, the reception when the vehicle 1 is connected to the charging facility 2 can be said to be a second reception.

[0082] Then, the MCU 10A sets parameters in the policy command, inputs the policy command to the TPM 18, and executes the policy command. 0A is the authorized MCU 10A, that is, the user of the vehicle 1 is a valid user. Then, the MCU 10A inputs a signature generation command to request creation of a signature using the Contract private key. When the TPM 18 has verified that the user of the vehicle 1 is a valid user, it creates a signature using the Contract private key and passes it to the MCU 10A. The MCU 10A notifies the charging facility 2 of the created signature and the Contract certificate. When the signature is verified by the charging facility 2 or the backend server 3, the MCU 10A can charge the battery 19.

[0083] ((Policy Command)) As described above, when the vehicle 1 is connected to the charging facility 2, the MCU 10 creates parameters to be set in the policy command. The policy command includes an HMAC value, an authentication entity name, and PolicyRef. The MCU 10 sets the parameters in the policy command. For this purpose, an HMAC value generating unit 106 is provided.

[0084] The HMAC value is a function value obtained by a hash function for HMAC authentication. The hash function for HMAC authentication calculates a hash value from an authentication value of a policy command shared in advance between the MCU 10 and the TPM 18, a session key generated from the authentication value, the message to be authenticated, and information obtained by bit-concatenating a predetermined fixed value. The hash value calculated by the MCU 10 is an example of a first hash value created by a hash function based on a message containing user identification information received again.

[0085] In this embodiment, there is no limitation on the message. In this embodiment, the message to be authenticated includes, for example, the authentication entity name and the policy command including PolicyRef, excluding the HMAC value. The HMAC value may be a bit string indicating the message, or a hash value of the bit string. In this embodiment, the HMAC value generation unit 106 calculates an HMAC value for such a message. The HMAC value is input to the TPM 18 in the policy command, and the TPM 18 calculates a hash value from the same message using the same hash function, thereby verifying the HMAC value. It can be said that the verification of the HMAC value is a verification that the MCU 10A of the vehicle 1 has the authority to execute the policy command. The authentication entity name and the bit string of the policy command including PolicyRef, excluding the HMAC value, are used to verify the execution of the message containing the received identification information again. This is an example of a

[0086] As already mentioned, the authentication entity name is the name of the module in the TPM 18 that is executed in the authentication by the policy command. As already mentioned, in this embodiment, PolicyRef contains the user's The user identification information (UID) input from the interface UIF is set. After setting the parameters in the policy command, the MCU 10A inputs the policy command to the TPM 18 and executes it. This process is an example of the MCU 10A acting as the first processing unit inputting the user identification information received again to the TPM 18 acting as the second processing unit. This process is also an example of the MCU 10A inputting a message together with the first hash value to the TPM 18 acting as the second processing unit.

[0087] ((Signature generation command)) After inputting the policy command to the TPM 18, the MCU 10A sets parameters in a signature generation command, inputs the command to the TPM 18, and executes it. The MCU 10A has a comparison unit 107 and a selection unit 108 for setting parameters in the signature generation command. In addition, the non-volatile memory 12A stores user identification information and contract identification information in association with each other.

[0088] The comparison unit 107 compares the user identification information (UID) input from the user interface UIF with the user identification information (UID) stored in the nonvolatile memory 12A, and if the two match, The MCU 10A searches an area of ​​the nonvolatile memory 12A for the Contract identification information stored in association with the user identification information (UID) input from the user interface UIF. The selection unit 108 then selects the Contract identification information stored in association with the user identification information (UID) input from the user interface UIF and sets the selected Contract identification information in the signature generation command. The MCU 10A inputs the signature generation command in which the Contract identification information has been set to the TPM 18 and causes it to be executed.

[0089] When the MCU10A as the first processing unit re-inputs the received user identification information into the TPM18 as the second processing unit, it can be said that the MCU10A specifies the first data and contract information to the TPM18 using the Contract identification information as the contract identification information.

[0090] ((Signature Generation)) To verify the authentication policy value (AuthPolicy value), the TPM 18 has an HMAC verification unit 180, a DIGEST generation unit 188, an AuthPolicy generation unit 189, and an AuthPolicy verification unit 183. The HMAC verification unit 180 calculates an HMAC value using the same algorithm and the same secret key for the same message as the HMAC value generation unit 106 of the MCU 10A. This process is an example of the TPM 18 as a second processing unit creating a second hash value using the same hash function as the MCU 10A as a first processing unit, based on the input message.

[0091] The HMAC verification unit 180 then determines whether the calculated HMAC value matches the HMAC value set in the policy command. If the calculated HMAC value matches the HMAC value set in the policy command, the HMAC verification unit 180 notifies the DIGEST generation unit 188 that the verification of the HMAC value was successful. The HMAC value set in the policy command is an example of a first hash value. The HMAC value calculated by the HMAC verification unit 180 is an example of a second hash value. Therefore, the verification of the HMAC value is successful when the second hash value matches the input first hash value.

[0092] The DIGEST generation unit 188 and the AuthPolicy generation unit 189 correspond to the AuthPolicy calculation unit 182 in FIG. 2. When the DIGEST generation unit 188 is notified that the verification of the HMAC value has been successful, it executes processing. The DIGEST generation unit 188 calculates a hash value (for example, PolicyDigestNew+1) using the algorithm shown in Equation 1. This calculation is performed by the DIGEST generation unit 101 of the MCU 10A. This is the same as when the PolicyDigestNew value was generated.

[0093] The AuthPolicy generation unit 189 calculates the authentication policy value (AuthPolicy) using the algorithm shown in Expression 2. The authentication policy value (AuthPolicy) is a hash value calculated from the hash value (e.g., PolicyDigestNew+1) generated by the DIGEST generation unit 101 and the user identification information set in PolicyRef of the policy command. The authentication policy value (AuthPolicy) generated by the AuthPolicy generation unit 189 can be said to be an example of second data based on the identification information received again.

[0094] Next, the AuthPolicy verification unit 183 compares the authentication policy value (AuthPolicy) generated by the AuthPolicy generation unit 189 with the stored authentication policy value (AuthPolicy). The authentication policy value (AuthPolicy) at the time of authentication policy registration is stored in the non-volatile memory 1812 at an address specified by the Contract identification information specified in the signature generation command. This processing is an example of determining whether or not second data based on the user identification information received again via the ECU 10A serving as the first processing unit matches the first data stored in the non-volatile memory 1812. The authentication policy value (AuthPolicy) generated by the AuthPolicy generation unit 189 is an example of second data. The authentication policy value (AuthPolicy) stored in the non-volatile memory 1812 at an address specified by the Contract identification information is an example of first data.

[0095] If the two match, the AuthPolicy verification unit 183 notifies the signature generation unit 184 of an instruction that the signature is OK. The value of the authentication policy (AuthPolicy value) stored at the address in the non-volatile memory 1812 specified by the Contract identification information is an example of stored first data. Therefore, if the two match, it can be said that the second data based on the user identification information received again matches the stored first data. Furthermore, the instruction that the signature is OK permits the creation of a signature for charging the vehicle 1 from the charging facility 2.

[0096] When the signature generation unit 184 receives the instruction of signature OK, it creates a signature for the DIGEST value delivered from the MCU 10A using the Contract private key stored in the nonvolatile memory 1812 at the address specified by the Contract identification information. Here, the DIGEST value is based on, for example, a bit string (GenChallenge) notified to the MCU 10A by the charging facility 2 in a message called PaymentDetailsRes. In other words, the TPM 18 as a controller creates a signature for the DIGEST value delivered from the MCU 10A using the Contract private key stored in the nonvolatile memory 1812 at the address specified by the Contract identification information. It can be said that when the second data based on the attached user identification information matches the stored first data, TPM 18 as the second processing unit creates a signature for charging vehicle 1 from charging facility 2. It can also be said that when the second data based on the user identification information received again via MCU 10A as the first processing unit matches the first data stored in nonvolatile memory 1012, TPM 18 as the second processing unit creates a signature and hands it over to MCU 10A.

[0097] Then, signature generation unit 184 passes the created signature to MCU 10A. Therefore, it can be said that MCU 10A as a first processing unit obtains a signature for charging vehicle 1 from charging facility 2 from TPM 18 as a second processing unit. MCU 10A notifies charging facility 2 of the signature created by TPM 18, for example, by a message called AuthorizationReq. As a result, signature verification is executed in charging facility 2, and if the signature verification is successful, charging starts.

[0098] (Processing Procedure) 7 and 8 are sequence diagrams illustrating an example of the authentication policy registration process. This sequence illustrates the exchange of information between the MCU 10A of the charging control device 10, the TPM 18, and the MO server 5. However, instead of the MO server 5, the OEM server 6 may execute this sequence. Furthermore, the MO server 5 may exchange information with the MCU 10A of the charging control device 10 via the charging facility 2 or the back-end server 3 of the charging facility 2, and execute the sequences of FIGS. 7 and 8.

[0099] In this process, first, the MCU 10A accepts input of user identification information from the user interface UIF (S1). Then, the MCU 10A generates a DIGEST value using the DIGEST generation unit 101 according to the above formula 1, and generates an authentication policy value (AuthPolicy value) using the AuthPolicy generation unit 102 according to the above formula 2 (S2). Then, the MCU 10A sets the generated authentication policy value (AuthPolicy value) in the import command (S3).

[0100] Next, the MCU10A sends the OEMProvisioning certificate with the generated DIGEST value embedded therein to For example, the MCU 10A notifies the MO server 5 via the OEM server 6 (S4). However, the MCU 10A may request the OEM server 6 to create an OEMProvisioning certificate with an embedded DIGEST value and notify the MO server 5 of the created OEMProvisioning certificate. Alternatively, the MCU 10A may notify the MO server 5 of the OEMProvisioning certificate directly via a network N1 such as the Internet. Alternatively, the MCU 10A may notify the MO server 5 of the OEMProvisioning certificate via the charging facility 2. The OEM may notify the OEM of the OEM Provisioning Certificate.

[0101] When the OEM server 6 executes the sequence of FIG. 7, the MCU 10A notifies the OEM server 6 of the OEMProvisioning certificate via a network N1 such as the Internet. In addition, in Figure 7 and subsequent figures, the OEMProvisioning certificate is abbreviated as the OEMProv. certificate. It is called.

[0102] The MO server 5 receives the user's identification information via a communication path other than the communication path between the MCU 10A and the OEM server 6 (S5). Then, the MO server 5 generates an AuthPolicy value according to the above formula 2 using the received user's identification information and the DIGEST value notified in S4, and stores the AuthPolicy value in the Contract public area P2 within the MO server 5 (S6). Furthermore, the MO server 5 obtains a Contract public key from a Contract certificate based on the contract between the user and the MO, and stores the Contract public key in the Contract public area P2 (S7). The MO server 5 also notifies the MCU 10A of the charging control device 10 of the Contract certificate including the Contract public key (S8). Note that the Contract certificate including the Contract public key may be temporarily stored in the certificate pool 7 and then installed in the MCU 10A.

[0103] Next, the MO server 5 creates a common key using, for example, the ECDH protocol and a KDF function, and encrypts the contract private key (S9). Then, the MO server 5 notifies the MCU 10A of the charging control device 10 of the encrypted contract private key (S10). Note that the encrypted contract private key may be temporarily stored in the certificate pool 7 together with the contract certificate, and then installed in the MCU 10A. Symbols A1 and B1 in FIG. 7 are connected to symbols A1 and B1 in FIG. 8. The explanation will be continued below with reference to FIG. 8.

[0104] The MCU 10A extracts the contract public key from the contract certificate received from the MO server 5 and sets it in the import command together with the encrypted contract private key, etc. (S20). Here, the contract certificate, the encrypted contract private key, etc. are included in the Certificate Installation data in Fig. 2. Then, the MCU 10A inputs the import command to the TPM 18 and causes it to be executed (S21).

[0105] The TPM 18 receives the import command (S22). In response, the TPM 18 notifies the MCU 10 of the Contract identification information as a return value (S23). The Contract identification information is information corresponding to the address in the non-volatile memory 1812 where the parameters input by the import command are saved.

[0106] Next, the TPM 18 creates a common key and decrypts the encrypted Contract private key using the same procedure as in S9 of the MO server 5 (S25). The TPM 18 then stores the decrypted Contract private key and other parameters notified by the import command (Contract public key, authentication policy value (AuthPolicy value), etc.) in the non-volatile memory 1812 (S26). In S26, the address of the non-volatile memory 1812 where the data is to be stored is specified by the Contract identification information.

[0107] 9 and 10 are sequence diagrams illustrating a process for determining whether or not a signature can be executed based on an authentication policy. Also, FIG. 9 and FIG. 10 illustrate an example of information exchange among the MCU 10A of the charging control device 10, the TPM 18, and the charging facility 2 in this sequence.

[0108] In this process, the MCU 10A receives the user identification information again from the user interface UIF (S41). Then, the MCU 10A sets the received user identification information in the parameter PolicyRef of the policy command (S42). The MCU 10A calculates an HMAC value and sets it in the policy command (S43). The MCU 10A also sets the authentication entity name in the policy command (S44).

[0109] Then, the MCU 10A inputs a policy command to the TPM 18 (S45). Next, the MCU 10 inputs a signature generation command to the TPM 18, requesting signature generation (S46). The MCU 10 specifies the Contract identifier in the signature generation command.

[0110] Upon receiving the policy command and the signature generation request, the TPM 18 first performs HMAC authentication. If the HMAC authentication fails (NO in S47), the TPM 18 ends the process. At this time, the TPM 18 may notify the MCU 10 of an error.

[0111] If the HMAC authentication is successful (YES in S47), the TPM 18 generates a DIGEST value according to Equation 1 (S48). Next, the TPM 18 calculates the value of the authentication policy from the DIGEST value generated in S48 and PolicyRef (user identification information) obtained as a parameter of the policy command. (called AuthPolicy A) is generated (S49). The symbols D1, E1, and F1 in FIG. 9 are It connects to symbols D1, E1, and F1 of 0. The explanation will be continued below with reference to FIG.

[0112] Next, the TPM 18 reads out the value of the authentication policy (referred to as AuthPolicy B) registered in the nonvolatile memory 1812 (S50). The address of the nonvolatile memory 1812 where the value of the authentication policy (AuthPolicy B) is stored is specified by the MCU 10 using the Contract identification information.

[0113] Next, the TPM18 stores the generated authentication policy value (AuthPolicy A) and It is determined whether the value (AuthPolicy B) registered in the AuthPolicy 1812 matches (S51 If they do not match (NO in S51), the TPM 18 ends the process. At this time, the TPM 18 may notify the MCU 10 of an error.

[0114] The generated authentication policy value (AuthPolicy A) and the value registered in the nonvolatile memory 1812 are If the value (AuthPolicy B) matches (YES in S51), the TPM 18 That is, the TPM 18 first reads the Contract private key from the nonvolatile memory 1812 (S53). Note that up to this point, the charging facility 2 has The message notifies the MCU 10A of data (GenChallenge) for creating a signature (S54).

[0115] The MCU 10A then generates a DIGEST value from the data (GenChallenge) and passes it to the TPM 18 (S55). The TPM 18 creates a signature by encrypting the DIGEST value passed from the MCU 10A with the Contract private key. The TPM 18 then notifies the MCU 10A of the created signature (S56).

[0116] The MCU 10A notifies the charging facility 2 of the signature created by the TPM 18 together with the Contract agreement (S57). The charging facility 2 verifies the signature by decrypting the signature with the Contract public key included in the Contract agreement received from the MCU 10A (S58).

[0117] (Effects of the embodiment) In this charging system, the MCU 10A and the TPM 18, as an example of a controller, accept user identification information and store first data (the authentication policy value (AuthPolicy)) based on the user identification information in the TPM 18 together with contract information (the Contract private key and the Contract public key) related to charging the vehicle 1. Then, when the vehicle 1 is connected to the charging facility 2, the MCU 10A and the TPM 18 accept the user identification information again. Then, if the second data (the authentication policy value (AuthPolicy)) based on the reaccepted user identification information matches the first data stored in the TPM 18, the MCU 10A and the TPM 18 create a signature for charging the vehicle 1 from the charging facility 2. Therefore, if the MCU 10A and the TPM 18 are taken out together as controllers or if they are stolen or otherwise stolen together with the vehicle 1, the MCU 10A and the TPM 18 prevent unauthorized signature creation.

[0118] MCU 10A as a first processing unit receives user identification information, creates first data based on the user identification information, and stores the contract information together with the created first data in TPM 18 as a second processing unit. MCU 10A then inputs the received user identification information again into TPM 18, thereby acquiring from TPM 18 a signature for charging from charging facility 2 to vehicle 1. MCU 10A then controls charging from charging facility 2 to vehicle 1 based on the signature acquired from TPM 18.

[0119] Meanwhile, the TPU 18 as a second processing unit stores the first data and contract information, and creates a signature and passes it to the MCU 10A when second data based on user identification information received again via the MCU 10A matches the first data stored in the non-volatile memory 1812. Therefore, if the MCU 10A and the TPM 18 are taken out separately, if the MCU 10A and the TPM 18 are taken out together, or if they are stolen together with the vehicle 1, the MCU 10A and the TPM 18 prevent unauthorized signatures from being created.

[0120] Furthermore, when the TPM 18 stores the first data and contract information, it passes contract identification information that identifies the stored first data and contract information to the MCU 10A. Meanwhile, when the MCU 10A re-inputs received user identification information into the TPM 18, it specifies the first data and contract information to the second processing unit using the contract identification information. Therefore, the MCU 10A and the TPM 18 can distribute and share the processing for identifying the first data and contract information corresponding to the user identification information.

[0121] Furthermore, the MCU 10A creates a first hash value using a hash function for HMAC authentication based on the message containing the user identification information received again, and inputs the message together with the created first hash value to the TPM 18. Meanwhile, the TPM 18 creates a second hash value based on the input message using the same hash function as the MCU 10A, and determines whether the created second hash value matches the first hash value. Then, when the second hash value matches the first hash value, the TPM 18 determines whether second data based on the user identification information received again via the MCU 10A matches the first data stored in the non-volatile memory 1812 of the TPM 18. This allows the MCU 10A and the TPM 18 to securely exchange messages containing user identification information, which is a prerequisite for confirming whether the first data and the second data match.

[0122] Second Embodiment 11 is a diagram illustrating an example of a data flow between the MCU 10, in which multiple pieces of user identification information are registered, and the TPM 18 in the second embodiment. In the first embodiment, the charging control device 10 generates an authentication policy value (AuthPolicy value) based on the user identification information and stores it in the TPM 18. Then, when the vehicle 1 is connected to the charging facility 2, the TPM 18 checks the authentication policy value (AuthPolicy value) of the user of the vehicle 1. This method can also be used to identify multiple users.

[0123] For example, the MCU 10A stores and manages pairs of contract identification information and user identification information in the nonvolatile memory 12A. The MCU 10A can then identify the user currently using the vehicle 1 by selecting the user identification information in the nonvolatile memory 12A that corresponds to the user identification information input during the charging session. In other words, the MCU 10A as the first processing unit can be said to receive the identification information of multiple users and store the received identification information of the multiple users together with the contract identification information of each user.

[0124] For example, the nonvolatile memory 12A of the MCU 10A stores Contract identification information A in association with user identification information A of user A. Contract identification information B is stored in association with the above.

[0125] Here, an example of processing when user B connects vehicle 1 to charging facility 2 is shown. When vehicle 1 is connected to charging facility 2, similar to the first embodiment, MCU 10A again accepts user identification information (fingerprint information, face authentication information, password, identification information of the smart key of vehicle 1, etc.) from user interface UIF. Then, MCU 10A selects Contract identification information B from the user identification information B of user B that has been accepted again.

[0126] Then, MCU 10A sets parameters in the policy command, inputs the policy command to TPM 18, and executes it. Furthermore, MCU 10A sets Contract identification information B, inputs a signature generation command, and requests creation of a signature using the Contract private key. That is, when vehicle 1 is connected to charging facility 2, MCU 10A acquires Contract identification information B as contract identification information corresponding to user identification information B received again, and specifies the acquired Contract identification information B to TPM 18 as a second processing unit.

[0127] When the TPM 18 receives the input of the policy command, it verifies that the MCU 10A of the vehicle 1 is the authorized MCU 10A, that is, that the user B of the vehicle 1 is a valid user. At this time, the TPM 18 acquires the authentication policy value (AuthPolicy value) from the address of the nonvolatile memory 1812 that is associated with the user identification information B of the user B and identified by the Contract identification information B. Then, the authentication policy value (AuthPolicy value) of the nonvolatile memory 1812 is compared with the authentication policy value (AuthPolicy value) generated from the user identification information B of the user B that was input by the policy command, and the legitimacy of the user B is confirmed.

[0128] When the TPM 18 verifies that the user B of the vehicle 1 is a valid user, the TPM 18 acquires the contract private key from the address of the non-volatile memory 1812 that is associated with the identification information B of the user B and that is specified by the contract identification information B. Then, the TPM 18 creates a signature using the acquired contract private key and passes it to the MCU 10A. The MCU 10A notifies the charging facility 2 of the created signature and the contract certificate. When the signature is verified by the charging facility 2 or the backend server 3, the MCU 10A can charge the battery 19.

[0129] As described above, according to this embodiment, the MCU 10A receives a plurality of pieces of user identification information and stores contract identification information corresponding to each of the received pieces of user identification information together with the respective user contract identification information. Then, when the vehicle 1 is connected to the charging facility 2, the MCU 10A again acquires contract identification information corresponding to the received user identification information and assigns the acquired contract identification information to the TPM 18. Therefore, the MCU 10A can identify a plurality of users and perform authentication and charging control using PnC.

[0130] In the second embodiment, the OEMProvisioning certificate contains the AuthPolicy value instead of the DIGEST value. This is because, in cases where multiple users are identified, it is necessary to prevent the first data based on the user identification information from being shared across users.

[0131] (Variation) In the second embodiment, the MCU 10A receives a plurality of pieces of user identification information and stores the contract identification information in association with each of the received pieces of user identification information. However, instead of this process, the MCU 10A may receive a plurality of pieces of user identification information, convert it into first data, and store the contract identification information in association with each of the converted pieces of first data. Then, when the vehicle 1 is connected to the charging facility 2, the MCU 10A may convert the received user identification information again into second data. Then, the MCU 10A acquires the contract identification information corresponding to the first data that matches the second data, and stores the acquired contract identification information. The information can be specified to the TPM18.

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

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

[0134] 1 vehicle 2 Charging equipment 3 Backend Server 5 MO Server 6 OEM Servers 7 Certificate Pool 10. Charging control device 10A ECU 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. receiving identification information of a user, and storing first data based on the identification information of the user together with contract information regarding charging of the vehicle; a controller that, when the vehicle is connected to the charging facility, receives the user's identification information again, and, if second data based on the received user's identification information matches the stored first data, creates a signature for charging the vehicle from the charging facility based on the contract information; Charging control device.

2. the controller has a first processing unit and a second processing unit; the first processing unit receives identification information of the user, creates the first data based on the identification information of the user, stores the contract information together with the created first data in the second processing unit, acquires the signature for charging the vehicle from the charging facility from the second processing unit by again inputting the re-accepted identification information of the user into the second processing unit, and controls charging of the vehicle from the charging facility based on the signature; The second processing unit includes:

2. The method according to claim 1, wherein the first data and the contract information are stored, and when the second data based on the user's identification information received again via the first processing unit matches the stored first data, the signature is created and handed over to the first processing unit. Charging control device.

3. when the second processing unit stores the first data and the contract information, the second processing unit delivers contract identification information that identifies the stored first data and the contract information to the first processing unit; 3. The method according to claim 2, wherein the first processing unit specifies the first data and the contract information to the second processing unit based on the contract identification information when the second processing unit receives the user identification information again. Charging control device.

4. the first processing unit receives identification information of a plurality of users, and stores the received identification information of the plurality of users or the first data corresponding to each of the identification information of the plurality of users together with the contract identification information of each user; 4. The method according to claim 3, wherein when the vehicle is connected to the charging facility, the contract identification information corresponding to the re-accepted user identification information is acquired, and the acquired contract identification information is specified in the second processing unit. Charging control device.

5. the first processing unit generates a first hash value using a hash function based on the re-accepted message including the identification information, and inputs the message together with the generated first hash value to the second processing unit; 3. The method according to claim 2, wherein the second processing unit generates a second hash value based on the input message using the same hash function as the first processing unit, and when the generated second hash value matches the input first hash value, determines whether the second data based on the user identification information received again via the first processing unit matches the stored first data. Charging control device.

6. On the computer, Accepting identification information of a user and storing first data based on the identification information of the user together with contract information regarding charging of the vehicle; When the vehicle is connected to a charging facility, the program receives the user's identification information again, and if second data based on the received user's identification information matches the stored first data, creates a signature for charging the vehicle from the charging facility based on the contract information.

Images