Apparatus and method for electric vehicle charging mutual authentication

Abstract

The present disclosure provides an apparatus and method for authentication capable of improving security during a secure channel configuration for PnC charging between an electric vehicle (EV) and a charging station (CS). The mutual authentication method includes the steps of: accepting a SECC certificate chain from the CS apparatus, the SECC certificate chain including a SECC certificate and at least one charging device-based sub-certificate for generating the SECC certificate; verifying the SECC certificate by using the at least one charging device-based sub-certificate and a first root certificate stored in a storage of the EV to authenticate the SECC; transmitting a verification result of the SECC certificate to the CS apparatus and providing the CS apparatus with an EV certificate chain including an EV certificate of the EV and at least one EV-based sub-certificate for generating the EV certificate; accepting a verification result of the EV certificate from the CS apparatus and generating a symmetric key through a signal exchange with the CS apparatus; and transmitting or receiving an encrypted message to or from the CS apparatus using the symmetric key.

Description

Technical Field

[0001] This disclosure relates to an apparatus and method for automatically authenticating electric vehicle charging users, and more specifically, to an apparatus and method for automatically authenticating electric vehicle charging users through mutual authentication between the electric vehicle and the charging station. Background Technology

[0002] Electric vehicles (EVs) are powered by battery-powered electric motors and offer advantages over traditional internal combustion engine vehicles, such as reduced emissions and noise, fewer breakdowns, longer lifespan, and simpler operation. An EV charging system can be defined as a system that charges the batteries installed in an EV using electricity obtained from the commercial power grid or stored in energy storage devices. Such EV charging systems can be implemented in various forms. For example, EV charging systems can include conductive charging systems using cables or contactless wireless power transmission systems.

[0003] The charging station begins charging the EV after completing the certification process. However, the certification process varies depending on the EV's charging infrastructure and capabilities. ISO 15118-1, one of the international standards for EV charging, specifies two certification methods: the PnC mechanism, which allows for automatic certification and payment using a contract certificate stored in the EV, and certification using external identification methods (EIM) such as credit cards, debit cards, cash, or smartphone applications. The PnC mechanism refers to a plug-and-charge solution where certification and charging are performed simply by inserting a plug between the EV and the charging station; it also refers to a stop-and-charge solution where certification and charging are performed simply by parking the vehicle above the charging point at the charging station.

[0004] To enable EVs to use the Plug and Charge (PnC) service, EV owners wishing to charge their EVs via PnC must enter into a service agreement with a mobile operator (MO). After the agreement takes effect, a contract certificate is installed in the EV during the initial charge. Subsequently, the EV can receive PnC-based charging services from charging stations associated with the MO. The contract certificate is used to verify the EV owner's identity and provides the charging station operator with the basis for charging fees to be collected from the EV owner.

[0005] An EV waiting to charge from a charging station via the PnC service sends and receives messages after a secure connection is established. The secure connection between the EV and the charging station generally involves two steps. In the first step, the EV authenticates the charging station's trustworthiness based on its certificate. If the EV determines the charging station is trustworthy, a secure connection is established between the EV and the charging station in the second step. Through this secure connection, the EV and the charging station exchange encrypted messages.

[0006] However, in traditional PnC schemes, the EV unilaterally authenticates the charging station's certificate, but the charging station does not verify the EV's identity. If the charging station does not check the EV's identity, devices other than legitimate EVs qualified to use the service could perform illegal attacks such as on-path attacks, spoofing attacks, or credential stuffing to open unauthorized ISO 15118 sessions and extract energy from the charging station. Furthermore, when a charging session between the EV and the charging station is paused, an attacker who knows the session ID of the paused session can hijack the paused session and steal energy from the charging station. Summary of the Invention

[0007] Technical issues

[0008] An authentication device and method are configured to improve security when a secure channel for plug-and-charge (PnC) charging is being established between an electric vehicle and a charging station.

[0009] Technical solution

[0010] A mutual authentication method according to one aspect of this disclosure can be implemented in an electric vehicle (EV) to achieve PnC charging through communication with a charging station (CS) device. The mutual authentication method includes: receiving a Supply Device Communication Controller (SECC) certificate chain from the CS device, the SECC certificate chain including an SECC certificate and at least one charging device series SubCA certificate for issuing the SECC certificate; authenticating the SECC certificate by verifying it using at least one charging device series SubCA certificate and a first RootCA certificate stored in the EV's storage device; sending the authentication result of the SECC certificate to the CS device and providing the CS device with an EV certificate chain including the EV certificate and at least one EV series SubCA certificate for issuing the EV certificate; receiving the authentication result of the EV certificate from the CS device and generating a symmetric key through handshake with the CS device; and sending and receiving messages encrypted with the symmetric key from the CS device.

[0011] Receiving a chain of SECC certificates from a CS device may include providing the CS device with a list of at least some RootCA certificates maintained in the EV. The SECC certificates can be authenticated by using the first RootCA certificate included in the list as a trust anchor.

[0012] At least one EV Series SubCA certificate can be a certificate issued based on the Original Equipment Manufacturer (OEM) RootCA certificate issued by the OEM RootCA.

[0013] The authentication result of the EV certificate can be determined in the CS device by verifying the EV certificate using at least one EV series SubCA certificate along with the V2GRootCA certificate or OEM RootCA certificate stored in the storage device of the CS device.

[0014] According to another aspect of this disclosure, a mutual authentication method can be performed in a charging station (CS) device configured to charge an electric vehicle (EV) to allow PnC charging of the EV. The mutual authentication method includes: providing the EV with a Supply Device Communication Controller (SECC) certificate chain, the SECC certificate chain including an SECC certificate and at least one charging device series SubCA certificate for issuing the SECC certificate; receiving from the EV an authentication result of the SECC certificate and an EV certificate chain including the EV's EV certificate and at least one EV series SubCA certificate for issuing the EV certificate; authenticating the EV by verifying the EV certificate using at least one EV series SubCA certificate and a first RootCA certificate stored in a storage device of the CS device; generating a symmetric key by exchanging signals with the EV; and sending and receiving messages encrypted with the symmetric key from the EV.

[0015] The process of authenticating an EV may include receiving a list of at least some RootCA certificates maintained in the EV. SECC certificates can be authenticated by using the first RootCA certificate included in the list as a trust anchor.

[0016] At least one EV Series SubCA certificate can be a certificate issued based on the Original Equipment Manufacturer (OEM) RootCA certificate issued by the OEM RootCA.

[0017] The SECC certificate can be verified using at least one SubCA certificate from the charging device series and a V2GRootCA certificate stored in the EV's storage device, thereby determining the certification result of the SECC certificate in the EV.

[0018] During EV authentication, the verification of the EV certificate and the mutual authentication between the EV and the CS device are only performed when an EV certificate chain is received from the EV. If no EV certificate chain is received from the EV, EV certificate verification may be skipped; instead, the EV will verify the SECC certificate to enable one-way Transport Layer Security (TLS).

[0019] The mutual authentication method may further include: in response to a service request from an EV after mutual authentication, allowing the authorized EV to request services by skipping EV identification in the application layer based on the result of mutual authentication.

[0020] When no EV certificate chain is received from the EV, communication with the EV can be terminated without generating a symmetric key and without sending messages encrypted with the symmetric key to the EV or receiving messages encrypted with the symmetric key from the EV.

[0021] According to another aspect of this disclosure, a charging station (CS) device provides PnC charging to an electric vehicle (EV) by communicating with the EV. The charging station device includes: a memory storing program instructions; and a processor coupled to the memory and configured to execute the program instructions stored in the memory. When executed by the processor, the program instructions are configured to cause the processor to: provide the EV with a Supply Device Communication Controller (SECC) certificate chain, the SECC certificate chain including an SECC certificate and at least one charging device series SubCA certificate for issuing the SECC certificate; receive from the EV an authentication result of the SECC certificate and an EV certificate chain including the EV certificate and at least one EV series SubCA certificate for issuing the EV certificate, and authenticate the EV certificate by verifying the EV certificate using at least one EV series SubCA certificate and a first RootCA certificate stored in the storage device of the CS device; generate a symmetric key by exchanging signals with the EV; and send and receive messages encrypted with the symmetric key from the EV.

