KR102454325B1 - Certificate provision method and system - Google Patents

Abstract

The method for providing a certificate of the present invention includes the steps of: requesting, in a charging operating system, to install a certificate for a vehicle connected to a charger to a certificate verification server; verifying the certificate installation request in the certificate verification server; checking all charging services available to the vehicle in the certificate verification server; generating certificate installation files for the vehicle for all the identified charging services and transmitting them to the charging operating system; storing the certificate installation files in the charging operating system; and for each of the charging services applied for use in the vehicle, transmitting and installing the corresponding certificate installation file to the vehicle.

Description

Certificate provision method and certificate provision system {CERTIFICATE PROVISION METHOD AND SYSTEM}

The present invention relates to a vehicle charging method and a certificate providing method for building an electric vehicle charging system having a Plug&Charge function, and to a vehicle charging method capable of supporting the ISO 15118 standard and a certificate providing system therefor.

As a change in the driving energy source of a vehicle, an electric vehicle using a battery as a power source has appeared in order to reduce the consumption of fuel such as gasoline, diesel, and LPG. In an electric vehicle, a generator (generator) is driven by regenerative braking or an existing engine, and electric power generated from the generator is charged to a battery installed in the vehicle. With the spread of electric vehicles, the supply of charging infrastructure such as electric vehicle charging stations equipped with multiple chargers is expanding.

Existing electric vehicle chargers use RFID membership cards/membership numbers and QR codes using mobile phones to authenticate charging members. In the case of chargers of some operators, they allow you to use the charger only with a credit card without member information, but in this case, the charging fee is higher than that of the members. In the beginning, there were 7~8 steps of member authentication and billing process due to the service improvement of the charging infrastructure, but now, the simple payment function has been introduced and reduced to 2~3 steps, so the inconvenience of using the charger has been resolved a lot.

However, in the case of RFID membership cards, not only there is a risk of loss, but also because the services of domestic charger operators are different, people who drive EVs sign up for membership with several charging companies (Hancharge, POSCO ICT, KT, Ministry of Environment, etc.) Keep your cards in your wallet or car. This is because the roaming system in Korea is not yet perfect, so if you arrive at a charging station and are not a member of the relevant operator, you may experience the failure of charging.

In addition, if someone sees an EV charging customer pressing their membership number and password and is exposed, there is a security loophole in which someone can charge free with their member information without knowing it.

Recently, the scene of making payments using the NFC function of mobile phones has become a common occurrence. The wallet, which was thick with multiple cards and cash, was solved with one mobile phone. In addition, when passing a toll-gate on a highway, more than 70% of cars use the high-pass service. In the early days, there were a small number of them due to the cost of the terminal, but these convenient functions were chosen by consumers.

In order to improve the inconvenience of the existing member authentication method and to provide better charging service in the future, the electric vehicle charger also applied the customer automatic authentication (PnC: plug and charge, park and charge) technology suggested by ISO 15118 to the charging infrastructure. . This technology installs an electronic certificate such as an official certificate used for banking transactions in an electric vehicle, and simply connects a charging cable to the electric vehicle to automatically receive services such as member authentication/charger usage authorization/charging/automatic billing and payment. services and technologies available.

In the past, communication was performed only during DC charging. Until now, the protocol that was the origin of ISO 15118 standard called DIN 70121 was used, and the AC charger controlled charging with a control signal called control pilot without digital communication. However, when an older EV communicating with DIN 70121 tries to charge an AC charger to which ISO 15118 is applied, if no passing sequence is specified, it will fall into an infinite loop and will not charge, delay a considerable amount of time, or cause the customer to charge the charging cable. It will make troublesome things to take back and plug it back in.

In order to apply the PnC technology suggested in the standard to our charger, a communication security modem that supports ISO 15118 communication is essential. Some operating techniques and specifications that have not been proposed/used are required.

Meanwhile, existing electric vehicle chargers have communicated with the operation server using each operator's own protocol. These communication messages are mainly used to exchange important information in operating the charging business, such as member authentication, power metering information for billing, and remote update in case of a charger SW problem.

However, such information is very sensitive personal information to customers, but since the authentication system for the charger is weak, various security threats exist between the charger and the operation server. Therefore, it is necessary to introduce an electronic certificate issuance system such as a public certificate to the charging infrastructure.

However, such an electronic certificate is required not only for the charger and the operation server, but also for the electric vehicle connected to the charger, and the need to apply security to the communication between the electric vehicle and the charger is increasing.

The above-mentioned security issue is realistically applied to ISO 15118 international standard communication protocol, and PnC (Plug & Charge: Electronic certificate for transaction is installed in vehicle in advance, and if you connect only connector, use the certificate to automatically perform member authentication, vehicle authentication and It is best to apply the function of charging and billing service). However, since a service model for commercializing and establishing the electronic authentication service was not presented, the location of responsibility and division of roles between operators was vague.

Republic of Korea Publication No. 10-2019-0081210

An object of the present invention is to provide a vehicle charging method and a certificate providing system that enables various types of electric vehicle customers to receive a charging service without interruption when using a charger.

Specifically, the present invention provides a charging method for a vehicle that quickly recognizes a protocol and control sequence applicable to a connected electric vehicle and negotiates a mutually supportable service so that there is no problem in charging an electric vehicle supporting the ISO 15118 standard and an electric vehicle not supporting the existing ISO 15118 standard and a certificate providing system.

