Concept for user-specific provision and charging contract certificates

Abstract

The invention relates to a charging controller (10), a user interface controller (20), a vehicle (100) having a charging controller (10) and a user interface controller (20), and to corresponding methods and computer programs. The charging controller (10) comprises at least one interface for communication (12) with a charging infrastructure (5). The charging controller (10) comprises a cryptographically protected element. The charging controller (10) comprises a control circuit (16). The control circuit (16) is designed to receive a cryptographically protected provisioning certificate. The cryptographically protected provisioning certificate comprises a unique identifier. The unique identifier is linked with a user account of a driver of a vehicle (100). The control circuit (16) is designed to receive one or multiple cryptographically protected charging contracts. The one or multiple cryptographically protected charging contracts are based on the cryptographically protected provisioning certificate. The control circuit (16) is designed to store the provisioning certificate and at least one charging contract of the one or multiple cryptographically protected charging contracts in the cryptographically protected element (14). The control circuit (16) is designed to authenticate the charging controller (10) with respect to the charging infrastructure on the basis of the at least one charging contract stored in the cryptographically protected element (14).

Description

[0001] Concept for user-specific commission and charging contract certificates

[0002] Technical area

[0003] 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.

[0004] background

[0005] Plug & Charge (a charging standard for electric vehicles) is based on the industry standard ISO 15118. Using Plug & Charge (P&C), drivers of electric vehicles, such as battery electric vehicles (BEVs) or hybrid vehicles (PHEVs, plug-in hybrid electric vehicles, a hybrid vehicle whose battery can be charged by the engine and by plugging in a charging connector), can authenticate at public charging stations simply by plugging in the charging cable. Authentication is performed using a digital contract certificate in accordance with the standard. The contract certificate contains, among other things, the contract number.The charging point operator (CPO) can use this number to bill the charging process via existing roaming platforms with the contracted provider (EMP or MO, Electro Mobility Provider or Mobility Operator, often the same as the EMP) or directly with the customer (if the CPO is also a contracted provider). The functionality is described in detail below.

[0006] According to the current version of the standard (ISO 15118-2), the vehicle can only transmit one certificate to the charging station; therefore, in many systems only one certificate is stored on the vehicle. According to the standard, 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), e.g. the vehicle manufacturer. According to ISO 15118-2, the contract certificates are linked to a vehicle, not to a vehicle user. The basic requirement for installing a contract certificate is the so-calledA provisioning certificate, which is also issued specifically for the vehicle for this purpose and exists only once. For provisioning certificates, as well as for contract certificates (i.e., the certificates for charging contracts), the certificate chain (up to the root certificate) and the associated private / secret key are always stored in the vehicle's secure storage. The secure storage for the private keys is often a special HSM (Hardware Security Module) with limited memory.

[0007] In modern vehicles, it is possible for vehicle users to log in with personal user accounts on the vehicle and through other touchpoints (such as a mobile application). Each vehicle can have a designated primary user and possibly several secondary users.

[0008] There is a need for an improved concept for the technical security of the charging process of electric vehicles.

[0009] Summary

[0010] This need is taken into account by the subject matter of the independent claims.

[0011] The present invention is based on the realization that linking contract certificates and provisioning certificates to a vehicle is not essential to ensuring the security of charging authentication. The aforementioned standard merely 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) (thereby linking the identifier to the vehicle) or be individually selected (the format of which is limited by the standard), as long as it is ensured that the identifier is unique and unambiguous.The present invention 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, for example when the user logs into the vehicle, is then inserted and stored in a cryptographically secured element of a charging control unit of 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 unit for a vehicle.The charging control unit comprises at least one interface for communication with a charging infrastructure. The charging control unit comprises a cryptographically secured element. The charging control unit comprises a control circuit. The control circuit is configured 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 configured 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 configured 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 configured to authenticate the charging control unit 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.

[0012] In particular, the unique identifier cannot be linked to the vehicle. This simplifies the use of the provisioning certificate in multiple vehicles.

[0013] For example, the control circuit may be further configured to receive at least one second cryptographically secured provisioning certificate comprising a second unique identifier linked to a user account of a second driver, and one or more second cryptographically secured charging contracts based on the second provisioning certificate. The control circuit may be 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.This allows switching between charging contracts for different drivers within the vehicle, for example, in a car-sharing scenario, a company fleet scenario, or when a company car is used for both private and business purposes. The concept is not limited to two provisioning certificates – the number of provisioning certificates may only be limited by the number of users assigned to the vehicle.