[0022] Program instructions configured to enable the processor to authenticate the EV may include instructions configured to cause the processor to receive a list of at least some RootCA certificates maintained in the EV. SECC certificates can be authenticated by using the first RootCA certificate included in the list as a trust anchor.

[0023] At least one EV Series SubCA certificate can be a certificate issued based on the Original Equipment Manufacturer (OEM) RootCA certificate issued by the OEM RootCA.

[0024] The SECC certificate can be verified in the EV by using at least one SubCA certificate from the charging device series and the V2GRootCA certificate stored in the EV's storage device, thereby determining the verification result of the SECC certificate.

[0025] Program instructions configured to enable the processor to authenticate the EV can further enable the processor to verify the EV certificate and the mutual authentication between the EV and the CS device only when an EV certificate chain is received from the EV. When no EV certificate chain is received from the EV, the program instructions can cause the processor not to perform EV certificate verification, while the EV performs SECC certificate verification so that one-way TLS can be performed.

[0026] The program instructions can be further configured to perform the operation of receiving a contract certificate encrypted using a symmetric key from the EV. In the case of mutual authentication between the EV and the CS device, the program instructions can enable the processor to authorize services requested by the EV based on the result of the mutual authentication. When one-way TLS is performed between the EV and the CS device, the program instructions can enable the processor to authorize services for the EV using the contract certificate.

[0027] The program instructions can be further configured to enable the processor to authenticate the EV, which may include program instructions that enable the processor to: in response to a service request from the EV after mutual authentication, allow the authorized EV to request the service by skipping EV identification in the application layer based on the result of mutual authentication.

[0028] The program instructions can be further configured to cause the processor to terminate communication with the EV if it does not receive the EV certificate chain from the EV, without generating a symmetric key and without sending messages encrypted with the symmetric key to the EV or receiving messages encrypted with the symmetric key from the EV.

[0029] Beneficial effects

[0030] According to embodiments of this disclosure, electric vehicles and charging stations can provide each other with their certificates and verify the certificates received from each other during the establishment of a secure channel for PnC charging, thereby enabling mutual authentication. Accordingly, the security of message exchange between electric vehicles and charging stations can be improved, and any unauthorized access to the charging station can be prevented to prevent energy theft. Attached Figure Description

[0031] Figure 1 This is a block diagram of an electric vehicle (EV) charging infrastructure according to exemplary embodiments of the present disclosure;

[0032] Figure 2 This is an example of a certificate hierarchy applicable to exemplary embodiments of this disclosure;

[0033] Figure 3 yes Figure 1 A block diagram illustrating an embodiment of the EV and charging station;

[0034] Figure 4 yes Figure 1 A block diagram of another embodiment of the EV and charging station shown;

[0035] Figure 5 This is a flowchart illustrating an exemplary embodiment of the communication process between an EV communication controller (EVCC) and a supply device communication controller (SECC) for plug-and-charge (PnC) charging;

[0036] Figure 6This illustrates in detail the establishment according to the first embodiment of the present disclosure. Figure 6 A sequence diagram of the Transport Layer Security (TLS) session establishment process for secure connections in the network;

[0037] Figure 7 The second embodiment of the present disclosure is shown in detail. Figure 6 A sequence diagram of the TLS session establishment process for secure connections;

[0038] Figure 8 This is a flowchart illustrating the differences in the TLS channel establishment process depending on whether the TLS version used to establish a secure channel or whether mutual authentication or bidirectional TLS is mandatory; and

[0039] Figure 9 This is a block diagram illustrating the physical configuration of a charging station according to an exemplary embodiment of the present disclosure. Detailed Implementation

[0040] To better understand the features and advantages of this disclosure, exemplary embodiments of the disclosure will be described in detail with reference to the accompanying drawings. However, it should be understood that this disclosure is not limited to the specific embodiments and includes all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure. In describing each drawing, similar reference numerals are used for similar components.

[0041] The terms used in this specification to describe various components, including ordinal numbers such as "first" and "second," are used to distinguish components from other components but are not intended to limit any particular component. For example, a second component may be referred to as a first component without departing from the scope of this disclosure, and similarly, a first component may be referred to as a second component. The expression "and / or" may be used to refer to a combination of multiple listed items or any one of multiple listed items.

[0042] When a component is referred to as "connected" or "linked" to another component, that component may be logically or physically connected or linked to the other component directly or indirectly through an intervening object. Conversely, when a component is referred to as "directly connected" or "directly linked" to another component, it should be understood that there is no intervening object between these components.

[0043] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that, when used in this specification, the terms “comprising” and / or “including” specifically describe the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0044] Unless otherwise defined, all terms used herein, including technical or scientific terms, shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. Terms such as those defined in common dictionaries shall be interpreted as having a meaning consistent with their meaning in the context of the relevant art and shall not be interpreted as having an ideal or overly formal meaning unless expressly defined in this application.

[0045] The terms used in this disclosure are defined as follows.

[0046] "Electric Vehicle (EV)": As defined in 49 CFR 523.3, an EV is a motor vehicle designed for use on public roads, driven by an electric motor that draws current from an onboard energy storage device such as a battery, which can be charged from an external power source (e.g., a residential or public power service or an onboard fuel-powered generator). An EV can be a four-wheeled or more-wheeled vehicle manufactured for primary use on public streets or roads. EVs can include electric vehicles, electric cars, electric road vehicles (ERVs), plug-in vehicles (PVs), plug-in electric vehicles (xEVs), etc., while xEVs can be further categorized into plug-in fully electric vehicles (BEVs), battery electric vehicles, plug-in electric vehicles (PEVs), hybrid electric vehicles (HEVs), hybrid plug-in electric vehicles (HPEVs), plug-in hybrid electric vehicles (PHEVs), etc.

[0047] "Plug-in Electric Vehicle (PEV)": An electric vehicle that charges its onboard main battery by connecting to the power grid.

[0048] "Wireless power charging system (WCS)": A system for wireless power transmission and control of interactions including alignment and communication operations between grounding components (GA) and vehicle components (VA).

[0049] Wireless power transfer (WPT) is a method of power transfer between power sources such as utilities and power grids and electric vehicles via contactless channels.

[0050] "Utility": A system that supplies electrical energy and includes a Customer Information System (CIS), Advanced Metering Infrastructure (AMI), rate and revenue systems, etc. Utilities can supply energy to EVs according to rate schedules and through intermittent incentives. Furthermore, utilities can provide information related to EV certification, power consumption measurement intervals, and costs.

[0051] "Smart charging": A system in which an electric vehicle power supply device (EVSE) and / or PEV communicates with the power grid to optimize the charging or discharging rate of the EV by taking into account the grid's allowable capacity or electricity costs.

[0052] Interoperability: A state in which components of a system interact with each other to perform the operations that the system is intended to perform. Furthermore, information interoperability can refer to the ability of two or more networks, systems, devices, applications, or components to effectively share and easily use information without inconveniencing users.

[0053] "Inductive charging system": A system that transfers energy from a power source to an EV via two parts separated by a magnetic core transformer, wherein the two halves of the transformer, namely the primary coil and the secondary coil, are physically separated from each other. In this disclosure, the inductive charging system can correspond to an EV power transmission system.

[0054] "Inductive coupling": Magnetic coupling between two coils. One of the two coils can be called the ground component (GA) coil, and the other can be called the vehicle component (VA) coil.

[0055] "Original Equipment Manufacturer (OEM)": A server operated by a manufacturer that manufactures EVs and can be identified by a root certificate authority (RootCA) that issues OEM RootCA certificates.

[0056] "Mobility Operator (MO)": A service provider that enters into service contracts with EV owners related to EV operations such as charging, licensing, and billing, enabling EV drivers to charge their EVs at charging stations.

[0057] “Charging station (CS)”: A facility equipped with one or more electric vehicle power supply units (EVSEs) and that actually charges EVs.

[0058] "Charging point operator (CPO)": An entity that manages electricity to provide requested energy transfer services.

[0059] "Charging station operator (CSO)": An entity that manages electricity to provide requested energy transfer services. The term "charging station operator" can be synonymous with "charging point operator (CPO)."

[0060] A "Charge Service Provider (CSP)" is an entity that manages and authenticates EV user credentials and provides billing and other value-added services to customers. A CSP can be considered a special type of Mobile Operator (MO) and can be integrated with an MO.