An object of the present invention is to provide a vehicle charging method and a system for providing a certificate that can present a model in which responsibility and role division between operators are clear when constructing commercialization of an electronic authentication service.

A method of charging a vehicle according to an aspect of the present invention includes: confirming a connection of the vehicle; In a manner that attempts to communicate with the vehicle connected with a PWM signal having a duty for direct current charging, and generates a PWM signal with a duty for alternating current charging in case of failure, determining the communication and control method to be applied when charging the vehicle step; performing service member authentication for the vehicle in an online or offline manner; performing charging; And it may include the step of performing a settlement for the completion of charging.

Here, in the step of determining the communication and control method, the duty of the PWM signal is checked to determine whether digital communication is performed, the protocol version is analyzed in the case of digital communication, and IEC61851-1 based AC charging is determined in the case of not digital communication can

Here, in the step of performing service member authentication, when data communication with an external server in charge of member authentication is desired, service member information is transmitted to the external server, and an authentication result is received from the external server, and the external server If data communication with the user is not desired, it is received and stored in advance from the external server, and member information who has requested charging can be checked from the whitelist or blacklist within the validity period.

Here, in the step of performing service member authentication, the PnC certificate of the vehicle may be checked for a vehicle supporting the 15118 standard.

Here, when member authentication is performed in a state where data communication with the external server is not smooth, the step of performing the settlement includes the charger confirming that the requested charging is complete, signing and storing the charging termination information, When the online communication channel with the external server is restored, the stored information may be transferred to the external server.

Here, generating a certificate according to the type of vehicle in the external security server; and storing the generated certificate in the vehicle or subscriber terminal.

A vehicle charging charger according to another aspect of the present invention includes: a cable assembly for performing charging power transmission or communication signal transmission/reception through a vehicle connection terminal connected to a vehicle charging terminal; an MCU controlling vehicle battery charging through the vehicle connection terminal; a meter for measuring the amount of power of charging the vehicle battery; An embedded board that stores charge termination information and integrates a driver function for the display; and a secure communication module for performing communication with a vehicle connected by a PLC communication method through the cable assembly, performing Ethernet communication with externally spaced servers, and signing a charger private key.

A vehicle charging charger according to another aspect of the present invention includes: a cable assembly for transmitting charging power or transmitting and receiving a communication signal through a vehicle connection terminal connected to a vehicle charging terminal; an MCU controlling vehicle battery charging through the vehicle connection terminal; a meter for measuring the amount of power of charging the vehicle battery; An embedded board in which the driver function for the display is integrated and performs Ethernet communication with externally spaced servers; and a 15118 modem that communicates with a vehicle connected by a PLC communication method through the cable assembly and performs local communication with the embedded board.

A method for providing a certificate according to another aspect of the present invention includes the steps of: requesting, in a charging operation system, installation of a certificate for a vehicle connected to a charger to a certificate verification server; verifying the certificate installation request in the certificate verification server; checking all charging services available to the vehicle in the certificate verification server; generating certificate installation files for the vehicle for all the identified charging services and transmitting them to the charging operating system; storing the certificate installation files in the charging operating system; and for each of the charging services applied for use in the vehicle, transmitting and installing the corresponding certificate installation file to the vehicle.

Here, the certificate installation file may be generated by the V2G root authority server that has jurisdiction over the charging operating system according to the verification of the certificate verification server.

Here, in the step of installing the certificate installation file, in response to the request for continuous installation of the vehicle, the charging operating system sets the logic such as priority and generation priority in the certificate installation file received from the certificate verification server by itself. You can respond one by one.

A system for providing a certificate according to another aspect of the present invention includes: an infrastructure operation server for generating a certificate installation request for a vehicle; a certificate verification server that verifies the certificate installation request and secures a certificate installation file for the certificate installation request; a charging service provider server that provides a charging service for the vehicle using the certificate; and a certificate verification API that performs secure communication with the certificate verification server, an infrastructure API that performs secure communication with the infrastructure operation server, and a charging business API that performs secure communication with the charging service provider server. may include

Here, the charging operating system may store a plurality of certificate installation files for the vehicle, and provide some of the stored certificate installation files to the vehicle according to a request of the infrastructure operation server or the charging service provider server.

Here, it may further include a root authentication server that generates a certificate according to the certificate installation request.

Here, the infrastructure API performs data communication with the authentication API provided in the infrastructure operation server, the charging business API performs data communication with the service API provided in the charging service provider server, and the certificate verification API is the certificate Data communication can be performed with the message link API provided in the verification server.

If the vehicle charging method and/or certificate providing system according to the spirit of the present invention having the above configuration is implemented, there is an advantage that various types of electric vehicle customers can receive a charging service without interruption even when using a charger.

The vehicle charging method and/or certificate providing system of the present invention quickly recognizes protocols and control sequences applicable to connected electric vehicles, regardless of ISO 15118 standard supported electric vehicles and existing unsupported electric vehicles, and negotiates mutually supportable services there is an advantage to

The vehicle charging method and/or certificate providing system of the present invention includes element technologies necessary for providing charging services to new electric vehicles to be launched at home and abroad, including CMO construction business, and as ISO 15118 standards are applied, charger manufacturers, charging services It has the advantage of supporting the commercialization of operators.

The vehicle charging method and/or certificate providing system of the present invention has the advantage of further spreading the spread of electric vehicles and increasing the utilization of charging infrastructure.