[0014] If multiple provisioning certificates are used, several options arise, depending on how many provisioning certificates can be stored in the cryptographically secured element, in a memory of the charging control unit outside the cryptographically secured element, or in a memory outside the charging control unit. For example, the control circuit can be configured 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. In addition, the control circuit can be configured to store a selection of which charging contract is to be used for authentication. This enables the charging contracts to be used by multiple chargers without the need to display and deposit the respective certificates when changing chargers / users.

[0015] Alternatively (or additionally, depending on the storage capacity of the cryptographically secured element), the control circuit can be configured to display 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 displaying them. The encrypted display can create the necessary storage space in the cryptographically secured element for storing the second provisioning certificate and the at least one second charging contract. By displaying them in encrypted form, the display can be carried out without compromising the security of the certificates.

[0016] The outsourcing can be carried out in a memory of the charging control device or in a memory outside the charging control device. In other words, the control circuit can be designed to store the provisioning certificate and the at least one charging contract in encrypted form in a further memory of the charging control device, wherein the further memory is arranged outside the cryptographically secured element. Alternatively (or additionally), the control circuit can be designed to store the provisioning certificate and the at least one charging contract in encrypted form in a further memory outside the charging control device. Storing in a memory of the charging control device enables simpler implementation without involving additional devices, but is dependent on the available memory.Storing in a memory external to the charging control unit increases implementation complexity, but enables the use of a memory shared by multiple control units in the vehicle.

[0017] To ensure the security of the outsourced data, data encryption can be linked to the charging control unit, and in particular to the cryptographically secured element. For example, the provisioning certificate and the at least one charging contract can be encrypted using a cryptographic key stored within the cryptographically secured element. This improves the security of the encryption, as the encrypted data remains secure even if the storage is removed.

[0018] Corresponding to the data being read out in encrypted form from the cryptographically secured element, the data can also be read in encrypted form and decrypted and stored in the cryptographically secured element. In other words, the control circuit can be configured 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. This allows the respective data to be stored back in the cryptographically secured element after a previous encrypted readout. As already mentioned above, this is generally possible for any number of provisioning certificates and associated charging contracts.

[0019] To signal to the charging control unit that a different provisioning certificate with a corresponding charging contract is to be used in the future, the current driver can log in to the vehicle via a user interface. This login can then be signaled to the charging control unit, whereupon the corresponding provisioning certificate and a corresponding charging contract can be stored in the cryptographically secured element. Accordingly, the control circuit can be configured to at least obtain and store the second provisioning certificate and the one or more second charging contracts in response to a control signal from a user interface control unit of the vehicle.

[0020] A further aspect of the present disclosure relates to a corresponding method for a charging control device for a 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 executed, for example, by the charging control device. A further aspect of the present disclosure relates to a corresponding program with program code for implementing 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.

[0021] Another aspect of the present disclosure relates to a user interface controller for a vehicle. The user interface controller comprises at least one interface for communicating with a charging controller of the vehicle and for communicating with a user interface. The user interface controller comprises a control circuit configured 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 their user account. The control circuit is configured to provide a control signal to the charging controller 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 must be used for authentication with the charging infrastructure. This can be used to signal to the charging control unit that a different provisioning certificate with a corresponding charging contract must be used in the future, for example, in the event of a driver change.

[0022] For example, the control circuitry can 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 linked to the currently logged-in user account. This allows the newly logged-in driver to select a charging contract if multiple charging contracts are linked to the same provisioning certificate.

[0023] A further aspect of the present disclosure relates to a corresponding method for a user interface controller for a vehicle. The method comprises receiving user input via a user interface. The user input indicates that a driver of the vehicle is logging into the vehicle using their user account. The method comprises 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 currently used for authentication to a charging infrastructure is based 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.The method can be executed, for example, by the user interface controller.

[0024] A further aspect of the present disclosure relates to a corresponding program having a program code for performing 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.

[0025] Short character description

[0026] Exemplary embodiments are explained in more detail below with reference to the accompanying figures. They show:

[0027] Fig. 1a shows a schematic diagram of a charging control device;

[0028] Fig. 1b shows a flowchart of a method for a charging control unit;

[0029] Fig. 2a shows a schematic diagram of a user interface controller;