[0061] "Clearing House (CH)": An entity that handles cooperation between MOs, CSPs, and CSOs. In particular, the clearing house can act as an intermediary to facilitate the authorization, billing, and settlement processes for EV charging service roaming between two clearing parties.

[0062] "Roaming": Information changes, schemes, and regulations between CSPs that allow EV users to enjoy charging services offered by multiple CSPs or CSOs associated with multiple electronic mobility networks by using a single credential and contract.

[0063] "Credential": A physical or digital asset that represents the identity of an EV or its owner. It may include a password used to verify identity, a public and private key pair used in a public-key cryptographic algorithm, a public key certificate issued by a certificate authority, and information associated with a trusted root certificate authority.

[0064] "Certificate": An electronic document that binds a public key to an ID through digital signature.

[0065] "Service session": A series of services with unique identifiers related to EV charging allocated to a specific customer within a specific time frame, centered around a charging point.

[0066] "Vehicle-to-Grid charging loop" or "V2G charging loop": The message sending and receiving process that controls the charging process according to the ISO 15118 standard.

[0067] "Renegotiation": A message exchange process during a V2G communication session in which parameters are retransmitted between the EV and EVSE to update the charging schedule protocol.

[0068] "e-Mobility Account Identifier (eMAID)": A unique identifier for an EV that links its contract certificate to the EV owner's payment account.

[0069] “V2G Transfer Protocol (V2GTP)”: A communication protocol used to transfer V2G messages between two V2GTP entities.

[0070] “V2GTP entity: A V2G entity that supports the V2G transport protocol.”

[0071] “EVPnC”: The process of identifying and verifying an EV and authorizing its charging by using an EV certificate issued to the EV through the PnC method, and is unrelated to the MO certificate issued in lieu of a contract certificate based on the contract between the EV owner and the MO.

[0072] "Mutual TLS": The process by which an EV and a charging station establish a secure connection session after mutually verifying each other's certificates based on the certificate chains provided by the other party in accordance with this disclosure.

[0073] Exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0074] Figure 1 This is a block diagram of an electric vehicle (EV) charging infrastructure according to exemplary embodiments of the present disclosure, and shows entities related to EV charging. Figure 2 A certificate hierarchy is shown that is applicable to exemplary embodiments of this disclosure.

[0075] Figure 1The EV charging infrastructure that can support charging services for EV 100 includes charging stations (CS) 200, original equipment manufacturer (OEM) servers 300, mobile operator (MO) 310, certificate supply service (CPS) 320, contract certificate pool (CCP) 330, vehicle to grid (V2G) servers 340, charging point operator (CPO) 350, charging service provider (CSP) 360, and clearing house (CH) 370.

[0076] The EV charging infrastructure enables a Vehicle-to-Grid Integration (VGI) system, which not only allows charging of the EV 100's battery with electrical energy supplied from the grid, but also allows supplying the electrical energy stored in the EV 100's battery to the grid, a specific building, or a device electrically connected to the grid. EV users can charge the EV 100 at charging station 200 using the Plug and Charge (PnC) method. During the charging process, the EV 100 and charging station 200 act as primary actors, while OEM servers 300, MO310, CPS 320, CCP 330, and V2G servers 340, CPO 350, CSP 360, and CH 370 can act as secondary actors.

[0077] EV 100 refers to a conventional electric vehicle, including plug-in hybrid electric vehicles (PHEVs), which can be charged at charging station 200 via conductive charging or wireless power transfer. Charging station (CS) 200 actually performs the charging of the EV 100. Charging station 200 may be equipped with one or more EV power supply units (EVSEs), and each EVSE may include at least one conductive charger and / or a wireless charging point that actually transfers power. Charging station 200 can be a dedicated commercial charging area. Furthermore, charging station 200 can be located in various places, such as the parking lot of an EV owner's house, a parking lot allocated for EV charging at a gas station, and the parking lot of a shopping mall or office building. Charging station 200 may also be referred to as a "charging point," "EV charging station," "electric charging point," or "electronic charging station (ECS)."

[0078] Original Equipment Manufacturer (OEM) 300 can refer to an electric vehicle manufacturer or an OEM server used to certify electric vehicles and provide various information. Specifically, regarding certificates, OEM can refer to the OEM Root CA, which issues OEM RootCA certificates.

[0079] The Mobile Operator (MO) 310 is a service provider that contracts with EV owners for services related to EV operation, such as charging, licensing, and billing, enabling EV drivers to charge their EVs at charging station 200. For EV 100 to receive charging services from the current charging station 200, charging station 200 must belong to MO 310 or support roaming scenarios. MO 310 can be operated by, for example, an electricity supplier or electricity wholesaler. MO 310 acts as the RootCA issuing MO RootCA certificates. MO RootCA certificates, as well as MO SubCA certificates issued by MO Sub-Certificates, can be used to issue contract certificates. Additionally, according to this disclosure, MO RootCA certificates and MO SubCA certificates can be used to verify contract certificates installed in EV 100 in both non-roaming and roaming environments. However, alternatively, only the EV certificate can be used without the contract certificate.

[0080] During the installation or renewal of contract certificates in an EV, the Certificate Provisioning Service (CPS) 320 provides clients such as the EV with a chain of contract certificate certificates and cryptographic keys for sending or receiving certificates. The CPS 320 is equipped with leaf-based provisioning certificates and provisioning SubCA certificates such as Prov SubCA1 and Prov SubCA2 certificates. When installing or renewing a contract certificate in an EV 100, the CPS 130 provides the EV with a provisioning service that provides the public key for each MO, the Diffie-Hellman (DH) public key, and the eMAID, as well as the chain of contract certificate certificates. This allows the EV to use this data to verify the chain of contract certificate certificates and to verify the integrity and authenticity of the contract certificate.

[0081] The Contract Certificate Pool (CCP) 330 temporarily stores installation or update response messages during the installation or update of contract certificates in an EV. Given the very short and strict time limits for installation or update settings in the ISO 15118 standard, response messages are pre-stored in the CCP 330 and retained until the installation or update is complete. Since multiple EVs may perform contract certificate installations or updates, response messages are maintained in a directory format after an index is assigned to each message.

[0082] The Vehicle-to-Grid (V2G) server 150 (hereinafter referred to as "V2G") authenticates the identity of each actor in the VGI system and manages all settings and system configurations related to the forward power transfer from the grid to each EV 100 and the reverse power transfer from each EV 100 to the grid. Additionally, considering that power demand and power factor within the grid may fluctuate over time, the V2G 340 performs demand response (DR) operations, i.e., peak reduction operations, and can perform frequency regulation (FR) operations to prevent severe power factor distortion. From the perspective of DR and FR, the V2G 340 can adjust the instantaneous power supply from each power generation company, renewable energy source, and EV 100 on a one-to-one basis, and can monitor the power supply to each consumer. The V2G 340 acts as the highest root CA in the public key infrastructure (PKI) of the EV charging infrastructure. Therefore, the V2G 340 serves as the highest trust anchor, and Figure 1 All actors shown consider V2G RootCA as a trusted actor.

[0083] A Charging Point Operator (CPO) 350 is responsible for the operation of charging stations and the management of electricity to provide requested energy transfer services. For example, a CPO 350 can be operated by a charging station manufacturer or an electricity supplier. Regarding PKI, a CPO 350 can operate CPO SubCAs such as CPO SubCA1 and CPO SubCA2, which are required to issue SECC leaf certificates for each charging station.

[0084] The Charging Service Provider (CSP) 360 manages and authenticates EV user credentials and provides billing and other value-added services to customers. A CSP 360 can be considered a special type of MO 310 and can be implemented as an integration with an MO 310. Multiple CSPs 360s can exist. In this case, each CSP 360 can be associated with one or more CPOs 350s, such that the CSP 360 and one or more CPOs 350s constitute a charging network. EV 100 can receive charging services in a CPO 350 associated with a CSP 360 via a plug-and-charge or stop-and-charge (PnC) method, where the CSP 360 is again associated with an MO 310, which has a contractual relationship with EV 110. However, when EV 100 needs to charge from another CPO 350 not associated with a CSP 360, roaming is required, where the CSP 360 is again associated with an MO 100, which has a contractual relationship with EV 100. Each CSP360 can exchange information with another CSP or CPO 350 belonging to another charging network and can also exchange information with the settlement 370 to enable roaming.