The vehicle charging method and/or certificate providing system of the present invention has the advantage of being able to support various service models for servicing the PKI system based on ISO 15118 in actual B2B, B2C, and the like.

The vehicle charging method and/or certificate providing system of the present invention is advantageous in that it is possible to build a security system that can safely link charging infrastructure data, and provides a basis for acquiring more data to the charging infrastructure operation platform There is this.

1 is an old electric vehicle (Type#1) based on the DIN 70121 protocol and a new electric vehicle (Type#2 / Type#3) to which the ISO 15118 protocol is applied and a charger to which the ISO 15118 standard is applied. Diagram.
2 is a flowchart illustrating an embodiment of a method for charging an electric vehicle according to the spirit of the present invention.
3 is a flowchart of a determination logic for determining a communication and control method to be applied when charging when connected to a vehicle charger;
4 is a flowchart illustrating an embodiment of a sequence required for local authentication using the above-described whitelist.
5 is a flowchart illustrating an embodiment of a sequence for generating messages necessary for a settlement process after charging according to local authentication according to FIG. 4;
6 and 7 are block diagrams illustrating embodiments of a charger constituting a charging system according to the spirit of the present invention.
8 is a flowchart illustrating a method for providing a certificate according to the spirit of the present invention.
9 is a configuration diagram illustrating an electronic authentication system of an electric vehicle charging infrastructure based on each PKI actor defined in ISO 15118.
10 is a block diagram illustrating a certificate providing system for performing a certificate providing process in the configuration of the electronic authentication system of FIG.
Fig. 11 is a block diagram showing a connection configuration between an authentication API and an infrastructure API;
Fig. 12 is a block diagram showing the linkage configuration of the message linkage API and the certificate verification API.
13 is a block diagram illustrating a configuration of a link between a service API and a charging business API.
Fig. 14 is a block diagram showing a linkage configuration between a service API and a message linkage API;
15 is a block diagram illustrating a connection configuration between a charging application of an electric vehicle and a service API.
Fig. 16 is a block diagram showing a configuration of a vehicle manufacturer PKI, a service API, and a message linkage API.

In describing the present invention, terms such as first, second, etc. may be used to describe various components, but the components may not be limited by the terms. The terms are 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.

When a component is referred to as being connected or connected to another component, it may be directly connected or connected to the other component, but it can be understood that other components may exist in between. .

The terms used herein are used only to describe specific embodiments, and are not intended to limit the present invention. The singular expression may include the plural expression unless the context clearly dictates otherwise.

In this specification, the terms include or include are intended to designate that a feature, number, step, operation, component, part, or combination thereof described in the specification exists, and includes one or more other features or numbers, It may be understood that the possibility of the presence or addition of steps, operations, components, parts, or combinations thereof is not precluded in advance.

In addition, shapes and sizes of elements in the drawings may be exaggerated for clearer description.

First, we will look at the prerequisites to be satisfied by the present invention.

The charger to which the ISO 15118 communication security modem is applied should not have any problem in charging existing electric vehicles, and new electric vehicles launched in the future should also be charged well. By quickly recognizing these protocols and control sequences and applying an algorithm to negotiate mutually supportable services, EV customers can receive charging services without interruption when using chargers.

In addition, since the operation server of the electric vehicle charger communicates with numerous chargers scattered across the country, an offline situation sometimes occurs. This can occur for various reasons, and systems that can properly collect charging charges (member authentication and payment status check, etc.) are generally based on online status. However, if the charger is offline and charging is not allowed because the relevant information cannot be checked online, customer complaints will be enormous. A local authentication system is provided.

In addition, although it is not specifically presented in ISO 15118, as mentioned above, there may be several certificates for PnC service because charging providers are multiple institutions. Therefore, we present a method and sequence required when installing these various agency certificates in a vehicle.

1 shows cases that require review between an old electric vehicle (Type#1) based on the existing DIN 70121 protocol, a new electric vehicle (Type#2 / Type#3) to which the ISO 15118 protocol is applied, and a charger to which the ISO 15118 standard is applied. it has been shown

In addition, as shown in Table 1 below, each type of electric vehicle will experience the charger (EVSE) initial setting protocol after the connector is fastened. At this point, the charger has to make a decision. This is the part marked Decision on which communication and control method to select to charge the vehicle. After that, the charger determines the control of the vehicle connected to it and performs charging according to the standard indicated on the far right of the table below.

2 is a flowchart illustrating an embodiment of a method for charging an electric vehicle according to the spirit of the present invention.

The illustrated electric vehicle charging method can be viewed as a charging method that is led by a charger installed in a charging station, and includes the steps of confirming the connection (connector connection) of the electric vehicle (connector connection) (S100); It attempts to communicate with the vehicle connected with a PWM signal having a duty for DC charging, and generates a PWM signal with a duty for AC charging in case of failure, and determines the communication and control method to be applied when charging the connected vehicle. to (S200); performing service member authentication for the connected vehicle in an offline manner (S300); performing charging for the vehicle authenticated as a service member (S400); And it may include a step (S600) of performing a settlement for the charging completion.

A certificate for a vehicle or a subscriber is required for the above-described service member authentication, etc., and the certificate may be performed prior to connection of a connector for charging. In this case, generating a certificate according to the type of vehicle in the external security server; and storing the generated certificate in the vehicle or subscriber terminal.

In particular, the certificate can be provided while satisfying the conditions stipulated by the ISO15118 standard, which will be described later.

3 is a flowchart illustrating a decision logic for determining a communication and control method to be applied when the charger is charged when the vehicle is connected to a charger.

First, if the charging cable is checked in the EV vehicle (S100), the duty of the PWM signal indicating the need for digital communication is checked (S210). At this time, if the 5% duty cycle is mutually understood, the matching signal (matching performed by SLAC in the case of PLC communication and Beacon in the case of WiFi) will be received from the vehicle to the charger (S220). At this time, when the SLAC is normally completed in the SLAC reception process (S220), the charger (specifically, the communication modem) analyzes the protocol version (S230) and communicates/charges with the corresponding protocol (S401, S402). That is, if the communication method supported by the connected vehicle is ISO15118 according to the protocol (version) analysis result, charging is performed using ISO15118 protocol digital communication (S401), and if the communication method supported by the connected vehicle is DIN70121, DIN70121 Charging is performed using protocol digital communication (S402).

On the other hand, if there is no SLAC request in the SLAC reception process (S220), retry is attempted within the maximum number of times (additional two times in the standard) (S240, S260) (At this time, the control pilot PWM, which means cable re-bonding, is removed. If there is no request after that, the charger considers that there is no communication, accepts the PWM as a PWM signal for AC charging (S250), and AC according to the control signal based on IEC61851-1 Charging proceeds (S403).

After performing ISO15118 charging (S401), DIN70121 charging (S402), or IEC61851-1 based charging (S403), settlement is performed according to the charging amount (S600).

However, as mentioned above, since the charger can be offline from the operating server, the charging operating system (or infrastructure operator (operating) server) performs a Whitelist (or blacklist) can be provided to the charger.

Specifically, in the case of ISO 15118 PnC service, there is an EMAID that corresponds to a membership number, and the charging service provider that manages this information has this EMAID value or hash value, status information of the PnC contract certificate installed in the vehicle, and payment billing. The status information required for member authentication/billing, such as whether the information is currently valid and information on the charging rate table, is delivered to the charging operation system (or infrastructure operator (operation) server), and the charging operation system (or infrastructure operator (operation) server) This information is provided to the chargers in the form of the whitelist (or blacklist). At this time, a TLS security channel is being established between the charger and the charging operating system (or the infrastructure operator (operating) server). This PnC authentication whitelist may send full information, or may send only increment/decrement information in consideration of network traffic efficiency. This may vary depending on the operating policy.

4 is a flowchart illustrating an embodiment of a sequence required for local authentication using the above-described white list.

In the illustrated flowchart, first looking at the whitelist creation process, the charging operator server that holds the service contract/member information creates the contents of the whitelist (S312), and stores the generated whitelist information and the updated information in the charging operating system ( Or, it is transmitted to the infrastructure operator (operation) server (S314). The charging operating system (or infrastructure operator (operating) server) performs notification, request and response/download processes (S316, S322, S324) for charger and whitelist information or updated information, and as a result, the The white list is stored in the internal storage of the charger (S326).

If the communication network between the charger and the spaced servers is smooth, the stored white list is not used, and member authentication may be performed by the server.

On the other hand, in the case of a network failure in the flowchart shown (or if there is a local operation instruction by policy), the EV is connected to the charger using the above whitelist information to request membership authentication, and the charger uses this information is used for member authentication and charging authorization (S355). At this time, the charger must perform the procedure (S360) to check whether the EV has the private key of the PnC certificate specified in ISO15118. Thereafter, when charging is finished, the charger signs and stores the charging termination information (S460), and when the charger is restored online, the information is transmitted to a separated server so that payment can be made (S582, S584, S590).

5 is a flowchart illustrating an embodiment of a sequence for generating messages necessary for a settlement process after charging according to local authentication according to FIG. 4 . That is, a protocol processing method different from the standard is proposed for processing the termination message during the local authentication processing described above. In order to examine the specific operation of the charger, detailed hardware 221 , 261 , and 281 of the charger are concretely shown.

In the past, chargers process and store charge termination information on the charger embedded board, and the integrated security module handles the security functions that were not previously available. The board 281 generates charging end information (message) (S482) and transmits it to the integrated security module 261 (S483).

At this time, the integrated security module 261 adds other ISO 15118-based charging termination information including PnC (S485), signs the charger (EVSE) private key (S486), and sends it back to the charger embedded board 281 ( S488), the charger embedded board 281 stores it in the history form (S489).

The above-described series of processes may all be performed within the embedded board rather than the integrated security module. In this case, it means that all mechanisms for securely communicating information related to charging, such as signing a termination message with the charger certificate to the operation server, and the messaging process for ISO 15118 secure communication can be integrated and provided.

Afterwards, when the network between the charger and the separated servers resumes online, this signed termination message is transmitted to the separated server (S495), and the charging operating system (or infrastructure operator (operating) server) performs signature verification through signature verification. It can be confirmed that the corresponding end information has not been altered (S496). It is confirmed that it has not been tampered with, that is, a payment request according to the properly terminated local mode charging may be transmitted to a payment agency server or the like (S498).

6 and 7 are block diagrams illustrating embodiments of a charger constituting a charging system according to the spirit of the present invention.

For the above functions, the charger must be equipped with an ISO 15118 secure communication module, and the two types shown can exist. It can support secure communication function between operation servers.

In the case of the charger shown in FIG. 6, while minimizing changes in the configuration of the conventional charger, it is a flexible configuration that can satisfy the requirements according to the ISO15118 standard and the local authentication support function, and in the case of the charger shown in FIG. 7, the ISO15118 standard It is a configuration in which the requirements are applied very strictly.

In the case of the charger of the type according to FIG. 6, the HW link connection is changed and applied inside the previously operated charger as an integrated security communication module type to the previously built charger, and a communication security function with the EV vehicle is added, and security with the operation server It is a model that can add function + communication control function.

In the case of the charger of the type according to FIG. 7, there is an advantage of being able to process and provide all functions more simply and naturally as a new charger type.

The charger for charging the vehicle shown in FIG. 6 includes a vehicle connection terminal 20 connected to a charging terminal of the vehicle; a cable assembly 210 for transmitting charging power or transmitting and receiving a communication signal through the vehicle connection terminal; an MCU 221 that controls charging of a vehicle battery through the vehicle connection terminal; a meter 241 for measuring the amount of electric power of charging the vehicle battery; an embedded board 281 with integrated driver functions for the display 290; and a security communication module 261 that communicates with a vehicle connected by a PLC communication method through the cable assembly 210 and performs Ethernet communication with externally spaced apart servers.

In the illustrated configuration, the charging termination information is processed and stored in the embedded board 281 , and the integrated security module 261 can process an existing security function.

On the other hand, the embedded board 281 does not have ISO 15118-related information, and the addition of other ISO 15118-based charging termination information including PnC according to charging termination in local mode and the charger (EVSE) private key signature is performed by the integrated security module 261 ) is performed.

The signed charging termination information may be stored in the embedded board 281 in the form of history.

Also, the embedded board 281 may receive the measured value of the meter 241 , package it as the integrated security module 261 , and transmit it to an external remote server.

In the illustrated charger, charging control and charging power amount check are performed centered on the embedded board 281 , and through the secure communication module 261, Ethernet communication with externally spaced servers is performed, which is a conventional charger. This is to minimize changes in configuration and achieve service flexibility using the secure communication module 261 .

The above-described series of processes can be applied to the conventional charger, and these functions can be integrated and implemented in the SW inside the embedded board to provide the functions.

The whitelist (or blacklist) may be stored in the secure communication module or in a separate storage device with enhanced security so that only the secure communication module can access it.

The charger for charging the vehicle shown in FIG. 7 includes a vehicle connection terminal 20 connected to a charging terminal of the vehicle; a cable assembly 210 for transmitting charging power or transmitting and receiving a communication signal through the vehicle connection terminal; MCU (222) for controlling the vehicle battery charging through the vehicle connection terminal; a meter 242 for measuring the amount of power of charging the vehicle battery; The embedded board 282 in which the driver function for the display 290 is integrated and performs Ethernet communication with externally spaced servers; and a 15118 modem 262 that communicates with a vehicle connected by a PLC communication method through the cable assembly 210 and performs local communication with the embedded board 282 .

In the case of FIG. 7 , in order to strictly apply the requirements according to the ISO15118 standard, the measured value of the meter 242 is transmitted to the MCU 222 that controls charging through RS-485 communication.

The 15118 modem 262 of FIG. 7 communicates with a vehicle connected through the PLC communication method through the cable assembly 210 and also performs serial data communication with the embedded board 282 . Meanwhile, the embedded board 282 performs Ethernet communication with externally spaced apart servers. In this configuration, external access to the 15118 modem 262 is blocked, and the embedded board 282 is exclusively responsible for processing communication packets.

According to implementation, similar to the case of FIG. 6 , a whitelist (or blacklist) may be stored in the 15118 modem 262 , or the 15118 modem 262 may access a separate storage device and read it.

8 is a flowchart illustrating a method for providing a certificate according to the spirit of the present invention.

The illustrated method for providing a certificate includes the steps of requesting the CPS 600 to install a certificate for the EV vehicle 10 connected to the charger 200 in the charging operating system 400 (S22); verifying the certificate installation request in the CPS (600); checking all charging services available to the vehicle (10) in the CPS (600); generating and transmitting certificate installation files for the vehicle for all the identified charging services to the charging operating system 400 (S25); storing the certificate installation files in the charging operating system 400; and for each of the charging services applied for use in the vehicle, transmitting and installing the corresponding certificate installation file to the vehicle (S44 and S54).

In the step of checking all available charging services, not only charging services provided by charging operators (MO) under the jurisdiction of the V2G route institution supported by the charging operating system 400, but also other V2G routes connectable to the network Charging services from institutions are also available.

The certificate installation file is generated by the V2G root authority server having jurisdiction over the charging operating system 400 according to the verification of the CPS and transmitted to the charging operating system 400 .

8 is a schematic diagram of a process for receiving PnC certificates from a number of charging providers and installing them as EVs through a charger. Since ISO 15118 ed1 does not specifically suggest a method for connection with the backend infrastructure or a method for installing multiple contract certificates (certificates for PnC), it is possible to install multiple certificates using messages and standards that can be expressed as standards. proposed a way out.

As shown in FIG. 8, first, the contract information requested from a plurality of charging service providers is made into an installation message by an institution called the CPS 600, and the installation request message requested by the first EV 10 (S12) is transmitted through the charging operating system 400. The request is received (S13, S22), and the response is transferred to the charging operating system 400 (S25). At this time, the CPS 60 secures certificate installation files (installation messages) for all charging services according to the result of checking all charging services available to the vehicle 10, and charges all certificate installation files (installation messages). can be communicated to system 400 .

Accordingly, if the electric vehicle connected to the charger has the function or ability to receive multiple certificates, the installation request can be continued through the charger, and in this case, the charging operating system 400 receives the certificate it has received from the CPS 600 . You can respond one by one by setting your own logic such as priority and creation priority in the installation file (installation message).

At this time, when the charging operating system 400 responds for the first time, INIT is followed by NEXT, and when it is the last of the certificate installation file (installation message) it has, COMP (complete) is displayed (S92), and then in the vehicle 10 When an installation request comes to the charger, the charger can transmit a response code (=FAILED_NoCertificateAvailable), which is a response code specified in ISO 15118, to the EV indicating that there is no more certificate to send (S94).

Afterwards, the part for the use of the installed certificate (S96) and the PnC authentication request is selected by the user (customer, driver) in the vehicle, or is initially set based on an algorithm, etc. can be

9 shows the configuration of the electronic authentication system of the electric vehicle charging infrastructure based on each of the PKI actors defined in ISO 15118.

As for the unique function of the PKI actor described and defined in ISO 15118, the description will be omitted as it is a known content.

Briefly looking at each actor, V2GRoot is the highest level of the charging infrastructure certification system, the CPO (Charge Point Operator) is the operator that builds and operates the charger (i.e., the charging infrastructure operator), and the CPO PKI is the charger and operation An entity that issues and manages certificates to servers, etc. OEM PKI is a vehicle manufacturer certification system, and has a system that issues a unique certificate to a vehicle and inserts it during vehicle manufacturing. MO (eMobility Operator) is the entity that provides and charges charging service to actual customers, such as charging member management, billing, and charging rate setting. CPS (Certificate Provisioning Service) is an entity that creates an installation message dedicated to ISO15118 required to install the contract certificate issued by the MO to the vehicle.

As shown, each individual may exist in plurality. For the role and linkage of these various entities, the charging infrastructure electronic authentication service is an entity for the integrated Web/Was function related to the idea of the present invention according to the entities that function unique to ISO15118 PKI and the charging infrastructure characteristics and linkage structure. can also be distinguished. This can be seen as dividing the charging infrastructure platform and operating system into another operator system and entity that will provide electronic authentication services.

First, V2GRoot manages the CPO PKI (SubCA) that exists under itself, and in the case of the same operator or business area as itself, it will be managed internally. You can register information and receive and operate your own SubCA certificate. At this time, if another CPO operates its own SubCA, for example, a certificate is issued from the CPO SubCA operated by KEPCO, and secure communication of the operating server and charger, and the ISO 15118 security system can be implemented. At this time, the integrated Web receives the information of the target that can identify the device by SubCA and charger/operation server, verifies the information, and issues and manages the certificate through a secure channel (the private key is generated by the device and converted to the electronic authentication system) We recommend only requesting a certificate issuance, but in the case of a small business operator, it can be transmitted through a secure system).

In addition, the integrated web supports operator and person in charge notification and auto-renewal service when the certificate expiration period arrives, distributes CRL (revocation information) for issued certificates, SubCA certificates, etc., and provides status information (OCSP) for issued certificates and SubCA certificates. ), provides the OCSP Stapling function (EV and EVSE direct OCSP access is restricted), and cross-certificate issuance or transmission for different V2GRootCA mutual authentications can be performed.

For example, when the PnC authentication service is supported according to the above-described linkage scheme. MO (Charging Service Provider) may have its own root according to ISO 15118, but may exist as a SubCA under V2GRoot. In terms of security, it is advantageous for the MO to have a root, but in terms of cost, it is advantageous to be below V2GRoot. In the present invention, the MO also includes a service that can be issued a SubCA like the CPO subCA. First, the MO registers and verifies the identity of its entity, and is then issued a SubCA certificate. At this time, the SubCA private key is generated by itself.

When the electric vehicle user accesses the service of the MO and applies for the PnC service, the MO generates contract information and requests the CPS APP in the electronic authentication service of the present invention to generate a PnC certificate installation file (message). At this time, CPS acts on behalf of the certificate installation service and performs validation of the certificate issued by the MO described in ISO 15118 and the validity of the electric vehicle-specific certificate. At this time, the installation message (PnC InstallRes) installed in the electric vehicle enters the electric vehicle through the CPS-operation server-charger, but if necessary, it can also perform the function of delivering the installation message so that it can be delivered in an offline manner. have.

FIG. 10 is a block diagram illustrating a certificate providing system for performing a certificate providing process in the configuration of the electronic authentication system of FIG. 9 .

The illustrated certificate providing system includes an infrastructure operation server 700 that generates a certificate installation request for a vehicle; a certificate verification server 600 that verifies the certificate installation request and secures a certificate installation file for the certificate installation request; a charging service provider server 800 that provides a charging service for the vehicle using the certificate; And a certificate verification API 460 for performing secure communication with the certificate verification server 600, an infrastructure API 470 for performing secure communication with the infrastructure operation server 700, and the charging service provider server 800 and and a charging operating system 400 having a charging business API 480 for conducting secure communication.

The charging station operating system 400 stores a plurality of certificate installation files for the vehicle 10 , and according to the request of the vehicle 10 , the infrastructure operation server 700 or the charging service provider server 800 , Some of the stored certificate installation files are provided to the vehicle 10 .

In the drawing, the V2G root authentication server 1000 and other root servers that generate a certificate according to the certificate installation request are also represented.

As a configuration for performing charging and providing a certificate according to the spirit of the present invention by operating in conjunction with the charging operating system 400 , the infrastructure operating server 700 includes an authentication API 740 , and the charging service provider server 800 includes a service API 840 , and the certificate verification server 600 includes a message association API 640 .

As shown, the authentication API 740 performs data communication with the infrastructure API 470 , the service API 840 performs data communication with the charging business API 480 , and the message-related API 640 performs data communication with the certificate verification API 460 .

The infrastructure operation server 700 , the charging service provider server 800 , and the certificate verification server 600 are provided with PKI modules 670 , 770 , 870 defined by the above-described ISO15118 standard, respectively.

Next, in the illustrated certificate providing system, protocols and transactions between actors will be described in detail.

11 is a diagram illustrating a connection configuration between the authentication API 740 and the infrastructure API 470 .

The illustrated linkage configuration is a CPOS ↔ V2G_RootCA / CPO_SubCA configuration, which generates a key pair for issuing a CPOS certificate, generates a certificate issuance request message (CSR), and requests issuing, renewing, and reissuing of the operating server and charger certificates etc., performs/represents the status check for issued operating server and charger certificates, performs certificate validation (OCSP, CRL, etc.), and provides the function of extracting certificate information (DN information, etc.). In addition, it performs the function of requesting revocation of the issued certificate or downloading the revocation list (CRL) periodically and storing it in a cache if necessary.

As shown, the authentication API 740 and the infrastructure API 470 constitute a pair for data communication according to the spirit of the present invention, and the PKI module 770 is another external root server or a competent V2G route ( 1000) and data communication specified in the standard.

Table 2 below is a linkage rule for generating a key pair for issuing an X.509-based certificate.

Table 3 below is a linkage rule for generating an X.509-based certificate issuance request message.

Table 4 below is the linkage rules for requesting issuance, renewal, and reissuance of CPO SubCA sub-leaf certificates.

Table 5 below is a linkage rule for performing a status check on the issued certificate.

Table 6 below is a linkage rule for performing validation on the issued certificate.

Table 7 below is an association rule for extracting a certificate DN value.

Table 8 below is the linkage rules for certificate revocation request.

Table 9 below is a linkage rule for downloading the revocation list of the issued certificate.

Table 10 below is the linkage rules for the periodic download and cache storage of the certificate revocation list.

12 shows the configuration of the linkage between the message linkage API 640 and the certificate verification API 460 .

The illustrated linked configuration is a CPOS ↔ CPS_APP configuration, and performs certificate installation and renewal requests, and notifies certificate installation and renewal results. Specifically, it is possible to obtain a response to the PnC certificate installation and renewal request requested from the vehicle for the certificate installation and renewal request, and as a result, to notify the processing result of the Install/UpdateRes statement transmitted from the CPS.

In addition, between the charging operating system (CPOS) 400 and the electronic authentication service CPO PKI, the operation server and charger unique information generation, each device key pair generation and CSR generation are performed, and identity information input and verification ( authentication), and after entering the specific information of the subject to be issued, the policy, and the CSR, the certificate can be issued. In this case, password setting and certificate/private key issuance (pfx) may be performed to operators and devices that do not generate private keys.

13 is a diagram illustrating a connection configuration between the service API 840 and the charging business API 480 .

The illustrated linkage configuration is a CPOS ↔ MO_APP configuration, which requests EMAID whitelist, requests PnC authentication/authorization, performs ISO 15118 SalesTariff request/response, and performs PnC charging termination settlement request.

To request the EMAID whitelist, obtain a whitelist of EMAID accounts with valid PnC authentication/authorization in preparation for offline situations in the charging infrastructure network, and the whitelist is changed in response to changes such as additions and exclusions can be

Table 11 below is a linkage rule for performing a PnC authentication/authorization request.

Table 12 below is an association rule for performing ISO 15118 SalesTariff request/response.

Table 13 below is a link between CPOS → MO for termination and billing after PnC charging.

14 is a diagram illustrating a configuration of the service API 840 and the message association API 640 in association.

The illustrated linkage configuration is a MO_APP ↔ CPS_APP configuration, and for example, PnC contract data transmission according to Table 14 below may be performed. In this case, according to the method specified in the ISO15118 standard, the charging service provider server 800 and the certificate verification server 600 may perform direct communication. If the charging service provider is small and does not meet sufficient security conditions, the charging business API 480 and the certificate verification API 460 may relay bilateral communication.

In addition, between the charging service provider (MO) server 800 and the certificate verification server 600 (CPS), the above-described CPS function can be accurately known from the electric vehicle, the charger, the operation server, etc. when the actual electric vehicle customer uses the PnC service. By monitoring the corresponding error or non-ideal situation in the CPS with no content, and notifying the charging service provider server 800, the charging service provider (MO) enables customer management.

For example, it is possible to notify the charging service provider server 800 of management requests such as contract renewal and deletion when the certificate installation information is not downloaded for more than a certain period of time that contract information regeneration and validity re-verification are required when the certificate installation fails in the vehicle.

For example, if the update validity period is not renewed for a certain period of time, the customer and the charging service provider (MO) may be notified by SMS or the like that the service will be limited later.

For example, if the certificate installation message to the CPS is continuously repeated, the access may be for the purpose of hacking, so the customer information protection system is activated after checking whether the certificate is normally installed and charged, etc. etc.) can be taken.