[0030] Fig. 2b shows a flowchart of a method for a user interface controller;

[0031] Fig. 3 shows a schematic diagram of a technical perspective on Plug & Charge; and

[0032] Fig. 4 shows a simplified representation of the technical infrastructure for the use of Plug & Charge.

[0033] Description

[0034] Some examples will now be described in more detail with reference to the accompanying figures. However, further possible examples are not limited to the features of these detailed embodiments. These may include modifications of the features, as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe particular examples is not intended to be limiting of other possible examples. Like or similar reference numerals refer to like or similar elements or features throughout the description of the figures, each of which may be implemented identically or in a modified form while providing the same or a similar function. Furthermore, in the figures, the thicknesses of lines, layers and / or regions may be exaggerated for clarity.

[0035] When two elements A and B are combined using "or," this is to be understood as disclosing all possible combinations, i.e., only A, only B, and both A and B, unless explicitly defined otherwise in the individual case. Alternative wording for the same combinations may be "at least one of A and B" or "A and / or B." This applies equivalently to combinations of more than two elements.

[0036] If a singular form is used, such as "a," "an," and "the," and the use of only a single element is neither explicitly nor implicitly defined as mandatory, further examples may also use multiple elements to implement the same function. If a function is described below as being implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity.It is further understood that the terms "comprises", "comprising", "has" and / or "having" when used herein describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof.

[0037] Fig. 1a shows a schematic diagram of a charging control unit 10 for a vehicle 100, wherein the charging control unit 10 is part of the vehicle 100. The charging control unit comprises at least one interface 12 for communication with a charging infrastructure 5 (such as a charging station), for example via power line communication. In some examples, the at least one interface 12 comprises an interface for communication with a user interface control unit 20 of the vehicle 100, at least one interface for communication with a server (not shown), for example via a telematics connection / mobile radio connection, and / or an interface for communication with a memory 105 of the vehicle. The charging control unit 10 comprises a cryptographically secured element 14, for example a so-called "secure element" or "trusted execution environment".The charging control unit 10 comprises a control circuit 16 coupled to the cryptographically secured element 14 and the at least one interface 12. For example, the cryptographically secured element can be part of the control circuit 16 or a separate component. Optionally, the charging control unit 18 further comprises a memory 18 coupled to the control circuit 16.

[0038] The control circuit 16 is configured to receive a cryptographically secured provisioning certificate. The cryptographically secured provisioning certificate includes a unique identifier. The unique identifier is linked to a user account of a driver of the vehicle. In the context of the present disclosure, 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 for locomotion and / or specifies the destination of the autonomous vehicle. The control circuit 16 is configured 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 configured 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 configured to authenticate the charging control unit to the charging infrastructure based on the at least one charging contract stored in the cryptographically secured element.

[0039] Fig. 1b shows a flowchart of a corresponding method for the charging control unit 10. The method comprises obtaining 110 the cryptographically secured provisioning certificate. The method comprises obtaining 120 the one or more cryptographically secured charging contracts. The method comprises 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 unit. The method comprises authenticating 140 the charging control unit 10 to the charging infrastructure 5 based on the at least one charging contract stored in the cryptographically secured element.

[0040] The charging control unit, the corresponding method, and a corresponding computer program are described below with reference to the charging control unit. Features that can be described in connection with the charging control unit also apply to the corresponding method or computer program.

[0041] In charging communication according to the Plug & Charge standard, provisioning certificates are used to prevent charging contracts (also called contract certificates) from being misused. The provisioning certificate comprises a public part (i.e., public key) and a private part (i.e., private key). The private part of the provisioning certificate is stored in the cryptographically secured element 14 when in use, and a public part of the provisioning certificate is made available to the other participants, for example via one or more aggregators, as shown in Fig. 4. The public part can then 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.In addition to the private key of the provisioning certificate and one or more private keys of contract certificates / loading contracts, the certificate chain (up to the root certificate) can also be stored in the cryptographically secured element. However, this is usually omitted to save storage space.

[0042] 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 (e.g., through a third-party EV charging provider). However, when changing vehicles, the EV charging provider must issue a new certificate (for the charging contract) because this vehicle has a different provisioning certificate / PCID. This creates costs for both the customer and the contract provider. Furthermore, each creation of a certificate incurs costs for the EV charging provider, which the customer must pay directly or indirectly. Furthermore, limiting the provisioning certificate / PCID to assignment to exactly one vehicle 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 into a rental vehicle, for example.

