Endpoint safety guarantee method and device in electric vehicle charging and discharging infrastructure management protocol

Abstract

The invention discloses an endpoint safety method and device suitable for an electric vehicle charging and discharging infrastructure management protocol. The endpoint security method comprises the steps of: signing at least one key-value pair among elements in a message body to be transmitted to a second node of the communication architecture; and sending a message comprising the at least one signed key-value pair to the second node.

Description

Technical Field

[0001] This disclosure relates to end-to-end security technologies. More specifically, this disclosure relates to end-to-end security methods and apparatus applicable to electric vehicle charging and discharging infrastructure management protocols. Background Technology

[0002] A charging station (CS) includes an electric vehicle power supply unit (EVSE) for charging and discharging electric vehicles (EVs) and a charging station controller (CSC) for managing the EVSE.

[0003] The charging station controller (CSC) communicates with charging point operators (CPOs), charging station operators (CSOs), or flexible operator systems (FOSs) according to predefined communication protocol specifications. These communication protocol specifications include the IEC 63110 series and the Open Charging Point Protocol (OCPP) of the Open Charging Alliance (OCA). The CSO or its backend includes a charging station management system (CSMS). The CSMS can be a central CSMS or a cloud-based CSMS.

[0004] Transport Layer Security (TLS) is used to ensure secure communication between CSC and CSMS. However, TLS has difficulty guaranteeing end-to-end security involving third parties, and due to certain inherent security issues in TLS, charging or discharging billing messages are vulnerable to hacking attacks.

[0005] Therefore, there is a need for a method to enhance the security of communication between CSC and local CSMS or cloud CSMS, or between local CSMS and Resource Manager (RM). Summary of the Invention

[0006] [Technical Issues]

[0007] This disclosure has been designed to meet the aforementioned needs of the conventional art. The purpose of this disclosure is to provide an end-to-end security method and apparatus that uses message signing, in whole or in part, to enhance the security of communication between a charging station controller (CSC) and a charging station management system (CSMS), or between the CSMS and a resource manager (RM), thereby improving end-to-end reliability in electric vehicle charging and discharging infrastructure management protocols.

[0008] Another object of this disclosure is to provide an end-to-end security method and apparatus that uses full or partial encryption of messages to improve end-to-end confidentiality in electric vehicle charging and discharging infrastructure management protocols.

[0009] Another object of this disclosure is to provide an end-to-end security method and apparatus for using JSON (JavaScript Object Notation) network signing and JSON network encryption on JSON messages or portions thereof in an electric vehicle charging and discharging infrastructure management protocol.

[0010] [Technical Solution]

[0011] According to one aspect of an exemplary implementation, an end-to-end security method performed by a first node of a communication architecture in an electric vehicle charging and discharging infrastructure management protocol includes: signing at least one key-value pair among elements in the body of a message to be transmitted to a second node of the communication architecture; and transmitting the message, which includes at least one signed key-value pair, to the second node.

[0012] According to one aspect of an exemplary embodiment, an end-to-end security device for performing end-to-end security in a communication architecture within an electric vehicle charging and discharging infrastructure management protocol includes: at least one instruction for end-to-end security; and a processor configured to perform end-to-end security according to the at least one instruction. The processor is configured to perform the following operations: sign at least one key-value pair among elements in the body of a message to be transmitted to a second node in the communication architecture; and transmit the message including at least one signed key-value pair to the second node.

[0013] At least one key-value pair may include a key as the header of the message and a value as the payload of the message.

[0014] The processor can also be configured to perform the following operation: sign the key path of at least one signed key-value pair.

[0015] When signing a key path, the key path value of the signed key path can include: a path to a specific element in the body of the message, and a path to a specific child element of that specific element within the path to that specific element.

[0016] The processor can also be configured to perform at least one of signing at least one key-value pair and signing a key path using a digital certificate.

[0017] The processor can also be configured to perform the following operation: sign the entire header of the message.

[0018] The processor can also be configured to perform the following operation: sign the range of a specific element in the protected header of a message.

[0019] The processor can also be configured to perform the following operation: bind at least one signed key-value pair to the message payload.

[0020] The processor can also be configured to perform the following operation: sign at least one key-value pair using a JSON (JavaScript Object Notation) network token.

[0021] The processor can also be configured to perform the following operation: encrypt at least one signed key-value pair using JSON (JavaScript Object Notation) network encryption.

[0022] The processor can also be configured to perform the following operation: add a signed key to the protected header of the message.

[0023] The processor can also be configured to perform the following operation: add a signed key path to the protected header of the message.

[0024] The processor can also be configured to do the following: add a signed key and a signed key path to the protected header of the message.

[0025] The first or second node may include any of the following: a charging station controller (CSC) that manages at least one electric vehicle power supply device (EVSE); a local charging station management system (CSMS) that sends messages to or receives messages from the CSC; a cloud CSMS that sends messages to or receives messages from the CSC or local CSMS; and a resource manager (RM) that sends messages to or receives messages from the CSC or local CSMS.

[0026] [Beneficial Effects]

[0027] According to this disclosure, end-to-end reliability in electric vehicle charging and discharging infrastructure management protocols can be improved by configuring the system to sign messages or portions thereof in communications between the charging station controller (CSC) and the charging station management system (CSMS), or in communications between the CSMS and the resource manager (RM).

[0028] Furthermore, according to this disclosure, end-to-end confidentiality in electric vehicle charging and discharging infrastructure management protocols can be enhanced by encrypting messages or portions thereof in communications between the CSC and CSMS, or in communications between the CSMS and RM.

[0029] Furthermore, according to this disclosure, by forming a JSON network signature and JSON network encryption for JSON (JavaScript Object Notation) messages or parts thereof in the electric vehicle charging and discharging infrastructure management protocol, robust end-to-end security against hacking can be effectively provided in communications between CSC and CSMS or between CSMS and RM for billing processing, etc. Attached Figure Description

[0030] Figure 1 This is a schematic block diagram illustrating a communication architecture capable of employing an end-to-end security method according to an exemplary embodiment of the present disclosure.

[0031] Figure 2 This is an exemplary diagram illustrating a JWS compact, one of three types of JWS (JSON Web Signature) serialization used in the end-to-end security method of this exemplary embodiment.

[0032] Figure 3 It is shown Figure 2 An exemplary diagram of a compact JWS application example is shown.

[0033] Figure 4 This is an exemplary diagram illustrating JWS JSON, one of three types of JWS serialization, used in the end-to-end security method of this exemplary embodiment.

[0034] Figure 5 It is shown Figure 4 An exemplary diagram of the signature format of JWS JSON is shown.

[0035] Figure 6 This is an exemplary diagram illustrating the flattened JWS JSON, one of the remaining three types of JWS serialization used in the end-to-end security method of this exemplary embodiment.

[0036] Figure 7 This is an exemplary diagram illustrating a request message CALL, one of the OCPP-J messages, used in the end-to-end security method of this exemplary embodiment.

[0037] Figure 8 This is an exemplary diagram illustrating the CALLRESULT response message, one of the OCPP-J messages, used in the end-to-end security method of this exemplary embodiment.

[0038] Figure 9 This is an exemplary diagram illustrating the CALLERROR response message, one of the OCPP-J messages, used in the end-to-end security method of this exemplary embodiment.

[0039] Figure 10 This is an exemplary diagram illustrating the original message used to describe a signed OCPP message.

[0040] Figure 11 It is shown in Figure 10 An exemplary diagram of a signed message with a protected header in the original message.

[0041] Figure 12 It is shown in Figure 10 An exemplary diagram of an original message with an unprotected header.

[0042] Figure 13 It is shown that has Figure 12 An exemplary diagram of the signed payload of the original message with an unprotected header is shown.

[0043] Figure 14 This is an exemplary diagram illustrating the signature range of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment.

[0044] Figure 15 This is an exemplary diagram showing a portion of the signature range of an IEC 63110 message.

[0045] Figure 16 This is an exemplary diagram illustrating the excluded signature range for IEC 63110 messages.