15 is a diagram illustrating a connection configuration between a charging application of an electric vehicle and the service API 840 .

The illustrated connection configuration is a MO_APP ↔ Charging APPP configuration, which performs member registration and information connection, pushes the valid authorization information of the PnC service member (transmits the valid authorization information whitelist of the PnC service member and its change value), A payment request (Reserved) is performed from the MO to the Charging APP.

The electric vehicle is generally connected to the communication network via the connected charger and charging operating system 400 , and the bilateral data communication of the illustrated MO_APP ↔ Charging APPP configuration can be relayed by the charging business API 480 .

Table 15 below is the linkage rules for PnC service member information and contract creation.

Table 16 below is a linkage regulation for PnC charging termination billing/payment request.

16 is a diagram illustrating a configuration of a vehicle manufacturer's PKI, the service API 840, and the message association API 640 linking.

The illustrated linkage configuration is a MO_APP / CPS_APP ↔ OEM configuration, and performs vehicle certificate verification and acquisition and vehicle certificate validation. For example, by making an OCSP request for the EV provisioning certificate and checking the OCSP response result, the validity of the EV certificate can be checked by requesting the OEM OCSP server.

According to the method specified in the ISO15118 standard, the charging service provider server 800 and the certificate verification server 600 may directly communicate with the vehicle manufacturer PKI. If the charging service provider is small and does not meet sufficient security conditions, the charging business API 480 and the certificate verification API 460 may relay mutual communication.