[0085] The Settlement Office (CH) 370 handles the cooperation between MO 300 and CSP 360. In other words, the Settlement Office 370 acts as an intermediary, facilitating the authorization, billing, and settlement processes for EV charging services roaming between the two settlement parties. When an EV owner wishes to charge their EV at a charging station not belonging to the charging network of MO 310, with which they have a contractual relationship, the CH 370 can connect to CPO 350 or CSP 360 to facilitate roaming. In cases requiring roaming, the CH 370 enables CPO 350 or CSP 360 to enter into a contract with MO 310 and transmits authorization data and charging detail records (CDRs) to MO 310. The CH 370 may also be referred to as a "Contract Settlement Office (CCH)," "Mobile Settlement Office (MCH)," "Roaming Platform," or "Electronic Mobile Settlement Office (E-MOCH)."

[0086] While the terms Electric Vehicle Manufacturer (OEM) 300, Mobile Operator (MO) 310, Certificate Supply Service (CPS) 320, Contract Certificate Pool (CCP) 330, Vehicle to Grid (V2G) 340, Charging Point Operator (CPO) 350, Charging Service Provider (CSP) 360, and Contract Clearing House (CH) 370 may appear to refer to individuals or organizations, these terms are used herein in shorthand to enhance the readability of the disclosure provided herein and may be implemented in hardware, software, and / or combinations thereof. In exemplary embodiments, each of these components may be a server device implemented by a combination of hardware and software and may allow access from other devices via a network such as the Internet. Because these components are functionally separate, two or more of them may be stored and executed in a single physical device or may be integrated into a single program. In particular, a single entity may simultaneously act as both a CSO and a CSP, while another entity may simultaneously act as both a CPS and a CCP. On the other hand, one or more components may be rearranged to produce different system configurations and different names.

[0087] On the other hand, EV charging services and related infrastructure exist at the intersection of multiple industrial sectors such as automobiles, power grids, energy, transportation, communications, finance, and electronics. Standardization has been implemented in parallel from multiple perspectives by various international standardization organizations and national standardization organizations, resulting in numerous terms containing similar concepts. Specifically, both Charge Station Operator (CSO) and Charge Point Operator (CPO) can be referred to as Charge Station Operator (CSO). Furthermore, Charge Service Provider (CSP) is at least partially identical to Mobile Operator (MO) in its role and function, and these terms are interchangeable. These considerations will be taken into account when interpreting this specification, including the claims.

[0088] exist Figure 1 In the EV charging infrastructure shown, Public Key Infrastructure (PKI) serves as the foundation for PnC operations. PKI provides a framework for authenticating the identity of individuals and devices, activating secure communications, and ensuring access control to resources. Figure 2 An example of a PKI-based certificate hierarchy applicable to exemplary embodiments of this disclosure is shown.

[0089] Reference Figure 2 OEM 300 acts as the RootCA for issuing OEM RootCA certificates and also operates subordinate certificate authorities, namely OEM SubCA1 and OEM SubCA2. OEM 300 issues OEM SubCA1 certificates by signing the hash of OEM SubCA1's public key with its own private key. OEM SubCA1 issues OEM SubCA2 certificates by signing the hash of OEM SubCA2's public key with its own private key. When the EV is being manufactured, OEM SubCA2 issues an OEM supply certificate by signing the hash of the EV's public key with its own private key, thereby installing the OEM supply certificate in the EV 100. The OEM supply certificate can be used to verify the signature in the certificate installation request message during the EV 100's certificate installation process and can uniquely identify the vehicle throughout the EV 100's lifespan.

[0090] Additionally, OEMs can operate and maintain sub-certification authorities, namely EV SubCA1 and EV SubCA2. OEM 300 issues EV SubCA1 certificates by signing the hash of EV SubCA1's public key with its own private key. EV SubCA1 issues EV SubCA2 certificates by signing the hash of EV SubCA2's public key with EV SubCA1's private key. While the EV is being manufactured, EV SubCA2 issues EV certificates by signing the hash of the EV's public key with EV SubCA2's private key, thus installing the EV certificate in the EV 100.

[0091] As used herein, "EV certificate" can refer to a certificate issued to an electric vehicle regardless of whether it corresponds to a contract certificate issued to an owner who has a contract with the MO. According to this disclosure, EV certificates can be used for mutual authentication during the TLS session establishment process. EV certificates can also be used for SECC or SA identification and authentication of EVs. The process of identifying, authenticating, and authorizing electric vehicles using EV certificates via the PnC method is referred to in this specification as "EVPnC". As described below, when mutual authentication according to this disclosure is performed during the TLS session establishment process, the identification and authentication process at the application layer can be omitted in the EVPnC process according to this disclosure.

[0092] Although the EV Certificate Chain, which includes EV SubCA certificates (i.e., EV SubCA1 and EV SubCA2 certificates), is issued separately from the OEM Supply Certificate Chain, which includes OEM SubCA1, OEM SubCA2, and OEM Supply Certificates, the OEM Supply Certificate Chain can be used as the EV Certificate Chain. In this case, "EV Certificate" in this specification can refer to the OEM Supply Certificate that functions as an EV Certificate.

[0093] MO 310 can also be used as a RootCA to issue MO RootCA certificates. MO 310 can issue MO SubCA1 certificates by adding its signature to the ID, public key, and hash of the public key of MO SubCA1. MO SubCA1 can issue MO SubCA2 certificates by adding its signature to the ID, public key, and hash of the public key of MO SubCA2. When the EV is delivered to the EV owner, MO SubCA2 can issue a contract certificate based on the contract between MO 310 and the EV owner by adding its signature to the ID, public key, and hash of the public key of the EV. This allows the contract certificate to be installed in the EV 100 via the charging station (CS) 200 first accessed by the EV. The contract certificate can be linked to the EV owner's payment account via a unique identifier called an Electronic Mobility Account Identifier (eMAID).

[0094] As described above, in the exemplary embodiments of this disclosure, EV certificates can be used without a contract certificate. In this case, EVPnC can use the EV certificate to perform EV identification, authentication, and service authorization. Specifically, when mutual authentication is performed during TLS session establishment, the identification and authentication process at the application layer can be omitted in the EVPnC process, and service authorization can be performed using contract information with the participation of MO 310 or by using the payment account information of the EV owner maintained by MO 310.

[0095] OEM supply certificates, EV certificates, and contract certificates can be issued based on OEM RootCA certificates and MO RootCA certificates, and can be independent of the global RootCA certificate, i.e., the V2G RootCA certificate. However, as... Figure 2 As shown by the dashed line, OEM supply certificates, EV certificates, and contract certificates can be issued based on V2GRootCA certificates instead of OEM RootCA certificates and MO RootCA certificates.

[0096] V2G 340 enables the issuance of at least two certificate chains: one for CPO 350 and CS 200, and another for providing services.

[0097] First, the V2G 340 can issue a CPO SubCA1 certificate by adding its signature to the ID, public key, and hash of the public key of CPO SubCA1. CPO SubCA1 (or MO SubCA1) can issue a CPO SubCA2 certificate by adding its signature to the ID, public key, and hash of the public key of CPO SubCA2. CPO SubCA2 can issue an SECC leaf certificate by adding its signature to the ID, public key, and hash of the public key of SECC, thus installing the SECC leaf certificate in the CS 200. During TLS communication established between the EV 100 and CS 200, the EV 100 can use the SECC leaf certificate. This certificate is stored in the backend of both the CS 200 and the CSO 350.

[0098] V2G 340 can issue a SubCA1 certificate by adding its signature to the ID, public key, and hash of the public key of SubCA1. SubCA1 can issue a SubCA2 certificate by adding its signature to the ID, public key, and hash of the public key of SubCA2. SubCA2 can issue a leaf certificate by adding its signature to the ID, public key, and hash of the public key of CPS 320, and provide the leaf certificate to CPS 320 for installation in CPS 320.