[0043] In the present invention, instead of a 1:1 relationship between vehicle and PCID / provisioning certificate, 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 to ensure it is unique for each user account.

[0044] Therefore, the cryptographically secured provisioning certificate includes a unique identifier linked to a user account of a vehicle driver, such as the aforementioned user account identifier. The identifier is unique, meaning it is uniquely linked to a user account, so that no second user account (or vehicle) can use the same identifier. For example, the identifier may include a prefix used exclusively by a vehicle manufacturer and another component that is unique among the vehicle manufacturer's user accounts. In particular, however, the identifier may be independent of an identifier, such as a chassis number, of the vehicle. Consequently, the unique identifier cannot be linked to a vehicle.

[0045] The charging control unit receives such a provisioning certificate with the unique identifier linked to the user account of the vehicle driver. This provisioning certificate can, for example, be inserted into the charging control unit, and in particular into the cryptographically secured element, before delivery of the vehicle, provided the user account of the vehicle buyer or lessee is known. Alternatively, 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 (e.g., via a user interface of the vehicle or via a mobile application). For this purpose, the provisioning certificate can, for example, be downloaded from a server of the vehicle manufacturer (see, for example, Fig.4, where the certificate is downloaded from the intermediary 430), or generated in the cryptographically secured element and transmitted to the server in encrypted form. For example, 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.

[0046] In addition to the provisioning certificate, one or more charging contracts based on the cryptographically secured provisioning certificate are now received (i.e., received or read from a vehicle's memory). 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. Depending on the available storage space, 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 (within or outside the cryptographically secured element) about which charging contract (or certificate) is to be used for authentication.During the authentication of the charging controller, at least the certificate of the charging contract is used to cryptographically secure communication with the charging infrastructure and to identify the charging controller to the charging infrastructure. The charging contracts and communication with the charging infrastructure can be based on the ISO 15118-2 standard. However, the basic principle works with both variants, ISO 15118-2 and ISO 15118-20.

[0047] The proposed invention can be used advantageously in two scenarios in particular: when a driver who has already concluded one or more charging contracts logs on to a new vehicle, and when a vehicle is used by multiple drivers. Especially for the latter case, a mechanism can now be provided that either stores provisioning certificates or the associated private keys for a (limited) number of users in the secure storage of the cryptographically secured element, or installs the corresponding private key from an encrypted container from a non-secure storage into the secure storage upon a user change.In addition, depending on the availability of secure storage in the vehicle, 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 when the user changes in the vehicle in order to reflect the installation status defined for each user.

[0048] For this purpose, the control circuit can be further configured to receive one or more additional 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. In the following, this refers to a second provisioning certificate (along with the second charging contract(s) based thereon). However, more than two charging contracts are also possible in principle. The number of provisioning certificates can depend, for example, on the number of users assigned to the vehicle.Thus, the control circuit can further be configured to receive at least one second cryptographically secured provisioning certificate comprising a second unique identifier linked to a user account of a second driver, and one or more second cryptographically secured charging contracts based on the second provisioning certificate. These can then be stored in the cryptographically secured element and used for authentication as an alternative to the first provisioning certificate and associated charging contract. Consequently, the control circuit can further be 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.

[0049] In the following, a distinction is made between three cases. In the first case, multiple provisioning certificates (and associated charging contract(s)) are stored in the cryptographically secured element. Accordingly, the control circuit can be configured 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.

[0050] In the second case, 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 unit. In other words, the control circuit can be configured 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 storage.In the second case, this is done by storing the provisioning certificate and the at least one charging contract in encrypted form on the additional memory 18 of the charging control device, wherein the additional memory is arranged outside the cryptographically secured element.

[0051] In the third case, 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 105 of the vehicle. In the third case, this is done, analogously to the second case, by storing the provisioning certificate and the at least one charging contract in encrypted form on another memory 105 outside the charging control unit. However, combinations of the three aforementioned cases are also possible, depending, for example, on the storage capacity of the cryptographically secured element or the memory 18 of the charging control unit.

[0052] If the provisioning certificate and the at least one charging contract are outsourced (or, later, the second provisioning certificate and at least one second charging contract), this occurs in encrypted form. A cryptographic key that is only present within the cryptographically secured element can be used for this purpose (e.g., because the key was generated within the cryptographically secured element). Thus, the provisioning certificate and the at least one charging contract can be encrypted using a cryptographic key stored within the cryptographically secured element. For example, the respective provisioning certificate and the charging contract(s) can be encrypted and stored together in a container. Analogous to the outsourcing of the provisioning certificate and the at least one charging contract, the depositing of the second (or third, fourth, etc.)) Provisioning certificate and associated charging contract(s) can be obtained from an insecure memory of the charging control unit or outside the charging control unit (but within the vehicle). For example, the control circuit can be configured 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.

