[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2021158021A1 - 전기차에 대한 계약 인증서 설치 지원 방법 및 장치 - Google Patents

전기차에 대한 계약 인증서 설치 지원 방법 및 장치 Download PDF

Info

Publication number
WO2021158021A1
WO2021158021A1 PCT/KR2021/001437 KR2021001437W WO2021158021A1 WO 2021158021 A1 WO2021158021 A1 WO 2021158021A1 KR 2021001437 W KR2021001437 W KR 2021001437W WO 2021158021 A1 WO2021158021 A1 WO 2021158021A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
contract
csp
external
contract certificate
Prior art date
Application number
PCT/KR2021/001437
Other languages
English (en)
French (fr)
Inventor
신민호
Original Assignee
현대자동차주식회사
기아 주식회사
명지대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 현대자동차주식회사, 기아 주식회사, 명지대학교 산학협력단 filed Critical 현대자동차주식회사
Priority to JP2022548200A priority Critical patent/JP7527383B2/ja
Priority to EP21751245.8A priority patent/EP4102769A4/en
Priority to US17/797,591 priority patent/US20230057752A1/en
Priority to CN202180013401.9A priority patent/CN115088230A/zh
Publication of WO2021158021A1 publication Critical patent/WO2021158021A1/ko
Priority to JP2024025744A priority patent/JP2024059807A/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/66—Data transfer between charging stations and vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/62—Monitoring or controlling charging stations in response to charging parameters, e.g. current, voltage or electrical charge
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/63—Monitoring or controlling charging stations in response to network capacity
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/65—Monitoring or controlling charging stations involving identification of vehicles or their battery types
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/66—Data transfer between charging stations and vehicles
    • B60L53/665—Methods related to measuring, billing or payment
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/67—Controlling two or more charging stations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G06Q30/0185—Product, service or business identity fraud
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/06—Energy or water supply
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60Y—INDEXING SCHEME RELATING TO ASPECTS CROSS-CUTTING VEHICLE TECHNOLOGY
    • B60Y2200/00—Type of vehicle
    • B60Y2200/90—Vehicles comprising electric prime movers
    • B60Y2200/91—Electric vehicles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/70—Energy storage systems for electromobility, e.g. batteries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/7072—Electromobility specific charging systems or methods for batteries, ultracapacitors, supercapacitors or double-layer capacitors
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/12—Electric charging stations
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/16—Information or communication technologies improving the operation of electric vehicles

Definitions

  • the present invention relates to a method for charging an electric vehicle and an apparatus therefor.
  • the present invention relates to a method and apparatus for installing a public key certificate in an electric vehicle so as to respond to a roaming environment in a PnC charging infrastructure.
  • An electric vehicle (EV: Electric Vehicle, hereinafter abbreviated as 'electric vehicle') operates by driving a motor with the power of a battery. , long life, and simple operation and operation.
  • An electric vehicle charging system may be defined as a system that charges a battery mounted in an electric vehicle using power from a commercial power grid or an energy storage device.
  • Such an electric vehicle charging system may be implemented in various forms, and may include, for example, a conductive charging system using a cable or a non-contact wireless power transmission system.
  • the charging station starts charging after going through a certain approval process for the EV.
  • the approval process differs depending on the charging infrastructure and EV functions.
  • ISO 15118-1 one of the international standards for electric vehicle charging, has two approval methods: the PnC method, in which approval and payment are automatically completed using the contract certificate stored in the EV; and credit card, debit card, cash, smart It stipulates the method of identification, approval, and payment by external identification means (EIM: External Identification Means) such as a phone app.
  • EIM External Identification Means
  • the PnC method refers to a plug-and-charge method in which service approval and charging are performed by simply inserting a plug between the EV and the charging station. It refers to a park-and-charge method in which service approval and charging are performed by simply parking.
  • the EV owner In order for an EV to use the PnC service, the EV owner must conclude a service use contract with an MO (Mobility Operator). After signing the contract, the contract certificate is installed on the EV at the time of initial charging, and thereafter, PnC service can be received at the charging station associated with the MO. If an EV wants to receive PnC service from a charging station associated with an MO that has no contractual relationship, roaming may occur. As long as the EV has a valid contract certificate already installed, EV owners will not have much difficulty using the charging service even in a roaming environment.
  • MO Mobility Operator
  • PnC may not work. Such a situation may occur, for example, when the first charging station visited by the EV after shipment is a charging station belonging to the network of the MO to which the EV has no contractual relationship.
  • the contract certificate installed in the EV cannot operate effectively for some reason, the contract certificate must be updated.
  • the installation or update of the contract certificate is required in the roaming environment, but it can be said that there is no countermeasure for this in the prior art. Therefore, when the PnC does not work as described above, the EV driver has to pay a fee by an external identification means (EIM), which is cumbersome and inconvenient for the EV driver.
  • EIM external identification means
  • the CSO or the charging service provider (CSP) verifies the contract certificate chain submitted by the EV to the charging station operator (CSO) through the charging station.
  • the MO root certificate (MO RootCA cert.) which is the highest certificate in the contract certificate chain, is not installed in the EV (based on ISO 15118-20 standard 2018. 7. 2. can't submit In this case, if the visiting CSO or visiting CSP also does not have this route accreditation certificate, since verification is only possible at the home CSP or a separate clearing house, it may cause delay in approval.
  • the present invention provides a method and apparatus for enabling installation or updating of a contract certificate even when an electric vehicle is in a roaming environment, and allowing approval for PnC charging to be made accurately and quickly.
  • a method for supporting installation of a contract certificate in a charging service providing device includes: generating a first contract certificate for a first electric vehicle (EV); By transmitting the first contract certificate to a first external charging service providing device (CSP) in which a roaming contract is formed, the first contract certificate can be installed in the first EV through the first external CSP in a roaming situation Including;
  • the first external CSP may include all external CSPs for which a roaming contract is established with the charging service providing device.
  • the first external CSP may include all external CSPs.
  • the contract certificate installation support method waits for installation in the first external CSP It may further include; transmitting a release request.
  • Transmitting the first contract certificate to the first external CSP may include: forming a contract certificate chain including the first contract certificate and a certificate installation package including eMAID information; transmitting the certificate installation package to the first CSP.
  • the certificate installation package may include a certificate revocation list associated with the first contract certificate and access information of an online certificate status protocol (OCSP) server.
  • OCSP online certificate status protocol
  • the contract certificate installation support method includes: receiving a second contract certificate for a second EV from a second external CSP, and transmitting and storing the second contract certificate to a certificate provisioning service device (CPS);
  • CPS certificate provisioning service device
  • a contract certificate installation request is received from the second EV in a roaming situation where the second EV enters the service network, the second contract certificate stored in the CPS is transmitted to the second EV and installed in the second EV It may further include;
  • the second external CSP may be any one of all external CSPs for which the roaming contract with the charging service providing device is established.
  • the step of causing the second contract certificate to be transmitted to the second EV to be installed in the second EV may include: notifying the second external CSP of completion of installation after the second contract certificate is installed in the second EV; may further include.
  • an apparatus for providing a charging service that can be utilized for a charging service using a PnC method.
  • the charging service providing device includes a processor; and a memory for storing at least one instruction executable by the processor.
  • the at least one command generates a first contract certificate for a first electric vehicle (EV) and transmits the first contract certificate to a first external charging service providing device (CSP), through the first external CSP 1 instruction to enable a contract certificate to be installed in the first EV; instructions for accepting the second contract certificate for the second EV from the second external CSP, and delivering and storing the second contract certificate to the certificate provisioning service device (CPS); and when a contract certificate installation request is received from the second EV in a roaming situation where the second EV enters the service network, the second contract certificate stored in the CPS is transmitted to the second EV to be transmitted to the second EV. command to be installed; includes.
  • the first external CSP may include all external CSPs that have a roaming contract with the charging service providing device, and the second external CSP includes all of the external CSPs that have a roaming contract with the charging service providing device.
  • the first external CSP may include all external CSPs that have a roaming contract with the charging service providing device
  • the second external CSP includes all of the external CSPs that have a roaming contract with the charging service providing device.
  • the first external CSP may include all external CSPs, and the second external CSP may be any one of all external CSPs.
  • the command for transmitting the first contract certificate to the first external CSP is when a predetermined period elapses after transmitting the first contract certificate to the first external CSP or when the first contract certificate is installed in the first EV , a command to transmit a request to release the installation standby to the first external CSP; may include.
  • the command to cause the second contract certificate to be transmitted to the second EV to be installed in the second EV is a command to notify the completion of installation to the second external CSP after the second contract certificate is installed in the second EV ; may be included.
  • Transmitting the first contract certificate to the first external CSP may include: forming a contract certificate chain including the first contract certificate and a certificate installation package including eMAID information; transmitting the certificate installation package to the first CSP.
  • the certificate installation package may include a certificate revocation list associated with the first contract certificate and access information of an online certificate status protocol (OCSP) server.
  • OCSP online certificate status protocol
  • a PnC (PnC) method EV charging approval method in a roaming environment is provided.
  • the EV charging approval method generates a first contract certificate for a first electric vehicle (EV), transmits the first contract certificate to a first external charging service providing device (CSP), and through the first external CSP 1 enabling a contract certificate to be installed in the first EV; accepting a second contract certificate for the second EV from a second external CSP, and transmitting and storing the second contract certificate to a certificate provisioning service device (CPS);
  • CPS certificate provisioning service device
  • the second external CSP may be any one of all external CSPs for which a roaming contract is established with the charging service providing device.
  • the step of causing the second contract certificate to be transmitted to the second EV to be installed in the second EV is a command of notifying the second external CSP of installation completion after the second contract certificate is installed in the second EV ; may be included.
  • the step of receiving and storing the second contract certificate from the second external CSP may include receiving and storing a contract certificate chain including the second contract certificate and a certificate installation package including eMAID information.
  • the home charging service provider pre-distributes the contract certificate for the EV to substantially all CSPs, so that the EV can be installed in a roaming environment. Even when a certificate installation request or update request is made, the visiting CSP immediately provides the contract certificate to the EV so that it can be installed. Therefore, even in a roaming environment, it is possible to install or update the contract certificate chain on the EV, PnC charging of the EV can be smoothed, and the convenience of EV users can be improved.
  • FIG. 1 is a conceptual diagram for explaining an electric vehicle wired charging method to which an embodiment of the present invention can be applied.
  • FIG. 2 is a conceptual diagram for explaining wireless power transmission for an electric vehicle to which an embodiment of the present invention can be applied.
  • FIG. 3 is a block diagram of an EV charging infrastructure according to an embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an example of a certificate hierarchy applied to an embodiment of the present invention.
  • FIG. 5 is a diagram exemplarily showing nodes constituting a PnC charging infrastructure in order to describe a roaming service for an EV.
  • FIG. 6 is a diagram illustrating examples of situations in which roaming is not required and situations in which roaming is required.
  • FIG. 7 is a flowchart illustrating a general service approval process according to a contract in a situation where roaming is not required.
  • FIG. 8 is a flowchart illustrating a general service approval process according to a contract in a situation in which direct roaming is performed.
  • FIG. 9 is a flowchart illustrating a general service approval process according to a contract in a situation in which indirect roaming is performed.
  • FIG. 10 is a flowchart illustrating a general service approval process according to a contract in a situation where on-the-fly direct roaming is performed.
  • 11 is a flowchart illustrating a general service approval process according to a contract in a situation where on-the-fly indirect roaming is performed.
  • FIG. 12 is a diagram showing a delivery path of a contract certificate delivered and installed from a home CSP to an EV through direct roaming according to an embodiment of the present invention.
  • FIG. 13 is a flowchart illustrating in more detail the certificate delivery process shown in FIG. 12 .
  • FIG. 14 is a diagram illustrating a transmission path of a contract certificate that is transmitted and installed from a home CSP to an EV through indirect roaming according to an embodiment of the present invention.
  • 15 is a flowchart illustrating in more detail the certificate delivery process shown in FIG. 14 .
  • 16 is a flowchart illustrating a service approval process according to a contract according to another embodiment of the present invention.
  • FIG. 17 is a block diagram of a CSP according to an embodiment of the present invention.
  • first, second, A, and B may be used to describe various elements, but the elements should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, a second component may also be referred to as a first component.
  • the term “and/or” includes a combination of a plurality of related listed items or any of a plurality of related listed items.
  • Electric vehicle may refer to an automobile defined in 49 CFR (code of federal regulations) 523.3 and the like. Electric vehicles can be used on highways and can be powered by electricity supplied from an on-board energy storage device, such as a rechargeable battery, from a power source external to the vehicle. Power sources may include residential or public electric services or generators using on-board fuel.
  • An electric vehicle (EV) may be referred to as an electric car, an electric automobile, an electric road vehicle (ERV), a plug-in vehicle (PV), a plug-in vehicle (xEV), etc.
  • BEV plug-in all-electric vehicle or battery electric vehicle
  • PEV plug-in electric vehicle
  • HEV low-voltage vehicle
  • HPEV high-voltage plug-in electric vehicle
  • PHEV plug-in hybrid electric vehicle
  • a 'Plug-in Electric Vehicle (PEV)' may refer to an electric vehicle that is connected to a power grid to recharge a vehicle-mounted primary battery.
  • WCS Wireless power charging system
  • WPT Wireless power transfer
  • AC alternating current
  • 'Utility' is a system that provides electrical energy and usually includes Customer Information System (CIS), Advanced Metering Infrastructure (AMI), Rates and Revenue system, etc. may be referred to as a set of Utilities make energy available to plug-in electric vehicles through price tags or discrete events.
  • utilities can provide information on tariff rates, intervals for metered power consumption, and validation of EV programs for plug-in EVs.
  • Smart charging' may refer to a system in which the EVSE and/or plug-in electric vehicle optimizes the vehicle charge or discharge rate over time of the grid capacity or cost-of-use ratio while communicating with the power grid.
  • Interoperability' may refer to a state in which components of a system relative to each other can work together to perform a desired operation of the entire system.
  • Information interoperability may refer to the ability of two or more networks, systems, devices, applications or components to share and easily use information safely and effectively with little or no inconvenience to a user. .
  • An 'inductive charging system' may refer to a system that electromagnetically transfers energy in a forward direction from an electricity supply network to an electric vehicle through a transformer in which two parts are loosely coupled.
  • the inductive charging system may correspond to an electric vehicle charging system.
  • 'Inductive coupling' may refer to magnetic coupling between two coils.
  • the two coils may refer to a ground assembly coil and a vehicle assembly coil.
  • OEM 'Original Equipment Manufacturer
  • CA top-level certification authority
  • a 'Mobility operator (MO)' may refer to a service provider that has a contractual relationship with an EV owner regarding charging, authorization, and payment so that EV drivers can charge their EVs at a charging station.
  • a 'Charging station (CS)' may refer to a facility that has one or more EV power supplies and actually performs charging for EVs.
  • CSO Charge station operator
  • CPO charge point operator
  • CSP Charge service provider
  • CH Clearing house
  • 'Roaming' refers to information exchange and related matters that allow EV users to access charging services provided by multiple CSPs or CSOs belonging to multiple mobility networks, using one credential and contract. It can refer to (provision) and scheme (scheme).
  • a 'credential' is a physical or digital asset that represents the personal information of an EV or EV owner.
  • Password which is cryptographic information used to verify identity, a public key/private key pair used in a public key encryption algorithm, It may include a public key certificate issued by a certification authority, information related to a trusted root certification authority, and the like.
  • a 'Certificate' may refer to an electronic document that binds a public key to an ID by a digital signature.
  • a 'service session' may refer to a set of services related to charging an electric vehicle at a charging point, assigned to a customer in a certain timeframe with a unique identifier.
  • An 'e-Mobility Account Identifier (eMAID)' may refer to an EV unique identifier that links a contract certificate to an EV owner's payment account.
  • an electric vehicle is connected to a charging station through a wired or wireless link, receives energy from the charging station, and charges an energy storage device such as a battery with the supplied energy.
  • an energy storage device such as a battery with the supplied energy.
  • Electric vehicle wired charging connects the electric vehicle 10 (hereinafter referred to as 'EV') to the power supply circuit of the charging station by the charging cable 30 , for example, by connecting the cable connector of the charging station 20 to the jack of the EV 10 . By connecting, it can be done.
  • 'EV' electric vehicle 10
  • the EV 10 may be defined as a vehicle that supplies power supplied from a rechargeable energy storage device, such as a battery, as an energy source of an electric motor, which is a power device.
  • the EV 10 may be a hybrid vehicle having both an electric motor and a general internal combustion engine, and may be a motorcycle, a cart, a scooter, and an electric bicycle as well as an automobile. may be
  • the EV 10 may include a plug connection or receptacle that may be connected to a connector of the charging cable 30 .
  • the plug connector provided in the EV 10 may support slow charging or support fast charging.
  • the EV 10 may support both slow charging and fast charging through one plug connection port, or may include a plurality of plug connection ports each supporting slow charging and fast charging.
  • the EV 10 may include an on-board charger to support slow charging or charging through AC power supplied from a general power system.
  • the on-board charger may boost the AC power supplied from the outside through a wire during slow charging, convert it into DC power, and supply it to the battery built into the EV 10 .
  • the DC power may be supplied to the battery to be charged without going through the on-board charger.
  • the EV charging cable 30 may include at least one of a charging connector 31 , an outlet socket connection part 33 , and an in-cable control box (ICCB) 32 .
  • the charging connector 31 may be a connection that can be electrically connected to the EV 10
  • the in-cable control box 32 communicates with the EV 10 to receive status information of the EV or charge power to the EV 10 . can be controlled.
  • the in-cable control box 32 is illustrated as being included in the EV charging cable 10, a power supply circuit (not shown) for supplying power to the EV 10 at a place other than the EV charging cable 10, for example, a charging station. ) or disposed within the power supply circuit.
  • the outlet socket connection part 33 may be connected to a charging device of a charging station as an electrical connection device such as a general plug or a cord set.
  • the power socket 40 refers to a connection point between the charging device of the charging station and the charging connector 31 .
  • the present invention is not limited thereto, and the power socket 40 may refer to a connection point between a charging device installed in another location and the charging connector 31 .
  • the power socket 40 is located in a parking lot attached to the owner's home of the EV 10, a parking area allocated for EV charging at a gas station, a parking area at a shopping center or workplace, etc. It may also indicate an installed wall jack.
  • FIG. 2 is a conceptual diagram for explaining wireless power transmission for an electric vehicle to which an embodiment of the present invention can be applied.
  • Wireless power transfer (WPT) for an EV can be defined as the transfer of electrical energy from a supply network from a supplier-side device to a consumer-side device through a magnetic field in magnetic resonance without the flow of current through a galvanic connection. .
  • the wireless power transmission may be utilized to charge the EV 10 by transmitting power from a charging station 10 to the EV 10 .
  • wireless power transmission may be performed by at least one component of the EV 10 and the charging station 20 in order to wirelessly transmit power to the EV 10 .
  • the EV 10 may include a receiving pad 11 having a receiving coil for wirelessly receiving magnetic energy from the charging station 20 .
  • the receiving coil at the receiving pad 11 receives magnetic energy from the transmitting coil of the transmitting pad 21 at the charging station 20 , for example by magnetic resonance.
  • the magnetic energy received from the EV 10 is converted into an induced current, and the induced current is rectified into a DC current to charge the battery 12 .
  • the charging station 20 may receive power from a commercial power grid 50 or a power backbone, and may supply energy to the EV 10 through the transmission pad 21 .
  • the transmitting pad 21 has a transmitting coil.
  • the transmitting coil in the transmitting pad 21 may generate a magnetic flux and supply magnetic energy amplified by magnetic resonance to the EV 10 .
  • the charging station 20 may be located in various places such as, for example, a parking lot attached to the owner's house of the EV 10 , a parking area for charging the EV at a gas station, a parking area of a shopping center or a business building, and the like.
  • the charging station 20 may communicate with a power infrastructure management system or an infrastructure server that manages the power grid 50 through wired/wireless communication. Also, the charging station 20 may perform wireless communication with the EV 10 .
  • the wireless communication may include a wireless LAN (WLAN) based on Wi-Fi according to the IEEE 802.11 protocol, and a low frequency (LF) magnetic field signal and/or low power magnetic field (LPE: Low Power Excitation) signal. It may further include P2PS communication using a signal.
  • wireless communication between the charging station 20 and the EV 10 may include one or more of various communication methods such as Bluetooth, Zigbee, and cellular.
  • a communication standard document for charging electric vehicles, EVs and EV charging stations control the entire charging process by exchanging messages. That is, communication for charging an electric vehicle may be performed between a vehicle-side communication controller (EVCC) and a power supply-side communication controller (SECC) through a wireless LAN (WLAN).
  • EVCC vehicle-side communication controller
  • SECC power supply-side communication controller
  • WLAN wireless LAN
  • the EV first verifies the charging station's identity to ensure that the charging station is a trusted facility, and establishes a secure channel with the charging station to protect the communication from unauthorized access.
  • This goal can be achieved by standardized Transport Layer Security (TLS) defined in IETF RFC 5246.
  • TLS Transport Layer Security
  • the TLS session may be created by the TLS session establishment procedure after the IP-based communication connection establishment procedure.
  • FIG. 3 is a block diagram of an EV charging infrastructure according to an embodiment of the present invention.
  • the EV charging infrastructure is for providing a charging service to the EV 10 , and includes an original equipment manufacturer server 100 , a mobility operator (MO: Mobility operator) 110 , and a certificate provisioning service (CPS: Certificate provisioning). serveice) 120, contract certificate pool (CCP) 130, vehicle-to-ground (V2G: Vehicle-to-ground) server 150, charging station (CS: Charging Station 200), and a Charging Station Operator (CSO) 210 , a Charge Service Provider (CSP) 220 , and a Clearing House (CH) 230 .
  • OEM Mobility operator
  • CPS Certificate provisioning
  • serveice 120
  • CCP contract certificate pool
  • V2G Vehicle-to-ground
  • CS Charging Station 200
  • CSO Charging Station Operator
  • CSP Charge Service Provider
  • CH Clearing House
  • EV 100 refers to a general car owned by an EV owner, and can be charged by wire or wirelessly at a charging station.
  • the EV 100 is uniquely manufactured with an OEM provisioning certificate installed.
  • a contract certificate may be installed in the EV 100 .
  • a vehicle-to-ground (V2G) root certificate may be installed in the EV 100 .
  • the original equipment manufacturer server (100, hereinafter abbreviated as 'OEM') is the top certification authority (CA) that issues OEM root certificates, and its subordinate certification bodies (OEM SubCA 1, OEM SubCA 2) are also operated, keep When EV 10 is manufactured.
  • the OEM 100 generates an OEM provisioning certificate using the OEM intermediate chain certificate (OEM SubCA 2 cert.) and installs it in the EV 10 .
  • a mobility operator (MO) 110 is a service provider that has a contractual relationship with an EV owner regarding charging, approval, and payment so that an EV driver can charge an EV at a charging station. For the EV to receive charging service from the current charging station, the current charging station must either belong to the MO or support a roaming scenario.
  • MO 110 may be operated by an electricity supplier or electricity wholesaler that sells energy.
  • MO 110 also acts as a top-level certification authority (CA) that issues the MO root certificate.
  • CA top-level certification authority
  • the MO certificate chain which consists of the MO root certificate and the MO intermediate chain certificates generated by its subordinate CAs, can be used when generating contract certificates.
  • the MO certificate chain is also used to verify the contract certificate installed in the EV 10 in a non-roaming environment or a roaming environment.
  • the MO may be referred to as an 'E-mobility service provider (EMSP)'.
  • the certificate provisioning service (CPS: Certificate provisioning serveice) 120 provides a contract certificate chain and an encryption key used for certificate transmission and reception to a client such as an EV in the process of installing or updating the contract certificate in the EV.
  • the CPS 120 is equipped with a leaf provisioning certificate (Leaf Prov cert.) and provisioning intermediate chain certificates (Prov SubCA 1 cert., Prov SubCA 2 cert.).
  • the CPS 130 supplies a provisioning service that provides each MO's public key, Diffie-Hellman (DH) public key, and eMAID along with the contract certificate chain, They allow EVs to use them to validate contract certificate chains and verify the integrity and authenticity of contract certificates.
  • DH Diffie-Hellman
  • a contract certificate pool (CCP) 130 temporarily stores a response message for installation or update in the process of installing or updating a contract certificate in the EV.
  • the response message is stored in the CCP 140 in advance and is maintained until the installation or update is completely completed. Since there may be multiple EVs for which the contract certificate installation or update is performed, the response message is maintained in the form of a directory after a reference number is added.
  • V2G server 150, hereinafter abbreviated as 'V2G'
  • 'V2G' vehicle-to-ground
  • PKI public key infrastructure
  • V2G 150 serves as the highest trust anchor, and all actors shown in FIG. 3 regard the V2G root CA as a trusted organization.
  • a charging station (CS: Charging station) 200 actually performs charging for the EV 100 .
  • the charging station 200 may include at least one wired charger and/or a wireless charging spot.
  • One or more charging stations 200 may be installed in commercial specialized charging facilities.
  • the charging station 200 may be located in various places, such as a parking lot attached to an EV owner's house, a parking area for EV charging at a gas station, a shopping center or a parking area at work.
  • the charging station 200 will be referred to as 'charging point', 'EV charging station', 'electric charging point', 'charging point', 'electronic charging station (ECS)', and 'EV side power supply (EVSE)'.
  • ECS electrostatic charging station
  • EVSE 'EV side power supply
  • a charging station operator (CSO) 210 or a charging point operator (CPO) manages electricity to operate the charging station and provide the requested energy transfer service.
  • CSO 210 may be operated by, for example, a charging station manufacturer, a charging station manufacturer, or an electricity provider. With respect to the PKI, the CSO 210 operates the subordinate certification authorities (CPO SubCA 1, CPO SubCA 2) required to generate a SECC leaf certificate for each charging station.
  • a charge service provider (CSP) 220 manages and authenticates credentials of EV users, and provides billing and other value-added services to customers.
  • the CSP 220 may be considered to correspond to a special type of the MO 110 , and may be implemented in a form combined with the MO 110 .
  • a plurality of CSPs 220 may exist, each CSP 220 is linked to one or more CSOs 210 , and the CSP 220 and the one or more CSOs 210 constitute one charging network.
  • EV 110 can receive charging service in the PnC method in the CSO 210 linked to the CSP 220 linked to the MO 100 in a contract relationship, but when charging from another CSO 210 is desired requires roaming.
  • Each CSP 200 may exchange information with another CSP or CSO 210 in another network for roaming, and may also exchange information with a clearing house 230 .
  • Clearing house (CH: Clearing house) 230 handles the cooperation between the MOs 110 to the CSPs (220). That is, the clearing house (CH) 230 may serve as an intermediate agent that facilitates the approval, billing, and settlement procedures for EV charging service roaming between two settlement or settlement parties.
  • the CH 230 is connected by the CSO 210 or the CSP 220 to perform roaming. can support you. In situations where roaming is required.
  • CH 230 allows CSO 210 or CSP 220 to contract with MO 110 and pass authorization and billing data (CDR) to MO 110 .
  • CH 230 is a 'contract clearing house (CCH: Contract clearing house)', 'mobility clearing house (MCH: Mobility clearing house)', 'roaming platform', 'e-mobility clearing house (E-MOCH) : E-MObility clearing house)', etc. may be referred to.
  • CH Contract clearing house
  • MCH Mobility clearing house
  • E-MOCH E-MObility clearing house
  • CSO Charging Service Operator
  • CPS 'Certificate Provisioning Service
  • MO 'Mobility Operator
  • CCH 'Contract Clearing House
  • 'V2G' refer to a person or refer to an organization of people
  • these expressions are implemented in hardware, software, and/or a combination thereof, and are given short and functional names to improve readability.
  • these components may be a server device implemented as a combination of hardware and software and allowing access of other devices through a network such as the Internet. Since these components are functionally separated, two or more of them may be stored and executed in one physical device, or may be integrated into one program.
  • a single entity may serve both as CSO and CSP, and another single entity may serve as both CPS and CCP. Meanwhile, one or more of the components may be rearranged to have a different appearance and name.
  • EV charging service and related infrastructure are fields in which various industrial fields such as automobile, power grid, energy, transportation, communication, finance, and electronic products are grafted, and standardization work has been carried out in parallel from various viewpoints, as well as multiple international
  • standardization at the level of individual countries has also been carried out, so there are many terms with similar concepts.
  • a charging station operator (CSO) and a charge point operator (CPO) have in common in roles and functions, and refer to substantially the same entity, although there may be some functional differences and nuances.
  • CSP charging service provider
  • MO mobility operator
  • PKI public key infrastructure
  • FIG. 3 shows an example of a PKI-based certificate hierarchy applied to an embodiment of the present invention.
  • the certificate hierarchy shown is in accordance with the ISO 15118 standard.
  • the OEM 100 acts as a top-level certification authority (CA) that issues an OEM root certificate (OEM RootCA cert.), and also operates its sub-certification authorities (OEM SubCA 1 and OEM SubCA 2). Accordingly, the OEM 100 generates an OEM intermediate chain certificate (OEM SubCA 1 cert. cert., OEM SubCA 2 cert.) by signing with its own private key as well as the OEM root certificate (OEM RootCA cert.).
  • the secondary intermediate CA (OEM SubCA 2) of the OEM 100 is provisioned by the OEM using the private key paired with the public key contained in the OEM secondary intermediate chain certificate (OEM SubCA 2 cert.) Generate a certificate (OEM Prov cert.) and install it on the EV (10).
  • This OEM provisioning certificate (OEM Prov cert.) can be used to verify the signature of the request message in the certificate installation request process for the EV 10, and uniquely identifies the vehicle during the life of the EV 10.
  • MO 110 also acts as a top-level certification authority (CA) that issues a MO root certificate (MO RootCA cert.).
  • the MO 110 may generate a primary intermediate chain certificate (MO SubCA 1 cert.) by adding its signature to the ID and public key of the primary sub-CA (MO SubCA 1).
  • the MO primary subCA (MO SubCA 1) can create a secondary intermediate chain certificate (MO SubCA 2 cert.) by adding its own signature to the ID and public key of the secondary sub CA (MO SubCA 2).
  • the secondary intermediate CA (MO SubCA 2) of the MO 110 is in the MO secondary intermediate chain certificate (MO SubCA 2 cert.)
  • a contract certificate is generated using the private key paired with the included public key, and it is installed in the EV 10 through, for example, the CS 200 that the EV 10 initially visits.
  • the contract certificate is linked to the EV owner's payment account via a unique identifier called an e-Mobility Account Identifier (eMAID).
  • eMAID e-Mobility Account Identifier
  • the OEM provisioning certificate (OEM Prov cert.) and the contract certificate (Contract Certificate) are root certificates (OEM RootCA cert., MO RootCA cert.) generated by the OEM 100 and the MO 110 themselves. It is generated based on each, and it is generated based on the global root certificate (V2G RootCA cert.) and is independent of the certificates used by other actors. However, as indicated by the dashed line in FIG. 3, using the V2G root certificate (V2G RootCA cert.) instead of the root certificates (OEM RootCA cert., MO RootCA cert.) of the OEM 100 and the MO 110, It is possible to generate an OEM Provisioning Certificate (OEM Prov cert.) and a Contract Certificate.
  • V2G RootCA cert. V2G RootCA cert.
  • V2G 150 can generate at least two series of certificates, that is, a certificate series for CSO 210 (which is a synonym for 'CPO' as mentioned above) and CS 200, and a certificate series for provisioning service. let there be
  • the V2G 150 may generate a primary intermediate chain certificate (CPO SubCA 1 cert.) by adding its own signature to the ID and public key of the CPO primary subCA (CPO SubCA 1).
  • the CPO primary subCA (MO SubCA 1) can create a secondary intermediate chain certificate (CPO SubCA 2 cert.) by adding its own signature to the ID and public key of the CPO secondary subordinate (CPO SubCA 2).
  • the CPO secondary intermediate CA (CPO SubCA 2) generates a SECC Leaf Certificate using the private key paired with the public key included in the CPO secondary intermediate chain certificate (CPO SubCA 2 cert.) It can be transmitted to the CS 200 to be installed.
  • This SECC Leaf Certificate may be used by the EV 10 during TLS communication establishment to verify that the EV 10 is communicating with a real charging station and not a fake charging station.
  • This certificate is stored inside the backend of the CSO 210 as well as the CS 200 .
  • the V2G 150 may generate a primary intermediate chain certificate (Prov SubCA 1 cert.) by adding its own signature to the ID and public key of the provisioning primary subCA (Prov SubCA 1).
  • the provisioning primary subCA (Prov SubCA 1) can create a secondary intermediate chain certificate (Prov SubCA 2 cert.) by adding its signature to the ID and public key of the provisioning secondary sub (Prov SubCA 2).
  • the Provisioning Secondary Intermediate CA (CPO SubCA 2) generates a Leaf Prov Certificate using the private key paired with the public key included in the Provisioning Secondary Intermediate Chain Certificate (Prov SubCA 2 cert.) It can be sent to the certificate provisioning service (CPS, 120) to be installed.
  • each root CA (V2G RootCA, MO RootCA, OEM RootCA) can issue and provide an OCSP certificate, so that all clients can access the OCSP server according to the Online Certificate Status Protocol (OCSP) to obtain the certificate. It allows you to request revocation/unrevocation status information about validity and receive inquiry results.
  • OCSP Online Certificate Status Protocol
  • FIG. 1 shows as if the OCSP certificate is only available for CPO subCAs (CPO SubCA 1, CPO SubCA 2) for simplicity, all root CAs (V2G RootCA, MO RootCA, OEM RootCA) An OCSP certificate can be issued and provided so that the validity of the certificates of the root certificate series can be inquired.
  • the certificate is verified or verified in three generally available ways.
  • the certificate recipient decrypts the signature value in the certificate with the public key in the certificate to restore the hash, and compares the restored hash with the hash included in the certificate to verify the integrity of the certificate.
  • the certificate recipient can verify the integrity and reliability of each certificate by sequentially comparing the owner information of each certificate with the issuer information of the subordinate CA from the root certificate to the leaf certificate in the certificate chain.
  • CTL Certificate Revocation List
  • the first EV (EV1) is in a contractual relationship with the first CSP (CSP1), the first CS (CS1) connected to the first CSO (CSO1) belonging to the network of the first CSP (CSP1) Charging services are available from EV Supply Equipment (EVSE).
  • the second EV (EV2) is in a contractual relationship with the second CSP (CSP2), and the electric vehicle power supply of the second CS (CS2) connected to the second CSO (CSO2) belonging to the network of the second CSP (CSP2)
  • a charging service is available at EV Supply Equipment (EVSE).
  • the first EV ( EV1 ) and the second EV ( EV2 ) may be charged without any particular obstacle in the CSs connected to the respective home CSOs ( CSO1 , CSO2 ).
  • the first EV (EV1) visits the second CS (CS2) under the jurisdiction of the second CSO (CSO2), or the second EV (EV2) is the first CS (CS1) managed by the first CSO (CSO1).
  • a roaming environment is created when you visit . In particular, in such an environment, there may be situations in which you need to install or renew a certificate in the EV, as will be described later.
  • FIG. 6 is a diagram illustrating examples of situations in which roaming is not required and situations in which roaming is required.
  • a plurality of MOs to CSPs may exist in the EV charging infrastructure, and each MO to CSP constitutes an independent network in terms of whether PnC is allowed.
  • Each EV can freely use the PnC service in the network to which the MO or CSP with which it has a contract belongs, but in other networks, the PnC service may be limited or unavailable.
  • FIG EV is in the contract between the first CSP (CSP A), from 5 EV is the first in the network belonging to a CSP (CSP A), a first that is managed by the CSO A associated with CSP (CSP A) PnC service is available in EVSE.
  • the visiting CSO (CSO A ) will receive an approval request from the EV under the support of the clearing house.
  • a PnC service for the EV may be made.
  • FIG. 7 is a flowchart illustrating a general service approval process according to a contract in a situation where roaming is not required.
  • the supply device communication controller (SECC) of the CS may generate a challenge (GenChallenge) by encrypting the random number with its personal machine, and transmit the generated challenge to the electric vehicle communication controller (EVCC) of the EV (600th) step).
  • the CS holds the challenge value at least until it receives a subsequent message from the EV.
  • the EV decrypts the challenge with the public key of the CS, encrypts an authorization request message (AuthorizationReq) including a number selected according to a predetermined rule with its private key, and sends it to the CS as a response to the challenge.
  • a reply may be made (step 602).
  • the authorization request message (AuthorizationReq) may include the EV contract certificate chain.
  • the CS restores the hash by decrypting the signature value included in the authorization request message (AuthorizationReq) with the EV's public key, and compares the restored hash with the hash included in the authorization request message to confirm the signature value of the authorization request message (step 604). In this case, the CS may additionally determine whether the response value included in the authorization request message corresponds to the challenge.
  • the CS transfers the contract certificate chain received from the EV to the CSO (step 606).
  • the CSO verifies the contract certificate chain (step 608).
  • verification of the contract certificate chain can be made by sequentially comparing the owner information of each certificate from the root certificate to the leaf certificate in the certificate chain with the issuer information of the subordinate CA, and through this, the integrity and reliability of each certificate. can be verified.
  • the CSO may pass the contract certificate chain to the CSP (step 610).
  • the CSP may check whether the certificate is revoked by using a certificate revocation list (CRL) or by querying the OCSP server (step 612).
  • the CSP may transmit a contract, that is, an acknowledgment message for approving the transaction to the CS (step 614).
  • the CS Upon receiving the authorization message, the CS transmits an authorization result message (Authorizat'Res) to the EV (step 616).
  • Authorizat'Res authorization result message
  • the EV is not installed with the MO RootCA cert.
  • step 602 when the contract certificate chain is sent to the CS, only the leaf certificate, the contract certificate itself, and the intermediate chain certificate (MO SubCA 1 cert., MO SubCA 2 cert.) are included, and the MO root certificate (MO RootCA cert.) is excluded. . Accordingly, the CSO receiving the certificate chain from the CS in step 608 also verifies the contract certificate chain without the MO RootCA cert. Otherwise, certificate verification may be incomplete. Of course, the CSP root certificate (CSP RootCA cert.) owned by the CSO cannot replace the MO root certificate (MO RootCA cert.).
  • the verification of whether the certificate is revoked in step 612 may be incomplete. .
  • FIG. 8 is a flowchart illustrating a general service approval process according to a contract in a situation in which direct roaming is performed.
  • the visiting CSO managing the CS does not belong to the network of the home CSP contracted with the EV, but a roaming contract relationship is formed between the visiting CSP and the home CSP.
  • steps 600 to 604 may be performed in the same manner as in FIG. 7 . That is, the CS may transmit a challenge to the EV (step 600), and in response, the CS may transmit an authorization request message (AuthorizationReq) to the CS (step 602). Then, the CS may check the signature value of the authorization request message (AuthorizationReq) (step 606).
  • AuthorizationReq authorization request message
  • the CS delivers the contract certificate chain received from the EV to the visiting CSO (step 626).
  • the visiting CSO may verify the contract certificate chain (step 628).
  • the visiting CSO may know a path to access the home CSP through the eMAID.
  • the visiting CSO may check the home CSP and deliver the contract certificate chain to the home CSP (step 630).
  • the home CSP may check whether the certificate is revoked by using a certificate revocation list (CRL) or by querying the OCSP server for each certificate in the contract certificate chain (step 632).
  • the home CSP may transmit a contract, that is, an authorization message for approving the transaction to the CS (step 634).
  • the CS may transmit an acknowledgment result message to the EV (step 636).
  • step 628 the visiting CSO verifies the contract certificate chain without the MO root certificate, and the visiting CSO separates the MO root certificate (MO RootCA cert.) from the CSP root certificate (CSP RootCA cert.). Certificate verification may be incomplete unless you have it.
  • the home CSP cannot guarantee that it can access the CRL or OCSP server linked to the MO root CA other than the CRL or OCSP server linked to the CSP root CA, it is also possible to check whether each certificate is revoked in step 632. may be incomplete.
  • FIG. 9 is a flowchart illustrating a general service approval process according to a contract in a situation in which indirect roaming is performed.
  • the visiting CSO managing the CS does not belong to the network of the home CSP contracted with the EV, but an indirect roaming contract relationship is formed between the visiting CSP and the home CSP through a clearing house.
  • steps 600 to 604 may be performed in the same manner as in FIGS. 7 and 8 . That is, the CS may transmit a challenge to the EV (step 600), and in response, the CS may transmit an authorization request message (AuthorizationReq) to the CS (step 602). Then, the CS may check the signature value included in the authorization request message (AuthorizationReq) (step 606). Then, the CS delivers the contract certificate chain received from the EV to the visiting CSO (step 646).
  • AuthorizationReq authorization request message
  • the CS delivers the contract certificate chain received from the EV to the visiting CSO (step 646).
  • the visiting CSO Since the visiting CSO does not have a direct contractual relationship with the home CSP that has signed a contract with the EV, the visiting CSO cannot identify the home CSP with information such as eMAID that the visiting CSO possesses. However, since the visiting CSO has a contractual relationship with the clearing house, it can be confirmed whether the clearing house can grasp the home CSP and which clearing house can grasp the home CSP (step 648). After confirming that the clearing house knows at least one home CSP (step 650), the visiting CSO may forward the contract certificate chain to the corresponding clearing house (step 652). The clearing house may verify the contract certificate chain (step 654), and then forward the contract certificate chain to the home CSP (step 656).
  • the home CSP may check whether the certificate is revoked by using a certificate revocation list (CRL) or by querying the OCSP server for each certificate in the contract certificate chain (step 657). According to the confirmation result, the home CSP may transmit a contract, that is, an authorization message for approving the transaction to the CS (step 658). Upon receiving the acknowledgment message, the CS may transmit an acknowledgment result message to the EV (step 659).
  • CCL certificate revocation list
  • the clearing house separately secures the MO root certificate (MO RootCA cert.) from the CSP root certificate (CSP RootCA cert.) in step 654, the certificate verification may be incomplete.
  • the home CSP since it cannot be guaranteed that the home CSP can access the CRL or OCSP server linked to the MO root CA other than the CRL or OCSP server linked to the CSP root CA, it is also possible to check whether each certificate is revoked in step 657. may be incomplete.
  • FIG. 10 is a flowchart illustrating a general service approval process according to a contract in a situation where on-the-fly direct roaming is performed.
  • the visiting CSO managing the CS is not part of the network of home CSPs contracting with the EV, but the visiting CSO can enter into an on-the-fly direct roaming contract with the home CSP. Assume
  • steps 600 to 604 may be performed in the same manner as in FIGS. 7 and 8 . That is, the CS may transmit a challenge to the EV (step 600), and in response, the CS may transmit an authorization request message (AuthorizationReq) to the CS (step 602). Then, the CS may check the signature value included in the authorization request message (AuthorizationReq) (step 606). The CS may deliver the contract certificate received from the EV to the visiting CSO (step 666).
  • AuthorizationReq authorization request message
  • AuthorizationReq authorization request message
  • the CS may deliver the contract certificate received from the EV to the visiting CSO (step 666).
  • the visiting CSO may enter into an instant roaming contract with the home CSP (step 668).
  • the visiting CSO may then verify the contract certificate chain (step 670).
  • the visiting CSO can know the route to access the home CSP through the eMAID. Accordingly, the visiting CSO may deliver the contract certificate chain to the home CSP (step 672).
  • the home CSP may check whether the certificate is revoked by using a certificate revocation list (CRL) or by querying the OCSP server for each certificate in the contract certificate chain (step 674).
  • the home CSP may transmit a contract, that is, an authorization message for approving the transaction to the CS (step 676).
  • the CS may transmit an acknowledgment result message to the EV (step 678).
  • the visiting CSO separately secures the MO root certificate (MO RootCA cert.) from the CSP root certificate (CSP RootCA cert.) in step 670
  • the certificate verification may be incomplete.
  • it cannot be guaranteed that the home CSP can access the CRL or OCSP server linked to the MO root CA other than the CRL or OCSP server linked to the CSP root CA it is also possible to check whether each certificate is revoked in step 674. may be incomplete.
  • FIG. 11 is a flowchart illustrating a general service approval process according to a contract in a situation where on-the-fly indirect roaming is performed.
  • the visiting CSO managing the CS does not belong to the network of the home CSP contracted with the EV, nor is an indirect roaming contract relationship formed between the visiting CSP and the home CSP through a clearing house.
  • the visiting CSO not only does not know the home CSP, but also does not know the clearing house that has a contractual relationship with the home CSP. Assume, however, that the visiting CSO can request that the clearing house be contracted online with the home CSP.
  • steps 600 to 604 may be performed in the same manner as in FIGS. 7 and 9 . That is, the CS may transmit a challenge to the EV (step 600), and in response, the CS may transmit an authorization request message (AuthorizationReq) to the CS (step 602). Then, the CS may check the signature value included in the authorization request message (AuthorizationReq) (step 606). Subsequently, the CS delivers the contract certificate received from the EV to the visiting CSO (step 686).
  • AuthorizationReq authorization request message
  • the CS delivers the contract certificate received from the EV to the visiting CSO (step 686).
  • the visiting CSO since the visiting CSO does not have a direct contractual relationship with the home CSP contracted with the EV, the visiting CSO cannot identify the home CSP with information such as eMAID that the visiting CSO possesses. Furthermore, the visiting CSO attempts to identify a clearing house that already has a contract with the home CSP, but fails (step 688). In this case, the visiting CSO may request the clearing house to confirm the home CSP and conclude a contract with the home CSP (step 690).
  • the contract may be a one-time power charging and settlement agency for the EV.
  • the clearing house may verify the contract certificate chain (step 694), and then transmit the contract certificate chain to the home CSP (step 696).
  • the home CSP may check whether the certificate is revoked by using a certificate revocation list (CRL) or by querying the OCSP server for each certificate in the contract certificate chain (step 697). According to the confirmation result, the home CSP may transmit a contract, that is, an authorization message for approving the transaction to the CS (step 698). Upon receiving the acknowledgment message, the CS may transmit an acknowledgment result message to the EV (step 699).
  • CCL certificate revocation list
  • the clearing house separately secures the MO root certificate (MO RootCA cert.) from the CSP root certificate (CSP RootCA cert.) in step 694, the certificate verification may be incomplete.
  • the home CSP since it cannot be guaranteed that the home CSP can access the CRL or OCSP server linked to the MO root CA other than the CRL or OCSP server linked to the CSP root CA, it is also possible to check whether each certificate is revoked in step 697. may be incomplete.
  • the CSP issues contract certificates for EVs as MO Sub CAs. That is, when the EV presents the OEM provisioning certificate stored therein from the time of shipment to the CSO, the CSO issues a contract certificate and delivers it to the EV.
  • the contract certificate while stored in the EV, is presented to the CS at every PnC charge, allowing the CS or other secondary actors to identify the EV's contract.
  • a situation may occur in which the EV visits the charging station (CS) and requests PnC charging.
  • the EV user at the time of initial charging, the EV user must deliver the OEM provisioning certificate installed in the EV at the time of shipment to the CSP or MO and be issued a contract certificate.
  • a charging station associated with a non-visited CSO For example, a charging station associated with a non-visited CSO.
  • a situation arises in which the contract certificate must be installed in the EV under roaming conditions. Such a situation may occur immediately after a name change due to the sale of an EV or immediately after a memory failure of the EV.
  • the certificate to be installed in the EV in the roaming situation is not limited to the contract certificate and may be another certificate.
  • the ISO 15118 standard which specifies the protocol requirements on the network layer and the application layer
  • the IEC 63119-1 standard which defines information exchange for EV charging roaming service
  • each CSP in a contract relationship with each EV enables the EV to receive, install, or update a contract certificate or other necessary certificates or data in any roaming situation.
  • a method of installing or updating a certificate in an EV according to an embodiment of the present invention will be described.
  • FIG. 12 shows a delivery path of a contract certificate that is delivered and installed from a home CSP to an EV through direct roaming according to an embodiment of the present invention.
  • the contract certificate stored in the home CPS needs to be installed in the EV or an existing certificate in the EV needs to be updated with this certificate.
  • the EV has visited the CS connected to the visited CSO (CSOV) belonging to the network of the visited CSP (CSPV).
  • the EV may directly install the contract certificate stored in the home CPS (CPSH) by roaming, or update the existing certificate with this certificate. be able to
  • FIG. 13 is a flowchart illustrating in more detail the certificate delivery process shown in FIG. 12 .
  • the owner of the EV and the operator of the home CSP may conclude a charging service contract (step 700).
  • the home CSP may generate a contract certificate for the EV (step 702).
  • the generated certificate includes the public key of the EV, a hash of the public key, and a signature value obtained by encrypting the hash with the private key of an intermediate CA (MO Sub 1 or MO Sub 2) of the MO root CA.
  • the generated certificate may be distributed to all visited CSPs that have a roaming contract with the corresponding home CSP (steps 704 to 708).
  • steps 700 to 708 may be preemptively performed before the EV transmits a certificate installation request message (CertificateInstallationReq) or a certificate update request message (CertificateUpdateReq) to the visited ESO through the CS.
  • the home CSP distributes the certificate installation package to all visiting CSPs in a contractual relationship in advance so that the visiting CSPs can store it in their CPS. do.
  • the certificate installation package may be distributed in advance to all CSPs regardless of whether or not there is a current contractual relationship.
  • the certificate installation package may include a contract certificate chain, eMAID account information, and additionally include a certificate revocation list (CRL) and access information of an OCSP server.
  • CCL certificate revocation list
  • the certificate package transfer between CSPs may be performed directly or through a clearing house as described below.
  • a certificate installation response message (CertificateInstallationRes) or a certificate update response message (CertificateUpdateRes) including the corresponding certificate package is sent to all visits that have a contractual relationship with the home CSP. It is distributed over a secure channel to CSPs. At this time, each home CSP can verify the contract certificate chain, check the revocation status of the contract certificate chain, check the eMAID account status, and check whether the contract can be approved for the service.
  • the home CSP distributes the certificate package to all visiting CSPs with direct roaming contracts, or distributes the certificate package to a clearing house with a certificate distribution contract. You can, or you can distribute to both.
  • the home CSP may have a list of visited CSPs, if any, with one or more visited CSPs with direct roaming agreements. Also, the home CSP may have a list of such clearing houses, if any, with roaming agreements for certificate installation. Communication for distributing the certificate package may take place beyond the roaming endpoint. Meanwhile, upon receiving the certificate installation package, the visiting CSP can distribute the corresponding package to their CPSs through the same procedure as is performed when issuing a certificate for their user.
  • Steps 720 to 734 of FIG. 13 show this process.
  • the EV may transmit a certificate installation or update request message (Cert ⁇ Ins/Upd ⁇ Req) to the CS.
  • the EV can send the OEM provisioning certificate chain to the charging station (CS) by communication conforming to the ISO 15118 standard.
  • the certificate renewal request message may include a contract certificate chain.
  • the CS checks the message signature value in the request message (step 722). At this time, the CS decrypts the signature value included in the request message with the public key to restore the hash, and then checks the message signature value by comparing the restored hash with the hash included in the request message.
  • the CS verifies the received certificate chain (step 724).
  • an OEM provisioning certificate for certificate installation in the provisioning certificate chain, from the OEM root certificate (OEM RootCA cert.) to the leaf certificate (OEM Prov cert.)
  • the owner information of each certificate is sequentially stored in its subordinate CA's. This can be done by comparing with the issuer information, and through this, the integrity and reliability of each certificate can be verified.
  • contract certificates for certificate update the owner information of each certificate sequentially from the MO root certificate (MO RootCA cert.) to the leaf certificate (Contract cert.) in the contract certificate chain is the issuer information of the subordinate CA This can be done by comparing with , and through this, the integrity and reliability of each certificate can be verified.
  • the CS delivers a certificate installation or update request message (Cert ⁇ Ins/Upd ⁇ Req) to the visiting CSO (step 726).
  • the visiting CSO may check whether each certificate in the OEM provisioning certificate chain or contract certificate chain has been revoked (step 728).
  • the revocation status that is, the validity of the certificate, can be checked through the certificate revocation list (CRL) received from the OEM root CA or the certificate revocation list received from the MO root CA, You can also request the certificate status and check it after receiving the inquiry result.
  • CTL certificate revocation list
  • the visited CPS verifies the new contract certificate chain stored in step 708 based on the MO root CA certificate (step 730). Then, the visiting CPS checks whether each certificate in the new contract certificate chain is revoked (step 732). The validity of the certificate can be checked through the certificate revocation list (CRL) received from the MO root CA, or it can be checked by requesting the certificate status from the OCSP server linked to the MO root CA and receiving the inquiry result.
  • CTL certificate revocation list
  • the CS needs to prove that all certificates in the CS's certificate chain are valid, i.e. not revoked. for teeth.
  • the CS may make a request to the CSMS periodically to get an OCSP response from the OCSP responder of the CSO PKI and often enough to keep the OCSP response valid.
  • the CS can store one OCSP response for one certificate chain.
  • the CS may decide to update the OCSP response immediately before the existing OCSP response expires, and may request the CSMS to retrieve the OCSP.
  • the OCSP search request may include an OCSP request message, a Distinguished Name (DN) of a certificate issuer, and a serial number of the certificate.
  • CSMS retrieves the OCSP response URL by querying the certificate database with the issuer DN and serial number. If the URL cannot be found, CSMS may try to retrieve the URL in another way. If there is no best URL, CSMS may display an error in the response.
  • the CSMS may return a list of OCSP response messages to the CS.
  • CSMS can indicate which OCSP query failed and why.
  • the CS may transmit it to the EV during the TLS connection through OCSP stapling. For each error, depending on the error type, the CS can decide whether to retry the search or enter a hold state.
  • the CSMS may maintain a certificate database for storing certificates used by the charging station and itself. And, the CS always maintains a set of valid OCSP responses to the certificate chain. It is desirable that the CS always request OCSP responses from the CSMS as often as possible to keep it valid.
  • step 730 the new contract certificate chain is verified, and in step 732, if there is no problem with the validity of each certificate in the new contract certificate chain, the visiting CPS sends a certificate install/renew response (i.e., Cert ⁇ Ins/Upd ⁇ Res message) is transmitted to the CS (step 734).
  • the CS may transmit the new contract certificate package back to the EV, and a new certificate may be installed or renewed in the EV (step 736).
  • the contract certificate distributed to virtually all CSPs in steps 704 to 708 is sent to each CSP to reduce the burden of storing personal information protection data after a certain period of time has elapsed or the contract certificate installation is completed in the EV. can be deleted from To this end, it is preferable that the home CSP notifies all CSPs to which the contract certificate is distributed and the clearing house of the completion of the installation of the contract acknowledgment after the installation of the contract certificate in the EV is completed.
  • the owner of the EV and the operator of the home CSP may conclude a charging service contract (step 700).
  • the home CSP may generate a contract certificate for the EV (step 702).
  • the generated certificate includes the public key of the EV, a hash of the public key, and a signature value obtained by encrypting the hash with the private key of an intermediate CA (MO Sub 1 or MO Sub 2) of the MO root CA.
  • the generated certificate may be distributed to all visited CSPs that have a roaming contract with the corresponding home CSP (steps 704 to 708).
  • the CS transmits data received from the visited CPS in step 734, for example, a contract certificate package, to the EV in step 736, but not all certificate data received by the CS is transmitted to the EV. That is, the CS may accept and install a certificate according to its own needs or renew a previously stored certificate. For example, the CS may obtain a root CA certificate and related metadata to be used to authenticate the EV and a Charging Station Management System (CSMS), and a cross-certificate to be used to authenticate itself to the EV from the CSMS. In other words, the CS needs to itself store some root CA certificates (issued for the root CA, but not necessarily self-signed) and associated metadata for its secure operation.
  • the metadata of the certificate may include the SHA1 hash (for TLS) and the DN/serial number of the issuer (for installing the certificate).
  • the CS needs the root CA certificate of the CSMS's certificate chain (ie, the CSMS's root CA certificate) to authenticate the CSMS while establishing a secure channel with the CSMS, which is generally the same as the V2G root CA of CS. Also, if an EV conforming to the ISO 15118 standard chooses to be approved in a PnC manner, and the role of the CS is to verify the contract certificate chain, the CS may need to have the EMSP's root CA certificate. In addition, in the case of contract certificate installation or update, if the role of the CS is to verify the installed OEM provisioning certificate chain or the updated contract certificate chain, the CS may need an OEM root CA certificate or an EMSP root CA certificate.
  • the CS may require a cross-certificate issued by the V2G root CA trusted by the EV.
  • the CS needs to know the metadata of available trust anchors.
  • the trust anchor includes the CS's V2G root CA (with a new root CA for migration) and cross-certified V2G root CA.
  • the CS may require the CS component manufacturer's Root CA certificate, which is used to verify the integrity of the firmware binary code.
  • V2G root CA migration of CS if the CSO chooses to use the migration method defined in RFC 4210, it may be necessary for the CS to hold one of two cross-certificates during the migration period.
  • OldWithNew and NewWithOld certificates may exist.
  • the OldWithNew certificate refers to a cross-certificate signed by the new root CA against the old root CA, and the CS with the old certificate chain needs it for EVs that trust the new root CA.
  • the NewWithOld certificate refers to a cross-certificate signed by the old root CA to the new root CA, and the CS with the new certificate chain needs it for EVs that trust the old root CA.
  • each update data being 'update (type, certificate, metadata)' is in the format of
  • each update data may be in the format of (V2G root CA, ⁇ V2G root CA certificate>).
  • the EMSP root CA certificate it may be in the format of (EMSP root CA, ⁇ EMSPRooCA certificate>, -).
  • OEM root CA certificate In case of OEM root CA certificate, it may be in the format of (OEM root CA, ⁇ OEMRooCA certificate>, -). It may be in the format of cross-certificate (CrossCert, ⁇ Cross-Certificate>, -). In the case of a cross-certified V2G root CA certificate, it may be in the format of (Cross root CA, -, ⁇ meta data>).
  • OldWithNew cross-certificate for migration it may be in the format of (OldWithNew, ⁇ OldWithNew certificate>, -), and in the case of the NewWithOld cross-certificate for migration, it may be in the format of (NewWithOld, ⁇ NewWithOld certificate>, -).
  • the CS upon receiving an update from the CSMS, the CS installs the received certificate or metadata without excessive delay and updates the update time stamp.
  • the CS may request the update of the CA certificate by sending certain information to the CSMS.
  • examples of the information transmitted from the CS to the CSMS may include a timestamp of the last successful update and a list of DN/serial numbers of the issuer of the CA certificate currently in the CS.
  • the CSMS may send the updated/added CA certificate/metadata after the indicated timestamp.
  • the CS securely stores the CA certificate and metadata.
  • the CSMS When the CSMS updates the CA certificate database, the CSMS must request the relevant CS to update or install the update set after the last update. Upon receiving the request, the CS installs the received CA certificate update and sets the timestamp to the update time. According to the CSO's policy, the CS may periodically request a CA certificate update while providing the timestamp of the last update to the CSMS. Also, upon receiving the request, CSMS sends any CA certificate updates that have changed since the timestamp included in the request. When CSMS sends a CA certificate update, it sends a list of certificate types, certificates, and metadata, where only the metadata is sent to cross-certify the cross-certification V2G root CA certificate.
  • the CS needs to hold a number of CA certificates and related information for a secure operation. For example, if an EV conforming to the ISO 15118 standard chooses to be approved in a PnC manner, the CS may need the EMSP's root CA certificate to validate the contract certificate chain. Also, for contract certificate installation, CS may need root CA certificate from OEM or EMPS.
  • CSMS When establishing a secure channel with CSMS, CS needs CSMS's root CA certificate, which is usually V2G root CA.
  • the CS needs to maintain cross-certificates issued by different V2G operators.
  • the CS needs to maintain the metadata (eg hash, DN, and serial number) of each trust anchor to determine if the EV can securely connect to the CSO.
  • One embodiment of the process by which the CS updates multiple CA certificates and related information for secure operation may be triggered by the CS. If the CS decides to update the CA certificate inventory with changes, the CS can request the update of all CA certificates from the CSMS. In this case, the request may include a timestamp of the last successful update request and a list of issuer DN/serial numbers of the CA certificate in the CS. Upon receiving the request, the CSMS may check the timestamp of the CA certificate update and send only the data of the certificate updated after the timestamp in the request to the CS.
  • Certificates sent to CS in this way may include: V2G RootCA Certificate and Metadata of CSMS, V2G RootCA Metadata of CS, RootCA Certificate of contracted EMSP (if required), (if required) OEM's RootCA Certificate, Cross Certificate and Metadata issued to CS' V2G RootCA, Cross Certificate's V2G RootCA Metadata, and Root Migration Cross Certificate.
  • the CS may securely store the received CA certificate.
  • the CSMS can request the CA certificate update by sending a list of certificate data and the type of certificate to be updated for all or some CSs.
  • the certificate types to be updated include, for example, V2G root CA of CSMS (for root migration), V2G root CA of CS (for root migration), root CA of EMSP, root CA of OEM, cross-certificate issued to V2G root CA of CS, Examples of cross-certificate V2G root CA and root migration cross-certificate.
  • CSMS may maintain a database for CA certificate data (certificate, DN, serial number, hash) tagged with update/time. And EV and CS can communicate through ISO15118 as a PnC identification method.
  • CPS/CCP can validate the certificate chain (OEM provisioning certificate chain for install and contract certificate chain for update), and check whether each certificate in the OEM provisioning certificate chain for install and contract certificate chain for update is revoked.
  • the CS checks the signatures of the CertificateInstallationReq and CertificateUpdateReq messages.
  • the CS then sends the following data to the CSMS: CertificateInstallationReq or CertificateUpdateReq message (as is), PCID (for installation) or eMAID (for update), ISO 15118 schema version of the message, retrieval (due to ISO15118 timeout) ) due date, list of V2G root CA certificates trusted by EV.
  • the CSMS may request a contract certificate from the secondary party and forward the received information back to the CS. If multiple contract certificates are received, the CSMS preferably indicates to the CS that reception is complete.
  • the CSMS may display an error message (eg 'NO_CONTRACT_CERTIFICATE_FOUND') to the CS.
  • CS may transmit CertificateInstallationRes or CertificateUpdateRes received from CSMS to EV with SessionID filled.
  • the CS modifies each CertificateInstallationRes received or generates a CertificateInstallationRes message for each information received from the CSMS, so that the message contains the correct values for the SessionID, EVSEProcessing, RemainingCerts, EVSEStatus and ResponseCode elements. may be included.
  • FIG. 14 shows a delivery path of a contract certificate delivered and installed from a home CSP to an EV through indirect roaming according to an embodiment of the present invention.
  • the contract certificate stored in the home CPS needs to be installed in the EV or an existing certificate in the EV needs to be updated with this certificate.
  • the EV has visited the CS connected to the visited CSO belonging to the network of the visited CSP.
  • the EV installs the contract certificate stored in the home CPS by indirect roaming through the clearing house or updates the existing certificate with this certificate be able to do
  • FIG. 15 is a flowchart illustrating in more detail the certificate delivery process shown in FIG. 14 .
  • the embodiment shown in FIG. 15 differs in that the visiting CSP and the home CSP communicate through a clearing house rather than directly communicating in the process of preemptively storing the certificate in the CSPs.
  • the owner of the EV and the operator of the home CSP may conclude a charging service contract (step 800).
  • the home CSP may generate a contract certificate for the EV (step 802).
  • the generated certificate includes the public key of the EV, a hash of the public key, and a signature value obtained by encrypting the hash with the private key of an intermediate CA (MO Sub 1 or MO Sub 2) of the MO root CA.
  • the generated certificate may be distributed to all visited CSPs that have a roaming contract with the corresponding home CSP (steps 804 to 808).
  • steps 800 to 808 may be preemptively performed before the EV transmits a certificate installation request message (CertificateInstallationReq) or a certificate update request message (CertificateUpdateReq) to the visited ESO through the CS.
  • the home CSP distributes the certificate installation package to all visiting CSPs in a contractual relationship in advance so that the visiting CSPs can store it in their CPS. do.
  • the certificate installation package may be distributed in advance to all CSPs regardless of whether or not there is a current contractual relationship.
  • the certificate installation package may include a contract certificate chain, eMAID account information, and additionally include a certificate revocation list (CRL) and access information of an OCSP server.
  • CCL certificate revocation list
  • the certificate package transfer between CSPs may be performed directly or through a clearing house as described below.
  • a certificate installation response message (CertificateInstallationRes) or a certificate update response message (CertificateUpdateRes) including the corresponding certificate package is sent to all visits that have a contractual relationship with the home CSP. It is distributed over a secure channel to CSPs.
  • the home CSP or clearing house can verify the contract certificate chain, check the revocation status of the contract certificate chain, check the eMAID account status, and check whether the contract can be approved for the service. As a result of verification, if there is no problem with the contract certificate chain, eMAID account, and contract content, the certificate package can be distributed to all visiting CSPs.
  • the home CSP When the distribution is complete, the home CSP sends the status code of the certificate chain and the result code for the account and authority to the clearing house.
  • the home CSP may have a list of visited CSPs, if any, with one or more visited CSPs with direct roaming agreements. Also, the home CSP may have a list of such clearing houses, if any, with roaming agreements for certificate installation. Communication for distributing the certificate package may take place beyond the roaming endpoint. Meanwhile, upon receiving the certificate installation package, the visiting CSP can distribute the corresponding package to their CPSs through the same procedure as is performed when issuing a certificate for their user.
  • Steps 820 to 836 of FIG. 14 show this process.
  • the EV may transmit a certificate installation or update request message (Cert ⁇ Ins/Upd ⁇ Req) to the CS.
  • the EV can send the OEM provisioning certificate chain to the charging station (CS) by communication conforming to the ISO 15118 standard.
  • the certificate renewal request message may include a contract certificate chain.
  • the CS checks the message signature value in the request message (step 822). At this time, the CS decrypts the signature value included in the request message with the public key to restore the hash, and then checks the message signature value by comparing the restored hash with the hash included in the request message.
  • the CS verifies the received certificate chain (step 824). That is, for certificate installation, the OEM provisioning certificate chain is verified in the manner described above, and for certificate update, the contract certificate chain is verified. Subsequently, the CS delivers a certificate installation or update request message (Cert ⁇ Ins/Upd ⁇ Req) to the visiting CSO (step 826). Then, the visiting CSO can check whether each certificate in the OEM provisioning certificate chain or contract certificate chain is revoked in the manner described above (step 828).
  • the visiting CPS verifies the new contract certificate chain stored in step 808 based on the MO root CA certificate (step 830). Then, the visiting CPS checks whether each certificate in the new contract certificate chain is revoked (step 832). The validity of the certificate can be checked through the certificate revocation list (CRL) received from the MO root CA, or it can be checked by requesting the certificate status from the OCSP server linked to the MO root CA and receiving the inquiry result.
  • CTL certificate revocation list
  • the new contract certificate chain is validated, and if there is no problem with the validity of each certificate in the new contract certificate chain, the visiting CPS responds to install/renew the certificate including the new contract certificate package (i.e., Cert ⁇ Ins/Upd ⁇ Res message) to the CS (step 834).
  • the CS may transmit the new contract certificate package back to the EV, and a new certificate may be installed or renewed in the EV (step 836).
  • the CS transmits data received from the visited CPS in step 834, eg, a contract certificate package, to the EV in step 836, but not all certificate data received by the CS is transmitted to the EV. That is, the CS may accept and install a certificate according to its own needs or renew a previously stored certificate. In addition, the CS needs to hold a plurality of CA certificates and related information for secure operation, and may update a plurality of CA certificates and related information. In the present embodiment, a process for the CS to install or renew a necessary certificate is similar to that described with reference to FIG. 13 , and thus a detailed description thereof will be omitted.
  • FIGS. 13 and 15 the roles of the visiting CSP and the home CSP may be reversed.
  • one CSP may act as a visiting CSP for another CSP while acting as a home CSP for another CSP.
  • 16 is a flowchart illustrating a service approval process according to a contract according to an embodiment of the present invention.
  • an EV desiring to receive approval for a service through the PnC method may transmit an authorization request message (AuthorizationReq) to a visiting CS (step 900).
  • the EV may transmit the contract certificate chain to the charging station (CS) by communication conforming to the ISO 15118 standard.
  • the CS restores the hash by decrypting the signature value included in the authorization request message (AuthorizationReq) with the EV's public key, and by comparing the restored hash with the hash included in the authorization request message, confirms the signature of the EV (step 902) ).
  • the CS may deliver the contract certificate chain and eMAID included in the authorization request message (AuthorizationReq) to the visiting CSO (step 904).
  • the visiting CSO determines whether the CSP contracted with the EV is inside or outside the network to which it belongs. The visiting CSO then identifies how to contact the home CSP or clearing house directly for roaming assistance. Then, the visiting CSO transmits an authorization request including EV-related information to the home CSP or clearing house (step 906).
  • the EV-related information includes an eMAID and a contract certificate chain, and may additionally include a service description for EV approval. If the destination of the EV-related information transmitted by the visited CSO is a clearing house in step 906, the clearing house delivers the EV-related information to the corresponding home CSP.
  • the home CSP confirms the complete contract certificate chain by including the previously secured MO RootCA certificate (MO RootCA cert.), and verifies the contract certificate chain (step 708).
  • the verification of the contract certificate chain is sequentially performed from the root certificate (MO RootCA cert.) to the intermediate chain certificate (MO SubCA 1 cert, MO SubCA 2 cert) to the leaf certificate (Contract Certificate). is compared with the issuer information of the subordinate CA to verify the integrity and reliability of each certificate.
  • the home CSP checks whether each certificate in the contract certificate chain is revoked (step 910).
  • the non-revocation status, ie, validity, of the certificate can be checked through the certificate revocation list (CRL) received from the MO root CA, or by inquiring the certificate status to the OCSP server linked to the MO root CA.
  • the home CSP may additionally check the status of the eMAID account and whether the requested service can be contractually approved (step 912 ).
  • the home CSP may return a status code indicating the status of the contract certificate chain and a result code regarding the EV's account and authority to the visiting CSO (step 914).
  • the status code may be, for example, one of 'OK', 'Expired', 'Revoked', 'Invalid_chain', and 'Unkown_error'.
  • the result code is, for example, 'OK', 'contract does not exist (NO_CONTRACT)', 'contract expired (CONTRACT_TERMINATED)', 'contract pending (CONTRACT_SUSPENDED)', 'not approved (NOT_AUTHORIZED)', 'contract expired (CONTRACT_TERMINATED)' It may be one of 'Unkown_error'.
  • the visiting CSO notifies the CS of the certification result, and the CS may notify the EV again of the certification result through communication conforming to the ISO 15118 standard (steps 916 and 918).
  • the visiting CSO directly exchanges information with the home CSP for EV authentication or establishes a clearing house.
  • the approval process can be performed by exchanging information via.
  • FIG. 16 illustrates an embodiment of the present invention, and this embodiment may be variously modified.
  • the message signing step (step 902 ) may be performed by the visiting CSO rather than the CS.
  • the contract certificate chain verification step (step 908) may be executed by the visiting CSO or CS rather than the home CSP.
  • the execution subject of each step may be changed as shown in FIGS. 7 to 11 according to the roaming situation.
  • the CSP 220 may include at least one processor 1020 , a memory 1040 , and a storage device 1060 .
  • the processor 1020 may execute program instructions stored in the memory 1040 and/or the storage device 1060 .
  • the processor 1020 may be implemented by at least one central processing unit (CPU) or a graphics processing unit (GPU), and any other processor capable of performing the method according to the present invention. can be
  • the memory 1040 may include, for example, a volatile memory such as a read only memory (ROM) and a non-volatile memory such as a random access memory (RAM).
  • the memory 1040 may load a program command stored in the storage device 1060 and provide it to the processor 1020 .
  • the storage device 1060 is a recording medium suitable for storing program instructions and data, for example, a magnetic medium such as a hard disk, a floppy disk, and a magnetic tape, a compact disk read only memory (CD-ROM), and a DVD (Compact Disk Read Only Memory).
  • Optical recording media such as Digital Video Disk), Magneto-Optical Media such as Floptical Disk, Flash memory or EPROM (Erasable Programmable ROM), or SSD manufactured based on them It may include a semiconductor memory such as
  • the storage device 1060 stores the program command.
  • the program command may include a program command for supporting certificate installation according to the present invention.
  • the program command for supporting certificate installation generates a first contract certificate for the first EV and transmits the first contract certificate to a first external CSP, so that the first contract certificate is transmitted through the first external CSP A command to be installed in the 1 EV, a command to receive the second contract certificate for the second EV from the second external CSP, and to transmit and store the second EV to the CPS, and a roaming situation in which the second EV enters the service network and when a contract certificate installation request is received from the second EV, the second contract certificate stored in the CPS is transmitted to the second EV and installed in the second EV.
  • the program command for wireless power transmission may include at least some of the commands required to implement the process shown in FIG. 12 .
  • Such a program command may be executed by the processor 1020 while being loaded into the memory 1040 under the control of the processor 1020 to implement the method according to the present invention.
  • the apparatus and method according to the embodiment of the present invention can be implemented as a computer-readable program or code on a computer-readable recording medium.
  • the computer-readable recording medium includes all types of recording devices in which data that can be read by a computer system is stored.
  • the computer-readable recording medium is distributed in a computer system connected to a network so that computer-readable programs or codes can be stored and executed in a distributed manner.
  • the computer-readable recording medium may include a hardware device specially configured to store and execute program instructions, such as ROM, RAM, and flash memory.
  • the program instructions may include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like.
  • aspects of the invention have been described in the context of an apparatus, it may also represent a description according to a corresponding method, wherein a block or apparatus corresponds to a method step or feature of a method step. Similarly, aspects described in the context of a method may also represent a corresponding block or item or a corresponding device feature. Some or all of the method steps may be performed by (or using) a hardware device such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, one or more of the most important method steps may be performed by such an apparatus.
  • a programmable logic device eg, a field programmable gate array
  • the field programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described herein.
  • the methods are preferably performed by some hardware device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Power Engineering (AREA)
  • Economics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Tourism & Hospitality (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Human Resources & Organizations (AREA)
  • Water Supply & Treatment (AREA)
  • Public Health (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Charge And Discharge Circuits For Batteries Or The Like (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Operations Research (AREA)

Abstract

본 개시는 충전 서비스 제공 장치에서의 계약 인증서 설치 지원 방법을 개시한다. 본 개시의 일 예로서, 제1 전기차(EV)에 대한 제1 계약 인증서를 생성하는 단계, 및 상기 제1 계약 인증서를 로밍 계약이 형성되어 있는 제1 외부 충전 서비스 제공 장치(CSP)에 전송하여, 상기 제1 계약 인증서가 로밍 상황에서 상기 제1 외부 CSP를 통해 상기 제1 EV에 설치될 수 있게 하는 단계를 포함할 수 있다.

Description

전기차에 대한 계약 인증서 설치 지원 방법 및 장치
본 발명은 전기차 충전 방법 및 이를 위한 장치에 관한 것이다. 특히, 본 발명은 PnC 방식의 충전 기반구조에서 로밍 환경에 대응할 수 있도록 전기차에 공개키 인증서를 설치하는 방법 및 장치에 관한 것이다.
전기 자동차(EV: Electric Vehicle, 이하 '전기차'로 약칭함)는 배터리의 동력으로 모터를 구동하여 운행하며, 종래의 가솔린 엔진 자동차에 비해 배기가스 및 소음 등과 같은 공기 오염원이 적으며, 고장이 적고, 수명이 길고, 운전 조작이 간단하다는 장점이 있다. 전기차 충전 시스템은 상용 전력 배전망(power grid)이나 에너지 저장 장치의 전력을 이용하여 전기차에 탑재된 배터리를 충전하는 시스템으로 정의할 수 있다. 이러한 전기차 충전 시스템은 다양한 형태로 구현될 수 있으며, 예를 들어, 케이블을 이용한 전도성 충전 시스템이나 비접촉 방식의 무선전력전송 시스템을 포함할 수 있다.
충전 스테이션은 EV에 대하여 일정한 승인 과정을 거친 후 충전을 시작하게 되는데, 상기 승인 과정은 충전 기반구조와 EV 기능에 따라 다르다. 전기차 충전에 관한 국제표준 중 하나인 ISO 15118-1은 두가지 승인 방법 즉, EV에 저장되어 있는 계약 인증서를 사용하여 승인과 결제가 자동으로 완료되는 PnC 방식과, 신용카드, 직불카드, 현금, 스마트폰앱과 같은 외부 식별 수단(EIM: External Identification Means)에 의해 식별, 승인, 요금결제가 이루어지는 방식을 규정하고 있다. PnC 방식이란 유선 충전의 경우 EV와 충전 스테이션 사이에 플러그만 꽂으면 서비스 승인과 충전이 이루어지는 플러그-앤-차지(Plug-and-charge) 방식을 일컬으며, 무선 충전의 경우 충전 스테이션의 충전 스팟 위에 주차만 해두면 서비스 승인과 충전이 이루어지는 파크-앤-차지(Park-and-charge) 방식을 일컫는다.
EV가 PnC 서비스를 이용하기 위해서는, EV 소유주가 MO(Mobility Operator)와 서비스 이용계약을 체결해야 한다. 계약 체결 후에는 최초 충전시에 EV에 계약 인증서가 설치되며, 이후에는 해당 MO와 연관된 충전 스테이션에서 PnC 서비스를 받을 수 있다. 만약 EV가 계약 관계가 없는 MO와 연관된 충전 스테이션에서 PnC 서비스를 받고자 한다면, 로밍이 발생할 수 있다. EV에 유효한 계약 인증서가 이미 설치되어 있기만 하다면, 로밍 환경에서도 EV 소유주는 충전 서비스 이용에 큰 어려움이 없다.
그렇지만, 충전 스테이션을 방문한 EV에 유효한 계약 인증서가 없다면 PnC가 작동하지 않을 수 있다. 이러한 상황은 예컨대 EV가 출고 후 방문한 최초의 충전 스테이션이 EV가 계약 관계가 없는 MO의 네트웍에 속하는 충전 스테이션인 경우 발생할 수 있다. 또한, EV에 설치된 계약 인증서가 어떤 사정에 의해 유효하게 동작할 수 없는 때에는 계약 인증서가 업데이트되어야 하는데, 이처럼 업데이트가 필요한 상황에서도 위와 같이 PnC가 작동하지 않을 수 있다. 이와 같이 로밍 환경에서 계약 인증서의 설치나 업데이트가 필요한 상황이 발생할 수 있지만, 종래에는 이에 대한 대책이 없다고 할 수 있다. 따라서, 이처럼 PnC가 작동하지 않는 때에는, 외부 식별 수단(EIM)에 의해 요금결제를 해야만 하게 되어 EV 운전자가 번거롭게 불편하게 된다.
한편, 종래의 PnC에 따르면, EV가 충전 스테이션을 통해 충전 스테이션 운영자(CSO: Charging station operator)에 제출한 계약 인증서 체인을 CSO 또는 충전 서비스 제공자(CSP: Charge service provider)가 검증한다. 그런데, EV에는 계약 인증서 체인의 최상위 인증서인 MO 루트인증서(MO RootCA cert.)가 설치되어 있지 않기 때문에(ISO 15118-20 표준 2018. 7. 2.자 기준), EV가 로밍 상황에서 방문 CSO에 제출할 수가 없다. 이 경우 방문 CSO나 방문 CSP 역시 이 루트인정서를 구비하고 있지 않다면 검증이 홈 CSP 또는 별도의 클리어링 하우스에서나 가능하기 때문에, 승인 지연을 야기할 수 있게 된다.
본 발명은 전기차가 로밍 환경에 있더라도 계약 인증서의 설치나 업데이트가 가능하게 수 있도록 해주고, PnC 방식의 충전을 위한 승인이 정확하고 신속하게 이루어질 수 있게 해주는 방법과 장치를 제공한다.
본 발명의 일 측면에 따르면, 충전 서비스 제공 장치(CSP)에서의 계약 인증서 설치 지원 방법이 제공된다. 상기 계약 인증서 설치 지원 방법은 제1 전기차(EV)에 대한 제1 계약 인증서를 생성하는 단계와; 상기 제1 계약 인증서를 로밍 계약이 형성되어 있는 제1 외부 충전 서비스 제공 장치(CSP)에 전송하여, 상기 제1 계약 인증서가 로밍 상황에서 상기 제1 외부 CSP를 통해 상기 제1 EV에 설치될 수 있게 하는 단계;를 포함한다.
상기 제1 외부 CSP는 상기 충전 서비스 제공 장치와 로밍 계약이 성립되어 있는 모든 외부 CSP들을 포함할 수 있다.
상기 제1 외부 CSP는 모든 외부 CSP들을 포함할 수 있다.
상기 계약 인증서 설치 지원 방법은 상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송한 후에 소정의 기간이 경과하거나 상기 제1 계약 인증서가 상기 제1 EV에 설치되면, 상기 제1 외부 CSP에 설치대기 해제 요청을 송신하는 단계;를 더 포함할 수 있다.
상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송하는 단계는 상기 제1 계약 인증서를 포함한 계약 인증서 체인과, eMAID 정보를 포함하는 인증서 설치 패키지를 형성하는 단계와; 상기 인증서 설치 패키지를 상기 제1 CSP에 전송하는 단계;를 포함할 수 있다.
상기 인증서 설치 패키지는 상기 제1 계약 인증서에 연관된 인증서 폐기 목록과 온라인 인증서 상태 프로토콜(OCSP) 서버의 접속 정보를 포함할 수 있다.
상기 상기 계약 인증서 설치 지원 방법은 제2 EV에 대한 제2 계약 인증서를 제2 외부 CSP로부터 받아들이고, 인증서 프로비저닝 서비스 장치(CPS)에 전달하여 저장하게 하는 단계와; 상기 제2 EV가 서비스 네트웍에 진입한 로밍 상황에서 상기 제2 EV로부터 계약 인증서 설치 요청이 수신되면, 상기 CPS에 저장된 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 단계;를 더 포함할 수 있다.
상기 제2 외부 CSP는 상기 충전 서비스 제공 장치와 상기 로밍 계약이 성립되어 있는 모든 외부 CSP들 중 어느 하나일 수 있다.
상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 단계는 상기 제2 계약 인증서가 상기 제2 EV에 설치된 후에 상기 제2 외부 CSP에 설치 완료를 통보하는 단계;를 더 포함할 수 있다.
본 발명의 다른 측면에 따르면, PnC 방식에 의한 충전 서비스에 활용될 수 있는 충전 서비스 제공 장치가 제공된다. 상기 충전 서비스 제공 장치는 프로세서와; 상기 프로세서에 의해 실행될 수 있는 적어도 하나의 명령을 저장하는 메모리;를 포함한다. 상기 적어도 하나의 명령은 제1 전기차(EV)에 대한 제1 계약 인증서를 생성하고 상기 제1 계약 인증서를 제1 외부 충전 서비스 제공 장치(CSP)에 전송하여, 상기 제1 외부 CSP를 통해 상기 제1 계약 인증서가 상기 제1 EV에 설치될 수 있게 하는 명령; 제2 EV에 대한 제2 계약 인증서를 제2 외부 CSP로부터 받아들이고, 인증서 프로비저닝 서비스 장치(CPS)에 전달하여 저장하게 하는 명령; 및 상기 제2 EV가 서비스 네트웍에 진입한 로밍 상황에서 상기 제2 EV로부터 계약 인증서 설치 요청이 수신되면, 상기 CPS에 저장된 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 명령;을 포함한다.
상기 제1 외부 CSP는 상기 충전 서비스 제공 장치와 로밍 계약이 성립되어 있는 모든 외부 CSP들을 포함할 수 있으며, 상기 제2 외부 CSP는 상기 충전 서비스 제공 장치와 로밍 계약이 성립되어 있는 상기 모든 외부 CSP들 중 어느 하나일 수 있다.
상기 제1 외부 CSP는 모든 외부 CSP들을 포함할 수 있고, 상기 제2 외부 CSP가 상기 모든 외부 CSP들 중 어느 하나일 수 있다.
상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송하는 명령은 상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송한 후 소정의 기간이 경과하거나 상기 제1 계약 인증서가 상기 제1 EV에 설치되면, 상기 제1 외부 CSP에 설치대기 해제 요청을 송신하는 명령;을 포함할 수 있다.
상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 명령은 상기 제2 계약 인증서가 상기 제2 EV에 설치된 후에, 상기 제2 외부 CSP에 설치 완료를 통보하는 명령;을 포함할 수 있다.
상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송하는 단계는 상기 제1 계약 인증서를 포함한 계약 인증서 체인과, eMAID 정보를 포함하는 인증서 설치 패키지를 형성하는 단계와; 상기 인증서 설치 패키지를 상기 제1 CSP에 전송하는 단계;를 포함할 수 있다.
상기 인증서 설치 패키지는 상기 제1 계약 인증서와 연관된 인증서 폐기 목록과 온라인 인증서 상태 프로토콜(OCSP) 서버의 접속 정보를 포함할 수 있다.
본 발명의 또 다른 측면에 따르면, 로밍 환경에서의 피앤씨(PnC) 방식의 EV 충전 승인 방법이 제공된다. 상기 EV 충전 승인 방법은 제1 전기차(EV)에 대한 제1 계약 인증서를 생성하고 상기 제1 계약 인증서를 제1 외부 충전 서비스 제공 장치(CSP)에 전송하여, 상기 제1 외부 CSP를 통해 상기 제1 계약 인증서가 상기 제1 EV에 설치될 수 있게 하는 단계와; 제2 EV에 대한 제2 계약 인증서를 제2 외부 CSP로부터 받아들이고, 인증서 프로비저닝 서비스 장치(CPS)에 전달하여 저장하게 하는 단계와; 상기 제2 EV가 서비스 네트웍에 진입한 로밍 상황에서, 상기 제2 EV로부터 계약 인증서 설치 요청이 수신되면 상기 CPS에 저장된 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하고, 상기 제2 EV가 충전 승인 요청을 하면 상기 제2 EV에 상기 제2 계약 인증서가 설치된 상태를 토대로 승인을 하는 단계;를 포함한다.,
상기 제2 외부 CSP는 상기 충전 서비스 제공 장치와 로밍 계약이 성립되어 있는 모든 외부 CSP들 중 어느 하나일 수 있다.
상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 단계는 상기 제2 계약 인증서가 상기 제2 EV에 설치된 후에, 상기 제2 외부 CSP에 설치 완료를 통보하는 명령;을 포함할 수 있다.
상기 제2 계약 인증서를 상기 제2 외부 CSP로부터 받아들여 저장하는 단계는 상기 제2 계약 인증서를 포함한 계약 인증서 체인과 eMAID 정보를 포함하는 인증서 설치 패키지를 받아들여 저장하는 단계;를 포함할 수 있다.
본 발명의 일 실시예에 따르면, EV의 인증서 설치 요청이나 업데이트 요청에 대비하여 홈 충전 서비스 제공자(CSP)가 상기 EV에 대한 계약 인증서를 실질적으로 모든 CSP들에 사전 배포함으로써, EV가 로밍 환경에서 인증서 설치 요청이나 업데이트 요청을 하더라도 즉각적으로 방문 CSP가 계약 인증서를 EV에 제공하여 설치될 수 있게 해준다. 따라서, 로밍 환경에서도 EV에 계약 인증서 체인의 설치나 업데이트가 가능해지며, EV의 PnC 방식 충전이 원활해지고 EV 이용자의 편의성이 향상될 수 있다.
한편, 계약 인증서 이외에도 다양한 인증서가 방문 CSP, 방문 CSO, 및 이에 연관된 CS에 설치될 수 있기 때문에, 각 엔티티의 대응능력이 향상되고 전기차에 대한 승인 과정에 융통성이 부여될 수 있게 된다.
도 1은 본 발명의 일 실시예가 적용될 수 있는 전기차 유선 충전 방법을 설명하기 위한 개념도이다.
도 2는 본 발명의 일 실시예가 적용될 수 있는 전기차에 대한 무선 전력 전송을 설명하기 위한 개념도이다.
도 3은 본 발명의 일 실시예에 따른 EV 충전 기반구조의 블록도이다.
도 4는 본 발명의 일 실시예에 적용되는 인증서 계층 구조의 일 예를 보여주는 도면이다.
도 5는 EV에 대한 로밍 서비스를 설명하기 위하여 PnC 충전 기반구조를 구성하는 노드들을 예시적으로 보여주는 도면이다.
도 6은 로밍이 필요하지 않은 상황과 필요한 상황들의 예를 보여주는 도면이다.
도 7은 로밍이 필요하지 않은 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다.
도 8은 직접 로밍이 이루어지는 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다.
도 9는 간접 로밍이 이루어지는 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다.
도 10은 즉석 직접 로밍(on-the-fly direct roaming)이 이루어지는 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다.
도 11은 즉석 간접 로밍(on-the-fly indirect roaming)이 이루어지는 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다.
도 12는 본 발명의 일 실시예에 있어서 홈 CSP로부터 직접 로밍을 통해 EV에 전달되어 설치되는 계약 인증서의 전달 경로를 보여주는 도면이다.
도 13은 도 12에 도시된 인증서 전달 과정을 보다 상세하게 보여주는 흐름도이다.
도 14는 본 발명의 일 실시예에 있어서 홈 CSP로부터 간접 로밍을 통해 EV에 전달되어 설치되는 계약 인증서의 전달 경로를 보여주는 도면이다.
도 15는 도 14에 도시된 인증서 전달 과정을 보다 상세하게 보여주는 흐름도이다.
도 16은 본 발명의 다른 실시예에 있어서 계약에 따른 서비스 승인 과정을 보여주는 흐름도이다.
도 17은 본 발명의 일 실시예에 따른 CSP의 블록도이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.
제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는 데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. "및/또는"이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
본 명세서에 사용되는 일부 용어를 정의하면 다음과 같다.
'전기차(Electric Vehicle, EV)'는 49 CFR(code of federal regulations) 523.3 등에서 정의된 자동차(automobile)를 지칭할 수 있다. 전기차는 고속도로 이용 가능하고, 차량 외부의 전원공급원으로부터 재충전 가능한 배터리 등의 차량 탑재 에너지 저장 장치에서 공급되는 전기에 의해 구동될 수 있다. 전원공급원은 주거지나 공용 전기서비스 또는 차량 탑재 연료를 이용하는 발전기 등을 포함할 수 있다. 전기차(electric vehicle, EV)는 일렉트릭 카(electric car), 일렉트릭 오토모바일(electric automobile), ERV(electric road vehicle), PV(plug-in vehicle), xEV(plug-in vehicle) 등으로 지칭될 수 있고, xEV는 BEV(plug-in all-electric vehicle 또는 battery electric vehicle), PEV(plug-in electric vehicle), HEV(hybrid electric vehicle), HPEV(hybrid plug-in electric vehicle), PHEV(plug-in hybrid electric vehicle) 등으로 지칭되거나 구분될 수 있다.
'플러그인 전기차(Plug-in Electric Vehicle, PEV)'는 전력 그리드에 연결하여 차량 탑재 일차 배터리를 재충전하는 전기차를 지칭할 수 있다.
'무선 충전 시스템(WCS: Wireless power charging system)'은 무선전력전송과 얼라인먼트 및 통신을 포함한 GA와 VA 간의 제어를 위한 시스템을 지칭할 수 있다.
'무선 전력 전송(Wireless power transfer, WPT)'은 유틸리티(Utility)나 그리드(Grid) 등의 교류(AC) 전원공급 네트워크에서 전기차로 무접촉 수단을 통해 전기적인 전력을 전송하는 것을 지칭할 수 있다.
'유틸리티(Utility)'는 전기적인 에너지를 제공하며 통상 고객 정보 시스템(Customer Information System, CIS), 양방향 검침 인프라(Advanced Metering Infrastructure, AMI), 요금과 수익(Rates and Revenue) 시스템 등을 포함하는 시스템들의 집합으로 지칭될 수 있다. 유틸리티는 가격표 또는 이산 이벤트(discrete events)를 통해 플러그인 전기차가 에너지를 이용할 수 있도록 한다. 또한, 유틸리티는 관세율, 계측 전력 소비에 대한 인터벌 및 플러그인 전기차에 대한 전기차 프로그램의 검증 등에 대한 정보를 제공할 수 있다.
'스마트 충전(Smart charging)'은 전력 그리드와 통신하면서 EVSE 및/또는 플러그인 전기차가 차량 충전율이나 방전율을 그리드 용량이나 사용 비용 비율의 시간에 따라 최적화하는 시스템을 지칭할 수 있다.
'상호운용성(Interoperabilty)'은 서로 상대적인 시스템의 성분들이 전체 시스템의 목적하는 동작을 수행하기 위해 함께 작동할 수 있는 상태를 지칭할 수 있다. 정보 상호운용성(Information interoperability)은 두 개 이상의 네트워크들, 시스템들, 디바이스들, 애플리케이션들 또는 성분들이 사용자가 거의 또는 전혀 불편함 없이 안전하고 효과적으로 정보를 공유하고 쉽게 사용할 수 있는 능력을 지칭할 수 있다.
'유도 충전 시스템(Inductive charging system)'은 두 파트가 느슨하게 결합된 트랜스포머를 통해 전기 공급 네트워크에서 전기차로 정방향에서 전자기적으로 에너지를 전송하는 시스템을 지칭할 수 있다. 본 실시예에서 유도 충전 시스템은 전기차 충전 시스템에 대응할 수 있다.
'유도 결합(Inductive coupling)'은 두 코일들 간의 자기 결합을 지칭할 수 있다. 두 코일은 그라운드 어셈블리 코일(Ground assembly coil)과 차량 어셈블리 코일(Vehicle assembly coil)을 지칭할 수 있다.
'OEM(Original Equipment Manufacturer)'은 전기차 제조업체가 운영하는 서버로서 OEM 루트인증서를 발급하는 최상위 인증기관(CA)을 지칭할 수 있다.
'모빌리티 운영자(MO: Mobility operator)'는 EV 운전자가 충전 스테이션에서 EV를 충전할 수 있도록 EV 소유자와 충전, 승인, 및 결제에 관한 계약 관계를 맺고 있는 서비스 제공자를 지칭할 수 있다.
'충전 스테이션(CS: Charging station)'은 하나 이상의 EV 전력공급장치를 구비하며 EV에 대한 충전을 실제로 실행하는 시설을 지칭할 수 있다.
'충전 스테이션 운영자(CSO: Charging station operator)'는 요청된 에너지 전송 서비스를 제공하기 위하여 전기를 관리하는 엔티티를 지칭할 수 있으며, 충전 포인트 운영자(CPO: Charge point operator)와 동일한 개념의 용어일 수 있다.
'충전 서비스 제공자(CSP: Charge service provider)'는 EV 사용자의 크리덴셜을 관리하고 인증하며, 요금청구 및 기타 부가가치 서비스를 고객에게 제공하는 역할을 하는 엔티티를 지칭할 수 있으며, MO의 특별한 유형에 해당한다고 볼 수 있고 MO와 합체된 형태로 구현될 수도 있다
'클리어링 하우스(CH: Clearing house)'는 MO들, CSP들, 및 CSO들 사이의 협력 사항을 처리하는 엔티티로서, 특히 두 정산 내지 청산 당사자 사이에서 EV 충전 서비스 로밍에 대한 승인, 요금청구, 정산 절차를 원활하게 해주는 중간 관여자 역할을 할 수 있다.
'로밍(roaming)'은 EV 사용자들이 하나의 크리덴셜과 계약을 사용하여, 다수의 모빌리티 네트웍에 속하는 다수의 CSP들 또는 CSO들에 의해 제공되는 충전 서비스를 접근할 수 있게 해주는 정보 교환 및 관련 사항(provision)과 체계(scheme)를 지칭할 수 있다.
'크리덴셜(credential)'은 EV 또는 EV 소유주의 개인 정보를 나타내는 물리적 또는 디지털 자산으로서, 신원을 검증하기 위해 사용하는 암호학적 정보인 패스워드, 공개키 암호 알고리즘에서 사용하는 공개키/개인키 쌍, 인증기관이 발행하는 공개키 인증서, 신뢰하는 루트 인증기관 관련 정보 등을 포함할 수 있다.
'인증서(Certificate)'는 디지털 서명에 의해 공개키를 ID와 바인딩하는 전자 문서를 지칭할 수 있다.
'서비스 세션'은 고유의 식별자를 가진 일정한 타임프레임에서의 어떤 고객에게 할당된, 충전 지점에서의 전기차 충전에 관한 서비스들의 집합을 지칭할 수 있다.
'전자모빌리티 계정 식별자(eMAID: e-Mobility Account Identifier)'는 계약 인증서를 EV 소유주의 결제 계정에 연결시키는 EV 고유 식별자를 지칭할 수 있다.
이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.
본 발명을 구현하기 위한 전기차 충전 시스템에서, 전기차(EV)는 충전 스테이션에 유선 또는 무선 링크를 통해 접속되어 충전 스테이션으로부터 에너지를 공급받고, 공급받은 에너지로 예컨대 배터리와 같은 에너지저장장치를 충전시킬 수 있다. 도 1과 도 2는 유선과 무선으로 전기차를 충전하는 방법을 각각 보여준다.
도 1은 본 발명의 일 실시예가 적용될 수 있는 전기차 유선 충전 방법을 설명하기 위한 개념도이다. 전기차 유선 충전은 전기차(10, 이하 'EV'라 칭함)를 충전 케이블(30)에 의해 충전 스테이션의 전력공급회로에 접속시킴으로써, 예컨대 충전 스테이션(20)의 케이블 커넥터를 EV(10)의 잭에 접속시킴으로써, 수행될 수 있다.
여기서, EV(10)는 배터리와 같이 충전가능한 에너지저장장치에서 공급되는 전력을 동력장치인 전기 모터의 에너지원으로 공급하는 차량(automobile)으로 정의할 수 있다. 상기 EV(10)는 전기 모터와 일반적인 내연기관을 함께 갖는 하이브리드 자동차일 수 있고, 자동차(automobile)뿐만 아니라 모터사이클(motocycle), 카트(cart), 스쿠터(scooter) 및 전기 자전거(electric bicycle)일 수도 있다.
EV(10)는 충전 케이블(30)의 커넥터에 접속될 수 있는 플러그 접속구 내지 리셉터클을 포함할 수 있다. EV(10)에 구비되는 상기 플러그 접속구는 완속 충전을 지원하거나 급속 충전을 지원할 수 있다. 이때, EV(10)는 하나의 플러그 접속구를 통해 완속 충전과 급속 충전을 모두 지원하거나, 각각이 완속 충전과 급속 충전을 지원하는 복수의 플러그 접속구들을 포함할 수 있다.
본 발명에 따른 EV(10)는 완속 충전 또는 일반적인 전력 계통에서 공급되는 교류 전력을 통한 충전을 지원하기 위하여 온보드 충전기(On Board Charger)를 포함할 수 있다. 온보드 충전기는 완속 충전시 외부에서 유선으로 공급되는 교류 전력을 승압하고 직류 전력으로 변환하여 EV(10)에 내장된 배터리에 공급할 수 있다. 한편, 플러그 접속구에 급속 충전을 위한 직류 전력이 공급되는 경우에는, 상기 직류전력이 온보드 충전기를 거치지 않고 배터리에 공급되어 충전시킬 수 있다.
한편, EV 충전 케이블(30)은 충전 커넥터(31), 콘센트 소켓 접속부(33) 및 인케이블 컨트롤 박스(ICCB; In-cable control box)(32) 중 적어도 하나를 포함하여 구성될 수 있다. 충전 커넥터(31)는 EV(10)와 전기적으로 연결할 수 있는 접속부일 수 있고, 인케이블 컨트롤 박스(32)는 EV(10)와 통신하여 EV의 상태 정보를 수신하거나 EV(10)로의 전력 충전을 제어할 수 있다. 인케이블 컨트롤 박스(32)는 EV 충전 케이블(10)에 포함되는 것으로 도시하였으나, EV 충전 케이블(10) 이외의 장소, 예컨대 충전 스테이션에서 EV(10)에 전력을 공급하는 전력공급회로(미도시)에 접속되거나 상기 전력공급회로 내에 배치될 수 있다. 콘센트 소켓 접속부(33)는 일반적인 플러그나 코드셋 등의 전기 접속 기구로서 충전 스테이션의 충전 장치에 접속될 수 있다.
한편, 전력 소켓(40)은 충전 스테이션의 충전 장치와 충전 커넥터(31)의 접속 지점을 의미한다. 그렇지만, 본 발명이 이에 한정되는 것은 아니며, 전력 소켓(40)이 여타의 장소에 설치된 충전 장치와 충전 커넥터(31) 간의 접속 지점을 의미할 수도 있다. 예컨대, 전력 소켓(40)은 상업적인 전문 충전 스테이션 시설 이외에, EV(10) 소유자의 집에 부속된 주차장, 주유소에서 EV 충전을 위해 할당된 주차구역, 쇼핑 센터나 직장의 주차구역 등과 같은 충전 시설물에 설치된 월 잭(wall jack)을 나타낼 수도 있다.
도 2는 본 발명의 일 실시예가 적용될 수 있는 전기차에 대한 무선 전력 전송을 설명하기 위한 개념도이다.
EV에 대한 무선전력전송(WPT: wireless power transfer)은 공급 네트워크로부터의 전기 에너지를 갈바닉 연결을 통한 전류 흐름 없이 자기공명 상태에서 자기장을 통해서 공급자측 디바이스로부터 소비자측 디바이스로 전달하는 것으로 정의될 수 있다. 무선전력전송은 충전 스테이션(charging station, 10)에서 EV(10)로 전력을 전송하여 EV(10)를 충전하는데 활용될 수 있다.
도 2를 참조하면, 무선 전력 전송은 EV(10)에 무선으로 전력을 전송하기 위해서 EV(10)의 적어도 하나의 구성요소와 충전 스테이션(20)에 의해서 수행될 수 있다.
EV(10)는 충전 스테이션(20)으로부터 무선으로 자기 에너지를 받아들이기 위한 수신 코일을 구비하는 수신 패드(11)를 포함할 수 있다. 수신 패드(11)에 있는 수신 코일은 충전 스테이션(20)에 있는 송신 패드(21)의 송신 코일로부터 예컨대 자기공명에 의해 자기 에너지를 받아들인다. EV(10)에서 수신된 자기 에너지는 유도전류로 변환되고, 상기 유도전류는 직류전류로 정류된 후 배터리(12)를 충전시키게 된다.
충전 스테이션(20)은 상용 전력망(power grid, 50) 내지 전력 백본으로부터 전력을 받아들이고, 송신 패드(21)를 통해 EV(10)에 에너지를 공급할 수 있다. 송신 패드(21)는 송신 코일을 구비한다. 송신 패드(21)에 있는 송신 코일은 자속을 발생하고, 자기공명에 의해 증폭된 자기 에너지를 EV(10)에 공급할 수 있다. 충전 스테이션(20)은 예컨대 EV(10) 소유자의 집에 부속된 주차장, 주유소에서 EV 충전을 위한 주차구역, 쇼핑센터나 업무용 건물의 주차구역 등과 같이 다양한 장소에 위치할 수 있다.
충전 스테이션(20)은 유무선 통신을 통하여 전력망(50)을 관리하는 전력 기반구조 관리 시스템(power infrastructure management system) 내지 인프라 서버와 통신할 수 있다. 또한, 충전 스테이션(20)은 EV(10)와도 무선 통신을 수행할 수 있다. 여기서, 무선 통신은 IEEE 802.11 규약에 따른 와이파이(WiFi)를 기반으로 한 무선랜(WLAN)을 포함할 수 있으며, 저주파(LF: Low frequency) 자기장 신호 및/또는 저출력 자기장(LPE: Low Power Excitation) 신호를 이용한 P2PS 통신을 더 포함할 수 있다. 아울러, 충전 스테이션(20)과 EV(10) 간의 무선 통신은 블루투스(Bluetooth), 지그비(zigbee), 셀룰러(cellular) 등 다양한 통신방식 중 하나 이상을 포함할 수 있다.
한편, 전기차 충전을 위한 통신 표준 문서인 ISO 15118에 따르면, EV 및 EV 충전 스테이션은 메시지를 교환하여 전체 충전 프로세스를 제어한다. 즉, 차량측 통신제어기(EVCC; Electric Vehicle Communication Controller)와 전력공급측 통신제어기(SECC; Supply Equipment Communication Controller) 사이에 전기차 충전을 위한 통신이 무선랜(WLAN)을 통해 이루어질 수 있다.
통신 과정에서 EV는 먼저 충전 스테이션이 신뢰할 수 있는 시설인지 확인하기 위해 충전 스테이션의 신원을 확인하고, 무단 액세스로부터 통신을 보호하기 위해 충전 스테이션과 보안 채널을 설정한다. 이러한 목표는 IETF RFC 5246에 정의된 표준화된 TLS(Transport Layer Security)에 의해 달성될 수 있다. TLS 세션은 IP 기반의 통신 연결 성립 절차 이후에 TLS 세션 설립 절차에 의해 생성될 수 있다.
도 3은 본 발명의 일 실시예에 따른 EV 충전 기반구조의 블록도이다.
EV 충전 기반구조는 EV(10)에 충전 서비스를 제공하기 위한 것으로서, 전기차 제조업체(Original Equipment Manufacturer) 서버(100), 모빌리티 운영자(MO: Mobility operator)(110), 인증서 프로비저닝 서비스(CPS: Certificate provisioning serveice)(120), 계약 인증서 풀(CCP: Contract certificate pool)(130), 비클-투-그라운드(V2G: Vehicle-to-ground) 서버(150), 충전 스테이션(CS: Charging Station(200), 충전 서비스 운영자(CSO: Charging station operator)(210), 충전 서비스 제공자(CSP: Charge service provider)(220), 및 클리어링 하우스(CH: Clearing house)(230)를 포함한다.
EV(100)는 EV 소유자가 소유한 일반적인 자동차를 지칭하며, 충전 스테이션에서 유선 또는 무선으로 충전이 가능하다. EV(100)에는 고유한 제조 과정에서 OEM 프로비저닝 인증서가 설치된다. 그리고, 차량 구매계약과 MO(110) 운영자와의 계약이 완료되면, EV(100)에는 계약 인증서가 설치될 수 있다. 아울러, EV(100)에는 비클-투-그라운드(V2G) 루트인증서가 설치될 수 있다.
전기차 제조업체(Original Equipment Manufacturer) 서버(100, 이하 'OEM'으로 약칭함)은 OEM 루트인증서를 발급하는 최상위 인증기관(CA)이며, 그 하위 인증기관(OEM SubCA 1, OEM SubCA 2)도 운영, 유지한다. EV(10)가 제조될 때. OEM(100)은 OEM 중간체인인증서(OEM SubCA 2 cert.)를 사용하여 OEM 프로비저닝 인증서를 생성하고 EV(10)에 설치한다.
모빌리티 운영자(MO: Mobility operator)(110)는 EV 운전자가 충전 스테이션에서 EV를 충전할 수 있도록 EV 소유자와 충전, 승인, 및 결제에 관한 계약 관계를 맺고 있는 서비스 제공자이다. EV가 현재의 충전 스테이션에서 충전 서비스를 받으려면, 현재의 충전 스테이션이 MO에 속하거나 로밍 시나리오를 지원해야 한다. MO(110)는 에너지를 판매하는 전기 공급자 또는 전기 도매업자에 의해 운영될 수 있다. MO(110)는 MO 루트인증서를 발급하는 최상위 인증기관(CA)으로도 작용한다. MO 루트인증서와 그 하위 CA들이 생성하는 MO 중간체인인증서들로 구성되는 MO 인증서 체인은 계약 인증서를 생성할 때 사용될 수 있다. 아울러, 본 발명에 따르면 MO 인증서 체인은 EV(10)에 설치된 계약 인증서를 비-로밍 환경이나 로밍 환경에서 검증하는 데에도 사용된다. MO는 '이모빌리티 서비스 공급자(EMSP: E-mobility service provider)'로 칭해질 수도 있다.
인증서 프로비저닝 서비스(CPS: Certificate provisioning serveice)(120)는 EV에 계약 인증서가 설치되거나 업데이트되는 과정에서 계약 인증서 체인과 함께, 인증서 송수신에 사용되는 암호화 키 등을 EV와 같은 클라이언트에 제공한다. CPS(120)에는 리프 프로비저닝 인증서(Leaf Prov cert.)와 프로비저닝 중간체인인증서들(Prov SubCA 1 cert., Prov SubCA 2 cert.)이 장착되어 있다. EV(100)에 계약 인증서가 설치되거나 업데이트될 때, CPS(130)는 계약 인증서 체인과 함께 각 MO의 공개키, 디피-헬만(DH) 공개키, 및 eMAID를 제공하는 프로비저닝 서비스를 공급함으로써, EV가 이들을 사용하여 계약 인증서 체인을 검증하고 계약 인증서의 무결성과 신뢰성을 확인할 수 있게 해준다.
계약 인증서 풀(CCP: Contract certificate pool)(130)은 EV에 계약 인증서가 설치되거나 업데이트되는 과정에서 설치 또는 업데이트에 대한 응답 메시지를 임시로 저장한다. ISO 15118 표준에서 정한 설치 및 업데이트 제한시간이 매우 짧고 엄격한 점을 감안하여, 상기 응답 메시지는 미리 CCP(140)에 저장되고 설치 또는 업데이트가 완전히 완료될 때까지 유지된다. 계약 인증서 설치 또는 업데이트가 이루어지는 EV가 여러 대일 수 있기 때문에 상기 응답 메시지는 참조번호가 부가된 후 디렉토리 형태로 유지된다.
비클-투-그라운드(V2G: Vehicle-to-ground) 서버(150, 이하 'V2G'로 약칭함)는 도시된 EV 충전 기반구조에서 공개키 기반구조(PKI: Public key Infrastructure) 와 관련하여 최상위 인증기관으로 작용한다. 따라서 V2G(150)은 최상위 신뢰 앵커 역할을 하게 되며, 도 3에 도시된 모든 관여자들(actors)은 V2G 루트CA를 신뢰할 수 있는 조직으로 간주하게 된다.
충전 스테이션(CS: Charging station)(200)은 EV(100)에 대한 충전을 실제로 실행한다. 충전 스테이션(200)은 적어도 하나의 유선 충전기 및/또는 무선충전 스팟을 구비할 수 있다. 충전 스테이션(200)은 상업적인 전문 충전 시설에 하나 이상 설치될 수 있다. 또한 충전 스테이션(200)은 EV 소유자의 주택에 부속된 주차장, 주유소에서 EV 충전을 위한 주차구역, 쇼핑센터나 직장의 주차구역 등과 같이 다양한 장소에 위치할 수도 있다. 충전 스테이션(200)은 '충전 포인트', 'EV 충전소', '전기 충전 포인트', '충전 포인트', '전자 충전 스테이션(ECS)', 및 'EV측 전력공급장치(EVSE)'라고 지칭될 수도 있다.
충전 스테이션 운영자(CSO: Charging station operator)(210) 내지 충전 포인트 운영자(CPO: Charge point operator)는 충전 스테이션의 운영과, 요청된 에너지 전송 서비스를 제공하기 위하여 전기를 관리한다. CSO(210)는 예컨대 충전 스테이션 제조사, 충전소 제조사, 또는 전기 공급자에 의해 운영될 수 있다. PKI와 관련하여, CSO(210)는 각 충전 스테이션에 대한 SECC 리프 인증서를 생성하는 데 필요한 하위 인증기관들(CPO SubCA 1, CPO SubCA 2)을 운영한다.
충전 서비스 제공자(CSP: Charge service provider)(220)는 EV 사용자의 크리덴셜을 관리하고 인증하며, 요금청구 및 기타 부가가치 서비스를 고객에게 제공한다. CSP(220)는 MO(110)의 특별한 유형에 해당한다고 볼 수 있고, MO(110)와 합체된 형태로 구현될 수도 있다. CSP(220)는 복수 개 존재할 수 있고, 각 CSP(220)는 하나 이상의 CSO(210)에 연계되어 있으며, 상기 CSP(220)와 상기 하나 이상의 CSO(210)는 하나의 충전 네트웍을 구성한다. EV(110)는 계약관계에 있는 MO(100)와 연관되어 있는 CSP(220)에 연계된 CSO(210)에서는 PnC 방식으로 충전 서비스를 받을 수 있지만, 다른 CSO(210)에서 충전을 하고자 하는 경우에는 로밍이 필요하다. 각 CSP(200)는 로밍을 위하여 다른 CSP 또는 다른 네트웍에 있는 CSO(210)와 정보 교환을 할 수 있고, 또한 클리어링 하우스(230)와도 정보 교환을 할 수 있다.
클리어링 하우스(CH: Clearing house)(230)는 MO들(110) 내지 CSP들(220) 사이의 협력 사항을 처리한다. 즉, 클리어링 하우스(CH)(230)는 두 정산 내지 청산 당사자 사이에서 EV 충전 서비스 로밍에 대한 승인, 요금청구, 정산 절차를 원활하게 해주는 중간 관여자 역할을 할 수 있다. EV 운전자가 자신이 계약관계를 맺고 있는 MO(110)의 네트웍에 속하지 않는 충전 스테이션에서 EV를 충전하고자 하는 경우, CH(230)는 CSO(210) 또는 CSP(220)에 의해 연결되어 로밍이 이루어지도록 지원할 수 있다. 로밍이 필요한 상황에서. CH(230)는 CSO(210) 또는 CSP(220)가 MO(110)와 계약을 맺고 승인 및 청구 데이터(CDR)를 MO(110)로 전달할 수 있게 해준다. CH(230)는 '계약 클리어링 하우스(CCH: Contract clearing house)', '모빌리티 클리어링 하우스(MCH: Mobility clearing house)', '로밍 플랫폼(roaming platform)', '이-모빌리티 클리어링 하우스(E-MOCH: E-MObility clearing house)' 등으로 지칭될 수도 있다.
상기 '충전 서비스 운영자(CSO)', '인증서 프로비저닝 서비스(CPS)', '모빌리티 운영자(MO)', '계약 클리어링 하우스(CCH)', 및 'V2G'는 사람을 지칭하거나 사람들의 조직을 지칭하는 것으로 보일 수 있지만, 청구범위를 포함하여 본 명세서에서 이들 표현은 하드웨어, 소프트웨어, 및/또는 이들의 결합으로 구현되는 것으로서, 가독성을 높일 수 있도록 짧게 그리고 기능적으로 명칭이 부여된 것이다. 일 실시예에 있어서, 이들 컴포넌트들은 하드웨어와 스프트웨어의 결합으로 구현되고 인터넷과 같은 네트웍을 통해 다른 디바이스들의 접근을 허용하는 서버 장치일 수 있다. 이들 컴포넌트들은 기능적으로 구분된 것이기 때문에, 이들 중 둘 이상이 하나의 물리적 장치 내에 격납되어 실행될 수도 있고, 하나의 프로그램으로 통합될 수도 있다. 특히, 단일 엔티티가 CSO와 CSP의 역할을 겸할 수 있으며, 다른 단일 엔티티가 CPS와 CCP의 역할을 겸할 수 있다. 한편 상기 컴포넌트들 중 하나 이상은 다른 외형 및 명칭을 가질 수 있도록 재편성될 수도 있다.
한편, EV 충전 서비스 및 관련 기반구조는 자동차, 전력 그리드, 에너지, 수송, 통신, 금융, 전자제품 등 다양한 산업분야가 접목되는 분야이고, 다양한 관점에서 표준화 작업이 병행되어왔을 뿐만 아니라, 복수의 국제표준화기구에서의 표준화와 별도로 개별국 단위의 표준화도 진행되어왔기 때문에, 유사한 개념의 용어가 많다. 특히, 충전 서비스 운영자(CSO: charging station operator)는 충전 포인트 운영자(CPO: charge point operator)와 역할과 기능 측면에서 공통점이 있으며, 일부 기능상의 차이점과 뉘앙스 차이가 있을 수 있지만 실질적으로 동일한 엔티티를 지칭하는 용어일 수 있다. 또한, 충전 서비스 운영자(CSP: charging service provider)는 모빌리티 운영자(MO: mobility operator)와 역할과 기능 측면에서 적어도 부분적으로 공통점이 있으며, 혼용되거나 뒤바뀌어 사용될 수 있는 용어들일 수 있다. 청구범위를 포함하여 본 명세서를 해석함에 있어서는 이와 같은 현실의 사정을 감안하여야 한다.
도 3에 도시된 기반구조에서는, PnC를 작동시키는데 필요한 기초로서 공개키 기반구조(PKI)가 사용된다. PKI는 사람과 장치의 신원 확인, 기밀 통신 활성화, 리소스에 대한 제어된 액세스 보장을 위한 프레임 워크를 제공한다. 도 4는 본 발명의 일 실시예에 적용되는 PKI-기반 인증서 계층 구조의 일 예를 보여준다. 도시된 인증서 계층 구조는 ISO 15118 표준에 따른 것이다.
도 4을 참조하면, OEM(100)은 OEM 루트인증서(OEM RootCA cert.)를 발급하는 최상위 인증기관(CA)으로 작용하며, 그 하위 인증기관(OEM SubCA 1, OEM SubCA 2)도 운영한다. 따라서, OEM(100)은 OEM 루트인증서(OEM RootCA cert.)와 아울러, 자신의 개인키로 서명하여 OEM 중간체인인증서(OEM SubCA 1 cert. cert., OEM SubCA 2 cert.)를 생성한다. EV가 제조될 때, OEM(100)의 2차 중간CA(OEM SubCA 2)는 OEM 2차 중간체인인증서(OEM SubCA 2 cert.)에 포함된 공개키와 쌍을 이루는 개인키를 사용하여 OEM 프로비저닝 인증서(OEM Prov cert.)를 생성하고 이를 EV(10)에 설치한다. 이 OEM 프로비저닝 인증서(OEM Prov cert.)는 EV(10)에 대한 인증서 설치 요청 과정에서 요청 메시지의 서명을 확인하는데 사용될 수 있으며, EV(10)의 수명동안 차량을 고유하게 식별하게 해준다.
MO(110)는 MO 루트인증서(MO RootCA cert.)를 발급하는 최상위 인증기관(CA)으로도 작용한다. MO(110)는 1차 하위 CA(MO SubCA 1)의 ID와 공개키에 자신의 서명을 추가하여 1차 중간체인인증서(MO SubCA 1 cert.)를 생성할 수 있다. MO 1차 하위 CA(MO SubCA 1)는 2차 하위 CA(MO SubCA 2)의 ID와 공개키에 자신의 서명을 추가하여 2차 중간체인인증서(MO SubCA 2 cert.)를 생성할 수 있다. EV가 출고될 때 MO(110) 운영자와 EV 소유주간에 체결되는 계약을 토대로, MO(110)의 2차 중간CA(MO SubCA 2)는 MO 2차 중간체인인증서(MO SubCA 2 cert.)에 포함된 공개키와 쌍을 이루는 개인키를 사용하여 계약 인증서(Contract Certificate)를 생성하고 이를 예컨대 EV(10)가 최초에 방문하는 CS(200)를 통해서 EV(10)에 설치한다. 계약 인증서는 전자모빌리티 계정 식별자(eMAID: e-Mobility Account Identifier)라는 고유 식별자를 통해 EV 소유주의 결제 계정에 연결된다.
도시된 바와 같이, OEM 프로비저닝 인증서(OEM Prov cert.)와 계약 인증서(Contract Certificate)는 OEM(100)과 MO(110)가 자체적으로 생성한 루트 인증서들(OEM RootCA cert., MO RootCA cert.)을 각각 토대로 하여 생성되며, 전역 루트인증서(V2G RootCA cert.)를 토대로 생성되고 다른 관여자들(actors)이 사용하는 인증서들과 독립적이다. 그렇지만, 도 3에서 쇄선으로 표시된 바와 같이, OEM(100)과 MO(110)의 루트 인증서들(OEM RootCA cert., MO RootCA cert.) 대신에 V2G 루트인증서(V2G RootCA cert.)를 사용하여, OEM 프로비저닝 인증서(OEM Prov cert.)와 계약 인증서(Contract Certificate)를 생성할 수는 있게 되어 있다.
V2G(150)는 적어도 두 계열의 인증서들 즉, CSO(210, 위에서 언급한 바와 같이 'CPO‘와 유사어임) 및 CS(200)를 위한 인증서 계열과, 프로비저닝 서비스를 위한 인증서 계열을 생성할 수 있게 해준다.
먼저, V2G(150)는 CPO 1차 하위 CA(CPO SubCA 1)의 ID와 공개키에 자신의 서명을 추가하여 1차 중간체인인증서(CPO SubCA 1 cert.)를 생성할 수 있다. CPO 1차 하위 CA(MO SubCA 1)는 CPO 2차 하위 (CPO SubCA 2)의 ID와 공개키에 자신의 서명을 추가하여 2차 중간체인인증서(CPO SubCA 2 cert.)를 생성할 수 있다. CPO 2차 중간CA(CPO SubCA 2)는 CPO 2차 중간체인인증서(CPO SubCA 2 cert.)에 포함된 공개키와 쌍을 이루는 개인키를 사용하여 SECC 리프 인증서(SECC Leaf Certificate)를 생성하고 이를 CS(200)에 전송하여 설치되게 할 수 있다. 이 SECC 리프 인증서(SECC Leaf Certificate)는 EV(10)가 가짜 충전 스테이션이 아니라 실제 충전 스테이션과 통신하는지 확인하기 위해 TLS 통신 설정 중에 EV(10)에 의해 사용될 수 있다. 이 인증서는 CS(200) 뿐만 아니라 CSO(210)의 백엔드 내부에도 저장되된다.
V2G(150)는 프로비저닝 1차 하위 CA(Prov SubCA 1)의 ID와 공개키에 자신의 서명을 추가하여 1차 중간체인인증서(Prov SubCA 1 cert.)를 생성할 수 있다. 프로비저닝 1차 하위 CA(Prov SubCA 1)는 프로비저닝 2차 하위 (Prov SubCA 2)의 ID와 공개키에 자신의 서명을 추가하여 2차 중간체인인증서(Prov SubCA 2 cert.)를 생성할 수 있다. 프로비저닝 2차 중간CA(CPO SubCA 2)는 프로비저닝 2차 중간체인인증서(Prov SubCA 2 cert.)에 포함된 공개키와 쌍을 이루는 개인키를 사용하여 리프 프로비저닝 인증서(Leaf Prov Certificate)를 생성하고 이를 인증서 프로비저닝 서비스(CPS, 120)에 전송하여 설치되게 할 수 있다.
한편, 각 루트CA(V2G RootCA, MO RootCA, OEM RootCA)는 OCSP 인증서를 발급하여 제공할 수 있어서, 제반 클라이언트들이 온라인 인증서 상태 프로토콜(OCSP: Online Certificate Status Protocol)에 따라서 OCSP 서버에 접속하여 인증서의 유효성에 관한 해지/미해지 상태 정보를 요청하고 조회결과를 수신할 수 있게 해준다. 도면에는 단순하게 표시하기 위해 OCSP 인증서가 CPO 하위 CA들(CPO SubCA 1, CPO SubCA 2)에 대해서만 이용할 수 있는 것처럼 도시되어 있지만, 모든 루트CA들(V2G RootCA, MO RootCA, OEM RootCA)이 자신의 루트인증서 계열의 인증서들에 대하여 유효성을 조회할 수 있도록 OCSP 인증서를 발급하여 제공할 수 있다.
본 발명의 실시예들에서는, 일반적으로 가용한 3가지 방식으로 인증서를 확인하거나 검증한다. 첫 번째로, 인증서 수신자가 인증서에 있는 서명값을 인증서에 있는 공개키로 복호화하여 해쉬를 복원하고, 복원된 해쉬를 인증서에 포함되어 있는 해쉬와 동일한지 비교하여, 인증서의 무결성을 확인하는 것이다. 두 번째로는 인증서 수신자가 인증서 체인에서 루트인증서부터 리프 인증서에 이르기까지 순차적으로 각 인증서의 소유자 정보를 그 하위 CA의 발급자 정보와 비교함으로써 각 인증서의 무결성과 신뢰성을 검증할 수 있다. 세 번째로는, 인증서 수신자가 해당 인증서에 대한 루트CA로부터 수신한 인증서 폐기 목록(CRL: Certificate Revocation List)를 통해서 폐기 여부를 확인하거나, 루트CA에 연계된 OCSP 서버에 인증서 상태를 조회하여 확인함으로써, 유효성을 검증할 수 있다.
도 5는 EV에 대한 로밍 서비스를 설명하기 위하여 PnC 충전 기반구조를 구성하는 노드들을 예시적으로 보여준다. 도시된 예에서, 제1 EV(EV1)는 제1 CSP(CSP1)과 계약 관계에 있으며, 제1 CSP(CSP1)의 네트웍에 속하는 제1 CSO(CSO1)에 접속된 제1 CS(CS1)의 전기차 전력공급장치(EVSE: EV Supply Equipment)에서 충전 서비스를 이용할 수 있다. 또한, 제2 EV(EV2)는 제2 CSP(CSP2)과 계약 관계에 있으며, 제2 CSP(CSP2)의 네트웍에 속하는 제2 CSO(CSO2)에 접속된 제2 CS(CS2)의 전기차 전력공급장치(EVSE: EV Supply Equipment)에서 충전 서비스를 이용할 수 있다. 즉, 제1 EV(EV1)와 제2 EV(EV2)는 각각의 홈 CSO들(CSO1, CSO2)에 접속된 CS들에서 별다른 장애없이 충전을 진행할 수 있다. 그런데, 제1 EV(EV1)가 제2 CSO(CSO2) 관할 하에 있는 제2 CS(CS2)에 방문하거나, 제2 EV(EV2)가 제1 CSO(CSO1)가 관리하는 제1 CS(CS1)에 방문하는 경우에는 로밍 환경이 조성되며, 특히 이와 같은 환경에서 후술하는 바와 같이 EV에 인증서를 설치하거나 갱신해야 하는 상황도 발생할 수 있게 된다.
도 6은 로밍이 필요하지 않은 상황과 필요한 상황들의 예를 보여주는 도면이다.
PnC 승인을 위한 기반구조에서, EV는 충전 스테이션(CS) 내지 전기차 전력공급 장치(EVSE)에 접속만 하면 자동적으로 승인, 충전, 및 결제가 이루어진다. 이와 같은 PnC 방식의 승인이 적용되기 위해서는, EV 소유주가 MO 내지 CSP와 서비스 이용계약을 체결해야 한다. 계약 체결 후에, EV에는 계약 인증서가 설치되며, 이 계약 인증서를 토대로 본인 인증과 충전 승인 및 결제가 이루어진다. 따라서, EV 소유주가 EV와 계약관계에 있는 MO 내지 CSP의 네트웍에 속하는 CSO가 관리하는 CS에 방문하여, 플러그를 접속시키거나 무선충전 스팟 위에 주차만 하면, EV가 계약 인증서를 자동으로 제시하고 승인과 충전 서비스를 받을 수 있게 된다.
EV 충전 기반구조 내에는 복수의 MO 내지 CSP가 존재할 수 있고, 각 MO 내지 CSP는 PnC의 허용여부 관점에서 독립적인 네트웍을 구성하게 된다. 각 EV는 자신이 계약관계에 있는 MO 내지 CSP가 속하는 네트웍에서는 PnC 서비스를 자유롭게 이용할 수 있지만, 다른 네트웍에서는 PnC 서비스가 제한적이거나 이용불가능할 수 있다. 예를 들어, 도 5에서 EV가 제1 CSP(CSPA)과 계약관계에 있다면, EV는 제1 CSP(CSPA)가 속하는 네트웍에서, 제1 CSP(CSPA)와 연관된 CSOA가 관리하는 EVSE에서 PnC 서비스를 이용할 수 있다.
이에 반하여, EV가 제2 CSP(CSPX)와 계약관계에 있다면, EV는 계약관계에 있지 않은 제1 CSP(CSPA)가 속하는 네트웍에서는, 예컨대 제1 CSP(CSPA)와 연관된 CSOA가 관리하는 EVSE에서는, PnC 서비스를 정상적으로 받기가 어려울 수 있다. 그렇지만 만약 방문 CSP(예컨대 CSPA)와 홈 CSP(예컨대 CSPX) 사이에 로밍 계약관계가 형성되어 있다면, 방문 CSO(CSOA)는 EV로부터 승인 요청이 있을 때 홈 CSP(CSPA)에 접근하여 EV에 대한 PnC 서비스가 이루어지게 할 수 있다. 또한, 만약 방문 CSP(CSPA)와 홈 CSP(CSOX) 사이에 클리어링 하우스를 통한 간접 로밍 계약관계가 형성되어 있다면, 방문 CSO(CSOA)는 EV로부터 승인 요청이 있을 때 클리어링 하우스의 지원 하에 EV에 대한 PnC 서비스가 이루어지게 할 수 있다.
도 7 내지 도 11을 참조하여 일반적인 승인 과정을 구체적으로 설명한다.
도 7은 로밍이 필요하지 않은 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다.
도시된 예에서, CS의 공급장치 통신 제어기(SECC)는 난수를 자신의 개인기로 암호화하여 챌린지(GenChallenge)를 생성하고, 생성된 챌린지를 EV의 전기차 통신 제어기(EVCC)에 전송할 수 있다(제600단계). CS는 적어도 EV로부터 후속 메시지를 수신할 때까지는 상기 챌린지 값을 보관한다. 상기 챌린지를 수신하면, EV는 이 챌린지를 CS의 공개키로 복호화하고, 사전에 정해진 규칙에 따라 선택되는 숫자를 포함하는 승인요청 메시지(AuthorizationReq)를 자신의 개인키로 암호화하여 챌린지에 대한 응답으로써 CS에 회신할 수 있다(제602단계). 이때 승인요청 메시지(AuthorizationReq)에는 EV의 계약 인증서 체인이 포함될 수 있다.
CS는 승인요청 메시지(AuthorizationReq)에 포함된 서명값을 EV의 공개키로 복호화하여 해시를 복원하고, 복원된 해시를 승인요청 메시지에 포함된 해시와 비교함으로써, 승인요청 메시지의 서명값을 확인한다(제604단계). 이때, CS는 승인요청 메시지에 포함된 응답 값이 상기 Challenge에 상응하는 것인지 추가적으로 판단할 수도 있다.
이어서, CS는 EV로부터 수신한 계약 인증서 체인을 CSO에 전달한다(제606단계). CSO는 계약 인증서 체인을 검증한다(제608단계). 계약 인증서 체인의 검증은 위에서 설명한 바와 같이 인증서 체인에서 루트인증서부터 리프 인증서에 이르기까지 순차적으로 각 인증서의 소유자 정보를 그 하위 CA의 발급자 정보와 비교함으로써 이루어질 수 있으며, 이를 통해서 각 인증서의 무결성과 신뢰성을 검증할 수 있다.
그 다음, CSO는 계약 인증서 체인을 CSP에 전달할 수 있다(제610단계). CSP는 계약 인증서 체인에 있는 각 인증서에 대하여, 인증서 폐기 목록(CRL)을 사용하거나 OCSP 서버에 조회함으로써, 인증서의 해지 여부를 확인할 수 있다(제612단계). 확인 결과에 따라, CSP는 계약 즉, 거래를 승인하는 승인 메시지를 CS에 송신할 수 있다(제614단계). 승인 메시지를 받으면, CS는 승인결과 메시지(Authorizat'Res)를 EV에 송신한다(제616단계).
그런데 이와 같은 승인 과정에서, EV에 계약 인증서 체인의 최상위 인증서인 MO 루트인증서(MO RootCA cert.)가 설치되어 있지 않기 때문에(ISO 15118-20 표준 2018. 7. 2.자 기준), EV가 제602단계에서 계약 인증서 체인을 CS에 송신할 때 리프 인증서인 계약 인증서 자체와 중간체인인증서(MO SubCA 1 cert., MO SubCA 2 cert.)만이 포함되고 MO 루트인증서(MO RootCA cert.)는 제외된다. 이에 따라 제608단계에서 인증서 체인을 CS로부터 수신한 CSO 역시 MO 루트인증서(MO RootCA cert.)가 없이 계약 인증서 체인을 검증하게 되며, CSO가 MO 루트인증서(MO RootCA cert.)를 별도로 확보하고 있지 않는 한 인증서 검증이 불완전할 수 있다. CSO가 보유하고 있는 CSP 루트인증서(CSP RootCA cert.)로는 MO 루트인증서(MO RootCA cert.)를 대체할 수 없음은 물론이다. 또한, CSP가 CSP 루트CA에 연계된 CRL이나 OCSP 서버 이외에 MO 루트CA에 연계된 CRL이나 OCSP 서버에 접근할 수 있는지 장담할 수 없기 때문에, 제612단계에서의 인증서 해지 여부 확인도 불완전할 수 있다.
도 8은 직접 로밍이 이루어지는 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다. 도시된 예에서, CS를 관리하는 방문 CSO는 EV와 계약을 맺은 홈 CSP의 네트웍에 속하는 것은 아니지만, 방문 CSP와 홈 CSP 간에 로밍 계약관계가 형성되어 있다고 가정한다.
이와 같은 경우에도, 제600단계 내지 제604단계는 도 7과 동일하게 이루어질 수 있다. 즉, CS는 챌린지를 EV에 전송할 수 있고(제600단계), 이에 응답하여 CS는 승인요청 메시지(AuthorizationReq)를 CS에 송신할 수 있다(제602단계). 그리고, CS는 승인요청 메시지(AuthorizationReq)의 서명값을 확인할 수 있다(제606단계).
이어서, CS는 EV로부터 수신한 계약 인증서 체인을 방문 CSO에 전달한다(제626단계). 방문 CSO는 계약 인증서 체인을 검증할 수 있다(제628단계). 이때, 방문 CSO는 eMAID를 통해서 홈 CSP에 접근하는 경로를 알고 있을 수 있다. 이에 따라 방문 CSO는 홈 CSP를 확인하고 계약 인증서 체인을 홈 CSP에 전달할 수 있다(제630단계). 홈 CSP는 계약 인증서 체인에 있는 각 인증서에 대하여, 인증서 폐기 목록(CRL)을 사용하거나 OCSP 서버에 조회함으로써, 인증서의 해지 여부를 확인할 수 있다(제632단계). 확인 결과에 따라, 홈 CSP는 계약 즉, 거래를 승인하는 승인 메시지를 CS에 송신할 수 있다(제634단계). 승인 메시지를 받으면, CS는 승인결과 메시지를 EV에 송신할 수 있다(제636단계).
그런데, 이 경우에도 제628단계에서 방문 CSO가 MO 루트인증서가 없이 계약 인증서 체인을 검증하게 되며, 방문 CSO가 CSP 루트인증서(CSP RootCA cert.)와 별도로 MO 루트인증서(MO RootCA cert.)를 별도로 확보하고 있지 않는 한 인증서 검증이 불완전할 수 있다. 또한, 홈 CSP가 CSP 루트CA에 연계된 CRL이나 OCSP 서버 이외에 MO 루트CA에 연계된 CRL이나 OCSP 서버에 접근할 수 있는지 장담할 수 없기 때문에, 제632단계에서의 각 인증서에 대한 해지 여부 확인도 불완전할 수 있다.
도 9는 간접 로밍이 이루어지는 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다. 도시된 예에서, CS를 관리하는 방문 CSO는 EV와 계약을 맺은 홈 CSP의 네트웍에 속하는 것은 아니지만, 방문 CSP와 홈 CSP 간에 클리어링 하우스를 통한 간접 로밍 계약관계가 형성되어 있다고 가정한다.
이와 같은 경우에도, 제600단계 내지 제604단계는 도 7 및 도 8과 동일하게 이루어질 수 있다. 즉, CS는 챌린지를 EV에 전송할 수 있고(제600단계), 이에 응답하여 CS는 승인요청 메시지(AuthorizationReq)를 CS에 송신할 수 있다(제602단계). 그리고, CS는 승인요청 메시지(AuthorizationReq)에 포함된 서명값을 확인할 수 있다(제606단계). 이어서, CS는 EV로부터 수신한 계약 인증서 체인을 방문 CSO에 전달한다(제646단계).
방문 CSO는 EV와 계약을 맺은 홈 CSP와 직접적인 계약 관계가 없기 때문에, 방문 CSO가 보유하고 있는 eMAID 등의 정보로는 홈 CSP를 파악할 수 없다. 그렇지만, 방문 CSO는 클리어링 하우스와 계약 관계에 있기 때문에, 클리어링 하우스가 홈 CSP를 파악할 수 있는지 그리고 어떤 클리어링 하우스가 홈 CSP를 파악할 수 있는지를 확인할 수 있다(제648단계). 클리어링 하우스가 적어도 하나의 홈 CSP를 파악하고 있는 것을 확인한 후(제650단계), 방문 CSO는 계약 인증서 체인을 해당 클리어링 하우스에 전달할 수 있다(제652단계). 클리어링 하우스는 계약 인증서 체인을 검증한 다음(제654단계), 계약 인증서 체인을 홈 CSP에 전달할 수 있다(제656단계). 홈 CSP는 계약 인증서 체인에 있는 각 인증서에 대하여, 인증서 폐기 목록(CRL)을 사용하거나 OCSP 서버에 조회함으로써, 인증서의 해지 여부를 확인할 수 있다(제657단계). 확인 결과에 따라, 홈 CSP는 계약 즉, 거래를 승인하는 승인 메시지를 CS에 송신할 수 있다(제658단계). 승인 메시지를 받으면, CS는 승인결과 메시지를 EV에 송신할 수 있다(제659단계).
이 경우에도 제654단계에서 클리어링 하우스가 CSP 루트인증서(CSP RootCA cert.)와 별도로 MO 루트인증서(MO RootCA cert.)를 별도로 확보하고 있지 않는 한, 인증서 검증이 불완전할 수 있다. 또한, 홈 CSP가 CSP 루트CA에 연계된 CRL이나 OCSP 서버 이외에 MO 루트CA에 연계된 CRL이나 OCSP 서버에 접근할 수 있는지 장담할 수 없기 때문에, 제657단계에서의 각 인증서에 대한 해지 여부 확인도 불완전할 수 있다.
도 10은 즉석(on-the-fly) 직접 로밍이 이루어지는 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다. 도시된 예에서, CS를 관리하는 방문 CSO는 EV와 계약을 맺은 홈 CSP의 네트웍에 속하는 것은 아니지만, 방문 CSO가 홈 CSP와 즉석 로밍 계약(on-the-fly direct roaming) 계약을 체결할 수 있다고 가정한다.
이와 같은 경우에도, 제600단계 내지 제604단계는 도 7 및 도 8과 동일하게 이루어질 수 있다. 즉, CS는 챌린지를 EV에 전송할 수 있고(제600단계), 이에 응답하여 CS는 승인요청 메시지(AuthorizationReq)를 CS에 송신할 수 있다(제602단계). 그리고, CS는 승인요청 메시지(AuthorizationReq)에 포함된 서명값을 확인할 수 있다(제606단계). CS는 EV로부터 수신한 계약 인증서를 방문 CSO에 전달할 수 있다(제666단계).
이어서, 방문 CSO는 홈 CSP와 즉석 로밍 계약을 체결할 수 있다(제668단계). 그 다음, 방문 CSO는 계약 인증서 체인을 검증할 수 있다(제670단계). 방문 CSO는 eMAID를 통해서 홈 CSP에 접근하는 경로를 알 수 있다. 이에 따라 방문 CSO는 계약 인증서 체인을 홈 CSP에 전달할 수 있다(제672단계). 홈 CSP는 계약 인증서 체인에 있는 각 인증서에 대하여, 인증서 폐기 목록(CRL)을 사용하거나 OCSP 서버에 조회함으로써, 인증서의 해지 여부를 확인할 수 있다(제674단계). 확인 결과에 따라, 홈 CSP는 계약 즉, 거래를 승인하는 승인 메시지를 CS에 송신할 수 있다(제676단계). 승인 메시지를 받으면, CS는 승인결과 메시지를 EV에 송신할 수 있다(제678단계).
이 경우에도 제670단계에서 방문 CSO가 CSP 루트인증서(CSP RootCA cert.)와 별도로 MO 루트인증서(MO RootCA cert.)를 별도로 확보하고 있지 않는 한, 인증서 검증이 불완전할 수 있다. 또한, 홈 CSP가 CSP 루트CA에 연계된 CRL이나 OCSP 서버 이외에 MO 루트CA에 연계된 CRL이나 OCSP 서버에 접근할 수 있는지 장담할 수 없기 때문에, 제674단계에서의 각 인증서에 대한 해지 여부 확인도 불완전할 수 있다.
도 11은 즉석 간접 로밍(on-the-fly indirect roaming)이 이루어지는 상황에서의 계약에 따른 일반적인 서비스 승인 과정을 보여주는 흐름도이다. 도시된 예에서, CS를 관리하는 방문 CSO는 EV와 계약을 맺은 홈 CSP의 네트웍에 속하는 것도 아니고, 방문 CSP와 홈 CSP 간에 클리어링 하우스를 통한 간접 로밍 계약관계가 형성되어 있는 것도 아니다. 따라서, 방문 CSO는 홈 CSP를 알지 못할 뿐만 아니라, 홈 CSP와 계약관계에 있는 클리어링 하우스도 알지 못한다. 그렇지만, 방문 CSO가 클리어링 하우스에 대하여 홈 CSP와 온라인으로 계약을 체결할 것을 요청할 수 있다고 가정한다.
이와 같은 경우에도, 제600단계 내지 제604단계는 도 7 및 도 9와 동일하게 이루어질 수 있다. 즉, CS는 챌린지를 EV에 전송할 수 있고(제600단계), 이에 응답하여 CS는 승인요청 메시지(AuthorizationReq)를 CS에 송신할 수 있다(제602단계). 그리고, CS는 승인요청 메시지(AuthorizationReq)에 포함된 서명값을 확인할 수 있다(제606단계). 이어서, CS는 EV로부터 수신한 계약 인증서를 방문 CSO에 전달한다(제686단계).
위에서 가정한 바와 같이 방문 CSO는 EV와 계약을 맺은 홈 CSP와 직접적인 계약 관계가 없기 때문에, 방문 CSO가 보유하고 있는 eMAID 등의 정보로는 홈 CSP를 파악할 수 없다. 더욱이, 방문 CSO는 홈 CSP와 이미 계약관계에 있는 클리어링 하우스를 식별하려 시도해보지만 실패한다(제688단계). 이와 같은 경우, 방문 CSO는 클리어링 하우스에 홈 CSP를 확인하여 홈 CSP와 계약을 체결할 것을 요청할 수 있다(제690단계). 여기서 계약이란 상기 EV에 대한 단발성 전력충전 및 결제 대행을 내용으로 하는 것일 수 있다. 클리어링 하우스와 홈 CSP 사이에 계약이 체결되면(제692단계), 클리어링 하우스는 계약 인증서 체인을 검증한 후(제694단계), 계약 인증서 체인을 홈 CSP에 전달할 수 있다(제696단계). 홈 CSP는 계약 인증서 체인에 있는 각 인증서에 대하여, 인증서 폐기 목록(CRL)을 사용하거나 OCSP 서버에 조회함으로써, 인증서의 해지 여부를 확인할 수 있다(제697단계). 확인 결과에 따라, 홈 CSP는 계약 즉, 거래를 승인하는 승인 메시지를 CS에 송신할 수 있다(제698단계). 승인 메시지를 받으면, CS는 승인결과 메시지를 EV에 송신할 수 있다(제699단계).
이 경우에도 제694단계에서 클리어링 하우스가 CSP 루트인증서(CSP RootCA cert.)와 별도로 MO 루트인증서(MO RootCA cert.)를 별도로 확보하고 있지 않는 한, 인증서 검증이 불완전할 수 있다. 또한, 홈 CSP가 CSP 루트CA에 연계된 CRL이나 OCSP 서버 이외에 MO 루트CA에 연계된 CRL이나 OCSP 서버에 접근할 수 있는지 장담할 수 없기 때문에, 제697단계에서의 각 인증서에 대한 해지 여부 확인도 불완전할 수 있다.
한편, 위에서 언급한 바와 같이, ISO 15118 표준에 따르면 CSP가 MO 하위 인증기관(MO Sub CA)으로서 EV에 대한 계약 인증서를 발급한다. 즉, EV가 출고시부터 그 내부에 저장되어 있는 OEM 프로비저닝 인증서를 CSO에 제시하면, CSO는 계약 인증서를 발급하여 EV에 전달하게 된다. 계약 인증서는 EV에 저장된 상태에서 PnC 충전시마다 CS에 제시되어, CS 또는 다른 보조 관여자(secondary actor)가 EV의 계약을 식별할 수 있게 해준다.
그런데, EV에 이와 같은 계약 인증서가 설치되지 않은 상태에서, EV가 충전 스테이션(CS)에 방문하여 PnC 충전을 요구하는 상황이 발생할 수 있다. 일 예로서, EV 사용자는 최초 충전 시에 출고 당시 EV에 설치되어 있는 OEM 프로비저닝 인증서를 CSP 내지 MO에 전달하고 계약 인증서를 발급받아야 하는데, EV가 최초 충전을 위해 방문한 CS가 홈 CSP의 네트웍에 속하지 않는 방문 CSO에 연관된 충전 스테이션인 경우를 들 수 있다. 이러한 경우, 로밍 조건에서 계약 인증서가 EV에 설치되어야 하는 상황이 발생된다. 이러한 상황은 EV의 매매에 의한 명의변경 직후 또는 EV의 메모리 장애 직후에도 발생할 수 있다. 아울러, 로밍 상황에서 EV에 설치되어야 하는 인증서는 계약 인증서에 한하지 않고 다른 인증서가 될 수도 있다. V2G 통신 인터페이스 중 네트웍 레이어 및 애플리케이션 레이어 상의 프로토콜 요건을 규정하고 있는 ISO 15118 표준이나, EV 충전 로밍 서비스를 위한 정보교환 사항을 규정하는 IEC 63119-1 표준은 이에 대하여 규정하는 바가 없다.
본 발명의 일 실시예에 따르면, 각 EV와 계약관계에 있는 각 CSP는 상기 EV가 어떠한 로밍 상황에서도 계약 인증서나 여타 필요한 인증서 또는 데이터를 수신하여 설치 또는 업데이트할 수 있게 해준다. 이하, 본 발명의 일 실시예에 따라, EV에 인증서를 설치하거나 업데이트하는 방법에 대하여 설명한다.
도 12는 본 발명의 일 실시예에 있어서 홈 CSP로부터 직접 로밍을 통해 EV에 전달되어 설치되는 계약 인증서의 전달 경로를 보여준다.
본 실시예에서, 홈 CPS(CPSH)에 저장되어 있는 계약 인증서를 EV에 설치하거나 또는 EV에 있는 기존 인증서를 이 인증서로 업데이트해야 하는 것으로 가정한다. 현재 EV는 방문 CSP(CSPV)의 네트웍에 속하는 방문 CSO(CSOV)에 접속된 CS에 방문한 상태이다. 그렇지만, 만약 홈 CSP(CSPH)와 방문 CSP(CSPV)가 로밍 계약 관계에 있다면, EV는 직접 로밍에 의해 홈 CPS(CPSH)에 저장되어 있는 계약 인증서를 설치하거나 또는 기존 인증서를 이 인증서로 업데이트할 수 있게 된다.
도 13은 도 12에 도시된 인증서 전달 과정을 보다 상세하게 보여주는 흐름도이다.
먼저 EV의 소유주와 홈 CSP의 운영자는 충전 서비스 계약을 체결할 수 있다(제700단계). 계약 체결 이후에, 홈 CSP는 EV에 대한 계약 인증서를 생성할 수 있다(제702단계). 생성된 인증서는 EV의 공개키와, 상기 공개키의 해쉬와, 상기 해쉬를 MO 루트CA의 중간CA(MO Sub 1 또는 MO Sub 2)의 개인키로 암호화한 서명값 등을 포함한다. 생성된 인증서는 해당 홈 CSP와 로밍 계약이 체결되어 있는 모든 방문 CSP들에 배포될 수 있다(제704단계~제708단계).
예시적인 실시예에 있어서, 제700단계 내지 제708단계는 EV가 CS를 통해서 방문 ESO에 인증서 설치 요청 메시지(CertificateInstallationReq) 또는 인증서 업데이트 요청 메시지(CertificateUpdateReq)를 송신하기 이전에 선제적으로 이루어질 수 있다. 즉, EV가 방문 CSP에 인증서 설치 또는 업데이트를 요청할 때 이를 지원할 수 있도록, 홈 CSP는 계약 관계에 있는 모든 방문 CSP들에 인증서 설치 패키지를 사전에 배포하여 방문 CSP들이 자신들의 CPS에 이를 저장할 수 있게 한다. 이때, 추후에 즉석 로밍(on-the-fly roaming)이 형성될 가능성을 감안하여 현재의 계약 관계 유무에 관계없이 모든 CSP들에 인증서 설치 패키지를 사전에 배포될 수도 있다. 인증서 설치 패키지는 계약 인증서 체인과, eMAID 계정 정보를 포함하고, 인증서 폐기 목록(CRL)과 OCSP 서버의 접속 정보를 추가적으로 포함할 수 있다. CSP들간의 인증서 패키지 전달은 직접 이루어질 수 있고, 후술하는 바와 같이 클리어링 하우스를 통해 이루어질 수도 있다.
보다 구체적으로 설명하면, 제704단계에서 홈 CSP가 계약 인증서를 생성하면, 해당 인증서 패키지를 포함하는 인증서 설치 응답 메시지(CertificateInstallationRes) 또는 인증서 업데이트 응답 메시지(CertificateUpdateRes)가 홈 CSP와 계약 관계에 있는 모든 방문 CSP들에 보안 채널을 통해 배포된다. 이때, 각 홈 CSP는 계약 인증서 체인을 검증하고, 계약 인증서 체인의 해지 상태를 확인하고, eMAID 계정 상태를 확인하고, 계약이 서비스에 대해 승인될 수 있는 것인지 확인할 수 있다. 확인 결과, 계약 인증서 체인과, eMAID 계정, 그리고 계약 내용에 아무런 문제가 없으면, 홈 CSP는 상기 인증서 패키지를 직접적인 로밍 계약이 있는 모든 방문 CSP들에 배포하거나, 인증서 배포 계약을 맺은 클리어링 하우스에 배포할 수 있고, 양자에 모두 배포할 수도 있다. 이 배포 프로세스를 위하여, 홈 CSP는 직접적인 로밍 계약이 있는 방문 CSP가 하나 이상 있다면 그와 같은 방문 CSP의 목록을 구비할 수 있다. 또한, 홈 CSP는 인증서 설치를 위한 로밍 계약이 있는 클리어링 하우스가 하나 이상 있다면 그와 같은 클리어링 하우스의 목록을 구비할 수 있다. 인증서 패키지 배포를 위한 통신은 로밍 엔드포인트를 넘어서 이루어질 수 있다. 한편, 인증서 설치 패키지를 받으면, 방문 CSP는 자신의 사용자에 대한 인증서를 발급할 때 수행하는 것과 동일한 절차를 통해서 해당 패키지를 자신의 CPS들에 배포할 수 있다.
이후, EV가 인증서 설치 또는 업데이트를 요청하면, 방문 CSO는 방문 CPS에서 인증서 설치 패키지를 가져와서 EV에 전달할 수 있다. 이때의 설치 또는 업데이트 프로세스는 비-로밍 상황과 로밍 상황간에 차이가 없을 수 있다. 도 13의 제720단계 내지 제734단계는 이 과정을 보여준다.
구체적으로, 제720단계에서, EV는 CS에 대하여 인증서 설치 또는 업데이트 요청 메시지(Cert{Ins/Upd}Req)를 송신할 수 있다. 인증서 설치 요청 메시지의 경우 EV는 ISO 15118 표준에 부합하는 통신에 의하여 충전 스테이션(CS)에 OEM 프로비저닝 인증서 체인을 송신할 수 있다. 한편, 인증서 갱신 요청 메시지에는 계약 인증서 체인이 포함될 수 있다. 인증서 설치 또는 업데이트 요청 메시지(Cert{Ins/Upd}Req)를 수신하면, CS는 요청 메시지에 있는 메시지 서명값을 확인한다(제722단계). 이때, CS는 요청 메시지에 포함된 서명값을 공개키로 복호화하여 해쉬를 복원한 다음, 복원된 해쉬를 요청 메시지에 포함되어 있는 해쉬와 비교함으로써 메시지 서명값을 확인하게 된다.
그 다음, CS는 수신된 인증서 체인을 검증한다(제724단계). 인증서 설치를 위한 OEM 프로비저닝 인증서의 경우, 프로비저닝 인증서 체인에서 OEM 루트인증서(OEM RootCA cert.)부터 리프 인증서인 프로비저닝 인증서(OEM Prov cert.)에 이르기까지 순차적으로 각 인증서의 소유자 정보를 그 하위 CA의 발급자 정보와 비교함으로써 이루어질 수 있으며, 이를 통해서 각 인증서의 무결성과 신뢰성을 검증할 수 있다. 인증서 업데이트를 위한 계약 인증서의 경우, 계약 인증서 체인에서 MO 루트인증서(MO RootCA cert.)부터 리프 인증서인 계약 인증서(Contract cert.)에 이르기까지 순차적으로 각 인증서의 소유자 정보를 그 하위 CA의 발급자 정보와 비교함으로써 이루어질 수 있으며, 이를 통해서 각 인증서의 무결성과 신뢰성을 검증할 수 있다. 이어서 CS는 인증서 설치 또는 업데이트 요청 메시지(Cert{Ins/Upd}Req)를 방문 CSO에 전달한다(제726단계).
방문 CSO는 OEM 프로비저닝 인증서 체인 또는 계약 인증서 체인에 있는 각 인증서의 해지 여부를 확인할 수 있다(제728단계). 인증서의 미해지 상태 즉, 유효성은 OEM 루트CA로부터 수신한 인증서 폐기 목록(CRL) 또는 MO 루트CA로부터 수신한 인증서 폐기 목록을 통해서 확인할 수도 있고, OEM 루트CA 또는 MO 루트CA에 연계된 OCSP 서버에 인증서 상태를 요청하고 조회결과를 수신한 후 확인할 수도 있다.
그 다음, 방문 CPS는 제708단계에서 저장된 새로운 계약 인증서 체인을 MO 루트CA 인증서를 토대로 검증한다(제730단계). 그리고 방문 CPS는 새로운 계약 인증서 체인에 있는 각 인증서의 해지 여부를 확인한다(제732단계). 인증서의 미해지 상태 즉, 유효성은 MO 루트CA로부터 수신한 인증서 폐기 목록(CRL)을 통해서 확인할 수도 있고, MO 루트CA에 연계된 OCSP 서버에 인증서 상태를 요청하고 조회결과를 수신하여 확인할 수도 있다.
일반적으로, ISO 15118 표준을 준수하는 EV가 CS와 TLS 연결을 시도할 때, CS는 CS의 인증서 체인에 있는 모든 인증서가 유효함 즉, 취소되지 않았음을 증명할 필요가 있다. 이를 위해. 본 발명의 일 실시예에 따르면, CS는 CSO PKI의 OCSP 응답자로부터의 OCSP 응답을 가져오기 위하여 CSMS에 주기적으로 그리고 OCSP 응답을 유효하게 유지하기에 충분히 자주 요청할 수 있다. CS는 하나의 인증서 체인에 대하여 하나의 OCSP 응답을 저장할 수 있다.
각 인증서에 대하여, CS는 기존 OCSP 응답이 만료되기 직전마다 OCSP 응답을 업데이트하기로 결정하고, CSMS에 OCSP 검색을 요청할 수 있다. OCSP 검색 요청에는 OCSP 요청 메시지와, 인증서 발급자의 고유명칭(DN: Distinguished Name)과, 인증서의 일련번호가 포함될 수 있다. 각 요청에 대하여, CSMS는 발급자 DN 및 일련번호로 인증서 데이터베이스를 조회하여 OCSP 응답 URL을 검색한다. URL을 찾을 수 없는 경우, CSMS는 다른 방법으로 URL 검색을 시도할 수 있다. 최상의 URL이 없는 경우 CSMS는 응답에 오류를 표시할 수 있다. OCSP 응답을 성공적으로 검색하면, CSMS는 OCSP 응답 메시지 목록을 CS에 회신할 수 있다. 검색 중 하나라도 실패하면, CSMS는 실패한 OCSP 쿼리와 그 이유를 표시할 수 있다. CS는 수신된 OCSP 응답을 저장함과 아울러, OCSP 스테이플링을 통해서 TLS 연결 중에 EV로 송신할 수 있다. 각 오류에 대해서는, 오류 유형에 따라 CS가 검색을 재시도할지 아니면 유지 상태를 입력할지 결정할 수 있다.
이와 같이 CS의 인증서 상태에 대한 정보를 최신 상태로 유지하기 위하여, CSMS는 충전 스테이션과 자신이 사용하는 인증서들을 저장하기 위한 인증서 데이터베이스를 유지할 수 있다. 그리고, CS는 인증서 체인에 대한 유효한 OCSP 응답 세트를 항상 유지한다. CS는 항상 유효한 상태로 유지할 수 있을 만큼 자주 CSMS에 OCSP 응답을 요청하는 것이 바람직하다.
제730단계에서 새로운 계약 인증서 체인이 검증되고, 제732단계에서 새로운 계약 인증서 체인 내에 있는 각 인증서의 유효성에 문제가 없으면, 방문 CPS는 새로운 계약 인증서 패키지를 포함하여 인증서 설치/갱신 응답(즉, Cert{Ins/Upd}Res 메시지)를 CS에 송신한다(제734단계). CS는 상기 새로운 계약 인증서 패키지를 다시 EV에 송신할 수 있으며, EV에서 새로운 인증서가 설치되거나 갱신될 수 있게 된다(제736단계).
한편, 제704단계~제708단계에서 사실상 거의 모든 CSP들에 배포된 계약 인증서는 배포 후 일정 기간이 경과하거나 해당 EV에 계약 인증서 설치가 완료된 후에는 개인정보 보호 데이터 저장부담 경감을 위하여 각 CSP들에서 삭제될 수 있다. 이를 위하여, 해당 EV에 계약 인증서 설치가 완료된 후에는 홈 CSP가 계약 인증서가 배포된 모든 CSP들 및 클리어링 하우스에 계약 인정서의 설치 완료를 통보하는 것이 바람직하다.
먼저 EV의 소유주와 홈 CSP의 운영자는 충전 서비스 계약을 체결할 수 있다(제700단계). 계약 체결 이후에, 홈 CSP는 EV에 대한 계약 인증서를 생성할 수 있다(제702단계). 생성된 인증서는 EV의 공개키와, 상기 공개키의 해쉬와, 상기 해쉬를 MO 루트CA의 중간CA(MO Sub 1 또는 MO Sub 2)의 개인키로 암호화한 서명값 등을 포함한다. 생성된 인증서는 해당 홈 CSP와 로밍 계약이 체결되어 있는 모든 방문 CSP들에 배포될 수 있다(제704단계~제708단계).
이와 같이 CS는 제734단계에서 방문 CPS로부터 수신한 데이터 예컨대, 계약 인증서 패키지를 제736단계에서 EV로 전송하지만, CS가 수신한 모든 인증서 데이터가 EV로 전송되는 것은 아니다. 즉, CS는 자신의 필요에 따라 인증서를 받아들여 설치하거나 기존에 저장되어 있던 인증서를 갱신할 수도 있다. 예를 들어, CS는 EV와 충전 스테이션 관리 시스템(CSMS: Charging Station management System)을 인증하는데 사용할 루트CA 인증서 및 관련 메타 데이터와, EV에 대하여 자신을 인증하는데 사용할 교차 인증서를 CSMS에서 가져올 수 있다. 다시 말해서, CS는 보안 동작을 위해 일부 루트CA 인증서(루트CA 용으로 발급된 것. 그렇지만, 반드시 자체서명되어야 하는 것은 아님)와 관련 메타 데이터를 자체적으로 저장할 필요가 있다. 인증서의 메타 데이터에는 SHA1 해쉬(TLS 용)와 발급자의 DN/일련번호 (인증서 설치용)가 포함될 수 있다.
CS가 자체적인 필요에 의해 수신하여 저장 또는 갱신하는 인증서들의 예를 들면 다음과 같다. CS는 CSMS와 보안 채널을 설정하는 동안에 CSMS를 인증하기 위하여 CSMS의 인증서 체인의 루트CA 인증서(즉, CSMS의 루트CA 인증서)가 필요한데, 이는 일반적으로 CS의 V2G 루트CA와 동일하다고 볼 수 있다. 또한, ISO 15118 표준을 준수하는 EV가 PnC 방식으로 승인을 받기로 선택하고, 계약 인증서 체인을 검증하는 것이 CS의 역할이라면, CS는 EMSP의 루트CA 인증서를 가질 필요가 있을 수 있다. 아울러, 계약 인증서 설치 또는 업데이트의 경우, 설치된 OEM 프로비저닝 인증서 체인 또는 업데이트된 계약 인증서 체인을 검증하는 것이 CS의 역할이라면, CS는 OEM 루트CA 인증서 또는 EMSP 루트CA 인증서가 필요할 수 있다.
나아가, CSO가 해당 CSO의 V2G 루트CA 이외의 V2G 루트CA만 신뢰하는 EV에 대한 서비스를 허용하기 위해 교차 인증을 지원할 때에는, CS는 EV가 신뢰하는 V2G 루트CA에서 발행한 교차 인증서를 필요로 할 수 있다. 다른 한편으로, EV가 CSO의 V2G 루트CA(TLS 용) 또는 CPS의 V2G 루트CA 인증서를 신뢰할 수 있는지 확인하려면, CS는 사용가능한 신뢰 앵커의 메타 데이터를 알 필요가 있다. 신뢰 앵커에는 CS의 V2G 루트CA(마이그레이션을 위한 새 루트CA 포함) 및 교차 인증 V2G 루트CA가 포함된다. 또 다른 한편으로, CS는 펌웨어 이진수 코드의 무결성을 확인하는 데 사용되는 CS 구성품 제조업체의 루트CA 인증서를 필요로 할 수 있다. 그리고, CS의 V2G 루트CA 마이그레이션의 경우, CSO가 RFC 4210에 정의된 마이그레이션 방법을 사용하기로 선택한다면, 마이그레이션 기간동안 CS는 두 개의 교차 인증서 중 하나를 보유하는 것이 필요할 수 있다.
여기에서, OldWithNew 인증서와 NewWithOld 인증서가 존재할 수도 있다. OldWithNew 인증서란 이전 루트CA에 대해 새 루트CA로 서명한 교차 인증서를 지칭하는 것이며, 이전 인증서 체인을 가진 CS는 새 루트CA를 신뢰하는 EV를 위해 이를 필요로 한다. NewWithOld 인정서는 새로운 루트CA에 대해 이전 루트CA로 서명한 교차 인증서를 일컬으며, 새 인증서 체인을 가진 CS는 이전 루트CA를 신뢰하는 EV를 위해 이를 필요로 한다.
CS가 자체적인 필요에 의해 인증서를 수신하여 저장 또는 갱신시키는 프로세스의 일 실시예는 CSMS에 의해 트리거된다. 즉, CS에 설치해야 하는 CA 인증서 및 메타데이터 중 하나에 대한 업데이트가 CSMS에 있는 경우, CSMS는 하나 이상의 CS에게 업데이트 목록을 보내는데, 각 업데이트 데이터는 '업데이트 = (유형, 인증서, 메타 데이터)'의 포맷으로 되어 있다. 예를 들어, CSO의 V2G 루트CA의 경우, 각 업데이트 데이터는 (V2G루트CA, <V2G루트CA 인증서>)의 포맷으로 되어 있을 수 있다. EMSP 루트CA 인증서의 경우, (EMSP루트CA, <EMSPRooCA 인증서>, -)의 포맷으로 되어 있을 수 있다. OEM 루트CA 인증서의 경우, (OEM루트CA, <OEMRooCA 인증서>, -)의 포맷으로 되어 있을 수 있다. 교차 인증서의 경우(CrossCert, <교차 인증서>, -)의 포맷으로 되어 있을 수 있다. 교차 인증 V2G 루트CA 인증서의 경우,(Cross루트CA, -, <메타 데이터>)의 포맷으로 되어 있을 수 있다. 마이그레이션을 위한 OldWithNew 교차 인증서의 경우, (OldWithNew, <OldWithNew 인증서>, -)의 포맷으로 되어 있을 수 있으며, 마이그레이션을 위한 NewWithOld 교차 인증서의 경우 (NewWithOld, <NewWithOld 인증서>, -)의 포맷으로 되어 있을 수 있다.
위와 같은 인증서의 경우, CSMS로부터 업데이트를 수신하면, CS는 과도한 지연없이 수신한 인증서 또는 메타 데이터를 설치하고, 업데이트 타임 스탬프를 업데이트한다.
CS가 자체적인 필요에 의해 인증서를 수신하여 저장 또는 갱신시키는 프로세스의 다른 실시예는 CSMS에 의해 트리거된다. 즉, CS가 CA 인증서의 변경 사항을 예컨대 주기적으로 업데이트하기로 결정할 때, CS는 일정한 정보를 CSMS에 송신함으로써, CA 인증서의 업데이트를 요청할 수 있다. 이때 CS에서 CSMS에 송신되는 정보의 예로는 마지막으로 성공한 업데이트의 타임스탬프, 현재 CS에 있는 CA 인증서의 발급자의 DN/일련번호 목록을 포함할 수 있다. 업데이트 요청을 수신하면, CSMS는 표시된 타임스탬프 이후에 업데이트/추가된 CA 인증서/메타데이터를 송신할 수 있다. CSMS에서 응답을 수신하면, CS는 CA 인증서와 메타데이터를 안전하게 저장한다.
CSMS가 CA 인증서 데이터베이스를 업데이트를 하게 되면, CSMS는 관련 CS에게 업데이트 또는 최종 업데이트 이후의 업데이트 모음의 설치를 요청해야 한다. 요청을 받으면, CS는 수신된 CA 인증서 업데이트를 설치하고 타임스탬프를 업데이트 시간으로 설정한다. CSO의 정책에 따라서, CS는 주기적으로 CSMS에 최종 업데이트의 타임스탬프를 제공하면서 CA 인증서 업데이트를 요청할 수 있다. 또한, 요청을 받으면, CSMS는 요청에 포함된 타임스탬프 이후에 변경된 모든 CA 인증서 업데이트를 송신한다. CSMS는 CA 인증서 업데이트를 송신할 때, 인증서 유형, 인증서, 및 메타데이터의 목록을 송신하는데, 여기서 메타데이터만이 교차 인증 V2G 루트CA 인증서를 교차 인증하기 위해 송신된다.
한편, CS는 안전한(secure) 동작을 위해 다수의 CA 인증서 및 관련 정보를 보유할 필요가 있다. 예를 들어, ISO 15118 표준을 준수하는 EV가 PnC 방식으로 승인을 받기로 선택하면, CS는 계약 인증서 체인을 유효화하기 위해 EMSP의 루트CA 인증서가 필요할 수 있다. 또한, 계약 인증서 설치를 위해, CS는 OEM 또는 EMPS의 루트CA 인증서가 필요할 수도 있다. CSMS과 보안 채널을 설정할 때, CS는 CSMS의 루트CA 인증서가 필요한데, 이 인증서는 일반적으로 V2G 루트CA이다. 아울러, 서로 다른 V2G 운영자 간의 더 나은 상호운용성을 위해, CS는 다른 V2G 운영자가 발행한 교차 인증서를 유지할 필요가 있다. 그리고 CS는 EV가 CSO에 안전하게 연결할 수 있는지 결정하기 위해 각 트러스트 앵커의 메타 데이터(예컨대, 해쉬, DN, 및 일련번호)를 유지할 필요가 있다.
CS가 안전한(secure) 동작을 위해 다수의 CA 인증서 및 관련 정보를 업데이트하는 프로세스의 일 실시예는 CS에 의해 트리거될 수 있다. 만약 CS가 CA 인증서 인벤토리의 변경 사항을 업데이트하기로 결정한다면, CS는 모든 CA 인증서의 업데이트를 CSMS에 요청할 수 있다. 이때, 상기 요청에는 마지막으로 성공한 업데이트 요청의 타임스탬프와, CS에 있는 CA 인증서의 발급자 DN/일련번호 목록이 포함될 수 있다. 요청을 받으면, CSMS는 CA 인증서 업데이트의 타임스탬프를 확인하고 요청에 있는 타임스탬프 이후 업데이트된 인증서의 데이터만을 CS에 송신할 수 있다. 이러한 방식으로 CS에 송신되는 인증서들에는 다음이 포함될 수 있다: CSMS의 V2G 루트CA 인증서 및 메타 데이터, CS의 V2G 루트CA 메타 데이터, (필요한 경우) 계약된 EMSP의 루트CA 인증서, (필요한 경우) OEM의 루트CA 인증서, CS의 V2G 루트CA에 발급된 교차 인증서 및 메타 데이터, 교차 인증서의 V2G 루트CA 메타 데이터, 및 루트 마이그레이션 교차 인증서. CSMS로부터 응답을 받으면, CS는 수신되는 CA 인증서를 안전하게 저장할 수 있다.
CS가 안전한 동작을 위해 다수의 CA 인증서 및 관련 정보를 업데이트하는 프로세스의 다른 실시예는 CSMS에 의해 트리거될 수 있다. 만약 CS에 설치해야하는 CA 인증서 중 하나에 대한 업데이트가 CSMS에 있다면, CSMS는 모든 또는 일부 CS에 대해 업데이트할 인증서 유형과, 일정 유형의 인증서 데이터 목록을 송신함으로써, CA 인증서 업데이트를 요청할 수 있다. 상기 업데이트할 인증서 유형은 예컨대 CSMS의 V2G 루트CA(루트 마이그레이션용), CS의 V2G 루트CA(루트 마이그레이션용), EMSP의 루트CA, OEM의 루트CA, CS의 V2G 루트CA에 발급된 교차 인증서, 교차 인증서의 V2G 루트CA, 루트 마이그레이션 교차 인증서를 들 수 있다. CSMS로부터 요청을 받으면, CS는 수신된 인증서 데이터를 과도한 지연없이 설치하고 업데이트 타임스탬프를 업데이트한다.
위와 같은 인증서 업데이트 과정에서, CSMS는 업데이트/시간 태그가 붙은 CA 인증서 데이터(인증서, DN, 일련번호, 해쉬)에 대한 데이터베이스를 유지할 수 있다. 그리고 EV와 CS는 PnC 식별 방법으로 ISO15118을 통해 통신할 수 있다. 한편, CPS/CCP는 인증서 체인(설치용 OEM 프로비저닝 인증서 체인 및 업데이트 용 계약 인증서 체인)을 검증할 수 있으며, 설치를 위한 OEM 프로비저닝 인증서 체인 및 업데이트를 위한 계약 인증서 체인에 있는 각 인증서의 해지 여부를 확인할 수 있다.
한편, 업데이트를 위한 인증서를 수신하게 되면, CS는 CertificateInstallationReq 및 CertificateUpdateReq 메시지의 서명을 확인한다. 그 다음, CS는 다음 데이터를 CSMS로 송신한다: CertificateInstallationReq 또는 CertificateUpdateReq 메시지(있는 그대로), PCID(설치용) 또는 eMAID(업데이트용), 메시지의 ISO 15118 스키마 버전, (ISO15118 제한 시간으로 인한) 검색(retrieval) 기한, EV가 신뢰하는 V2G 루트CA 인증서 목록. 상기 데이터를 수신하게 되면, CSMS는 보조 관여자에게 계약 인증서를 요청하고 수신된 정보를 CS로 다시 전달할 수 있다. 다수의 계약 인증서가 수신되면, CSMS는 수신 완료를 CS에 표시하는 것이 바람직하다. 계약 인증서가 수신되지 않은 경우 CSMS는 CS에 오류 메시지(예컨대 'NO_CONTRACT_CERTIFICATE_FOUND')를 표시할 수 있다. ISO15118-2 표준에 입각하는 경우, CS는 CSMS로부터 수신한 CertificateInstallationRes 또는 CertificateUpdateRes를 SessionID가 채워진 상태로 EV에 전달할 수 있다. 한편, ISO 15118-20 표준에 입각하는 경우, CS는 수신된 각 CertificateInstallationRes를 수정하거나 CSMS에서 수신한 각 정보에 대해 CertificateInstallationRes 메시지를 생성하여, 메시지가 SessionID, EVSEProcessing, RemainingCerts, EVSEStatus 및 ResponseCode 요소에 올바른 값을 포함하도록 할 수 있다.
도 14는 본 발명의 일 실시예에 있어서 홈 CSP로부터 간접 로밍을 통해 EV에 전달되어 설치되는 계약 인증서의 전달 경로를 보여준다.
본 실시예에서, 홈 CPS에 저장되어 있는 계약 인증서를 EV에 설치하거나 또는 EV에 있는 기존 인증서를 이 인증서로 업데이트해야 하는 것으로 가정한다. 현재 EV는 방문 CSP의 네트웍에 속하는 방문 CSO에 접속된 CS에 방문한 상태이다. 그렇지만, 만약 홈 CSP와 방문 CSP가 클리어링 하우스를 통한 간접 로밍 계약관계에 있다면, EV는 클리어링 하우스를 경유하는 간접 로밍에 의해 홈 CPS에 저장되어 있는 계약 인증서를 설치하거나 또는 기존 인증서를 이 인증서로 업데이트할 수 있게 된다.
도 15는 도 14에 도시된 인증서 전달 과정을 보다 상세하게 보여주는 흐름도이다. 도 15에 도시된 실시예는 인증서를 선제적으로 CSP들에 저장해두는 과정에서 방문 CSP와 홈 CSP가 직접 통신하는 것이 아니라 클리어링 하우스를 통해서 통신하는 점이 다르다.
먼저 EV의 소유주와 홈 CSP의 운영자는 충전 서비스 계약을 체결할 수 있다(제800단계). 계약 체결 이후에, 홈 CSP는 EV에 대한 계약 인증서를 생성할 수 있다(제802단계). 생성된 인증서는 EV의 공개키와, 상기 공개키의 해쉬와, 상기 해쉬를 MO 루트CA의 중간CA(MO Sub 1 또는 MO Sub 2)의 개인키로 암호화한 서명값 등을 포함한다. 생성된 인증서는 해당 홈 CSP와 로밍 계약이 체결되어 있는 모든 방문 CSP들에 배포될 수 있다(제804단계~제808단계).
예시적인 실시예에 있어서, 제800단계 내지 제808단계는 EV가 CS를 통해서 방문 ESO에 인증서 설치 요청 메시지(CertificateInstallationReq) 또는 인증서 업데이트 요청 메시지(CertificateUpdateReq)를 송신하기 이전에 선제적으로 이루어질 수 있다. 즉, EV가 방문 CSP에 인증서 설치 또는 업데이트를 요청할 때 이를 지원할 수 있도록, 홈 CSP는 계약 관계에 있는 모든 방문 CSP들에 인증서 설치 패키지를 사전에 배포하여 방문 CSP들이 자신들의 CPS에 이를 저장할 수 있게 한다. 이때, 추후에 즉석 로밍(on-the-fly roaming)이 형성될 가능성을 감안하여 현재의 계약 관계 유무에 고나계없이 모든 CSP들에 인증서 설치 패키지를 사전에 배포될 수도 있다. 인증서 설치 패키지는 계약 인증서 체인과, eMAID 계정 정보를 포함하고, 인증서 폐기 목록(CRL)과 OCSP 서버의 접속 정보를 추가적으로 포함할 수 있다. CSP들간의 인증서 패키지 전달은 직접 이루어질 수 있고, 후술하는 바와 같이 클리어링 하우스를 통해 이루어질 수도 있다.
보다 구체적으로 설명하면, 제804단계에서 홈 CSP가 계약 인증서를 생성하면, 해당 인증서 패키지를 포함하는 인증서 설치 응답 메시지(CertificateInstallationRes) 또는 인증서 업데이트 응답 메시지(CertificateUpdateRes)가 홈 CSP와 계약 관계에 있는 모든 방문 CSP들에 보안 채널을 통해 배포된다. 이때, 홈 CSP 또는 클리어링 하우스는 계약 인증서 체인을 검증하고, 계약 인증서 체인의 해지 상태를 확인하고, eMAID 계정 상태를 확인하고, 계약이 서비스에 대해 승인될 수 있는 것인지 확인할 수 있다. 확인 결과, 계약 인증서 체인과, eMAID 계정, 그리고 계약 내용에 아무런 문제가 없으면, 상기 인증서 패키지가 모든 방문 CSP들에 배포될 수 있다. 배포가 완료되면, 홈 CSP는 인증서 체인의 상태 코드와 계정 및 권한에 대한 결과 코드를 클리어링 하우스에 송신한다. 이 배포 프로세스를 위하여, 홈 CSP는 직접적인 로밍 계약이 있는 방문 CSP가 하나 이상 있다면 그와 같은 방문 CSP의 목록을 구비할 수 있다. 또한, 홈 CSP는 인증서 설치를 위한 로밍 계약이 있는 클리어링 하우스가 하나 이상 있다면 그와 같은 클리어링 하우스의 목록을 구비할 수 있다. 인증서 패키지 배포를 위한 통신은 로밍 엔드포인트를 넘어서 이루어질 수 있다. 한편, 인증서 설치 패키지를 받으면, 방문 CSP는 자신의 사용자에 대한 인증서를 발급할 때 수행하는 것과 동일한 절차를 통해서 해당 패키지를 자신의 CPS들에 배포할 수 있다.
이후, EV가 인증서 설치 또는 업데이트를 요청하면, 방문 CSO는 방문 CPS에서 인증서 설치 패키지를 가져와서 EV에 전달할 수 있다. 이때의 설치 또는 업데이트 프로세스는 비-로밍 상황과 로밍 상황간에 차이가 없을 수 있다. 도 14의 제820단계 내지 제836단계는 이 과정을 보여준다.
구체적으로, 제820단계에서, EV는 CS에 대하여 인증서 설치 또는 업데이트 요청 메시지(Cert{Ins/Upd}Req)를 송신할 수 있다. 인증서 설치 요청 메시지의 경우 EV는 ISO 15118 표준에 부합하는 통신에 의하여 충전 스테이션(CS)에 OEM 프로비저닝 인증서 체인을 송신할 수 있다. 한편, 인증서 갱신 요청 메시지에는 계약 인증서 체인이 포함될 수 있다. 인증서 설치 또는 업데이트 요청 메시지(Cert{Ins/Upd}Req)를 수신하면, CS는 요청 메시지에 있는 메시지 서명값을 확인한다(제822단계). 이때, CS는 요청 메시지에 포함된 서명값을 공개키로 복호화하여 해쉬를 복원한 다음, 복원된 해쉬를 요청 메시지에 포함되어 있는 해쉬와 비교함으로써 메시지 서명값을 확인하게 된다.
그 다음, CS는 수신된 인증서 체인을 검증한다(제824단계). 즉, 인증서 설치의 경우 OEM 프로비저닝 인증서 체인을 위에서 설명한 방식으로 검증하며, 인증서 업데이트의 경우 계약 인증서 체인을 검증한다. 이어서 CS는 인증서 설치 또는 업데이트 요청 메시지(Cert{Ins/Upd}Req)를 방문 CSO에 전달한다(제826단계). 그리고, 방문 CSO는 위에서 설명한 방식으로 OEM 프로비저닝 인증서 체인 또는 계약 인증서 체인에 있는 각 인증서의 해지 여부를 확인할 수 있다(제828단계).
방문 CPS는 제808단계에서 저장된 새로운 계약 인증서 체인을 MO 루트CA 인증서를 토대로 검증한다(제830단계). 그리고 방문 CPS는 새로운 계약 인증서 체인에 있는 각 인증서의 해지 여부를 확인한다(제832단계). 인증서의 미해지 상태 즉, 유효성은 MO 루트CA로부터 수신한 인증서 폐기 목록(CRL)을 통해서 확인할 수도 있고, MO 루트CA에 연계된 OCSP 서버에 인증서 상태를 요청하고 조회결과를 수신하여 확인할 수도 있다.
확인 결과, 새로운 계약 인증서 체인이 검증되고, 새로운 계약 인증서 체인 내에 있는 각 인증서의 유효성에 문제가 없으면, 방문 CPS는 새로운 계약 인증서 패키지를 포함하여 인증서 설치/갱신 응답(즉, Cert{Ins/Upd}Res 메시지)를 CS에 송신한다(제834단계). CS는 상기 새로운 계약 인증서 패키지를 다시 EV에 송신할 수 있으며, EV에서 새로운 인증서가 설치되거나 갱신될 수 있게 된다(제836단계).
이와 같이 CS는 제834단계에서 방문 CPS로부터 수신한 데이터 예컨대, 계약 인증서 패키지를 제836단계에서 EV로 전송하지만, CS가 수신한 모든 인증서 데이터가 EV로 전송되는 것은 아니다. 즉, CS는 자신의 필요에 따라 인증서를 받아들여 설치하거나 기존에 저장되어 있던 인증서를 갱신할 수도 있다. 또한, CS는 안전한 동작을 위해 다수의 CA 인증서 및 관련 정보를 보유할 필요가 있고, 다수의 CA 인증서 및 관련 정보를 업데이트할 수 있다. 본 실시예에서 CS가 자신이 필요한 인증서를 설치하거나 갱신하는 프로세스는 도 13과 관련하여 설명한 것과 유사하므로, 이에 대한 자세한 설명은 생략하기로 한다.
도 13과 도 15에서, 방문 CSP와 홈 CSP는 역할이 서로 뒤바뀔 수 있다는 점을 유의해야 한다. 아울러, 어느 한 CSP가 다른 CSP에 대해서는 방문 CSP로 작용하면서 또 다른 CSP에 대해서는 홈 CSP로 작용할 수 있다는 점을 고려해야 한다.
도 16은 본 발명의 일 실시예에 있어서 계약에 따른 서비스 승인 과정을 보여주는 흐름도이다.
먼저, PnC 방법을 통해 서비스에 대한 승인을 받고자 하는 EV는 방문 CS에 승인요청 메시지(AuthorizationReq)를 송신할 수 있다(제900단계). 이때, EV는 ISO 15118 표준에 부합하는 통신에 의하여 계약 인증서 체인을 충전 스테이션(CS)에 송신할 수 있다. CS는 승인요청 메시지(AuthorizationReq)에 포함된 서명값을 EV의 공개키로 복호화하여 해시를 복원하고, 복원된 해시를 승인요청 메시지에 포함된 해시와 비교함으로써, EV의 서명을 확인한다(제902단계).
이어서, CS는 승인요청 메시지(AuthorizationReq)에 포함된 계약 인증서 체인과 eMAID를 방문 CSO에 전달할 수 있다(제904단계). 방문 CSO는 EV와 계약관계에 있는 CSP가 자신이 속한 네트워크 내부에 있는지 외부에 있는지 판단한다. 그리고, 방문 CSO는 로밍 지원을 받기 위하여 홈 CSP 또는 클리어링 하우스에 직접 연락하는 방법을 확인한다. 이어서, 방문 CSO는 홈 CSP 또는 클리어링 하우스에 EV 관련 정보를 포함하는 승인 요청을 송신한다(제906단계). 상기 EV 관련 정보는 eMAID와, 계약 인증서 체인이 포함되며, EV 승인을 위한 서비스 설명이 추가적으로 포함될 수 있다. 만약 제906단계에서 방문 CSO가 송신한 EV 관련 정보의 목적지가 클리어링 하우스인 경우, 클리어링 하우스는 상기 EV 관련 정보를 해당 홈 CSP로 전달한다.
이어서, 홈 CSP는 사전에 확보하고 있는 MO 루트CA 인증서(MO RootCA cert.)를 포함시켜 완전한 계약 인증서 체인을 확인하고, 계약 인증서 체인을 검증한다(제708단계). 계약 인증서 체인의 검증은 루트인증서(MO RootCA cert.)부터 중간체인인증서(MO SubCA 1 cert, MO SubCA 2 cert)를 거쳐 리프인증서인 계약 인증서(Contract Certificate)에 이르기까지 순차적으로 각 인증서의 소유자 정보를 그 하위 CA의 발급자 정보와 비교함으로써 각 인증서의 무결성과 신뢰성을 검증하게 된다. 그리고, 홈 CSP는 계약 인증서 체인에 있는 각 인증서의 해지 여부를 확인한다(제910단계). 인증서의 미해지 상태 즉, 유효성은 MO 루트CA로부터 수신한 인증서 폐기 목록(CRL)을 통해서 확인할 수도 있고, MO 루트CA에 연계된 OCSP 서버에 인증서 상태를 조회함으로써 확인할 수도 있다. 아울러, 홈 CSP는 eMAID 계정의 상태와, 요청한 서비스가 계약상 승인될 수 있는 것인지 여부에 대해서도 추가적으로 확인할 수 있다(제912단계).
확인 결과에 따라, 홈 CSP는 계약 인증서 체인의 상태를 나타내는 상태 코드와 EV의 계정 및 권한에 관한 결과 코드를 방문 CSO에게 회신할 수 있다(제914단계). 상기 상태 코드는 예컨대 ‘문제없음(OK)’, ‘만료됨(Expired)’, ‘취소됨(Revoked)’, ‘유효하지 않은 인증서 체인(Invalid_chain)’, ‘알 수 없는 오류(Unkown_error)’ 중 하나일 수 있다. 상기 결과 코드는 예컨대 ‘문제없음(OK)’, ‘존재하지 않는 계약(NO_CONTRACT)’, ‘만료된 계약(CONTRACT_TERMINATED)’, ‘보류된 계약(CONTRACT_SUSPENDED)’, '미승인(NOT_AUTHORIZED)‘, ‘알 수 없는 오류(Unkown_error)’ 중 하나일 수 있다.
방문 CSO는 인증 결과를 CS에 통보하고, CS는 ISO 15118 표준에 부합하는 통신을 통해 인증 결과를 다시 EV에 통보할 수 있다(제916단계, 제918단계).
이와 같이, EV와 계약관계에 있는 CSP가 방문 CSO와 직접적인 로밍 계약관계에 있거나 클리어링 하우스를 통한 간접 로밍 계약관계에 있다면, 방문 CSO는 홈 CSP와 직접 EV의 인증에 필요한 정보를 교환하거나 클리어링 하우스를 경유하여 정보 교환을 행함으로써 승인 프로세스를 수행할 수 있다.
한편, 도 16은 본 발명의 일 실시예를 예시하는 것이며, 이 실시예는 다양하게 변형될 수 있다. 예컨대, 변형된 실시예에 있어서는, 메시지 서명 단계(제902단계)가 CS가 아니라 방문 CSO에 의해 실행될 수도 있다. 또한, 계약 인증서 체인 검증 단계(제908단계)는 홈 CSP가 아닌 방문 CSO 또는 CS에 의해 실행될 수 있다. 그밖에도, 도 16에 도시된 실시예는 로밍 상황에 따라 도 7 내지 도 11에 도시된 바와 같이 각 단계의 실행 주체가 변경될 수 있다.
도 17은 본 발명의 일 실시예에 따른 충전 서비스 제공자(CSP)(220)의 블록도이다. 본 발명의 일 실시예에 따른 CSP(220)는 적어도 하나의 프로세서(1020), 메모리(1040), 및 저장 장치(1060)를 포함할 수 있다.
프로세서(1020)는 메모리(1040) 및/또는 저장 장치(1060)에 저장된 프로그램 명령을 실행할 수 있다. 프로세서(1020)는 적어도 하나의 중앙 처리 장치(central processing unit, CPU)나 그래픽 처리 장치(graphics processing unit, GPU)에 의해 구현될 수 있으며, 그밖에 본 발명에 따른 방법을 수행할 수 있는 여타의 프로세서일 수 있다.
메모리(1040)는 예컨대 ROM(Read Only Memory)와 같은 휘발성 메모리와, RAM(Random Access Memory)과 같은 비휘발성 메모리를 포함할 수 있다. 메모리(1040)는 저장 장치(1060)에 저장된 프로그램 명령을 로드하여, 프로세서(1020)에 제공할 수 있다.
저장 장치(1060)는 프로그램 명령과 데이터를 저장하기에 적합한 기록매체로서, 예컨대 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(Magnetic Media), CD-ROM(Compact Disk Read Only Memory), DVD(Digital Video Disk)와 같은 광 기록 매체(Optical Media), 플롭티컬 디스크(Floptical Disk)와 같은 자기-광 매체(Magneto-Optical Media), 플래시 메모리나 EPROM(Erasable Programmable ROM) 또는 이들을 기반으로 제작되는 SSD와 같은 반도체 메모리를 포함할 수 있다.
저장 장치(1060)는 상기 프로그램 명령을 저장한다. 특히, 상기 프로그램 명령은 본 발명에 따른 인증서 설치 지원을 위한 프로그램 명령을 포함할 수 있다. 상기 인증서 설치 지원을 위한 프로그램 명령은 제1 EV에 대한 제1 계약 인증서를 생성하고 상기 제1 계약 인증서를 제1 외부 CSP에 전송하여, 상기 제1 외부 CSP를 통해 상기 제1 계약 인증서가 상기 제1 EV에 설치될 수 있게 하는 명령과, 제2 EV에 대한 제2 계약 인증서를 제2 외부 CSP로부터 받아들이고, CPS에 전달하여 저장하게 하는 명령, 및 상기 제2 EV가 서비스 네트웍에 진입한 로밍 상황에서 상기 제2 EV로부터 계약 인증서 설치 요청이 수신되면, 상기 CPS에 저장된 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 명령을 포함한다. 아울러, 무선전력전송을 위한 프로그램 명령은 도 12에 도시된 프로세스를 구현하는데 필요한 명령 중 적어도 일부를 포함할 수 있다. 이와 같은 프로그램 명령은 프로세서(1020)의 제어에 의해 메모리(1040)에 로드된 상태에서, 프로세서(1020)에 의해 실행되어 본 발명에 의한 방법을 구현할 수 있다.
위에서 언급한 바와 같이 본 발명의 실시예에 따른 장치와 방법은 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 프로그램 또는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어 분산 방식으로 컴퓨터로 읽을 수 있는 프로그램 또는 코드가 저장되고 실행될 수 있다.
상기 컴퓨터가 읽을 수 있는 기록매체는 롬(rom), 램(ram), 플래시 메모리(flash memory) 등과 같이 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치를 포함할 수 있다. 프로그램 명령은 컴파일러(compiler)에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터(interpreter) 등을 사용해서 컴퓨터에 의해 실행될 수 있는 고급 언어 코드를 포함할 수 있다.
본 발명의 일부 측면들은 장치의 문맥에서 설명되었으나, 그것은 상응하는 방법에 따른 설명 또한 나타낼 수 있고, 여기서 블록 또는 장치는 방법 단계 또는 방법 단계의 특징에 상응한다. 유사하게, 방법의 문맥에서 설명된 측면들은 또한 상응하는 블록 또는 아이템 또는 상응하는 장치의 특징으로 나타낼 수 있다. 방법 단계들의 몇몇 또는 전부는 예를 들어, 마이크로프로세서, 프로그램 가능한 컴퓨터 또는 전자 회로와 같은 하드웨어 장치에 의해(또는 이용하여) 수행될 수 있다. 몇몇의 실시예에서, 가장 중요한 방법 단계들의 하나 이상은 이와 같은 장치에 의해 수행될 수 있다.
실시예들에서, 프로그램 가능한 로직 장치(예를 들어, 필드 프로그래머블 게이트 어레이)가 여기서 설명된 방법들의 기능의 일부 또는 전부를 수행하기 위해 사용될 수 있다. 실시예들에서, 필드 프로그래머블 게이트 어레이는 여기서 설명된 방법들 중 하나를 수행하기 위한 마이크로프로세서와 함께 작동할 수 있다. 일반적으로, 방법들은 어떤 하드웨어 장치에 의해 수행되는 것이 바람직하다.
위에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

Claims (20)

  1. 제1 전기차(EV)에 대한 제1 계약 인증서를 생성하는 단계; 및
    상기 제1 계약 인증서를 로밍 계약이 형성되어 있는 제1 외부 충전 서비스 제공 장치(CSP)에 전송하여, 상기 제1 계약 인증서가 로밍 상황에서 상기 제1 외부 CSP를 통해 상기 제1 EV에 설치될 수 있게 하는 단계;
    를 포함하는, 충전 서비스 제공 장치에서의 계약 인증서 설치 지원 방법.
  2. 제1항에 있어서,
    상기 제1 외부 CSP가 상기 충전 서비스 제공 장치와 로밍 계약이 성립되어 있는 모든 외부 CSP들을 포함하는 계약 인증서 설치 지원 방법.
  3. 제2항에 있어서,
    상기 제1 외부 CSP가 모든 외부 CSP들을 포함하는 계약 인증서 설치 지원 방법.
  4. 제1항에 있어서,
    상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송한 후에 소정의 기간이 경과하거나 상기 제1 계약 인증서가 상기 제1 EV에 설치되면, 상기 제1 외부 CSP에 설치대기 해제 요청을 송신하는 단계;
    를 더 포함하는 계약 인증서 설치 지원 방법.
  5. 제1항에 있어서, 상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송하는 단계가
    상기 제1 계약 인증서를 포함한 계약 인증서 체인과, eMAID 정보를 포함하는 인증서 설치 패키지를 형성하는 단계; 및
    상기 인증서 설치 패키지를 상기 제1 CSP에 전송하는 단계;
    를 포함하는 계약 인증서 설치 지원 방법.
  6. 제5항에 있어서,
    상기 인증서 설치 패키지가 상기 제1 계약 인증서에 연관된 인증서 폐기 목록과 온라인 인증서 상태 프로토콜(OCSP) 서버의 접속 정보를 포함하는 계약 인증서 설치 지원 방법.
  7. 제1항에 있어서,
    제2 EV에 대한 제2 계약 인증서를 제2 외부 CSP로부터 받아들이고, 인증서 프로비저닝 서비스 장치(CPS)에 전달하여 저장하게 하는 단계; 및
    상기 제2 EV가 서비스 네트웍에 진입한 로밍 상황에서 상기 제2 EV로부터 계약 인증서 설치 요청이 수신되면, 상기 CPS에 저장된 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 단계;
    를 더 포함하는 계약 인증서 설치 지원 방법.
  8. 제7항에 있어서,
    상기 제2 외부 CSP가 상기 충전 서비스 제공 장치와 상기 로밍 계약이 성립되어 있는 모든 외부 CSP들 중 어느 하나인 계약 인증서 설치 지원 방법.
  9. 제7항에 있어서, 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 단계가
    상기 제2 계약 인증서가 상기 제2 EV에 설치된 후에, 상기 제2 외부 CSP에 설치 완료를 통보하는 단계;
    를 포함하는 계약 인증서 설치 지원 방법.
  10. 프로세서; 및
    상기 프로세서에 의해 실행될 수 있는 적어도 하나의 명령을 저장하는 메모리;를 포함하고,
    상기 적어도 하나의 명령이
    제1 전기차(EV)에 대한 제1 계약 인증서를 생성하고 상기 제1 계약 인증서를 제1 외부 충전 서비스 제공 장치(CSP)에 전송하여, 상기 제1 외부 CSP를 통해 상기 제1 계약 인증서가 상기 제1 EV에 설치될 수 있게 하는 명령;
    제2 EV에 대한 제2 계약 인증서를 제2 외부 CSP로부터 받아들이고, 인증서 프로비저닝 서비스 장치(CPS)에 전달하여 저장하게 하는 명령; 및
    상기 제2 EV가 서비스 네트웍에 진입한 로밍 상황에서 상기 제2 EV로부터 계약 인증서 설치 요청이 수신되면, 상기 CPS에 저장된 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 명령;
    을 포함하는 충전 서비스 제공 장치.
  11. 제10항에 있어서,
    상기 제1 외부 CSP가 상기 충전 서비스 제공 장치와 로밍 계약이 성립되어 있는 모든 외부 CSP들을 포함하며,
    상기 제2 외부 CSP가 상기 충전 서비스 제공 장치와 로밍 계약이 성립되어 있는 상기 모든 외부 CSP들 중 어느 하나인 충전 서비스 제공 장치.
  12. 제11항에 있어서,
    상기 제1 외부 CSP가 모든 외부 CSP들을 포함하며,
    상기 제2 외부 CSP가 상기 모든 외부 CSP들 중 어느 하나인 충전 서비스 제공 장치.
  13. 제10항에 있어서, 상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송하는 명령이
    상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송한 후 소정의 기간이 경과하거나 상기 제1 계약 인증서가 상기 제1 EV에 설치되면, 상기 제1 외부 CSP에 설치대기 해제 요청을 송신하는 명령;
    을 더 포함하는 계약 인증서 설치 지원 방법.
  14. 제13항에 있어서, 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 명령이
    상기 제2 계약 인증서가 상기 제2 EV에 설치된 후에, 상기 제2 외부 CSP에 설치 완료를 통보하는 명령;
    을 포함하는 충전 서비스 제공 장치.
  15. 제10항에 있어서, 상기 제1 계약 인증서를 상기 제1 외부 CSP에 전송하는 단계가
    상기 제1 계약 인증서를 포함한 계약 인증서 체인과, eMAID 정보를 포함하는 인증서 설치 패키지를 형성하는 단계; 및
    상기 인증서 설치 패키지를 상기 제1 CSP에 전송하는 단계;
    를 포함하는 충전 서비스 제공 장치.
  16. 제15항에 있어서,
    상기 인증서 설치 패키지가 상기 제1 계약 인증서에 연관된 인증서 폐기 목록과 온라인 인증서 상태 프로토콜(OCSP) 서버의 접속 정보를 포함하는 충전 서비스 제공 장치.
  17. 충전 서비스 제공 장치(CSP)가 로밍 환경에 있는 전기차(EV)에 대하여 피앤씨(PnC) 방식의 EV 충전을 승인하는 방법으로서,
    제1 EV에 대한 제1 계약 인증서를 생성하고 상기 제1 계약 인증서를 제1 외부 CSP에 전송하여, 상기 제1 외부 CSP를 통해 상기 제1 계약 인증서가 상기 제1 EV에 설치될 수 있게 하는 단계;
    제2 EV에 대한 제2 계약 인증서를 제2 외부 CSP로부터 받아들이고, 인증서 프로비저닝 서비스 장치(CPS)에 전달하여 저장하게 하는 단계; 및
    상기 제2 EV가 서비스 네트웍에 진입한 로밍 상황에서, 상기 제2 EV로부터 계약 인증서 설치 요청이 수신되면 상기 CPS에 저장된 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하고, 상기 제2 EV가 충전 승인 요청을 하면 상기 제2 EV에 상기 제2 계약 인증서가 설치된 상태를 토대로 승인을 하는 단계;
    를 포함하는 로밍 환경에서의 피앤씨(PnC) 방식의 EV 충전 승인 방법.
  18. 제17항에 있어서,
    상기 제2 외부 CSP가 상기 충전 서비스 제공 장치와 로밍 계약이 성립되어 있는 모든 외부 CSP들 중 어느 하나인 EV 충전 승인 방법.
  19. 제17항에 있어서, 상기 제2 계약 인증서가 상기 제2 EV에 송신되게 하여 상기 제2 EV에 설치되도록 하는 단계가
    상기 제2 계약 인증서가 상기 제2 EV에 설치된 후에, 상기 제2 외부 CSP에 설치 완료를 통보하는 명령;
    을 포함하는 EV 충전 승인 방법.
  20. 제17항에 있어서, 상기 제2 계약 인증서를 상기 제2 외부 CSP로부터 받아들여 저장하는 단계가
    상기 제2 계약 인증서를 포함한 계약 인증서 체인과 eMAID 정보를 포함하는 인증서 설치 패키지를 받아들여 저장하는 단계;
    를 포함하는 EV 충전 승인 방법.
PCT/KR2021/001437 2020-02-06 2021-02-03 전기차에 대한 계약 인증서 설치 지원 방법 및 장치 WO2021158021A1 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2022548200A JP7527383B2 (ja) 2020-02-06 2021-02-03 電気自動車に対する契約証明書の設置支援方法及び装置
EP21751245.8A EP4102769A4 (en) 2020-02-06 2021-02-03 METHOD AND APPARATUS FOR SUPPORTING THE INSTALLATION OF CONTRACT CERTIFICATES FOR ELECTRIC VEHICLES
US17/797,591 US20230057752A1 (en) 2020-02-06 2021-02-03 Method and device for supporting installation of contract certificate for electric vehicle
CN202180013401.9A CN115088230A (zh) 2020-02-06 2021-02-03 支持电动车辆安装合同证书的方法和设备
JP2024025744A JP2024059807A (ja) 2020-02-06 2024-02-22 電気自動車に対する契約証明書の設置支援方法及び装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202062970777P 2020-02-06 2020-02-06
US62/970,777 2020-02-06

Publications (1)

Publication Number Publication Date
WO2021158021A1 true WO2021158021A1 (ko) 2021-08-12

Family

ID=77200281

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/001437 WO2021158021A1 (ko) 2020-02-06 2021-02-03 전기차에 대한 계약 인증서 설치 지원 방법 및 장치

Country Status (6)

Country Link
US (1) US20230057752A1 (ko)
EP (1) EP4102769A4 (ko)
JP (2) JP7527383B2 (ko)
KR (1) KR20210100545A (ko)
CN (1) CN115088230A (ko)
WO (1) WO2021158021A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023203279A1 (en) * 2022-04-22 2023-10-26 Liikennevirta Oy / Virta Ltd Method to configure electric vehicle charging station to enable plug and charge function

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2024128711A (ja) * 2023-03-10 2024-09-24 トヨタ自動車株式会社 充電制御装置、車両、および、充電制御方法
DE102023106713A1 (de) 2023-03-17 2024-09-19 Bayerische Motoren Werke Aktiengesellschaft Verfahren, Vorrichtungen und Computerprogramme für einen Server und ein Fahrzeug
DE102023106845A1 (de) * 2023-03-20 2024-09-26 Bayerische Motoren Werke Aktiengesellschaft Konzept für eine ladestationsbasierte Ladekontraktauswahl
DE102023106848A1 (de) * 2023-03-20 2024-09-26 Bayerische Motoren Werke Aktiengesellschaft Konzept für nutzerspezifische Provisions- und Ladekontraktzertifikate

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014075889A2 (en) * 2012-11-16 2014-05-22 Volkswagen Aktiengesellschaft Apparatus, method and computer program for initiating a charging process of an electric vehicle
KR101810325B1 (ko) * 2016-07-29 2018-01-26 주식회사 포스코아이씨티 전기차 충전 로밍 시스템, 전기차 충전 로밍이 가능한 충전기 및 전기차 충전 로밍 서버
KR20180086934A (ko) * 2017-01-24 2018-08-01 건국대학교 산학협력단 차량의 인증서 생성 방법 및 장치
WO2019072011A1 (zh) * 2017-10-10 2019-04-18 蔚来汽车有限公司 基于凭证管理的电动车充电方法和系统
KR20190081757A (ko) * 2017-12-29 2019-07-09 주식회사 유라코퍼레이션 전기 차량 충전용 케이블 일체형 제어박스 및 이를 이용한 전기 차량 충전 방법

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2938263T3 (es) * 2016-09-12 2023-04-05 Innogy Innovation Gmbh Método de itinerancia
US10195956B2 (en) * 2017-06-02 2019-02-05 United Arab Emirates University Secure charging method for electric vehicles

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014075889A2 (en) * 2012-11-16 2014-05-22 Volkswagen Aktiengesellschaft Apparatus, method and computer program for initiating a charging process of an electric vehicle
KR101810325B1 (ko) * 2016-07-29 2018-01-26 주식회사 포스코아이씨티 전기차 충전 로밍 시스템, 전기차 충전 로밍이 가능한 충전기 및 전기차 충전 로밍 서버
KR20180086934A (ko) * 2017-01-24 2018-08-01 건국대학교 산학협력단 차량의 인증서 생성 방법 및 장치
WO2019072011A1 (zh) * 2017-10-10 2019-04-18 蔚来汽车有限公司 基于凭证管理的电动车充电方法和系统
KR20190081757A (ko) * 2017-12-29 2019-07-09 주식회사 유라코퍼레이션 전기 차량 충전용 케이블 일체형 제어박스 및 이를 이용한 전기 차량 충전 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4102769A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023203279A1 (en) * 2022-04-22 2023-10-26 Liikennevirta Oy / Virta Ltd Method to configure electric vehicle charging station to enable plug and charge function

Also Published As

Publication number Publication date
US20230057752A1 (en) 2023-02-23
JP2024059807A (ja) 2024-05-01
EP4102769A1 (en) 2022-12-14
JP7527383B2 (ja) 2024-08-02
KR20210100545A (ko) 2021-08-17
JP2023514170A (ja) 2023-04-05
EP4102769A4 (en) 2024-03-13
CN115088230A (zh) 2022-09-20

Similar Documents

Publication Publication Date Title
WO2021158021A1 (ko) 전기차에 대한 계약 인증서 설치 지원 방법 및 장치
WO2022015017A1 (ko) 목표 전력전송량 변경 방법 및 이를 구현하기 위한 전력전송 장치
WO2020218810A1 (ko) Ev 사용자 인가 방법 및 시스템
JP5905286B2 (ja) 電力ネットワークアクセス制御装置および電力ネットワークアクセス制御方法
WO2020222516A1 (ko) 전기차 충전을 위한 교차 인증 방법 및 장치
US12132332B2 (en) Method and apparatus for automatically authenticating electric vehicle charging user based on blockchain
EP4250221A1 (en) Method and device for providing information about pnc-related service provider
WO2021158020A1 (ko) 전기차 충전 스테이션의 부트스트랩 방법
KR20200124621A (ko) Ev 사용자 인가 방법 및 시스템
WO2022114903A1 (ko) 전기차 충전을 위한 교차인증 방법 및 장치
WO2022065989A1 (ko) 전기자동차 충전을 위한 상호인증 장치 및 방법
WO2022055222A1 (ko) 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치
KR20220027781A (ko) 블록체인 기반 전기차 충전사용자 자동인증 방법 및 장치
KR20220034674A (ko) 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치
Kilic Plug and Charge solutions with vehicle-to-grid communication
KR102672072B1 (ko) 교차 인증서를 이용한 전기차 인증 방법 및 장치
WO2022139485A1 (ko) Pnc 관련 서비스 제공자 정보 제공 방법 및 장치
US20230327886A1 (en) Method and device for installing certificate on basis of encryption and decryption of contract certificate private key
WO2024205223A1 (ko) 전기차 충방전 인프라 관리 프로토콜에서 종단 보안 방법 및 장치
EP4219225A1 (en) Device and method for mutual authentication for electric vehicle charging
WO2024186110A1 (ko) 차량 대 차량 전기차 충전 방법 및 장치
KR20220074784A (ko) 전기차 충전을 위한 교차인증 방법 및 장치
WO2022086204A1 (ko) 무선랜 기반 지능형 충전 또는 충방전을 위한 능동적 페어링 방법 및 장치
CN116669985A (zh) 用于提供关于pnc相关服务提供商的信息的方法及装置
WO2022075778A1 (ko) 전기차와 그리드 간 메시지 시퀀싱에서의 조기 재협상 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21751245

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022548200

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021751245

Country of ref document: EP

Effective date: 20220906