[0099] On the other hand, each of the RootCAs—V2G RootCA, MO RootCA, and OEM RootCA—can issue and provide Online Certificate Status Protocol (OCSP) certificates, allowing clients to access the OCSP server according to the OCSP protocol to query the certificate status indicating the validity of the certificate and receive the query results. Although in Figure 2As shown, for simplicity, it appears that OCSP certificates are only applicable to CPO SubCAs (i.e., CPO SubCA1 and CPO SubCA2), but all RootCAs can issue OCSP certificates to allow querying the validity of certificates in the certificate chain associated with their RootCA certificates.

[0100] In the exemplary embodiments of this disclosure, certificates are verified or confirmed using one of three generally available methods. First, the certificate recipient can decrypt the message signature in the certificate using the public key in the certificate to recover the hash value, and compare the recovered hash value with the hash value included in the certificate to confirm the integrity of the certificate. Second, the certificate recipient can confirm the integrity and reliability of each certificate in the certificate chain by comparing the owner information of each certificate with the issuer information of its SubCA certificate, sequentially from the RootCA certificate to the leaf certificates. Third, the certificate recipient can confirm the certificate by checking whether it has been revoked using a Certificate Revocation List (CRL) received from the RootCA or by querying the certificate status from the OCSP server associated with the RootCA.

[0101] Figure 3 yes Figure 1 The diagram illustrates an embodiment of an EV and a charging station. The EV and EVSE shown are suitable for a conductive transmission system. The charging station 200 includes at least one EV power supply device (EVSE) 210, and the EV 100 includes an EV unit 110 correspondingly supplied to the EVSE 210 for power transmission. The EVSE 210 can supply DC or AC power to the EV 100 via a conductor, allowing the battery 199 installed in the EV 100 to be charged. The EV unit 110 and the EVSE 210 can be connected via a connector 190.

[0102] The EVSE 210 may include a Supply Equipment Communication Controller (SECC) 220, a power supply side circuit 230, a Power Line Communication (PLC) module 240, a Hardware Security Module (HSM) 270, and a gateway 280. The SECC 220 can be installed not only in a charging station but also outside of the EVSE 210, and one SECC 220 can be configured to control multiple, for example, four EVSE 210s. Figure 3 As shown, for ease of description, one EVSE 210 includes two SECC 220s.

[0103] The SECC 220, acting as an advanced controller, can communicate with the EV Communication Controller (EVCC) 120 in the EV device 110 via power line communication (PLC) or wireless LAN (WLAN). For example, the SECC 220 and EVCC 120 can communicate with each other at the application layer (i.e., at OSI layer 3 and higher) according to ISO 15118-2 or ISO 15118-20 standards. For instance, the physical layer and data link layer between the SECC 220 and EVCC 120 can be configured to conform to the ISO 15118-8 standard. Additionally, the SECC 220 can control the power supply circuit 230 on the power supply side. Furthermore, the SECC 220 can perform EV user authentication and charging fee payment processes via a secondary actor (SA) such as MO 310 over the Internet.

[0104] The power supply circuit 230 can supply power from the grid to EV 100 or supply power from discharging EV 100 to the grid. The power supply circuit 230 may include a power supply electronic circuit 232 and a meter 238. The power supply electronic circuit 232 may include one or more of a converter that adjusts the voltage and / or current levels and a rectifier that converts AC current to DC current. The meter 238 measures the amount of energy supplied to EV 110 through the power supply electronic circuit 232 or the amount of energy supplied in reverse from EV 110 to the power supply electronic circuit 232.

[0105] PLC module 240 can modulate signals transmitted to EV device 110 via power line communication and demodulate signals received from EV device 110 via power line communication. Although Figure 3 Not shown, but EVSE 210 may further include a control pilot transceiver that is capable of sending control signals to EV device 110 and receiving control signals 110 from EV device 110 via a cable connecting EVSE 210 and EV device 110.

[0106] The Hardware Security Module (HSM) 270 can store various security information such as: SECC certificates, public and private keys of SECC 220, keys for symmetric key encryption, other credentials of SECC 220, and OEM RootCA certificates and / or V2G RootCA certificates for verifying EV certificate chains received from EVCC 120.

[0107] Gateway 280 can provide a connection between SECC 220 and secondary actor (SA) 299 via the Internet to enable user authentication and payment processing through communication between SECC 220 and SA 299.

[0108] The EV device 110 may include an EVCC 120, an EV-side power supply circuit 130, a PLC module 140, and a hardware safety module (HSM) 170.

[0109] The EVCC 120, acting as an advanced controller, can communicate with and control the EV-side power supply circuit 130 in the EVSE 210 via power line communication (PLC) or wireless LAN (WLAN). The EV-side power supply circuit 130 can charge the battery 199 used to propel the EV 100 using power received from the EVSE 210, or it can supply energy stored in the battery 199 to the grid via the EVSE 210. The EV-side power electronics circuit 132 in the EV-side power supply circuit 130 may include one or more of a converter that regulates voltage and / or current levels and a rectifier that converts AC current to DC current. The PLC module 140 can modulate signals transmitted to the EVSE 210 via power line communication and demodulate signals received from the EVSE 210 via power line communication.

[0110] The Hardware Security Module (HSM) 170 can store various security information such as: contract certificates, the public and private keys of the EVCC 120, keys for symmetric key encryption, other credentials of the EVCC 120, and V2G RootCA certificates for verifying the SECC certificate chain received from the SECC 220.

[0111] Figure 4 yes Figure 1 A block diagram of another embodiment of the EV and charging station is shown. The EV and EVSE shown are suitable for a wireless power transfer system. Charging station 200 includes at least one EV power supply device (EVSE) 210, and EV 100 includes an EV device 110 correspondingly supplied to EVSE 210 for power transfer. EVSE 210 can supply energy to EV 100 via wireless power transfer so that the battery 199 installed in EV 100 can be charged.

[0112] The EVSE 210 may include a SECC 220, a power supply circuit 230, a point-to-point signal (P2PS) controller 260, a hardware security module 270, and a gateway 280. The SECC 220 can be installed not only in a charging station but also outside of the EVSE 210, and one SECC 220 can be configured to control multiple, for example, four EVSE 210s. Figure 2 As shown, for ease of description, one EVSE 210 includes two SECC 220s.

[0113] The SECC 220, acting as an advanced controller, can communicate with the EVCC 120 in the EV device 110 via a wireless LAN (WLAN). For example, the SECC 220 and EVCC 120 can communicate with each other at the application layer (i.e., at OSI Layer 3 and higher) according to ISO 15118-2 or ISO 15118-20 standards. For instance, the physical and data link layers of the WLAN link can be configured to conform to the ISO 15118-8 standard. Additionally, the SECC 220 can control the power supply circuit 230 and the P2PS controller 260. Furthermore, the SECC 220 can perform EV user authentication and charging fee payment processing via a secondary actor (SA) such as MO 310 over the Internet.

[0114] The power supply circuit 230 can supply power from the grid to EV 100 or supply power from discharging EV 100 to the grid. During the forward power transfer from EVSE 210 to EV 100, the power supply circuit 230 can receive power from the grid, generate magnetic flux, and transfer energy to EV device 110 via magnetic resonance. The power supply circuit 230 may include a power supply circuit 232 for regulating the frequency and voltage and / or current levels, a grounding component (GA) device 236 for generating high-frequency magnetic flux, and a meter 238 for measuring the amount of energy transferred between EVSE 210 and EV device 110.

[0115] The P2PS controller 260 can perform P2PS communication with corresponding components of the EV device 110 under the control of the SECC 220. In the specification of this patent application, including the appended claims, P2PS communication refers to communication that transmits and receives signals for charging using low-frequency (LF) magnetic field signals and / or low-power excitation (LPE) signals.

[0116] The EV device 110 may include an EVCC 120, an EV-side power supply circuit 130, and a hardware safety module 170.

[0117] The EVCC 120, acting as an advanced controller, can communicate with the SECC 220 in the EVSE 210 via wireless LAN. The EVCC 120 can control the EV-side power supply circuit 130 and the P2PS controller 160. Under the control of the EVCC 120, the P2PS controller 160 can perform P2PS communication with the P2PS controller 260 of the EVSE 210 using low-frequency (LF) magnetic field signals and / or low-power excitation (LPE) signals.