[0053] To control the process, the charging controller can be controlled via the vehicle's user interface controller 20. For example, the control circuit can be configured 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 the vehicle's user interface controller 20.This control signal can, for example, indicate that the second provisioning certificate and the one or more second charging contracts are to be received (e.g., by receiving them from a server, or by reading them, in encrypted form, from a memory of the vehicle or the charging control unit) and are to be used for authentication instead of the first provisioning certificate and the charging contract. This is explained below with reference to Figures 2a and 2b.

[0054] The previous description assumes that each driver uses the charging contract(s) linked to their user account. However, provided sufficient secure storage is available, a user can also decide that their contract is also available to other drivers / users, deviating from the previous point.

[0055] 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.

[0056] In embodiments, the control circuit 16 can correspond to any controller or processor or a programmable hardware component. For example, the control circuit 16 can also be implemented as software programmed for a corresponding hardware component. In this respect, the control circuit 16 can be implemented as programmable hardware with appropriately adapted software. Any processors, such as digital signal processors (DSPs), can be used. Embodiments are not limited to a specific type of processor. Any processor or even multiple processors are conceivable for implementation. In some examples, the control circuit 16 can include the cryptographically secured element 14.

[0057] The memory 18 of the charging control unit and / or the memory 105 of the vehicle may, 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 (also known as random access memory), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), and network storage.

[0058] 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.

[0059] More details and aspects of the charging controller, the corresponding method, and the computer program are mentioned in connection with the concept or examples described below (e.g., Figs. 2a to 4). The charging controller, the corresponding method, and the computer program may include 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.

[0060] Fig. 2a shows a schematic diagram of a user interface control unit 20 (also called a "head unit") for a vehicle. The user interface control unit 20 comprises at least one interface 22 for communication with a charging control unit 10 (shown in Fig. 1a) of the vehicle and for communication 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 unit comprises a control circuit 24 coupled to the at least one interface 22. The control circuit 24 is configured to receive user input via the user interface.The user input indicates that a driver of the vehicle is logging into the vehicle using their user account. The control circuit 24 is configured to provide a control signal to the charging control unit if a unique identifier included in a provisioning certificate on which a charging contract is based and 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.

[0061] Fig. 2b shows a flowchart 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 vehicle's charging controller if the unique identifier included in the provisioning certificate on which the charging contract is based and currently used for authentication to a charging infrastructure is linked to another user account.

[0062] The user interface control device, the corresponding method, and a corresponding computer program are described below with reference to the user interface control device. Features that can be described in connection with the user interface control device also apply to the corresponding method or computer program.

