WO2022055222A1 - 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치 - Google Patents

계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치 Download PDF

Info

Publication number
WO2022055222A1
WO2022055222A1 PCT/KR2021/012135 KR2021012135W WO2022055222A1 WO 2022055222 A1 WO2022055222 A1 WO 2022055222A1 KR 2021012135 W KR2021012135 W KR 2021012135W WO 2022055222 A1 WO2022055222 A1 WO 2022055222A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
private key
contract
encryption
installation
Prior art date
Application number
PCT/KR2021/012135
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
Priority claimed from KR1020210118599A external-priority patent/KR20220034674A/ko
Application filed by 현대자동차주식회사, 기아 주식회사, 명지대학교 산학협력단 filed Critical 현대자동차주식회사
Priority to CN202180062436.1A priority Critical patent/CN116472693A/zh
Priority to US18/025,452 priority patent/US20230327886A1/en
Priority to EP21867088.3A priority patent/EP4195587A4/en
Publication of WO2022055222A1 publication Critical patent/WO2022055222A1/ko

Links

Images

Classifications

    • 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/3247—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 digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys

Definitions

  • the present invention relates to a certificate installation technology for a vehicle, and more particularly, to a method and apparatus for installing a certificate based on encryption and decryption of a contract certificate private key for an electric vehicle communication controller.
  • An electric vehicle uses an XML signature method defined in standards or regulations to authenticate itself and transmits information to the outside through a transport layer security (TLS) protocol.
  • Information transfer takes place between an EV communication controller (EVCC) of an electric vehicle, a supply equipment communication controller (SECC) of an EV supply equipment (EVSE), and a secondary actor (SA).
  • EVCC EV communication controller
  • SECC supply equipment communication controller
  • SA secondary actor
  • the sender when exchanging an XML message between SA, SECC and EVCC, the sender writes the reference ID in the message to be signed.
  • the reference ID indicates which content is signed.
  • the sender calculates the EXI (efficient XML interchange) value of the content to be signed as SHA256, and puts the digest value encoded in Base64, etc. into the DigestValue field of the reference.
  • the sender then digitally signs the XML message or part of the XML message using a specific class (SignedInfo) and puts the value in the SignatureValue field.
  • the receiver uses the value of the DigestValue field in the XML message received from the sender to check whether the message data has been tampered with, and then verifies the value of the SignatureValue field.
  • a mobility operator (MO) or an electro-mobility service provider (eMSP) must encrypt a contract certificate to be installed in an electric vehicle and a corresponding secret key and deliver it to the electric vehicle.
  • MO mobility operator
  • eMSP electro-mobility service provider
  • related standards or regulations recommend using the ECDHE (elliptic curve Diffie-Hellman ephemeral) key exchange algorithm using elliptic curve cryptography.
  • MO or eMSP uses advanced encryption standard (AES)-CBC (cipher block chaining)-128 with a 128-bit initialization vector (IV) at the beginning to encrypt a contract certificate and a pair of secret keys.
  • AES advanced encryption standard
  • CBC cipher block chaining
  • IV 128-bit initialization vector
  • the private key corresponding to the contract certificate is encrypted using a session key derived from an elliptic curve Diffie-Hellman (ECDH) protocol.
  • the initialization vector (IV) can be randomly generated prior to encryption and can be 128-bits long, but can never be reused.
  • the initialization vector is transmitted by being included in the most significant 16-byte of a specific field (eg, ContractCertificateEncryptedPrivateKey) of a predetermined message for certificate installation.
  • the contract certificate data packet containing the encrypted private key is transferred from the MO or eMSP to the certificate provisioning service (CPS).
  • the role of the CPS may be assumed by, for example, an MO or eMSP itself, an EVSE operator, or a fully stand-alone service provider.
  • the CPS converts the message received from the MO/eMSP into a format defined in standards or regulations or a transmission format that can be received by an electric vehicle, puts its own signature, and then delivers it to the electric vehicle through the SECC.
  • the signature of the CPS guarantees the authenticity of the data passed to the EVCC of the electric vehicle.
  • the aforementioned contract certificate data packet is transmitted from the MO to the CPS, and is transmitted from the CPS to the EVCC through the SECC along with the signature of the CPS.
  • the contract certificate data packet has a data format with a 128-bit long initialization vector (IV), a 256-bit encrypted private key, and a field with the least significant 128-bit length not specifically specified.
  • TPM trusted platform module
  • the present invention is to meet the needs of the prior art described above, and an object of the present invention is to provide a mobility operator (MO) or an electro-mobility service provider (eMSP) in a vehicle to grid (V2G) environment.
  • MO mobility operator
  • eMSP electro-mobility service provider
  • V2G vehicle to grid
  • Another object of the present invention is to contract the highly confidential private key received by the EVCC from a mobility operator (MO) or an electro-mobility service provider (eMSP) in a vehicle to grid (V2G) environment.
  • An object of the present invention is to provide a method and apparatus for installing a certificate based on encryption and decryption of the contract certificate private key for EVCC, which can be decrypted with the certificate private key.
  • the public key encryption method that can be employed in the certificate installation method according to an aspect of the present invention for solving the above technical problem is a certificate installation method by encryption and decryption of a contract certificate private key for an electric vehicle communication controller, the electric vehicle transmitting, by the communication controller, a certificate installation request message signed with the private key associated with the manufacturer's provisioning certificate to the secondary actor; and receiving, from the secondary actor, a certificate installation response message signed with a private key associated with a leaf certificate of the certificate provisioning service.
  • the certificate installation response message includes a contract certificate data packet including a signature installation data element
  • the signature installation data element includes a contract certificate chain element and an encrypted private key element
  • the encrypted private key element is trusted. It stores the private key belonging to the encrypted new contract certificate for the EV communication controller without the platform module.
  • the private key belonging to the new contract certificate is encrypted with advanced encryption standard (AES)-GCM (galois/counter mode) based on the encryption key input from the public key of the manufacturer provisioning certificate and generated through the ECDH protocol, , the AES-GCM-encrypted private key is included as a cipher text or encrypted private key field in the 528-bit or 448-bit following the initial 96-bit to 128-bit initialization vector of the contract certificate data packet.
  • AES advanced encryption standard
  • GCM Galois/counter mode
  • a public key encryption device that can be employed in a certificate installation device according to another aspect of the present invention is an apparatus for installing a certificate in an electric vehicle by encryption and decryption of a contract certificate private key, the device comprising: a processor; a memory storing instructions executed by the processor; and a communication interface connected to the processor and communicating with an external device through a network. and when the processor is executed, the instructions may include: sending, by the processor, a certificate installation request message signed with the private key associated with the manufacturer provisioning certificate to the secondary actor; and receiving a certificate installation response message signed with a private key associated with a leaf certificate of the certificate provisioning service from the secondary actor.
  • the certificate installation response message includes a contract certificate data packet including a signature installation data element, the signature installation data element includes a contract certificate chain element and an encrypted private key element, and the encrypted private key element is trusted. It stores the private key belonging to the encrypted new contract certificate for the EV communication controller without the platform module.
  • the private key belonging to the new contract certificate is encrypted with advanced encryption standard (AES)-GCM (galois/counter mode) based on the encryption key input from the public key of the manufacturer provisioning certificate and generated through the ECDH protocol, , the AES-GCM-encrypted private key is included in the encrypted private key field of the contract certificate data packet as a 528-bit or 448-bit ciphertext following the preface 96-bit to 128-bit initialization vector.
  • AES advanced encryption standard
  • GCM Galois/counter mode
  • a public key encryption device that can be employed in a certificate installation device according to another aspect of the present invention for solving the above technical problem is a device for installing a certificate in an electric vehicle by encryption and decryption of a contract certificate private key, the processor ; a memory storing instructions executed by the processor; and a communication interface connected to the processor and communicating with an external device through a network.
  • the instructions may include: receiving, by the processor, a certificate installation request message signed by the private key associated with the manufacturer provisioning certificate from the electric vehicle communication controller; and transmitting a certificate installation response message signed with the private key associated with the leaf certificate of the certificate provisioning service to the electric vehicle communication controller, wherein the certificate installation response message includes a contract certificate data packet including a signature installation data element, , the signature installation data element includes a contract certificate chain element and an encrypted private key element, and the encrypted private key element stores a private key belonging to an encrypted new contract certificate for an electric vehicle communication controller without a trust platform module.
  • the private key belonging to the new contract certificate is encrypted with advanced encryption standard (AES)-GCM (galois/counter mode) based on the encryption key input from the public key of the manufacturer provisioning certificate and generated through the ECDH protocol, , the AES-GCM-encrypted private key is included in the contract certificate data packet as a 528-bit or 448-bit ciphertext after the opening 96-bit to 128-bit initialization vector.
  • AES advanced encryption standard
  • GCM Galois/counter mode
  • the private key used in AES is 128-bit and its number of bits is small, confidentiality is low when creating the private key through the random number generator, so the private key can be predicted relatively easily by an attacker. problems can be improved.
  • the contract certificate private key transmitted to the EVCC by a mobility operator (MO) or an electro-mobility service provider (eMSP) in a vehicle to grid (V2G) environment is confidentiality (confidentiality).
  • MO mobility operator
  • eMSP electro-mobility service provider
  • V2G vehicle to grid
  • a secondary actor transmits the contract certificate secret key to an EV communication controller (EVCC) with high confidentiality, so that, in addition to a certificate installation request or certificate installation response message, electric vehicle charging or automatic Confidentiality is increased in messages related to authentication, such as approval request, charge amount confirmation request, and charging parameter discovery response messages, which are key elements required for electric vehicle-related communication security, such as confidentiality, integrity, availability, and authentication. It has the advantage of increasing the overall reliability of authenticity.
  • EV electric vehicle
  • 'certificate installation method' a certificate installation method based on encryption and decryption of a contract certificate private key for an electric vehicle communication controller according to an embodiment of the present invention
  • FIG. 2 is a conceptual diagram for explaining a structure of wireless electric power transmission associated with a method for installing a certificate according to an embodiment of the present invention.
  • FIG. 3 is a schematic block diagram of an electric vehicle charging infrastructure associated with a method for installing a certificate according to an embodiment of the present invention.
  • PKI public key infrastructure
  • FIG. 5 is a conceptual diagram for explaining a method for installing a certificate according to an embodiment of the present invention.
  • 6 to 8 are diagrams for explaining a certificate installation related message that can be employed in the certificate installation method of FIG. 5 .
  • 9A and 9B are diagrams for explaining an encryption and decryption process of a SECP521-based encrypted private key that can be employed in the certificate installation method of FIG. 5 .
  • 10A and 10B are diagrams for explaining an encryption and decryption process of an X448-based encrypted private key that can be employed in the certificate installation method of FIG. 5 .
  • FIG. 11 is a schematic block diagram of a certificate installation device based on encryption and decryption of a contract certificate private key for an electric vehicle communication controller (hereinafter, simply 'certificate installation device') according to another embodiment of the present invention.
  • FIG. 12 is a block diagram of an AES-GCM core that can be employed in the certificate installation device of FIG. 11 .
  • FIG. 13 is a schematic block diagram of an apparatus for installing a certificate according to another 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.
  • a 'wireless power charging system (WCS)' may refer to a system for wireless power transmission, alignment, and communication between a ground assembly (GA) and a vehicle assembly (VA).
  • WPT Wireless power transfer
  • '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 electric energy available to electric vehicles through price tags or discrete events.
  • utilities can provide information on tax rates, intervals for metered power consumption, and validation of EV programs for EVs.
  • Smart charging' may refer to an operating method or system in which an EVSE and/or an electric vehicle optimizes a vehicle charging or discharging rate according to grid capacity or cost of use while communicating with a 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 via a two-part loosely coupled transformer.
  • the inductive charging system may correspond to an electric vehicle wireless 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.
  • An 'Original equipment manufacturer (OEM)' is an electric vehicle manufacturer or a server operated by an electric vehicle manufacturer, and may include a CA (Certificate Authority) or a top-level authentication server that issues an OEM root certificate.
  • CA Certificate Authority
  • V2G operator' refers to a primary actor participating in V2G communication using a transport protocol, or starts a blockchain for automatic authentication of electric vehicles or electric vehicle users and creates a smart contract on the blockchain. It may refer to an entity for the purpose, and may include at least one or more trusted certification authorities or trusted certification servers.
  • 'Mobility operator (MO)' shall refer to one of the entities within the PnC architecture that has a contractual relationship with the EV owner for charging, authorization and payment to allow EV drivers to charge EV batteries at charging stations. and may include at least one or more certification authorities or certification servers that issue and manage their own certificates.
  • the charging service provider may be referred to as a mobility operator.
  • CSP Charge service provider
  • a 'Charging station (CS: Charging station)' may refer to a facility or device that has one or more EV supply equipment and actually performs charging for the EV.
  • CSO Charging station operator
  • CPO Charge point operator
  • eMSP eMobility Service Provider
  • the CSO, CPO, or eMSP may include at least one or more certification authorities that issue or manage their own certificates.
  • An 'e-Mobility Authentication Identifier (eMAID)' may refer to a unique identifier that connects a contract certificate to a payment account of an owner of an electroMobility using electricity.
  • the mobility account identifier may include an identifier of an electric vehicle certificate or an identifier of a provisioning certificate. This term eMAID may be substituted to refer to 'e-Mobility Account Identifier' or may be substituted with a contract ID.
  • CH Clearing house
  • 'Roaming' refers to information exchange and related matters that allow electric vehicle users to access charging services provided by multiple CSPs or CSOs belonging to multiple mobility networks using a single 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 electric vehicle or electric vehicle user. 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 identifier (ID) by a digital signature.
  • a 'service session' may refer to a set of services related to electric vehicle charging at a charging point, assigned to a certain customer in a certain timeframe with a unique identifier.
  • the certificate installation method based on encryption and decryption of the contract certificate private key for the electric vehicle communication controller is a power supply communication controller (SECC) of a charging station through a wired or wireless link.
  • SECC power supply communication controller
  • the secondary actor connected to the equipment communication controller transmits the contract certificate and the private key to the electric vehicle (EV) connected to the SECC.
  • FIG. 1 is a conceptual diagram for explaining a structure for charging an electric vehicle (EV) wire associated with a method for installing a certificate according to an embodiment of the present invention.
  • EV electric vehicle
  • wired charging of an electric vehicle may be performed by connecting an electric vehicle 10 (hereinafter referred to as 'EV') to a power supply circuit of a charging station by a charging cable 30 .
  • 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. there is.
  • the EV 10 may have a vehicle inlet that may be connected to a vehicle connector of the charging cable 30 .
  • the vehicle inlet provided in the EV 10 may support slow charging, support fast charging, or support both 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 . Meanwhile, when DC power for rapid charging is supplied to the vehicle inlet, the DC power may be supplied to the battery to be charged without going through the on-board charger.
  • the charging cable 30 may be configured to include a charging connector 31 and a plug 33 , or further include an in-cable control box (ICCB) 32 .
  • ICCB in-cable control box
  • the charging connector 31 is a connection part that can be electrically connected to the EV 10 , and the plug 33 can be connected to a charging device of a charging station or a socket-outlet 40 of a power supply device.
  • the socket-outlet 40 refers to a connection point between the charging device of the charging station and the plug 33 or the vehicle inlet, but the present invention is not limited thereto, and the socket-outlet 40 is connected to a charging device installed in another place. It may mean a connection point between the plug or the charging cable 30 .
  • the socket-outlet 40 is, in addition to commercial specialized charging station facilities, a garage or parking lot attached to the home of the EV 10 owner, a parking area allocated for EV charging at a gas station, a parking area at a shopping center or workplace, etc. It may represent a wall jack installed in a charging facility, and the like.
  • the incable control box 32 may communicate with the EV 10 to receive status information of the EV or control power charging to the EV 10 .
  • the in-cable control box 32 may be installed in a form integrally coupled to the charging cable 30, but is not limited thereto, and may be connected to a power supply circuit (not shown) that supplies power to the EV 10 in the charging station. connected or disposed within the power supply circuit.
  • the incable control box 32 may correspond to a power supply communication controller to be described later.
  • the electric vehicle 10 and the incable control box 32 may be connected to each other through power line communication, and the incable control box and the secondary actor may be connected to each other through at least one of a wired and wireless communication network.
  • FIG. 2 is a conceptual diagram for explaining a structure of wireless electric power transmission associated with a method for installing a certificate according to an embodiment of the present invention.
  • wireless power transfer for an electric vehicle transfers electrical energy from a supply network to a consumer side from a supplier side device through a magnetic field in a magnetic induction or magnetic resonance state without current flow through a galvanic connection. It can be defined as delivering to the device.
  • the wireless power transmission may be used to charge the battery 150 of the EV 10 by transmitting power from the charging station GA1 to the EV 10 .
  • the EV 10 may include a receiving pad 130 having a receiving coil for wirelessly receiving electromagnetic energy from the transmitting pad GAP1 of the charging station GA1 .
  • the receiving coil in the receiving pad 130 receives magnetic energy from the transmitting coil of the transmitting pad GAP1 in the charging station GA1 by electromagnetic induction or magnetic resonance.
  • the magnetic energy received by the EV 10 is converted into an induced current, and the induced current is rectified into a DC current and then used to charge the battery 150 .
  • the charging station GA1 may receive power from a commercial power grid G1 or a power backbone, and may supply energy to the EV 10 through the transmission pad GAP1.
  • EV supply equipment (EVSE) corresponding to the charging station (GA1) is a garage or parking lot attached to the owner's house, a parking area for EV charging at a gas station, and parking in a shopping center or business building. It may be located in various places, such as a zone.
  • the charging station GA1 may communicate with a power infrastructure management system or an infrastructure server that manages the power grid G1 through wired/wireless communication. Also, the charging station GA1 may perform wireless communication with the EV 10 .
  • Wireless communication may include wireless LAN (WLAN)-based communication based on Wi-Fi according to the IEEE 802.11 protocol, and also a low frequency (LF) magnetic field signal and/or low power magnetic field (LPE: Low Power Excitation) ) signal using P2PS communication.
  • Wireless communication between the charging station GA1 and the EV 10 may include one or more of various communication methods such as Bluetooth, Zigbee, and cellular.
  • the EV 10 and the charging station GA1 may exchange messages according to an extensible markup language (XML) or an efficient XML interchange (EXI) based data expression format to perform a charging process. That is, communication for a charging process between an Electric Vehicle Communication Controller (EVCC) and a Supply Equipment Communication Controller (SECC) may be performed through a wireless LAN (WLAN) or the like.
  • XML extensible markup language
  • EXI efficient XML interchange
  • the EV In the communication process for the charging process, the EV first verifies the identity of the charging station 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.
  • a secure channel may be achieved by TLS (Transport Layer Security).
  • the TLS session may be performed according to the TLS session establishment procedure after the IP (Internet Protocol)-based communication connection establishment procedure.
  • the certificate installation method establishes a secure channel based on the electric vehicle charging infrastructure and the certificate of the main entity of the infrastructure.
  • an electric vehicle charging infrastructure and a public key infrastructure (PKI)-based certificate hierarchy that can be employed in this embodiment will be described as follows.
  • FIG. 3 is a schematic block diagram of an electric vehicle charging infrastructure associated with a method for installing a certificate according to an embodiment of the present invention.
  • the electric vehicle charging infrastructure is for providing a charging service to the EV 10 , and includes a charging station operator (CSO) 210 , a charging station (CS) 220 , Mobility operator (MO) 300, Certificate provisioning serveice (CPS) 390, Original Equipment Manufacturer server 400, Charge service provider (CSP) 220 ), a vehicle-to-ground (V2G) server 600 , a contract certificate pool (CCP) 700 , and a clearing house (CH: Clearing house) 800 .
  • CSO charging station operator
  • CS charging station
  • MO Mobility operator
  • CPS Certificate provisioning serveice
  • V2G vehicle-to-ground
  • CCP Charge service provider
  • CCP Charge service provider
  • V2G vehicle-to-ground
  • CCP contract certificate pool
  • CH clearing house
  • the EV 10 refers to a general vehicle owned by an electric vehicle user, and can be charged by wire or wirelessly at a charging station.
  • EV 100 may have a unique OEM provisioning certificate installed during manufacturing.
  • a contract with the operator of the MO 300 is completed, such as a vehicle purchase contract, a contract certificate may be installed in the EV 10 .
  • a root certificate of the vehicle-to-ground (V2G) server 600 may be installed in the EV 10 .
  • the electric vehicle manufacturer (Original Equipment Manufacturer) server (hereinafter abbreviated as 'OEM') 400 is a top-level certification authority (CA) that issues OEM root certificates, and its sub-certification bodies (OEM SubCA 1, OEM SubCA 2) are also operated. and keep When EV 10 is manufactured.
  • the OEM 400 can use the OEM intermediate chain certificate (OEM SubCA 2 cert.) to generate an OEM provisioning certificate and install it on the EV 10 .
  • a mobility operator (MO) 300 is a service provider that enters into a contractual relationship with an electric vehicle user regarding charging, approval, and payment so that the electric vehicle user can charge the EV 10 at the charging station 200 .
  • MO 300 may be operated by an electricity supplier or electricity wholesaler that sells energy.
  • the MO 300 also acts as a top-level certification authority (CA) that issues a 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 a contract certificate.
  • the MO certificate chain may also be used to verify the contract certificate installed in the EV 10 in a non-roaming environment or in a roaming environment.
  • the MO may be referred to as an e-mobility service provider (eMSP).
  • eMSP e-mobility service provider
  • the certificate provisioning service (CPS: Certificate provisioning serveice) 390 transmits the encryption key used for certificate transmission and reception along with the contract certificate chain in the process of installing or updating the contract certificate in the EV 10 or the same. provided to the client.
  • the CPS 390 may include a leaf provisioning certificate (Leaf Prov cert.) and provisioning intermediate chain certificates (Prov SubCA 1 cert., Prov SubCA 2 cert.).
  • the CPS 390 is a public key of each MO, a Diffie Hellman (DH) public key, and an e-Mobility authentication identifier (eMAID) along with the contract certificate chain. ), allowing the EV 10 to use them to verify the contract certificate chain and verify the integrity and authenticity of the contract certificate.
  • DH Diffie Hellman
  • eMAID e-Mobility authentication identifier
  • a contract certificate pool (CCP) 700 temporarily stores a response message for installing or updating a certificate while a contract certificate is installed or updated in the EV 10 .
  • the response message may be stored in the CCP 700 in advance and maintained until the certificate installation or update is completely completed. Since there may be multiple EVs 10 for which the contract certificate installation or update is performed, the response message may be maintained in the form of a directory after a reference number is assigned.
  • V2G server 600, hereinafter abbreviated as 'V2G'
  • 'V2G' vehicle-to-grid server
  • PKI public key infrastructure
  • the V2G 600 serves as the highest trust anchor, and all actors shown in FIG. 3 may regard the V2G root CA as a trusted organization.
  • a charging station (CS) 220 actually performs charging for the EV 10 .
  • the charging station 220 may have at least one wired charger and/or a wireless charging spot.
  • One or more charging stations 220 may be installed in commercial specialized charging facilities.
  • the charging station 220 may be located in various places, such as a garage or parking lot attached to an electric vehicle user's house, a parking area for charging an electric vehicle at a gas station, a shopping center or a parking area at work.
  • the charging station 220 may be referred to as a 'charging point', 'electric vehicle charging station', 'electric vehicle charging point', 'charging point', 'electric vehicle charging station (ECS)', or 'electric vehicle power supply system (EVSE)'. there is.
  • a charging station operator (CSO) 210 or a charging point operator (CPO) manages electricity to operate a charging station and provide a requested energy transfer service.
  • the CSO 210 may be operated by, for example, a charging station manufacturer, an electric vehicle power supply manufacturer, or an electricity supplier.
  • the CSO 210 includes the sub-certificates (CPO SubCA 1, CPO SubCA) required to generate a power supply communication controller (SECC) leaf certificate for each charging station 220 . 2) can be operated.
  • a charge service provider (CSP) 500 manages and authenticates credentials of an electric vehicle user, and provides billing and other value-added services to customers.
  • the CSP 500 may be considered to correspond to a special type of the MO 300 , and may be implemented in a form combined with the MO 300 .
  • a plurality of CSPs 500 may exist, each CSP 500 may be linked to one or more CSOs 210 , and the CSP 500 and one or more CSOs 210 may constitute one charging network.
  • the EV 10 is, when the contract certificate is installed, PnC (Plug and charge / Park and charge) in the CSO 210 linked to the CSP 500 associated with the MO 300 in the contract relationship. You can receive charging service in this way, but roaming is required if you want to recharge from another CSO that is associated with a non-contractual MO.
  • Each CSP 500 may exchange information with another CSP or CSO in another network for roaming, and may also exchange information with the clearing house 800 .
  • a clearing house (CH: Clearing house) 800 processes cooperation between a plurality of MOs 300 and a plurality of CSPs 500 .
  • the clearing house (CH, 800) may act as an intermediary that facilitates the approval, billing, and settlement procedures for EV charging service roaming between two settlements or payment parties.
  • CH 800 when the armature user wants to charge the EV at a charging station that does not belong to the network of the MO 300 with which the armature user has a contract, the CH 800 is connected by the CSO 210 or the CSP 500 and roams. We can support you to make this happen. In situations where roaming is required. CH 800 allows CSO 210 or CSP 500 to contract with MO 300 and pass authorization and billing data to MO 300 .
  • CH 800 are 'contract clearing house (CCH)', 'mobility clearing house (MCH: Mobility clearing house)', 'roaming platform', 'e-mobility clearing house (E-) MOCH: E-MObility clearing house) 'and the like may be referred to.
  • CSO Charging Service Operator
  • CPS 'Certificate Provisioning Service
  • MO 'Mobility Operator
  • CH 'Contract Clearing House
  • 'V2G' refer to a person or an organization of people. Although it may appear to refer, in this specification including the claims, 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.
  • 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.
  • electric vehicle charging service and related infrastructure are fields in which various industrial fields such as automobiles, power grid, energy, transportation, communication, finance, and electronic products are grafted.
  • CSO charging station operator
  • CPO charge point operator
  • a charging service provider CSP
  • MO mobility operator
  • a public key infrastructure (PKI) is used for secure communication such as a PnC procedure or message transmission/reception between entities.
  • PKI provides a framework for verifying the identity of people and devices, enabling confidential communication, and ensuring controlled access to resources.
  • PKI public key infrastructure
  • an EV manufacturer acts as a root certificate authority (CA) that issues an OEM RootCA cert. It also operates certification bodies (OEM SubCA 1, OEM SubCA 2). Accordingly, OEM generates OEM intermediate chain certificates (OEM SubCA 1 cert. cert., OEM SubCA 2 cert.) by signing with their private key as well as the OEM root certificate (OEM RootCA cert.).
  • CA root certificate authority
  • OEM SubCA 1 cert. cert., OEM SubCA 2 cert. OEM intermediate chain certificates
  • OEM SubCA 2 uses the private key paired with the public key contained in the OEM secondary intermediate chain certificate (OEM SubCA 2 cert.) to create the OEM Provisioning Certificate (OEM). Prov cert.) and install it on the EV.
  • This OEM Provisioning Certificate can be used to verify the signature of the request message during the certificate installation request process for the EV, and uniquely identifies the vehicle over the life of the EV.
  • MO Mobility operator
  • CA top-level certification authority
  • the MO can generate the primary intermediate chain certificate (MO SubCA 1 cert.) by adding its own signature to the ID and public key of the primary subCA (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 is A contract certificate is generated using the paired private key, and it is transmitted, for example, through the EV supply equipment (EVSE) power supply communication controller (SECC) of the charging station that the EV initially visits. It can be installed in EVs.
  • the contract certificate can be linked to the EV user's payment account via a unique identifier called an e-Mobility Account Identifier (eMAID).
  • the OEM provisioning certificate (OEM Prov cert.) and the contract certificate (Contract Certificate) are generated based on the root certificates (OEM RootCA cert., MO RootCA cert.) generated by the OEM and the MO, respectively, and also the global root certificate It can be generated based on (V2G RootCA cert.) and is independent of certificates used by other actors. However, as indicated by a dashed line in FIG. 3, by using the V2G root certificate (V2G RootCA cert.) instead of the OEM and MO root certificates (OEM RootCA cert., MO RootCA cert.), the OEM provisioning certificate (OEM Prov) cert.) and a contract certificate can also be generated.
  • a V2G server (hereinafter, 'V2G' for short) generates at least two series of certificates, namely, a certificate series for CSO (corresponding to 'CPO' as mentioned above) and SECC of charging station, and a certificate series for provisioning service. support you to do it
  • V2G can create 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 subordinate CA (MO SubCA 1) can create a secondary intermediate chain certificate (CPO SubCA 2 cert.) by adding its 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 EVSE's SECC to be installed.
  • This SECC Leaf Certificate can be used by the EV during TLS communication setup to verify that the EV is communicating with a real charging station and not a fake charging station.
  • This certificate can be stored not only on the SECC, but also on the CSO's backend server.
  • V2G can create 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 own 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 function to be installed by sending it to the Certificate Provisioning Service (CPS).
  • CPS Certificate Provisioning Service
  • each root CA V2G RootCA, MO RootCA, OEM RootCA
  • each subordinate CA can issue an OCSP certificate and provide it to clients such as electric vehicles. That is, clients such as electric vehicles may access the OCSP server according to the Online Certificate Status Protocol (OCSP), request revocation/non-revocation status information regarding the validity of the certificate, and receive the inquiry result.
  • OCSP Online Certificate Status Protocol
  • an OCSP signer certificate by a specific signer is shown as available only for CPO subCAs (CPO SubCA 1, CPO SubCA 2), but all root CAs (V2G RootCA, MO RootCA, OEM RootCA) can issue and provide an OCSP certificate to check the validity of their root certificate series certificates.
  • the certificate receiver can restore the hash by decrypting the signature value in the certificate with the public key in the certificate, and compare 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 from the root certificate to the leaf certificate in the certificate chain with the issuer information of the subordinate CA.
  • the certificate recipient checks whether the certificate has been revoked through the Certificate Revocation List (CRL) received from the root CA for the corresponding certificate, or by inquiring the certificate status to the OCSP server linked to the root CA. By doing so, validity can be verified.
  • CTL Certificate Revocation List
  • the following describes in detail the process of installing the contract certificate in the electric vehicle communication controller through encryption and decryption of the contract certificate private key by the secondary actor in the aforementioned electric vehicle wired or wireless charging infrastructure and public key-based certificate hierarchy environment.
  • FIG. 5 is a conceptual diagram for explaining a method for installing a certificate according to an embodiment of the present invention.
  • the certificate installation method of this embodiment includes installing a contract certificate (CC) in an EV communication controller (EVCC) that does not include a trusted platform module (TPM) 2.0. and a process of encrypting the contract certificate private key in a secondary actor (SA) such as an e-Mobility service provider (eMSP) 300 in order to do so.
  • a contract certificate CC
  • EVCC EV communication controller
  • TPM trusted platform module
  • SA secondary actor
  • eMSP e-Mobility service provider
  • the SA For the minimization of the distribution path and communication processing time and simple structural processing, the SA generates a key pair for the certificate, then uses the key pair to generate its own certificate, and stores the generated contract certificate and the corresponding private key. It is distributed to EVCC (100). In order to maintain the confidentiality of the contract private key, a security mechanism is used for secure transmission of the contract certificate private key.
  • the contract certificate (CC) is a certificate (Sub-CA 1 certificate) 350 issued for the EVCC 100 by the eMSP primary sub-certification authority of the eMSP 300 and/or the eMSP secondary sub-certification authority is the EVCC 100 ) may include a certificate issued for (Sub-CA 2 certificate) 360 .
  • the contract certificate may be used for XML signatures on the application layer to verify the signature generated by EVCC 100 .
  • a public key (hereinafter also referred to as a 'contract public key') 370 belonging to a contract certificate (CC) is contracted from a secondary actor (SA) such as the eMSP 300 to the EVCC 100 It is used to encrypt the contract private key for security when the certificate and contract private key are distributed. That is, the encryption of the contract certificate (CC) includes the secondary actor or the root certificate 312 of the eMSP 300, or the public included in the eMSP primary intermediate CA certificate 350 or eMSP secondary intermediate CA certificate 360.
  • a private key paired with the key (contract public key) 370 may be used.
  • a data packet (CCDP) of the encrypted contract private key (K1) may include a mobility account identifier (eMAID) corresponding to an electric vehicle user.
  • the contract private key 380 is an authentication tag based on the ECDH (Elliptic-curve Diffie-Hellman) shared secret key input from the public key 412 of the OEM provisioning certificate 411 . tag) can be encrypted with AES (Advanced encryption standard) in GCM (Galois/counter mode).
  • the ECDH shared secret key may correspond to the encryption parameter M3.
  • the contract private key (K1) to which the authentication tag is bound can be encrypted with AES in GCM mode based on the ECDH shared secret key input from the public key 412 of the OEM provisioning certificate.
  • the ECDH shared secret key includes a DH temporary public key (K2, 372) and a DH temporary private key.
  • a DH temporary secret key or a DH ephemeral Diffi-Hellman private key corresponding to the DH temporary public keys K2 and 372 may be prepared separately.
  • An e-Mobility service provider (eMSP) 300 may use the root certificate 312 to generate a contract certificate.
  • the root certificate 312 is an eMSP root CA certificate, and this root does not need to exist in the EVCC, but the certificate provisioning service (CPS) needs to process the contract certificate according to a preset procedure.
  • CPS certificate provisioning service
  • the eMSP 300 may generate a credential for the EVCC 100 that constitutes a contract certificate and includes an encrypted contract certificate private key, that is, a key specifically encrypted for the EVCC 100 .
  • This credential may be stored in a specific message field (SignedInstallationData).
  • the eMSP 300 distributes the contract certificate and the encrypted private key to the EVCC 100 through the online installation path via the SECC 200 of the EVSE, a contract certificate data packet (CCDP). ) or a certificate installation package including the same, a certificate installation response (CIR) message may be transmitted to the CPS 390 through a preset communication channel of general B2B communication.
  • CCDP contract certificate data packet
  • CIR certificate installation response
  • the CPS 390 uses its signature to give the credential accuracy and reliability, and relays the signed message to the SECC 200 .
  • the SECC 200 may compile a certificate installation response (CertificateInstallationRes) message and transmit it to the EVCC 100 .
  • the certificate providing service is considered reliable, and therefore the EVCC 100 does not need to verify the contract certificate received through the certificate installation response message.
  • the role of the aforementioned CPS 390 may be assumed by, for example, the eMSP itself, an EVSE operator, or a completely standalone service provider.
  • the aforementioned credential may include information such as a symmetric key shared by the eMSP 300 and the EVCC 100 in advance or an ID that can be used to confirm the physical or logical identity of the EVCC 100 .
  • the aforementioned credential may include a public key paired with the private key of the EVCC 100, or a public key certificate or certificate chain for the public key.
  • the certificate chain may include a provisioning certificate chain.
  • the provisioning certificate is a certificate used for one-time authentication through the EVCC 100, and since the CPS leaf certificate is issued and installed after authentication is completed, it can be used for subsequent authentication.
  • the eMSP 300 or SA provides multiple contract certificates based on different curves as defined in standards or regulations
  • the eMSP 300 or SA provides multiple different signed installation data containers to the SECC 200, and the EVCC 100 may obtain and install all different contract certificates by utilizing a looping mechanism for the certificate installation request (certificatleInstallationReq) message at the discretion of the electric vehicle user.
  • the EVCC 100 may use the private key associated with the electric vehicle public key ('subjectPublicKey') of the OEM provisioning certificate 411 to sign the body element of the certificate installation request message.
  • the above-described certificate installation method uses a temporary static Diffie-Hellman key exchange protocol to derive a session key in which the recipient's key is static.
  • the SA or esMSP transmits the private key in an encrypted format to the EVCC 100 using the derived session key.
  • the public key of the recipient e.g. EVCC 100 is not changed. That is, it is static and is already known to the sender, ie, the eMSP 300 . However, the sender 300 may continue to use the temporary public key transmitted to the receiver. In this way, both sender and receiver can derive the same session key without the receiver's response message. Since SA uses a temporary key, the derived session key is different for each instance (distribution) of the private key or private key.
  • the CPS 390 asserts the accuracy and reliability of the credentials using the signature, and relays the signed message fragment P2 to the SECC 200 .
  • the SECC 200 may compile a certificate installation response (CertificateInstallationRes) message received from the CPS 390 and transmit it to the EVCC 100 .
  • the certificate provisioning service is considered reliable, and therefore the EVCC 100 does not need to verify the contract certificate received through the certificate installation response message.
  • 6 to 8 are diagrams for explaining in more detail a certificate installation related message that can be employed in the certificate installation method of FIG. 5 .
  • the electric vehicle communication controller transmits a Certificate Installation Request message signed by the private key associated with the manufacturer's provisioning certificate to the secondary actor, and from the secondary actor, the individual associated with the leaf certificate of the certificate provisioning service You may receive a Certificate Installation Response message signed with the key.
  • the certificate installation response message generated by the secondary actor includes a Contract Certificate Data Packet including a Signed Installation Data element.
  • the signature installation data element includes a Contract Certificate Chain element and an Encrypted Private Key element.
  • the encrypted private key element stores a private key belonging to an encrypted new contract certificate for an electric vehicle communication controller without a trusted platform module (TPM).
  • TPM trusted platform module
  • AES advanced encryption standard
  • GCM Galois/counter mode
  • the secondary actor may include a mobility service provider (eMSP) or a charging service provider (MO).
  • eMSP mobility service provider
  • MO charging service provider
  • AES is an algorithm that encrypts actual data
  • GCM refers to a method that prevents data guessing by combining blocked encryption packets in block-level encryption.
  • the certificate installation request message type (Certificate Installation Request Type) transmitted by the electric vehicle charging controller (EVCC) to the secondary actor (SA), an attribute including an ID (attributes) element and, OEM Provisioning Certificate Chain, List of Root Certificate IDs, Maximum Contract Certificate Chain, and Prioritized eMAIDs may include elements .
  • the Manufacturer Provisioning Certificate Chain is an EV-specific certificate chain consisting of the OEM Provisioning Certificate and the OEM Sub-CA Certificate previously installed by the OEM in the EVCC.
  • the ID of the OEM provisioning certificate i.e., Provisioning certificate identifier (PCID)
  • PCID Provisioning certificate identifier
  • the PCID can also be used in the eMSP to identify the contract belonging to the associated EV. This is possible if the EV user provided the PCID to the eMSP when creating the contract.
  • the PCID can be generated as a short string unique to the OEM that generated the provisioning certificate, and can be included in the manufacturer's provisioning certificate.
  • the manufacturer provisioning certificate may be encoded with distinguished encoding rules (DER).
  • DER distinguished encoding rules
  • the OEM provisioning certificate itself, i.e. the public key, can later be used to encrypt the private key associated with the contract certificate in the CertificateInstallationRes message.
  • the PCID may be provided to the SA through another communication channel from the electric vehicle user.
  • the manufacturer provisioning certificate chain may include a Certificate element and SubCertificates element as sub-elements.
  • the certificate may refer to an x.509v3 certificate or a client certificate, and may be encoded in a DER format.
  • the DER (distinguished encoding rule) format is used for encryption to function to create a representation with a unique serial number for data that must be digitally signed, such as an X.509 certificate.
  • the use of the DER format makes it possible to sign and verify X.509 certificates.
  • a sub-certificate refers to a chain with all sub-certificates to the root certificate that do not contain the root certificate.
  • the list of root certificate identifiers includes certificate IDs of all V2G root CA certificates currently installed in EVCC. This root certificate can be used by EVCC to validate the SA certificate included in the CertificateInstallationRes message. In addition, the public key of the SA certificate included in the certificate installation response message may be used to verify the signature of the certificate installation response message.
  • Maximum Contract Certificate Chain represents the maximum number of contract certificate chains that an electric vehicle or EVCC of an electric vehicle intends to install at that time. It can be less than or equal to the maximum number of contract certificate chains the EV can store in memory. For example, if the EV can store 5 contract certificates and you want to install all 5, the maximum contract certificate chain parameter is set to 5. On the other hand, if the same EV wants to install only three contract certificates, the EVCC can set the maximum contract certificate chain parameter to 3, and can store up to five contract certificate chains.
  • the MaximumContractCertificateChains is the maximum contract certificate chain (MaximumContractCertificateChains) for that EV, even if the number of contract certificates held by the SA for that EV is greater than the number of contract certificates the SA can use. Limit the number of contract certificates in the SA's maximum contract certificate chain to provide only certificates to the EVCC. On the other hand, if the SA has 7 contract certificates and the EV sets the parameter of the maximum contract certificate chain to 3 and sends it in a certificate installation request message, the SA will have a preset priority based on the PrioritizedEMAIDs parameter. Depending on the ranking, only three contract certificates can be selected and provided to the SECC.
  • Prioritized account identifiers are elements that are optionally included in the message, and indicate a list of EMAIDs that refer to the contract certificate to be installed in the EV. At this time, EMAIDs are listed in order of highest priority to lowest priority.
  • the SA uses the parameter of the Priority Account Identifier element to filter the list of contract certificates to install if the MaximumContractCertificateChains is less than the number of contract certificates available in the SA, and the EV gets the highest priority contract certificate desired. can function as
  • the SA may send a contract certificate applicable to the corresponding EV selected by the SA according to the parameters of the maximum contract certificate chain.
  • Certificate Installation Response Type that the electric vehicle charging controller (EVCC) receives from the secondary actor (SA) is, as shown in FIG. 7 , a header (not shown), a response code ( Response Code), EVSE Processing, Certificate Provisioning Service Certificate Chain, Signed Installation Data, and Remaining Contract Certificate Chains elements can be included. there is.
  • the response code indicates the approval status of the V2G message received by the SECC.
  • the electric vehicle power supply processing state may optionally have parameter values indicating Finished or Ongoing.
  • the parameter value 'Finished' indicates that the EVSE has completed the processing started after sending the CertificateInstallationReq message.
  • the parameter value 'Ongoing' indicates that the EVSE is still processing the above-described processing at the time the response message is transmitted from the SA.
  • Certificate Provisioning Service Certificate Chain (CPS Certificate Chain) is used in EVCC to verify the signature of the message header received from the SA.
  • Remaining Contract Certificate Chains indicates whether to install additional contract certificate chains. If the value of this element is greater than 0, EVCC may install additional contract certificate chains.
  • Signed Installation Data includes all data types required for the above description.
  • the Signed Installation Data Type is, as shown in FIG. 8, a contract certificate chain, a trust platform module support encryption (Encrypted for TPM), an elliptic curve Diffie-Hellman curve (ECDHCurve) : elliptic-curve Diffie-Hellman Curve), Diffie-Hellman Public Key (DH Public Key), SECP521 Encrypted Private Key (SECP521_Encrypted Private Key), X448 Encrypted Private Key (X448_Encrypted Private Key) and TPM Encrypted Private Key (TPM_Encrypted) private key).
  • ECDHCurve elliptic curve Diffie-Hellman curve
  • DH Public Key Diffie-Hellman Public Key
  • SECP521 Encrypted Private Key SECP521_Encrypted Private Key
  • X448 Encrypted Private Key X448_Encrypted Private Key
  • TPM Encrypted Private Key
  • the contract certificate chain is used for authentication of services used by EVSE in relation to automatic electric vehicle user authentication, electric vehicle charging, and charge amount payment.
  • TPM Trusted Platform Module Support Encrypted
  • TPM Trusted Platform Module
  • the Elliptic-Curve Diffie-Hellman Curve (ECDHCurve) is an Elliptic Curve (ECC) cipher that the eMSP will use to generate the session key or seed used to encrypt the contract certificate private key.
  • Cryptography curve.
  • the ECC curve may include encryption algorithms such as Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). This parameter can be set to 'SECP521' or 'X448'.
  • the SA when the SA uses the first ECC curve specified in advance for generating the encryption key of the contract certificate private key through ECDHE, the SA sets the ECDHCurve parameter to 'SECP521'. In addition, when the SA uses the second ECC curve as specified in advance for generating the contract certificate private key encryption key through ECDHE, the SA sets the ECDHCurve parameter to 'X448'.
  • the Diffie-Hellman public key (DH Public Key) is used for encrypting the contract signing private key or contract certificate private key in the SA and decrypting it in the EVCC. ) is the public key.
  • a DH public key can be up to 133-bytes long, and the first byte can have a fixed value of 0x04 indicating an uncompressed format. If ECDHCurve is set to 'SECP521', the length of the DH public key may be 133-bytes, and if ECDHCurve is set to 'X448', the length of the DH public key may be 57-bytes.
  • the SECP521 Encrypted Private Key is a 521-bit private key belonging to the new contract certificate encrypted for EVCC without TPM.
  • X448_Encrypted Private Key is a 448-bit private key belonging to the new contract certificate encrypted for EVCC without TPM.
  • TPM Encrypted Private Key is the private key belonging to the new contract certificate encrypted for EVCC with TPM.
  • the SA may receive a request from the SECC to provide the signature installation data for a specific PCID, thereby encrypting the contract certificate private key and generating the signature installation data on-the-fly.
  • the eMSP already stores the OEM provisioned certificate public key, it may add some delay to responding to the certificate installation request (CertificateInstallationReq) especially when the data packet is ready. This delay may be selected at the discretion of the SA or eMSP of the system in question. However, in this embodiment, it is not required to change the ECDHE key for each of all signed installation data packets sent from the SA.
  • the SA or eMSP may also indicate on the certificate provisioning service the curve that the certificate provisioning service would like to use for the certificate provisioning service (CPS) certificate used to sign the signature installation data field. This allows the certificate provisioning service to use the certificate associated with the curve that the SA or eMSP wishes to use to sign that specific signature installation data. This can help the SA or eMSP's assurance that the contract certificate will not be rejected by the EVCC.
  • CPS certificate provisioning service
  • the SA or eMSP will request that the SignedInstallationData field be signed with a certificate based on the ECC curve, but the CPS may optionally comply with the SA or eMSP's request.
  • the CPS may have a certificate based on the ECC curve that can be used to sign the signature installation data (SignedInstallationData).
  • the CPS may not comply with the SA or eMSP's request. In this case, the CPS may respond to non-compliance with the request.
  • 9A and 9B are diagrams for explaining an encryption and decryption process of a SECP521-based encrypted private key that can be employed in the certificate installation method of FIG. 5 .
  • a 521-bit contract certificate private key corresponding to a contract certificate is encrypted by the sender, ie, SA or eMSP, using a session key derived from the ECDHE protocol.
  • the sender can apply the algorithm AES-GCM-256 for this encryption.
  • the contract certificate private key is extended to 528-bit by padding 7 leading 0 bits so that AES-GCM-256 can be applied. Explicit padding is necessary because 521-bit private keys are not byte aligned.
  • a leading zero may be included in the corresponding data element. If the length of the plaintext or private key is a multiple of the block size of the encryption algorithm used, no padding of the plaintext or private key is required.
  • the initialization vector (IV) for this encryption must be randomly generated before encryption and must have a minimum 96-bit length with sender-defined entropy.
  • Additional authenticatied data (AAD) for this encryption concatenates the PCID received/used in the Certificate Installation Req. message by an 18-byte size with uppercase letters and numbers without delimiters, and then contains uppercase letters and numbers. It can be calculated by concatenating the 16-byte SKI value of the contract certificate encoded as a decimal string and included in the certificate installation response message.
  • the byte order of all input data elements for AES-GCM-256 encryption may be big endian.
  • a 528-bit ciphertext includes a 7-bit Leading 0 and a 521-bit Contract Certificate Private Key ciphertext.
  • the initialization vector (IV) is transmitted as an encrypted private key using a specific ECC curve, that is, 12-bytes in the corresponding position in the most significant 12-bytes of the SECP521_EncryptedPrivateKey field.
  • a 66-byte ciphertext that is, an encrypted private key, is created/placed.
  • the tag is arranged to constitute the least significant 16-byte of the SECP521_EncryptedPrivateKey field.
  • SA is initialized vector (IV) and 528-bit length ciphertext (encrypted leading zero and private key) and a 128-bit long authentication tag ('tag' for short) concatenated to create a contract certificate data packet.
  • SA sends the contract certificate data packet to the CPS, and the CPS sends a second contract certificate data packet with its signature added to the contract certificate data packet (hereinafter referred to as the first contract certificate data packet) to the SECC or via the SECC It can be transmitted with EVCC.
  • the SECC may compile the second contract certificate data packet and transmit the first contract certificate data packet to the EVCC.
  • the receiver or EVCC upon receiving the corresponding message or SECP521_EnlcryptedPrivateKey in the message, uses a session key derived from the ECDHE protocol, and applies the AES-GCM-256 algorithm to decrypt the contract certificate private key. do.
  • the receiver calculates additional authentication data (AAD) before decryption to obtain a PCID and SKI.
  • AAD additional authentication data
  • the PCID and SKI may be placed between the ciphertext and the tag.
  • the receiver reads the initialization vector (IV) from at least the most significant 12-bytes of the SECP521_EncryptedPrivateKey field.
  • the receiver reads the ciphertext, that is, the encrypted private key, from the 66-bytes following the initialization vector (IV) of the SECP521_EncryptedPrivateKey field.
  • the receiver reads the authentication tag from the least significant 16 bytes of the SECP521_EncryptedPrivateKey field.
  • the order of the data is important.
  • the receiver verifies that the input data to the AES-GCM-256 decryption function/API conforms to a preset format or format.
  • the receiver or EVCC uses the 521-bit contract certificate private key as the least significant 521-bit after checking that the most significant 7-bit is zero (0) in the decrypted data.
  • EVCC verifies that the 521-bit private key received with the contract certificate is a valid 521-bit private key for that certificate.
  • the value of the 521-bit private key is strictly smaller than the reference point order of the secp521r1 curve, and multiplying this value by the reference point produces a key that matches the 521-bit public key of the contract certificate, EVCC or the recipient can It can be determined that the 521-bit private key received together with .
  • 10A and 10B are diagrams for explaining an encryption and decryption process of an X448-based encrypted private key that can be employed in the certificate installation method of FIG. 5 .
  • a 448-bit contract certificate private key corresponding to a contract certificate is encrypted by the sender, ie, SA or eMSP, using a session key derived from the ECDHE protocol.
  • the sender can apply the algorithm AES-GCM-256 for this encryption.
  • the initialization vector (IV) for this encryption is randomly generated before encryption and can have a minimum 96-bit length with sender-defined entropy.
  • the additional authenticated data (AAD) for this encryption can be calculated in the same way as the AAD of the 521-bit contract certificate private key.
  • the output of the above-described AES-GCM-256 encryption becomes a cipher text and an authentication tag (Tag).
  • the 448-bit ciphertext is an encrypted Contract Certificate Private Key.
  • the initialization vector (IV) is transmitted with the corresponding position and size in the most significant 12-byte of the encrypted private key using a specific ECC curve, that is, the X448_EncryptedPrivateKey field.
  • a specific ECC curve that is, the X448_EncryptedPrivateKey field.
  • a 56-byte ciphertext that is, an encrypted private key, is recorded.
  • the tag constitutes the least significant 16-byte of the X448_EncryptedPrivateKey field.
  • the receiver or EVCC when the receiver or EVCC receives the X448_EnlcryptedPrivateKey in the certificate installation response message or message, the receiver or EVCC uses a session key derived from the ECDHE protocol and applies the AES-GCM-256 algorithm to obtain a contract certificate Decrypt the private key.
  • the receiver calculates additional authentication data (AAD) before decryption to obtain a PCID and SKI.
  • AAD additional authentication data
  • the 128-bit PCID and SKI included in the ADD calculated by EVCC can be placed between the ciphertext and the tag.
  • the receiver reads the initialization vector (IV) from a byte of a preset size among most significant 12-bytes to 16-bytes of the X448_EncryptedPrivateKey field.
  • the receiver reads the ciphertext, that is, the encrypted private key, from the 66-bytes following the initialization vector (IV) of the X448_EncryptedPrivateKey field.
  • the receiver reads the authentication tag from the least significant 16 bytes of the X448_EncryptedPrivateKey field.
  • the receiver can check whether the input data to the AES-GCM-256 decryption function/API conforms to a preset format or format.
  • the receiver or EVCC uses the least significant 448-bits of the decrypted data as the 448-bit contract certificate private key.
  • EVCC verifies that the 448-bit private key received with the contract certificate is a valid 448-bit private key for that certificate.
  • the value of the 448-bit private key is strictly smaller than the order of the reference point of the X448 curve, and multiplying this value by the reference point produces a key that matches the 448-bit public key of the contract certificate, EVCC or the recipient of the contract certificate It can be determined that the 448-bit private key received together with .
  • the receiver or EVCC can check whether the authenticated decryption function used to decrypt the data can use a 128-bit authentication tag (also called 'tag' for short) as a second input. If decryption of the 521-bit private key or the 448-bit private key or both fails, the recipient MAY reject the CertificateInstallationRes message as invalid.
  • a 128-bit authentication tag also called 'tag' for short
  • 11 is a schematic block diagram of a certificate installation device based on encryption and decryption of a contract certificate private key for an electric vehicle communication controller (hereinafter, simply 'certificate installation device') according to another embodiment of the present invention.
  • 12 is a block diagram of an AES-GCM core that can be employed in the certificate installation device of FIG. 11 .
  • the certificate installation device may be implemented by the electric vehicle communication controller (EVCC) itself, a processor in the EVCC, and at least one core 110c in the processor.
  • EVCC electric vehicle communication controller
  • the certificate installation device corresponding to the electric vehicle communication controller 100 includes at least one processor (Processor, 110) and a memory (Memory, 120), and programs or instructions for implementing the certificate installation method are stored in the memory 120.
  • Programs or instructions may be read from the memory 120 according to the operation of the processor 110 and loaded in the processor 110 .
  • the certificate installation device may further include a communication interface (comm. I/F, 130).
  • the processor 110 may execute a program command stored in the memory 120 or a separate storage device.
  • the processor 110 may be implemented by at least one central processing unit (CPU), a graphics processing unit (GPU), a vehicle controller, or a charging controller, and other certificate installation according to the present invention It may be implemented by any other processor capable of performing the method.
  • An input interface, an output interface, or an input/output interface such as a keyboard, a mouse, a display device, a touch screen, and a voice input device may be connected to the processor 110 .
  • the memory 120 may include, for example, a volatile memory such as a read only memory (ROM) and a nonvolatile memory such as a random access memory (RAM).
  • the memory 120 may load a program command stored in the storage device and provide it to the processor 110 .
  • the memory 120 or a separate storage device is a recording medium suitable for storing program commands and data, and includes a magnetic medium such as a hard disk, a floppy disk, and a magnetic tape, and a compact disk read only memory (CD-ROM). ), an optical recording medium such as a DVD (Digital Video Disk), a magneto-optical medium such as a floppy disk, a flash memory or EPROM (Erasable Programmable ROM), or based on them It may include a semiconductor memory such as a solid state drive (SSD) manufactured with
  • the above-described memory 120 or storage device is a control block that can be mounted on a processor, an AES crypto-block, which is a kind of algorithm for encrypting actual data, and an encryption packet in block units. It is possible to store program commands for control, operation, and function for a GCM block, which is a type of method for preventing data extraction.
  • the program command stored in the memory 120 or the storage device may include a program command for encryption and/or decryption of the contract certificate private key that can be employed in the certificate installation method according to the present embodiment.
  • the program command is a command to send a certificate installation request message to the secondary actor, a command to receive a certificate installation response message from the secondary actor, a command to check AAD in the received message, a command to obtain an IV from the received message , a command to obtain a 521-bit or 448-bit contract certificate private key from the ciphertext of the received message, a command to verify that the obtained contract certificate private key is valid for the contract certificate received through the message, and enter an authentication tag a second time It may include a command to check whether it can be used as a command, and a command to reject a certificate installation response message as invalid if decryption of both the 521-bit private key and the 448-bit private key fails.
  • the communication interface 130 connects the EVCC with the SECC using a power line communication method, or connects the EVCC with a secondary actor such as CPS, eMSP, or MO through communication networks such as a local area wired/wireless network, mobile communication network, vehicle network, and satellite communication network. It may include at least one or more communication subsystems for
  • the certificate installation device is implemented by the processor 110 in the EVCC or at least one or more cores 110c in the processor 110, as shown in FIG. 12, the certificate installation device is mounted on the coder 110c. It may include a control block (control block, 111), an AES crypto-block (AES crypto-block, 112), and a GCM block (GCM block, 113).
  • control block control block, 111
  • AES crypto-block AES crypto-block
  • GCM block GCM block, 113
  • the certificate installation device includes a first input terminal 115 for inputting a key value to the AES cipher block 112, and a plaintext/ciphertext, an initialization vector and additional authentication data (AAD) to the GCM block 113.
  • a second input terminal 116, a first output terminal 117 for outputting ciphertext/plaintext from the GCM block 113, and a second output terminal 118 for outputting a tag from the GCM block 113 can do.
  • the control block 111 may control the overall operation of the AES cipher block 112 and the GCM block 113 .
  • the AES cipher block 112 includes a round block, a key scheduler and a sub control block, and the data path may be 128-bit.
  • encryption/decryption is performed in a specific operating mode using a 251-bit or 256-bit secret key.
  • the AES cipher block 112 may require more than 15 clock cycles due to the size of the 251-bit or 256-bit secret key, but the confidentiality of security can be improved by that much.
  • the GCM block 113 includes three 256-bit registers, two 32-bit registers, a finite field or galois field multiplier 114 and an adder.
  • a finite field multiplier operation is performed, and in the case of plaintext/ciphertext, an initialization vector (IV) is counted and transmitted to the AES block. Then, when the ciphertext/plaintext is input from the AES block 112 , a finite-body multiplier operation may be performed.
  • FIG. 13 is a schematic block diagram of an apparatus for installing a certificate according to another embodiment of the present invention.
  • the certificate installation device may be implemented by a secondary actor, in particular, a mobility service provider (eMSP, 300), a charging service provider (MO), a device executing a certificate provisioning service (CPS), or a combination thereof.
  • eMSP mobility service provider
  • MO charging service provider
  • CPS certificate provisioning service
  • the certificate installation device corresponding to the mobility service provider 300 includes at least one processor (Processor, 310), a memory (Memory, 320) and a communication interface (comm. I/F, 330), and the memory 320 is It can store programs or commands that implement the certificate installation method. Programs or instructions may be read from the memory 320 according to the operation of the processor 310 and loaded in the processor 310 .
  • the components of the certificate installation device of the present embodiment may be substantially the same as corresponding components of the certificate installation device described above with reference to FIGS. 11 and 12 except that the installation location or the operating subject is different.
  • the program command stored in the memory 320 or a separate storage device may include a program command for encryption and/or decryption of the contract certificate private key that can be employed in the device for installing the certificate according to the present embodiment.
  • the program command is a command to receive a certificate installation request message from EVCC, a command to send a certificate installation response message to the secondary actor, and a command to generate a data packet in which the contract certificate private key is encrypted together with the contract certificate associated with the EVCC , a command for determining the size of a ciphertext that fits a 521-bit key when generating a data packet, and the like.
  • the apparatus and method according to the present embodiment 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 may be distributed in a network-connected computer system to store and execute computer-readable programs or codes 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.
  • a block or device may correspond to a method step or characteristic of a method step.
  • 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 is operable with a microprocessor to perform one of the methods described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Charge And Discharge Circuits For Batteries Or The Like (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)