[0118] The EV-side power supply circuit 130 can convert magnetic energy received from the EVSE 210 into electrical energy to charge the battery 199, or it can convert the energy stored in the battery 199 into electrical energy to transfer the energy to the EVSE 210 in the form of magnetic energy. During the forward power transfer from the EVSE 210 to the EV 100, the EV-side power supply circuit 130 can receive magnetic energy from the GA 236 of the EVSE 210, convert the received magnetic energy into an induced current, and rectify the induced current into a direct current to charge the battery 199. The EV-side power supply circuit 130 may include a vehicle component (VA) device 136 and an EV-side power electronic circuit 138. The vehicle component (VA) device 136 receives high-level magnetic energy supplied in a magnetic resonance state from the GA device 236 by capturing magnetic flux fluctuations caused by the GA device 236 and converts the magnetic energy into current. The EV-side power electronic circuit 138 rectifies the current.

[0119] The Hardware Security Module (HSM) 170 can store various security information such as: contract certificates, EV certificates, the public and private keys of EVCC 120, keys for symmetric key encryption, other credentials of EVCC 120, and V2G RootCA certificates for verifying the SECC certificate chain received from SECC 220.

[0120] Figure 5 This is a flowchart illustrating an exemplary embodiment of the communication process between EVCC 120 and SECC 220 for PnC charging. Figure 5 The PnC charging process shown is based on ISO 15118-2 and ISO 15118-20 standards.

[0121] First, a communication channel is established between EVCC 120 and SECC 220 (Operation 400). In the communication establishment operation, an IP-based connection is first established between EVCC 120 and SECC 220 (Operation 410), and then a TLS session, i.e. a secure connection, is established between EVCC 120 and SECC 220 (Operation 420).

[0122] During the initial phase of TLS session establishment, EVCC 120 and SECC 220 provide their certificate chains to each other and authenticate each other based on the certificate chains received from each other. Specifically, EVCC 120 receives a SECC certificate chain from SECC 220, including the SECC leaf certificate and CPO SubCA certificates (i.e., CPO SubCA1 and CPO SubCA2 certificates), and uses the CPO subCA certificates along with the V2G RootCA certificate stored in HSM 170 to verify the SECC leaf certificate.

[0123] Similarly, SECC 220 receives an EV certificate chain from EVCC 120, including the EV certificate and EV SubCA certificates, namely EV SubCA1 and EV SubCA2 certificates. SECC 220 reads the trust anchor of the EV subCA certificate from HSM 270, namely the V2GRootCA certificate or the OEM RootCA certificate, and authenticates the EV certificate using the EV subCA certificate and the trust anchor read from HSM 270.

[0124] This mutual authentication between EVCC 120 and SECC 220 can enhance the system's ability to resist external attacks and improve security during the establishment of secure channels.

[0125] When a TLS session is established after mutual authentication, the EVCC 120 and SECC 220 can generate a symmetric key to be used for data encryption during data exchange. That is, the EVCC 120 and SECC 220 exchange messages and data encrypted with the symmetric key during Operations 500-700.

[0126] In Operation 500, the identification, authentication, and authorization of EVCC 100 are performed. Specifically, SECC 200 receives a contract certificate chain from EVCC 100, including the contract certificate and MO subCA certificates, namely MO SubCA1 and MO SubCA2 certificates. SECC 200 reads the trust anchor of the MO subCA certificate, namely the V2G RootCA certificate or the OEM RootCA certificate. SECC 200 uses the EV subCA certificate and the trust anchor read from HSM 270 to verify the EV certificate. Subsequently, SECC 200 provides CSP 360 with the eMAID from the certificate owner identification information in the contract certificate and requests authorization for services for the EV. In response to SECC 200's request, CSP 360 checks the eMAID account status to determine whether the EV's contract is valid enough to provide charging services, and provides SECC 200 with the authorization result based on that determination.

[0127] If authentication and authorization are successfully completed in Operation 500, the target charge level can be determined through communication between EVCC 120 and SECC 220, and a charging plan including a charging profile can be established (Operation 600). SECC 220 controls the charging of the EV, ensuring that charging is performed until the charging termination conditions are met (Operation 700). The charging plan can be adjusted during charging. Examples of charging termination conditions may include completion of the target charge level, a request from EVCC 100, a decision made by SECC 220 due to insufficient power, and a request from a secondary actor. The charging plan can be adjusted based on requests from EV users in the EV, or via secondary actors, or by adjustment request entries from EV users at EVSE 210 (e.g., based on charging mode). SECC 220 may also decide to adjust the charging plan based on information or requests from secondary actors. When power transfer is complete, EVCC 120 may request a receipt from SECC 220, and SECC 220 may respond to the request by providing a receipt indicating the amount of charge.

[0128] Figure 6 This is a detailed illustration of the first embodiment according to the present disclosure. Figure 5 The sequence diagram of the TLS session establishment process in operation 420. Figure 6 The TLS session establishment process shown is a modification of the process specified in the ISO 15118-2 (2014) standard.

[0129] According to the ISO 15118-2 standard, unilateral authentication is used during TLS session establishment. That is, EVCC 120 authenticates SECC 220, but SECC 220 does not authenticate EVCC 120. According to this standard, there are cases where a certificate installed in EV 100 can be used to verify the EV. However, the certificate used for EV authentication is not the EV certificate itself, but a contract certificate. Furthermore, EV authentication is not performed during TLS session establishment, but rather for authorization and payment. In other words, EV 100 is used for identification, authentication, and authorization during Operation 500, not during... Figure 5 During the TLS session establishment process in operation 420, the contract certificate is sent via a PaymentDetailsReq message and the signature is sent via an AuthorizationReq message, and CPO 350 verifies the identity of EV 100. Conversely, according to an exemplary embodiment of this disclosure, the mutual authentication process causes SECC 220 to authenticate the certificate provided by EVCC 120, and EVCC 120 to authenticate the certificate provided by SECC 220. During the establishment of the TLS session for mutual authentication, SECC 220 functions as a TLS server component.

[0130] Reference Figure 6 When sending a ClientHello message, EVCC 120 can provide SECC 220 with a list of V2G RootCA certificate IDs maintained by EVCC 120 (Operation 440). Subsequently, SECC 220 responds to the ClientHello message by sending a ServerHello message and providing EVCC 120 with the SECC leaf certificate chain (Operations 442 and 444). The trust anchors of the CPOSubCA certificates in the SECC leaf certificate chain (i.e., the CPO SubCA1 and CPO SubCA2 certificates) should preferably be included in the V2G RootCA certificate provided by EVCC 120.

[0131] Alternatively, SECC 220 can request a certificate chain from EVCC 120 by sending a CertificateRequest message (Operation 446). In this case, SECC 220 can specify a list of distinguishable names of V2G root certificates and / or OEM root certificates maintained by SECC 220 and available for mutual authentication in the “certificate_authorities” extension of the CertificateRequest message, and can further specify the “SHA256” hash function and ECDSA signature algorithm in the “supported_signature_algorithms” extension, so that EVCC 120 can provide a certificate chain corresponding to the specification in the extension.

[0132] In operation 448, EVCC 120 authenticates SECC 220 using the SECC leaf certificate. That is, EVCC 120 can verify the integrity of the SECC leaf certificate by verifying the public key of CPO SubCA2 included in the CPO SubCA2 certificate, verifying the CPO SubCA2 certificate by verifying the public key of CPO SubCA1 included in the CPOSubCA1 certificate, and verifying the CPO SubCA1 certificate by verifying the public key of V2G 340 included in, for example, the V2G RootCA certificate, which can be a trust anchor of the SECC leaf certificate chain. After verifying the integrity of the SECC leaf certificate, EVCC 120 can send the verification result to SECC 220 (operation 450).

[0133] In response to a request for a certificate chain from SECC 220, EVCC 120 may send an EV certificate chain to SECC 220 (Operation 452). The EV certificate chain may include EV SubCA certificates, namely EV SubCA1 and EV SubCA2. After receiving the EV certificate chain from EVCC 120 in Operation 454, SECC 220 can authenticate EVCC 120 using the EV certificates (Operation 456). That is, SECC 220 can verify the integrity of the EV certificates by verifying the EV certificate with the public key of EV SubCA2 included in the EV SubCA2 certificate, verifying the EV SubCA2 certificate with the public key of EV SubCA1 included in the EV SubCA1 certificate, and verifying the EV SubCA1 certificate with the public key of OEM 300 included in, for example, the OEM RootCA certificate which can be the trust anchor of the EV certificate chain. Therefore, mutual authentication can be completed (Operation 457). On the other hand, if no response is received from EVCC120 in operation 454 or the EV certificate chain is not received normally because the certificate list received from EVCC120 is empty, SECC220 can perform one-way (i.e., one-way) TLS instead of two-way TLS.