[0046] Figure 17 This is an exemplary diagram illustrating the signed key binding problem of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment, and exemplary hacking behaviors that exploit this problem.

[0047] Figure 18 This is an exemplary diagram illustrating the key path binding problem of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment, and the hacking behavior that exploits this problem.

[0048] Figure 19 This is a diagram illustrating the JWS of the IEC 63110 message used in the end-to-end security method of this exemplary embodiment.

[0049] Figure 20a This is a diagram illustrating JWE (JSON Network Encryption) of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment.

[0050] Figure 20b It is shown Figure 20a An exemplary diagram illustrating an application example of the JWE for the IEC 63110 message shown.

[0051] Figure 21 and Figure 22 This is an exemplary diagram illustrating a combination of JSON network signing and JSON network encryption of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment.

[0052] Figure 23This is a schematic block diagram illustrating another form of a communication architecture capable of employing an end-to-end security approach according to this exemplary embodiment.

[0053] Figure 24 This is a schematic block diagram illustrating yet another form of a communication architecture capable of employing an end-to-end security approach according to this exemplary embodiment.

[0054] Figure 25 This is a schematic block diagram illustrating an end-to-end security device according to another exemplary embodiment of the present disclosure. Detailed Implementation

[0055] To better understand the features and advantages of the present invention, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. However, it should be understood that the present disclosure is not limited to the specific embodiments disclosed herein, but includes all modifications, equivalents, and substitutions falling within the spirit and scope of the present disclosure. In the drawings, similar or corresponding components may be indicated by the same or similar reference numerals.

[0056] The terms including ordinal numbers (such as “first” and “second”) designated in this specification for interpreting various components are used to distinguish components from other components, but are not intended to limit to any particular component. For example, a second component may be referred to as a first component without departing from the scope of this disclosure, and similarly, a first component may be referred to as a second component. As used herein, the term “and / or” may include one or more associated listed items and the presence of any and all combinations of listed items.

[0057] When a component is referred to as "connected" or "coupled" to another component, the component may be directly logically or physically connected or coupled to the other component, or indirectly connected through an intervening object. Conversely, when a component is referred to as "directly connected" or "directly coupled" to another component, it should be understood that there is no intervening object between the components. Other terms used to describe relationships between components should be interpreted in a similar manner.

[0058] These terms are used herein for the purpose of describing specific exemplary embodiments only and are not intended to limit this disclosure. Unless the context clearly specifies otherwise, the singular form also includes the plural indicator. Moreover, the expressions “comprising,” “including,” “construction,” and “configuration” are used to refer to the presence of a combination of the stated features, quantities, processing steps, operations, elements, or components, but are not intended to exclude the presence or addition of other features, quantities, processing steps, operations, elements, or components.

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

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

[0061] "Electric vehicle (EV)": A motor vehicle, as defined in 49 CFR 523.3, intended for use on public roads, powered by an electric motor that draws current from an onboard energy storage device (such as a battery) that can be recharged from an external source (such as a residential or utility power service or an onboard fuel-powered generator). EVs can include electric vehicles, electric cars, electric road vehicles (ERVs), plug-in vehicles (PVs), electric vehicles (xEVs), etc., and xEVs can be classified as plug-in fully electric vehicles (BEVs), battery electric vehicles, plug-in electric vehicles (PEVs), hybrid electric vehicles (HEVs), hybrid plug-in electric vehicles (HPEVs), plug-in hybrid electric vehicles (PHEVs), etc.

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

[0063] "Wireless Power Charging System (WCS)": A system for wireless power transfer, alignment, and communication between the ground component (GA) and the vehicle component (VA).

[0064] "Wireless power transfer (WPT)": The transmission or reception of electricity between an electric vehicle and a power source (such as a utility, power grid, energy storage device, or fuel cell generator) via a non-contact method such as electromagnetic induction or resonance.

[0065] "Utilities": A collection of systems that supply electricity, including Customer Information Systems (CIS), Two-Way Metering Infrastructure (AMI), rate and revenue systems, etc. Utilities can supply energy to EVs through rate tables and discrete events. Furthermore, utilities can provide information related to EV certification, intervals for electricity consumption measurement, and tax rates.

[0066] "Smart charging": an operating method or system in which electric vehicle charging equipment and / or electric vehicles communicate with the power grid to optimize the charging or discharging rate of the vehicle based on grid capacity or usage costs.

[0067] "Interoperability": The state in which components of a system cooperate with their counterparts to perform a target operation by the system. Additionally, information interoperability can refer to the ability of two or more networks, systems, devices, applications, or components to effectively share and easily use information without causing inconvenience to users.

[0068] "Inductive charging system": A system that transfers energy from a power source to an EV via a two-part air-gap core transformer, wherein the two halves of the transformer (i.e., the primary coil and the secondary coil) are physically separated from each other. In this invention, the inductive charging system can correspond to an EV power delivery system.

[0069] "Inductive coupling": Magnetic coupling between two coils. The two coils can refer to the ground component coil and the vehicle component coil.

[0070] "OEM (Original Equipment Manufacturer)" can include electric vehicle manufacturers or servers operated by electric vehicle manufacturers, and can also include root certificate authorities (CAs) or root certificate servers that issue OEM root certificates.

[0071] "V2G operator" can refer to a major participant in V2G communication via a transmission protocol, or an entity responsible for initiating a blockchain and generating smart contracts on a blockchain for automatic authentication of electric vehicles or EV users, and may include at least one reliable certification authority or reliable certificate server.

[0072] "Mobility Operator (MO)" can refer to one of the entities within the Plug and Charge (PnC) architecture that has a contractual relationship with EV owners regarding charging, authorization, and payment, allowing EV drivers to charge the EV battery at charging stations, and may include at least one certification authority or certificate server responsible for issuing and managing its own certificates.

[0073] "Charging Service Provider (CSP)" can refer to an entity that manages and authenticates EV users' credentials and provides billing and other value-added services to customers, and can be considered a specific type of MO and implemented in the form of integration with MO.

[0074] A “charging station (CS)” can refer to an entity that includes one or more charging station controllers (CSCs) and one or more electric vehicle power supply equipment (EVSE) units, and is responsible for transferring energy to or from an EV. A CSC can be a subsystem of a CS that manages one or more EVSEs. An EVSE can also include an EVSE controller, an EVSE interface, and a plug.

[0075] "Customer Energy Manager (CEM)" can refer to an internal automation function that optimizes on-site energy consumption and / or production based on customer preferences, using internal flexibility and external information received via smart grid connection points (SGCPs) and other data resources.

[0076] A “Mobility Account Identifier (eMAID)” can refer to a unique identifier that links a contract certificate to the payment account of the owner of the electric mobility device. In this exemplary embodiment, the mobility account identifier may include an identifier for the EV certificate or an identifier for the certificate provider. The term eMAID can be replaced by “Electric Mobility Account Identifier” or “Contract ID”.

[0077] "Clearing Center (CH)" can refer to an entity that handles collaborative matters between multiple MOs, CSPs, and CSOs, and can specifically act as an intermediary facilitating the approval, billing, and settlement processes for EV charging service roaming related to different EMSP contracts between two settlement entities or parties. The term "Clearing Center" can include the Electric Mobility Clearing Center (EMOCH).

[0078] "Roaming" can refer to a scheme and information exchange mechanism that allows EV users to access charging services provided by multiple CSPs or CSOs belonging to multiple mobility networks using a single credential and contract.

[0079] "Certificates" can refer to physical or digital assets that represent the personal information of an EV or an EV user, and can include encrypted information used to verify identity, such as passwords, public / private key pairs used in public-key cryptography, public key certificates issued by a certification authority, or information related to a trusted root certificate authority.

[0080] A "certificate" can refer to an electronic document that binds a public key to an identifier (ID) through digital signature.

[0081] A “service session” can refer to a set of services related to EV charging that are assigned to a specific customer at a charging point during a defined time period and have a unique identifier.

[0082] Exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. In the drawings, the same components may be designated by the same reference numerals to aid in the overall understanding of the present disclosure, and for simplicity, repeated descriptions thereof will be omitted.