Abstract

전기차 통신제어기를 위한 계약 인증서 개인키의 암호화 및 복호화를 기반으로 하는 인증서 설치 방법 및 장치가 개시된다. 인증서 설치 방법은, 전기차 통신제어기가 제조사 프로비저닝 인증서와 연관된 개인키로 서명한 인증서 설치 요청 메시지를 세컨더리 액터로 전송하는 단계와, 세컨더리 액터로부터 인증서 프로비저닝 서비스의 리프 인증서와 연관된 개인키로 서명된 인증서 설치 응답 메시지를 수신하는 단계를 포함하며, 인증서 설치 응답 메시지의 암호화된 개인키 엘리먼트는 신뢰 플랫폼 모듈이 없는 전기차 통신제어기를 위해 암호화된 새 계약 인증서에 속하는 개인키를 저장하고, 새 계약 인증서에 속하는 개인키는, 제조사 프로비저닝 인증서의 공개 키로부터 입력되고 ECDH 프로토콜을 통해 생성되는 암호화 키를 기반으로 AES-GCM-256으로 암호화되며, AES-GCM-256으로 암호화된 개인키는 계약 인증서 데이터 패킷의 서두 초기화 벡터 다음의 528-비트 또는 448-비트에 암호문에 포함된다.

Description

계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치
본 발명은 차량의 인증서 설치 기술에 관한 것으로, 보다 상세하게는 전기차 통신제어기를 위한 계약 인증서 개인 키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치에 관한 것이다.
전기차(EV: Electric Vehicle)는 표준이나 규정에 정의된 XML 서명 방식을 사용하여 자신을 인증하고 전송 계층 보안(TLS: transport layer security) 프로토콜을 통해 외부로 정보를 전달한다. 정보 전달은 전기차의 통신제어기(EVCC: EV communication controller)와 전기차 전원공급장치(EVSE: EV supply equipment)의 통신제어기(SECC: supply equipment communication controller)와 세컨더리 액터(SA: secondary actor) 간에 이루어진다.
일례로, SA, SECC 및 EVCC 간에 XML 형태의 메시지를 주고받을 때, 송신자는 서명할 메시지 내용에 레퍼런스 아이디를 적는다. 레퍼런스 아이디는 어떤 내용이 서명되는지를 표시한다. 그리고 송신자는 서명을 위해 서명할 내용의 EXI(efficient XML interchange) 값을 SHA256으로 계산하고, Base64 등으로 인코딩한 다이제스트(Digest) 값을 레퍼런스의 다이제스트값(DigestValue) 필드에 넣는다. 그런 다음 송신자는 특정 클래스(SignedInfo)를 사용하여 XML 메시지나 XML 메시지 일부에 디지털 서명하고 그 값을 서명값(SignatureValue) 필드에 넣는다. 수신자는 송신자로부터 수신한 XML 메시지에서 다이제스트값(DigestValue) 필드의 값을 사용하여 메시지 데이터의 변조 여부를 확인한 후, 서명값(SignatureValue) 필드의 값을 검증한다.
한편, 충전서비스 사업자(MO: mobility operator)나 모빌리티 서비스 제공자(eMSP: electro-mobility service provider)는 전기차에 설치할 계약 인증서(contract certificate)와 이에 대응되는 비밀키를 암호화하여 전기차에 전달해야 한다. 이를 위해 관련 표준이나 규정에서는 타원곡선 암호를 이용한 ECDHE(elliptic curve Diffie-Hellman ephemeral) 키 교환 알고리즘을 사용하도록 권고한다.
예컨대, MO나 eMSP는 계약 인증서와 한 쌍의 비밀키를 암호화하기 위해 128비트 초기화 벡터(IV: initialization vector)를 서두에 가진 AES(advanced encryption standard)-CBC(cipher block chaining)-128를 이용한다. 계약 인증서에 대응하는 개인키는 타원곡선 디피-헬먼(ECDH: elliptic curve Diffie-Hellman) 프로토콜로 유도된 세션 키를 이용하여 암호화된다. 초기화 벡터(IV)는 암호화 전에 임의로 생성될 수 있고, 128-비트 길이를 가질 수 있으나, 결코 재사용될 수 없다. 또한, 초기화 벡터는 인증서 설치를 위한 소정 메시지의 특정 필드(예컨대 ContractCertificateEncryptedPrivateKey)의 최상위 16-바이트에 포함되어 전송된다.
암호화된 개인키를 포함하는 계약 인증서 데이터 패킷은 MO나 eMSP에서 인증서 프로비저닝 서비스(CPS: certificate provisioning service)로 전달된다. CPS의 역할은 예를 들어 MO 또는 eMSP 자체, EVSE 사업자, 또는 완전 독립형 서비스(stand-alone service) 제공자가 맡을 수 있다. CPS는 MO/eMSP로부터 수신한 메시지를 표준이나 규정에 정의된 포맷이나 전기차에서 수신가능한 전송 포맷으로 변환하면서 자신의 서명을 넣은 후 SECC를 통해 전기차에 전달한다. CPS의 서명은 전기차의 EVCC에 전달되는 데이터가 진본임을 보증한다.
전술한 계약 인증서 데이터 패킷은 MO에서 CPS로 전송되고, CPS의 서명과 함께 CPS에서 SECC를 통해 EVCC로 전송된다. 여기서 계약 인증서 데이터 패킷은 128-비트 길이의 초기화 벡터(IV), 256-비트의 암호화된 개인키, 특별히 규정되지 않은 최하위 128-비트 길이의 필드를 가진 데이터 포맷을 가진다.
한편, 전기차 보급이 빠르게 진행되면서 전기차를 위한 충전 인프라도 빠르게 확대되고 있고, 이와 함께 전기차 사용자에게 보다 편리하고 안전한 충전 환경을 제공하기 위한 다양한 연구도 진행되고 있다. 아울러 디지털 통신 기술의 발전에 따라 전기차를 위한 다양한 부가 서비스 예컨대, 전기차 원격 진단, 전기차 펌웨어 업데이트, 전기차 인증서 업데이트 등에 대한 전기차 지원 기술도 함께 연구되고 있다.
그러나, 전기차 사용자에게 편리한 기능을 제공하기 위한 통신 기술은 동시에 보안적인 위협요소를 증가시킨다. 특히, EVCC, SECC 및 SA는 전력선 통신, 근거리 무선 통신, 셀룰러 통신, 인터넷 등의 네트워크를 통해 서로 연결될 때, 신뢰 인증기관을 실시간 검증하기 어렵거나, 비밀키의 해킹 등과 같이 비인가 사용자의 접근에 노출되어 있어 보안에 취약할 수 있다. 이와 관련하여 현재 전기차와 관련된 통신에서는 TLS(Transport layer security)를 활용한 보안 통신과, 공개키 인증서와 개인키를 이용한 전자 서명 기법을 사용하여 송수신 메시지 보안을 처리하고 있으나, 아직까지 전기차 통신에 대한 보안이 미흡한 실정이다.
이와 같이 전기차와 관련한 통신에서 신뢰 플랫폼 모듈(TPM: trusted platform module)을 구비하지 않은 EVCC로 계약 인증서 설치 등을 위한 메시지를 안전하게 전송할 수 있고 메시지 보안의 신뢰성을 높일 수 있는 방안이 요구되고 있다.
본 발명은 전술한 종래 기술의 요구에 부응하기 위한 것으로, 본 발명의 목적은 V2G(vehicle to grid) 환경에서 충전서비스 사업자(MO: mobility operator)나 모빌리티 서비스 제공자(eMSP: electro-mobility service provider)가 EVCC를 위한 계약 인증서 개인키를 기밀성(confidentiality)을 높게 암호화할 수 있는, EVCC를 위한 계약 인증서 개인키의 암호화 및 복호화 기반의 인증서 설치 방법 및 장치를 제공하는데 있다.
본 발명의 또 다른 목적은 V2G(vehicle to grid) 환경에서 EVCC가 충전서비스 사업자(MO: mobility operator)나 모빌리티 서비스 제공자(eMSP: electro-mobility service provider)로부터 받은 기밀성을 높게 암호화된 개인키를 계약 인증서 개인키로 복호화할 수 있는, EVCC를 위한 계약 인증서 개인키의 암호화 및 복호화 기반의 인증서 설치 방법 및 장치를 제공하는데 있다.
상기 기술적 과제를 해결하기 위한 본 발명의 일 측면에 따른 인증서 설치 방법에 채용할 수 있는 공개키 암호화 방법은, 전기차 통신제어기를 위한 계약 인증서 개인키의 암호화 및 복호화에 의한 인증서 설치 방법에 있어서, 전기차 통신제어기가 제조사 프로비저닝 인증서와 연관된 개인키로 서명한 인증서 설치 요청 메시지를 세컨더리 액터로 전송하는 단계; 및 상기 세컨더리 액터로부터 인증서 프로비저닝 서비스의 리프 인증서와 연관된 개인키로 서명된 인증서 설치 응답 메시지를 수신하는 단계;를 포함한다. 여기서, 상기 인증서 설치 응답 메시지는 서명 설치 데이터 엘리먼트를 포함한 계약 인증서 데이터 패킷을 포함하고, 상기 서명 설치 데이터 엘리먼트는 계약 인증서 체인 엘리먼트와 암호화된 개인키 엘리먼트를 포함하고, 상기 암호화된 개인키 엘리먼트는 신뢰 플랫폼 모듈이 없는 전기차 통신제어기를 위해 암호화된 새 계약 인증서에 속하는 개인키를 저장한다.
또한, 상기 새 계약 인증서에 속하는 개인키는, 상기 제조사 프로비저닝 인증서의 공개 키로부터 입력되고 ECDH 프로토콜을 통해 생성되는 암호화 키를 기반으로 AES(advanced encryption standard)-GCM(galois/counter mode)으로 암호화되며, 상기 AES-GCM으로 암호화된 개인키는, 상기 계약 인증서 데이터 패킷의 서두 96-비트 내지 128-비트 초기화 벡터 다음의 528-비트 또는 448-비트에 암호문 또는 암호화된 개인키 필드로서 포함된다.
상기 기술적 과제를 해결하기 위한 본 발명의 다른 측면에 따른 인증서 설치 장치에 채용할 수 있는 공개키 암호화 장치는, 계약 인증서 개인키의 암호화 및 복호화에 의해 전기차에 인증서를 설치하는 장치에 있어서, 프로세서; 상기 프로세서에 의해 실행되는 명령어들을 저장하는 메모리; 및 상기 프로세서에 연결되고 네트워크를 통해 외부 장치와 통신하는 통신 인터페이스를 포함한다. 그리고 상기 프로세서가 실행될 때, 상기 명령어들은 상기 프로세서가: 제조사 프로비저닝 인증서와 연관된 개인키로 서명한 인증서 설치 요청 메시지를 세컨더리 액터로 전송하는 단계; 및 상기 세컨더리 액터로부터 인증서 프로비저닝 서비스의 리프 인증서와 연관된 개인키로 서명된 인증서 설치 응답 메시지를 수신하는 단계를 수행하도록 한다.
여기서, 상기 인증서 설치 응답 메시지는 서명 설치 데이터 엘리먼트를 포함한 계약 인증서 데이터 패킷을 포함하고, 상기 서명 설치 데이터 엘리먼트는 계약 인증서 체인 엘리먼트와 암호화된 개인키 엘리먼트를 포함하고, 상기 암호화된 개인키 엘리먼트는 신뢰 플랫폼 모듈이 없는 전기차 통신제어기를 위해 암호화된 새 계약 인증서에 속하는 개인키를 저장한다.
또한, 상기 새 계약 인증서에 속하는 개인키는, 상기 제조사 프로비저닝 인증서의 공개 키로부터 입력되고 ECDH 프로토콜을 통해 생성되는 암호화 키를 기반으로 AES(advanced encryption standard)-GCM(galois/counter mode)으로 암호화되며, 상기 AES-GCM으로 암호화된 개인키는, 서두 96-비트 내지 128-비트 초기화 벡터의 다음에 528-비트 또는 448-비트의 암호문으로 상기 계약 인증서 데이터 패킷의 암호화된 개인키 필드에 포함된다.
상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 측면에 따른 인증서 설치 장치에 채용할 수 있는 공개키 암호화 장치는, 계약 인증서 개인키의 암호화 및 복호화에 의해 전기차에 인증서를 설치하는 장치에 있어서, 프로세서; 상기 프로세서에 의해 실행되는 명령어들을 저장하는 메모리; 및 상기 프로세서에 연결되고 네트워크를 통해 외부 장치와 통신하는 통신 인터페이스를 포함한다. 상기 프로세서가 실행될 때, 상기 명령어들은 상기 프로세서가: 전기차 통신제어기로부터 제조사 프로비저닝 인증서와 연관된 개인키로 서명한 인증서 설치 요청 메시지를 수신하는 단계; 및 상기 전기차 통신제어기로 인증서 프로비저닝 서비스의 리프 인증서와 연관된 개인키로 서명된 인증서 설치 응답 메시지를 전송하는 단계를 수행하도록 하며, 상기 인증서 설치 응답 메시지는 서명 설치 데이터 엘리먼트를 포함한 계약 인증서 데이터 패킷을 포함하고, 상기 서명 설치 데이터 엘리먼트는 계약 인증서 체인 엘리먼트와 암호화된 개인키 엘리먼트를 포함하고, 상기 암호화된 개인키 엘리먼트는 신뢰 플랫폼 모듈이 없는 전기차 통신제어기를 위해 암호화된 새 계약 인증서에 속하는 개인키를 저장한다.
그리고, 상기 새 계약 인증서에 속하는 개인키는, 상기 제조사 프로비저닝 인증서의 공개 키로부터 입력되고 ECDH 프로토콜을 통해 생성되는 암호화 키를 기반으로 AES(advanced encryption standard)-GCM(galois/counter mode)으로 암호화되며, 상기 AES-GCM으로 암호화된 개인키는, 서두 96-비트 내지 128-비트 초기화 벡터의 다음에 528-비트 또는 448-비트의 암호문으로 상기 계약 인증서 데이터 패킷에 포함된다.
본 발명에 의하면, AES(advanced encryption standard)에 사용되는 개인키가 128-비트로 그 의 비트수가 적기 때문에 난수생성기를 통해 개인키를 만들 때 기밀성이 떨어져 공격자에 의해 개인키가 상대적으로 쉽게 예측될 수 있는 문제를 개선할 수 있다.
즉, 본 발명에 의하면, V2G(vehicle to grid) 환경에서 충전서비스 사업자(MO: mobility operator)나 모빌리티 서비스 제공자(eMSP: electro-mobility service provider)가 EVCC로 전송하는 계약 인증서 개인키를 기밀성(confidentiality) 높게 암호화하거나 복호화하여 전기차 관련 통신 보안에 대한 신뢰성과 안정성을 높일 수 있다.
또한, 본 발명에 의하면, 세컨더리 액터(SA: secondary actor)가 전기차 통신제어기(EVCC: EV communication controller)로 계약 인증서 비밀 키를 기밀성 높게 전달함으로써, 인증서설치요청이나 인증서설치응답 메시지 외에 전기차 충전이나 자동인증 등과 관련된 메시지들 예컨대, 승인요청, 충전량확인요청, 충전파라미터발견응답 메시지들에서 기밀성(confidentiality)을 높여 전기차 관련 통신 보안에 요구되는 주요 요소들인 기밀성, 무결성(integrity), 가용성(availability) 및 인증성(authenticity)에 대한 전체적인 신뢰도를 높일 수 있는 장점이 있다.
도 1은 본 발명의 일실시예에 따른 전기차 통신제어기를 위한 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법(이하 간략히 '인증서 설치 방법')과 연관된 전기차(EV: Electric Vehicle) 유선 충전 구조를 설명하기 위한 개념도이다.
도 2는 본 발명의 일실시예에 따른 인증서 설치 방법과 연관된 전기차 무선 전력 전송 구조를 설명하기 위한 개념도이다.
도 3은 본 발명의 일실시예에 따른 인증서 설치 방법과 연관된 전기차 충전 기반구조에 대한 개략적인 블록도이다.
도 4는 본 발명의 일실시예에 따른 인증서 설치 방법과 연관된 공개키(PKI: public key infrastructure) 기반 인증서 계층 구조의 일례에 대한 예시도이다.
도 5는 본 발명의 일실시예에 따른 인증서 설치 방법을 설명하기 위한 개념도이다.
도 6 내지 도 8은 도 5의 인증서 설치 방법에 채용할 수 있는 인증서 설치 관련 메시지를 설명하기 위한 도면들이다.
도 9a 및 도 9b는 도 5의 인증서 설치 방법에 채용할 수 있는 SECP521 기반 암호화된 개인키의 암호화 및 복호화 과정을 설명하기 위한 도면들이다.
도 10a 및 도 10b는 도 5의 인증서 설치 방법에 채용할 수 있는 X448 기반 암호화된 개인키의 암호화 및 복호화 과정을 설명하기 위한 도면들이다.
도 11은 본 발명의 다른 실시예에 따른 전기차 통신제어기를 위한 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 장치(이하 간략히 '인증서 설치 장치')에 대한 개략적인 블록도이다.
도 12는 도 11의 인증서 설치 장치에 채용할 수 있는 AES-GCM 코어에 대한 블록도이다.
도 13은 본 발명의 다른 실시예에 따른 인증서 설치 장치에 대한 개략적인 블록도이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.
제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) 등으로 지칭되거나 구분될 수 있다.
'플러그인 전기차(PEV: Plug-in Electric Vehicle)'는 전력 그리드에 연결하여 차량 탑재 일차 배터리를 재충전하는 전기차를 지칭할 수 있다.
'무선 충전 시스템(WCS: Wireless power charging system)'은 그라운드 어셈블리(GA: Ground assembly)와 차량 어셈블리(VA: Vehicle assembly) 간의 무선전력전송과 얼라인먼트 및 통신을 위한 시스템을 지칭할 수 있다.
'무선 전력 전송(WPT: Wireless power transfer)'은 유틸리티(Utility), 그리드(Grid), 에너지 저장 장치, 연료전지 발전기 등의 전원공급원에서 전자기 유도, 공진 등의 무접촉 수단을 통해 전기차와 전력을 전달하거나 전달받는 것을 지칭할 수 있다.
'유틸리티(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: Certificate Authority)이나 최상위 인증서버를 포함할 수 있다.
'전력망 사업자(V2G operator)'는 전송 프로토콜을 이용하여 V2G 통신에 참여하는 1차 액터(primary actor)를 지칭하거나, 전기차 또는 전기차 사용자의 자동인증을 위한 블록체인 시작과 블록체인 상의 스마트 계약서 생성을 위한 엔티티를 지칭할 수 있고, 적어도 하나 이상의 신뢰된 인증기관이나 신뢰된 인증서버를 포함할 수 있다.
'충전서비스 사업자(MO: Mobility operator)'는 EV 운전자가 충전 스테이션에서 EV 배터리를 충전할 수 있도록 EV 소유자와 충전, 승인 및 결제에 관한 계약 관계를 맺고 있는 PnC 아키텍처 내 엔티티들 중 하나를 지칭할 수 있고, 자신의 인증서를 발급하고 관리하는 적어도 하나 이상의 인증기관이나 인증서버를 포함할 수 있다. 충전서비스 사업자는 모빌리티 운영자로 지칭될 수 있다.
'충전서비스 제공자(CSP: Charge service provider)'는 전기차 사용자의 크리덴셜을 관리하고 인증하며, 요금청구 및 기타 부가가치 서비스를 고객에게 제공하는 역할을 하는 엔티티를 지칭할 수 있으며, MO의 특별한 유형에 해당한다고 볼 수 있고 MO와 합체된 형태로 구현될 수 있다.
'충전 스테이션(CS: Charging station)'은 하나 이상의 EV 전원공급장치(supply equipment)를 구비하며 EV에 대한 충전을 실제로 실행하는 시설이나 장치를 지칭할 수 있다.
'충전 스테이션 사업자(CSO: Charging station operator)'는 전기차에서 요청하는 전력을 공급하기 위하여 전력망에 연결되어 전력을 관리하는 엔티티를 지칭할 수 있으며, 충전인프라 운영사업자(CPO: Charge point operator) 또는 모빌리티 서비스 제공자(eMSP: eMobility Service Provider)와 동일한 개념의 용어일 수 있고, 혹은 CPO 또는 eMSP에 포함되거나 CPO 또는 eMSP를 포함하는 개념의 용어일 수 있다. CSO, CPO 또는 eMSP는 자신의 인증서를 발급하거나 관리하는 적어도 하나 이상의 인증기관을 포함할 수 있다.
'모빌리티 계정 식별자(eMAID: e-Mobility Authentication Identifier)'는 계약 인증서를 전기를 사용하는 이동체(electroMobility)의 소유주의 결제 계정에 연결시키는 고유 식별자를 지칭할 수 있다. 본 실시예에서, 모빌리티 계정 식별자는 전기차 인증서의 식별자 또는 프로비저닝 인증서의 식별자를 포함할 수 있다. 이 용어 eMAID는 'e-Mobility Account Identifier'를 지칭하도록 대체되거나 계약 ID(contract ID)로 대체될 수 있다.
'클리어링 하우스(CH: Clearing house)'는 MO들, CSP들, 및 CSO들 사이의 협력 사항을 처리하는 엔티티로서, 특히 두 정산 사이 또는 두 정산 당사자 사이에서 EV 충전서비스 로밍에 대한 승인, 요금청구, 정산 절차를 원활하게 해주는 중간 관여자 역할을 할 수 있다.
'로밍(roaming)'은 전기차 사용자들이 하나의 크리덴셜과 계약을 사용하여, 다수의 모빌리티 네트웍에 속하는 다수의 CSP들 또는 CSO들에 의해 제공되는 충전서비스를 접근할 수 있게 해주는 정보 교환 및 관련 사항(provision)과 체계(scheme)를 지칭할 수 있다.
'크리덴셜(credential)'은 전기차 또는 전기차 사용자의 개인 정보를 나타내는 물리적 또는 디지털 자산으로서, 신원을 검증하기 위해 사용하는 암호학적 정보인 패스워드, 공개키 암호 알고리즘에서 사용하는 공개키/개인키 쌍, 인증기관이 발행하는 공개키 인증서, 신뢰하는 루트 인증기관 관련 정보 등을 포함할 수 있다.
'인증서(Certificate)'는 디지털 서명에 의해 공개키를 식별자(ID)와 바인딩하는 전자 문서를 지칭할 수 있다.
'서비스 세션'은 고유의 식별자를 가진 일정한 타임프레임에서의 어떤 고객에게 할당된, 충전 지점에서의 전기차 충전에 관한 서비스들의 집합을 지칭할 수 있다.
이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.
본 실시예에 따른 전기차 통신제어기를 위한 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법(이하 간략히 '인증서 설치 방법')은 유선 또는 무선 링크를 통해 충전 스테이션의 전력공급장치 통신제어기(SECC: supply equipment communication controller)에 연결되는 세컨더리 액터가 SECC에 연결되는 전기차(EV: electric vehicle)로 계약 인증서와 개인키를 전송하는 과정을 포함한다.
도 1은 본 발명의 일실시예에 따른 인증서 설치 방법과 연관된 전기차(EV: Electric Vehicle) 유선 충전 구조를 설명하기 위한 개념도이다.
도 1을 참조하면, 전기차 유선 충전은 전기차(10, 이하 'EV'라 칭함)를 충전 케이블(30)에 의해 충전 스테이션의 전력공급회로에 접속시킴으로써 수행될 수 있다.
EV(10)는 배터리와 같이 충전가능한 에너지저장장치에서 공급되는 전력을 동력장치인 전기 모터의 에너지원으로 공급하는 차량(automobile)으로 정의할 수 있다. EV(10)는 전기 모터와 일반적인 내연기관을 함께 갖는 하이브리드 자동차일 수 있고, 자동차(automobile)뿐만 아니라 모터사이클(motorcycle), 카트(cart), 스쿠터(scooter) 및 전기 자전거(electric bicycle)일 수도 있다.
EV(10)는 충전 케이블(30)의 차량 커넥터에 접속될 수 있는 차량 인렛을 구비할 수 있다. EV(10)에 구비되는 차량 인렛은 완속 충전을 지원하거나 급속 충전을 지원하거나 완속 충전과 급속 충전을 함께 지원할 수 있다.
또한, EV(10)는 완속 충전 또는 일반적인 전력 계통에서 공급되는 교류 전력을 통한 충전을 지원하기 위하여 온보드 충전기(On Board Charger)를 구비할 수 있다. 온보드 충전기는 완속 충전시 외부에서 유선으로 공급되는 교류 전력을 승압하고 직류 전력으로 변환하여 EV(10)에 내장된 배터리에 공급할 수 있다. 한편, 차량 인렛에 급속 충전을 위한 직류 전력이 공급되는 경우에는, 직류 전력은 온보드 충전기를 거치지 않고 배터리에 공급되어 충전될 수 있다.
한편, 충전 케이블(30)은 충전 커넥터(31) 및 플러그(33)를 구비하거나, 인케이블 컨트롤 박스(ICCB; In-cable control box)(32)를 더 구비하도록 구성될 수 있다.
충전 커넥터(31)는 EV(10)와 전기적으로 연결할 수 있는 접속부이고, 플러그(33)는 충전 스테이션의 충전 장치나 전력공급장치의 소켓-아울렛(40)에 접속될 수 있다. 소켓-아울렛(40)은 충전 스테이션의 충전 장치와 플러그(33) 또는 차량 인렛의 접속 지점을 의미하나, 본 발명은 이에 한정되지 아니하며, 소켓-아울렛(40)이 여타의 장소에 설치된 충전 장치와 플러그나 충전 케이블(30) 간의 접속 지점을 의미할 수도 있다. 예컨대, 소켓-아울렛(40)은 상업적인 전문 충전 스테이션 시설 이외에, EV(10) 소유자의 집에 부속된 차고나 주차장, 주유소에서 EV 충전을 위해 할당된 주차구역, 쇼핑 센터나 직장의 주차구역 등과 같은 충전 시설물에 설치된 월 잭(wall jack) 등을 나타낼 수 있다.
인케이블 컨트롤 박스(32)는 EV(10)와 통신하여 EV의 상태 정보를 수신하거나 EV(10)로의 전력 충전을 제어할 수 있다. 인케이블 컨트롤 박스(32)는 충전 케이블(30)에 일체로 결합된 형태로 설치될 수 있으나, 이에 한정되지 않고, 충전 스테이션에서 EV(10)에 전력을 공급하는 전력공급회로(미도시)에 접속되거나 전력공급회로 내에 배치될 수 있다.
인케이블 컨트롤 박스(32)는 후술하는 전원공급장치 통신제어기에 대응될 수 있다. 전기차(10)와 인케이블 컨트롤 박스(32)는 전력선 통신을 통해 서로 연결될 수 있고, 인케이블 컨트롤 박스와 세컨더리 액터는 유선 및 무선 통신망 중 적어도 어느 하나를 통해 서로 연결될 수 있다.
도 2는 본 발명의 일실시예에 따른 인증서 설치 방법과 연관된 전기차 무선 전력 전송 구조를 설명하기 위한 개념도이다.
도 2를 참조하면, 전기차에 대한 무선전력전송(WPT: wireless power transfer)은 공급 네트워크로부터의 전기 에너지를 갈바닉 연결을 통한 전류 흐름 없이 자기유도 혹은 자기공명 상태에서 자기장을 통해서 공급자측 디바이스로부터 소비자측 디바이스로 전달하는 것으로 정의될 수 있다. 무선전력전송은 충전 스테이션(charging station, GA1)에서 EV(10)로 전력을 전송하여 EV(10)의 배터리(150)를 충전하는데 이용될 수 있다.
EV(10)는 충전 스테이션(GA1)의 전송 패드(GAP1)으로부터 무선으로 전자기 에너지를 받아들이기 위한 수신 코일을 구비하는 수신 패드(130)를 포함할 수 있다. 수신 패드(130)에 있는 수신 코일은 충전 스테이션(GA1)에 있는 송신 패드(GAP1)의 송신 코일로부터 전자기유도나 자기공명에 의해 자기 에너지를 전달받는다. EV(10)에 수신된 자기 에너지는 유도전류로 변환되고, 유도전류는 직류전류로 정류된 후 배터리(150)를 충전시키는데 이용된다.
충전 스테이션(GA1)은 상용 전력망(power grid, G1)이나 전력 백본으로부터 전력을 받아들이고, 송신 패드(GAP1)를 통해 EV(10)에 에너지를 공급할 수 있다. 충전 스테이션(GA1)에 대응하는 전기차 전원공급장치(EVSE: EV supply equipment)는 EV(10) 소유자의 집에 부속된 차고나 주차장, 주유소에서 EV 충전을 위한 주차구역, 쇼핑센터나 업무용 건물의 주차구역 등과 같이 다양한 장소에 위치할 수 있다.
충전 스테이션(GA1)은 유무선 통신을 통하여 전력망(G1)을 관리하는 전력 기반구조 관리 시스템(power infrastructure management system)이나 인프라 서버와 통신할 수 있다. 또한, 충전 스테이션(GA1)은 EV(10)와도 무선 통신을 수행할 수 있다.
무선 통신은 IEEE 802.11 규약에 따른 와이파이(WiFi)를 기반으로 한 무선랜(WLAN) 기반 통신을 포함할 수 있으며, 또한 저주파(LF: Low frequency) 자기장 신호 및/또는 저출력 자기장(LPE: Low Power Excitation) 신호를 이용한 P2PS 통신을 포함할 수 있다. 충전 스테이션(GA1)과 EV(10) 간의 무선 통신은 블루투스(Bluetooth), 지그비(zigbee), 셀룰러(cellular) 등 다양한 통신방식 중 하나 이상을 포함할 수 있다.
또한, EV(10) 및 충전 스테이션(GA1)은 XML(extensible markup language)이나 EXI(efficient XML interchange) 기반 데이터 표현 포맷에 따라 메시지를 교환하여 충전 프로세스를 진행할 수 있다. 즉, 전기차 통신제어기(EVCC; Electric Vehicle Communication Controller)와 전력공급장치 통신제어기(SECC; Supply Equipment Communication Controller) 사이에 충전 프로세스를 위한 통신이 무선랜(WLAN) 등을 통해 이루어질 수 있다.
충전 프로세스를 위한 통신 과정에서 EV는 먼저 충전 스테이션이 신뢰할 수 있는 시설인지 확인하기 위해 충전 스테이션의 신원을 확인하고, 무단 액세스로부터 통신을 보호하기 위해 충전 스테이션과 보안 채널을 설정한다. 보안 채널은 TLS(Transport Layer Security)에 의해 달성될 수 있다. TLS 세션은 IP(Internet Protocol) 기반의 통신 연결 설정 절차 이후에 TLS 세션 설정 절차에 따라 수행될 수 있다.
한편, 본 실시예에 따른 인증서 설치 방법은 전기차 충전 기반구조와 이 기반구조의 주요 엔티티의 인증서에 기반으로 보안 채널을 설정한다. 이를 위해 본 실시에에 채용가능한 전기차 충전 기반구조와 공개키(PKI: public key infrastructure) 기반 인증서 계층 구조를 설명하면 다음과 같다.
도 3은 본 발명의 일실시예에 따른 인증서 설치 방법과 연관된 전기차 충전 기반구조에 대한 개략적인 블록도이다.
도 3을 참조하면, 전기차 충전 기반구조는 EV(10)에 충전 서비스를 제공하기 위한 것으로서, 충전 스테이션 운영자(CSO: Charging station operator)(210), 충전 스테이션(CS: Charging Station)(220), 모빌리티 운영자(MO: Mobility operator)(300), 인증서 프로비저닝 서비스(CPS: Certificate provisioning serveice)(390), 전기차 제조업체(Original Equipment Manufacturer) 서버(400), 충전 서비스 제공자(CSP: Charge service provider)(220), 비클-투-그라운드(V2G: Vehicle-to-ground) 서버(600), 계약 인증서 풀(CCP: Contract certificate pool)(700) 및 클리어링 하우스(CH: Clearing house)(800)를 포함한다.
EV(10)는 전기차 사용자가 소유한 일반적인 자동차를 지칭하며, 충전 스테이션에서 유선 또는 무선으로 충전이 가능하다. EV(100)에는 제조 과정에서 고유한 OEM 프로비저닝 인증서가 설치될 수 있다. 그리고, 차량 구매계약 등과 같이 MO(300) 운영자와의 계약이 완료되면, EV(10)에는 계약 인증서가 설치될 수 있다. 아울러, EV(10)에는 비클-투-그라운드(V2G) 서버(600)의 루트인증서가 설치될 수 있다.
전기차 제조업체(Original Equipment Manufacturer) 서버(이하 'OEM'으로 약칭함)(400)은 OEM 루트인증서를 발급하는 최상위 인증기관(CA)이며, 그 하위 인증기관(OEM SubCA 1, OEM SubCA 2)도 운영하고 유지한다. EV(10)가 제조될 때. OEM(400)은 OEM 중간체인인증서(OEM SubCA 2 cert.)를 사용하여 OEM 프로비저닝 인증서를 생성하고 EV(10)에 설치할 수 있다.
모빌리티 운영자(MO: Mobility operator)(300)는 전기차 사용자가 충전 스테이션(200)에서 EV(10)를 충전할 수 있도록 전기차 사용자와 충전, 승인 및 결제에 관한 계약 관계를 맺고 있는 서비스 제공자이다. EV(10)가 충전 스테이션(220)에서 충전 서비스를 받으려면, 충전 스테이션(220)이 MO(300)에 속하거나 로밍 시나리오를 지원해야 한다. MO(300)는 에너지를 판매하는 전기 공급자 또는 전기 도매업자에 의해 운영될 수 있다. MO(300)는 MO 루트인증서를 발급하는 최상위 인증기관(CA)으로도 작용한다. MO 루트인증서와 그 하위 CA들이 생성하는 MO 중간체인인증서들로 구성되는 MO 인증서 체인은 계약 인증서를 생성할 때 사용될 수 있다. 아울러, MO 인증서 체인은 EV(10)에 설치된 계약 인증서를 비-로밍 환경이나 로밍 환경에서 검증하는 데에도 사용될 수 있다. MO는 모빌리티 서비스 공급자(eMSP: e-mobility service provider)로 지칭될 수 있다.
인증서 프로비저닝 서비스(CPS: Certificate provisioning serveice)(390)는 EV(10)에 계약 인증서가 설치되거나 업데이트되는 과정에서 계약 인증서 체인과 함께, 인증서 송수신에 사용되는 암호화 키 등을 EV(10) 또는 이와 같은 클라이언트에 제공한다. CPS(390)에는 리프 프로비저닝 인증서(Leaf Prov cert.)와 프로비저닝 중간체인인증서들(Prov SubCA 1 cert., Prov SubCA 2 cert.)이 구비될 수 있다. EV(10)에 계약 인증서가 설치되거나 업데이트될 때, CPS(390)는 계약 인증서 체인과 함께 각 MO의 공개키, 디피-헬만(DH: Diffie Hellman) 공개키, 및 eMAID(e-Mobility authentication identifier)를 제공하는 프로비저닝 서비스를 공급함으로써, EV(10)가 이들을 사용하여 계약 인증서 체인을 검증하고 계약 인증서의 무결성과 신뢰성을 확인할 수 있게 해준다.
계약 인증서 풀(CCP: Contract certificate pool)(700)은 EV(10)에 계약 인증서가 설치되거나 업데이트되는 과정에서 인증서 설치 또는 업데이트에 대한 응답 메시지를 임시로 저장한다. 설치 및 업데이트 제한시간이 매우 짧고 엄격한 점을 감안하여, 응답 메시지는 미리 CCP(700)에 저장되고 인증서 설치 또는 업데이트가 완전히 완료될 때까지 유지될 수 있다. 계약 인증서 설치 또는 업데이트가 이루어지는 EV(10)가 여러 대일 수 있기 때문에 응답 메시지는 참조번호가 부여된 후 디렉토리 형태로 유지될 수 있다.
비클-투-그리드(V2G: Vehicle-to-grid) 서버(600, 이하 'V2G'로 약칭함)는 전기차 충전 기반구조에서 공개키 기반구조(PKI: Public key Infrastructure)와 관련하여 최상위 인증기관으로 작용할 수 있다. 따라서 V2G(600)은 최상위 신뢰 앵커 역할을 하게 되며, 도 3에 도시된 모든 관여자들(actors)은 V2G 루트CA를 신뢰할 수 있는 조직으로 간주할 수 있다.
충전 스테이션(CS: Charging station)(220)은 EV(10)에 대한 충전을 실제로 실행한다. 충전 스테이션(220)은 적어도 하나의 유선 충전기 및/또는 무선 충전 스팟을 구비할 수 있다. 충전 스테이션(220)은 상업적인 전문 충전 시설에 하나 이상 설치될 수 있다. 또한 충전 스테이션(220)은 전기차 사용자의 주택에 부속된 차고나 주차장, 주유소에서 전기차 충전을 위한 주차구역, 쇼핑센터나 직장의 주차구역 등과 같이 다양한 장소에 위치할 수 있다. 충전 스테이션(220)은 '충전 포인트', '전기차 충전소', '전기차 충전 포인트', '충전 포인트', '전기차 충전 스테이션(ECS)', 또는 '전기차 전력공급장치(EVSE)'로 지칭될 수 있다.
충전 스테이션 운영자(CSO: Charging station operator)(210) 혹은 충전 포인트 운영자(CPO: Charge point operator)는 충전 스테이션의 운영과, 요청된 에너지 전송 서비스를 제공하기 위하여 전기를 관리한다. CSO(210)는 예컨대 충전 스테이션 제조사, 전기차 전력공급장치 제조사, 또는 전기 공급자에 의해 운영될 수 있다. 공개키 기반구조(PKI)와 관련하여, CSO(210)는 각 충전 스테이션(220)에 대한 전력공급장치 통신제어기(SECC) 리프 인증서를 생성하는 데 필요한 하위 인증기관들(CPO SubCA 1, CPO SubCA 2)을 운영할 수 있다.
충전 서비스 제공자(CSP: Charge service provider)(500)는 전기차 사용자의 크리덴셜을 관리하고 인증하며, 요금청구 및 기타 부가가치 서비스를 고객에게 제공한다. CSP(500)는 MO(300)의 특별한 유형에 해당한다고 볼 수 있고, MO(300)와 합체된 형태로 구현될 수 있다. CSP(500)는 복수 개 존재할 수 있고, 각 CSP(500)는 하나 이상의 CSO(210)에 연계되며, CSP(500)와 하나 이상의 CSO(210)는 하나의 충전 네트웍을 구성할 수 있다.
즉, EV(10)는, 계약 인증서가 설치되어 있는 경우, 계약 관계에 있는 MO(300)와 연관되어 있는 CSP(500)에 연계된 CSO(210)에서 PnC(Plug and charge/ Park and charge) 방식으로 충전 서비스를 받을 수 있지만, 계약 관계에 있지 않는 MO와 연관되어 있는 다른 CSO에서 충전을 하고자 하는 경우에는 로밍이 필요하다. 각 CSP(500)는 로밍을 위하여 다른 CSP 또는 다른 네트웍에 있는 CSO와 정보 교환을 할 수 있고, 또한 클리어링 하우스(800)와도 정보를 교환할 수 있다.
클리어링 하우스(CH: Clearing house)(800)는 복수의 MO(300)와 복수의 CSP(500) 사이의 협력 사항을 처리한다. 클리어링 하우스(CH, 800)는 두 정산이나 결제 당사자 사이에서 EV 충전 서비스 로밍에 대한 승인, 요금청구, 정산 절차를 원활하게 해주는 중간 관여자 역할을 수행할 수 있다.
즉, 전기자 사용자가 자신이 계약관계를 맺고 있는 MO(300)의 네트웍에 속하지 않는 충전 스테이션에서 EV를 충전하고자 하는 경우, CH(800)는 CSO(210) 또는 CSP(500)에 의해 연결되어 로밍이 이루어지도록 지원할 수 있다. 로밍이 필요한 상황에서. CH(800)는 CSO(210) 또는 CSP(500)가 MO(300)와 계약을 맺고 승인 및 청구 데이터를 MO(300)로 전달할 수 있게 해준다. 이러한 CH(800)는 '계약 클리어링 하우스(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의 역할을 겸할 수 있다. 한편 상기 컴포넌트들 중 하나 이상은 다른 외형 및 명칭을 가질 수 있도록 재편성될 수도 있다.
한편, 전기차 충전 서비스 및 관련 기반구조는 자동차, 전력 그리드, 에너지, 수송, 통신, 금융, 전자제품 등 다양한 산업분야가 접목되는 분야이고, 다양한 관점에서 표준화 작업이 병행되어왔을 뿐만 아니라, 복수의 국제표준화기구에서의 표준화와 별도로 개별국 단위의 표준화도 진행되어왔기 때문에, 유사한 개념의 용어가 많다. 특히, 충전 서비스 운영자(CSO: charging station operator)는 충전 포인트 운영자(CPO: charge point operator)와 역할과 기능 측면에서 공통점이 있으며, 일부 기능상의 차이점과 뉘앙스 차이가 있을 수 있지만 실질적으로 동일한 엔티티를 지칭하는 용어일 수 있다. 또한, 충전 서비스 운영자(CSP: charging service provider)는 모빌리티 운영자(MO: mobility operator)와 역할과 기능 측면에서 적어도 부분적으로 공통점이 있으며, 혼용되거나 뒤바뀌어 사용될 수 있는 용어들일 수 있다. 청구범위를 포함하여 본 명세서를 해석함에 있어서는 이와 같은 현실의 사정을 감안하여야 한다.
도 3에 도시된 전기차 충전 기반구조에서는, PnC 절차나, 엔티티 상호 간의 메시지 송수신 등의 보안 통신을 위해 공개키 기반구조(PKI)가 사용된다. PKI는 사람과 장치의 신원 확인, 기밀 통신 활성화, 리소스에 대한 제어된 액세스 보장을 위한 프레임워크를 제공한다.
도 4는 본 발명의 일실시예에 따른 인증서 설치 방법과 연관된 공개키(PKI: public key infrastructure) 기반 인증서 계층 구조의 일례에 대한 예시도이다.
도 4를 참조하면, 전기차 제조사(EV Manufacturer)(이하 간략히 'OEM')는 OEM 루트인증서(OEM RootCA cert.)를 발급하는 최상위(root) 인증기관(CA: Certificate authority)으로 작용하며, 그 하위 인증기관(OEM SubCA 1, OEM SubCA 2)도 운영한다. 따라서, OEM은 OEM 루트인증서(OEM RootCA cert.)와 아울러, 자신의 개인키로 서명하여 OEM 중간체인인증서(OEM SubCA 1 cert. cert., OEM SubCA 2 cert.)를 생성한다.
EV가 제조될 때, OEM의 2차 중간CA(OEM SubCA 2)는 OEM 2차 중간체인인증서(OEM SubCA 2 cert.)에 포함된 공개키와 쌍을 이루는 개인키를 사용하여 OEM 프로비저닝 인증서(OEM Prov cert.)를 생성하고 이를 EV에 설치한다. 이 OEM 프로비저닝 인증서(OEM Prov cert.)는 EV에 대한 인증서 설치 요청 과정에서 요청 메시지의 서명을 확인하는데 사용될 수 있으며, EV의 수명동안 차량을 고유하게 식별하게 해준다.
MO(Mobility operator)는 MO 루트인증서(MO RootCA cert.)를 발급하는 최상위 인증기관(CA)으로도 작용한다. MO는 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와 전기차 사용자 간에 체결되는 계약을 토대로, MO의 2차 중간CA(MO SubCA 2)는 MO 2차 중간체인인증서(MO SubCA 2 cert.)에 포함된 공개키와 쌍을 이루는 개인키를 사용하여 계약 인증서(Contract Certificate)를 생성하고 이를 예컨대 EV가 최초에 방문하는 충전 스테이션의 전기차 전력공급장치(EVSE: EV supply equipment)의 전력공급장치 통신제어기(SECC)를 통해 EV에 설치할 수 있다. 계약 인증서는 모빌리티 계정 식별자(eMAID: e-Mobility Account Identifier)라는 고유 식별자를 통해 EV 사용자의 결제 계정에 연결될 수 있다.
OEM 프로비저닝 인증서(OEM Prov cert.)와 계약 인증서(Contract Certificate)는 OEM과 MO가 자체적으로 생성한 루트 인증서들(OEM RootCA cert., MO RootCA cert.)을 토대로 하여 각각 생성되며, 또한 전역 루트인증서(V2G RootCA cert.)를 토대로 생성될 수 있으며, 다른 관여자들(actors)이 사용하는 인증서들과 독립적이다. 다만, 도 3에서 쇄선으로 표시된 바와 같이, OEM과 MO의 루트 인증서들(OEM RootCA cert., MO RootCA cert.) 대신에 V2G 루트인증서(V2G RootCA cert.)를 사용하여, OEM 프로비저닝 인증서(OEM Prov cert.)와 계약 인증서(Contract Certificate)를 생성할 수도 있다.
V2G 서버(이하 간략히 'V2G')는 적어도 두 계열의 인증서들 즉, CSO(위에서 언급한 바와 같이 'CPO'에 대응함) 및 충전 스테이션의 SECC를 위한 인증서 계열과, 프로비저닝 서비스를 위한 인증서 계열을 생성할 수 있게 지원한다.
좀더 구체적으로, V2G는 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)를 생성하고 이를 EVSE의 SECC에 전송하여 설치되게 할 수 있다. 이 SECC 리프 인증서(SECC Leaf Certificate)는 EV가 가짜 충전 스테이션이 아니라 실제 충전 스테이션과 통신하는지 확인하기 위해 TLS 통신 설정 중에 EV에 의해 사용될 수 있다. 이 인증서는 SECC 뿐만 아니라 CSO의 백엔드 서버에도 저장될 수 있다.
또한, V2G는 프로비저닝 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)에 전송하여 설치되게 기능할 수 있다.
한편, 각 루트CA(V2G RootCA, MO RootCA, OEM RootCA)와 각 하위 CA들은 OCSP 인증서를 발급하여 전기차 등의 클라이언트들에게 제공할 수 있다. 즉, 전기차 등의 클라이언트들은 온라인 인증서 상태 프로토콜(OCSP: Online Certificate Status Protocol)에 따라 OCSP 서버에 접속하여 인증서의 유효성에 관한 해지/미해지 상태 정보를 요청하고 조회결과를 수신할 수 있다.
도 4에서는 표시를 단순화하기 위해 특정 서명자에 의한 OCSP 인증서(OCSP signer certificate)가 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는 본 발명의 일실시예에 따른 인증서 설치 방법을 설명하기 위한 개념도이다.
도 5를 참조하면, 본 실시예의 인증서 설치 방법은 신뢰 플랫폼 모듈(TPM: trusted platform module) 2.0이 포함되지 않은 전기차 통신제어기(EVCC: EV communication controller)에 계약 인증서(CC: contract certificate)를 설치하기 위해 모빌리티 서비스 제공자(eMSP: e-Mobility service provider)(300)와 같은 세컨더리 액터(SA: secondary actor)에서 계약 인증서 개인 키를 암호화하는 과정을 포함한다.
즉, 배포 경로와 통신처리 시간의 최소화 및 단순한 구조적 처리를 위해, SA는 인증서를 위한 키 쌍을 생성한 후, 키 쌍을 이용하여 자신의 인증서를 생성하고, 생성한 계약 인증서와 대응 개인키를 EVCC(100)로 배포한다. 계약 개인키의 기밀성(confidential) 유지를 위해, 계약 인증서 개인키의 보안 전송에는 보안 메커니즘이 사용된다.
계약 인증서(CC)는 eMSP(300)의 eMSP 1차 하위인증기관이 EVCC(100)에 대해 발행한 인증서(Sub-CA 1 certificate)(350) 및/또는 eMSP 2차 하위인증기관이 EVCC(100)에 대해 발행한 인증서(Sub-CA 2 certificate)(360)를 포함할 수 있다. 계약 인증서는 EVCC(100)에 의해 생성된 서명을 검증하도록 어플리케이션 계층 상의 XML 서명에 사용될 수 있다.
계약 인증서(CC: contract certificate)에 속한 공개 키(이하 간략히 '계약 공개 키'(contract public key)라고도 한다)(370)는 eMSP(300) 등의 세컨더리 액터(SA)에서 EVCC(100)로 계약 인증서와 계약 개인키가 배포될 때 보안을 위해 계약 개인키의 암호화에 사용된다. 즉, 계약 인증서(CC)의 암호화에는 세컨더리 액터 또는 eMSP(300)의 루트 인증서(312)에 포함되거나, eMSP 1차 중간CA 인증서(350) 또는 eMSP 2차 중간CA 인증서(360)에 포함된 공개 키(계약 공개키)(370)와 쌍을 이루는 비밀키가 사용될 수 있다.
또한, 계약 인증서 개인키 즉, 계약 개인키(K1)의 암호화에는 계약 인증서(CC)의 계약 공개키(contract public key)(370)와 OEM 프로비저닝 인증서(prov. certificate, 411)에 포함된 OEM 프로비저닝 공개키(prov. public key, 412)의 암호화 파라미터(encryption parameter)(M3)와, 임시 DH 공개 키(ephemeral Diffie Hellman public key)(K2, 372)가 사용될 수 있다. 암호화된 계약 개인키(K1)의 데이터 패킷(CCDP)에는 전기차 사용자에 대응하는 모빌리티 계정 식별자(eMAID)가 포함될 수 있다.
다시 말해서, 계약 개인키(380)는 OEM 프로비저닝 인증서(411)의 공개 키(412)에서 입력되는 ECDH(Elliptic-curve Diffie-Hellman, 타원곡선 디피-헬먼) 공유 비밀키를 기반으로 인증 태그(Authentication tag)를 가진 GCM(Galois/counter mode)에서 AES(Advanced encryption standard)로 암호화될 수 있다. ECDH 공유 비밀키는 암호화 파라미터(M3)에 대응될 수 있다.
즉, 인증 태그가 결합되는 계약 개인키(K1)는 OEM 프로비저닝 인증서의 공개키(412)에서 입력되는 ECDH 공유 비밀키를 기반으로 GCM 모드에서 AES로 암호화될 수 있다. ECDH 공유 비밀키는 DH 임시 공개키(K2, 372)와 DH 임시 비밀키를 포함한다. DH 임시 공개키(K2, 372)에 대응하는 DH 임시 비밀키 또는 DH 임시 개인키(ephemeral Diffi-Hellman private key)는 별도로 준비될 수 있다.
모빌리티 서비스 제공자(eMSP: e-Mobility service provider)(300)는 계약 인증서(contract certificate)를 생성하기 위해 루트 인증서(312)를 사용할 수 있다. 루트 인증서(312)는 eMSP 루트CA 인증서(root CA certificate)이며, 이러한 루트는 EVCC에 존재할 필요가 없지만, 인증서 프로비저닝 서비스(CPS)는 미리 설정된 절차에 따라 계약 인증서를 처리할 필요가 있다.
또한, eMSP(300)는 계약 인증서를 구성하고 암호화된 계약 인증서 개인키 즉, EVCC(100)를 위해 특별히 암호화된 키를 포함하는 EVCC(100)용 크레덴셜(credential)를 생성할 수 있다. 이 크레덴셜은 특정 메시지 필드(SignedInstallationData)에 저장될 수 있다.
또한, eMSP(300)는, EVSE의 SECC(200)를 경유하는 온라인 설치 경로를 통해 계약 인증서와 암호화된 개인키를 EVCC(100)로 배포하기 위해, 계약 인증서 데이터 패킷(contract certificate data packet, CCDP)이나 이를 포함한 인증서 설치 패키지(certificate installation package)를 일반적인 B2B 통신의 미리 설정된 통신 채널을 통해 CIR(certificate installation response) 메시지를 CPS(390)로 전달할 수 있다.
CPS(390)는 자신의 서명을 사용하여 자격 증명의 정확성과 신뢰성을 부여하고 서명된 메시지를 SECC(200)로 중계한다. 여기서, SECC(200)는 인증서 설치 응답(CertificateInstallationRes) 메시지를 컴파일하고 이를 EVCC(100)로 전송할 수 있다. 이 경우, 인증서 제공 서비스는 신뢰할 수 있는 것으로 간주되며, 따라서 EVCC(100)는 인증서 설치 응답 메시지를 통해 수신한 계약 인증서를 검증할 필요가 없다. 전술한 CPS(390)의 역할은 예를 들어 eMSP 자체, EVSE 운영자 또는 완전 독립형 서비스 사업자가 맡을 수 있다.
전술한 크리덴셜은 eMSP(300)와 EVCC(100)가 사전에 공유하는 대칭키 또는 EVCC(100)의 물리적 또는 논리적 신원을 확인하는데 사용될 수 있는 ID 등의 정보를 포함할 수 있다. 또한, 전술한 크리덴셜은 EVCC(100)의 개인키와 쌍을 이루는 공개키, 또는 공개키에 대한 공개키 인증서나 인증서 체인을 포함할 수 있다. 인증서 체인은 프로비저닝 인증서 체인을 포함할 수 있다. 프로비저닝 인증서는 EVCC(100)를 통한 일회성 인증에 사용되는 인증서이며, 인증 완료 후에 CPS 리프 인증서가 발급되어 설치됨으로써 추후의 인증에 사용될 수 있다.
한편, eMSP(300) 또는 SA가 표준이나 규정에 정의된 대로 서로 다른 곡선을 기반으로 여러 계약 인증서를 제공하는 경우, eMSP(300) 또는 SA는 여러 개의 서로 다른 서명 설치 데이터(SignedInstallationData) 컨테이너를 SECC(200)로 보내야 하며, EVCC(100)는 전기차 사용자의 재량에 따라 인증서 설치 요청(certificatleInstallationReq) 메시지에 대한 루핑 메커니즘을 활용하여 서로 다른 모든 계약 인증서를 가져와 설치할 수 있다.
또 한편으로, EVCC(100)는 OEM 프로비저닝 인증서(411)의 전기차 공개키('subjectPublicKey')와 연결된 개인 키를 사용하여 인증서 설치 요청(certificate installation request) 메시지의 본문 엘리먼트에 서명할 수 있다.
요약하면, 전술한 인증서 설치 방법은, 임시 정적 디피헬먼(Diffie-Hellman) 키 교환 프로토콜을 사용하여 수신자의 키가 정적인 세션 키를 파생한다. SA 또는 esMSP는 파생된 세션 키를 사용하여 암호화된 형식의 개인 키를 EVCC(100)로 전송한다. 디피헬먼 프로토콜의 임시 정적 변형에서 수신자 예컨대 EVCC(100)의 공개 키는 변경되지 않는다. 즉, 정적이며 발신자 즉, eMSP(300)에게 이미 알려져 있다. 그러나 발신자(300)는 수신자에게 전송되는 임시 공개 키를 계속 사용할 수 있다. 이러한 방식으로 발신자와 수신자 모두는 수신자의 응답 메시지 없이 동일한 세션 키를 파생할 수 있다. SA는 임시 키를 사용하기 때문에 파생된 세션 키는 비밀키 또는 개인키의 인스턴스(배포)마다 다르다.
또한, CPS(390)는 서명을 사용하여 자격 증명의 정확성과 신뢰성을 주장하고, 서명된 메시지 조각(P2)을 SECC(200)로 중계한다. SECC(200)는 CPS(390)로부터 받은 인증서 설치 응답(CertificateInstallationRes) 메시지를 컴파일하고 이를 EVCC(100)로 전송할 수 있다. 이 경우, 인증서 프로비저닝 서비스는 신뢰할 수 있는 것으로 간주되고, 따라서 EVCC(100)는 인증서 설치 응답 메시지를 통해 수신한 계약 인증서를 검증할 필요가 없다.
도 6 내지 도 8은 도 5의 인증서 설치 방법에 채용할 수 있는 인증서 설치 관련 메시지를 좀더 구체적으로 설명하기 위한 도면들이다.
본 실시예에 따른 인증서 설치 방법은 전기차 통신제어기가 제조사 프로비저닝 인증서와 연관된 개인키로 서명한 인증서 설치 요청(Certificate Installation Request) 메시지를 세컨더리 액터로 전송하고, 세컨더리 액터로부터 인증서 프로비저닝 서비스의 리프 인증서와 연관된 개인키로 서명된 인증서 설치 응답(Certificate Installation Response) 메시지를 수신할 수 있다.
여기서, 세컨더리 액터가 생성하는 인증서 설치 응답 메시지는 서명 설치 데이터(Signed Installation Data) 엘리먼트를 포함한 계약 인증서 데이터 패킷(Contract Certificate Data Packet)을 포함한다. 서명 설치 데이터 엘리먼트는 계약 인증서 체인(Contract Certificate Chain) 엘리먼트와 암호화된 개인키(Encrypted Private Key) 엘리먼트를 포함한다. 암호화된 개인키 엘리먼트는 신뢰 플랫폼 모듈(TPM: trusted platform module)이 없는 전기차 통신제어기를 위해 암호화된 새 계약 인증서에 속하는 개인키를 저장한다.
그리고 새 계약 인증서에 속하는 개인키는, 제조사 프로비저닝 인증서의 공개키로부터 입력되고 ECDH(elliptic curve Diffie-Hellman) 프로토콜을 통해 생성되는 암호화 키를 기반으로 AES(advanced encryption standard)-GCM(galois/counter mode)으로 암호화된다. AES-GCM으로 암호화된 개인키는, 서두 96-비트 내지 128-비트 초기화 벡터(IV: Initialization vector)의 다음에 528-비트 또는 448-비트의 암호문으로 계약 인증서 데이터 패킷의 암호화된 개인키 필드에 포함된다.
세컨더리 액터는 모빌리티 서비스 제공자(eMSP) 또는 충전서비스 사업자(MO)를 포함할 수 있다. AES는 실제 데이터를 암호화하는 알고리즘이고, GCM은 블록 단위의 암호화에서 블록된 암호화 패킷을 조합하여 데이터를 추측하는 것을 방지하는 방식을 가리킨다.
구체적으로, 도 6에 도시한 바와 같이, 전기차 충전제어기(EVCC)가 세컨더리 액터(SA)로 전송하는 인증서 설치 요청 메시지 타입(Certificate Installation Request Type)은, ID를 포함하는 속성(attributes) 엘리먼트와, 제조사 프로비저닝 인증서 체인(OEM Provisioning Certificate Chain), 루트 인증서 식별자 목록(List of Root Certificate IDs), 최대 계약 인증서 체인(Maximum Contract Certificate Chain), 및 우선순위형 계정 식별자(Prioritized eMAIDs) 엘리먼트들을 포함할 수 있다.
제조사 프로비저닝 인증서 체인은 OEM이 EVCC에 이전에 설치한 OEM 프로비저닝 인증서와 OEM 하위 CA 인증서로 구성된 EV 관련 인증서 체인이다. OEM 프로비저닝 인증서의 ID 즉, PCID(Provisioning certificate identifier)는 계약 파트너에 대응하는 특정 SA에 저장된 정보와 함께 현재 유효한 차량 계약을 식별하는 데 사용된다. 또한 PCID는 eMSP에서 연관된 EV에 속한 계약을 식별하는 데 사용될 수 있다. 이는 전기차 사용자가 계약을 생성할 때 eMSP에 PCID를 제공한 경우에 가능하다. 이를 위해 PCID는 프로비저닝 인증서를 생성한 OEM에 대한 고유한 짧은 문자열로 생성될 수 있고, 제조사 프로비저닝 인증서에 포함될 수 있다.
제조사 프로비저닝 인증서는 DER(distinguished encoding rules)로 인코딩될 수 있다. OEM 프로비저닝 인증서 자체 즉, 공개 키는 나중에 인증서 설치 응답(CertificateInstallationRes) 메시지의 계약 인증서와 관련된 개인 키를 암호화하는 데 사용될 수 있다. 또한, PCID는 전기차 사용자로부터 다른 통신 채널을 통해 SA에 제공될 수 있다.
또한 제조사 프로비저닝 인증서 체인은 하위 엘리먼트들로서 인증서(Certificate) 엘리먼트와 서브인증서(SubCertificates) 엘리먼트를 포함할 수 있다. 여기서 인증서는 x.509v3 인증서 또는 클라이언트 인증서를 지칭할 수 있고, DER 포맷으로 인코딩될 수 있다. DER(distinguished encoding rulue) 포맷은 암호화에 사용되어 X.509 인증과 같이 디지털 방식으로 서명해야 하는 데이터가 고유한 일련 번호를 가진 표시를 생성하도록 기능한다. DER 포맷을 사용하면 X.509 인증의 서명과 검증이 가능해진다. 서브인증서는 루트 인증서를 포함하지 않은 루트 인증서에 대한 모든 하위 인증서들을 가진 체인을 지칭한다.
루트 인증서 식별자 목록(ListofRootCertificateIDs)은, 현재 EVCC에 설치된 모든 V2G 루트 CA 인증서의 인증서 ID가 포함되어 있다. 이러한 루트 인증서는 EVCC에서 인증서 설치 응답(CertificateInstallationRes) 메시지에 포함된 SA 인증서의 유효성을 검사하는 데 사용될 수 있다. 그리고, 인증서 설치 응답 메시지에 포함된 SA 인증서의 공개키는 인증서 설치 응답 메시지의 서명을 확인하는 데 사용될 수 있다.
최대 계약 인증서 체인(MaximumContractCertificateChain)은 해당 시점에 전기차 또는 전기차의 EVCC가 설치하려는 최대 계약 인증서 체인 수를 나타낸다. EV가 메모리에 저장할 수 있는 최대 계약 인증서 체인 수보다 작거나 같을 수 있다. 예를 들어, EV가 5개의 계약 인증서를 저장할 수 있고 5개 모두를 설치하려는 경우, 최대 계약 인증서 체인 파라미터는 5로 설정된다. 한편, 동일한 EV가 3개의 계약 인증서만 설치하려는 경우, EVCC는 최대 계약 인증서 체인 파라미터를 3으로 설정할 수 있고, 최대 5개의 계약 인증서 체인을 저장할 수 있다.
또한, SA에 이 EV에 대해 사용할 수 있는 계약 인증서가 2개뿐인 경우, 최대 계약 인증서 체인(MaximumContractCertificateChains)은, 해당 EV에 대해 SA가 보유한 계약 인증서의 개수보다 많더라도, SA가 사용가능한 2개의 계약 인증서만 EVCC에 제공하도록 SA의 최대 계약 인증서 체인 내 계약 인증서의 개수를 제한한다. 한편, SA에 7개의 계약 인증서가 있고 EV가 최대 계약 인증서 체인의 파라미터를 3으로 설정하여 인증서 설치 요청 메시지에 담아 전송한 경우, SA는 우선순위형 계정식별자(PrioritizedEMAIDs) 파라미터를 기반으로 미리 설정된 우선순위에 따라 3개의 계약 인증서만을 선택하여 SECC에 제공할 수 있다.
우선순위형 계정 식별자(PrioritizedEMAIDs)는 해당 메시지에 선택적으로 포함되는 엘리먼트로서, EV에 설치해야 하는 계약 인증서를 참조하는 EMAID 목록을 나타낸다. 이때, EMAID는 가장 높은 우선순위에서 가장 낮은 우선순위 순으로 나열된다. SA는 우선순위형 계정 식별자 엘리먼트의 파라미터를 사용하여 최대 계약 인증서 체인(MaximumContractCertificateChains)이 SA에서 사용 가능한 계약 인증서 수보다 작은 경우 설치할 계약 인증서 목록을 필터링하고 EV가 원하는 가장 높은 우선 순위의 계약 인증서를 얻도록 기능할 수 있다.
우선순위형 계정 식별자 파라미터가 생략되고 SA가 인증서 설치 요청(CertificateInstallationReq) 메시지의 최대 계약 인증서 체인(Maximum Contract Certificate Chains)으로 표시된, EV가 설치하려는 최대 계약 인증서 체인 수보다 많은 EV에 대한 계약 인증서를 갖고 있는 경우, SA는 최대 계약 인증서 체인의 파라미터에 따라 SA가 선택한 해당 EV에 적용가능한 계약 인증서를 보낼 수 있다.
또한, 전기차 충전제어기(EVCC)가 세컨더리 액터(SA)로부터 수신하는 인증서 설치 응답 메시지 타입(Certificate Installation Response Type)은, 도 7에 도시한 바와 같이, 헤더(header)(미도시), 응답 코드(Response Code), 전기차 전원공급장치 처리상태(EVSE Processing), 인증서 프로비저닝 서비스 인증서 체인(CPS Certificate Chain), 서명 설치 데이터(Signed Installation Data), 추가 계약 인증서 체인(Remaining Contract Certificate Chains) 엘리먼트들을 포함할 수 있다.
응답 코드(ResponseCode)는 SECC에 의해 수신된 V2G 메시지의 승인 상태를 나타낸다.
전기차 전원공급장치 처리상태(EVSEProcessing)는 완료(Finished) 또는 진행 중(Ongoing)을 나타내는 파라미터 값들을 선택적으로 가질 수 있다. 파라미터 값 '완료(Finished)'는 인증서 설치 요청(CertificateInstallationReq) 메시지를 전송한 이후에 시작된 프로세싱을 EVSE가 완료했음을 나타낸다. 그리고 파라미터 값 '진행 중(Ongoing)'은 SA에서 응답 메시지가 전송된 시점에 EVSE가 상기의 프로세싱을 아직 처리 중임을 나타낸다.
인증서 프로비저닝 서비스 인증서 체인(CPS Certificate Chain)은 EVCC에서 SA로부터 수신되는 메시지 헤더의 서명을 확인하는데 사용된다.
추가 계약 인증서 체인(Remaining Contract Certificate Chains)은 추가 계약 인증서 체인의 설치 여부를 나타내는 것으로, 이 엘리먼트의 값이 0보다 크면, EVCC는 추가 계약 인증서 체인을 설치할 수 있다.
서명 설치 데이터(Signed Installation Data)는 위의 설명에 필요한 모든 데이터 유형을 포함한다.
즉, 서명 설치 데이터 타입(Signed Installation Data Type)는, 도 8에 도시한 바와 같이, 계약 인증서 체인(Contract Certificate Chain), 신뢰 플랫폼 모듈 지원 암호화(Encrypted for TPM), 타원곡선 디피-헬먼 곡선(ECDHCurve: elliptic-curve Diffie-Hellman Curve), 디피-헬먼 공개키(DH Public Key), SECP521 암호화된 개인키(SECP521_Encrypted Private Key), X448 암호화된 개인키(X448_Encrypted Private Key) 및 TPM 암호화된 개인키(TPM_Encrypted Private Key)를 포함할 수 있다.
계약 인증서 체인(Contract Certificate Chain)은 전기차 사용자 자동인증, 전기차 충전, 충전량 결제 등과 관련하여 EVSE에서 이용 중인 서비스의 인증에 사용된다.
신뢰 플랫폼 모듈 지원 암호화(Encrypted for TPM)는, 신뢰 플랫폼 모듈(TPM)을 지원하는 EVCC를 위한 것으로, 이 파라미터가 '있음(true)'으로 설정되면, TPM을 구비한 EVCC용 계약 인증서 개인키를 SA가 암호화한 것을 나타낸다. 따라서, TPM을 지원하지 않는 EVCC용 계약 인증서 개인키를 SA가 암호화한 경우, 이 파라미터는 '없음(false)'으로 설정된다.
타원곡선 디피-헬먼 곡선(ECDHCurve: Elliptic-Curve Diffie-Hellman Curve)은 eMSP가 계약 인증서 개인 키를 암호화하는 데 사용되는 세션 키 또는 시드(seed)를 생성하는 데 사용할 타원 곡선 암호(ECC: Elliptic Curve Cryptography) 곡선을 나타낸다. ECC 곡선은 ECDSA(Elliptic Curve Digital Signature Algorithm), ECDHE(Elliptic Curve Diffie-Hellman Ephemeral) 등의 암호 알고리즘을 포함할 수 있다. 이 파라미터는 'SECP521' 또는 'X448'로 설정될 수 있다.
이 파라미터에 대하여 좀더 구체적으로 설명하면, SA가 ECDHE를 통한 계약 인증서 개인 키의 암호화 키 생성을 위해 미리 지정된 제1 ECC 곡선을 사용하는 경우, SA는 ECDHCurve 파라미터를 'SECP521'로 설정한다. 또한, SA가 ECDHE를 통한 계약 인증서 개인 키 암호화 키 생성을 위해 미리 지정된 대로 제2 ECC 곡선을 사용하는 경우, SA는 ECDHCurve 파라미터를 'X448'로 설정한다.
디피-헬먼 공개키(DH Public Key)는, SA에서 계약 서명 개인키 또는 계약 인증서 개인키를 암호화하고 EVCC에서 복호화하는데 사용되는 것으로서, EVCC에서 세션 키를 생성하기 위한 SA의 디피-헬먼(Diffie Hellman) 공개 키이다. DH공개키는 최대 133-바이트이고, 첫 번째 바이트는 압축되지 않은 형식을 나타내는 고정 값 0x04를 가질 수 있다. ECDHCurve가 'SECP521'로 설정되면 DH공개키의 길이는 133-바이트이고, ECDHCurve가 'X448'로 설정되면 DH공개키의 길이는 57-바이트일 수 있다.
SECP521 암호화된 개인키(SECP521_Encrypted Private Key)는 TPM이 없는 EVCC에 대해 암호화된 새 계약 인증서에 속하는 521-비트 개인 키이다.
X448 암호화된 개인키(X448_Encrypted Private Key)는 TPM이 없는 EVCC에 대해 암호화된 새 계약 인증서에 속하는 448-비트 개인 키이다.
TPM 암호화된 개인키(TPM_Encrypted Private Key)는 TPM이 있는 EVCC에 대해 암호화된 새 계약 인증서에 속하는 개인 키이다.
전술한 바와 같이, SA에서 SECC로 보내는 모든 단일 서명 설치 데이터(SignedInstallationData) 패킷에 대해 고유한 ECDHE 키로 계약 인증서 개인키를 암호화할 수 있다. SA가 SECC로 보내는 모든 서명 설치 데이터 패킷 각각에 대해 ECDHE 키를 변경하는 것은, EVCC가 동일한 계약 인증서에 대해 세 개의 연속적인 인증서 설치 요청(CertificateInstallationReq) 메시지를 보내는 경우와 인증서 설치 응답(CertificateInstallationRes) 메시지 내 세 개의 서명 설치 데이터(Signed Installation Data) 모두에서 정확히 동일한 개인키를 사용하여 정확히 동일한 계약 인증서를 가져옴을 의미한다. 그러나 서명 설치 데이터는 모든 인증서 설치 응답 메시지에서 고유(unique)해야 한다. 이를 위하여, SA는 SECC로부터 특정 PCID에 대해 서명 설치 데이터를 제공하라는 요청을 받고, 그에 따라 계약 인증서 개인 키를 암호화하고 즉석에서 서명 설치 데이터를 생성할 수 있다.
위와 같은 구성에 의하면, 보안이 향상되지만 eMSP가 이미 OEM 프로비저닝 인증서 공개키를 저장하고 있으므로 데이터 패킷이 준비되어 있는 경우, 특히 인증서 설치 요청(CertificateInstallationReq)에 응답하는 데 약간의 지연이 추가될 수 있다. 이러한 지연은 해당 시스템의 SA나 eMSP의 재량에 따라 선택될 수 있다. 다만, 본 실시예에서는 SA에서 보낸 모든 서명 설치 데이터(Signed Installation Data) 패킷 각각에 대해 ECDHE 키를 변경할 것을 요구하지 않는다.
또한, SA 또는 eMSP는 서명 설치 데이터 필드에 서명하는 데 사용되는 인증서 프로비저닝 서비스(CPS) 인증서에 대해 인증서 프로비저닝 서비스가 사용하기를 원하는 곡선을 인증서 프로비저닝 서비스 상에 나타낼 수 있다. 이렇게 하면 인증서 프로비저닝 서비스는 SA 또는 eMSP가 해당 특정 서명 설치 데이터의 서명에 사용하기를 원하는 곡선과 관련된 인증서를 사용할 수 있다. 이것은 계약 인증서가 EVCC에 의해 거부되지 않도록 하는 SA 또는 eMSP의 보증에 도움이 될 수 있다.
또한, 특정 ECC 곡선과 관련된 CPS의 인증서가 취소된 경우, SA 또는 eMSP는 ECC 곡선에 기반한 인증서로 서명 설치 데이터(SignedInstallationData) 필드에 서명하도록 요청하지만, CPS는 SA 또는 eMSP의 요청을 선택적으로 준수할 수 있다. 즉, CPS는 서명 설치 데이터(SignedInstallationData)의 서명에 사용할 수 있는 ECC 곡선을 기반으로 하는 인증서를 구비할 수 있다. 한편, CPS가 ECC 곡선 기반 인증서를 가지고 있지 않지만 SA 또는 eMSP가 ECC 곡선 기반 인증서로 서명 설치 데이터의 추가 서명을 요청하는 경우, CPS는 SA 또는 eMSP의 요청을 준수하지 못할 수 있다. 이 경우, CPS는 해당 요청의 준수 불가를 응답할 수 있다.
도 9a 및 도 9b는 도 5의 인증서 설치 방법에 채용할 수 있는 SECP521 기반 암호화된 개인키의 암호화 및 복호화 과정을 설명하기 위한 도면들이다.
도 9a를 참조하면, 계약 인증서에 해당하는 521-비트 계약 인증서 개인키(Contact Certificate Private Key)는 ECDHE 프로토콜에서 파생된 세션 키를 사용하여 발신자 즉, SA 또는 eMSP에 의해 암호화된다.
발신자는 이 암호화를 위해 알고리즘 AES-GCM-256를 적용할 수 있다. 계약 인증서 개인키는 AES-GCM-256이 적용될 수 있도록 7개의 선행 0 비트를 패딩하여 528-비트로 확장된다. 명시적 패딩은 521-비트 개인키가 바이트 정렬되지 않기 때문에 필요하다.
즉, 입력 데이터의 길이가 미리 규정된 길이에 도달하기 위해 해당 데이터 요소에 선행 0이 포함될 수 있다. 평문 혹은 개인키의 길이가 사용되는 암호화 알고리즘의 블록 크기의 배수인 경우, 평문 또는 개인 키의 패딩은 필요하지 않다.
이 암호화를 위한 초기화 벡터(IV)는 암호화 전에 무작위로 생성되어야 하며 발신자가 정의한 엔트로피로써 최소 96-비트 길이를 가져야 한다.
이 암호화에 대한 AAD(additional authenticatied data)는 인증서 설치 요청(Certificate Installation Req.) 메시지에서 수신된/사용된 PCID를 구분 기호 없이 대문자와 숫자로 18-바이트 사이즈만큼 연결한 다음, 대문자와 숫자가 포함된 10진수 문자열로 인코딩되고 인증서 설치 응답 메시지에 포함된 계약 인증서의 16-바이트 SKI 값을 연결하여 계산될 수 있다.
AES-GCM-256 암호화를 위한 모든 입력 데이터 요소의 바이트 순서는 빅 엔디안(big endian)일 수 있다.
즉, AES-GCM-256 암호화의 출력은, 암호문과 인증 태그(Tag)가 된다. 528-비트 암호문에서는 7-비트 리딩 제로(Leading 0)와 521-비트 계약 인증서 개인 키(Contract Certificate Private Key) 암호문이 포함된다. 초기화 벡터(IV)는 특정 ECC 곡선을 이용하는 암호화된 개인키 즉, SECP521_EncryptedPrivateKey 필드의 최상위 12-바이트에서 대응하는 위치의 12-바이트로 전송된다. SECP521_EncryptedPrivateKey 필드에서 초기화 벡터(IV) 다음에 66-바이트의 암호문(Chphertext) 즉, 암호화된 개인 키(Encrypted Private Key)가 작성/배치된다. 태그(Tag)는 SECP521_EncryptedPrivateKey 필드의 최하위 16-바이트를 구성하도록 배치된다.
전술한 초기화 벡터(IV)와, 선행 0 비트들과 521-비트 계약 인증서 개인키와 PCID와 SKI 값을 알고리즘 AES-GCM-256를 통해 암호화하면, SA는 초기화 벡터(IV)와 528-비트 길이의 암호문(암호화된 리딩제로와 개인키)과 128-비트 길이의 인증 태그(간략히 '태그')가 연결된 계약 인증서 데이터 패킷을 생성할 수 있다. SA는 계약 인증서 데이터 패킷을 CPS로 전송하고, CPS는 계약 인증서 데이터 패킷(이하 제1 계약 인증서 데이터 패킷)에 자신을 서명을 추가한 제2 계약 인증서 데이터 패킷을 SECC로 전송하거나 또는 SECC를 경유하여 EVCC로 전송할 수 있다. SECC는 제2 계약 인증서 데이터 패킷을 컴파일하여 제1 계약 인증서 데이터 패킷을 EVCC로 전송할 수 있다.
도 9b에 도시한 바와 같이, 해당 메시지 또는 메시지 내의 SECP521_EnlcryptedPrivateKey를 수신하면, 수신자 또는 EVCC는 ECDHE 프로토콜에서 파생된 세션 키를 사용하고, AES-GCM-256 알고리즘을 적용하여 계약 인증서 개인키의 복호화를 진행한다.
수신자는 복호화 전에 추가 인증 데이터(AAD)를 계산하여 PCID와 SKI를 획득한다. PCID와 SKI는 암호문과 태그 사이에 배치될 수 있다.
수신자는 초기화 벡터(IV)를 SECP521_EncryptedPrivateKey 필드의 적어도 최상위 12-바이트에서 읽어낸다. 수신자는 암호문 즉 암호화된 개인 키를 SECP521_EncryptedPrivateKey 필드의 초기화 벡터(IV) 다음의 66-바이트에서 읽어낸다. 그리고 수신자는 인증 태그를 SECP521_EncryptedPrivateKey 필드의 최하위 16바이트에서 읽어낸다.
AES-GCM-256을 사용하여 데이터를 복호화할 때 데이터의 순서가 중요하다. 수신자는 AES-GCM-256 복호화 기능/API에 대한 입력 데이터가 미리 설정된 형식이나 포맷을 따르는지 확인한다.
수신자 또는 EVCC는 복호화된 데이터에서 최상위 7-비트가 제로(0)인지 확인한 뒤에 오는 최하위 521-비트를 521-비트 계약 인증서 개인키로 사용한다. 계약 인증서를 받으면 EVCC는 계약 인증서와 함께 받은 521-비트 개인키가 해당 인증서에 대해 유효한 521-비트 개인키인지 확인한다. 확인 결과, 521-비트 개인키의 값이 secp521r1 곡선의 기준점 차수보다 엄격하게 작고, 이 값과 기준점을 곱하면 계약 인증서의 521-비트 공개 키와 일치하는 키가 생성되면, EVCC 또는 수신자는 계약 인증서와 함께 받은 521-비트 개인키가 유효한 것으로 판단할 수 있다.
도 10a 및 도 10b는 도 5의 인증서 설치 방법에 채용할 수 있는 X448 기반 암호화된 개인키의 암호화 및 복호화 과정을 설명하기 위한 도면들이다.
도 10a를 참조하면, 계약 인증서에 해당하는 448-비트 계약 인증서 개인키(Contact Certificate Private Key)는 ECDHE 프로토콜에서 파생된 세션 키를 사용하여 발신자 즉, SA 또는 eMSP에 의해 암호화된다. 발신자는 이 암호화를 위해 알고리즘 AES-GCM-256를 적용할 수 있다. 이 암호화에 대한 초기화 벡터(IV)는 암호화 전에 무작위로 생성되며 발신자가 정의한 엔트로피로써 최소 96-비트 길이를 가질 수 있다. 또한, 이 암호화에 대한 AAD(additional authenticatied data)는 521-비트 계약 인증서 개인키의 AAD와 동일한 방식으로 계산될 수 있다.
전술한 AES-GCM-256 암호화의 출력은, 암호문과 인증 태그(Tag)가 된다. 448-비트 암호문은 암호화된 계약 인증서 개인 키(Contract Certificate Private Key)이다.
즉, 448-비트 계약 인증서 개인키의 암호화에서, 초기화 벡터(IV)는 특정 ECC 곡선을 이용하는 암호화된 개인키 즉, X448_EncryptedPrivateKey 필드의 최상위 12-바이트에서 대응하는 위치와 사이즈로 전송된다. X448_EncryptedPrivateKey 필드에서 초기화 벡터(IV) 다음에 56-바이트의 암호문(Chphertext) 즉, 암호화된 개인 키(Encrypted Private Key)가 기록된다. 태그(Tag)는 X448_EncryptedPrivateKey 필드의 최하위 16-바이트를 구성한다.
수신자 즉 EVCC는, 도 10b에 도시한 바와 같이, 인증서 설치 응답 메시지 또는 메시지 내의 X448_EnlcryptedPrivateKey를 수신하면, 수신자 또는 EVCC는 ECDHE 프로토콜에서 파생된 세션 키를 사용하고 AES-GCM-256 알고리즘을 적용하여 계약 인증서 개인키의 복호화를 진행한다.
수신자는 복호화 전에 추가 인증 데이터(AAD)를 계산하여 PCID와 SKI를 획득한다. EVCC에 의해 계산된 ADD에 포함되는 128-비트의 PCID와 SKI는 암호문과 태그 사이에 배치될 수 있다.
수신자는 초기화 벡터(IV)를 X448_EncryptedPrivateKey 필드의 최상위 12-바이트 내지 16-바이트 중 기설정된 사이즈의 바이트에서 읽어낸다. 수신자는 암호문 즉 암호화된 개인 키를 X448_EncryptedPrivateKey 필드의 초기화 벡터(IV) 다음의 66-바이트에서 읽어낸다. 그리고 수신자는 인증 태그를 X448_EncryptedPrivateKey 필드의 최하위 16바이트에서 읽어낸다.
AES-GCM-256을 사용하여 데이터를 복호화할 때 데이터의 순서가 중요하다. 수신자는 AES-GCM-256 복호화 기능/API에 대한 입력 데이터가 미리 설정된 형식이나 포맷을 따르는지 확인할 수 있다.
수신자 또는 EVCC는 복호화된 데이터의 최하위 448-비트를 448-비트 계약 인증서 개인키로 사용한다. 계약 인증서를 받으면, EVCC는 계약 인증서와 함께 받은 448-비트 개인키가 해당 인증서에 대해 유효한 448-비트 개인키인지 확인한다. 확인 결과, 448-비트 개인키의 값이 X448 곡선의 기준점 차수보다 엄격하게 작고, 이 값과 기준점을 곱하면 계약 인증서의 448-비트 공개 키와 일치하는 키가 생성되면, EVCC 또는 수신자는 계약 인증서와 함께 받은 448-비트 개인키가 유효한 것으로 판단할 수 있다.
전술한 실시예에서, 수신자 또는 EVCC는 데이터를 복호화하는 데 사용되는 인증된 복호화 기능이 128-비트의 인증 태그(줄여서 '태그'라고도 함)를 두 번째 입력으로 사용할 수 있는지 확인할 수 있다. 521-비트 개인 키 또는 448-비트 개인 키 또는 둘 다의 암호 해독이 실패하면, 수신자는 인증서 설치 응답(CertificateInstallationRes) 메시지를 유효하지 않은 것으로 거부할 수 있다.
도 11은 본 발명의 다른 실시예에 따른 전기차 통신제어기를 위한 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 장치(이하 간략히 '인증서 설치 장치')에 대한 개략적인 블록도이다. 도 12는 도 11의 인증서 설치 장치에 채용할 수 있는 AES-GCM 코어에 대한 블록도이다.
도 11 및 도 12를 참조하면, 인증서 설치 장치는 전기차 통신제어기(EVCC) 자체, EVCC 내 프로세서, 프로세서 내 적어도 하나 이상의 코어(110c)에 의해 구현될 수 있다.
전기차 통신제어기(100)에 대응하는 인증서 설치 장치는 적어도 하나의 프로세서(Processor, 110) 및 메모리(Memory, 120)를 포함하며, 인증서 설치 방법을 구현하는 프로그램이나 명령어들이 메모리(120)에 저장될 수 있다. 프로그램이나 명령어들은 프로세서(110)의 동작에 따라 메모리(120)에서 읽혀져 프로세서(110)에 탑재될 수 있다. 또한 인증서 설치 장치는 통신 인터페이스(comm. I/F, 130)를 더 포함할 수 있다.
프로세서(110)는 메모리(120)나 별도의 저장장치에 저장된 프로그램 명령을 실행할 수 있다. 프로세서(110)는 적어도 하나의 중앙 처리 장치(central processing unit, CPU), 그래픽 처리 장치(graphics processing unit, GPU), 차량 제어기, 또는 충전 제어기에 의해 구현될 수 있으며, 그밖에 본 발명에 따른 인증서 설치 방법을 수행할 수 있는 여타의 프로세서에 의해 구현될 수 있다. 프로세서(110)에는 키보드, 마우스, 디스플레이 장치, 터치스크린, 음성 입력장치 등의 입력 인터페이스, 출력 인터페이스 또는 입출력 인터페이스가 연결될 수 있다.
메모리(120)는 예컨대 ROM(Read Only Memory)와 같은 휘발성 메모리와, RAM(Random Access Memory)과 같은 비휘발성 메모리를 포함할 수 있다. 메모리(120)는 저장 장치에 저장된 프로그램 명령을 로드하여, 프로세서(110)에 제공할 수 있다.
메모리(120) 또는 별도의 저장 장치는, 프로그램 명령과 데이터를 저장하기에 적합한 기록매체로서, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(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(Solid State Drive)와 같은 반도체 메모리를 포함할 수 있다.
전술한 메모리(120) 또는 저장 장치는 프로세서에 탑재될 수 있는 제어 블록(control block), 실제 데이터를 암호화하는 알고리즘의 일종인 AES 암호블록(AES crypto-block), 블록 단위로 암호화 패킷을 조합하여 데이터의 추출을 방지하는 방식의 일종인 GCM 블록(GCM block)를 위한 제어, 동작 및 기능을 위한 프로그램 명령을 저장할 수 있다.
또한, 메모리(120) 또는 저장 장치에 저장되는 프로그램 명령은 본 실시예에 따른 인증서 설치 방법에 채용할 수 있는 계약 인증서 개인키 암호화 및/또는 복호화를 위한 프로그램 명령을 포함할 수 있다. 예를 들어, 프로그램 명령은 인증서 설치 요청 메시지를 세컨더리 액터로 전송하는 명령, 세컨더리 액터로부터 인증서 설치 응답 메시지를 수신하는 명령, 수신한 메시지에서 AAD를 확인하는 명령, 수신한 메시지에서 IV를 획득하는 명령, 수신한 메시지의 암호문에서 521-비트 또는 448-비트 계약 인증서 개인키를 획득하는 명령, 획득한 계약 인증서 개인키가 메시지를 통해 받은 계약 인증서에 대해 유효한지 확인하는 명령, 인증 태그를 두 번째 입력으로 사용할 수 있는지 확인하는 명령, 521-비트 개인키 및 448-비트 개인키 모두의 복호화가 실패하면, 인증서 설치 응답 메시지를 유효하지 않은 것으로 거부하는 명령 등을 포함할 수 있다.
통신 인터페이스(130)는 EVCC를 전력선 통신 방식으로 SECC와 연결하거나, EVCC를 근거리 유선/무선 네트워크, 이동통신망, 차량 네트워크, 위성통신망 등의 통신 네트워크를 통해 CPS, eMSP, MO 등의 세컨더리 액터와 연결하기 위한 적어도 하나 이상의 통신서브시스템을 포함할 수 있다.
한편, 인증서 설치 장치가 EVCC 내 프로세서(110) 또는 프로세서(110) 내 적어도 하나 이상의 코어(110c)에 의해 구현되는 경우, 도 12에 도시한 바와 같이, 인증서 설치 장치는 코더(110c)에 탑재되는 제어 블록(control block, 111), AES 암호블록(AES crypto-block, 112) 및 GCM 블록(GCM block, 113)를 포함할 수 있다.
또한, 인증서 설치 장치는 AES 암호블록(112)으로 키 값을 입력하기 위한 제1 입력단(115)과, GCM 블록(113)으로 평문/암호문, 초기화 벡터 및 추가 인증 데이터(AAD)를 입력하기 위한 제2 입력단(116)과, GCM 블록(113)으로부터 암호문/평문을 출력하기 위한 제1 출력단(117)과, GCM 블록(113)으로부터 태그(Tag)를 출력하기 위한 제 출력단(118)을 구비할 수 있다. 제어 블록(111)은 AES 암호블록(112) 및 GCM 블록(113)의 전체적인 동작을 제어할 수 있다.
AES 암호블록(112)은 라운드 블록, 키스케줄러 및 서브제어블록을 구비하고 데이터 패스는 128-비트일 수 있다. 128-비트의 평문/암호문 블록이 입력되면, 251-비트 또는 256-비트의 비밀키를 사용하여 특정 운영모드에서 암호화/복호화를 수행한다. AES 암호블록(112)는 251-비트 또는 256-비트의 비밀키의 사이즈에 의해 15 클록 이상의 사이클을 필요로 할 수 있으나, 그만큼 보안의 기밀성을 향상시킬 수 있다.
GCM 블록(113)은 세 개의 256-비트 레지스터, 두 개의 32-비트 레지스터, 유한체(finite field or galois field) 곱셈기(114) 및 덧셈기를 구비한다. GCM 블록(113)에 데이터가 입력되면, 추가 입력 데이터의 경우, 유한체 곱셈기 연산을 하며, 평문/암호문의 경우 초기화벡터(IV)를 카운트하여 AES 블록으로 전송할 수 있다. 그리고, AES 블록(112)로부터 암호문/평문이 입력되면 유한체 곱셈기 연산을 수행할 수 있다.
도 13은 본 발명의 다른 실시예에 따른 인증서 설치 장치에 대한 개략적인 블록도이다.
도 13을 참조하면, 인증서 설치 장치는 세컨더리 액터 특히, 모빌리티 서비스 제공자(eMSP, 300), 충전서비스 사업자(MO), 인증서 프로비저닝 서비스(CPS)를 실행하는 장치 또는 이들의 조합에 의해 구현될 수 있다.
모빌리티 서비스 제공자(300)에 대응하는 인증서 설치 장치는 적어도 하나의 프로세서(Processor, 310), 메모리(Memory, 320) 및 통신 인터페이스(comm. I/F, 330)를 포함하고, 메모리(320)는 인증서 설치 방법을 구현하는 프로그램이나 명령어들을 저장할 수 있다. 프로그램이나 명령어들은 프로세서(310)의 동작에 따라 메모리(320)에서 독출되어 프로세서(310)에 탑재될 수 있다.
본 실시예의 인증서 설치 장치의 구성요소들은 설치 장소나 동작 주체가 다른 것을 제외하고 도 11 및 도 12를 참조하여 앞서 설명한 인증서 설치 장치의 대응 구성요소들과 실질적으로 동일할 수 있다.
다만, 메모리(320) 또는 별도의 저장 장치에 저장되는 프로그램 명령은 본 실시예에 따른 인증서 설치 장치에 채용할 수 있는 계약 인증서 개인키 암호화 및/또는 복호화를 위한 프로그램 명령을 포함할 수 있다. 예를 들어, 프로그램 명령은 인증서 설치 요청 메시지를 EVCC로부터 수신하는 명령, 세컨더리 액터로 인증서 설치 응답 메시지를 전송하는 명령, EVCC와 연관된 계약 인증서와 함께 계약 인증서 비밀키를 암호화한 데이터 패킷을 생성하는 명령, 데이터 패킷의 생성시 521-비트 키에 맞는 암호문의 사이즈를 결정하는 명령 등을 포함할 수 있다.
한편, 위에서 언급한 바와 같이 본 실시예에 따른 장치와 방법은 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 프로그램 또는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어 분산 방식으로 컴퓨터로 읽을 수 있는 프로그램 또는 코드가 저장되고 실행될 수 있다.
컴퓨터가 읽을 수 있는 기록매체는 롬(rom), 램(ram), 플래시 메모리(flash memory) 등과 같이 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치를 포함할 수 있다. 프로그램 명령은 컴파일러(compiler)에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터(interpreter) 등을 사용해서 컴퓨터에 의해 실행될 수 있는 고급 언어 코드를 포함할 수 있다.
본 발명의 일부 측면들은 장치의 문맥에서 설명되었으나, 그것은 상응하는 방법에 따른 설명을 나타낼 수도 있다. 즉, 블록 또는 장치는 방법 단계 또는 방법 단계의 특징에 상응할 수 있다. 이와 유사하게, 방법의 문맥에서 설명된 측면들은 또한 상응하는 블록이나 아이템 또는 상응하는 장치의 특징으로 나타낼 수 있다. 방법 단계들의 일부 또는 전부는 예를 들어, 마이크로프로세서, 프로그램 가능한 컴퓨터 또는 전자 회로와 같은 하드웨어 장치에 의해(또는 이용하여) 수행될 수 있다. 일부 실시예에서, 가장 중요한 방법 단계들의 하나 이상은 이와 같은 장치에 의해 수행될 수 있다.
일실시예들에서, 프로그램 가능한 로직 장치 예를 들어, 필드 프로그래머블 게이트 어레이가 여기서 설명된 방법들의 기능의 일부 또는 전부를 수행하기 위해 사용될 수 있다. 필드 프로그래머블 게이트 어레이는 여기서 설명된 방법들 중 하나를 수행하기 위한 마이크로프로세서와 함께 작동할 수 있다.
위에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

Claims (20)

  1. 전기차 통신제어기를 위한 계약 인증서 개인키의 암호화 및 복호화를 기반으로 하는 인증서 설치 방법에 있어서,
    전기차 통신제어기가 제조사 프로비저닝 인증서와 연관된 개인키로 서명한 인증서 설치 요청 메시지를 세컨더리 액터로 전송하는 단계; 및
    상기 세컨더리 액터로부터 인증서 프로비저닝 서비스의 리프 인증서와 연관된 개인키로 서명된 인증서 설치 응답 메시지를 수신하는 단계;
    를 포함하며,
    상기 인증서 설치 응답 메시지는 서명 설치 데이터 엘리먼트를 포함한 계약 인증서 데이터 패킷을 포함하고, 상기 서명 설치 데이터 엘리먼트는 계약 인증서 체인 엘리먼트와 암호화된 개인키 엘리먼트를 포함하고, 상기 암호화된 개인키 엘리먼트는 신뢰 플랫폼 모듈이 없는 전기차 통신제어기를 위해 암호화된 새 계약 인증서에 속하는 개인키를 저장하며,
    상기 새 계약 인증서에 속하는 개인키는, 상기 제조사 프로비저닝 인증서의 공개 키로부터 입력되고 ECDH 프로토콜을 통해 생성되는 암호화 키를 기반으로 AES(advanced encryption standard)-GCM(galois/counter mode)으로 암호화되며, 상기 AES-GCM으로 암호화된 개인키는, 상기 계약 인증서 데이터 패킷의 서두 96-비트 내지 128-비트 초기화 벡터 다음의 528-비트 또는 448-비트에 암호문 또는 암호화된 개인키 필드로서 포함되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  2. 제1항에 있어서,
    상기 AES-GCM으로 암호화된 개인키는, 상기 인증서 설치 응답 메시지의 전송 계층 보안에서 사용된 암호화 스위트(cipher suite)에 맞는 AES-GCM-256으로 암호화되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  3. 제1항에 있어서,
    상기 계약 인증서 데이터 패킷은 상기 암호문 뒤에 최하위 128-비트 태그를 더 포함하는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  4. 제3항에 있어서,
    상기 태그는 프로비저닝 인증서 식별자와 모빌리티 계정 식별자와의 연결에서 SHA-256 또는 SHA-384를 포함한 비밀 해시 알고리즘(SHA: secure hash algorithm)의 처음 128-비트에 추가 인증 데이터를 포함하는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  5. 제4항에 있어서,
    상기 추가 인증 데이터는 상기 인증서 설치 요청 메시지에서 사용되거나 수신된 상기 프로비저닝 인증서 식별자를 구분 기호 없이 18-바이트의 대문자와 숫자로 연결한 다음, 16-바이트의 대문자와 숫자가 포함된 10진수 문자열로 인코딩되는상기 인증서 설치 응답 메시지에 포함된 계약 인증서의 모빌리티 계정 식별자 또는 사용자 키 식별자의 값을 연결하여 계산되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  6. 제1항에 있어서,
    상기 계약 인증서 체인 엘리먼트는 전기차 전원공급장치에서 이용 중인 서비스의 인증에 사용되는 인증서 체인 파라미터를 포함하고,
    상기 인증서 체인 파라미터는 체인의 루트(root)까지 모든 하위 인증기관의 공개키 기반의 인증서 또는 상기 리프 인증서를 저장하는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  7. 제6항에 있어서,
    상기 인증서 또는 상기 리프 인증서는 클라이언트 인증서로서 DER(distinguished encoding rules) 포맷으로 인코딩되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  8. 제1항에 있어서,
    상기 서명 설치 데이터 엘리먼트는 ECDH커브(elliptic-curve Diffie-Hellman curve) 파라미터를 더 포함하고, 상기 ECDH커브 파라미터는 상기 서명 설치 데이터 엘리먼트에 서명하는데 사용되는 상기 인증서 프로비저닝 서비스의 리프 인증서에 대해 상기 인증서 프로비저닝 서비스가 사용하기 원하는 곡선을 나타내는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  9. 제8항에 있어서,
    상기 ECDH커브 파라미터는 ECDH커브의 종류는 나타내는 SECP521 또는 X448로 설정되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  10. 제9항에 있어서,
    상기 AES-GCM으로 암호화된 개인키는, 상기 ECDH커브의 설정에 따라 서로 다른 비트 사이즈로 암호화되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  11. 제1항에 있어서,
    상기 서명 설치 데이터 엘리먼트는 디피-헬먼 공개키(Diffie-Hellman public key) 엘리먼트를 더 포함하고, 상기 디피-헬먼 공개키 엘리먼트는 상기 세컨더리 액터에서 계약 인증서 개인키를 암호화하고 상기 전기차 통신제어기에서 복호화하기 위해, 상기 전기차 통신제어기에서 세션키를 생성하는데 이용되는 상기 제조사 프로비저닝 인증서의 전기차 공개키(subject public key) 또는 선택적 전기차 공개키(alternate subject public key)를 포함하거나 상기 세컨더리 액터의 스태틱 공개키(static public key) 또는 임시 공개키(ephemeral public key)를 포함하는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  12. 제11항에 있어서,
    상기 전기차 공개키, 상기 선택적 전기차 공개키, 상기 스태틱 공개키 또는 상기 임시 공개키는 압축되지 않은 형태로 인코딩되어 상기 디피-헬먼 공개키 엘리먼트에 저장되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  13. 제1항에 있어서,
    상기 서명 설치 데이터 엘리먼트는 상기 신뢰 플랫폼 모듈을 위한 특정 파라미터(EncryptedForTPM)를 더 포함하고, 상기 특정 파라미터는 해당 값이나 필요한 값이 없음을 나타내는 폴스(false)로 설정되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  14. 제1항에 있어서,
    상기 전기차 통신제어기는 상기 인증서 설치 요청 메시지 및 상기 인증서 설치 응답 메시지의 모든 비트 문자열 및 계산에 대해 빅-엔디언(big-endian) 순서 또는 리틀-엔디언(little-endian)를 사용하는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  15. 제1항에 있어서,
    상기 세컨더리 액터로부터 여러 개의 서로 다른 서명 설치 데이터 컨테이너(SignedInstallationData container)를 수신한 경우, 상기 전기차 통신제어기는 상기 인증서 설치 요청 메시지에 대한 루핑 메커니즘을 활용하여 상기 세컨더리 액터로부터 상기 신뢰 플랫폼 모듈이 없는 전기차 통신제어기에 대해 암호화된 서로 다른 모든 계약 인증서를 가져와 설치하는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법.
  16. 계약 인증서 개인키의 암호화 및 복호화를 기반으로 전기차에 인증서를 설치하는 장치에 있어서,
    프로세서;
    상기 프로세서에 의해 실행되는 명령어들을 저장하는 메모리; 및
    상기 프로세서에 연결되고 네트워크를 통해 외부 장치와 통신하는 통신 인터페이스;를 포함하며,
    상기 프로세서가 실행될 때, 상기 명령어들은 상기 프로세서가: 제조사 프로비저닝 인증서와 연관된 개인키로 서명한 인증서 설치 요청 메시지를 세컨더리 액터로 전송하는 단계; 및 상기 세컨더리 액터로부터 인증서 프로비저닝 서비스의 리프 인증서와 연관된 개인키로 서명된 인증서 설치 응답 메시지를 수신하는 단계;를 수행하도록 하며,
    상기 인증서 설치 응답 메시지는 서명 설치 데이터 엘리먼트를 포함한 계약 인증서 데이터 패킷을 포함하고, 상기 서명 설치 데이터 엘리먼트는 계약 인증서 체인 엘리먼트와 암호화된 개인키 엘리먼트를 포함하고, 상기 암호화된 개인키 엘리먼트는 신뢰 플랫폼 모듈이 없는 전기차 통신제어기를 위해 암호화된 새 계약 인증서에 속하는 개인키를 저장하며,
    상기 새 계약 인증서에 속하는 개인키는, 상기 제조사 프로비저닝 인증서의 공개 키로부터 입력되고 ECDH 프로토콜을 통해 생성되는 암호화 키를 기반으로 AES(advanced encryption standard)-GCM(galois/counter mode)으로 암호화되며, 상기 AES-GCM으로 암호화된 개인키는, 서두 96-비트 내지 128-비트 초기화 벡터의 다음에 528-비트 또는 448-비트의 암호문으로 상기 계약 인증서 데이터 패킷의 암호화된 개인키 필드에 포함되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 장치.
  17. 제16항에 있어서,
    상기 프로세서는 AES-GCM 코어를 포함하고,
    상기 AES-GCM 코어는 제어 블록, AES 암호블록 및 GCM 블록을 구비하고,
    상기 GCM 블록은 유한체(finite field or galois field)의 곱셈기를 구비하고,
    상기 AES 암호블록으로 키 값을 입력하기 위한 제1 입력포트와, 상기 GCM 블록으로 평문/암호문, 초기화 벡터 및 추가 인증 데이터를 입력하기 위한 제2 입력포트와, 상기 GCM 블록으로부터 암호문/평문을 출력하기 위한 제1 출력포트를 더 구비하는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 장치.
  18. 계약 인증서 개인키의 암호화 및 복호화를 기반으로 전기차에 인증서를 설치하는 장치에 있어서,
    프로세서;
    상기 프로세서에 의해 실행되는 명령어들을 저장하는 메모리; 및
    상기 프로세서에 연결되고 네트워크를 통해 외부 장치와 통신하는 통신 인터페이스;를 포함하며,
    상기 프로세서가 실행될 때, 상기 명령어들은 상기 프로세서가: 전기차 통신제어기로부터 제조사 프로비저닝 인증서와 연관된 개인키로 서명한 인증서 설치 요청 메시지를 수신하는 단계; 및 상기 전기차 통신제어기로 인증서 프로비저닝 서비스의 리프 인증서와 연관된 개인키로 서명된 인증서 설치 응답 메시지를 전송하는 단계;를 수행하도록 하며,
    상기 인증서 설치 응답 메시지는 서명 설치 데이터 엘리먼트를 포함한 계약 인증서 데이터 패킷을 포함하고, 상기 서명 설치 데이터 엘리먼트는 계약 인증서 체인 엘리먼트와 암호화된 개인키 엘리먼트를 포함하고, 상기 암호화된 개인키 엘리먼트는 신뢰 플랫폼 모듈이 없는 전기차 통신제어기를 위해 암호화된 새 계약 인증서에 속하는 개인키를 저장하며,
    상기 새 계약 인증서에 속하는 개인키는, 상기 제조사 프로비저닝 인증서의 공개 키로부터 입력되고 ECDH 프로토콜을 통해 생성되는 암호화 키를 기반으로 AES(advanced encryption standard)-GCM(galois/counter mode)으로 암호화되며, 상기 AES-GCM으로 암호화된 개인키는, 서두 96-비트 내지 128-비트 초기화 벡터의 다음에 528-비트 또는 448-비트의 암호문으로 상기 계약 인증서 데이터 패킷에 포함되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 장치.
  19. 제18항에 있어서,
    상기 전기차 통신제어기로 상기 인증서 설치 응답 메시지를 전송하는 세컨더리 액터는, 모빌리티 사업자(MO: mobility operator) 또는 모빌리티 서비스 사업자(eMSP: e-mobility service provider)를 포함하며,
    상기 인증서 프로비저닝 서비스(CPS: certificate provisioning service)의 역할은 상기 MO 또는 상기 eMSP 자체, 전기차 전원공급장치 사업자 또는 완전 독립형(stand-alone) 서비스 사업자에 의해 수행되는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 장치.
  20. 제19항에 있어서,
    상기 명령어들은 상기 프로세서가:
    상기 MO, 상기 eMSP 및 상기 CPS가 상기 계약 인증서 개인키와, 상기 ECDH 프로토콜을 통해 생성되는 비밀 키를 복구 불가능하게 삭제하거나 파기하는 단계를 더 수행하도록 하는, 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 장치.
PCT/KR2021/012135 2020-09-11 2021-09-07 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치 WO2022055222A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202180062436.1A CN116472693A (zh) 2020-09-11 2021-09-07 基于合同证书私钥的加密和解密来安装证书的方法和装置
US18/025,452 US20230327886A1 (en) 2021-09-06 2021-09-07 Method and device for installing certificate on basis of encryption and decryption of contract certificate private key
EP21867088.3A EP4195587A4 (en) 2020-09-11 2021-09-07 METHOD AND DEVICE FOR INSTALLING CERTIFICATE BASED ON ENCRYPTION AND DECRYPTION OF PRIVATE KEY OF CONTRACT CERTIFICATE

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US202063077109P 2020-09-11 2020-09-11
US63/077,109 2020-09-11
US202063117089P 2020-11-23 2020-11-23
US63/117,089 2020-11-23
KR10-2021-0118599 2021-09-06
KR1020210118599A KR20220034674A (ko) 2020-09-11 2021-09-06 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2022055222A1 true WO2022055222A1 (ko) 2022-03-17

Family

ID=80629728

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/012135 WO2022055222A1 (ko) 2020-09-11 2021-09-07 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치

Country Status (2)

Country Link
EP (1) EP4195587A4 (ko)
WO (1) WO2022055222A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115391750A (zh) * 2022-10-26 2022-11-25 浙江华东工程数字技术有限公司 一种算法授权方法、装置、电子设备和存储介质
CN117424700A (zh) * 2023-10-20 2024-01-19 重庆大学 基于充电桩自组网的数据安全访问方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200282859A1 (en) * 2019-03-05 2020-09-10 Hyundai Motor Company Charging control method and apparatus for electric vehicle

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200282859A1 (en) * 2019-03-05 2020-09-10 Hyundai Motor Company Charging control method and apparatus for electric vehicle

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
LEE SEOKCHEOL; PARK YONGMIN; LIM HYUNWOO; SHON TAESHIK: "Study on Analysis of Security Vulnerabilities and Countermeasures in ISO/IEC 15118 Based Electric Vehicle Charging Technology", 2014 INTERNATIONAL CONFERENCE ON IT CONVERGENCE AND SECURITY (ICITCS), IEEE, 28 October 2014 (2014-10-28), pages 1 - 4, XP032729742, DOI: 10.1109/ICITCS.2014.7021815 *
LEE SUJEONG, MINHO SHIN, HYUK-SOO JANG: "A Study on the Application of Cross-Certification Technology for the Automatic Authentication of Charging Users in ISO 15118 Standard", THE JOURNAL OF SOCIETY FOR E-BUSINESS STUDIES, vol. 25, no. 2, 31 May 2020 (2020-05-31), pages 1 - 14, XP055910720, ISSN: 2288-3908, DOI: 10.7838/jsebs.2020.25.2.001 *
SAYED NADIM EL: "A Prototypical Implementation of an ISO-15118-Based Wireless Vehicle to Grid Communication for Authentication over Decoupled Technologies", 2019 AEIT INTERNATIONAL CONFERENCE OF ELECTRICAL AND ELECTRONIC TECHNOLOGIES FOR AUTOMOTIVE (AEIT AUTOMOTIVE), AEIT, 2 July 2019 (2019-07-02), pages 1 - 6, XP033599581, DOI: 10.23919/EETA.2019.8804545 *
See also references of EP4195587A4 *
VAIDYA BINOD; MOUFTAH HUSSEIN T.: "Multimodal and Multi-pass Authentication Mechanisms for Electric Vehicle Charging Networks", 2020 INTERNATIONAL WIRELESS COMMUNICATIONS AND MOBILE COMPUTING (IWCMC), IEEE, 15 June 2020 (2020-06-15), pages 371 - 376, XP033799631, DOI: 10.1109/IWCMC48107.2020.9148231 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115391750A (zh) * 2022-10-26 2022-11-25 浙江华东工程数字技术有限公司 一种算法授权方法、装置、电子设备和存储介质
CN115391750B (zh) * 2022-10-26 2023-02-14 浙江华东工程数字技术有限公司 一种算法授权方法、装置、电子设备和存储介质
CN117424700A (zh) * 2023-10-20 2024-01-19 重庆大学 基于充电桩自组网的数据安全访问方法及装置

Also Published As

Publication number Publication date
EP4195587A4 (en) 2024-08-28
EP4195587A1 (en) 2023-06-14

Similar Documents

Publication Publication Date Title
WO2021158021A1 (ko) 전기차에 대한 계약 인증서 설치 지원 방법 및 장치
WO2022015017A1 (ko) 목표 전력전송량 변경 방법 및 이를 구현하기 위한 전력전송 장치
US7181015B2 (en) Method and apparatus for cryptographic key establishment using an identity based symmetric keying technique
WO2022055222A1 (ko) 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치
CN112689981B (zh) 车辆、充电站和充电站管理服务器之间的通信认证系统和方法
WO2022065989A1 (ko) 전기자동차 충전을 위한 상호인증 장치 및 방법
WO2020218810A1 (ko) Ev 사용자 인가 방법 및 시스템
WO2020222516A1 (ko) 전기차 충전을 위한 교차 인증 방법 및 장치
JP5905286B2 (ja) 電力ネットワークアクセス制御装置および電力ネットワークアクセス制御方法
KR101377570B1 (ko) 전기자동차의 충전 통신 보안 장치 및 그 방법
CN111435390B (zh) 一种配电终端运维工具安全防护方法
EP4250221A1 (en) Method and device for providing information about pnc-related service provider
WO2022114903A1 (ko) 전기차 충전을 위한 교차인증 방법 및 장치
WO2021158020A1 (ko) 전기차 충전 스테이션의 부트스트랩 방법
Fuchs et al. HIP-20: Integration of vehicle-hsm-generated credentials into plug-and-charge infrastructure
Kilic Plug and Charge solutions with vehicle-to-grid communication
US20230327886A1 (en) Method and device for installing certificate on basis of encryption and decryption of contract certificate private key
KR101491553B1 (ko) 인증서 기반의 dms를 이용한 안전한 스마트그리드 통신 시스템 및 방법
KR20220034674A (ko) 계약 인증서 개인키의 암호화 및 복호화 기반 인증서 설치 방법 및 장치
WO2024205223A1 (ko) 전기차 충방전 인프라 관리 프로토콜에서 종단 보안 방법 및 장치
KR20220110062A (ko) 교차 인증서를 이용한 전기차 인증 방법 및 장치
WO2022139485A1 (ko) Pnc 관련 서비스 제공자 정보 제공 방법 및 장치
Xiong Research on security communication technology of internet of vehicles based on 5g technology
CN116472693A (zh) 基于合同证书私钥的加密和解密来安装证书的方法和装置
EP4219225A1 (en) Device and method for mutual authentication for electric vehicle charging

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: 21867088

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180062436.1

Country of ref document: CN

ENP Entry into the national phase

Ref document number: 2021867088

Country of ref document: EP

Effective date: 20230310

NENP Non-entry into the national phase

Ref country code: DE