[0063] As already explained in connection with Figs. 1a and 1b, the trigger for storing (or activating) a provisioning certificate along with a charging contract(s) in the cryptographically secured element is a driver / user logging into the vehicle. However, this procedure should not occur 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 for authentication is enabled, then it is not necessary to control the charging control unit accordingly. Therefore, the control signal is only provided if the charging contract currently being used (or intended 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.This is done by comparing the unique identifier of the logging-in user's user account with the unique identifier used in the provisioning certificate on which the charging contract currently used for authentication is based. To perform this comparison, the charging controller can provide the user interface controller with metadata about the available or currently used provisioning certificates and charging contracts. If the unique identifiers are different, 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 includes the unique identifier of the logging-in user's user account.

[0064] Once the user / driver is logged in, a list of available charging contracts can be displayed. For example, the control circuit can 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 linked to the currently logged-in user account. This list can be based on the metadata provided by the charging controller to the user interface controller. Thus, depending on the possible storage scenario, a mechanism in the user management system 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 that user, or can only use these.

[0065] 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.

[0066] In exemplary embodiments, the control circuit 24 can correspond to any controller or processor or a programmable hardware component. For example, the control circuit 24 can also be implemented as software programmed for a corresponding hardware component. In this respect, the control circuit 24 can be implemented as programmable hardware with appropriately adapted software. Any processors, such as digital signal processors (DSPs), can be used. Exemplary embodiments are not limited to a specific type of processor. Any processor or even multiple processors are conceivable for implementation.

[0067] More details and aspects of the user interface controller, the corresponding method, and the computer program are mentioned in connection with the concept or examples described below (e.g., Figs. 1a to 1b, 3 to 4). The user interface controller, the corresponding method, and the computer program may include 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.

[0068] The following is an example of a possible process flow, starting with the creation of a user account. When creating a driver's user account with a vehicle manufacturer, a unique identifier (as a PCID) can be derived from a user identifier (or user account identifier) ​​used by user account management, for example, and assigned to this user. A provisioning certificate according to ISO 15118 can then be created for this PCID. The certificate (i.e., its public part) is stored at relevant external provisioning certificate repositories. The driver / user can then conclude Plug & Charge-enabled contracts for their PCID. The certificate chain or the private part of the provisioning certificate is now stored, for example, in user-specific encrypted form.When a Plug & Charge-capable vehicle is added to the user account, the private part of the provisioning certificate or the certificate chain can be additionally encrypted specifically for the vehicle in a container (e.g., with the vehicle identifier certificate). This container (provisioning container) is stored, for example, on a user-specific basis. When the user logs into the vehicle (as the current vehicle user), the provisioning container can be downloaded and its contents stored on the vehicle in compliance with the standards (as described in connection with Figures 1a to 1b). Subsequently, the contract certificates (charging contracts) requested by the customer, and in particular their private keys, can be installed in compliance with the standards. The active contract certificate can be selected according to the customer's requirements, as can the activation status of the function itself. This information can be stored on a user-specific basis.For example, the setting applies to all vehicles in which the customer is registered. Depending on the available storage space in the vehicle, all or a limited number of contract certificates and provisioning certificates can be stored in the vehicle per user, or deleted and re-downloaded when the user changes. When logging into another vehicle of the vehicle manufacturer, the same procedure is followed, starting with the encryption of the provisioning container for that specific vehicle.

[0069] The following provides a brief overview of the Plug & Charge mechanisms used in the present invention for further understanding. Plug & Charge enables a fully automated and secure charging experience through 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.

[0070] 4) provides a provisioning certificate to an aggregator. In this case, this provisioning certificate includes a user account-specific unique identifier. The vehicle user then concludes a charging contract with the mobility operator (MO). As part of concluding the charging contract, the vehicle user communicates the user account-specific unique identifier (e.g., the PCID, provisioning certificate identifier), which can be done, for example, by the vehicle manufacturer. 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 them (or the contract certificate is retrieved from the OEM as needed).The customer instructs the vehicle manufacturer, and in particular the vehicle, to download and install the contract certificate (5). During the charging process, the vehicle manufacturer or the vehicle communicates (6) via ISO 15118 with the charging point operator (CPO), which in turn can contact the mobility operator via the aggregator and / or a roaming platform regarding payment for the charging process.