[0083] Figure 1 This is a schematic block diagram illustrating a communication architecture capable of employing an end-to-end security method according to an exemplary embodiment of the present disclosure.

[0084] like Figure 1As shown, the communication architecture includes a premises network 100 serving as a Smart Grid Connection Point (SGCP), a charging station operator backend (CSO backend) 300, and secondary participants (SAs) 500. The premises network 100 can refer to a local or home network within a specific area.

[0085] The site network 100 may include a charging station (CS) 110, a local charging station management system (local CSMS) 130, a resource manager (RM) 150, and a customer energy manager (CEM) 170. The site network 100 may also include meters 190. Furthermore, the site network 100 may include power-related equipment 195, including loads, power generation systems, energy storage devices, etc.

[0086] In the site network 100, CS110 may include one or more Electric Vehicle Power Supply Devices (EVSEs) 112 and one or more Charging Station Controllers (CSCs) 114 configured to manage the EVSEs 112. CSC 114 may be a subsystem of CS110. EVSE 112 may include an EVSE controller, an EVSE interface, and a plug. In this exemplary embodiment, CS110 includes two EVSEs, namely a first EVSE 112a and a second EVSE 112b; however, the number is not limited to this, and CS110 may include one, three, or more EVSEs.

[0087] The first EVSE 112a can exchange power with the first electric vehicle (EV) 210 and communicate with the first EV user (EVU) 220. The first EV 210 and the first EVU 220 can exchange signals and data with each other. Similarly, the second EVSE 112b can exchange power with the second EV 230 and communicate with the second EVU 240. The second EV 230 and the second EVU 240 can exchange signals and data with each other.

[0088] Within the site network 100, the local CSMS 130 can exchange messages with CSC 114, cloud CSMS 310, and RM 150 according to the Electric Vehicle Charging and Discharging Infrastructure Management Protocol (hereinafter referred to as the "Management Protocol"). Messages according to the Management Protocol may include JSON (JavaScript Object Notation) messages as defined by the IEC 63110 standard.

[0089] The RM 150 of the site network 100 can refer to a logical component or entity typically implemented in software, representing the energy flexibility of a single smart device or a group of devices used to manage customer energy in a building or vehicle, and using device-specific protocols to transmit control commands.

[0090] Here, flexibility can refer to the resilience within an energy system to resource use (demand, storage, generation), consumption adjustment, and / or energy or electricity generation in response to external signals (such as price signals or requests) at the individual or aggregate level in order to provide services. The RM 150 can exchange messages, signals, and data with the CEM 170 according to predetermined agreements.

[0091] The CEM 170 features internal automation capabilities that utilize the internal flexibility of the site network 100, based on external information typically received through Smart Grid Connection Points (SGCPs) and other data sources, to optimize energy consumption and / or generation within the site according to customer preferences. The CEM 170 may include a CEM system. The CEM 170 can be connected for communication with at least one SA 500. The CEM 170 may be an optional component and can be omitted.

[0092] Meter 190 can measure the amount of electricity transmitted when power is supplied from SA 500 to EVs 210 and 230, loads, storage devices, etc. within site network 100, or when power is supplied from EVs 210 and 230, power generation systems, etc. within site network 100 to SA 500. Meter 190 may include a cumulative energy meter, a bidirectional digital energy meter, etc. Meter 190 can exchange signals and data with CEM 170 according to a predetermined communication protocol.

[0093] The CSO backend 300 may include a charging station management system (CSMS) 310. In this case, CSMS 310 may include a cloud CSMS 310. The cloud CSMS 310 can exchange IEC 63110 JSON messages with the local CSMS 130.

[0094] Therefore, the end-to-end security method of this exemplary embodiment can be configured to perform at least one of signing and encryption on messages or portions thereof sent from cloud CSMS 310 to local CSMS 130. The end-to-end security method of this exemplary embodiment can also be configured to perform at least one of signing and encryption on messages or portions thereof sent from local CSMS 130 to cloud CSMS 310.

[0095] SA500 may supply electricity or provide electricity-related services in accordance with contracts with site network 100 or its components. SA500 may include distribution system operator (DSO) 510, flexible operator (FO) 520, power supplier (ES), power / energy provider (EP) 530, electric mobility service provider (EMSP) 540, EV user (EVU) 550, charging station operator (CSO) or other system operator.

[0096] A DSO 510 is an entity responsible for the planning, operation, maintenance, and development of a specific area of ​​a distribution network. This specific area can be a low-voltage, medium-voltage, or high-voltage area. A DSO 510 can provide electricity supply (e.g., power supply, voltage, etc.) and customer access to the electricity supplier market through regulated systems. A DSO 510 can also mediate between two clearing partners to provide roaming verification services related to different EMSP contracts.

[0097] FO 520 is an entity responsible for providing at least one service (such as aggregating load flexibility from users of low-voltage and / or intermediate-voltage grids) and transacting the aggregated load flexibility with different third parties (including Transmission System Operators (TSOs) and / or DSOs 510s) to provide ancillary services or other flexibility markets (e.g., optimization of grid balancing charges).

[0098] EP 530 can refer to entities or participants that purchase electricity in bulk through contracts and resell it directly to customers. EP 530 can include EP systems. EP 530 can provide energy-related services. EP 530 can also provide flexibility in energy market or network operation pricing by adjusting electricity prices based on usage time, maximum marginal price, etc.

[0099] EMSP 540 is an entity that provides high-value services related to EV use. These high-value services may include EV leasing, parking reservation services, navigation services, energy services, etc. EMSP 540 may include charging station providers (CSPs) associated with CSO 560.

[0100] EVU 550 is an entity that uses the vehicle and provides the information required by the vehicle. EVU 550 may include the EVU system.

[0101] CSO 560 can refer to an entity connected to the power grid to manage electricity in order to supply electricity requested by electric vehicles. CSO 560 can be a term equivalent to or included in Charging Point Operator (CPO) or EMSP, or a term that includes CPO or EMSP. CSO, CPO, or EMSP can include at least one certification body responsible for issuing or managing certificates.

[0102] The aforementioned CSO 560, as one of the SA 500s, may include a CSO backend 300. The CSO backend 300 may refer to a device that manages a server or database, and is an area of ​​network applications invisible to users or a component performing equivalent functions. The CSO backend 300 may be a subsystem of the CSO 560.

[0103] This exemplary embodiment illustrates a basic system overview of the communication architecture for a single charging station installed behind an SGCP. The CEM 170 is responsible for optimizing power and energy within the SGCP. The CEM 170 can exchange messages with the local CSMS 130 or the cloud CSMS 310 via the RM 150, which implements the IEC 63110 protocol. Based on the behavior of local or auxiliary users, the CEM 170 can also connect to other systems outside its range.

[0104] All EVSE 112s connect to the CS110 via their own communication protocols. EVU 220 and 240 can interact with EV 210 and 230, EVSE 112a and 112b, CSO backend 300, CS0 560, and EMSP 540 by exchanging JSON messages through adapter interfaces (e.g., local display interface or remote application interface). Additional CS110s can be provided within the same SGCP or the same location network 100 under the control of one or more local CSMS130s. Optional local CSMS130s can be located within the CS110 or in another device.

[0105] The communication architecture of this exemplary embodiment can apply at least one of JSON network signing and JSON network encryption to messages to enhance the security of communication between CSC 114 and local CSMS 130, between local CSMS 130 and cloud CSMS 310, or between local CSMS 130 and RM 150.

[0106] Specifically, certain entities in the communication architecture can be configured to sign key-value pairs, including values ​​corresponding to the message payload and keys corresponding to the header, in the electric vehicle charge / discharge management protocol, or additionally sign the key path as needed, thereby protecting the message. Entities in the communication architecture can refer to devices or nodes with communication capabilities on a network that includes the communication architecture.