Table 17 below is a linkage regulation for vehicle certificate verification and acquisition.

In addition, although not shown as a separate diagram, the tasks of subCA unique information generation, SubCA operation policy setting, certificate key pair generation, and CSR generation are performed between SubCA and V2GRootCA of other organizations such as CPO/MO, and identity on the electronic authentication service integrated web Information input and verification (authentication) are performed, SubCA unique information, policy, and CSR input are performed, a certificate is issued, SubCA certificate injection, and work for establishing and operating a sub-Leaf certification system is performed.

In addition, between charging operating system (CPOS) - electronic certificate issuance verification service CPS PKI, ISO 15118 contract (PnC) certificate issuance/renewal request message verification and response message verification, root certificate system verification in contract certificate request message (own root is ) is performed, manages multiple contract (PnC) certificate installation messages received from the MO, and responds to a certificate issuance message according to priority when requesting a contract (PnC) certificate issuance from the charging operating system (CPOS) certificate processing) may be performed.

Those skilled in the art to which the present invention pertains should understand that the present invention may be embodied in other specific forms without changing the technical spirit or essential characteristics thereof, so the embodiments described above are illustrative in all respects and not restrictive. only do The scope of the present invention is indicated by the following claims rather than the detailed description, and all changes or modifications derived from the meaning and scope of the claims and their equivalent concepts should be construed as being included in the scope of the present invention. .