[0071] Fig. 4 shows a simplified representation of the technical infrastructure for using Plug & Charge. Fig. 4 shows a charging control unit 410, which may correspond to the charging control unit 10 of Fig. 1a, a user interface control unit 420, which may correspond to the user interface control unit 20 of Figs. 1a and 1b, an intermediary 430 (which can be used in the vehicle, during vehicle production, 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, a charging station operator 470, and the charging station 480. The charging control unit 410 is configured for communication according to ISO 15118 and is responsible for certificate storage and handling (including diagnostic requests).The intermediary is the vehicle manufacturer's root certificate authority 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.

[0072] To install a new contract in the vehicle, and in particular in the charging control unit, the following steps can be performed. To enable the installation of charging contracts (or the corresponding certificates), a so-called commission certificate is required. In the present example, this is carried out by the intermediary 430. The intermediary receives a certificate signing request (CSR), for example from the charging control unit, and provides a private key of the certificate to the charging control unit 430 and a public key to the Plug & Charge coordinator 440. The coordinator publishes the commission certificate (i.e., its public key) to the aggregator 450. The commission certificate contains a cryptographically secured identification code, the user account-specific unique identifier.Alternatively, the intermediary can also receive the certificate signing request from a server, such as the Plug & Charge coordinator 440, for example when a user account is created or when the Plug & Charge functionality is activated in the user account. Accordingly, the generation 435 of the key pair can be carried out, for example, by the charging control unit 410 or a server, such as the Plug & Charge coordinator 440. If a customer signs a charging contract, they provide 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 public key), so that it can only be decrypted by a charging control unit that has the private key of the provisioning certificate.The appropriate commission certificate is determined using the identification code (i.e., the unique identifier). The aggregator 450 receives the encrypted contract certificate and informs the Plug & Charge coordinator 440. The coordinator can then receive the contract certificate and provide it to the charging controller, for example, via a telematics connection. Alternatively, the contract certificate can be exchanged via powerline communication between the charging station 480 and the charging controller 410. If the charging controller has a corresponding contract certificate, it can identify itself via the contract certificate via a connection secured by TLS (Transport Layer Security) communication. The charging station identifies itself via a leaf certificate derived from a V2G (Vehicle-to-Grid) root certificate.Using the charging station's Leaf certificate, a TLS (e.g., TLS 1.2) connection is first established between the charging station and the vehicle (similar to transport encryption on the internet). The contract certificate is then transmitted. The contract certificate is therefore not part of the TLS chain. In the case of TLS 1.3, another certificate is used, which is described in ISO 15518-20. The charging session is authorized between the charging station 480, the charging station operator 470, and the aggregator 450. The charging station operator 470 can identify the mobility service provider 460 via the aggregator 450. Payment is then made, in accordance with the contract, to the mobility service provider 460 via an e-mobility identifier.

[0073] The user interface control unit comprises a system for a graphical user interface, which can be based, for example, on a graphical operating system for mobile devices and can enable on-board user guidance, vehicle configuration, and Plug & Charge functionality, as well as the actual control unit functionality. The latter communicates with the charging control unit 410 and receives information about provisioning and contract certificates stored there from the charging control unit 410. For example, a user can log in to the vehicle via the user interface control unit, whereupon the corresponding provisioning certificate and contract certificate are activated. The graphical user interface system can then provide the option of selecting one of the stored certificates, with the selection being communicated to the charging control unit.The user interface control unit 420 also requests identifiers of new contract certificates (and V2G root certificates) from the Plug & Charge coordinator 440 in order 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 forwarded to the charging control unit. For communication between the user interface control unit 420 and the charging control unit 410, diagnostic communication and / or status / configuration communication can be used, for example.

[0074] The aspects and features described in connection with a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the feature into the further example.

[0075] Examples may further be or relate to a (computer) program with program code for executing one or more of the above methods when the program is executed on a computer, a processor, or other programmable hardware component. Steps, operations, or processes of various of the methods described above may therefore also be executed 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, for example,Digital storage, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives or optically readable digital data storage media may include or be computers, processors, control units, field-programmable logic arrays ((F)PLAs = (Field) Programmable Logic Arrays), field-programmable gate arrays ((F)PGA = (Field) Programmable Gate Arrays), graphics processors (GPU = Graphics Processor Unit), application-specific integrated circuits (ASIC = application-specific integrated circuit), integrated circuits (IC = Integrated Circuit) or one-chip systems (SoC = System-on-a-Chip) programmed to carry out the steps of the methods described above.

[0076] It is further understood that the disclosure of multiple steps, processes, operations, or functions disclosed in the specification or claims should not be construed as necessarily being in the described order, unless explicitly stated in the individual case or technically required. Therefore, the foregoing description does not limit the performance of multiple steps or functions to any particular order. Furthermore, in further examples, a single step, function, process, or operation may include and / or be broken down into multiple sub-steps, functions, processes, or operations.

[0077] If some aspects in the preceding sections were described in connection with a device or system, these aspects are also to be understood as a description of the corresponding method. For example, 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 system.

[0078] The following claims are hereby incorporated into the Detailed Description, each claim being understood to stand on its own as a separate example. It should also be noted that although a dependent claim in the claims refers to a particular combination with one or more other claims, other examples may include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly contemplated unless it is specifically stated that a particular combination is not intended. Furthermore, features of a claim for any other independent claim are also intended to be included, even if that claim is not directly defined as dependent on that other independent claim.

[0079] List of reference symbols

[0080] 5 Charging infrastructure

[0081] 10 Charging control unit

[0082] 12 Interface

[0083] 14 Cryptographically secured element

[0084] 16 Control circuit

[0085] 18 storage