[0107] In this way, in the end-to-end (E2E) security method of this exemplary embodiment, in communications between local CSMS130 and CSC 114, between local CSMS130 and cloud CSMS 310, and between local CSMS130 and RM 150, messages or portions thereof can be signed for E2E reliability, encrypted for E2E confidentiality, or both for E2E reliability and confidentiality. The signature can correspond to JSON Web Signature (JWS), and the encryption can correspond to JSON Web Encryption (JWE).

[0108] Based on the above configuration of the end-to-end security method, the problem that using Transport Layer Security (TLS) in existing electric vehicle charging and discharging infrastructure management protocols cannot guarantee end-to-end security involving third parties can be addressed. As a result, losses due to hacking during the billing period caused by certain security issues in TLS can be prevented.

[0109] The above IEC 63110 JSON message will be described in more detail below.

[0110] Figure 2 This is an exemplary diagram illustrating a JWS compact, one of three types of JWS (JSON Web Signature) serialization used in the end-to-end security method of this exemplary embodiment.

[0111] Figure 3 It shows Figure 2 An exemplary diagram of a compact JWS application example is shown. Figure 4 This is an exemplary diagram illustrating JWS JSON, one of three types of JWS serialization, used in the end-to-end security method of this exemplary embodiment. Figure 5 It is shown Figure 4 An exemplary diagram of the signature format of JWS JSON is shown. Figure 6 This is an exemplary diagram illustrating a flattened JWS JSON, one of the remaining three types of JWS serializations, used in the end-to-end security method of this exemplary embodiment.

[0112] The Internet Engineering Task Force (IETF) JSON Object Signing and Encryption (JOSE) Working Group defines three JSON object formats: JSON Web Signature (JWS) (RFC 7515), JSON Web Encryption (JWE) (RFC 7516), and JSON Web Key (JWK) (RFC 7517). These formats utilize the JSON Web Algorithm (JWA) (RFC 7518) and the JSON Web Token (JWT) (RFC 7519).

[0113] JWS consists of a JOSE header, payload, and signature. The JOSE header includes the type, signature algorithm, and certificate.

[0114] JWE includes a JOSE header, encryption key, initialization vector (IV), ciphertext, and message authentication code (MAC).

[0115] JWS and JWE can be represented in three serialization formats. Specifically, these formats can include a compact format represented as a BASE64URL string, a JSON object with multiple keys, and a JSON object with a single key. A JSON object with multiple keys can be represented as JWS JSON, and a JSON object with a single key can be represented as flattened JWS JSON.

[0116] During serialization using the BASE64URL function, message data is encoded in BASE64 and can be padded to arbitrarily adjust its size. It can also be converted into a URL-safe string, or expressed as B64 by removing spaces and encoding it using the BASE64URL function. <data>).

[0117] In more detail, when using the BASE64URL function described above for JWS serialization, JWS serialization supports JWS compactness, which includes a single signature 23 associated with the header 21 and payload 22, such as... Figure 2 As shown. Each of the header 21, payload 22, and signature 23 can be 64 bytes in size. For example, JWS Compact can be constructed by sequentially concatenating B64 ( <jose-header> )、B64( <payload>) and B64 ( <signature>There are no spaces, and each part is constructed by separating it with a period (.). Here, signature 23 can be represented as a signature function SIG() with a JOSE header 21 and a payload 22 separated by periods. For example, as Figure 3 As shown, a serialized JWS compact message can have such a form in which the header 21, payload 22, and signature 23 are separated by periods and sequentially connected without spaces.

[0118] In addition, such as Figure 4 As shown, JWS serialization can be represented as a JWS JSON message 40, which has multiple signatures 23a for the protected header 21a and payload 22a. In JWS JSON, signature 23a can be represented as a signature function SIG() including the protected header 21a and payload 22a separated by periods, as shown. Figure 5 As shown in the diagram, the JOSE head 21a can be represented as the union of the unprotected head and the protected head.

[0119] In addition, such as Figure 6 As shown, JWS serialization can be configured to generate a flattened JWS JSON message 60, or simply flattened JSON, including a protected header 21a, a payload 22a, and a signature 23a for the protected header 21a. The JOSE header 21a can be represented as the union of the unprotected header and the protected header.

[0120] JWE JSON serialization represents JWE as a JSON object. JWE JSON serialization allows multiple parties to encrypt the same content. However, this method is not currently optimized for compactness or URL (Uniform Resource Locator) security.

[0121] In the JWS and JWE serialization methods described above, Compact and JSON have configurations for size, header protection, and number of signatures as shown in Table 1, but do not support the Open Charge Point Protocol (OCPP). Flat JSON supports OCPP but does not use a protected header, and for Compact, a single signer signs a single key-value pair with a single signature, thus it cannot be applied to situations requiring multiple signatures.

[0122] [Table 1]

[0123]

[0124]

[0125] Therefore, this exemplary embodiment provides an end-to-end security method using JWE Compact or JWE JSON, which can be used with OCPP. The end-to-end security method of this exemplary embodiment can be used for end-to-end security in electric vehicle charging and discharging infrastructure management protocols. Hereinafter, the aforementioned Open Charging Point Protocol (OCPP) messages (hereinafter referred to as "OCPP-J messages" or "OCPP messages") will be described.

[0126] Figure 7 This is an exemplary diagram illustrating a request message CALL, one of the OCPP-J messages, used in the end-to-end security method of this exemplary embodiment. Figure 8 This is an exemplary diagram illustrating the CALLRESULT response message, one of the OCPP-J messages, used in the end-to-end security method of this exemplary embodiment. Figure 9 This is an exemplary diagram illustrating the CALLERROR response message, one of the OCPP-J messages, used in the end-to-end security method of this exemplary embodiment.

[0127] OCPP-J messages can have versions such as OPP1.6J or OCPP2.1J, and can include message formats such as CALL (request), CALLRESULT (response), and CALLERROR (response).

[0128] A CALL (request) is a request message that indicates a call, and includes a message type identifier (MessageTypeId), a message identifier (MessageId), an action, and a payload. For example, as... Figure 7 As shown, the actions in a CALL (request) can include a boot notification, and the payload can include information such as the reason for power-on and charging station (CS) information. Charging station information can include a charger model such as a single-socket charger and a supplier name such as "Supplier X" (supplier name).

[0129] A CALLRESULT (response) is a response message that represents the result of a call, and can include a message type identifier (MessageTypeId), a message identifier (MessageId), and a payload. For example, ... Figure 8 As shown, the payload in CALLRESULT can include the current time, a time interval such as 300 seconds, and a status such as "accept".

[0130] A CALLERROR (response) is a message indicating a call error and can include a message type identifier (MessageTypeId), a message identifier (MessageId), an error code (ErrorCode), an error description (ErrorDescription), and error details (ErrorDetails). For example, as... Figure 9 As shown, in the CALLERROR (response), the error code can be represented as "Not supported", the error description can be represented as "Setting display message request not implemented", and the error details can be represented as an empty structure ({}) indicating that there is no content.

[0131] In the aforementioned CALL (request), CALLRESULT (response), and CALLERROR (response), the message type identifiers can be set to, for example, 2, 3, and 4 in the aforementioned order, and the message identifiers can be set to, for example, "19223201", "19223201", and "162376037" in the aforementioned order. The message types of CALL (request), CALLRESULT (response), and CALLERROR (response) can be briefly represented as CALL, CALLRESULT, and CALLERROR, respectively.

[0132] The aforementioned signed OCPP message may include additional elements for end-to-end security between the charging station (CS), the charging station management system (CSMS), the local controller, and third parties.

[0133] That is, a signed OCPP message can include a signing action and a signing payload, wherein only a portion of the message, including the message type identifier (MessageTypeId), message identifier (MessageId), action, and payload, is signed. Here, the signing action (SignedAction) can be represented as " <action>The signature payload is in the form of "-Signed" and can be represented as a flattened JWS JSON serialization with a protected header. The protected header may include the action recorded in the OCPPAction field, the message type identifier recorded in the OCPPPMessageTypeId field, and a certificate signed using a cryptographic algorithm such as SHA-256 (SHA256 signed certificate).

[0134] The processing of signed OCPP messages can be configured to check whether the signature is optional, and, when signing is supported, respond with a signed message.

[0135] Signed OCPP messages can use encryption algorithms such as ES256, RS256, and RS384. ES256 indicates the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) with P-256 and SHA-256, RS256 indicates the use of RASSA-PKCS1-v1_5 with SHA-256, and RS384 indicates the use of RASSA-PKCS1-v1_5 with SHA-384.

