In-vehicle device and program

Abstract

To improve a defect on security caused by charging and power feeding in a range exceeding an authentication period in charging and power feeding between a vehicle and a charging and power feeding facility.SOLUTION: The on-vehicle device communicates with a charging / feeding facility for executing charging / feeding including at least one of charging the battery of the vehicle from the outside of the vehicle and feeding power from the battery to the outside of the vehicle so as to obtain a predetermined charge amount by the scheduled departure time of the vehicle, and executes control of the charging / feeding. When a validity period of each of one or more authentications between the vehicle and the electric power supply equipment is reached during the control of the electric power supply, the in-vehicle device ends the control of the electric power supply, and updates the validity period to be reached.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to an in-vehicle 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 that complies with ISO15118, a standard for the communication interface between vehicles and the power grid. With PnC, the user stores a contract certificate in the vehicle in advance, and the encryption key paired with the contract certificate is used to perform user authentication between the vehicle and the charging equipment (Electric Vehicle Supply Equipment, EVSE).

[0003] Regardless of the authentication method, if vehicle or EVSE authentication is required, after the vehicle and EVSE are connected, the vehicle certificate (e.g., Vehicle Certificate) is sent to the EVSE, and the EVSE certificate (e.g., The vehicle is notified of the operator's certificate (for example, a SECC certificate). Each certificate is then authenticated by the operator's certificate (for example, a V2G ROOT certificate or an OEM ROOT certificate) stored on the peer (the vehicle to the EVSE, and the EVSE to the vehicle). This authentication procedure is called Transport Layer Security (TLS) client and server authentication.

[0004] Furthermore, ISO15118 assumes V2G, and infrastructure equipment on the power grid side and vehicles can arbitrate V2G power transmission via communication protocols between vehicles / EVSE and between EVSE / infrastructure equipment. This power transmission is accompanied by the authentication process described above. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2014-225995 Summary of the Invention [Problem to be solved by the invention]

[0006] However, ISO15118 does not specify these certificates, authentication processes, or TLS session operation methods. In such a situation, it is expected that the TLS session lifetime may expire while charging is in progress. In addition, there are cases where the Contract certificate, Vehicle certificate, or SECC certificate expires. In such a case, a combination of these cases may occur. In these cases, there will be a period during which user authentication is not guaranteed. Aspects of the disclosed embodiments improve security deficiencies in charging between a vehicle and a charging facility when charging may occur beyond the authentication period between the vehicle and the charging facility. [Means for solving the problem]

[0007] One aspect of the disclosed embodiment is exemplified by an in-vehicle device that communicates with a charging facility that performs charging including at least one of charging a battery of the vehicle from outside the vehicle and feeding power from the battery to outside the vehicle so that a predetermined charge amount is reached by a scheduled departure time of the vehicle, and controls the charging. The in-vehicle device includes a controller that controls the charging. If the expiration date for one or more authentications between the vehicle and the charging equipment arrives during the control, the charging control is terminated and the expiration date is updated. [Effects of the Invention]

[0008] The controller of the in-vehicle device terminates the control of power charging when an expiration date for one or more authentications between the vehicle and the charging equipment arrives during power charging control. This prevents power charging beyond the expiration date for the authentications between the vehicle and the charging equipment. The controller then updates the upcoming expiration date. Therefore, even if the in-vehicle device cannot recognize the power supply schedule by the charging equipment, it can update the expiration date when the expiration date for one or more authentications between the vehicle and the charging equipment arrives. Therefore, the in-vehicle device prevents power charging between the vehicle and the charging equipment from exceeding the authentication expiration date, and improves security by obtaining a new expiration date. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating a vehicle equipped with an in-vehicle device according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating modules included in the on-board device of the vehicle, the equipment control device of the charging and supply equipment, 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 and a charging facility. [Figure 4] FIG. 4 is a flowchart illustrating a process after a charging session is started after a TLS session is established by a TLS full handshake. [Figure 5] FIG. 5 is a flowchart illustrating the details of the update process. [Figure 6] FIG. 6 is a flowchart illustrating the details of the update process. [Figure 7]FIG. 7 is a sequence diagram illustrating an example of data exchange between the OEM server, the vehicle, and the charging equipment. [Figure 8] FIG. 8 is a sequence diagram illustrating an example of data exchange between the OEM server, the vehicle, and the charging equipment. DETAILED DESCRIPTION OF THE INVENTION

[0010] An in-vehicle device 10 and a computer program (hereinafter simply referred to as a program) according to an embodiment will be described below with reference to FIGS.

[0011] <Embodiment> (Configuration) FIG. 1 is a diagram illustrating an example of a vehicle 1 equipped with an on-board device 10 according to this embodiment. Also shown in FIG. 1 are a charging and supplying facility 2 that supplies and receives power to and from a battery 19 (see FIG. 2, also referred to as a secondary battery or a storage battery) of the vehicle 1, a back-end server 3 that cooperates with the charging and supplying facility 2 and assists in charging and supplying power, a mobility operator (MO) server 5 that supplies and receives information to and from the vehicle 1, an original equipment manufacturer (OEM) server 6, a certificate pool 7, a user device 4 that provides a user interface, and a commercial power grid provided by a power company or the like. It is also assumed that a home power grid or a power load may be connected instead of the grid. The on-board device 10 is also called an Electric Vehicle Communication Controller (EVCC). The equipment control device 20 is also referred to as a Supply Equipment Communication Controller (SE Also called CC.

[0012] The vehicle 1 is called an electric vehicle, and can charge a battery 19 for driving. The vehicle 1 has an on-board device 10, and performs a process of charging the battery 19 from a charging and supplying facility 2, or a process of supplying power from the battery 19 to a commercial power grid via the charging and supplying facility 2. In this embodiment, the charging process and the power supply process are called a charging and power supply process. The power supply process can also be called a process of discharging the battery 19.

[0013] The charging and supplying facility 2 has an facility control device 20, and when connected to the on-board device 10 of the vehicle 1, communicates with the on-board 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 and supplies power to or receives power from the vehicle 1 (i.e., supplies power from the battery 19). In other words, it can be said that the charging and supplying facility 2 performs charging and supplying power, including at least one of charging the battery 19 of the vehicle 1 from outside the vehicle 1 and supplying power from the battery 19 to outside the vehicle 1. The charging and supplying facility 2 is an example of something outside the vehicle 1.

[0014] Charging facility 2 is operated by a business called a Charge Point Operator (CPO) 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 and serves as an interface for sending and receiving power between the vehicle 1 and the power grid.

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

[0016] 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 facility 2, and the backend server 3. In this embodiment, there are two main possibilities for providing the signed contract data to the vehicle 1: via the charging facility 2 or via the OEM server 6.

[0017] 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 backend 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.

[0018] However, when the signed contract data is installed in the vehicle 1 from the OEM server 6, 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] In the power receiving 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. Then, the SECC certificate is authenticated by the V2G ROOT certificate stored on the vehicle 1 side. Next, the vehicle certificate of the vehicle 1 is notified to the charging equipment 2. Then, The Vehicle certificate is authenticated by the V2G ROOT certificate or OEM ROOT certificate stored on the power supply equipment 2 side. Here, the SECC certificate contains the V2G ROOT certificate The Vehicle Certificate contains a hierarchical chain of certificates of the operators associated with the Vehicle Certificate. The certificate contains a hierarchical certificate associated with the V2G ROOT certificate or the OEM ROOT certificate. The certificate chain of the entity with the appropriate structure is included.

[0020] 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. The CA certificates (sub-certificates) of the lower-level intermediate CAs are signed by the higher-level CA.

[0021] Vehicle 1 authenticates the certificate chain from top to bottom based on the V2G ROOT certificate, and ultimately can authenticate the EVSE Leaf certificate (referred to as the SECC certificate). If vehicle 1 successfully authenticates the SECC certificate, it can obtain a shared key (session key) to be used for communication with the charging facility 2, and subsequent communication is encrypted using the shared key. This establishes a TLS session. The shared key used for communication with the charging facility 2 is an example of information for ensuring the security of communication with the charging facility 2. The TLS handshake is also an example of information exchange for ensuring the security of communication.

[0022] A communication session using TLS is called a TLS session. The process of establishing a TLS session is called a TLS handshake. During the TLS handshake, the in-vehicle device 10 and the equipment control device 20 exchange messages to authenticate each other, establish the encryption algorithm to be used, and share a common key. The TLS session is the period during which the common key shared by both parties is valid, and the end of this period is called the TLS session lifetime.

[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 and supply equipment 2 are transmitted to each other, and charging and power supply are performed. In this V2G communication, in addition to PnC, external authentication using a Radio Frequency Identification (RFID) card or the like is performed, for example.

[0024] After the TLS session is established, the on-board device 10 of the vehicle 1 creates a signature based on the Contract certificate or the like and the encryption key, and the charging facility 2 authenticates this. If the authentication is successful, the vehicle 1 executes a power supply and reception process with the charging facility 2 using the PnC procedure. The communication session between the on-board device 10 and the facility control device 20 when executing the power supply process is called a V2G session or a power supply session. However, as described above, in the power supply and reception process between the vehicle 1 and the charging facility 2, in addition to the PnC procedure described above, an external authentication method (EIM) procedure in which an RFID card or the like is presented can also be used as a second authentication procedure.

[0025] The in-vehicle device 10 can be connected to an MO server 5, an OEM server 6, a certificate pool 7, and the like via a network N1. The network N1 is, for example, a Long Term Evolution (LTE) network. This includes wireless networks such as LTE, 5th Generation Mobile Communication System (5G), and 6th Generation Mobile Communication System (6G), as well as wired public networks such as the Internet.

[0026] For example, the charging and supplying equipment 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 and supplying equipment 2 may execute a power receiving process with the battery 19 of the vehicle 1 and a payment process (billing or settlement) with the user of the vehicle 1.

[0027] The user device 4 is a smartphone, a mobile phone, or the like that is connected to the in-vehicle device 10 by wireless communication. Here, the wireless communication is, for example, communication via a wireless access network such as LTE, 5G, or 6G. The wireless communication may also be performed using Bluetooth (registered trademark), Bluetooth (registered trademark), or the like. Communication using Bluetooth Low Energy (BLE) or similar technologies is also acceptable.

[0028] The user device 4 may also be a device connected to the in-vehicle device 10 by wire. The user device 4 may also be incorporated into the in-vehicle device 10, for example, a device corresponding to the display unit 14 and operation unit 15 in FIG. 2. The user device 4 may also have audio, visual, navigation functions, etc. The user device 4 executes processing as an example of a user interface through which a user inputs information.

[0029] FIG. 2 is a diagram illustrating modules and data flows between modules included in the on-board 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 on-board device 10 in FIG. 2, the CPU 11 illustrated in FIG. 3 executes processing in accordance with a computer program executablely loaded in the memory 12. The back-end server 3, the MO server 5, the OEM server 6, and the certificate pool 7 each have a configuration similar to that of the CPU 11 and the memory 12, and execute processing in accordance with a computer program. Note that at least some of the components of the equipment control device 20 may be provided in the back-end server 3. Therefore, in FIG. 2, the reference numeral 3 is enclosed in parentheses along with the reference numeral 20.

[0030] For example, before the vehicle 1 is connected to the charging and supplying equipment 2, 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 performs a certificate acquisition process to acquire a vehicle certificate, a contract certificate, etc. The acquisition request is sent to the OEM communication control unit 613 (M30).

[0031] Of the certificates, the Vehicle certificate is issued by the certificate issuing unit 601 of the OEM server 6. The vehicle certificate is then handed over to the OEM communication control unit 113 by the certificate acquisition unit 602 via the OEM communication control unit 613 (M32, M35, M36). The leaf certificate is issued to the in-vehicle device 10 (EVCC) by an OEM or a V2G certification authority (such as a sub-CA) to authenticate the authenticity of the vehicle.

[0032] Furthermore, the Contract certificate is stored in the certificate storage unit 712 in the certificate pool 7. The Contract certificate is issued by the MO server 5 of the business that supplies power (referred to as a mobility service provider) and stored in the certificate pool 7. Then, the certificate acquisition unit 602 notifies the certificate storage unit 712 of the certificate pool 7 of a Contract certificate request (M33) and acquires the Contract certificate (M34). In this way, the certificate acquisition unit 602 passes the Contract certificate to the OEM communication control unit 113 via the OEM communication control unit 613 (M35, M36).

[0033] Certificates (Vehicle Certificate, Contract Certificate) acquired by the OEM communication control unit 113 ) are stored in the certificate storage unit 112 (M4). The certificate storage unit 112 has a non-volatile memory area in the memory 12 (see FIG. 3), and stores the Vehicle certificate, Contract certificate, etc. The Contract certificate can also be obtained from the equipment control device 20 (or the backend server 3) via the V2G communication control units 104 and 204 (M7, M8, M5).

[0034] When plug 2B of charging and power supply equipment 2 is connected to a connection part including a terminal of a power receiving part and a charging communication part 16B of a power circuit in vehicle 1 that charges battery 19 (see FIG. 3), in-vehicle device 10 and equipment control device 20 (or back-end server 3) communicate with each other. That is, in-vehicle device 10 and equipment control device 20 (or back-end server 3) perform TLS authentication and V2G communication.

[0035] First, the in-vehicle device 10 notifies, for example, the equipment control device 20 (or the backend server 3) of a Client Hello message, and the equipment control device 20 (or the backend server 3) notifies the in-vehicle device 10 of a Server Hello message. In the following embodiment, the processing is described as being executed between the in-vehicle 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.

[0036] Here, for example, in a procedure according to ISO15118-20, the TLS communication control unit 103 of the in-vehicle device 10 transmits the Vehicle certificate to the TLS communication control unit 203 of the equipment control device 20. As described above, the vehicle certificate is stored in the certificate storage unit 112, for example. The TLS communication control unit 103 reads the vehicle certificate from the certificate storage unit 112 and The LS communication control unit 203 is notified.

[0037] The equipment control device 20 uses the vehicle certificate to establish the reliability of the in-vehicle device 10 in TLS communication. The vehicle certificate is used to verify the authenticity of the vehicle belonging to the same V2G session by the equipment control device 20. However, vehicle certificates are not used in procedures specified in standards prior to ISO 15118-20.

[0038] Meanwhile, the TLS communication control unit 203 of the equipment control device 20 transmits the SECC certificate to the TLS communication control unit 103 of the in-vehicle device 10 in both the procedures of ISO15118-20 and the standard earlier than ISO15118-20 (M2). The SECC certificate is a certificate issued so that the in-vehicle 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 power charging equipment 2, the equipment control device 20, or the backend server 3 by either the V2G root CA or the sub-CA.

[0039] The on-board device 10 and the equipment control device 20 complete a TLS handshake through mutual communication via the TLS communication control units 103 and 203, and a TLS session begins. Here, for example, the on-board device 10 authenticates the power charging equipment 2 or the equipment control device 20 using the SECC certificate received from the equipment control device 20. The TLS communication control unit 103 also notifies the user authentication continuation determination unit 105 of the TLS session lifetime (denoted as "TLS expiration date" in FIG. 2) (M18). In this manner, the user authentication continuation determination unit 105 acquires the TLS session lifetime as an example of expiration date information indicating an expiration date related to authentication during the process of transferring power. Note that the TLS session lifetime can also be considered an example of an expiration date related to one or more authentications between the vehicle 1 and the power charging equipment 2. The TLS communication control unit 103 then passes the received SECC certificate to the certificate expiration date acquisition unit 102 (M3).

[0040] Furthermore, the certificate expiration date acquisition unit 102 reads out the Contract certificate and the Vehicle certificate from the certificate storage unit 112 (M45). The expiration dates of the C certificate, Contract certificate, and Vehicle certificate are checked by the user authentication continuation determination unit 10. 5 and certificate renewal determination unit 106 (M6). In this way, user authentication continuation determination unit 105 and certificate renewal determination unit 106 acquire the expiration dates of the SECC certificate, the Contract certificate, and the Vehicle certificate as examples of expiration date information indicating the expiration dates related to authentication during the process of transferring power. The expiration dates of the SECC certificate, the Contract certificate, and the Vehicle certificate can also be considered as examples of expiration dates related to one or more authentications between vehicle 1 and power supply equipment 2.

[0041] Furthermore, the TLS communication control unit 103 reads out the vehicle certificate from the certificate storage unit 112. The read vehicle certificate is authenticated through the TLS communication control unit 203. However, the vehicle certificate authentication is based on ISO15118-20. The SECC certificate is authenticated through the control unit 103. If these authentications are successful, the V2G communication control units 104 and 204 execute negotiation of the V2G communication protocol and authentication method. The V2G communication protocol ( ISO15118-20, ISO15118-2, etc.) is decided, and negotiations for certification methods begin. The option determines the authentication method (PnC, EIM, etc.) used for the payment.

[0042] Furthermore, the V2G communication control unit 104 reads the Contract certificate from the certificate storage unit 112 and transmits it together with a signature generated using the corresponding private key to the V2G communication control unit 204. When 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, power supply is performed between the power charging facility 2 and the vehicle 1.

[0043] However, if the on-board device 10 does not store a valid Contract certificate in the certificate storage unit 112, the V2G communication control unit 104 may acquire the Contract certificate via the equipment control device 20. That is, the V2G communication control unit 104 notifies the V2G communication control unit 204 of the equipment control device 20 of a Contract certificate request together with a certificate (OEM provisioning certificate) issued by the manufacturer and distributor of the vehicle 1 (M7). If the equipment control device 20 has a valid Contract certificate associated with the OEM provisioning certificate notified from the vehicle 1, it can provide the Contract certificate to the vehicle 1.

[0044] However, if the business operator'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, the equipment control device 20 acquires a valid Contract certificate from the certificate pool 7. That is, the V2G communication control unit 204 notifies the certificate storage unit 712 of the certificate pool 7 of a Contract certificate request together with the OEM provisioning certificate via the certificate acquisition unit 212 (M71, M37).

[0045] Upon receiving the Contract certificate request, the certificate storage unit 712 notifies the certificate acquisition unit 212 of the valid Contract certificate associated with the OEM provisioning certificate (M38). Then, the V2G communication control unit 204 transmits the Contract certificate acquired via the certificate acquisition unit 212 to the V2G communication control unit 104 (M81, M8). The V2G communication control unit 104 passes the acquired Contract certificate to the certificate storage unit 112 (M5, M4). In this way, the on-board device 10 can acquire a valid contract certificate from the power charging facility 2.

[0046] (Application example issue) In the dynamic control mode defined in ISO15118-20, the on-board device 10 of the vehicle 1 does not have the role of calculating a power schedule related to power charging. Therefore, the on-board device 10 accepts input of a scheduled departure time of the vehicle 1 by the user from the departure time input unit 107, and transmits the scheduled departure time of the vehicle 1 to the power grid side such as the charging facility 2 instead of the power schedule. When the vehicle 1 is connected to the charging facility 2, the vehicle 1 notifies the charging facility 2 of ratings related to the power of the vehicle 1, such as the maximum voltage, minimum voltage, maximum current, and minimum current during charging.

[0047] Therefore, the power grid side including the charging equipment 2 adjusts the power schedule for each vehicle 1 until the scheduled departure time based on information such as the maximum voltage, minimum voltage, maximum current, and minimum current of the vehicle 1 and the scheduled departure time of the vehicle 1. In FIG. 2, the grid power schedule calculation unit 205 performs this adjustment. Then, the equipment control device 20 performs V2G charging by the scheduled departure time so that the vehicle will be charged to a predetermined amount by the scheduled departure time. The predetermined amount of charge is, for example, the state of charge (SOC) required by the user.

[0048] Therefore, in this embodiment, the vehicle 1 (the on-board device 10) is configured to understand the power schedule. Therefore, the vehicle 1 (on-board device 10) cannot determine whether the expiration date of each certificate or the expiration date of the TLS session lifetime has passed the completion point of the power schedule. Therefore, in this embodiment, when the expiration date of each certificate or the expiration date of the TLS session lifetime has arrived, the on-board device 10 stops the current V2G session (i.e., the power supply session) and attempts to update the certificate or the TLS session.

[0049] The user authentication continuation determination unit 105 acquires each "certificate expiration date" from the certificate expiration date acquisition unit 102 (M6). The user authentication continuation determination unit 105 also acquires the "TLS session lifetime expiration date" from the TLS communication control unit 103 (M18). Note that the ISO15118 standard stipulates that the "TLS session lifetime expiration date" is one day. The user authentication continuation determination unit 105 also acquires the "scheduled vehicle departure time" from the departure time input unit 107 (M12). When the "scheduled vehicle departure time" exceeds each "certificate expiration date" or "TLS session lifetime expiration date," the user authentication continuation determination unit 105 controls each unit so that the expiring certificate or TLS session lifetime expiration date is updated.

[0050] That is, the user authentication continuation determination unit 105 checks the expiration dates of the SECC certificate, the Contract certificate, and the Vehicle certificate notified by the certificate expiration date acquisition unit 102, and the T The user authentication continuation determination unit 105 compares the expiration date of the LS session lifetime with the scheduled departure time of the vehicle. The earliest possible expiration time T1 is determined between the expiration time and the TLS session lifetime expiration time.

[0051] Then, the user authentication continuation determination unit 105 determines whether the scheduled vehicle departure time is before the earliest time T1. Then, the user authentication continuation determination unit 105 notifies the TLS communication control unit 103 and the V2G communication control unit 104 of the determination result on whether or not to continue the user authentication (in FIG. 2, "Authentication continuation possible") (M19).

[0052] The certificate renewal determination unit 106 determines whether the vehicle certificate notified by the certificate expiration date acquisition unit 102 is valid. The certificate update determination unit 106 then notifies the OEM communication control unit 113, the V2G communication control unit 104, and the payment method determination unit 108 whether or not the certificate needs to be updated (M20).

[0053] The TLS communication control unit 103 temporarily terminates the V2G session before the TLS session lifetime expires, performs a TLS full handshake, and updates the TLS session lifetime. The OEM communication control unit 113 or the V2G communication control unit 104 temporarily terminates the V2G session before the Contract certificate expires and updates the Contract certificate. Then, the V2G communication control unit 104 starts the charging session again using the updated Contract certificate. The Vehicle certificate or the SECC certificate is updated Then, the TLS communication control unit 103 performs a TLS full handshake and starts a new TLS session. Then, the V2G communication control unit 104 starts a charging session again using the existing valid Contract certificate.

[0054] The payment method determination unit 108 determines a payment method (a method of authentication with the power charging and supply facility 2) according to the certificate update necessity and update result from the certificate update determination unit 106, and notifies the V2G communication control unit 104. The payment method is, for example, PnC or EIM according to ISO15118-20, or PnC or EIM according to ISO15118-2.

[0055] FIG. 3 is a diagram illustrating an example of the hardware configuration of the vehicle 1 and the charging and supplying facility 2. The on-board device 10 of the vehicle 1 and the charging and supplying facility 2 constitute a charging system. The on-board device 10 includes a CPU 11 The CPU 11 has a memory 12 and external devices connected to an external interface (I / F), and executes information processing by a program. The external devices include an external storage unit 13, a display unit 14, an operation unit 15, an external communication unit 16A, and a charging and communication unit 16B. The CPU 11 and the memory 12 can be collectively referred to as a control unit. The control unit is an Electronic Control Unit ( The control unit is also called an ECU.

[0056] The CPU 11 executes a computer program deployed in an executable manner in the memory 12, and provides the functions of the in-vehicle 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, such as a GPU or a DSP.

[0057] 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 Flash memory, Electrically Erasable Programmable Read-Only Memory (EE 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. be.

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

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

[0060] 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 and power supply equipment 2, for example, based on Power Line Communications (PLC). However, the charging communication unit 16B may communicate with the charging communication unit 26B via a Controller Area Network (CAN), a wireless LAN, an Ethernet, or the like. Communication may be performed according to the above or a communication procedure based on these.

[0061] The charging and supplying equipment 2 has an equipment control device 20 and a power supply circuit 29. The equipment control device 20 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 and communication unit 26B, and an EIM reader 2A. The configuration of the charging and supplying equipment 2, other than the EIM reader 2A and the power supply circuit 29, is the same as that of the on-board device 10 of the vehicle 1, and therefore a description thereof will be omitted.

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

[0063] 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 MO server 5, OEM server 6, and certificate pool 7 may be a collection of multiple computers called a cloud.

[0064] (Processing flow) In this embodiment, the expiration date of each certificate and the expiration date of the TLS session lifetime are collectively referred to as the authentication expiration date. The on-board device 10 stops the charging session before the shortest authentication expiration date, updates the certificate required for authentication or re-establishes the TLS session, and then starts the charging session again.

[0065] (i) When the authentication deadline (for example, the expiration date of a certificate or the expiration date of a TLS session lifetime) arrives, the in-vehicle device 10 ends the charging session at the timing when the authentication deadline expires.

[0066] (ii) The in-vehicle device 10 attempts to update the certificate from the OEM server 6 or the like, if necessary, at an appropriate timing before the end of the charging session or after the end of the charging session. When the TLS session lifetime expires, there is no need to update the certificate, and the in-vehicle device 10 simply executes a TLS full handshake, starts a new TLS session, and then starts a V2G session.

[0067] (iii) If the vehicle certificate is successfully updated, the in-vehicle device 10 If the Contract certificate is successfully updated, the in-vehicle device 10 may start a new V2G session while maintaining the TLS session, or may start a new V2G session after performing a TLS full handshake.

[0068] 4 is a flowchart illustrating processing after the start of a charging session after a TLS session is established by a TLS full handshake. In this embodiment, the state in which a charging session is established is referred to as a state in which charging is being controlled. In the processing in FIG. 4, the on-board device 10 determines whether any authentication expiration date is before the scheduled vehicle departure time (S1). If the determination in S1 is YES, it means that the expiration date for one or more authentications between the vehicle 1 and the charging equipment 2 will arrive during the control of charging.

[0069] If the determination in S1 is YES, the on-board device 10 determines whether the current time has reached the authentication deadline determined in S1 to be before the scheduled vehicle departure time (S2). If the determination in S2 is NO, the on-board device 10 repeats the process of S2. If the determination in S2 is YES, it can be said that the expiration date for one or more authentications between the vehicle 1 and the charging equipment 2 has arrived.

[0070] If the determination in S2 is YES, the in-vehicle device 10, for example, ends the charging / supply session (S3) and executes a certificate update process or the like (S4). The process in S3 is an example of ending the control of charging / supply. Note that if the authentication deadline is the expiration of the TLS session lifetime, the in-vehicle device 10 performs a TLS full handshake in S4 and ends the TLS session. Therefore, the process of S4 can be said to be an example of a process for updating the upcoming expiration date.

[0071] Furthermore, the certificate update is not limited to being performed after the end of the charging session in S3. That is, the certificate update can be performed regardless of the end of the charging session. For example, the in-vehicle device 10 may update a certificate whose authentication expiration date comes before the scheduled vehicle departure time before the processing in S3.

[0072] After the charging session is ended in S3, the in-vehicle device 10 determines whether the update process is successful (S5). The update is successful in S5 if the certificate update is successful or if the TLS full handshake is successful. If the determination in S5 is YES, the in-vehicle device 10 starts the next charging session (S6). The process in S6 may include three cases.

[0073] The first case is when a new TLS session is started by a TLS full handshake without updating the certificate in the process of S4. If the certificate is not updated in the process of S4, the in-vehicle device 10 may start a new charging session with the existing Contract certificate in the process of S6. If a new TLS session is started by a TLS full handshake, the charging equipment 10 may start a new TLS session with the existing Contract certificate based on a vehicle certificate (Vehicle certificate) for authenticating the vehicle 1. 2. A TLS session can be said to be a communication session in which the security of communication is ensured.

[0074] The second case is when the vehicle certificate is successfully updated in the process of S4. When the vehicle certificate is successfully updated, the on-board device 10 performs TLS full-frame authentication using the updated vehicle certificate. A new TLS session can be started with a handshake, and a new charging session can be started with the existing Contract certificate.

[0075] The third case is when the contract certificate is successfully updated in the process of S4. If the contract certificate is successfully updated, the in-vehicle device 10 starts a new charging / supply session using the updated certificate. In the third case, the TLS session may be continued as is, or a new TLS session may be started by a TLS full handshake. After the process of S6, the in-vehicle device 10 returns the process to S1.

[0076] On the other hand, if it is determined in S5 that the update is not successful, the in-vehicle device 10 executes a fallback process and ends the process (S7). If the certificate update fails, the in-vehicle device 10 uses ISO1 without a Vehicle certificate. 5118-2 standard. Similarly, if the contract certificate update fails, the in-vehicle device 10 can perform authentication and charging using EIM without using the contract certificate. Furthermore, for example, if a user has concluded multiple contracts with MOs and multiple contract agreements are installed in the in-vehicle device 10, the in-vehicle device 10 may start a charging session using another valid contract agreement whose authentication expiration date has not yet arrived.

[0077] Furthermore, if it is determined in S1 that all authentication deadlines are after the scheduled vehicle departure time (NO in S1), the in-vehicle device 10 determines whether the current time has reached the scheduled vehicle departure time (S8). If the determination in S8 is NO, the in-vehicle device 10 repeats the determination in S8 until the current time reaches the scheduled vehicle departure time. On the other hand, if the current time has reached the scheduled vehicle departure time, the in-vehicle device 10 ends the charging session and completes charging (S9).

[0078] 5 and 6 are flowcharts illustrating details of the update process (S4 in FIG. 4). In this process, the on-board device 10 determines, for example, whether or not the contract certificate needs to be updated (S41). A case where the contract certificate needs to be updated is an example where the expiration date of the contract certificate (contract certificate) related to the power charging contract is approaching. Furthermore, a case where the contract certificate needs to be updated in S41 can be said to be an example where the expiration date of the certificate related to power charging is approaching.

[0079] If the Contract certificate needs to be updated, the in-vehicle device 10 determines whether communication with the OEM server 6 is possible (S42). If communication with the OEM server 6 is possible, the in-vehicle device 10 transmits a Contract certificate request to the OEM server 6 (S43).

[0080] The on-board device 10 then determines whether or not the Contract certificate has been successfully received from the OEM server 6 (S44). If the on-board device 10 has successfully received the Contract certificate (YES in S44), the on-board device 10 stores the updated Contract certificate in a non-volatile memory (for example, a non-volatile area of ​​the memory 12 or the external storage unit 13) (S45). The on-board device 10 then proceeds to S47 in FIG. 6, which is connected by symbol A1. The processes from S41 to S45 are an example of updating a certificate whose expiration date is approaching. The processes from S41 to S45 are also an example of updating a contract certificate.

[0081] On the other hand, if the on-board device 10 fails to receive the Contract certificate (NO in S44), it may determine whether to retry updating the Contract certificate (S46). If the on-board device 10 retries, it returns the process to S43. The on-board device 10 may retry, for example, a number of times or for a period of time determined by the system. If the on-board device 10 determines in S41 that updating the Contract certificate is not necessary, if the on-board device 10 is unable to communicate with the OEM server 6 in S42, or if the on-board device 10 does not retry in S46, it moves the process to S47 in FIG. 6 connected by symbol A1.

[0082] The description will be continued below with reference to FIG. 6. That is, the in-vehicle device 10, for example, It is determined whether the vehicle certificate needs to be updated (S47). When the expiration date of the vehicle certificate for authenticating vehicle 1 arrives, This is an example. Also, if you need to update your vehicle certificate in S47, This can be considered an example of when the certificate expires.

[0083] When the vehicle certificate needs to be updated, the in-vehicle device 10 starts communication with the OEM server 6. It is determined whether communication with the OEM server 6 is possible (S48). If communication with the OEM server 6 is possible, the on-board device 10 transmits a Vehicle certificate request to the OEM server 6 (S49).

[0084] Then, the in-vehicle device 10 successfully receives the Vehicle certificate from the OEM server 6. The in-vehicle device 10 determines whether or not the vehicle certificate has been successfully received (S4A). If this is done (YES in S4A), the updated Vehicle certificate is saved in non-volatile memory and Then, the on-board device 10 executes a TLS full handshake (S4B). The processes from S47 to S4B are an example of updating an expiring certificate. The processes from S47 to S4B are an example of updating a vehicle certificate. The process of S4B is an example of executing information exchange to ensure the security of communication with the power charging and supply equipment 2 based on the updated vehicle certificate. Then, the on-board device 10 proceeds to S4D.

[0085] On the other hand, if the in-vehicle device 10 fails to receive the vehicle certificate (NO in S4A), The on-board device 10 may then determine whether to retry updating the Contract certificate (S4C). If a retry is to be made, the on-board device 10 returns the process to S49. If it is determined in S47 that updating the Vehicle certificate is necessary, If communication with the OEM server 6 is not necessary, if communication with the OEM server 6 is not possible in S48, and if a retry is not performed in S4C, the in-vehicle device 10 proceeds to S4D.

[0086] Then, the on-board device 10 determines whether the session lifetime is about to expire (S4D). If the session lifetime is about to expire, this is an example of the expiration date of information for ensuring the security of communication with the charging and supplying facility 2. If the session lifetime is about to expire, the on-board device 10 executes a TLS full handshake (S4E). The processing of S4E is an example of executing information exchange for ensuring the security of communication with the charging and supplying facility 2 based on a vehicle certificate for authenticating the vehicle 1. Note that the expiration date of the vehicle certificate and the expiration date of the session lifetime occur at approximately the same time. In this case, in the processing example of Figure 6, the TLS full handshake is executed in S4B before S4E. As a result, the TLS lifetime is updated, so the result of S4D is NO and the TLS full handshake is not executed in S4E.

[0087] Then, the in-vehicle device 10 (CPU 11) sets a return code and returns to the processing in Fig. 4. For example, if the certificate update is successful and the TLS full handshake is successful, the in-vehicle device 10 sets a normal value to the return code. On the other hand, for example, if the update of any of the certificates fails or the TLS full handshake fails, the in-vehicle device 10 may set a corresponding error value to the return code.

[0088] In addition, the processing of Contract certificates, Vehicle certificates, and TLS security The execution order of the processes for the session lifetime expiration is not limited to the order shown in FIGS. 5 and 6. In short, the on-board device 10 only needs to be able to update the authentication expiration. In other words, the on-board device 10 executes the process for the Vehicle certificate, and then the process for the Contract certificate. Alternatively, the in-vehicle device 10 may first perform processing regarding the expiration of the TLS session lifetimes of S4D and S4E.

[0089] 7 and 8 are sequence diagrams illustrating an example of data exchange between the OEM server 6, the vehicle 1, and the charging facility 2. In the following description, it is assumed that the on-board device 10 executes the processing for the vehicle 1, and the facility control device 20 executes the processing for the charging facility 2. Note that the back-end server 3 may execute at least a part of the processing for the facility control device 20. Also, in FIGS. 7 and 8, the processing when the expiration date of the vehicle certificate is before the scheduled departure time of the vehicle is described. Therefore, if the vehicle certificate is not renewed, the period from the expiration date of the vehicle certificate to the scheduled departure time of the vehicle will be a period during which the authentication of the vehicle 1 has expired.

[0090] The process in FIG. 7 starts when plug 2B of charging equipment 2 is connected to the connection terminal of vehicle 1 (S51). When plug 2B of charging equipment 2 is connected to the connection terminal of vehicle 1, on-board device 10 of vehicle 1 notifies charging equipment 2 of a ClientHello message and starts the first TLS session. In order to establish the connection, a TLS handshake is initiated (S52). During the TLS handshake, the on-board device 10 notifies the power charging equipment 2 of a ClientCertificate message including a Vehicle certificate, and requests authentication of the vehicle 1 by verifying the Vehicle certificate (S53).

[0091] When the verification of the Vehicle certificate is successful and a TLS session is established, the on-board device 10 notifies the power charging facility 2 of a SessionSetupReq message to request the start of a V2G session (power charging session) (S54). The device responds with a message (S55). This starts the charging session. The session ID started here is assumed to be 01, for example. Here, the charging session with session ID=01 can be said to be the first charging session.

[0092] In the charging / supplying session, the on-board device 10 receives a scheduled vehicle departure time from the user (S56). It is determined whether the vehicle departure time is after the expiration date of the vehicle certificate. If the deadline has passed, the in-vehicle device 10 notifies the OEM server 6 of the issuance of the vehicle certificate. (S58).

[0093] Upon receiving the request for issuing a Vehicle certificate, the OEM server 6 issues the Vehicle certificate (S59). The process of FIG. 7 continues to FIG. 8 with symbols B1, C1, and D1. Then, the OEM server 6 notifies the in-vehicle device 10 of the new Vehicle certificate and installs it. (S71 in FIG. 8). As already mentioned, when requesting the issuance of a Vehicle Certificate, However, there is no limitation on the point. After the charging session is ended, the in-vehicle device 10 may request the OEM server 6 to issue a Vehicle certificate. If you can install a new Vehicle certificate before the TLS full handshake begins, good.

[0094] On the other hand, if the scheduled departure time of the vehicle is before the expiration date of the vehicle certificate, The in-vehicle device 10 does not execute the process of S58. Then, the in-vehicle device 10 requests power supply by notifying the equipment control device 20 of a PowerDeliveryReq message (S60). In response to this, the equipment control device 20 replies to the in-vehicle device 10 with a PowerDeliveryRes message (S61) to indicate that power supply is possible.

[0095] In the charging session, the in-vehicle device 10 sends a ChargeLoopReq message to the equipment control device 20. (S62), and the equipment control device 20 sends a ChargeLoopRes message to the in-vehicle device 10. By answering (S63), charging is executed.

[0096] In this example, the current time is the expiration date of the vehicle certificate. The in-vehicle device 10 then notifies the equipment control device 20 of a SessionStopReq message (S64), and the equipment control device 20 responds with a SessionStopRes message to the in-vehicle device 10 (S65), thereby ending the charging / power supply session. The following description will be continued with reference to FIG. 8.

[0097] After the charging session ends, the charging facility 2 and the facility control device 20 may be in a sleep state. When the charging facility 2 and the facility control device 20 are in a sleep state, the in-vehicle device 10 transmits a WAKE UP packet to the facility control device 20, and wakes up the charging facility 2 and the facility control device. The device 20 may then be started (S72).

[0098] When the installation of the vehicle certificate is completed (S71), the expiration date of the vehicle certificate will be after the scheduled departure time of the vehicle. In order to establish the next TLS session, the in-vehicle device 10 performs a TLS full handshake using the newly acquired vehicle certificate (S73, S74) Then, the in-vehicle device 10 starts a new charging session (session ID=02) (S75, S76).

[0099] (Effects of the embodiment) In this embodiment, when the expiration date of one or more authentications between the vehicle 1 and the power charging equipment 2 arrives during the control of power charging, the on-board device 10 ends the control of power charging (power charging session) as shown in S3 of Fig. 4. Then, the on-board device 10 updates the expiration date as shown in S4. Therefore, when the expiration date of a certificate related to power charging or information for ensuring the safety of power charging arrives and a security flaw occurs, the on-board device 10 can improve such a flaw by updating the expiration date.

[0100] Furthermore, when the expiration date of each certificate related to charging arrives during the control of charging, the in-vehicle device 10 ends the control of charging (charging session) as in S3. Then, the in-vehicle device 10 updates the certificate whose expiration date has arrived (S41 to S45 in FIG. 5, S47 to S4B in FIG. 6). Therefore, the in-vehicle device 10 updates the certificate whose expiration date has arrived when the expiration date of each certificate related to charging arrives. If a security flaw occurs, the flaw can be remedied by updating the expiration date.

[0101] Furthermore, the in-vehicle device 10 may obtain a vehicle certificate for authenticating the vehicle 1 during the charge / supply control. If the expiration date is reached, the control of charging (charging session) is terminated as in S3. Then, the in-vehicle device 10 updates the Vehicle certificate (S47 to S4B in FIG. 6) and Based on the vehicle certificate, a full TLS handshake is performed like S4B. That is, the on-vehicle device 10 exchanges information to ensure the security of communication with the charging and power supply facility 2. Then, the on-vehicle device 10 restarts charging and power supply as shown in S6 of FIG. 4. Therefore, the on-vehicle device 10 is notified of the expiration date of the Vehicle certificate and the occurrence of a security flaw. In such cases, such defects can be remedied by updating the vehicle certificate.

[0102] Furthermore, if the expiration date of the Contract certificate related to the power charging contract arrives during the control of power charging, the in-vehicle device 10 ends the control of power charging (power charging session) as in S3. Then, the in-vehicle device 10 updates the Contract certificate to ensure the security of communication with the power charging equipment 2 (S41 to S45 in FIG. 5). Then, the in-vehicle device 10 restarts power charging based on the updated Contract certificate as in S6 in FIG. 4. Therefore, when the expiration date of the Contract certificate arrives and a security defect occurs, the in-vehicle device 10 can improve such a defect by updating the Contract certificate.

[0103] Furthermore, when the TLS session lifetime expires during the control of charging and power supply, the on-board device 10 terminates the control of charging and power supply (charging session) as shown in S3 of Fig. 4. Then, the on-board device 10 establishes a connection between the on-board device 10 and the charging equipment 2 based on a Vehicle certificate for authenticating the vehicle 1. Then, the in-vehicle device 10 executes a TLS full handshake, which is an information exchange for ensuring the security of communication. Then, the in-vehicle device 10 restarts charging and power supply as shown in S6 of Fig. 4. Therefore, when the lifetime of the TLS session expires and a security flaw occurs, the in-vehicle device 10 executes a TLS full handshake and establishes a new TLS session, thereby resolving such a flaw.

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

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

[0106] 1 vehicle 2 Charging power supply equipment 3 Backend Server 5 MO Server 6 OEM Servers 7 Certificate Pool 10 Onboard equipment 11, 21 CPUs 12, 22 memory 13, 23 External memory unit 14 Display section 15 Control section 16A, 26A external communication section 16B, 26B Charging communication section 19 Battery 29 Power supply circuit

Claims

1. An in-vehicle device that communicates with a charging facility that performs charging including at least one of charging a battery of the vehicle from outside the vehicle and supplying power from the battery to outside the vehicle so that a predetermined charge amount is reached by a scheduled departure time of the vehicle, and controls the charging, a controller that, when an expiration date for one or more authentications between the vehicle and the charging equipment arrives during the control of the charging, ends the control of the charging and updates the expiration date. In-vehicle device.

2. 2. The method according to claim 1, wherein, when an expiration date of a certificate related to the power charging arrives during the control of the power charging, the controller terminates the control of the power charging and updates the certificate whose expiration date has arrived. In-vehicle device.

3. 3. The method according to claim 2, wherein, when a vehicle certificate for authenticating the vehicle expires during the control of the power supply, the controller terminates the control of the power supply, updates the vehicle certificate, and performs information exchange to ensure security of communication with the power supply facility based on the updated vehicle certificate, and then restarts the power supply. In-vehicle device.

4. 3. The method according to claim 2, wherein, when an expiration date of a contract certificate related to the contract for the power charging arrives during control of the power charging, the controller terminates control of the power charging, updates the contract certificate while maintaining information for ensuring security of communication with the power charging facility, and restarts the power charging based on the updated contract certificate. In-vehicle device.

5. 2. The method according to claim 1, wherein, when an expiration date of information for ensuring security of communication with the charging facility arrives during control of the charging, the controller terminates the control of the charging, exchanges information for ensuring security of communication with the charging facility based on a vehicle certificate for authenticating the vehicle, and then restarts the charging. In-vehicle device.

6. an on-board device that communicates with a charging facility that performs charging including at least one of charging a battery of the vehicle from outside the vehicle and supplying power from the battery to outside the vehicle so that a predetermined charge amount is reached by a scheduled departure time of the vehicle, and that controls the charging; When an expiration date for one or more authentications between the vehicle and the charging equipment arrives during the control of the charging, the control of the charging is terminated and the expiration date is updated. program.

Images