[0134] Subsequently, EVCC 120 can generate a random number to send to SECC 220, and SECC 220 can generate a random number to send to EVCC 120. Next, EVCC 120 can generate a random number called a pre-master key (PMS), encrypt the PMS value using the public key of SECC 220 obtained from the SECC leaf certificate, and send the encrypted PMS value to SECC 220. Through the exchange of the random number and the PMS value, EVCC 120 and SECC 220 generate a symmetric key (operation 458). Afterwards, EVCC 120 and SECC 220 perform encrypted communication by encrypting data using the symmetric key (operation 459). Since encrypting and decrypting data using an asymmetric key requires more resources than using a symmetric key, EVCC 120 and SECC 220 use an asymmetric key to encrypt data during the initial authentication process, but use a symmetric key to encrypt data once a secure connection is established.

[0135] On the other hand, Figure 5In the EV identification, authentication, and authorization operation shown (Operation 500), EVCC 120 can provide SECC 220 with payment options available to the EV user via the PaymentServiceSelectionReq() message, and the payment options may include "EVPnC", i.e., PnC using the EV certificate. When the payment option selected by the EV user is EVPnC, EVCC 120 may skip the PaymentDetailsReq message but send an empty AuthorizationReq message. In the cases where (1) the EV certificate provided in the TLS session has not been revoked, (2) a valid contract associated with the EV is found, (3) the contract requesting the service is approved, or (4) authentication is performed on the backend from the connection point to the current time, SECC 220 responds to the AuthorizationReq message by sending an AuthorizationRes message with the parameter set to ResponseCode = 'OK'. Therefore, when a TLS session is established through mutual authentication according to this disclosure, SECC 220 can provide EVPnC as one of the methods for EV identification and authentication. In this case, authentication at the application layer according to the ISO 15118-2 standard may be unnecessary. Alternatively, the services requested by EVCC 120 can be authorized using the results of mutual authentication. In this case, no interaction with EVCC 120 may be required, and the backend may only need confirmation from the MO or CSP. On the other hand, when a TLS session is established via one-way authentication instead of mutual authentication, SECC 220 does not provide EVPnC as one of the methods for EV identification and authentication; therefore, EV identification, authentication, and authorization can be performed through normal PnC procedures.

[0136] If the EV wants to resume a suspended charging session, the EVCC 120 can send the same EV certificate used in the suspended session during TLS establishment. After receiving the SessionSetupReq message from the EVCC 220, the SECC 220 can check whether a pair of session IDs and EV certificates matches the pair used in the suspended session to resume the suspended session. In this case, the remaining communication process can be the same as the process for establishing a new session described above. Alternatively, modifications can be made according to the embodiments. Figure 6 The execution order of operations 442 to 452 in the code.

[0137] Although the ISO 15118-2 standard requires TLS to be used only for PnC, based on current discussions, the upcoming ISO 15118-20 standard is expected to require TLS for all use cases. Furthermore, considering security concerns, it is thought that the future ISO 15118-20 standard may specify support for mutual authentication over TLS. According to this disclosure, EV certificates belonging to the OEM PKI series can be installed in the EV 100 and used for mutual authentication. For this purpose, the EV certificate chain needs to be pre-installed in the EV 100, and the trust anchor of the EV certificate chain needs to be installed in the charging station 200. Alternatively, OEM-supplied certificates can serve as EV certificates to achieve the aforementioned mutual authentication purpose.

[0138] The same principle applies when establishing a secure channel using TLS 1.2 in the ISO 15118-20 standard. Figure 6 The diagram illustrates the TLS session establishment process. On the other hand, when establishing a secure channel using TLS 1.3 in the ISO 15118-20 standard, the TLS session establishment process can generally be similar to that in operation 446, except for the extensions or parameters used in the CertificateRequest message sent by SECC 220 to EVCC 120 when the ServerHello message is sent to EVCC 120. Figure 6 The process is illustrated. That is, SECC 220 can send a CertificateRequest message to EVCC 120 that indicates the signature algorithm in the “signature_algorithms” or “signature_algorithms_cert” extension and indicates a list of distinguishable names of V2G RootCA and / or OEM RootCA in the “certificate_authorities” extension. Figure 7 This illustrates the TLS session establishment process when using TLS 1.3. Figure 7 Other operations shown Figure 6 Similar to what is shown, therefore its description is omitted.

[0139] On the other hand, depending on whether the TLS version used to establish a secure channel or whether mutual TLS is mandatory in the ISO 15118-20 standard or a corresponding future standard, the mutual authentication and TLS channel establishment process may differ slightly. Figure 8 This is a flowchart illustrating the differences in the TLS channel establishment process depending on whether the TLS version used to establish a secure channel or whether mutual authentication and TLS are mandatory.

[0140] If mutual TLS is not mandatory and EVCC 120 sends an empty certificate list, i.e., EVCC 120 does not provide a certificate chain to SECC 120 (operations 480 and 482), then SECC 220 may continue with one-way TLS but without providing EVPNC as an identification method (operation 484). If mutual TLS is not mandatory and EVCC 120 provides an EV certificate chain to SECC 120 (operations 480 and 484), then SECC 220 may verify the certificate chain and may provide EVPnC as an identification method (operation 486).

[0141] On the other hand, if mutual TLS is mandatory and EVCC 120 sends an empty certificate list (operations 480 and 488), then SECC 220 can stop communication (operation 490). If mutual TLS is mandatory and EVCC 120 provides SECC 120 with an EV certificate chain (steps 480 and 488), then SECC 220 can verify the certificate chain and provide EVPnC as an identification method.

[0142] If mutual authentication is completed and EVCC 120 selects EVPnC as the payment option, EVCC 120 can skip the certificate authentication process, and SECC 220 can skip the EV identification and authentication process in the application layer and utilize the result of mutual authentication. If EVCC 120 wants to resume a suspended session, SECC 220 can apply the same mechanism described for the ISO 15118-2 standard.

[0143] Figure 9 This is a block diagram illustrating the physical configuration of a charging station 200 according to an exemplary embodiment of the present disclosure. The charging station 200 may include at least one processor 1020, a memory 1040, a storage device 1060, a communication interface 1080, and a power supply side circuit 230. At least some components of the charging station 200, including the processor 1020 and the memory 1040, can be connected via a bus to exchange data. The charging station 200 may be based on... Figure 2 or Figure 3 The EVSE 210 shown is used for implementation. The processor 1020, memory 1040, and program instructions executed by the processor 1020 can configure the SECC 220 of the EVSE 210.

[0144] Processor 1020 can execute program instructions stored in memory 1040 and / or storage device 1060. Processor 1020 can be at least one central processing unit (CPU), graphics processing unit (GPU), or any other kind of dedicated processor suitable for executing the methods according to this disclosure.

[0145] Memory 1040 may include, for example, volatile memory such as read-only memory (ROM) and non-volatile memory such as random access memory (RAM). Memory 1040 may load program instructions stored in storage device 1060 so that processor 1020 executes the program instructions.

[0146] Storage device 1060 may include an intangible recording medium suitable for storing program instructions and data files. Any device capable of storing data readable by a computer system can be used for this storage device. Examples of storage media may include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical media such as optical disc read-only memory (CD-ROM) and digital video disc (DVD); magneto-optical media such as floppy discs; and semiconductor memories such as ROM, RAM, flash memory, and solid-state drives (SSDs).

[0147] When executed by processor 1020, program instructions may cause processor 1020 to: provide the EV with a Supply Device Communication Controller (SECC) certificate chain, the SECC certificate chain including an SECC certificate and at least one charging device series SubCA certificate for issuing the SECC certificate; receive from the EV a verification result of the SECC certificate and an EV certificate chain including the EV certificate and at least one EV series SubCA certificate for issuing the EV certificate, and authenticate the EV by verifying the EV certificate using at least one EV series SubCA certificate and a first RootCA certificate stored in the storage device of the CS device; generate a symmetric key by exchanging signals with the EV; and send to the EV and receive from the EV messages encrypted with the symmetric key.