[0136] Table 2 below shows the encryption algorithms that can be used for signed OCPP messages.

[0137] [Table 2]

[0138]

[0139]

[0140] In Table 2, the Parm Value of the Algorithm ("alg") field in a signed OCPP message can indicate a specific digital signature algorithm or Message Authentication Code (MAC) algorithm. Specifically, regarding the parm value, HSxxx indicates a Hash-based Message Authentication Code (HMAC) using SHA-xxx, RSxxx indicates RASSA-PKCS1-v1_5 using SHA-xxx, ESxxx indicates an Elliptic Curve Digital Signature Algorithm (ECDSA) using P-xxx and SHA-xxx, and PSxxx indicates RASSA-PSS using SHA-xxx and MGF1 with SHA-xxx. Here, RASSA-PKCS1 indicates an RSA signature scheme with an appendix defined in Public Key Encryption Standard #1, and includes RASSA-PKCS1-v1_5 indicating version 1.5. RASSA-PSS indicates an RASSA signature and encryption scheme. Meanwhile, the parm value "None" indicates that no digital signature or Message Authentication Code (MAC) was performed. (See reference...) Figures 10 to 13 An example describing the aforementioned signed OCPP message.

[0141] Figure 10 This is an exemplary diagram illustrating the original message used to describe a signed OCPP message. Figure 11 It is shown in Figure 10 An exemplary diagram of a signed message with a protected header in the original message. Figure 12 It is shown in Figure 10 An exemplary diagram of an original message with an unprotected header. Figure 13 It is shown that has Figure 12 An exemplary diagram of the signature payload of the original message with an unprotected header is shown.

[0142] like Figure 10 As shown, when the original message 10 has a structure including a message type identifier, a message identifier, an action, and a payload, the signed OCPP message can have a structure including a message type identifier, a message identifier, a signature action, and a signature payload.

[0143] For example, such as Figure 11 As shown, based on the parameter values ​​of the encryption algorithm ("alg"), the signed message 11 can represent the OCPP message type identifier (OCPPMessageTypeId) as "2", the signing action corresponding to the OCPP action (OCPPAction) as "BootNotification", and the signature payload ("x5t#S256") as the hash value of the signature certificate encrypted using the EC256 encryption algorithm. For example, the hash value can be represented as "YmFzZTY0dXJsKCBTSEEyNTYoPFNpZ25pbmctQ2VydGlmaW".

[0144] Furthermore, when the original message has an unprotected header, the original message can be converted into a signed message 12, such as... Figure 12 As shown, the signed message 12 can be generated as elements including a message type identifier (MessageTypeId), a message identifier (MessageId), a signing action, and a signing payload (SignedPayload).

[0145] In this exemplary embodiment, the signing action is exemplified as a BootNotification-Signed, but the structure of this disclosure is not limited to this example.

[0146] like Figure 13 As shown, the SignedPayload 13 may include the payload, header, protection value, and signature. Here, the header may include information such as the type (typ) set to JWT (JSON Web Token) and the parameter value of the encryption algorithm (such as EC256) (e.g., "x5t#S256").

[0147] As mentioned above, OCPP messages only allow signing of the entire message, not just a part of it. The message identifier is not signed. That is, the message ID may not be known when a third party is the signer. Furthermore, this OCPP message only supports {128, 192}-bit security and does not support multi-signature. Multi-signature refers to supporting multiple algorithms, multiple keys, or multiple signers. Additionally, this OCPP message does not support end-to-end encryption.

[0148] Therefore, traditional OCPP cannot be directly applied to management protocols for electric vehicle charging and discharging infrastructure for end-to-end security. In particular, existing OCPP cannot be directly applied in situations requiring partial message signing, where it is desirable to select a signature algorithm based on security levels, where multiple signatures are needed to achieve a secure environment (such as end-to-end security and interoperability), or where selective encryption of all or part of the message is required.

[0149] Meanwhile, the IEC 63110 standard document specifies that Extensible Messages and XMPP (Extensible Multilingual Protocol) messages are used to transmit messages between key participants. XMPP is an application configuration file based on Extensible Markup Language (XML), which enables the near real-time exchange of structured yet scalable data between multiple participants.

[0150] XMPP operates as a message broker and, based on a distributed architecture of XMPP servers, allows clients to exchange messages with payloads, even if the clients are connected to different XMPP servers. End-to-end message routing depends on inter-server communication within the XMPP network. XMPP provides session-layer functionality and protects clients from the actual transport layer.

[0151] In the IEC 63110-2 standard, XMPP is used as the communication layer, introduced to clearly distinguish the services provided by XMPP from the lower-layer services of the protocol stack. XMPP itself uses TLS (Transmission Control Protocol / Internet Protocol) connections over TCP / IP as the transport layer.

[0152] The XMPP message described above includes a JSON header and a JSON body. In this case, it is not necessarily required to sign the entire JSON message. For example, since the JSON header is protected by TLS and is not part of the end-to-end communication, signing the JSON header is usually unnecessary.

[0153] Therefore, the end-to-end security device of this exemplary embodiment can be configured to sign the entire JSON body or specific elements thereof. Signing the entire JSON body or a portion thereof can be used when a message from a third party is transmitted to the CS / CSMS, or when a message from the CS / CSMS is transmitted to a third party. Here, the signer (including the CS, CSMS, RM, or a third party) knows the entire content of the body.

[0154] In the following text, reference will be made to Figures 14 to 18 A more detailed description is given of the configuration for implementing an end-to-end security approach by performing partial signing on XMPP messages.

[0155] Figure 14 This is an exemplary diagram illustrating the signature range of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment. Figure 15 This is an exemplary diagram showing a portion of the signature range of an IEC 63110 message. Figure 16 This is an exemplary diagram illustrating the excluded signature range for IEC 63110 messages. Figure 17 This is an exemplary diagram illustrating the signed key binding problem of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment, and exemplary hacking behaviors that exploit this problem. Figure 18 This is an exemplary diagram illustrating the key path binding problem of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment, and the hacking behavior that exploits this problem.

[0156] like Figure 14 As shown, the end-to-end security device can be configured to sign the entire body 141 of the JSON message 14 belonging to the XMPP message, as a form of partial signature.

[0157] In addition, such as Figure 15 As shown, the end-to-end security device can be configured to selectively sign specific elements in the body of JSON message 14.

[0158] For example, in Case 1, the end-to-end security device can be configured to sign the key path (kpath). In Case 2, the end-to-end security device can be configured to sign a time range. The time range can include subfields such as start, end, and unit, and the unit can be set to minutes. In Case 3, the end-to-end security device can also be configured to sign the trigger cause. The trigger field can include a source corresponding to a subfield involving a specific participant (such as CSMS), and a cause corresponding to a subfield storing a specific value such as a predefined code (e.g., "123", "124").

[0159] The end-to-end security device of this exemplary embodiment can be configured to perform partial signatures for any one or a combination of the above examples 1 to 3.

[0160] Simultaneously, the end-to-end security mechanism can be configured to exclude certain elements from the signature range of a partial signature, such as the range corresponding to a subfield of the duration field and the reason corresponding to a subfield of the trigger field included in the body. The reason for excluding this range and reason from the signature range is that signing multiple key-value pairs at once can be complex. Therefore, as needed, the end-to-end security mechanism can be configured to bind multiple key-value pairs into a single key pair or to sign them separately.

[0161] In another form of partial signature range, signing multiple key-value pairs at once can be complex, such as... Figure 16 As shown, an end-to-end security device can be configured to bind multiple key-value pairs into a single key pair, or to sign them separately. In this case, the signature can be replaced with at least one period.

