EP4683823A1 - Konzept für nutzerspezifische provisions- und ladekontraktzertifikate - Google Patents

Konzept für nutzerspezifische provisions- und ladekontraktzertifikate

Info

Publication number
EP4683823A1
EP4683823A1 EP24702794.9A EP24702794A EP4683823A1 EP 4683823 A1 EP4683823 A1 EP 4683823A1 EP 24702794 A EP24702794 A EP 24702794A EP 4683823 A1 EP4683823 A1 EP 4683823A1
Authority
EP
European Patent Office
Prior art keywords
charging
vehicle
contract
cryptographically secured
certificate
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP24702794.9A
Other languages
English (en)
French (fr)
Inventor
Florian Kotsch
Harald Hofmeier
Holger Wierschin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Publication of EP4683823A1 publication Critical patent/EP4683823A1/de
Pending legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/30—Constructional details of charging stations
    • B60L53/305—Communication interfaces
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/10—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles characterised by the energy transfer between the charging station and the vehicle
    • B60L53/14—Conductive energy transfer
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/65—Monitoring or controlling charging stations involving identification of vehicles or their battery types
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/66—Data transfer between charging stations and vehicles
    • B60L53/665—Methods related to measuring, billing or payment
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • 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
    • 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/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L2240/00—Control parameters of input or output; Target parameters
    • B60L2240/70—Interactions with external data bases, e.g. traffic centres
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L2250/00—Driver interactions
    • B60L2250/12—Driver interactions by confirmation, e.g. of the input
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L2250/00—Driver interactions
    • B60L2250/20—Driver interactions by driver identification
    • 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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/70—Energy storage systems for electromobility, e.g. batteries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/7072—Electromobility specific charging systems or methods for batteries, ultracapacitors, supercapacitors or double-layer capacitors