[0086] 20 User interface control unit

[0087] 22 Interface

[0088] 24 control circuit

[0089] 100 vehicles

[0090] 105 storage

[0091] 110 Obtaining a cryptographically secured provisioning certificate

[0092] 120 Obtaining one or more cryptographically secured charging contracts

[0093] 130 Storing the provisioning certificate and at least one charging contract in a cryptographically secured element

[0094] 140 Authenticating the charging controller

[0095] 210 Receiving user input

[0096] 220 Providing a control signal

[0097] 410 charging control unit

[0098] 420 User Interface Control Unit

[0099] 430 Intermediary

[0100] 435 Key generation

[0101] 440 Plug & Charge coordinator

[0102] 450 Aggregator

[0103] 460 mobility service providers

[0104] 470 charging station operators

[0105] 480 charging stations

Claims

Patent claims 1. A charging control device (10) for a vehicle (100), the charging control device comprising: at least one interface (12) for communication with a charging infrastructure (5); a cryptographically secured element (14); and a control circuit (16) designed to: 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, 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, Storing the provisioning certificate and at least one charging contract of the one or more cryptographically secured charging contracts in the cryptographically secured element, and Authenticating the charging control unit to the charging infrastructure based on the at least one charging contract stored in the cryptographically secured element.

2. The charging controller according to claim 1, wherein the unique identifier is not linked to the vehicle.

3. The charging control device according to one of claims 1 or 2, wherein the control circuit is further configured to receive at least one second cryptographically secured provisioning certificate comprising a second unique identifier linked to a user account of a second driver, and one or more second cryptographically secured charging contracts based on the second provisioning certificate, 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.

4. The charging control device according to claim 3, wherein the control circuit is 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 load contract to use for authentication.

5. The charging control device according to claim 3, wherein the control circuit is configured to display 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 display.

6. The charging control device according to claim 5, wherein the control circuit is designed to store the provisioning certificate and the at least one charging contract in encrypted form on a further memory (18) of the charging control device, wherein the further memory is arranged outside the cryptographically secured element.

7. The charging control device according to claim 5, wherein the control circuit is designed to store the provisioning certificate and the at least one charging contract in encrypted form on a further memory (105) outside the charging control device.

8. The charging control device according to one of claims 5 to 7, wherein the provisioning certificate and the at least one charging contract are encrypted by means of a cryptographic key stored within the cryptographically secured element.

9. The charging control device according to one of claims 5 to 8, wherein the control circuit is configured 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 device.

10. The charging control device according to one of claims 3 to 9, wherein the control circuit is configured to at least perform the obtaining and storing of the second provisioning certificate and the one or more second charging contracts in response to a control signal of a user interface control device (20) of the vehicle.

11. A user interface control device (20) for a vehicle (100), the user interface control device comprising: at least one interface (22) for communication with a charging control device (10) of the vehicle and for communication with a user interface; a control circuit (24) designed to: Receiving a user input via the user interface, wherein the user input indicates that a driver of the vehicle is logging into the vehicle using their user account, and Providing 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, wherein 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.

12. The user interface controller of claim 11, wherein the control circuit is configured to output a representation of one or more charging contracts via the user interface based on the provisioning certificate whose unique identifier is linked to the currently logged-in user account.

13. A method for a charging controller (10) for a vehicle (100), the method comprising: obtaining (110) a cryptographically secured provisioning certificate, the cryptographically secured provisioning certificate comprising a unique identifier, the unique identifier being linked to a user account of a driver of the vehicle; Obtaining (120) one or more cryptographically secured charging contracts, wherein the one or more cryptographically secured charging contracts are based on the cryptographically secured provisioning certificate; Storing (130) 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; and Authenticating (140) the charging control device to a charging infrastructure based on the at least one charging contract stored in the cryptographically secured element.

14. A method for a user interface controller (20) for a vehicle (200), the method comprising: Receiving (210) a user input via a user interface, the user input indicating that a driver of the vehicle is logging into the vehicle using their user account; and Providing (220) a control signal to a charging control device 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, wherein the control signal indicates that a second provisioning certificate and at least one user account based on the second A provisioning certificate-based charging contract is to be used for authentication to the charging infrastructure.

15. A program comprising a program code for carrying out the method according to claim 13 or the method according to claim 14 when the program code is executed on a computer, a processor, a control module or a programmable hardware component.

Images