[0162] In another form of partial signature scope, when it is difficult to bind a signature to an object, the end-to-end security mechanism can be configured to sign JSON objects.

[0163] This partial signature essentially refers to signing a single key-value pair. In this case, the signer, including CS, CSMS, RM, or a third party, knows the key-value pair at the time of signing. Therefore, the end-to-end security device of this exemplary embodiment can be configured to add a signature to a JSON message and bind the signature to the payload. The signature range can be added as a JSON Network Token (JWT). In this way, the end-to-end protection method of this exemplary embodiment can be configured to sign the original key "range" in the protected header to prevent signature movement issues. This method can also be applied to OCPP messages.

[0164] like Figure 17 As shown, due to the issue of key binding in signed signatures, the aforementioned partial signatures are vulnerable to external attacks (e.g., hacking). Specifically, there is no binding between the JWS signature and the signed key, allowing an attacker to replace a signed key (e.g., "reason-signed") with an expired signature (e.g., "expire-Signed"). <jws>And it inserts arbitrary cause values ​​(e.g., "789"). To address this weakness, end-to-end security mechanisms can be configured to add a signed key to the JOSE protected header.

[0165] like Figure 18 As shown, the aforementioned partial signatures may suffer from a key path binding problem. That is, because there is no binding between the positions of multiple signed keys, JWS signed messages may be vulnerable to external attacks that could rearrange their positions. To address this key path binding problem, an end-to-end security mechanism can be configured to add the key path of the signed key to the JOSE protected header.

[0166] Thus, in this exemplary embodiment, when performing JSON network signing on JSON messages, the system can be designed to use JWS Compact Serialization or JWS JSON Serialization. This configuration can prevent key spoofing attacks caused by the aforementioned issues with signed key bindings or key path spoofing attacks caused by key path binding issues.

[0167] The following section provides a more detailed description of the JSON network signature process in messages according to the IEC 63110 standard.

[0168] First, taking JWS Compact as an example, the end-to-end security device can be configured to sign key-value pairs with the header as the key and the payload as the value, and to sign the key path as needed. The end-to-end security device can also be configured to assume digital signatures with digital certificates. Furthermore, the end-to-end security device can be configured to sign the entire JOSE header, ensuring that no unprotected headers exist.

[0169] End-to-end security devices can use ES256, ES512, etc. as signature algorithms. Here, ES256 refers to an encryption algorithm that uses sep256r1, SHA256, and 128-bit secure elliptic curves, and ES512 refers to an encryption algorithm that uses sep512r1, SHA512, and 256-bit secure elliptic curves.

[0170] To describe in more detail the method for signing JWS compact messages, the end-to-end security device can first remove the payload to sign the payload corresponding to the key of the key-value pair. Then, the end-to-end security device can add a JWS token as the signed key.

[0171] JWS tokens can be generated as "B64( <jose-header> ).B64( <payload> ).B64( <signature>)".

[0172] The header included in the above JWS token ( <jose-header>An example format for ) is shown in Example 1 below.

[0173] [Example 1]

[0174]

[0175]

[0176] In addition, the signature included in the JWS token <signature>It can have features such as "SIG(B64( <jose-header> ).B64( <payload>The format is ))".

[0177] Furthermore, in the header (see Example 1) included in the JWS token, a signed key path ("signed-key-path") can be generated. <key-path>), as shown in Example 2.

[0178] [Example 2]

[0179] <key-path> ：＝{ <key-1> ：{ <key-2> ：....{ <key-n> ：{ <key>:{}}}}...}

[0180] In Example 2, the key path ( <key-path>This indicates the exact location of the signed key-value pair in the message.

[0181] like Figure 19 As shown, the signed key path in message 19 can be defined as {"body":{"trigger":{"reason":{}}}}}.

[0182] The following describes a method for signing JWS JSON, whereby an end-to-end security device can remove keys from the payload of a message and add signed keys in the form of a JWS token. <key>-signed).

[0183] JWS tokens can include a "payload" and a "signature". The "signature" can include a "protected" header and a "signature". The header ( <jose-header>The format of the signature can be the same as described in Example 1. <signature>It can have features such as "SIG(B64( <jose-header> ).B64( <payload>The format is ))".

[0184] An example of the JWS token mentioned above is shown in Example 3.

[0185] [Example 3]

[0186]

[0187]

[0188] As mentioned above, end-to-end security can be achieved in JWS JSON messages using JWS tokens that pair the protected header and the signature.

[0189] The following describes JWE encryption, which can be used for end-to-end security in electric vehicle charging and discharging infrastructure management protocols.

[0190] Figure 20a This is a diagram illustrating JWE (JSON Network Encryption) of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment. Figure 20b It is shown Figure 20a An exemplary diagram illustrating an application example of the JWE for the IEC 63110 message shown.

[0191] In this exemplary embodiment, the end-to-end security device can use JSON Compact Encryption for JWE Encryption. JWE Compact Encryption does not include encryption using multiple keys for multiple recipients. For JWE Encryption, the end-to-end security device can be configured to replace the key-payload pairs in the message with the encryption key and JWE.

[0192] That is, end-to-end security devices can add elements to JWE messages. <key>-Encrypt: <jwe>, to replace " <key> ： <payload>The added JWE element can have the form shown in Example 4.

[0193] [Example 4]

[0194] <jwe>=B64(<jose header>)

[0195] .B64(Encrypt( <encryption-key>))

[0196] .B64(<Initialization vector>)

[0197] .B64(Encrypt( <payload>))

[0198] .B64(<authentication tag> )

[0199] As can be seen from Example 4, the key encryption is used... <jwe>It can have a serialized form, where, for example, a header (<jose header> Encryption key encryption (Encrypt) <encryption-key>)), initialization vector (<initialization vector> ), payload encryption (Encrypt) <payload>and certification labels<authentication tag> Elements of the ) are separated by periods (.). Here, the encryption key is B64(Encrypt( <encrypt-key>The elements of )) can be used in key wrapping methods.

[0200] Example 5 illustrates the use of key encryption. <jwe>The head used (<jose header> Examples of ).

[0201] [Example 5]

[0202]

[0203] As an example of JWE encryption application, such as Figure 20a As shown, the end-to-end security device can use a format as shown in Example 6 to encrypt a specific element ("contractID": "123") in the JWE raw message.

[0204] [Example 6]

[0205] "contractIID-Enc": "B64( <header> )..B64( <iv> ).B64( <ciphertext> ).B64( <tag>)”

[0206] That is, JWE encryption may include the element ("contractID": "123") in the original message 20a being transformed and converted into "contractID-Enc: <jwe>The process of adding the form "" to the encrypted message 20b, such as Figure 20b As shown.

[0207] Figure 21 and Figure 22 This is an exemplary diagram illustrating a combination of JSON network signing and JSON network encryption of IEC 63110 messages used in the end-to-end security method of this exemplary embodiment.