[0148] Communication interface 1080 includes Figure 3 or Figure 4 The WLAN interface, PLC module 240, P2PS controller 260, and G / W 280 shown enable the charging station 200 to communicate with external devices. The power supply circuit 230 can supply power from the grid to the EV 100 or supply power from discharging the EV 100 to the grid under the control of program instructions executed by the processor 1020.

[0149] As described above, the apparatus and methods according to exemplary embodiments of this disclosure can be implemented using computer-readable program code or instructions stored on a computer-readable intangible recording medium. The computer-readable recording medium includes all types of recording means for storing data that can be read by a computer system. The computer-readable recording medium can be distributed across computer systems connected via a network, enabling the computer-readable program or code to be stored and executed in a distributed manner.

[0150] Computer-readable recording media can include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Program instructions can include not only machine language code generated by a compiler, but also high-level language code executable by a computer using an interpreter.

[0151] Some aspects of this disclosure described above in the context of a device may indicate a corresponding description of a method according to this disclosure, and blocks or means may correspond to operations or features of the method. Similarly, some aspects described in the context of a method may be expressed by features of their corresponding blocks, items, or means. Some or all of the operations of the method may be performed using hardware means such as a microprocessor, a programmable computer, or electronic circuits. In some exemplary embodiments, one or more of the most important operations of the method may be performed by such means.

[0152] In some exemplary embodiments, a programmable logic device, such as a field-programmable gate array (FPGA), can be used to perform some or all of the functions of the methods described herein. The FPGA can operate in conjunction with a microprocessor to perform one of the methods described herein. Typically, these methods can preferably be performed by a hardware device.

[0153] Although the present disclosure has been described above with reference to exemplary embodiments thereof, it will be apparent to those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the present disclosure as defined by the appended claims.

Claims

1. A mutual authentication method, wherein the mutual authentication method is performed by an electric vehicle (EV) for implementing plug-and-charge (PnC) charging of the EV through communication with a charging station device (CS device), the method comprising: During the establishment of a Transport Layer Security (TLS) session, the CS device receives a supply device communication controller SECC certificate chain, which includes SECC certificates. SECC is authenticated by verifying the SECC certificate using at least one SubCA certificate from the charging device series and the first RootCA certificate stored in the storage device of the EV; The CS device is provided with an EV certificate chain including the EV certificate of the EV, so that the CS device can authenticate the EV by verifying the EV certificate during the establishment of the TLS session, thereby achieving mutual authentication with the CS device during the establishment of the TLS session based on the authentication result of the EV certificate in the CS device and the authentication result of the SECC certificate in the EV. as well as Following the mutual authentication, in response to a service request from the EV, authorization for the requested service is granted at the application layer based on the mutual authentication established during the TLS session establishment. Based on mutual authentication during the establishment of the TLS session, it is possible to skip one or more of the EV identification or EV authentication in the application layer.

2. The mutual authentication method according to claim 1, wherein receiving the SECC certificate chain from the CS device comprises: Provide the CS device with a list of at least some RootCA certificates maintained in the EV. The SECC certificate is authenticated by using the first RootCA certificate included in the list as a trust anchor.

3. The mutual authentication method according to claim 1, wherein the EV certificate chain further includes at least one EV series SubCA certificate, the at least one EV series SubCA certificate being issued based on an OEMRootCA certificate issued by the original equipment manufacturer (OEM) RootCA.

4. The mutual authentication method according to claim 3, wherein the verification result of the EV certificate is determined in the CS device by verifying the EV certificate using the at least one EV series SubCA certificate together with the V2G RootCA certificate or the OEM RootCA certificate stored in the storage device of the CS device.

5. A mutual authentication method, said mutual authentication method being executed by a charging station device, i.e., a CS device, for allowing plug-and-charge (PnC) charging of an electric vehicle, i.e., an EV, through communication with said CS device, said method comprising: Provide the EV with a chain of SECC certificates including the supply device communication controller SECC certificate to allow the EV to authenticate the SECC certificate during transport layer security (TLS) session establishment by verifying the SECC certificate using the at least one charging device series SubCA certificate and the first RootCA certificate stored in the EV's storage device; The system receives an EV certificate chain including the EV certificate of the EV and authenticates the EV by verifying the EV certificate during the establishment of the TLS session, thereby achieving mutual authentication with the EV during the establishment of the TLS session based on the authentication result of the EV certificate in the CS device and the authentication result of the SECC certificate in the EV. as well as Following the mutual authentication, in response to a service request from the EV, the service requested by the EV is authorized at the application layer based on the mutual authentication during the TLS session establishment. Based on mutual authentication during the establishment of the TLS session, it is possible to skip one or more of the EV identification or EV authentication in the application layer.

6. The mutual authentication method according to claim 5, wherein authenticating the EV comprises: Receive a list of at least some RootCA certificates maintained in the EV. The SECC certificate is authenticated by using the first RootCA certificate included in the list as a trust anchor.

7. The mutual authentication method of claim 5, wherein the EV certificate chain further comprises at least one EV series SubCA certificate, the at least one EV series SubCA certificate being issued based on an OEMRootCA certificate issued by the original equipment manufacturer (OEM) RootCA.

8. The mutual authentication method according to claim 7, wherein the verification result of the SECC certificate is determined in the EV by verifying the SECC certificate using the at least one charging device series SubCA certificate and the V2G RootCA certificate stored in the storage device of the EV.

9. The mutual authentication method according to claim 5, wherein, During the EV authentication process, the verification of the EV certificate and the mutual authentication between the EV and the CS device are performed only when the EV certificate chain is received from the EV. Specifically, when the EV certificate chain is not received from the EV, the verification of the EV certificate is not performed, and the EV performs the verification of the SECC certificate to perform one-way TLS.

10. The mutual authentication method according to claim 9, wherein, If the EV certificate chain is not received from the EV, communication with the EV is terminated without generating a symmetric key, and no messages encrypted with the symmetric key are sent to or received from the EV.

11. A charging station device, wherein the charging station device is a CS device, the CS device being configured to provide PnC charging to an electric vehicle, i.e., an EV, via communication, the CS device comprising: Memory, which stores program instructions; and a processor, connected to the memory and configured to execute program instructions stored in the memory. The program instructions, when executed by the processor, are configured to cause the processor to: Provide the EV with a chain of SECC certificates including the supply device communication controller SECC certificate to allow the EV to authenticate the SECC certificate during the establishment of a Transport Layer Security (TLS) session by verifying the SECC certificate using the at least one charging device series SubCA certificate and the first RootCA certificate stored in the EV's storage device; The system receives an EV certificate chain including the EV certificate of the EV and authenticates the EV by verifying the EV certificate during the establishment of the TLS session, thereby achieving mutual authentication with the EV during the establishment of the TLS session based on the authentication result of the EV certificate in the CS device and the authentication result of the SECC certificate in the EV. as well as Following the mutual authentication, in response to a service request from the EV, the application layer authorizes the service requested by the EV based on the mutual authentication established during the TLS session establishment. Based on mutual authentication during the establishment of the TLS session, it is possible to skip one or more of the EV identification or EV authentication in the application layer.

12. The charging station apparatus of claim 11, wherein the program instructions configured to cause the processor to authenticate the EV include: Instructions configured to cause the processor to perform the following operations: Receive a list of at least some RootCA certificates maintained in the EV. The SECC certificate is authenticated by using the first RootCA certificate included in the list as a trust anchor.

13. The charging station apparatus of claim 11, wherein the EV certificate chain further comprises at least one EV series SubCA certificate, the at least one EV series SubCA certificate being issued based on an OEMRootCA certificate issued by the original equipment manufacturer (OEM) RootCA.

14. The charging station apparatus of claim 13, wherein the verification result of the SECC certificate is determined in the EV by verifying the SECC certificate using the at least one charging device series SubCA certificate and a V2G RootCA certificate stored in the storage device of the EV.

15. The charging station apparatus of claim 11, wherein the program instructions are further configured to cause the processor to: If the EV certificate chain is not received from the EV, communication with the EV is terminated, and no symmetric key is generated, nor are messages encrypted with the symmetric key sent to or received from the EV.

Images