10: electric vehicle
200: charger
400: charging operating system
460: Certificate Validation API
470 : Infrastructure API
480 : Charging Business API
600: Certificate Verification Server
640: Message Association API
700: infrastructure operation server
740 : Authentication API
800: charging operator server
840 : service API
1000: V2G root authentication server

Claims (15)

delete delete delete delete delete delete delete delete requesting the certificate verification server to install a certificate for the vehicle connected to the charger in the charging operating system;
verifying the certificate installation request in the certificate verification server;
checking all charging services available to the vehicle in the certificate verification server;
generating certificate installation files for the vehicle for all the identified charging services and transmitting them to the charging operating system;
storing the certificate installation files in the charging operating system; and
Transmitting and installing a corresponding certificate installation file to the vehicle for each of the charging services applied for use in the vehicle
A method of providing a certificate comprising a.
10. The method of claim 9,
The certificate installation file is a certificate providing method that is generated by the V2G root authority server that has jurisdiction over the charging operating system according to the verification of the certificate verification server.
10. The method of claim 9,
In the step of installing the certificate installation file,
A method of providing a certificate in which the charging operating system responds one by one to the request for continuous installation of the vehicle by setting logic such as priority and generation priority in the certificate installation file received from the certificate verification server.
an infrastructure operation server that generates a certificate installation request for a vehicle;
a certificate verification server that verifies the certificate installation request and secures a certificate installation file for the certificate installation request;
a charging service provider server that provides a charging service for the vehicle using the certificate; and
Charging operating system having a certificate verification API for performing secure communication with the certificate verification server, an infrastructure API for performing secure communication with the infrastructure operation server, and a charging business API for performing secure communication with the charging service provider server
A certificate providing system that includes.
13. The method of claim 12,
The charging operating system,
Store a plurality of certificate installation files for the vehicle,
Certificate providing system, characterized in that for providing some of the stored certificate installation files to the vehicle in response to a request of the infrastructure operation server or the charging service provider server.
13. The method of claim 12,
A root authentication server that generates a certificate according to the certificate installation request
A certificate providing system further comprising a.
13. The method of claim 12,
The infrastructure API performs data communication with the authentication API provided in the infrastructure operation server,
The charging business API performs data communication with the service API provided in the charging service provider server,
The certificate verification API is a certificate providing system for performing data communication with the message link API provided in the certificate verification server.

Images