[0208] like Figure 21 As shown, in step S211, the end-to-end security device can use JSON Network Signature (JWS) to sign key-value pairs in the JSON message. <key> ： <val>The value of 21a ( <val>The JWS value is signed using JSON Web Encryption (JWE) in step S212, and in that step, the signed JWS value can be encrypted using JSON Web Encryption (JWE). <key>-Sig:<JWS(val> Encryption is performed using 21b. Based on this process, the end-to-end security device can generate a cryptographically signed JWS value ( <key>-Sig-Enc: <JWE(<JWS(val)> )>) Element 21c. The generated element can be inserted into messages used in the management protocol of electric vehicle charging and discharging infrastructure.

[0209] Furthermore, as an example of the application of the combination of JSON network signing and JSON network encryption, such as Figure 22 As shown, when the contact identifier (contID) 22a has the value "1234", in step S221, the end-to-end security device can use JWS to check the value ( <val>The JWS value (contID-Sig:) is signed, and in step S223, the signed JWS value (contID-Sig:) is encrypted using JSON Web Encryption (JWE). <s-hdr> . <val> . <sig>Encryption is performed using 22b. Following this process, the end-to-end security device can generate a cryptographically signed JWS value (contID-Sig-Enc: <e-hdr> . <ekey> . <iv> . <ctext> . <tag>) element 22c.

[0210] Furthermore, in step S225, the end-to-end security device can transmit the encrypted and signed JWS value (contID-Sig-Enc: <e-hdr> . <ekey> . <iv> . <ctext> . <tag>)22c decryption, and in step S227, from the decrypted signed JWS value (contID-Sig: <s-hdr> . <val> . <sig>In step 22b, the JWS signature is removed. According to this procedure, the end-to-end security device can obtain the original contact identifier, which shows that its JWE has been decrypted and its JWS signature has been removed.

[0211] Therefore, in the electric vehicle charging and discharging infrastructure management protocol according to this exemplary embodiment, the end-to-end security method may include JSON network signing, JSON network encryption, or a combination thereof. In particular, by using double encryption—where the signed elements are encrypted again—both confidentiality and integrity can be effectively protected in billing messages using IEC 63110 messages, etc.

[0212] Figure 23 This is a schematic block diagram illustrating another form of a communication architecture capable of employing an end-to-end security approach according to this exemplary embodiment.

[0213] like Figure 23 As shown, the communication architecture includes a home network 100a serving as the smart grid connection point SGCP, a CSO backend 300, and secondary participants 500. The home network 100a may correspond to a local area network or a site network in a specific area.

[0214] Home network 100a may include a charging station (CS) 111 and a meter 190. In home network 100a, CS 111 may include one or more electric vehicle power supply devices (EVSEs) 112, one or more charging station controllers (CSCs) 114 managing the EVSEs 112, and a control interface 116. CSC 114 may be a subsystem of CS 110. EVSE 112 may include an EVSE controller 1121, an EVSE interface 1123, and a plug 1125.

[0215] Furthermore, within home network 100a, CSC 114 can send and receive messages with cloud CSMS 310 according to the Electric Vehicle Charging and Discharging Infrastructure Management Protocol (hereinafter referred to as the "Management Protocol"). Messages according to the Management Protocol may include JSON messages conforming to the IEC 63110 standard.

[0216] The CSO backend 300 can include Cloud CSMS 310. Secondary participants 500 can include DSO 510, FO 520, EP530, EMSP 540, EVU 550, CSO 560, etc. Cloud CSMS 310 and secondary participants 500 can be referenced above. Figure 1 The corresponding parts described are basically the same.

[0217] In the end-to-end (E2E) security method of this exemplary embodiment, in the message between CSC 114 and Cloud CSMS 310, for E2E reliability, a signature may be added to the message or a portion thereof; for E2E confidentiality, encryption may be applied to the message or a portion thereof; or for both E2E reliability and confidentiality, a signature may be added to the message or a portion thereof, and the signed message or its signed portion may be encrypted. The signature may be a JSON Web Signature (JWS), and the encryption may be a JSON Web Encryption (JWE).

[0218] This configuration based on the end-to-end security approach can address the issue that the use of TLS (Transport Layer Security) in existing electric vehicle charging and discharging infrastructure management protocols cannot guarantee end-to-end security for third parties, and thus prevent losses due to hacking during billing processing caused by certain security issues with TLS.

[0219] Figure 24 This is a schematic block diagram illustrating yet another form of a communication architecture capable of employing an end-to-end security approach according to this exemplary embodiment.

[0220] like Figure 24 As shown, the communication architecture includes a home network 100b serving as a Smart Grid Connection Point (SGCP), a CSO560, and secondary participants 500. The home network 100b can correspond to a local area network or a site network for a specific area.

[0221] Home network 100b may include a first charging station 110a, a second charging station 110b, a local CSMS 130a, a resource manager (RM) 150, and a customer energy manager (CEM) 170. Home network 100b may include power-related devices 195, such as loads, power generation systems, energy storage devices, etc.

[0222] In home network 100b, a first CS 110a may include one or more first electric vehicle power supply devices (EVSEs) 112a and one or more first CS controllers (CSCs) 114a configured to manage the first EVSEs 112a. The first CSC 114a may be a subsystem of the first CS 110a. A second CS 110b may include one or more second EVSEs 112b and one or more second CSCs 114b configured to manage the second EVSEs 112b. The second CSC 114b may be a subsystem of the second CS 110b. Each of the first EVSE 112a and the second EVSE 112b may include an EVSE controller, an EVSE interface, a plug, etc.

[0223] In home network 100b, local CSMS 130a can be connected to each of the first CSC 114a and the second CSC 114b via at least one of wired, wireless, or satellite communication methods. Local CSMS 130a can also be connected to RM 150 and cloud CSMS 310. Cloud CSMS 310 can be included in CSO 560. RM 150 can be connected to CEM 170, and CEM 170 can be connected to secondary participants 500 and power-related equipment 195 in the site. Secondary participants 500 can be connected to local CSMS 130a via CSO 560 and can include DSO 510, FO 520, EP 530, EMSP 540, and EVU 550. Each component of secondary participant 500 can be substantially the same as previously referenced. Figure 1 The corresponding components described are the same.

[0224] As described above, the local CSMS130a can exchange messages with the first CSC114a, the second CSC 114b, and the cloud CSMS 310 according to the Electric Vehicle Charging and Discharging Infrastructure Management Protocol. Such messages may include JSON messages according to the IEC 63110 standard.

[0225] In the end-to-end (E2E) security method of this exemplary embodiment, for messages between local CSMS 130a and the first CSC 114a, messages between local CSMS 130a and the second CSC 114b, messages between local CSMS 130a and the cloud CSMS 310, and messages between local CSMS 130a and the Resource Manager (RM) 150, for E2E reliability, a signature may be applied to the message or a portion thereof; for E2E confidentiality, encryption may be applied to the message or a portion thereof; or for both E2E reliability and confidentiality, a signature may be applied and the signed message or a portion thereof may be encrypted. The signature may be a JSON Web Signature (JWS), and the encryption may be a JSON Web Encryption (JWE).

[0226] This configuration based on the end-to-end security approach addresses the issue that the use of Transport Layer Security (TLS) in existing electric vehicle charging and discharging infrastructure management protocols cannot guarantee end-to-end security for third parties. Therefore, it can prevent losses during billing periods caused by hacking due to security vulnerabilities in TLS.

[0227] Figure 25 This is a schematic block diagram illustrating an end-to-end security device according to another exemplary embodiment of the present disclosure.

[0228] like Figure 25 As shown, the end-to-end security device 1000 may include at least one processor 1010 and a memory 1020. Furthermore, the end-to-end security device 1000 may also include at least one of a transceiver 1030, an input interface device 1040, an output interface device 1050, or a storage device 1060. The components of the end-to-end security device 1000 may be interconnected via a bus 1700 or a dedicated interface.

[0229] The processor 1010 can execute program instructions stored in the memory 1020 and / or the storage device 1060. The processor 1010 can be implemented by at least one central processing unit (CPU), graphics processing unit (GPU), or other processor capable of executing the method according to the invention.

[0230] Memory 1020 may include non-volatile memory such as read-only memory (ROM) and volatile memory such as random access memory (RAM). Memory 1020 may load program instructions stored in storage device 1060 to provide to processor 1010.

[0231] Storage device 1060 suitable for storing program instructions and data may include magnetic media, such as hard disks, floppy disks and magnetic tapes; optical media, such as CD-ROMs and DVDs; magneto-optical media, such as floppy disks; and semiconductor memories, such as flash memory, erasable programmable ROMs (EPROMs) or solid-state drives (SSDs) based thereon.

[0232] In this exemplary embodiment, certain components within the electric vehicle charging and discharging infrastructure can communicate with each other via wired, wireless, satellite, or a combination thereof. Wireless communication may include Wi-Fi-based wireless local area network (WLAN) communication according to the IEEE 802.11 standard. Alternatively, wireless communication may include peer-to-peer (P2PS) signaling communication using low-frequency (LF) signals or low-power excitation (LPE) signals. Furthermore, wireless communication may also include, or alternatively use, at least one of various communication methods such as Bluetooth, Zigbee, cellular, satellite communication, etc.

[0233] Furthermore, terminal devices can exchange messages based on data representation formats such as Extensible Markup Language (XML) or Effective XML Exchange (EXI) for wireless power transfer (WPT) or charging processes. During the charging and discharging of electric vehicles, an end-to-end secure channel can be established to verify the identity of the electric vehicle or user and protect communications from unauthorized access. The secure channel can use Transport Layer Security (TLS) as the default specification. After establishing a communication connection based on Internet Protocol (IP), a TLS session can be executed according to the TLS session establishment procedure.

[0234] Furthermore, in the exemplary embodiments described above, charging and discharging of the electric vehicle may include fast charging, slow charging, or a combination thereof. Slow charging may correspond to a situation where the amount of electricity supplied per unit time is relatively less than the amount supplied during fast charging.

[0235] While the above exemplary embodiments focus on end-to-end security in messages between the charging station controller (CSC) and the local charging station management system (CSMS), between the CSC and the cloud CSMS, between the local CSMS and the cloud CSMS, and between the local CSMS and the resource manager (RM), this disclosure is not limited to such configurations. Based on the security configurations in the above messages, the end-to-end security of this exemplary embodiment can be extended to messages between electric vehicles (EVs) and electric vehicle power supply equipment (EVSEs), between EVSEs and charging stations / charging station controllers (CS / CSCs), between CS / CSCs and charging station operators / charging station management systems (CSOs / CSMSs), between CSOs / CSMSs and customer service providers / marketplace operators / energy providers / charging point operators (CSPs / MOs / EPs / CPOs), and between CSPs / MOs / EPs / CPOs and clearing centers (CHs). For example, the end-to-end security of this exemplary embodiment can be applied in the order described or in the reverse order to all or at least part of the channels connecting EV, EVSE, CSC, CSMS / CSO, CSP / MO / EP / CPO and CH, and the end-to-end security method according to the exemplary embodiment of this disclosure can also be applied to communication channels involving these secondary participants when no other secondary participants such as facility operators (FOs) described herein are involved.

[0236] The methods described in the exemplary embodiments above can be implemented by computer-readable program code or instructions stored on a computer-readable intangible recording medium. A computer-readable recording medium includes all types of recording devices that store data readable by a computer system. The computer-readable recording medium can be distributed across a computer system connected via a network, allowing the computer-readable program or code to be stored and executed in a distributed manner.

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

[0238] Some aspects of this disclosure described above in the context of apparatus can indicate a corresponding description of a method according to this disclosure. That is, a block or apparatus can correspond to an operation or feature of the method. Similarly, some aspects described in the context of the method can be represented by features of blocks, modules, or corresponding apparatuses. For example, some or all of the operations of the method can be performed by (or using) hardware apparatus such as a microprocessor, a programmable computer, or electronic circuitry. In some exemplary embodiments, one or more of the most important operations of the method can be performed by such apparatus.

[0239] In some exemplary embodiments, programmable logic devices, such as field-programmable gate arrays (FPGAs), can be used to perform some or all of the functions of the methods described herein. FPGAs can be operated with a microprocessor to perform one of the methods described herein.

[0240] The description in this disclosure may be exemplary in nature only, and therefore, variations that do not depart from the spirit of this disclosure may be intended to fall within its scope. Such changes should not be considered as a departure from the spirit and scope of this disclosure. Consequently, those skilled in the art will understand that various changes in form and detail may be made without departing from the spirit and scope defined by the appended claims.< / sig> < / val> < / s-hdr> < / tag> < / ctext> < / iv> < / ekey> < / e-hdr> < / tag> < / ctext> < / iv> < / ekey> < / e-hdr> < / sig> < / val> < / s-hdr> < / val> < / key> < / key> < / val> < / val> < / key> < / jwe> < / tag> < / ciphertext> < / iv> < / header> < / jwe> < / payload> < / jwe> < / payload> < / jwe> < / payload> < / key> < / jwe> < / key> < / payload> < / jose-header> < / signature> < / key> < / key> < / key-n> < / key-2> < / key-1> < / key-path> < / payload> < / jose-header> < / signature> < / signature> < / payload> < / jose-header> < / jws> < / action> < / signature> < / payload> < / jose-header> < / data>

Claims

1. An end-to-end security method executed by a first node of a communication architecture in an electric vehicle charging and discharging infrastructure management protocol, the end-to-end security method comprising: Sign at least one key-value pair in the body of the message to be transmitted to the second node of the communication architecture; and The message, which includes at least one signed key-value pair, is sent to the second node.

2. The end-to-end security method according to claim 1, wherein, One of the at least one key-value pairs includes: a key as the header of the message and a value as the payload of the message.

3. The end-to-end security method according to claim 2 further includes: Sign the key path of the at least one signed key-value pair.

4. The end-to-end security method according to claim 3, wherein, When signing the key path, the key path value of the signed key path includes: the path to a specific element in the body of the message (text), and the path to a specific sub-element of the specific element in the path to the specific element.

5. The end-to-end security method according to claim 3, wherein, At least one of the signatures of the at least one key-value pair and the signature of the key path is performed using a digital certificate.

6. The end-to-end security method according to claim 2, further comprising: Add the signed key to the protected header of the message.

7. The end-to-end security method according to claim 6, wherein, Signing the at least one key-value pair includes binding the at least one signed key-value pair to the payload of the message.

8. The end-to-end security method according to claim 7, wherein, When signing the at least one key-value pair, a JSON (JavaScript Object Notation) network token is used.

9. The end-to-end security method according to claim 2, further comprising: Add the signed key path to the protected header of the message.

10. The end-to-end security method according to claim 1, further comprising: The at least one signed key-value pair is encrypted using JSON (JavaScript Object Notation) network encryption.

11. The end-to-end security method according to claim 1, wherein, The first node or the second node includes either of the following: The charging station controller (CSC) manages at least one electric vehicle power supply device (EVSE). The local (local) charging station management system (CSMS) sends the message to the CSC or receives the message from the CSC; The cloud CSMS can send the message to the CSC or the local CSMS, or receive the message from the CSC or the local CSMS. as well as The resource manager (RM) sends the message to the CSC or the local CSMS, or receives the message from the CSC or the local CSMS.

12. An end-to-end security device for performing end-to-end security in the communication architecture of an electric vehicle charging and discharging infrastructure management protocol, comprising: At least one instruction for end-to-end security; as well as A processor is configured to perform the end-to-end security according to the at least one instruction, wherein the processor is configured to perform the following operations: Sign at least one key-value pair in the body of the message to be transmitted to the second node of the communication architecture; as well as The message, which includes at least one signed key-value pair, is transmitted to the second node.

13. The end-to-end safety device according to claim 12, in, One of the at least one key-value pairs includes: a key as the header of the message and a value as the payload of the message.

14. The end-to-end safety device according to claim 13, wherein, The processor is also configured to perform the following operation: sign the key path of the at least one signed key-value pair.

15. The end-to-end safety device according to claim 14, wherein, The key path value of a signed key path includes: a path to a specific element in the body of the message (text), and a path to a specific sub-element of the specific element within the path to the specific element.

16. The end-to-end safety device according to claim 14, wherein, The processor is also configured to: use a digital certificate to perform at least one of signing the at least one key-value pair and signing the key path.

17. The end-to-end safety device according to claim 13, wherein, The processor is also configured to perform the following operations: The entire header of the message is signed, or a range (scope) of a specific element in the protected header of the message is signed.

18. The end-to-end safety device according to claim 17, wherein, The processor is also configured to perform the following operations: Bind the at least one signed key-value pair to the payload of the message.

19. The end-to-end safety device according to claim 18, wherein, The processor is also configured to perform the following operations: The at least one key-value pair is signed using a JSON (JavaScript Object Notation) network token.

20. The end-to-end safety device according to claim 12, wherein, The processor is also configured to perform the following operations: The at least one signed key-value pair is encrypted using JSON (JavaScript Object Notation) network encryption.

Images