Definitions

  • the invention relates to a charging control device, a user interface control device, a vehicle with a charging control device and a user interface control device, as well as to corresponding methods and computer programs.
  • Plug & Charge (a charging standard for charging electric vehicles) is based on the industry standard ISO 15118.
  • P&C Plug & Charge
  • drivers of electric cars such as battery-electric cars (also called BEV, Battery Electric Vehicle) or hybrid vehicles (also called PHEV, Plug-in Hybrid Electric Vehicle, a motor vehicle with a hybrid drive whose battery can be charged by the engine and by plugging in a charging plug) can authenticate at public charging stations simply by plugging in the charging cable.
  • Authentication is carried out using a digital contract certificate in accordance with the standard.
  • the contract certificate contains, among other things, the contract number.
  • the charging point operator can use this number to bill the contract provider (EMP or MO, Electro Mobility Provider or Mobility Operator, often the same as the EMP) for the charging process via the existing roaming platforms or to bill the customer directly (if the CPO is also the contract provider).
  • EMP Electro Mobility Provider or Mobility Operator
  • the vehicle can only transmit one certificate to the charging station; therefore, in many systems, only one certificate is kept on the vehicle.
  • the certificate is usually stored on the charger. Certificates can be installed either via PLC (communication via charging cable) from the charging station or via a backend (i.e. via a server) / telematics connection. Contract certificates are managed in a shared pool (collection) in backends/servers. The certificates are created by the MO and retrieved by the OEM (Original Equipment Manufacturer), for example the vehicle manufacturer. According to ISO 15118-2, the contract certificates are linked to a vehicle, not to a vehicle user.
  • provisioning certificate which is also issued specifically for the vehicle for this purpose and is only available once.
  • provisioning certificates i.e. the certificates of the In addition to the certificate chain (up to the root certificate)
  • the associated private/secret key is always stored in the vehicle's secure memory.
  • the secure memory for the private keys is often a special HSM (Hardware Security Module) that has limited memory.
  • the present invention is based on the realization that linking contract certificates and provisioning certificates to a vehicle is not essential to ensure the security of charging authentication.
  • the aforementioned standard only stipulates that each provisioning certificate has a unique identifier, the so-called PCID (Provisioning Certificate Identifier).
  • This identifier can match the chassis number (VIN, Vehicle Identification Number) (which links the identifier to the vehicle) or can be selected individually (limited in format by the standard), as long as it is ensured that the identifier is unambiguous and unique.
  • the present invention now uses provisioning certificates that are linked to a user account of a driver (or general "user") of the vehicle instead of to the vehicle.
  • Such a provisioning certificate is then inserted and stored in a cryptographically secured element of a charging control unit of the vehicle, for example when the user logs on to the vehicle, together with at least one charging contract based on the provisioning certificate, and is subsequently used to authenticate the charging control unit to a charging infrastructure.
  • This allows the driver (or user) of the vehicle to use "his" charging contracts in different vehicles without this functionality having to be explicitly supported by the aforementioned ISO standard.
  • One aspect of the present disclosure relates to a charging control device for a vehicle.
  • the charging control device comprises at least one interface for communicating with a charging infrastructure.
  • the charging control device comprises a cryptographically secured element.
  • the charging control device comprises a control circuit.
  • the control circuit is designed to receive a cryptographically secured provisioning certificate.
  • the cryptographically secured provisioning certificate comprises a unique identifier.
  • the unique identifier is linked to a user account of a driver of the vehicle.
  • the control circuit is designed to receive one or more cryptographically secured charging contracts.
  • the one or more cryptographically secured charging contracts are based on the cryptographically secured provisioning certificate.
  • the control circuit is designed to store the provisioning certificate and at least one charging contract of the one or more cryptographically secured charging contracts in the cryptographically secured element.
  • the control circuit is designed to authenticate the charging control device to the charging infrastructure based on the at least one charging contract stored in the cryptographically secured element. This allows the driver (or user) of the vehicle to use "his" charging contracts in different vehicles without this functionality having to be explicitly supported by the aforementioned ISO standard.
  • the unique identifier cannot be linked to the vehicle. This simplifies the use of the provisioning certificate in multiple vehicles.
  • the storage can be carried out on a memory of the charging control device or on a memory outside the charging control device.
  • the control circuit can be designed to store the provisioning certificate and the at least one charging contract in encrypted form on another memory of the charging control device, wherein the other memory is arranged outside the cryptographically secured element.
  • the control circuit can be designed to store the provisioning certificate and the at least one charging contract in encrypted form on another memory outside the charging control device. Storing in a memory of the charging control device enables a simpler implementation without involving other devices, but is dependent on the available memory. Storing in a memory outside the charging control device increases the implementation complexity, but enables the use of a memory shared by several control devices in the vehicle.
  • the method comprises obtaining a cryptographically secured provisioning certificate, wherein the cryptographically secured provisioning certificate comprises a unique identifier, wherein the unique identifier is linked to a user account of a driver of the vehicle.
  • the method comprises obtaining one or more cryptographically secured charging contracts, wherein the one or more cryptographically secured charging contracts are based on the cryptographically secured provisioning certificate.
  • the method comprises storing the provisioning certificate and at least one charging contract of the one or more cryptographically secured charging contracts in a cryptographically secured element of the charging control device.
  • the method comprises authenticating the charging control device to a charging infrastructure based on the at least one charging contract stored in the cryptographically secured element.
  • the method can be carried out by the charging control device, for example.
  • a further aspect of the present disclosure relates to a corresponding program with a program code for carrying out the method for the charging control device when the program code is executed on a computer, a processor, a control module, a control circuit or a programmable hardware component of the charging control device.
  • the user interface control device comprises at least one interface for communicating with a charging control device of the vehicle and for communicating with a user interface.
  • the user interface control device comprises a control circuit designed to receive a user input via the user interface. The user input indicates that a driver of the vehicle is logging into the vehicle via his user account.
  • the control circuit is designed to provide a control signal to the charging control device if a unique identifier included in a provisioning certificate on which a charging contract is based that is currently used for authentication to a charging infrastructure is linked to another user account.
  • the control signal indicates that a second provisioning certificate and at least one charging contract based on the second provisioning certificate are to be used for authentication to the charging infrastructure. This can signal to the charging control device that a different provisioning certificate with a corresponding charging contract is to be used in the future, for example when there is a driver change.
  • control circuit may be configured to output a representation of one or more charging contracts via the user interface based on the provisioning certificate whose unique identifier is associated with the currently logged in user account. This allows the newly logged in driver to select a charging contract if multiple charging contracts are associated with the same provisioning certificate.
  • the method includes receiving a user input via a user interface.
  • the user input indicates that a driver of the vehicle is logging into the vehicle via his user account.
  • the method includes providing a control signal to a charging controller of the vehicle if a unique identifier included in a provisioning certificate on which a charging contract is based that is currently used for authentication to a charging infrastructure is linked to another user account.
  • the control signal indicates that a second Provisioning certificate and at least one charging contract based on the second provisioning certificate is to be used for authentication to the charging infrastructure.
  • the method can be carried out, for example, by the user interface control device.
  • Another aspect of the present disclosure relates to a corresponding program with a program code for carrying out the method for the user interface controller when the program code is executed on a computer, a processor, a control module or a programmable hardware component, such as the user interface controller.
  • Fig. la shows a schematic diagram of a charging control device
  • Fig. 1b shows a flow chart of a method for a charging control device
  • Fig. 2a shows a schematic diagram of a user interface controller
  • Fig. 2b shows a flowchart of a method for a user interface controller
  • Fig. 3 shows a schematic diagram of a technical perspective on Plug &Charge
  • Fig. 4 shows a simplified representation of the technical infrastructure for the use of Plug & Charge.
  • Fig. 1a shows a schematic diagram of a charging control device 10 for a vehicle 100, wherein the charging control device 10 is part of the vehicle 100.
  • the charging control device comprises at least one interface 12 for communicating with a charging infrastructure 5 (such as a charging station), for example via powerline communication.
  • the at least one interface 12 comprises an interface for communicating with a user interface control device 20 of the vehicle 100, at least one interface for communicating with a server (not shown), for example via a telematics connection/cellular connection, and/or an interface for communicating with a memory 105 of the vehicle.
  • the charging control device 10 comprises a cryptographically secured element 14, for example a so-called “secure element” or “trusted execution environment”.
  • the charging control device 10 comprises a control circuit 16 which is coupled to the cryptographically secured element 14 and the at least one interface 12.
  • the cryptographically secured element can be part of the Control circuit 16 or a separate component.
  • the charging control unit 18 further comprises a memory 18 which is coupled to the control circuit 16.
  • the control circuit 16 is designed to receive a cryptographically secured provisioning certificate.
  • the cryptographically secured provisioning certificate comprises a unique identifier.
  • the unique identifier is linked to a user account of a driver of the vehicle.
  • a driver of the vehicle is not necessarily the person who controls the vehicle. If the vehicle is an autonomous vehicle, the driver is the person who uses the vehicle to move and/or specifies the destination of the autonomous vehicle.
  • the control circuit 16 is designed to receive one or more cryptographically secured charging contracts.
  • the one or more cryptographically secured charging contracts are based on the cryptographically secured provisioning certificate.
  • the control circuit 16 is designed to store the provisioning certificate and at least one charging contract of the one or more cryptographically secured charging contracts in the cryptographically secured element.
  • the control circuit 16 is designed to authenticate the charging control device to the charging infrastructure based on the at least one charging contract stored in the cryptographically secured element.
  • Fig. 1b shows a flow chart of a corresponding method for the charging control device 10.
  • the method includes obtaining 110 the cryptographically secured provisioning certificate.
  • the method includes obtaining 120 the one or more cryptographically secured charging contracts.
  • the method includes storing 130 the provisioning certificate and the at least one charging contract of the one or more cryptographically secured charging contracts in the cryptographically secured element 14 of the charging control device.
  • the method includes authenticating 140 the charging control device 10 to the charging infrastructure 5 based on the at least one charging contract stored in the cryptographically secured element.
  • the charging control device the corresponding method and a corresponding computer program are described below with reference to the charging control device. Features that can be described in connection with the charging control device can also be applied to the corresponding method or computer program.
  • provisioning certificates are used to prevent charging contracts (also called contract certificates) from being misused.
  • the provisioning certificate comprises a public part (ie public key) and a private part (ie private key).
  • the private part of the provisioning certificate is stored in the cryptographically secured element 14 when used. and a public part of the provisioning certificate is made available to the other participants, as shown in Fig. 4, for example via one or more aggregators.
  • the public part can now be used to encrypt the cryptographically secured charging contracts or to restrict their use so that they can only be used using the private part of the provisioning certificate, with commissioning taking place within the cryptographically secured element.
  • the certificate chain up to the root certificate
  • this is usually omitted in order to save storage space.
  • the proposed concept is based on the realization that if a provisioning certificate is tied to a vehicle, a user can conclude a personal charging contract (for example via a third-party vehicle power provider), but when changing vehicles, the vehicle power provider must issue a new certificate (of the charging contract) because this vehicle has a different provisioning certificate/PCID. This creates costs for both the customer and the contract provider. In addition, each time a certificate is created, the vehicle power provider incurs costs that the customer has to pay directly or indirectly.
  • the restriction of the provisioning certificate/PCID to assignment to exactly one vehicle also does not allow, for example, secondary users to use a contract exclusively for themselves or for a contract to always be available to all users of the vehicle. Likewise, this restriction does not allow a temporary user to take their personal Plug & Charge contract with them in a rental vehicle, for example.
  • the provisioning certificate or PCID is issued once per user account identifier (of the personal user account). Since the standard does not necessarily require the use of the chassis number, this identifier can be freely chosen so that it is unique per user account.
  • the cryptographically secured provisioning certificate comprises a unique identifier linked to a user account of a driver of the vehicle, such as the user account identifier mentioned above.
  • the identifier is unique, i.e. it is uniquely linked to a user account so that no second user account (or vehicle) can use the same identifier.
  • the identifier may comprise a prefix used exclusively by a vehicle manufacturer and another component that is unique among the vehicle manufacturer's user accounts.
  • the identifier may be independent of an identifier of the vehicle, such as a chassis number. Consequently, the unique identifier cannot be linked to a vehicle.
  • the charging control unit receives such a provisioning certificate with the unique identifier that is linked to the user account of the driver of the vehicle.
  • This provisioning certificate can, for example, be inserted into the charging control unit, and in particular into the cryptographically secured element, before the vehicle is delivered, provided that the user account of the buyer or lessee of the vehicle is known.
  • the provisioning certificate can be inserted into the charging control unit, and in particular into the cryptographically secured element, when the driver logs on to the vehicle for the first time (for example via a user interface of the vehicle or via a mobile application).
  • the provisioning certificate can, for example, be downloaded from a server of the vehicle manufacturer (see, for example, Fig.
  • the certificate can be generated in the cryptographically secured element and transmitted to the server in encrypted form.
  • the key pair of the provisioning certificate can be generated on the charging control unit (within the cryptographically secured element) and the certificates can be created via a certificate signing request (CSR), for example by the intermediary 430 shown in Fig. 4. While the key pair can be created by the charging control unit, the key pair can also be created elsewhere, for example by a cryptographically secured server. This is particularly advantageous if the provisioning certificate is not tied to a vehicle but to a user account. The provisioning certificate can then be transferred to the charging control unit when logging in to a vehicle with the user account.
  • CSR certificate signing request
  • one or more charging contracts based on the cryptographically secured provisioning certificate are now received (i.e. received or read from a memory in the vehicle).
  • These charging contracts (or rather cryptographically secured certificates of the respective charging contracts, i.e. the contracts with a mobility operator or charging infrastructure operator) are also stored in the cryptographically secured element if they are to be used for authentication.
  • one or more charging contracts can be stored in the cryptographically secured element. In the latter case, in addition to the charging contracts, information can also be stored (inside or outside the cryptographically secured element) about which charging contract (or certificate) is to be used for authentication.
  • the certificate of the charging contract is now used to cryptographically secure communication with the charging infrastructure 5 and to identify the charging control unit to the charging infrastructure.
  • This can the charging contracts and the communication with the charging infrastructure are based on the ISO 15118-2 standard. However, the basic principle works with both variants, ISO 15118-2 and ISO 15118-20.
  • the proposed invention can be used advantageously in two scenarios in particular - when a driver who has already concluded one or more charging contracts registers with a new vehicle, and when a vehicle is used by several drivers.
  • a mechanism can now be provided that either keeps provisioning certificates or the associated private keys in the secure storage of the cryptographically secured element for a (limited) number of users, or installs the corresponding private key from an encrypted container from a non-secure storage into the secure storage when the user changes.
  • the private keys of the contract certificates for all users can be stored permanently in the secure storage, or can also be installed from an encrypted container in the vehicle when the user changes, in order to reflect the installation status defined for each user.
  • control circuit can also be designed to receive one or more further provisioning certificates (along with the charging contract(s) based thereon) in addition to the (first) provisioning certificate and to store them in the cryptographically secured element.
  • a second provisioning certificate (along with the second charging contract(s) based thereon).
  • the number of provisioning certificates can depend, for example, on the number of users assigned to the vehicle.
  • the control circuit can thus also be designed to receive at least one second cryptographically secured provisioning certificate, which comprises a second unique identifier that is linked to a user account of a second driver, and one or more second cryptographically secured charging contracts based on the second provisioning certificate.
  • control circuit may be further configured to store the second provisioning certificate and at least one second charging contract of the one or more second charging contracts in the cryptographically secured element and to authenticate the charging control device to the charging infrastructure based on the at least one second charging contract.
  • control circuit can be designed to store the second provisioning certificate and the at least one second charging contract in addition to the provisioning certificate and the at least one charging contract in the cryptographically secured element, and to store a selection of which charging contract is to be used for authentication.
  • an actively used provisioning certificate (and associated charging contract(s)) is stored in the cryptographically secured element, and at least one unused provisioning certificate (and associated charging contract(s)) is stored in encrypted form in another (insecure) memory 18 of the charging control device.
  • the control circuit can be designed to store the provisioning certificate and the at least one charging contract in encrypted form from the cryptographically secured element, and to store the second provisioning certificate and the at least one second charging contract in the cryptographically secured element after they have been stored. In the second case, this is done by storing the provisioning certificate and the at least one charging contract in encrypted form in the further memory 18 of the charging control device, wherein the further memory is arranged outside the cryptographically secured element.
  • provisioning certificate and the at least one charging contract are outsourced (or, later, the second provisioning certificate and at least a second charging contract), this is done in encrypted form.
  • a cryptographic key can be used that is only present within the cryptographically secured element (for example, because the key was generated within the cryptographically secured element).
  • the provisioning certificate and the at least one charging contract can be encrypted using a cryptographic key that is stored within the cryptographically secured element.
  • the respective provisioning certificate and the charging contract or contracts can be encrypted and stored together in a container.
  • the second (or third, fourth, etc.) provisioning certificate and associated charging contract(s) can also be deposited from an insecure memory of the charging control unit or outside the charging control unit (but inside the vehicle).
  • the control circuit can be designed to receive at least the second provisioning certificate and the one or more second charging contracts in encrypted form from a memory inside or outside the charging control unit. These can then be decrypted using the key secured within the cryptographically secured element.
  • the charging controller can be controlled via the user interface controller 20 of the vehicle.
  • the control circuit can be designed to at least obtain and store the second provisioning certificate and the one or more second charging contracts (and/or the provisioning certificate and the one or more charging contracts, and/or a third/fourth provisioning certificate and corresponding charging contracts) in response to a control signal from a user interface controller 20 of the vehicle.
  • This control signal can indicate, for example, that the second provisioning certificate and the one or more second charging contracts are to be obtained (for example by receiving them from a server, or by reading them, in encrypted form, from a memory of the vehicle or the charging controller) and are to be used for authentication instead of the first provisioning certificate and the charging contract. This is explained below with reference to Figs. 2a and 2b.
  • the at least one interface 12 may, for example, correspond to one or more inputs and/or one or more outputs for receiving and/or transmitting information, for example in digital bit values, based on a code, within a module, between modules, or between modules of different entities.
  • control circuit 16 can correspond to any controller or processor or a programmable hardware component.
  • control circuit 16 can also be implemented as software that is programmed for a corresponding hardware component.
  • the control circuit 16 can be programmable hardware with appropriately adapted software. Any processors, such as digital signal processors (DSPs), can be used. Embodiments are not restricted to a specific type of processor. Any processor or even multiple processors can be used for implementation.
  • the control circuit 16 can include the cryptographically secured element 14.
  • the memory 18 of the charging controller and/or the memory 105 of the vehicle can, for example, comprise at least one element of the group of computer-readable storage medium, magnetic storage medium, optical storage medium, hard disk, flash memory, floppy disk, random access memory, programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), and network storage.
  • PROM programmable read only memory
  • EPROM erasable programmable read only memory
  • EEPROM electronically erasable programmable read only memory
  • the vehicle 100 may, for example, correspond to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, an off-road vehicle, a motor vehicle, or a truck.
  • the charging controller, the corresponding method and the computer program may comprise one or more additional optional features corresponding to one or more aspects of the proposed concept or the described examples as described before or after.
  • Fig. 2a shows a schematic diagram of a user interface control device 20 (also called a “head unit”) for a vehicle.
  • the user interface control device 20 comprises at least one interface 22 for communicating with a charging control device 10 (shown in Fig. 1a) of the vehicle and for communicating with a user interface, such as a touch-sensitive screen or a combination of screen and haptic input device), of the vehicle (not shown) or outside the vehicle (such as a user interface of a mobile device of a driver of the vehicle, via a mobile application).
  • the user interface control device comprises a control circuit 24 which is coupled to the at least one interface 22.
  • the control circuit 24 is designed to receive a user input via the user interface.
  • the user input indicates that a driver of the vehicle is logging into the vehicle via his user account.
  • the control circuit 24 is designed to provide a control signal to the charging control device if a unique identifier included in a provisioning certificate on which a charging contract is based which is currently used for authentication to a charging infrastructure is linked to another user account.
  • the control signal indicates that a second provisioning certificate and at least one charging contract based on the second provisioning certificate are to be used for authentication to the charging infrastructure.
  • Fig. 2b shows a flow chart of a corresponding method for the user interface controller 24.
  • the method includes receiving 210 the user input via the user interface.
  • the method includes providing 220 the control signal to the charging controller of the vehicle if the unique identifier included in the provisioning certificate on which the charging contract is based that is currently used for authentication to a charging infrastructure is linked to another user account.
  • the user interface control device the corresponding method and a corresponding computer program are described with reference to the user interface control device.
  • Features that can be described in connection with the user interface control device can also be applied to the corresponding method or computer program.
  • the trigger for storing (or activating) a provisioning certificate together with a charging contract or charging contracts in the cryptographically secured element is a driver/user logging into the vehicle.
  • this procedure should not take place every time a user logs into the vehicle - if the correct provisioning certificate is already installed in the cryptographically secured element and the use of an associated charging contract is activated for authentication, then it is not necessary to control the charging control unit accordingly. Therefore, the control signal is only provided if the charging contract that is currently being used (or is to be used) for authentication to the charging infrastructure is based on a provisioning certificate that is not linked to the user account of the logging in driver/user.
  • the charging controller may provide the user interface controller with metadata about the available or currently used provisioning certificates and charging contracts. If the unique identifiers are different, then the control signal is provided to instruct the charging controller to store the second provisioning certificate and at least one associated charging contract in the cryptographically secured element.
  • the second provisioning certificate contains the unique identifier of the user account of the logging in user.
  • the control circuit can be designed to output a representation of one or more charging contracts via the user interface that are based on the provisioning certificate whose unique identifier is linked to the currently logged in user account.
  • This list can be based on the metadata that the charging controller has provided to the user interface controller.
  • a mechanism in the user management can ensure that a logged in user sees (only) the contract certificates in the user interface that are assigned to the unique identifier (e.g. the PCID) of this user or can only use these.
  • the at least one interface 22 may, for example, correspond to one or more inputs and/or one or more outputs for receiving and/or transmitting information, for example in digital bit values, based on a code, within a module, between modules, or between modules of different entities.
  • control circuit 24 can correspond to any controller or processor or a programmable hardware component.
  • control circuit 24 can also be implemented as software that is programmed for a corresponding hardware component.
  • control circuit 24 can be implemented as programmable hardware with appropriately adapted software.
  • Any processors, such as digital signal processors (DSPs), can be used. Embodiments are not restricted to a specific type of processor. Any processor or even multiple processors are conceivable for implementation.
  • the user interface controller, the corresponding method and the computer program may comprise one or more additional optional features corresponding to one or more aspects of the proposed concept or the described examples as described before or after.
  • a user identifier used by the user account management or user account identifier
  • a unique identifier can be derived (as a PCID) and assigned to this user.
  • a provisioning certificate in accordance with ISO 15118 can now be created for this PCID.
  • the certificate i.e. the public part of it
  • the driver/user can then conclude Plug & Charge-enabled contracts for his PCID.
  • the certificate chain or the private part of the provisioning certificate is now stored in a user-specific encrypted form, for example.
  • the private part of the provisioning certificate or the certificate chain can also be encrypted specifically for the vehicle in a container (e.g. with the vehicle identifier certificate).
  • This container provisioning container
  • This container is stored in a user-specific manner, for example.
  • the provisioning container can be downloaded and the contents stored on the vehicle in accordance with the standard (as described in connection with Figs. 1a to 1b).
  • the contract certificates (charging contracts) requested by the customer, and in particular their private keys, can then be installed in accordance with the standard.
  • the active contract certificate can be selected according to the customer's wishes, as can the activation status of the function itself.
  • This information can be saved for each user.
  • the setting applies, for example, to all vehicles in which the customer is registered. Depending on the available storage in the vehicle, all or a limited number of contract certificates and provisioning certificates can be saved in the vehicle for each user, or deleted and downloaded again when the user changes in the vehicle. When logging into another vehicle of the vehicle manufacturer, the same procedure is followed, starting with the encryption of the provisioning container for this specific vehicle.
  • Plug & Charge enables a fully automated and secure charging experience through the EV-to-charging station authentication technology (according to ISO 15118).
  • Fig. 3 shows a schematic diagram of a technical perspective on Plug & Charge. First (1.) the vehicle manufacturer (OEM in Fig.
  • this provisioning certificate includes a user account-specific unique identifier.
  • the vehicle user then concludes a charging contract with the mobility operator (MO).
  • the vehicle user provides the user account-specific unique identifier (e.g. the PCID, provisioning certificate identifier), which can be done by the vehicle manufacturer, for example.
  • the mobility operator creates a contract certificate (3.) for the specified identifier, which is also provided to the aggregator.
  • the aggregator notifies the OEM (4.) that it has received a contract certificate and optionally forwards it to it (or the contract certificate is retrieved from the OEM as required).
  • Fig. 4 shows a simplified representation of the technical infrastructure for the use of Plug & Charge.
  • Fig. 4 shows a charging control unit 410, which can correspond to the charging control unit 10 of Fig. 1a, a user interface control unit 420, which can correspond to the user interface control unit 20 of Figs. 1a and 1b, an intermediary 430 (which can be used in the vehicle, during production of the vehicle, or when reissuing a provisioning certificate for a new user, even independently of production), a Plug & Charge coordinator 440 (on the part of the vehicle manufacturer), an aggregator 450, a mobility service provider 460, an operator of the charging station 470, and the charging station 480.
  • a charging control unit 410 which can correspond to the charging control unit 10 of Fig. 1a
  • a user interface control unit 420 which can correspond to the user interface control unit 20 of Figs. 1a and 1b
  • an intermediary 430 which can be used in the vehicle, during production of the vehicle, or when reis
  • the charging control unit 410 is designed for communication in accordance with ISO 15118 and is responsible for certificate storage & handling (including diagnostic orders).
  • the intermediary is the root certificate authority of the vehicle manufacturer and provides provisioning certificates.
  • the key pair of the provisioning certificate can be created, for example, in the charging control unit 410 or on a server such as the Plug & Charge coordinator. This is indicated by block 435 in Fig. 4.
  • the intermediary can also receive the certificate signing request from a server, such as the Plug & Charge coordinator 440, for example when creating a user account or when activating the Plug & Charge functionality in the user account.
  • the generation 435 of the key pair can be carried out by the charging control unit 410 or a server, such as the Plug & Charge coordinator 440.
  • a customer signs a charging contract, he or she provides the identification code of the provisioning certificate (i.e. the user account-specific unique identifier) to the mobility service provider 450 as part of the contract.
  • the mobility service provider creates a new contract certificate.
  • the contract certificate can now be encrypted using the provisioning certificate (i.e.
  • the aggregator 450 receives the encrypted contract certificate and informs the Plug & Charge coordinator 440 about it.
  • the coordinator can now receive the contract certificate and make it available to the charging control unit, for example via a telematics connection.
  • the contract certificate can be exchanged via the powerline communication between the charging station 480 and the charging control unit 410. If the charging control unit has a corresponding contract certificate, it can identify itself via a connection that is secured using TLS (Transport Layer Security) communication using the contract certificate.
  • TLS Transport Layer Security
  • the Plug & Charge coordinator 440 in order to be able to offer the installation of the contract certificates. If the installation is initiated, the user interface control unit 420 requests the respective certificates for installation from the Plug & Charge coordinator. These are then passed on to the charging control unit. For example, diagnostic communication and/or status/configuration communication can be used for the communication between the user interface control unit 420 and the charging control unit 410.
  • Examples may further be or relate to a (computer) program having program code for carrying out one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Steps, operations or processes of various of the methods described above may thus also be carried out by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, e.g. digital data storage media, that are machine-, processor- or computer-readable and encode or contain machine-executable, processor-executable or computer-executable programs and instructions.
  • the program storage devices may include or be, for example, digital memories, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives or optically readable digital data storage media.
  • FIG. 1 Further examples may also cover computers, processors, controllers, field-programmable logic arrays ((F)PLAs), field-programmable gate arrays ((F)PGAs), graphics processor units (GPUs), application-specific integrated circuits (ASICs), integrated circuits (ICs), or systems-on-a-chip (SoCs) programmed to perform the steps of the methods described above.
  • FPLAs field-programmable logic arrays
  • FPGAs field-programmable gate arrays
  • GPUs graphics processor units
  • ASICs application-specific integrated circuits
  • ICs integrated circuits
  • SoCs systems-on-a-chip
  • a block, a device or a functional aspect of the device or system can correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in connection with a method are also to be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Power Engineering (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Bioethics (AREA)
  • Medical Informatics (AREA)
  • Charge And Discharge Circuits For Batteries Or The Like (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)

Abstract

Die Erfindung bezieht sich auf ein Ladesteuergerät (10), ein Benutzerschnittstellensteuergerät (20), ein Fahrzeug (100) mit einem Ladesteuergerät (10) und einem Benutzerschnittstellensteuergerät (20), sowie auf entsprechende Verfahren und Computerprogramme. Das Ladesteuergerät (10) umfasst zumindest eine Schnittstelle zur Kommunikation (12) mit einer Ladeinfrastruktur (5). Das Ladesteuergerät (10) umfasst ein kryptografisch gesichertes Element. Das Ladesteuergerät (10) umfasst eine Steuerungsschaltung (16). Die Steuerungsschaltung (16) ist ausgebildet zum Erhalten von einem kryptografisch gesicherten Provisionierungszertifikat. Das kryptografisch gesicherte Provisionierungszertifikat umfasst einen eindeutigen Identifikator. Der eindeutige Identifikator ist mit einem Benutzerkonto eines Fahrers des Fahrzeugs (100) verknüpft. Die Steuerungsschaltung (16) ist ausgebildet zum Erhalten von ein oder mehreren kryptografisch gesicherten Ladekontrakten. Die ein oder mehreren kryptografisch gesicherte Ladekontrakte basieren auf dem kryptografisch gesicherten Provisionierungszertifikat. Die Steuerungsschaltung (16) ist ausgebildet zum Speichern des Provisionierungszertifikats und zumindest eines Ladekontrakts der ein oder mehreren kryptografisch gesicherten Ladekontrakte in dem kryptografisch gesicherten Element (14). Die Steuerungsschaltung (16) ist ausgebildet zum Authentifizieren des Ladesteuergeräts (10) gegenüber der Ladeinfrastruktur basierend auf dem zumindest einen in dem kryptografisch gesicherten Element (14) gespeicherten Ladekontrakt.

Description

Konzept für nutzerspezifische Provisions- und Ladekontraktzertifikate
Technisches Gebiet
Die Erfindung bezieht sich auf ein Ladesteuergerät, ein Benutzerschnittstellensteuergerät, ein Fahrzeug mit einem Ladesteuergerät und einem Benutzerschnittstellensteuergerät, sowie auf entsprechende Verfahren und Computerprogramme.
Hintergrund
Plug & Charge (Einstecken und Laden, ein Ladestandards für das Laden von Elektrofahrzeugen) basiert auf dem Industriestandard ISO 15118. Unter Nutzung von Plug & Charge (P&C im Folgenden) können Fahrer von Elektroautos, etwa batterieelektrischen Autos (auch BEV, Battery Electric Vehicle, genannt) oder Hybridfahrzeugen (auch PHEV, Plug-in Hybrid Electric Vehicle, ein Kraftfahrzeug mit Hybridantrieb, dessen Akku von dem Motor und durch Einstecken („Plug-In“) eines Ladesteckers geladen werden kann), an öffentlichen Ladesäulen nur durch Einstecken des Ladekabels authentifizieren. Die Authentifizierung erfolgt dabei mit einem digitalen Vertragszertifikat gemäß Norm. Das Vertragszertifikat enthält unter anderem die Vertragsnummer. Der Lade Säulenbetreiber (CPO, Charging Point Operator) kann mit dieser Nummer über die bestehenden Roamingplattformen mit dem Vertragsanbieter (EMP oder MO, Electro Mobility Provider / Elektromobilitätsbereitsteller oder Mobility Operator / Mobilitätsoperator, oft derselbe wie der EMP) den Ladevorgang abrechnen oder direkt mit dem Kunden abrechnen (falls CPO gleichzeitig Vertragsanbieter ist). Die Funktionsweise wird im Detail im weiteren Verlauf beschrieben.
Gemäß dem bisherigem Stand der Norm (ISO 15118-2) kann das Fahrzeug der Ladesäule nur ein Zertifikat übermitteln; daher wird in vielen Systemen nur ein Zertifikat auf dem Fahrzeug vorgehalten. Das Zertifikat wird gemäß Norm i.d.R. auf dem Ladegerät gespeichert. Zertifikate können dabei entweder über PLC (Kommunikation über Ladekabel) von der Ladesäule installiert werden oder über eine Backend (d.h. über einen Server) /Telematik-Verbindung. Vertragszertifikate werden in einem gemeinsam genutzten Pool (Sammlung) in Backends/Servem verwaltet. Dabei erfolgt die Erstellung der Zertifikate durch den MO, und der Abruf durch den OEM (Original Equipment Manufacturer, Hersteller der Erstausrüstung), etwa durch den Fahrzeughersteller. Gemäß ISO 15118-2 sind die Vertragszertifikate dabei an ein Fahrzeug gekoppelt, nicht an einen Fahrzeugnutzer. Grundvoraussetzung zur Installation eines Vertragszertifikats ist das sog. Provisioniemngszertifikat, das zu diesem Zweck ebenfalls spezifisch für das Fahrzeug ausgestellt wird und nur einmal vorliegt. Für Provisioniemngszertifikate wie auch für Vertragszertifikate (d.h. die Zertifikate der Ladekontrakte) wird neben der Zertifikatskette (bis zum Wurzelzertifikat) immer auch der zugehörige private/geheime Schlüssel im sicheren Speicher des Fahrzeugs abgelegt. Der sichere Speicher für die privaten Schlüssel ist häufig ein spezielles HSM (Hardware Security Module, Hardware- Sicherheitsmodul), das einen beschränkten Speicher besitzt.
Es ist in modernen Fahrzeugen möglich, dass sich Fahrzeugnutzer mit persönlichen Benutzerkonten am Fahrzeug und weiteren Berührungspunkten (etwa einer mobilen Applikation) anmelden können. Dabei kann es für jedes Fahrzeug einen ausgewiesenen Hauptnutzer und ggf. mehrere Nebennutzer geben.
Es besteht der Bedarf nach einem verbesserten Konzept zur technischen Sicherung eines Ladevorgangs von Elektrofahrzeugen.
Zusammenfassung
Diesem Bedarf wird durch den Gegenstand der unabhängigen Ansprüche Rechnung getragen.
Die vorliegende Erfindung basiert auf der Erkenntnis, dass die Kopplung von Vertragszertifikaten und Provisionierungszertifikat an ein Fahrzeug nicht unabdingbar ist, um die Sicherheit der Ladeauthentifizierung sicherzustellen. Die zuvor genannte Norm schreibt lediglich vor, dass jedes Provisionierungszertifikat einen eindeutige Identifikator, die sog. PCID (Provisioning Certificate Identificator, Provisionierungszertifikatsidentifikator) hat. Dieser Identifikator kann mit der Fahrgestellnummer (auch engl. VIN, Vehicle Identification Number, Fahrzeugidentifizierungsnummer) übereinstimmen (wodurch der Identifikator an das Fahrzeug gekoppelt ist) oder aber individuell gewählt werden (beschränkt im Format durch die Norm), solange sichergestellt ist, dass der Identifikator eindeutig und einzigartig ist. In der vorliegenden Erfindung werden nun Provisionierungszertifikate verwendet, die anstatt mit dem Fahrzeug mit einem Benutzerkonto eines Fahrers (oder genereller „Nutzer“) des Fahrzeugs verknüpft sind. Ein solches Provisionierungszertifikat wird nun, beispielsweise beim Anmelden des Benutzers am Fahrzeug, zusammen mit zumindest einem auf dem Provisionierungszertifikat basierenden Ladekontrakt, in ein kryptografisch gesichertes Element eines Ladesteuergeräts des Fahrzeugs eingebracht und gespeichert, und nachfolgend für die Authentifizierung des Ladesteuergeräts gegenüber einer Ladeinfrastruktur genutzt. Hierdurch kann der Fahrer (oder Nutzer) des Fahrzeugs „seine“ Ladekontrakte in verschiedenen Fahrzeugen nutzen, ohne dass diese Funktionalität explizit von der zuvor genannten ISO-Norm unterstützt werden muss. Ein Aspekt der vorliegenden Offenbarung bezieht sich auf ein Ladesteuergerät für ein Fahrzeug. Das Ladesteuergerät umfasst zumindest eine Schnittstelle zur Kommunikation mit einer Ladeinfrastruktur. Das Ladesteuergerät umfasst ein kryptografisch gesichertes Element. Das Ladesteuergerät umfasst eine Steuerungsschaltung. Die Steuerungsschaltung ist ausgebildet zum Erhalten von einem kryptografisch gesicherten Provisionierungszertifikat. Das kryptografisch gesicherte Provisionierungszertifikat umfasst einen eindeutigen Identifikator. Der eindeutige Identifikator ist mit einem Benutzerkonto eines Fahrers des Fahrzeugs verknüpft. Die Steuerungsschaltung ist ausgebildet zum Erhalten von ein oder mehreren kryptografisch gesicherten Ladekontrakten. Die ein oder mehreren kryptografisch gesicherte Ladekontrakte basieren auf dem kryptografisch gesicherten Provisionierungszertifikat. Die Steuerungsschaltung ist ausgebildet zum Speichern des Provisionierungszertifikats und zumindest eines Ladekontrakts der ein oder mehreren kryptografisch gesicherten Ladekontrakte in dem kryptografisch gesicherten Element. Die Steuerungsschaltung ist ausgebildet zum Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem zumindest einen in dem kryptografisch gesicherten Element gespeicherten Ladekontrakt. Hierdurch kann der Fahrer (oder Nutzer) des Fahrzeugs „seine“ Ladekontrakte in verschiedenen Fahrzeugen nutzen, ohne dass diese Funktionalität explizit von der zuvor genannten ISO-Norm unterstützt werden muss.
Insbesondere kann der eindeutige Identifikator nicht mit dem Fahrzeug verknüpft sein. Dies vereinfacht die Nutzung des Provisionierungszertifikats in mehreren Fahrzeugen.
Beispielsweise kann wobei die Steuerungsschaltung ferner ausgebildet sein, um zumindest ein zweites kryptografisch gesicherte Provisionierungszertifikat, das einen zweiten eindeutigen Identifikator umfasst, der mit einem Benutzerkonto eines zweiten Fahrers verknüpft ist, und ein oder mehrere zweite, auf dem zweiten Provisionierungszertifikat basierende kryptografisch gesicherte Ladekontrakte zu erhalten. Die Steuerungsschaltung kann ausgebildet sein, um das zweite Provisionierungszertifikat und zumindest einen zweiten Ladekontrakt der ein oder mehreren zweiten Ladekontrakte in dem kryptografisch gesicherten Element zu speichern und das Ladesteuergerät gegenüber der Ladeinfrastruktur basierend auf dem zumindest einen zweiten Ladekontrakt zu authentifizieren. Somit kann innerhalb des Fahrzeugs zwischen Ladekontrakten unterschiedlicher Fahrer gewechselt werden, etwa in einem Car-Sharing-Szenario, in einem Firmenflottenszenario, oder bei einer privaten und geschäftlichen Nutzung eines Firmenwagens. Dabei ist das Konzept nicht auf zwei Provisionierungszertifikate beschränkt - die Anzahl der Provisionierungszertifikate ist möglicherweise nur limitiert durch die Anzahl der zum Fahrzeug zugeordneten Nutzer.
Werden mehrere Provisionierungszertifikate genutzt, dann ergeben sich mehrere Möglichkeiten, je nachdem, wie viele Provisionierungszertifikate in dem kryptografisch gesicherten Element, in einem Speicher des Ladesteuergeräts außerhalb des kryptografisch gesicherten Elements oder in einem Speicher außerhalb des Ladesteuergeräts speicherbar sind. Beispielsweise kann die Steuerungsschaltung ausgebildet sein, um das zweite Provisionierungszertifikat und den zumindest einen zweiten Ladekontrakt zusätzlich zu dem Provisionierungszertifikat und dem zumindest einen Ladekontrakt in dem kryptografisch gesicherten Element zu speichern. Zusätzlich kann die Steuerungsschaltung ausgebildet sein, um eine Auswahl darüber zu speichern, welcher Ladekontrakt für die Authentifizierung zu verwenden ist. Dies ermöglicht eine Nutzung der Ladekontrakte mehrere Lahrer, ohne dass hierfür ein Auslagem und Einlagem der jeweiligen Zertifikate beim Wechsel des Lahrers/Nutzers notwendig ist.
Alternativ (oder zusätzlich, je nach Speicherkapazität des kryptografisch gesicherten Elements) kann die Steuerungsschaltung ausgebildet sein, um das Provisionierungszertifikat und den zumindest einen Ladekontrakt verschlüsselt aus dem kryptografisch gesicherten Element auszulagem, und um das zweite Provisionierungszertifikat und den zumindest einen zweiten Ladekontrakt nach dem Auslagem in dem kryptografisch gesicherten Element zu speichern. Durch das verschlüsselte Auslagem kann der notwendige Speicherplatz in dem kryptografisch gesicherten Element zum Speichern des zweiten Provisioniemngszertifikats und zum Speichern des zumindest einen zweiten Ladekontrakts geschaffen werden. Durch Auslagem in verschlüsselter Lorrn kann dabei das Auslagem durchgeführt werden, ohne dass die Sicherheit der Zertifikate beeinträchtigt wird.
Dabei kann das Auslagem auf einen Speicher des Ladesteuergeräts, oder auf einen Speicher außerhalb des Ladesteuergeräts durchgeführt werden. In anderen Worten kann die Steuerungsschaltung ausgebildet sein, um das Provisioniemngszertifikat und den zumindest einen Ladekontrakt verschlüsselt auf einem weiteren Speicher des Ladesteuergeräts zu speichern, wobei der weitere Speicher außerhalb des kryptografisch gesicherten Elements angeordnet ist. Alternativ (oder zusätzlich) kann die Steuemngsschaltung ausgebildet sein, um das Provisioniemngszertifikat und den zumindest einen Ladekontrakt verschlüsselt auf einem weiteren Speicher außerhalb des Ladesteuergeräts zu speichern. Ein Speichern in einem Speicher des Ladesteuergeräts ermöglicht eine einfachere Implementierung ohne Einbeziehung weiterer Geräte, ist jedoch abhängig von dem verfügbaren Speicher. Ein Speichern in einem Speicher außerhalb des Ladesteuergeräts erhöht die Implementiemngskomplexität, ermöglicht jedoch die Nutzung von einem von mehreren Steuergeräten geteilten Speicher im Fahrzeug.
Um die Sicherheit der ausgelagerten Daten zu gewährleisten, kann die Verschlüsselung der Daten an das Ladesteuergerät, und insbesondere an das kryptografisch gesicherte Element gekoppelt werden. Beispielsweise kann das Provisioniemngszertifikat und der zumindest einen Ladekontrakt mittels eines kryptografischen Schlüssels, der innerhalb des kryptografisch gesicherten Elements gespeichert ist, verschlüsselt sein. Dies verbesserte die Sicherheit der Verschlüsselung, da die verschlüsselten Daten auch bei einem Ausbau des Speichers sicher bleiben.
Entsprechend dem Auslagem der Daten in verschlüsselter Form aus dem kryptografisch gesicherten Element können die Daten auch in verschlüsselter Form eingelesen und in dem kryptografisch gesicherten Element entschlüsselt und gespeichert werden. In anderen Worten kann die Steuerungsschaltung ausgebildet sein, um zumindest das zweite Provisionierungszertifikat und die ein oder mehreren zweiten Ladekontrakte in verschlüsselter Form von einem Speicher innerhalb oder außerhalb des Ladesteuergeräts zu erhalten. Hierdurch können die jeweiligen Daten nach einem vorherigen verschlüsselten Auslagem wieder in das kryptografisch gesicherte Element eingelagert werden. Grundsätzlich ist dies, wie bereits oben erwähnt, für eine beliebige Anzahl von Provisionierungszertifikaten und dazugehörigen Ladekontrakten möglich.
Um dem Ladesteuergerät zu signalisieren, dass zukünftig ein anderes Provisionierungszertifikat mit einem entsprechenden Ladekontrakt zu nutzen ist, kann der aktuelle Fahrer sich über eine Benutzerschnittstelle an dem Fahrzeug anmelden. Diese Anmeldung kann dem Ladesteuergerät dann signalisiert werden, woraufhin das entsprechende Provisionierungszertifikat und ein entsprechender Ladekontrakt in dem kryptografisch gesicherten Element gespeichert werden kann. Entsprechend kann die Steuerungsschaltung ausgebildet sein, um zumindest das Erhalten und Speichern des zweiten Provisionierungszertifikats und der ein oder mehreren zweiten Ladekontrakte als Reaktion auf ein Steuersignal eines Benutzerschnittstellensteuergerät des Fahrzeugs durchzuführen.
Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf ein entsprechendes Verfahren für ein Ladesteuergerät für ein Fahrzeug. Das Verfahren umfasst ein Erhalten von einem kryptografisch gesicherten Provisionierungszertifikat, wobei das kryptografisch gesicherte Provisionierungszertifikat einen eindeutigen Identifikator umfasst, wobei der eindeutige Identifikator mit einem Benutzerkonto eines Fahrers des Fahrzeugs verknüpft ist. Das Verfahren umfasst ein Erhalten von ein oder mehreren kryptografisch gesicherten Ladekontrakten, wobei die ein oder mehreren kryptografisch gesicherte Ladekontrakte auf dem kryptografisch gesicherten Provisionierungszertifikat basieren. Das Verfahren umfasst ein Speichern des Provisionierungszertifikats und zumindest eines Ladekontrakts der ein oder mehreren kryptografisch gesicherten Ladekontrakte in einem kryptografisch gesicherten Element des Ladesteuergeräts. Das Verfahren umfasst ein Authentifizieren des Ladesteuergeräts gegenüber einer Ladeinfrastruktur basierend auf dem zumindest einen in dem kryptografisch gesicherten Element gespeicherten Ladekontrakt. Das Verfahren kann beispielsweise von dem Ladesteuergerät ausgeführt werden. Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf ein entsprechendes Programm mit einem Programmcode zum Durchfuhren des Verfahrens für das Ladesteuergerät, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul, einer Steuerungsschaltung oder einer programmierbaren Hardwarekomponente des Ladesteuergeräts ausgeführt wird.
Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf ein Benutzerschnittstellensteuergerät für ein Lahrzeug. Das Benutzerschnittstellensteuergerät umfasst zumindest eine Schnittstelle zur Kommunikation mit einem Ladesteuergerät des Lahrzeugs und zur Kommunikation mit einer Benutzerschnittstelle. Das Benutzerschnittstellensteuergerät umfasst eine Steuerungsschaltung, ausgebildet zum Erhalten einer Benutzereingabe über die Benutzerschnittstelle. Die Benutzereingabe zeigt an, dass sich ein Lahrer des Lahrzeugs über sein Benutzerkonto an dem Fahrzeug anmeldet. Die Steuerungsschaltung ist ausgebildet zum Bereitstellen eines Steuersignals an das Ladesteuergerät, falls ein eindeutiger Identifikator, der in einem Provisionierungszertifikat umfasst ist, auf dem ein Ladekontrakt basiert, der aktuell für die Authentifizierung gegenüber einer Ladeinfrastruktur verwendet ist, mit einem anderen Benutzerkonto verknüpft ist. Das Steuersignal zeigt an, dass ein zweites Provisionierungszertifikat und zumindest ein auf dem zweiten Provisionierungszertifikat basierender Ladekontrakt für die Authentifizierung gegenüber die Ladeinfrastruktur zu verwenden ist. Hierdurch kann dem Ladesteuergerät signalisiert werden, dass zukünftig ein anderes Provisionierungszertifikat mit einem entsprechenden Ladekontrakt zu nutzen ist, etwa bei einem Fahrerwechsel.
Beispielsweise kann die Steuerungsschaltung ausgebildet sein, um eine Darstellung von ein oder mehreren Ladekontrakten über die Benutzerschnittstelle auszugeben, die auf dem Provisionierungszertifikat basieren, dessen eindeutiger Identifikator mit dem aktuell angemeldeten Benutzerkonto verknüpft ist. Dies ermöglicht dem neu angemeldeten Fahrer eine Auswahl eines Ladekontrakts, falls mehrere Ladekontrakte mit dem gleichen Provisionierungszertifikat verknüpft sind.
Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf ein entsprechendes Verfahren für ein Benutzerschnittstellensteuergerät für ein Fahrzeug. Das Verfahren umfasst ein Erhalten einer Benutzereingabe über eine Benutzerschnittstelle. Die Benutzereingabe zeigt, dass sich ein Fahrer des Fahrzeugs über sein Benutzerkonto an dem Fahrzeug anmeldet. Das Verfahren umfasst ein Bereitstellen eines Steuersignals an ein Ladesteuergerät des Fahrzeugs, falls ein eindeutiger Identifikator, der in einem Provisionierungszertifikat umfasst ist, auf dem ein Ladekontrakt basiert, der aktuell für die Authentifizierung gegenüber einer Ladeinfrastruktur verwendet ist, mit einem anderen Benutzerkonto verknüpft ist. Das Steuersignal zeigt an, dass ein zweites Provisionierungszertifikat und zumindest ein auf dem zweiten Provisionierungszertifikat basierender Ladekontrakt für die Authentifizierung gegenüber die Ladeinfrastruktur zu verwenden ist. Das Verfahren kann beispielsweise von dem Benutzerschnittstellensteuergerät ausgeführt werden.
Ein weiterer Aspekt der vorliegenden Offenbarung bezieht sich auf ein entsprechendes Programm mit einem Programmcode zum Durchführen des Verfahrens für das Benutzerschnittstellensteuergerät, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente, etwa des Benutzerschnittstellensteuergeräts, ausgeführt wird.
Figurenkurzbeschreibung
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:
Fig. la zeigt ein schematisches Diagramm eines Ladesteuergeräts;
Fig. 1b zeigt ein Flussdiagramm eines Verfahrens für ein Lade Steuergerät;
Fig. 2a zeigt ein schematisches Diagramm eines Benutzerschnittstellensteuergeräts;
Fig. 2b zeigt ein Flussdiagramm eines Verfahrens für ein Benutzerschnittstellensteuergerät;
Fig. 3 zeigt ein schematisches Diagramm einer technischen Perspektive auf Plug & Charge; und
Fig. 4 zeigt eine vereinfachte Darstellung der technischen Infrastruktur für die Nutzung von Plug & Charge.
Beschreibung
Einige Beispiele werden nun ausführlicher Bezug nehmend auf die beiliegenden Figuren beschrieben. Weitere mögliche Beispiele sind jedoch nicht auf die Merkmale dieser detailliert beschriebenen Ausführungsformen beschränkt. Diese können Modifikationen der Merkmale sowie Entsprechungen und Alternativen zu den Merkmalen aufweisen. Ferner soll die Terminologie, die hierin zum Beschreiben bestimmter Beispiele verwendet wird, nicht einschränkend für weitere mögliche Beispiele sein. Gleiche oder ähnliche Bezugszeichen beziehen sich in der gesamten Beschreibung der Figuren auf gleiche oder ähnliche Elemente beziehungsweise Merkmale, die jeweils identisch oder auch in abgewandelter Form implementiert sein können, während sie die gleiche oder eine ähnliche Funktion bereitstellen. In den Figuren können ferner die Stärken von Linien, Schichten und/oder Bereichen zur Verdeutlichung übertrieben sein.
Wenn zwei Elemente A und B unter Verwendung eines „oder“ kombiniert werden, ist dies so zu verstehen, dass alle möglichen Kombinationen offenbart sind, d. h. nur A, nur B sowie A und B, sofern nicht im Einzelfall ausdrücklich anders definiert. Als alternative Formulierung für die gleichen Kombinationen kann „zumindest eines von A und B“ oder „A und/oder B“ verwendet werden. Das gilt Äquivalent für Kombinationen von mehr als zwei Elementen.
Wenn eine Singularform, z. B. „ein, eine“ und „der, die, das“ verwendet wird und die Verwendung nur eines einzelnen Elements weder explizit noch implizit als verpflichtend definiert ist, können weitere Beispiele auch mehrere Elemente verwenden, um die gleiche Funktion zu implementieren. Wenn eine Funktion im Folgenden als unter Verwendung mehrerer Elemente implementiert beschrieben ist, können weitere Beispiele die gleiche Funktion unter Verwendung eines einzelnen Elements oder einer einzelnen Verarbeitungsentität implementieren. Es versteht sich weiterhin, dass die Begriffe „umfasst“, „umfassend“, „aufweist“ und/oder „aufweisend“ bei deren Gebrauch das Vorhandensein der angegebenen Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Elemente, Komponenten und/oder einer Gruppe derselben beschreiben, dabei aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Elemente, Komponenten und/einer Gruppe derselben ausschließen.
Fig. la zeigt ein schematisches Diagramm eines Ladesteuergeräts 10 für ein Fahrzeug 100, wobei das Ladesteuergerät 10 Teil des Fahrzeugs 100 ist. Das Lade Steuergerät umfasst zumindest eine Schnittstelle 12 zur Kommunikation mit einer Ladeinfrastruktur 5 (etwa einer Ladesäule), etwa über eine Powerline -Kommunikation. In manchen Beispielen umfasst die zumindest eine Schnittstelle 12 eine Schnittstelle zur Kommunikation mit einem Benutzerschnittstellensteuergerät 20 des Fahrzeugs 100, zumindest eine Schnittstelle zur Kommunikation mit einem Server (nicht gezeigt), etwa über eine Telematikverbindung/Mobilfunkverbindung, und/oder eine Schnittstelle zur Kommunikation mit einem Speicher 105 des Fahrzeugs. Das Ladesteuergerät 10 umfasst ein kryptografisch gesichertes Element 14, etwa ein sogenanntes „Secure Element“ oder „Trusted Execution Environment“ (Ausführungsumgebung, der vertraut wird). Das Ladesteuergerät 10 umfasst eine Steuerungsschaltung 16, die mit dem kryptografisch gesicherten Element 14 und der zumindest einen Schnittstelle 12 gekoppelt ist. Beispielsweise kann das kryptografisch gesicherte Element ein Teil der Steuerungsschaltung 16 sein oder ein separates Bauteil sein. Optional umfasst das Lade Steuergerät 18 ferner einen Speicher 18, der mit der Steuerungsschaltung 16 gekoppelt ist.
Die Steuerungsschaltung 16 ist ausgebildet zum Erhalten von einem kryptografisch gesicherten Provisionierungszertifikat. Das kryptografisch gesicherte Provisionierungszertifikat umfasst einen eindeutigen Identifikator. Der eindeutige Identifikator ist mit einem Benutzerkonto eines Fahrers des Fahrzeugs verknüpft. Dabei ist, im Zusammenhang der vorliegenden Offenbarung, ein Fahrer des Fahrzeugs nicht notwendigerweise derjenige, der das Fahrzeug steuert. Ist das Fahrzeug ein autonomes Fahrzeug, ist der Fahrer derjenige, der das Fahrzeug zur Fortbewegung nutzt und/oder das Ziel des autonomen Fahrzeugs vorgibt. Die Steuerungsschaltung 16 ist ausgebildet zum Erhalten von ein oder mehreren kryptografisch gesicherten Ladekontrakten. Die ein oder mehreren kryptografisch gesicherte Ladekontrakte basieren auf dem kryptografisch gesicherten Provisionierungszertifikat. Die Steuerungsschaltung 16 ist ausgebildet zum Speichern des Provisionierungszertifikats und zumindest eines Ladekontrakts der ein oder mehreren kryptografisch gesicherten Ladekontrakte in dem kryptografisch gesicherten Element. Die Steuerungsschaltung 16 ist ausgebildet zum Authentifizieren des Lade Steuergeräts gegenüber der Ladeinfrastruktur basierend auf dem zumindest einen in dem kryptografisch gesicherten Element gespeicherten Ladekontrakt.
Fig. 1b zeigt ein Flussdiagramm eines entsprechenden Verfahrens für das Ladesteuergerät 10. Das Verfahren umfasst ein Erhalten 110 des kryptografisch gesicherten Provisionierungszertifikats. Das Verfahren umfasst ein Erhalten 120 des einen oder der mehreren kryptografisch gesicherten Ladekontrakte. Das Verfahren umfasst ein Speichern 130 des Provisionierungszertifikats und des zumindest eines Ladekontrakts der ein oder mehreren kryptografisch gesicherten Ladekontrakte in dem kryptografisch gesicherten Element 14 des Ladesteuergeräts. Das Verfahren umfasst ein Authentifizieren 140 des Ladesteuergeräts 10 gegenüber der Ladeinfrastruktur 5 basierend auf dem zumindest einen in dem kryptografisch gesicherten Element gespeicherten Ladekontrakt.
Im Folgenden wird das Lade Steuergerät, das entsprechende Verfahren sowie ein entsprechendes Computerprogramm mit Bezug auf das Ladesteuergerät beschrieben. Merkmale, die im Zusammenhang mit dem Ladesteuergerät beschrieben werden können, gleichfalls auf das entsprechende Verfahren oder Computerprogramm angewandt werden.
In der Ladekommunikation gemäß Plug & Charge -Standard werden Provisionierungszertifikate genutzt, um zu verhindern, dass Ladekontrakte (auch Vertragszertifikate genannt) missbraucht werden. Dabei umfasst das Provisionierungszertifikat einen öffentlichen Teil (d.h. öffentlichen Schlüssel) und einen privaten Teil (d.h. privaten Schlüssel). Der private Teil des Provisionierungszertifikats wird dabei, bei Benutzung, im kryptografisch gesicherten Element 14 vorgehalten, und ein öffentlicher Teil des Provisionierungszertifikats wird, wie in Fig. 4 dargestellt, den übrigen Teilnehmern bereitgestellt, etwa über ein oder mehrere Aggregatoren. Der öffentliche Teil kann nun genutzt werden, um die kryptografisch gesicherten Ladekontrakte zu verschlüsseln oder ihre Nutzung einzuschränken, so dass sie nur unter Nutzung des privaten Teils des Provisionierungszertifikat genutzt werden können, wobei die Inbetriebnahme innerhalb des kryptografisch gesicherten Elements geschieht. Neben dem privaten Schlüssel des Provisionierungszertifikats, und einem oder mehreren privaten Schlüsseln von Vertragszertifikaten/Ladekontrakten kann auch jeweils die Zertifikatskette (bis zum Wurzeizertifikat in dem kryptografisch gesicherten Element abgelegt werden. Dies wird jedoch meist aus unterlassen, um Speicherplatz zu sparen.
Das vorgeschlagene Konzept basiert nun auf der Erkenntnis, dass, wenn ein Provisionierungszertifikat an ein Fahrzeug gebunden ist, ein Nutzer zwar einen persönlichen Ladevertrag abschließen kann (etwa über einen dritten Fahrstromanbieter), beim Wechsel des Fahrzeugs aber durch den Fahrstromanbieter ein neues Zertifikat (des Ladekontrakts) ausgestellt werden muss, da dieses Fahrzeug ein anderes Provisionierungszertifikat/PCID besitzt. Beim Kunden sowie dem Vertragsanbieter entsteht Aufwand. Zudem versucht jeder Erstellung eines Zertifikats dem Fahrstromanbieter Kosten, die der Kunde direkt oder indirekt zu bezahlen hat. Die Beschränkung des Provisionierungszertifikats/PCID auf die Zuordnung zu genau einem Fahrzeug ermöglicht es zudem nicht, dass beispielsweise Nebennutzer einen Vertrag exklusiv für sich nutzen können bzw. dass ein Vertrag immer allen Nutzem des Fahrzeugs zur Verfügung steht. Ebenso ermöglicht diese Einschränkung nicht, dass ein temporärer Nutzer seinen persönlichen Plug & Charge Vertrag etwa in ein Mietfahrzeug mitnimmt.
In der vorliegenden Erfindung wird anstelle einer 1 : 1 -Beziehung zwischen Fahrzeug zu PCID/ Provisionierungszertifikat das Provisionierungszertifikat bzw. die PCID einmal pro Benutzerkontenidentifikator (des persönlichen Benutzerkontos) ausgestellt. Da die Norm nicht zwangsläufig die Nutzung der Fahrgestellnummer voraussetzt kann dieser Identifikator insofern frei gewählt werden, dass sie eindeutig pro Benutzerkonto ist.
Daher umfasst das kryptografisch gesicherte Provisionierungszertifikat einen eindeutigen Identifikator, der mit einem Benutzerkonto eines Fahrers des Fahrzeugs verknüpft ist, etwa den zuvor genannten Benutzerkontenidentifikator. Der Identifikator ist eindeutig, d.h. er ist eindeutig mit einem Benutzerkonto verknüpft, so dass kein zweites Benutzerkonto (oder kein Fahrzeug) den gleichen Identifikator nutzen kann. Beispielsweise kann der Identifikator einen Präfix umfassen, der ausschließlich von einem Fahrzeughersteller verwendet wird, und eine weitere Komponente, die unter den Benutzerkonten des Fahrzeugherstellers eindeutig ist. Insbesondere kann der Identifikator jedoch unabhängig von einem Identifikator, etwa einer Fahrgestellnummer, des Fahrzeugs sein. Folglich kann der eindeutige Identifikator nicht mit einem Fahrzeug verknüpft sein.
Das Ladesteuergerät erhält ein solches Provisionierungszertifikat mit dem eindeutigen Identifikator, der mit dem Benutzerkonto des Fahrers des Fahrzeugs verknüpft ist. Dieses Provisionierungszertifikat kann beispielsweise vor Auslieferung des Fahrzeugs in das Ladesteuergerät, und insbesondere in das kryptografisch gesicherte Element, eingebracht werden, sofern das Benutzerkonto des Käufers oder Leasingnehmers des Fahrzeugs bekannt ist. Alternativ kann das Provisionierungszertifikat bei der ersten Anmeldung des Fahrers an dem Fahrzeug (etwa über eine Benutzerschnittstelle des Fahrzeugs oder über eine mobile Applikation) in das Ladesteuergerät, und insbesondere in das kryptografisch gesicherte Element, eingebracht werden. Dazu kann das Provisionierungszertifikat beispielsweise von einem Server des Fahrzeugherstellers heruntergeladen werden (siehe etwa in Fig. 4, wo das Zertifikat von dem Intermediär 430 heruntergeladen wird), oder aber in dem kryptografisch gesicherten Element erzeugt werden und, in verschlüsselter Form, an dem Server übermittelt werden. Beispielsweise kann das Schlüsselpaar des Provisionierungszertifikat auf dem Ladesteuergerät (innerhalb des kryptografisch gesicherten Elements) erzeugt werden und die Zertifikate über eine Zertifikatssignierungsanfrage (CSR, Certificate Signing Request), etwa durch den in Fig. 4 gezeigten Intermediär 430 erstellt werden. Während die Erstellung des Schlüsselpaars durch das Lade Steuergerät stattfinden kann, ist die Erstellung des Schlüsselpaars auch an anderer Stelle möglich, etwa durch einen kryptografisch gesicherten Server. Dies ist insbesondere dann Vorteilhaft, wenn das Provisionierungszertifikat nicht an ein Fahrzeug, sondern an ein Benutzerkonto gebunden sind. Hernach kann das Provisionierungszertifikat bei Anmeldung mit dem Benutzerkonto an einem Fahrzeug in das Ladesteuergerät übernommen werden.
Zusätzlich zu dem Provisionierungszertifikat werden nun die ein oder mehreren Ladekontrakte, die auf dem kryptografisch gesicherten Provisionierungszertifikat basieren, erhalten (d.h. empfangen oder von einem Speicher des Fahrzeugs ausgelesen). Diese Ladekontrakte (oder vielmehr kryptografisch gesicherte Zertifikate der jeweiligen Ladekontrakte, also der Verträge mit einem Mobilitätsoperator oder Ladeinfrastrukturbetreiber) werden, wenn sie zur Authentifizierung genutzt werden sollen, ebenfalls in dem kryptografisch gesicherten Element gespeichert. Dabei kann, je nach verfügbarem Speicherplatz, ein Ladekontrakt oder auch mehrere Ladekontrakte in dem kryptografisch gesicherten Element gespeichert werden. In letzterem Fall kann zusätzlich zu den Ladekontrakten noch eine Information darüber gespeichert werden (innerhalb oder außerhalb des kryptografisch gesicherten Elements), welcher Ladekontrakt (bzw. Zertifikat) zur Authentifizierung genutzt werden soll. Während der Authentifizierung des Ladesteuergeräts wird nun zumindest das Zertifikat des Ladekontrakts genutzt, um die Kommunikation mit der Ladeinfrastruktur 5 kryptografisch abzusichem und das Ladesteuergerät gegenüber der Ladeinfrastruktur zu identifizieren. Dabei können die Ladekontrakte und die Kommunikation mit der Ladeinfrastruktur auf dem Standard ISO 15118-2, basieren. Das Grundprinzip funktioniert jedoch mit beiden Varianten, ISO 15118-2 und ISO 15118-20.
Die vorgeschlagene Erfindung ist insbesondere in zwei Szenarien vorteilhaft einsetzbar - wenn sich ein Fahrer, der bereits ein oder mehrere Ladekontrakte abgeschlossen hat an einem neuen Fahrzeug anmeldet, und aber wenn ein Fahrzeug von mehreren Fahrern genutzt wird. Insbesondere für den letzteren Fall kann nun ein Mechanismus bereitgestellt werden, der entweder für eine (beschränkte) Zahl von Nutzers Provisionierungszertifikate bzw. die zugehörigen privaten Schlüssel im sicheren Speicher des kryptografisch gesicherten Elements vorhält oder bei einem Nutzerwechsel den entsprechenden privaten Schlüssel aus einem verschlüsselten Container von einem nicht-sicheren Speicher in den sicheren Speicher installiert. Zudem können, abhängig von der Verfügbarkeit von sicherem Speicher im Fahrzeug, die privaten Schlüssel der Vertragszertifikate für alle Nutzer gesammelt im sicheren Speicher dauerhaft abgelegt werden, oder ebenfalls beim Nutzerwechsel im Fahrzeug aus einem verschlüsseltem Container installiert werden, um den jeweils für einen Nutzer definierten Installationsstatus abzubilden.
Dazu kann die Steuerungsschaltung ferner ausgebildet sein, um neben dem (ersten) Provisionierungszertifikat auch ein oder mehrere weitere Provisionierungszertifikate (nebst darauf basierendem/n Ladekontrakt/en) zu erhalten und in dem kryptografisch gesicherten Element zu speichern. Im Folgenden ist die Rede von einem zweiten Provisionierungszertifikat (nebst darauf basierendem zweiten Ladekontrakten oder darauf basierenden zweiten Ladekontrakten). Grundsätzlich sind jedoch auch mehr als zwei Ladekontrakte möglich. Die Anzahl Provisionierungszertifikate kann beispielsweise von der Anzahl der zum Fahrzeug zugeordneten Nutzer abhängen. Somit kann die Steuerungsschaltung ferner ausgebildet sein, um zumindest ein zweites kryptografisch gesicherte Provisionierungszertifikat, das einen zweiten eindeutigen Identifikator umfasst, der mit einem Benutzerkonto eines zweiten Fahrers verknüpft ist, und ein oder mehrere zweite, auf dem zweiten Provisionierungszertifikat basierende kryptografisch gesicherte Ladekontrakte zu erhalten. Diese können nun in dem kryptografisch gesicherten Element gespeichert werden, und, alternativ zu dem ersten Provisionierungszertifikat und dazugehörigen Ladekontrakt, zur Authentifizierung verwendet werden. Folglich kann die Steuerungsschaltung ferner ausgebildet sein, um das zweite Provisionierungszertifikat und zumindest einen zweiten Ladekontrakt der ein oder mehreren zweiten Ladekontrakte in dem kryptografisch gesicherten Element zu speichern und das Ladesteuergerät gegenüber der Ladeinfrastruktur basierend auf dem zumindest einen zweiten Ladekontrakt zu authentifizieren.
Im Folgenden wird nun zwischen drei Fällen unterschieden - in dem ersten Fall werden mehrere Provisionierungszertifikate (und dazugehörige Ladekontrakt(e)) in dem kryptografisch gesicherten Element gespeichert. Entsprechend kann die Steuerungsschaltung ausgebildet sein, um das zweite Provisionierungszertifikat und den zumindest einen zweiten Ladekontrakt zusätzlich zu dem Provisionierungszertifikat und dem zumindest einen Ladekontrakt in dem kryptografisch gesicherten Element zu speichern, und um eine Auswahl darüber zu speichern, welcher Ladekontrakt für die Authentifizierung zu verwenden ist.
In dem zweiten Fall wird ein aktiv genutztes Provisionierungszertifikat (und dazugehörige Ladekontrakt(e)) in dem kryptografisch gesicherten Element gespeichert, und zumindest ein nicht genutztes Provisionierungszertifikat (und dazugehörige Ladekontrakt(e)) wird verschlüsselt in einen anderen (unsicheren) Speicher 18 des Ladesteuergeräts ausgelagert. In anderen Worten kann die Steuerungsschaltung ausgebildet sein, um das Provisionierungszertifikat und den zumindest einen Ladekontrakt verschlüsselt aus dem kryptografisch gesicherten Element auszulagem, und um das zweite Provisionierungszertifikat und den zumindest einen zweiten Ladekontrakt nach dem Auslagem in dem kryptografisch gesicherten Element zu speichern. In dem zweiten Fall geschieht dies durch Speichern des Provisionierungszertifikat und des zumindest einen Ladekontrakts in verschlüsselter Form auf dem weiteren Speicher 18 des Ladesteuergeräts, wobei der weitere Speicher außerhalb des kryptografisch gesicherten Elements angeordnet ist.
In dem dritten Fall wird ein aktiv genutztes Provisionierungszertifikat (und dazugehörige Ladekontrakt(e)) in dem kryptografisch gesicherten Element gespeichert, und zumindest ein nicht genutztes Provisionierungszertifikat (und dazugehörige Ladekontrakt(e)) wird verschlüsselt in einen anderen (unsicheren) Speicher 105 des Fahrzeugs ausgelagert. In dem dritten Fall geschieht dies, analog zum zweiten Fall, durch Speichern des Provisionierungszertifikat und des zumindest einen Ladekontrakts in verschlüsselter Form auf einem weiteren Speicher 105 außerhalb des Ladesteuergeräts. Jedoch sind auch Mischfälle zwischen den drei zuvor genannten Fällen möglich, etwa abhängig von der Speicherkapazität des kryptografisch gesicherten Elements bzw. des Speichers 18 des Ladesteuergeräts.
Wird das Provisionierungszertifikat und der zumindest eine Ladekontrakt ausgelagert (oder, später, das zweite Provisionierungszertifikat und zumindest ein zweiter Ladekontrakt), dann geschieht dies in verschlüsselter Form. Dazu kann ein kryptografischer Schlüssel verwendet werden, der nur innerhalb des kryptografisch gesicherten Elements vorliegt (etwa, weil der Schlüssel innerhalb des kryptografisch gesicherten Elements erzeugt wurde). Somit kann das Provisionierungszertifikat und der zumindest einen Ladekontrakt mittels eines kryptografischen Schlüssels, der innerhalb des kryptografisch gesicherten Elements gespeichert ist, verschlüsselt sein. Beispielsweise kann das jeweilige Provisionierungszertifikat und der Ladekontrakt oder die Ladekontrakte zusammen in einem Container verschlüsselt werden und gespeichert werden. Analog zum Auslagem des Provisionierungszertifikats und des zumindest einen Ladekontrakts kann auch das Einlagem des zweiten (oder dritten, vierten etc.) Provisionierungszertifikats und dazugehörigem Ladekontrakt(en) von einem unsicheren Speicher des Ladesteuergeräts oder außerhalb des Lade Steuergeräts (jedoch innerhalb des Fahrzeugs) geschehen. Beispielsweise kann die Steuerungsschaltung ausgebildet sein, um zumindest das zweite Provisionierungszertifikat und die ein oder mehreren zweiten Ladekontrakte in verschlüsselter Form von einem Speicher innerhalb oder außerhalb des Ladesteuergeräts zu erhalten. Diese können dann mit Hilfe des innerhalb des kryptografisch gesicherten Elements gesicherten Schlüssels entschlüsselt werden.
Um den Vorgang zu steuern, kann das Ladesteuergerät, über das Benutzerschnittstellensteuergerät 20 des Fahrzeugs, gesteuert werden. Beispielsweise kann die Steuerungsschaltung ausgebildet sein, um zumindest das Erhalten und Speichern des zweiten Provisionierungszertifikats und der ein oder mehreren zweiten Ladekontrakte (und/oder des Provisionierungszertifikats und der ein oder mehreren Ladekontrakte, und/oder eines dritten/vierten Provisionierungszertifikats und entsprechender Ladekontrakte) als Reaktion auf ein Steuersignal eines Benutzerschnittstellensteuergerät 20 des Fahrzeugs durchzuführen. Dieses Steuersignal kann beispielsweise anzeigen, dass das zweite Provisionierungszertifikat und die ein oder mehreren zweiten Ladekontrakte zu erhalten sind (etwa durch Empfangen von einem Server, oder durch Auslesen, in verschlüsselter Form, von einem Speicher des Fahrzeugs oder des Lade Steuergeräts) und anstelle des ersten Provisionierungszertifikats und des Ladekontrakts zur Authentifizierung zu verwenden sind. Dies wird im Folgenden mit Bezug auf die Fign. 2a und 2b erläutert.
In der vorhergehenden Beschreibung wurde angenommen, dass jeder Fahrer den- oder diejenigen Ladekontrakt(e) nutzt, die mit seinem Benutzerkonto verknüpft sind. Sofern ausreichend sicherer Speicher verfügbar ist, kann ein Nutzer jedoch auch entscheiden, dass sein Vertrag, abweichend vom vorherigen Punkt, auch für andere Fahrer/Nutzer nutzbar ist.
Die zumindest eine Schnittstelle 12 kann beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten.
In Ausführungsbeispielen kann die Steuerungsschaltung 16 einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Steuerungsschaltung 16 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern kann die Steuerungsschaltung 16 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung denkbar. In manchen Beispielen kann die Steuerungsschaltung 16 das kryptografisch gesicherte Element 14 umfassen.
Der Speicher 18 des Ladesteuergeräts und/oder der Speicher 105 des Fahrzeugs kann beispielsweise zumindest ein Element der Gruppe von computerlesbares Speichermedium, magnetisches Speichermedium, optisches Speichermedium, Festplatte, Flash-Speicher, Diskette, Zufallszugriffsspeicher (auch engl. Random Access Memory), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), Electronically Erasable Programmable Read Only Memory (EEPROM), und Netzwerkspeicher umfassen.
Das Fahrzeug 100 kann beispielsweise einem Landfahrzeug, einem Wasserfahrzeug, einem Luftfahrzeug, einem Schienenfahrzeug, einem Straßenfahrzeug, einem Auto, einem Geländefahrzeug, einem Kraftfahrzeug, oder einem Lastkraftfahrzeug entsprechen.
Mehr Details und Aspekte des Ladesteuergeräts, des entsprechenden Verfahrens und des Computerprogramms werden in Verbindung mit dem Konzept oder Beispielen genannt, die nachher (z.B. Fig. 2a bis 4) beschrieben werden. Das Ladesteuergerät, des entsprechenden Verfahren und das Computerprogramm kann ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben werden.
Fig. 2a zeigt ein schematisches Diagramm eines Benutzerschnittstellensteuergeräts 20 (auch „Head Unit“, Kopfeinheit, genannt) für ein Fahrzeug. Das Benutzerschnittstellensteuergerät 20 umfasst zumindest eine Schnittstelle 22 zur Kommunikation mit einem Ladesteuergerät 10 (in Fig. la gezeigt) des Fahrzeugs und zur Kommunikation mit einer Benutzerschnittstelle, etwa eines berührungsempfmdlichen Bildschirms oder einer Kombination aus Bildschirm und haptischem Eingabegerät), des Fahrzeugs (nicht gezeigt) oder außerhalb des Fahrzeugs (etwa eine Benutzerschnittstelle eines Mobilgeräts eines Fahrers des Fahrzeugs, über eine mobile Applikation). Das Benutzerschnittstellensteuergerät umfasst eine Steuerungsschaltung 24, die mit der zumindest einen Schnittstelle 22 gekoppelt ist. Die Steuerungsschaltung 24 ist ausgebildet zum Erhalten einer Benutzereingabe über die Benutzerschnittstelle. Die Benutzereingabe zeigt an, dass sich ein Fahrer des Fahrzeugs über sein Benutzerkonto an dem Fahrzeug anmeldet. Die Steuerungsschaltung 24 ist ausgebildet zum Bereitstellen eines Steuersignals an das Ladesteuergerät, falls ein eindeutiger Identifikator, der in einem Provisionierungszertifikat umfasst ist, auf dem ein Ladekontrakt basiert, der aktuell für die Authentifizierung gegenüber einer Ladeinfrastruktur verwendet ist, mit einem anderen Benutzerkonto verknüpf ist. Das Steuersignal zeigt an, dass ein zweites Provisionierungszertifikat und zumindest ein auf dem zweiten Provisionierungszertifikat basierender Ladekontrakt für die Authentifizierung gegenüber die Ladeinfrastruktur zu verwenden ist.
Fig. 2b zeigt ein Flussdiagramm eines entsprechenden Verfahrens für das Benutzerschnittstellensteuergerät 24. Das Verfahren umfasst ein Erhalten 210 der Benutzereingabe über die Benutzerschnittstelle. Das Verfahren umfasst ein Bereitstellen 220 des Steuersignals an das Ladesteuergerät des Fahrzeugs, falls der eindeutige Identifikator, der in dem Provisionierungszertifikat umfasst ist, auf dem der Ladekontrakt basiert, der aktuell für die Authentifizierung gegenüber einer Ladeinfrastruktur verwendet wird, mit einem anderen Benutzerkonto verknüpft ist.
Im Folgenden wird das Benutzerschnittstellensteuergerät, das entsprechende Verfahren sowie ein entsprechendes Computerprogramm mit Bezug auf das Benutzerschnittstellensteuergerät beschrieben. Merkmale, die im Zusammenhang mit dem Benutzerschnittstellensteuergerät beschrieben werden können, gleichfalls auf das entsprechende Verfahren oder Computerprogramm angewandt werden.
Wie im Zusammenhang mit den Fign. la und 1b bereits erläutert wurde, ist der Auslöser dafür, ein Provisionierungszertifikat nebst Ladekontrakt oder Ladekontrakten in das kryptografisch gesicherte Element zu speichern (oder zu aktivieren) eine Anmeldung eines Fahrers/Nutzers an dem Fahrzeug. Jedoch soll diese Prozedur nicht bei jeder Anmeldung eines Nutzers im Fahrzeug stattfinden - ist bereits das korrekte Provisionierungszertifikat im kryptografisch gesicherten Element installiert und die Nutzung eines dazugehörigen Ladekontrakts zur Authentifizierung aktiviert, dann ist es nicht notwendig, das Ladesteuergerät dementsprechend zu steuern. Daher wird das Steuersignal lediglich dann bereitgestellt, falls der Ladekontrakt, der aktuell für die Authentifizierung gegenüber der Ladeinfrastruktur verwendet wird (bzw. werden soll), auf einem Provisionierungszertifikat basiert, das nicht mit dem Benutzerkonto des sich anmeldenden Fahrers/Benutzers verknüpft ist. Dies geschieht durch Vergleichen des eindeutigen Identifikators des Benutzerkontos des sich anmeldenden Benutzers mit dem eindeutigen Identifikator, der in dem Provisionierungszertifikat benutzt wird, auf dem der aktuell zur Authentifizierung genutzte Ladekontrakt basiert. Um diesen Vergleich durchzuführen, kann das Lade Steuergerät dem Benutzerschnittstellensteuergerät Metadaten über die verfügbaren bzw. aktuell genutzten Provisionierungszertifikate und Ladekontrakte bereitstellen. Sind die eindeutigen Identifikatoren verschieden, dann wird das Steuersignal bereitgestellt, um das Ladesteuergerät zu instruieren, um das zweite Provisionierungszertifikat und zumindest ein dazugehöriger Ladekontrakt in dem kryptografisch gesicherten Element zu speichern. Dabei umfasst das zweite Provisionierungszertifikat den eindeutigen Identifikator des Benutzerkontos des sich anmeldenden Benutzers.
Ist der Benutzer/Fahrer angemeldet, so kann ihm eine Liste der verfügbaren Ladekontrakte angezeigt werden. Beispielsweise kann die Steuerungsschaltung ausgebildet sein, um eine Darstellung von ein oder mehreren Ladekontrakten über die Benutzerschnittstelle auszugeben, die auf dem Provisionierungszertifikat basieren, dessen eindeutiger Identifikator mit dem aktuell angemeldeten Benutzerkonto verknüpft ist. Diese Liste kann auf den Metadaten basieren, die das Ladesteuergerät dem Benutzerschnittstellensteuergerät bereitgestellt hat. Somit kann, abhängig von dem möglichen Speicherszenario, ein Mechanismus in der Nutzerverwaltung sicherstellen, dass ein angemeldeter Nutzer (nur) die Vertragszertifikate in der Benutzeroberfläche sieht, die dem eindeutigen Identifikator (etwa der PCID) dieses Nutzers zugeordnet sind bzw. nur diese nutzen kann.
Die zumindest eine Schnittstelle 22 kann beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten.
In Ausführungsbeispielen kann die Steuerungsschaltung 24 einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Steuerungsschaltung 24 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern kann die Steuerungsschaltung 24 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung denkbar.
Mehr Details und Aspekte des Benutzerschnittstellensteuergeräts, des entsprechenden Verfahrens und des Computerprogramms werden in Verbindung mit dem Konzept oder Beispielen genannt, die nachher (z.B. Fig. la bis 1b, 3 bis 4) beschrieben werden. Das Benutzerschnittstellensteuergerät, des entsprechenden Verfahren und das Computerprogramm kann ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben werden.
Im Folgenden wird beispielhaft ein möglicher Prozessfluss dargestellt, angefangen vom Anlegen eines Benutzerkontos. Beim Erstellen eines Benutzerkontos eines Fahrers bei einem Fahrzeughersteller kann beispielsweise von einem von der Benutzerkontoverwaltung verwendeten Benutzeridentifikator (oder Benutzerkontenidentifikator) ein eindeutiger Identifikator abgeleitet werden (als PCID) und diesem Nutzer zugeordnet werden. Für diese PCID kann nun ein Provisionierungszertifikat nach ISO 15118 erstellt werden. Das Zertifikat (d.h. der öffentliche Teil davon) wird bei relevanten externen Provisionierungszertifikatssammelstellen abgelegt. Nachfolgend kann der Fahrer/Nutzer Plug & Charge-fähige Verträge für seine PCID abschließen. Die Zertifikatskette bzw. der private Teil des Provisionierungszertifikats werden nun beispielsweise benutzerspezifisch verschlüsselt abgelegt. Wenn ein Plug & Charge-fähiges Fahrzeug dem Benutzerkonto hinzugefügt wird, kann der private Teil des Provisionierungszertifikats bzw. die Zertifikatskette zusätzlich spezifisch für das Fahrzeug in einem Container (z.B. mit dem Fahrzeug-Identifikator-Zertifikat) verschlüsselt werden. Dieser Container (Provisionierungscontainer)wird beispielsweise benutzerspezifisch abgelegt. Beim Anmelden im Fahrzeug durch den Nutzer (als aktueller Fahrzeugnutzer) kann der Provisionierungscontainer heruntergeladen und die Inhalte normkonform auf dem Fahrzeug abgelegt werden (wie im Zusammenhang mit den Fign. la bis 1b beschrieben). Im Anschluss können die vom Kunden gewünschten Vertragszertifikate (Ladekontrakte), und insbesondere die privaten Schlüssel davon, normkonform installiert werden. Das aktive Vertragszertifikat kann nach Kundenwunsch ausgewählt werden, ebenso wie der Aktivierungsstatus der Funktion an sich. Diese Information kann nutzerspezifisch gespeichert werden. Die Einstellung gilt beispielsweise für alle Fahrzeuge in der der Kunde angemeldet ist. Abhängig vom verfügbaren Speicher im Fahrzeug können alle bzw. eine beschränkte Menge an Vertragszertifikaten und Provisionierungszertifikaten im Fahrzeug je Nutzer gespeichert oder beim Nutzerwechsel im Fahrzeug gelöscht und erneut heruntergeladen werden. Mit der Anmeldung in einem anderen Fahrzeug des Fahrzeugherstellers erfolgt die selbe Prozedur ab der Verschlüsselung des Provisionierungscontainers für dieses spezifische Fahrzeug.
Im Folgenden wird ein kurzer Überblick zu dem Mechanismen von Plug & Charge, wie sie in der vorliegenden Erfindung genutzt werden, zum weiteren Verständnis gegeben. Plug & Charge ermöglicht ein vollautomatisches und sicheres Ladeerlebnis durch die Authentifizierungstechnologie von EV zu Ladestation (gemäß ISO 15118). Fig. 3 zeigt ein schematisches Diagramm einer technischen Perspektive auf Plug & Charge. Zuerst (1.) stellt der Fahrzeughersteller (als OEM in Fig.
4 dargestellt) ein Provisionierungszertifikat einem Aggregator bereit. Dieses Provisionierungszertifikat umfasst im vorliegenden Fall einen Benutzerkonto-spezifischen eindeutigen Identifikator. Dann schließt der Fahrzeugnutzer einen Ladekontrakt mit dem Mobilitätsoperator (MO) ab. Im Rahmen des Abschlusses des Ladekontrakts teilt der Fahrzeugnutzer den Benutzerkonto-spezifischen eindeutigen Identifikator (etwa die PCID, Provisionierungszertifikats-Identifikator) mit, was etwa durch den Fahrzeughersteller geschehen kann. Der Mobilitätsoperator erstellt ein Kontrakt-Zertifikat (3.) für den angegebenen Identifikator, das ebenfalls dem Aggregator bereitgestellt wird. Der Aggregator benachrichtigt den OEM (4.), dass er ein Kontrakt-Zertifikat erhalten hat und leitet es ihm optional weiter (oder das Kontrakt -Zertifikat wird nach Bedarf von dem OEM abgerufen). Der Kunde beauftragt den Fahrzeughersteller, und insbesondere das Fahrzeug, das Kontrakt-Zertifikat herunterzuladen und zu installieren (5.). Im Rahmen des Ladevorgangs kommuniziert (6.) der Fahrzeughersteller bzw. das Fahrzeug über ISO 15118 mit dem Ladestellenoperator (CPO), welcher nun wiederum über den Aggregator und/oder eine Roaming-Plattform mit dem Mobilitätsoperator Kontakt aufnehmen kann bezüglich der Bezahlung des Ladevorgangs.
In Fig. 4 ist eine vereinfachte Darstellung der technischen Infrastruktur für die Nutzung von Plug & Charge gezeigt. Fig. 4 zeigt ein Ladesteuergerät 410, das dem Ladesteuergerät 10 von Fig. la entsprechen kann, ein Benutzerschnittstellensteuergerät 420, das dem Benutzerschnittstellensteuergerät 20 der Fign. la und 1b entsprechen kann, einen Intermediär 430 (der im Fahrzeug, bei der Fertigung des Fahrzeugs, oder aber bei dem Neuausstellen eines Provisionierungszertifikats für einen neuen Nutzer auch unabhängig von der Fertigung genutzt werden kann), ein Plug & Charge -Koordinator 440 (seitens des Fahrzeugherstellers), einen Aggregator 450, einen Mobilitätsdienstleister 460, einen Betreiber der Ladestation 470, sowie die Ladestation 480. Das Ladesteuergerät 410 ist zur Kommunikation gemäß ISO 15118 ausgebildet und ist für die Zertifikatsspeicherung & -handhabung (inkl. Diagnoseaufträge) zuständig. Der Intermediär ist die Wurzel-Zertifikatsautorität des Fahrzeugherstellers und stellt Provisionierungszertifikate bereit. Das Schlüsselpaar des Provisionierungszertifikats kann beispielsweise in dem Ladesteuergerät 410, oder aber auf einem Server, wie etwa dem Plug & Charge -Koordinator, erstellt werden. Dies ist durch Block 435 in Fig. 4 angedeutet.
Um einen neuen Kontrakt im Fahrzeug, und insbesondere im Ladesteuergerät zu installieren, können die folgenden Schritte ausgeführt werden. Um die Installation von Ladekontrakten (bzw. der entsprechenden Zertifikate) zu ermöglichen, wird ein sogenanntes Provisionszertifikat benötigt. Im vorliegenden Beispiel wird dies durch den Intermediär 430 durchgeführt. Dieser erhält einen Certificate Signing Request (CSR, Zertifikatssignierungsanfrage), etwa von dem Lade Steuergerät, und stellt einen privaten Schlüssel des Zertifikats dem Ladesteuergerät 430 bereit und einen öffentlichen Schlüssel dem Plug & Charge -Koordinator 440. Dieser veröffentlich das Provisionszertifikat (d.h. den öffentlichen Schlüssel davon) bei dem Aggregator 450. Das Provisionszertifikat enthält kryptografisch gesichert eine Identifikationskennung, den Benutzerkontospezifischen eindeutigen Identifikator. Alternativ kann der Intermediär die Zertifikatssignierungsanfrage auch von einem Server, etwa dem Plug & Charge -Koordinator 440 erhalten, etwa bei einer Erstellung eines Benutzerkontos oder bei einer Freischaltung der Plug & Charge-Funktionalität im Benutzerkonto. Entsprechend kann die Generierung 435 des Schlüsselpaars etwa durch das Ladesteuergerät 410 oder einen Server, wie etwa den Plug & Charge -Koordinator 440 erfolgen. Unterzeichnet ein Kunde einen Ladevertrag, so gibt er als Teil des Vertrags die Identifikationskennung des Provisionierungszertifikats (d.h. den Benutzerkonto-spezifischen eindeutigen Identifikator) gegenüber dem Mobilitätsdienstleister 450 an. Dieser erstellt ein neues Kontrakt-Zertifikat. Das Kontrakt-Zertifikat kann nun mittels des Provisionszertifikats (d.h. des öffentlichen Schlüssels) verschlüsselt werden, so dass es nur von einem Ladesteuergerät entschlüsselt werden kann, das über den privaten Schlüssel des Provisionierungszertifikats verfügt. Das passende Provisionszertifikat wird mittels der Identifikationskennung (d.h. den eindeutigen Identifikator) ermittelt. Der Aggregator 450 erhält das verschlüsselte Kontrakt-Zertifikat und informiert den Plug & Charge -Koordinator 440 darüber. Dieser kann nun das Kontrakt-Zertifikat erhalten und dem Ladesteuergerät bereitstellen, etwa über eine Telematikverbindung. Alternativ kann das Kontrakt-Zertifikat über die Powerline- Kommunikation zwischen Ladestation 480 und Lade Steuergerät 410 ausgetauscht werden. Verfügt das Ladesteuergerät über ein entsprechendes Kontraktzertifikat, so kann es sich, über eine Verbindung, die mittels einer TLS (Transport Layer Security, Transportschichtsicherheit)- Kommunikation gesichert ist, über das Kontraktzertifikat identifizieren. Die Ladestation identifiziert sich über ein Leaf-Zertifikat, das von einem V2G (Vehicle-to-Grid, Fahrzeug-zu-Netz)- Wurzelzertifikat abgeleitet ist. Mittels dem Leaf-Zertifikat der Ladestation wird zunächst eine TLS (etwa eine TLS 1.2)-Verbindung zwischen Ladestation und Fahrzeug aufgebaut (ähnlich der Transportverschlüsslung im Internet). Im Anschluss wird das Kontraktzertifikat übertragen. Das Kontraktzertifikat ist damit nicht Teil der TLS-Kette . Im Falle von TLS 1.3 wird ein weiteres Zertifikat genutzt, das in ISO15518-20 beschrieben ist. Die Autorisierung der Ladesitzung erfolgt zwischen Ladestation 480, Betreiber der Ladestation 470 und Aggregator 450, wobei der Betreiber 470 der Ladestation den Mobilitätsdienstleister 460 über den Aggregator 450 ermitteln kann. Die Bezahlung erfolgt dann, gemäß Kontrakt, über einen E-Mobilitäts-Identifikator an den Mobilitätsdienstleister 460.
Das Benutzerschnittstellensteuergerät umfasst ein System für eine grafische Oberfläche, das beispielsweise auf einem grafischen Betriebssystem für Mobilgeräte basieren kann und die Benutzerführung an Bord sowie die Konfiguration des Fahrzeugs sowie der Plug & Charge- Funktionalität ermögliche kann, sowie die eigentliche Steuergerätfunktionalität. Letztere kommuniziert mit dem Lade Steuergerät 410 und erhält Informationen über dort gespeicherte Provisionierungs- und Vertragszertifikate von dem Ladesteuergerät 410. Beispielsweise kann sich ein Benutzer über das Benutzerschnittstellensteuergerät an dem Fahrzeug anmelden, worauf das entsprechende Provisionierungszertifikat und Vertragszertifikat aktiviert wird. Über das System für die grafische Oberfläche kann nun eine Möglichzeit zur Auswahl eines der gespeicherten Zertifikate gegeben werden, wobei die Auswahl an das Ladesteuergerät kommuniziert wird. Das Benutzerschnittstellensteuergerät 420 fragt zudem Identifikatoren von neuen Kontraktzertifikaten (und V2G-Wurzelzertifikaten) am Plug & Charge -Koordinator 440 an, um die Installation der Kontraktzertifikate anbieten zu können. Wird die Installation veranlasst, dann fragt das Benutzerschnittstellensteuergerät 420 die jeweiligen Zertifikate zur Installation von dem Plug & Charge -Koordinator an. Diese werden dann an das Ladesteuergerät weitergegeben. Für die Kommunikation zwischen Benutzerschnittstellensteuergerät 420 und Ladesteuergerät 410 kann dabei beispielsweise eine Diagnose-Kommunikation und/oder eine Status/Konfigurations-Kommunikation verwendet werden.
Die Aspekte und Merkmale, die im Zusammenhang mit einem bestimmten der vorherigen Beispiele beschrieben sind, können auch mit einem oder mehreren der weiteren Beispiele kombiniert werden, um ein identisches oder ähnliches Merkmal dieses weiteren Beispiels zu ersetzen oder um das Merkmal in das weitere Beispiel zusätzlich einzufuhren.
Beispiele können weiterhin ein (Computer-)Programm mit einem Programmcode zum Ausfuhren eines oder mehrerer der obigen Verfahren sein oder sich darauf beziehen, wenn das Programm auf einem Computer, einem Prozessor oder einer sonstigen programmierbaren Hardwarekomponente ausgeführt wird. Schritte, Operationen oder Prozesse von verschiedenen der oben beschriebenen Verfahren können also auch durch programmierte Computer, Prozessoren oder sonstige programmierbare Hardwarekomponenten ausgeführt werden. Beispiele können auch Programmspeichervorrichtungen, z.B. Digitaldatenspeichermedien, abdecken, die maschinen-, Prozessor- oder computerlesbar sind und maschinenausführbare, prozessorausführbare oder computerausführbare Programme und Anweisungen codieren beziehungsweise enthalten. Die Programmspeichervorrichtungen können z.B. Digitalspeicher, magnetische Speichermedien wie beispielsweise Magnetplatten und Magnetbänder, Festplattenlaufwerke oder optisch lesbare Digitaldatenspeichermedien umfassen oder sein. Weitere Beispiele können auch Computer, Prozessoren, Steuereinheiten, feld-programmierbare Logik-Arrays ((F)PLAs = (Field) Programmable Logic Arrays), feld-programmierbare Gate-Arrays ((F)PGA = (Field) Programmable Gate Arrays), Grafikprozessoren (GPU = Graphics Processor Unit), anwendungsspezifische integrierte Schaltungen (ASIC = application-specific integrated circuit), integrierte Schaltungen (IC= Integrated Circuit) oder Ein-Chip -Systeme (SoC = System-on-a-Chip) abdecken, die zum Ausführen der Schritte der oben beschriebenen Verfahren programmiert sind.
Es versteht sich ferner, dass die Offenbarung mehrerer, in der Beschreibung oder den Ansprüchen offenbarter Schritte, Prozesse, Operationen oder Funktionen nicht als zwingend in der beschriebenen Reihenfolge befindlich ausgelegt werden soll, sofern dies nicht im Einzelfall explizit angegeben oder aus technischen Gründen zwingend erforderlich ist. Daher wird durch die vorhergehende Beschreibung die Durchführung von mehreren Schritten oder Funktionen nicht auf eine bestimmte Reihenfolge begrenzt. Ferner kann bei weiteren Beispielen ein einzelner Schritt, eine einzelne Funktion, ein einzelner Prozess oder eine einzelne Operation mehrere Teilschritte, -Funktionen, - prozesse oder -Operationen einschließen und/oder in dieselben aufgebrochen werden.
Wenn einige Aspekte in den vorhergehenden Abschnitten im Zusammenhang mit einer Vorrichtung oder einem System beschrieben wurden, sind diese Aspekte auch als eine Beschreibung des entsprechenden Verfahrens zu verstehen. Dabei kann beispielsweise ein Block, eine Vorrichtung oder ein funktionaler Aspekt der Vorrichtung oder des Systems einem Merkmal, etwa einem Verfahrensschritt, des entsprechenden Verfahrens entsprechen. Entsprechend dazu sind Aspekte, die im Zusammenhang mit einem Verfahren beschrieben werden, auch als eine Beschreibung eines entsprechenden Blocks, eines entsprechenden Elements, einer Eigenschaft oder eines funktionalen Merkmals einer entsprechenden Vorrichtung oder eines entsprechenden Systems zu verstehen.
Die folgenden Ansprüche werden hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Anspruch als getrenntes Beispiel für sich stehen kann. Ferner ist zu beachten, dass - obwohl ein abhängiger Anspruch sich in den Ansprüchen auf eine bestimmte Kombination mit einem oder mehreren anderen Ansprüchen bezieht - andere Beispiele auch eine Kombination des abhängigen Anspruchs mit dem Gegenstand jedes anderen abhängigen oder unabhängigen Anspruchs umfassen können. Solche Kombinationen werden hiermit explizit vorgeschlagen, sofern nicht im Einzelfall angegeben ist, dass eine bestimmte Kombination nicht beabsichtigt ist. Ferner sollen auch Merkmale eines Anspruchs für jeden anderen unabhängigen Anspruch eingeschlossen sein, selbst wenn dieser Anspruch nicht direkt als abhängig von diesem anderen unabhängigen Anspruch definiert ist.
Bezugszeichenliste
5 Ladeinfrastruktur
10 Ladesteuergerät
12 Schnittstelle
14 Kryptografisch gesichertes Element
16 Steuerungsschaltung
18 Speicher
20 Benutzerschnittstellensteuergerät
22 Schnittstelle
24 Steuerungsschaltung
100 Fahrzeug
105 Speicher
110 Erhalten von einem kryptografisch gesicherten Provisionierungszertifikat
120 Erhalten von einem oder mehreren kryptografisch gesicherten Ladekontrakten
130 Speichern des Provisionierungszertifikats und zumindest eines Ladekontrakts in einem kryptografisch gesicherten Element
140 Authentifizieren des Ladesteuergeräts
210 Erhalten einer Benutzereingabe
220 Bereitstellen eines Steuersignals
410 Ladesteuergerät
420 Benutzerschnittstellensteuergerät
430 Intermediär
435 Schlüsselgenerierung
440 Plug & Charge -Koordinator
450 Aggregator
460 Mobilitätsdienstleister
470 Betreiber einer Ladestation
480 Lade Station

Claims

Patentansprüche
1. Ein Ladesteuergerät (10) für ein Fahrzeug (100), das Ladesteuergerät umfassend: zumindest eine Schnittstelle (12) zur Kommunikation mit einer Ladeinfrastruktur (5); ein kryptografisch gesichertes Element (14); und eine Steuerungsschaltung (16), ausgebildet zum:
Erhalten von einem kryptografisch gesicherten Provisionierungszertifikat, wobei das kryptografisch gesicherte Provisionierungszertifikat einen eindeutigen Identifikator umfasst, wobei der eindeutige Identifikator mit einem Benutzerkonto eines Fahrers des Fahrzeugs verknüpft ist,
Erhalten von ein oder mehreren kryptografisch gesicherten Ladekontrakten, wobei die ein oder mehreren kryptografisch gesicherte Ladekontrakte auf dem kryptografisch gesicherten Provisionierungszertifikat basieren,
Speichern des Provisionierungszertifikats und zumindest eines Ladekontrakts der ein oder mehreren kryptografisch gesicherten Ladekontrakte in dem kryptografisch gesicherten Element, und
Authentifizieren des Ladesteuergeräts gegenüber der Ladeinfrastruktur basierend auf dem zumindest einen in dem kryptografisch gesicherten Element gespeicherten Ladekontrakt.
2. Das Ladesteuergerät gemäß Anspruch 1, wobei der eindeutige Identifikator nicht mit dem Fahrzeug verknüpft ist.
3. Das Lade Steuergerät gemäß einem der Ansprüche 1 oder 2, wobei die Steuerungsschaltung ferner ausgebildet ist, um zumindest ein zweites kryptografisch gesicherte Provisionierungszertifikat, das einen zweiten eindeutigen Identifikator umfasst, der mit einem Benutzerkonto eines zweiten Fahrers verknüpft ist, und ein oder mehrere zweite, auf dem zweiten Provisionierungszertifikat basierende kryptografisch gesicherte Ladekontrakte zu erhalten, das zweite Provisionierungszertifikat und zumindest einen zweiten Ladekontrakt der ein oder mehreren zweiten Ladekontrakte in dem kryptografisch gesicherten Element zu speichern und das Ladesteuergerät gegenüber der Ladeinfrastruktur basierend auf dem zumindest einen zweiten Ladekontrakt zu authentifizieren.
4. Das Ladesteuergerät gemäß Anspruch 3, wobei die Steuerungsschaltung ausgebildet ist, um das zweite Provisionierungszertifikat und den zumindest einen zweiten Ladekontrakt zusätzlich zu dem Provisionierungszertifikat und dem zumindest einen Ladekontrakt in dem kryptografisch gesicherten Element zu speichern, und um eine Auswahl darüber zu speichern, welcher Ladekontrakt für die Authentifizierung zu verwenden ist.
5. Das Ladesteuergerät gemäß Anspruch 3, wobei die Steuerungsschaltung ausgebildet ist, um das Provisionierungszertifikat und den zumindest einen Ladekontrakt verschlüsselt aus dem kryptografisch gesicherten Element auszulagem, und um das zweite Provisionierungszertifikat und den zumindest einen zweiten Ladekontrakt nach dem Auslagem in dem kryptografisch gesicherten Element zu speichern.
6. Das Ladesteuergerät gemäß Anspruch 5, wobei die Steuerungsschaltung ausgebildet ist, um das Provisionierungszertifikat und den zumindest einen Ladekontrakt verschlüsselt auf einem weiteren Speicher (18) des Ladesteuergeräts zu speichern, wobei der weitere Speicher außerhalb des kryptografisch gesicherten Elements angeordnet ist.
7. Das Lade Steuergerät gemäß Anspruch 5, wobei die Steuerungsschaltung ausgebildet ist, um das Provisionierungszertifikat und den zumindest einen Ladekontrakt verschlüsselt auf einem weiteren Speicher (105) außerhalb des Ladesteuergeräts zu speichern.
8. Das Ladesteuergerät gemäß einem der Ansprüche 5 bis 7, wobei das Provisionierungszertifikat und der zumindest einen Ladekontrakt mittels eines kryptografischen Schlüssels, der innerhalb des kryptografisch gesicherten Elements gespeichert ist, verschlüsselt ist.
9. Das Ladesteuergerät gemäß einem der Ansprüche 5 bis 8, wobei die Steuerungsschaltung ausgebildet ist, um zumindest das zweite Provisionierungszertifikat und die ein oder mehreren zweiten Ladekontrakte in verschlüsselter Lorrn von einem Speicher innerhalb oder außerhalb des Ladesteuergeräts zu erhalten.
10. Das Ladesteuergerät gemäß einem der Ansprüche 3 bis 9, wobei die Steuerungsschaltung ausgebildet ist, um zumindest das Erhalten und Speichern des zweiten Provisionierungszertifikats und der ein oder mehreren zweiten Ladekontrakte als Reaktion auf ein Steuersignal eines Benutzerschnittstellensteuergerät (20) des Fahrzeugs durchzuführen.
11. Ein Benutzerschnittstellensteuergerät (20) für ein Fahrzeug (100), das Benutzerschnittstellensteuergerät umfassend: zumindest eine Schnittstelle (22) zur Kommunikation mit einem Lade Steuergerät (10) des Fahrzeugs und zur Kommunikation mit einer Benutzerschnittstelle; eine Steuerungsschaltung (24), ausgebildet zum:
Erhalten einer Benutzereingabe über die Benutzerschnittstelle, wobei die Benutzereingabe anzeigt, dass sich ein Fahrer des Fahrzeugs über sein Benutzerkonto an dem Fahrzeug anmeldet, und
Bereitstellen eines Steuersignals an das Ladesteuergerät, falls ein eindeutiger Identifikator, der in einem Provisionierungszertifikat umfasst ist, auf dem ein Ladekontrakt basiert, der aktuell für die Authentifizierung gegenüber einer Ladeinfrastruktur verwendet ist, mit einem anderen Benutzerkonto verknüpft ist, wobei das Steuersignal anzeigt, dass ein zweites Provisionierungszertifikat und zumindest ein auf dem zweiten Provisionierungszertifikat basierender Ladekontrakt für die Authentifizierung gegenüber die Ladeinfrastruktur zu verwenden ist.
12. Das Benutzerschnittstellensteuergerät gemäß Anspruch 11, wobei die Steuerungsschaltung ausgebildet ist, um eine Darstellung von ein oder mehreren Ladekontrakten über die Benutzerschnittstelle auszugeben, die auf dem Provisionierungszertifikat basieren, dessen eindeutiger Identifikator mit dem aktuell angemeldeten Benutzerkonto verknüpft ist.
13. Ein Verfahren für ein Ladesteuergerät (10) für ein Fahrzeug (100), das Verfahren umfassend: Erhalten (110) von einem kryptografisch gesicherten Provisionierungszertifikat, wobei das kryptografisch gesicherte Provisionierungszertifikat einen eindeutigen Identifikator umfasst, wobei der eindeutige Identifikator mit einem Benutzerkonto eines Fahrers des Fahrzeugs verknüpft ist;
Erhalten (120) von ein oder mehreren kryptografisch gesicherten Ladekontrakten, wobei die ein oder mehreren kryptografisch gesicherte Ladekontrakte auf dem kryptografisch gesicherten Provisionierungszertifikat basieren;
Speichern (130) des Provisionierungszertifikats und zumindest eines Ladekontrakts der ein oder mehreren kryptografisch gesicherten Ladekontrakte in einem kryptografisch gesicherten Element des Ladesteuergeräts; und
Authentifizieren (140) des Ladesteuergeräts gegenüber einer Ladeinfrastruktur basierend auf dem zumindest einen in dem kryptografisch gesicherten Element gespeicherten Ladekontrakt.
14. Ein Verfahren für ein Benutzerschnittstellensteuergerät (20) für ein Fahrzeug (200), das Verfahren umfassend:
Erhalten (210) einer Benutzereingabe über eine Benutzerschnittstelle, wobei die Benutzereingabe anzeigt, dass sich ein Fahrer des Fahrzeugs über sein Benutzerkonto an dem Fahrzeug anmeldet; und Bereitstellen (220) eines Steuersignals an ein Ladesteuergerät des Fahrzeugs, falls ein eindeutiger Identifikator, der in einem Provisionierungszertifikat umfasst ist, auf dem ein Ladekontrakt basiert, der aktuell für die Authentifizierung gegenüber einer Ladeinfrastruktur verwendet ist, mit einem anderen Benutzerkonto verknüpft ist, wobei das Steuersignal anzeigt, dass ein zweites Provisionierungszertifikat und zumindest ein auf dem zweiten
Provisionierungszertifikat basierender Ladekontrakt für die Authentifizierung gegenüber die Ladeinfrastruktur zu verwenden ist.
15. Programm mit einem Programmcode zum Durchführen des Verfahrens gemäß Anspruch 13 oder des Verfahrens gemäß Anspruch 14, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.
EP24702794.9A 2023-03-20 2024-01-31 Konzept für nutzerspezifische provisions- und ladekontraktzertifikate Pending EP4683823A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102023106848.2A DE102023106848A1 (de) 2023-03-20 2023-03-20 Konzept für nutzerspezifische Provisions- und Ladekontraktzertifikate
PCT/EP2024/052380 WO2024193884A1 (de) 2023-03-20 2024-01-31 Konzept für nutzerspezifische provisions- und ladekontraktzertifikate

Publications (1)

Publication Number Publication Date
EP4683823A1 true EP4683823A1 (de) 2026-01-28

Family

ID=89771663

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24702794.9A Pending EP4683823A1 (de) 2023-03-20 2024-01-31 Konzept für nutzerspezifische provisions- und ladekontraktzertifikate

Country Status (4)

Country Link
EP (1) EP4683823A1 (de)
CN (1) CN120882589A (de)
DE (1) DE102023106848A1 (de)
WO (1) WO2024193884A1 (de)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011101535A1 (de) * 2011-05-14 2012-02-02 Daimler Ag System und Verfahren zum Aufladen von Batterien von Fahrzeugen
CN114008973B (zh) * 2019-04-24 2023-11-21 现代自动车株式会社 Ev用户授权方法和系统
KR20210100545A (ko) * 2020-02-06 2021-08-17 현대자동차주식회사 전기차에 대한 계약 인증서 설치 지원 방법 및 장치
DE102020205022B4 (de) * 2020-04-21 2024-01-04 Siemens Aktiengesellschaft Verfahren, Authentifikationsmittel und Autorisierungseinrichtung zur Autorisierung eines Ladevorgangs
DE102020120945A1 (de) * 2020-08-07 2022-02-10 Innogy Innovation Gmbh Verfahren zum Kommunizieren, basierend auf einer Distributed-Ledger-Technologie, zwischen einer Vielzahl von Ladestationen für Elektrofahrzeuge
US20240121110A1 (en) * 2020-11-27 2024-04-11 Hyundai Motor Company Cross-certification method and device for charging electric vehicle

Also Published As

Publication number Publication date
DE102023106848A1 (de) 2024-09-26
WO2024193884A1 (de) 2024-09-26
CN120882589A (zh) 2025-10-31

Similar Documents

Publication Publication Date Title
DE102010005422B4 (de) System und Verfahren zum Aufbauen einer sicheren Verbindung mit einer mobilen Vorrichtung
DE102014114607B4 (de) Programmierung von Fahrzeugmodulen mit Remotevorrichtungen und zugehörige Methoden und Systeme
DE102009037193B4 (de) System und Verfahren zum Durchführen eines Austauschs eines asymmetrischen Schlüssels zwischen einem Fahrzeug und einer entfernten Einrichtung
DE102011081804B4 (de) Verfahren und System zum Bereitstellen von gerätespezifischen Betreiberdaten, welche an ein Authentisierungs-Credential gebunden werden, für ein Automatisierungsgerät einer Automatisierungsanlage
DE102019212959B3 (de) Verfahren zur geschützten Kommunikation eines Fahrzeugs mit einem externen Server, Vorrichtung zur Durchführung der Schlüsselableitung bei dem Verfahren sowie Fahrzeug
WO2019243269A1 (de) Ladesystem zur dynamischen aufladung von elektrofahrzeugen
EP3615371A1 (de) Verfahren zur zweistufigen autorisierung eines ladevorgangs an einer ladesäule
EP3157281A1 (de) Verfahren zur geschützten kommunikation eines fahrzeugs
DE102012224421A1 (de) Fahrzeuggebundenes system und kommunikationsverfahren
DE102007022100B4 (de) Kraftfahrzeugsteuergerätedatenübertragungssystem und -verfahren
DE102017119373A1 (de) Aktualisierung der servers der netzwerkadresse der mobilvorrichtung
DE102019121164A1 (de) Fahrzeugbasiertes passwort
DE102018101479A1 (de) Steuerungsschnittstelle für ein autonomes fahrzeug
DE102019004726A1 (de) Verfahren, Vorrichtung, System, elektronisches Schloss, digitaler Schlüssel und Speichermedium für die Autorisierung
DE102022003988B4 (de) Verfahren zur Nutzungsfreigabe von Telematik-Diensten, mobiles Kommunikationsgerät und Kommunikationssystem zur Ausführung des Verfahrens
DE102023107659A1 (de) Unleugbarer verlauf von fahrzeugänderungen
DE102008050406A1 (de) Datenübertragungsverfahren
DE102021131515A1 (de) Verfahren, Fortbewegungsmittel, Server und Ladesäule zum Autorisieren eines Ladevorgangs
EP4683823A1 (de) Konzept für nutzerspezifische provisions- und ladekontraktzertifikate
WO2019053221A1 (de) Verfahren zum aufladen eines elektrischen energiespeichers; ladeeinheit und system mit ladeeinheit
DE102023106713A1 (de) Verfahren, Vorrichtungen und Computerprogramme für einen Server und ein Fahrzeug
DE102023106845A1 (de) Konzept für eine ladestationsbasierte Ladekontraktauswahl
EP4658528A1 (de) Ladesteuergerät, benutzerschnittstellensteuergerät, fahrzeug und entsprechende verfahren und computerprogramme
WO2021110425A1 (de) Verfahren und messeinheit zur identitätsgesicherten bereitstellung eines messdatensatzes
WO2026082529A1 (de) Inbetriebnahme eines fortbewegungsmittels in der produktion

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250818

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR