WO2022194658A1 - Verfahren zur autorisierung eines ersten teilnehmers in einem kommunikationsnetz, verarbeitungseinrichtung, kraftfahrzeug und infrastruktureinrichtung - Google Patents

Verfahren zur autorisierung eines ersten teilnehmers in einem kommunikationsnetz, verarbeitungseinrichtung, kraftfahrzeug und infrastruktureinrichtung Download PDF

Info

Publication number
WO2022194658A1
WO2022194658A1 PCT/EP2022/056140 EP2022056140W WO2022194658A1 WO 2022194658 A1 WO2022194658 A1 WO 2022194658A1 EP 2022056140 W EP2022056140 W EP 2022056140W WO 2022194658 A1 WO2022194658 A1 WO 2022194658A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
authorization
participant
data structure
identification information
Prior art date
Application number
PCT/EP2022/056140
Other languages
English (en)
French (fr)
Inventor
Marcel Dietz
Kevin DORLÖCHTER
Kevin Ostheimer
Pavlo FOMENKO
Original Assignee
Audi 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 Audi Ag filed Critical Audi Ag
Priority to CN202280021224.3A priority Critical patent/CN116982332A/zh
Publication of WO2022194658A1 publication Critical patent/WO2022194658A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/06—Electricity, gas or water supply
    • G06Q50/40—
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • 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]
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2240/00—Transportation facility access, e.g. fares, tolls or parking
    • 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

Definitions

  • the invention relates to a method for authorizing a first participant in a communication network, via which several participants communicate, identification information being assigned to each participant.
  • the invention relates to a processing device, a motor vehicle and an infrastructure device.
  • motor vehicles can largely automate interactions with infrastructure facilities, in which payment processes can also be relevant. This can be particularly relevant, for example, when charging a motor vehicle at a public charging facility, since this process should be carried out regularly when parking in public space, for example, and should therefore generate as little effort as possible for a user. Automation can also make it possible, for example, for a fully automated vehicle to approach a charging device itself and carry out the charging process without user intervention or the like.
  • a possible approach to at least automate the payment process and thereby achieve a high level of data economy is to use a blockchain-based payment system, as is known, for example, from publication DE 10 2017 212 904 A1.
  • the advantage of such payment systems is that with high data economy, transactions within the blockchain are secured by the data structure used, so that it can be ensured, for example, that a credit assigned to a user can only be spent once.
  • a credit-based system which means that users have to transfer credit to the blockchain in advance, in particular to a so-called “wallet” assigned to the user and, for example, no direct debit from an external account is possible.
  • a blockchain can only secure transactions within the blockchain itself, so that, for example, an actual charge quantity provided, compliance with specified parameters, compliance with security standards, etc. between transaction participants, for example when charging a vehicle, can be disputed.
  • the second problem can be avoided to a large extent if the individual participants are certified, which can, for example, relate to the measurement accuracy for recording energy quantities and other technical parameters.
  • digital certificates can be used, for example, which can be generated in particular with the aid of asymmetric cryptography methods.
  • the invention is therefore based on the object of specifying an improved method for authorizing a subscriber in a communications network which, in particular, avoids the disadvantages of a central certificate administration.
  • the invention is based on the idea of no longer performing an authorization with the help of a central device, but instead storing the data required for this locally in the respective processing device by replicating the required data structure in different processing devices, in particular in as many processing devices as possible in the communication network .
  • the chaining of the data blocks described can also be used to achieve decentralized storage the data structure is largely tamper-proof by using suitable approaches to add further data blocks or to replicate the data structure.
  • Various implementation options for this are known in particular from the area of blockchains or cryptocurrencies, with credit or financial transactions being stored there instead of authorization data.
  • the sequence of the data blocks can generally be defined by a one- or multi-dimensional acyclic graph.
  • a one-dimensional arrangement is used so that a clear order of the blocks is defined.
  • a subsequent data block can depend in particular on the data block that immediately precedes it in this order.
  • the dependency of the following data block on the content of the at least one preceding data block can consist in particular in that the following data block includes a hash value, in particular a cryptographic hash value, of the preceding data block or data blocks or information dependent thereon.
  • a hash value in particular a cryptographic hash value
  • the further requirement can be selected, for example, in such a way that a certain subscriber can only generate a certain number of blocks in a certain time interval.
  • the frequency with which blocks can be generated by a specific participant can depend in particular on an economic interest of the respective participant in the reliability of the data structure.
  • the economic interest can, for example, be determined on the basis of the data structure itself, for example by taking into account the economic values depicted therein or on the basis of a transaction volume or the like. Such a bet is also referred to as a "proof of stake".
  • the data structure can be a blockchain and/or a distributed transaction database (“distributed ledger”) that stores individual transactions.
  • distributed ledger distributed transaction database
  • one transaction can be stored per data block.
  • earlier transactions are stored in early data blocks in the sequence and later transactions are stored in later data blocks in the sequence.
  • a rough time of the transaction can thus already be estimated based on the data block in which it is stored.
  • the individual transactions are preferably additionally provided with time stamps.
  • Each transaction is preferably signed by the respective participant using secret information, in particular a secret key of a key pair in an asymmetric encryption method.
  • Transactions can also be carried out using so-called "smart contracts".
  • Computer programs that are provided as part of the data structure, in particular as a data block, are triggered and optionally signed.
  • triggering a transaction using such a smart contract requires proof that a participant has the secret information, for example the private key. This proof can be done by signing a request to the smart contract, but a challenge-response method can also be used or similar.
  • the authorization data can include the respective identification information and a variable or a flag which indicates whether the subscriber is authorized with this identification information or not.
  • the authorization data preferably also includes information about which subscriber created and/or changed the authorization data and/or a digital signature of this subscriber and/or a time stamp.
  • all participants can be or include processing devices. However, there can also be subscribers without their own or permanently assigned processing device. For example, identification information can be assigned to a user in order to identify and authorize them even if several users use the same processing device or the same user uses different processing devices.
  • the method according to the invention can also be used to authorize both parties and thus enable two participants to function on both sides. This can make it possible, for example, for a motor vehicle to be charged at a charging device only if it has been determined on the one hand by the vehicle that the charging device is authorized and on the other hand by the charging device that the motor vehicle is authorized. It is possible that all participants are always connected to the communication network. However, use cases are also possible in which individual participants or all participants are temporarily separated from the communication network and, for example after a renewed connection to the communication network, first update the internal data structure, if necessary. This can happen, for example, if a valid data structure with a larger number of blocks is provided by another participant. The current data structure can then be used to authorize other participants as required.
  • the authorization data can be created and/or changed in the data structure in that an additional data block that depends on at least one of the preceding data blocks of the data structure is appended to the data structure by a processing device that is a participant or part of a participant .
  • This procedure is expedient in particular if the authorization condition always evaluates only the most recent or the most recent valid authorization data. Conditions for the validity of a transaction stored in the data structure or the authorization data will be explained later.
  • the block can be added by the subscriber who triggers the creation and/or change of the authorization data.
  • the block can be added by the subscriber who triggers the creation and/or change of the authorization data.
  • the validity of the transaction can optionally be checked there, it being possible, for example, to check whether the transaction has been validly signed by the participant, whether the participant is authorized to carry out this process, etc. After a successful check or if such a check is not carried out, several transactions can be combined into one data block, which is added to the data structure.
  • the authorization data can include the identification information of that participant through which the creation and/or modification of the authorization data was triggered, and/or a signature linked to the identification information, with the fulfillment of the authorization condition being dependent on the identification information and/or the signature depends.
  • the authorization condition can only be met or can be met if the identification information or the signature is assigned to such an authorized participant.
  • the link between the signature and the identification information can be taken from the data structure or can be checked on the basis of the data structure and/or the identification information.
  • the signature can be created using a private key using a cryptographic signature method, various of which are known. If the identification information corresponds to the public key of this key pair, the signature can be checked directly on the basis of the identification information. Since the public key is generally relatively long, it can be advantageous to use a shorter alias as identification information instead, with the assignment of this alias to the private key being able to be stored in the data structure.
  • the authorization condition can only be fulfilled or can only be fulfilled if there are authorization data assigned to the data structure of the identification information and/or the signature, which indicate authorization of the subscriber creating and/or changing the authorization data.
  • the authorization data can indicate such an authorization per se.
  • indirect authorization is also possible.
  • the authorization data can give a subscriber a higher-level authorization that authorizes him to create or change sub-authorization data.
  • the authorization condition can be fulfilled or can be fulfilled if sub-authorization data for the subscriber creating and/or changing the authorization data indicate that he is authorized to do so, with the sub-authorization data having identification information and/or a subscriber's signature, who is authorized by authorization data to create or change sub-authorization data.
  • a multi-level hierarchy of authorizations is also possible.
  • the authorization data can be created and/or changed in the data structure in that an additional data block that depends on at least one of the preceding data blocks of the data structure is appended to the data structure by a processing device that is a participant or part of a participant. As explained above with regard to the authorization data, only the most recent valid authorization data can be taken into account. As has also already been explained with regard to the authorization data, a participant or its processing device can trigger the creation or change by means of a transaction which, taken alone or together with other transactions, is appended to the data structure as a data block.
  • the creation or creation and/or modification of the authorization data can take place automatically by a program which is executed by a processing device of at least one participant and which is stored in particular in the data structure.
  • Storing programs in data structures made up of concatenated data blocks, for example in blockchains, is known per se, such programs also being referred to as “smart contracts”.
  • the program code is typically stored in a machine-independent script language and can be stored in a relatively early data block in order to achieve a high level of protection against manipulation. surgery Nationally, the program code of the program can be uniform for each participant interacting with the data structure or blockchain. This enables a defined set of rules and creates trust among the participants.
  • Requesting and/or changing the authorization data can depend on voting data provided by a number of participants to the processing device executing the program, in particular as part of the data structure.
  • the program or the smart contract is controlled by certain participants who are authorized to vote, which means that there is no need for a central authority.
  • the program that automatically creates and/or changes the authorization data represents the central authority and can therefore also be referred to as the "root contract”.
  • the collection of voting data can be triggered in a targeted manner, for example by calling up this program by a participant, where, for example, corresponding requests can be sent to the participants entitled to vote, after which they cast their vote and authenticate them, for example, with a signature.
  • voting data can be added to the data structure by the participants entitled to vote before this point in time or stored in a transaction buffer so that the program can automatically evaluate the votes.
  • authorization data can only be created and/or changed if there is a minimum number of yes votes and fewer no votes than yes votes. It may also be possible here to assign different vote weights to different participants, for example on the basis of their economic interest in robustness the data structure.
  • the voting rights of the participants can also be managed via the data structure. For example, voting rights data can be stored there for the individual participants, which indicate whether they are entitled to vote or not and how many votes they have.
  • the entitlement data, authorization data, voting rights, etc. can be stored independently in the data structure. However, it is also possible to combine several of these data sets in a common data set, which describes, for example, the identification information of the respective subscriber and their rights. Instead of storing the individual rights explicitly, the individual participant can also be assigned a specific role, which in turn is assigned specific rights, for example via a data record in the data structure.
  • the right to create and/or change authorization records can apply generally or can relate to specific groups of participants. If, for example, charging stations, motor vehicles and vehicle users are participants in the method, a vehicle manufacturer as a participant may only be authorized to create and/or change authorization data relating to motor vehicles and/or their users. An operator of charging devices, on the other hand, can only be authorized to create or change authorization data for these charging stations.
  • At least part of the data stored in the data structure may not be legible or not legible in plain text for some of the participants, in particular by encrypting this data. This allows in particular different reading rights can be implemented for different participants.
  • data can be encrypted by the public keys of all parties who should have access to that data, and the data cannot be stored in plain text. This means that only those participants who know a respective assigned private key have access to the stored data.
  • meta data for the respective identification information can relate, for example, to personal data of a user who is a participant or of a vehicle owner of a participating vehicle.
  • meta data for example, to personal data of a user who is a participant or of a vehicle owner of a participating vehicle.
  • such metadata can be encrypted, for example, using the subscriber's public key, so that it can only be read out if this subscriber's private key is known. In this case, deleting the private key makes the data unreadable.
  • Participants can have read rights for their own public keys and metadata. Subscribers who, in particular as explained above through authorization data stored in the data structure, are authorized to create and/or change authorization data can also be referred to as administrators. Administrators can have read rights to the public keys and metadata of participants whose authorization data they created. In addition, they can have a reader genuinely for the identification information and/or the public key of participants with whom participants authorized by them interact, ie for example participants to or from whom a transaction takes place. Optionally, access to metadata for these participants or at least parts of the metadata for these participants can also be possible. For example, motor vehicle manufacturers and operators of charging devices can have reading rights for the respective objects and users that interact with one another and form participants. However, motor vehicle manufacturers can preferably not read any information on participants, ie in particular on motor vehicles or users, from other motor vehicle manufacturers or charging device operators cannot read any information on participants, in particular charging devices or users, from other charging device operators.
  • Administrators can create identification information for a participant, in particular by generating a key pair for that participant. You can activate participants or the identification information assigned to them by creating the corresponding authorization data or changing them in such a way that the function is released. Various functions, services, services, etc. can also be released separately or together as a function.
  • the respective administrator can trigger a status change of the respective participant by changing the authorization data, for example setting a flag or a variable to true or false.
  • Administrators can delete metadata of the participants they have authorized or created. With the deletion of the metadata and the link between metadata and identification information or public key, a high level of data protection is achieved, since there is no longer any directly personal information and transactions stored in the data structure can no longer be assigned to a specific person.
  • a motor vehicle can be used as the first participant and an infrastructure device can be used as the second participant, or vice versa.
  • an entry into a certain area can be blocked by a barrier or the like and only released after the motor vehicle has been authorized.
  • a number ment requirement of an infrastructure facility for example for driving in a certain area or parking, can only be met after the infrastructure facility has been authorized.
  • Authorization of infrastructure facilities can also be relevant, for example, if control of the motor vehicle for an automated parking process or the like is to be handed over to the infrastructure facility in order to ensure that the infrastructure facility meets specified requirements.
  • the infrastructure device can in particular be a charging device for charging an energy store of the motor vehicle.
  • a motor vehicle can be used particularly advantageously as the first participant and a charging device for charging an energy storage device of the motor vehicle can be used as the second participant or vice versa, with the function of the second participant being necessary for charging the energy storage device using the charging device.
  • authorization can be carried out on both sides, in particular, so that charging only takes place when both the charging device is authorized for the motor vehicle and the motor vehicle is authorized for the charging device.
  • As a function of the charging device it is thus possible to release electricity or, on the motor vehicle side, charging control and/or a payment function.
  • the data structure can also store transactions between participants, in particular with regard to enabled functions.
  • a transaction relating to a charging process can include, for example, an identification of the transaction as relating to a charging process, the identification information for the motor vehicle and the charging device, and an amount of transmitted energy.
  • such a transaction can optionally include a current state of charge of the energy storage device of the motor vehicle, a credit balance of the motor vehicle or a user of the motor vehicle in a digital currency, quality criteria of the charging station, for example the accuracy of a power measurement, the maximum power that can be provided or the like, etc .
  • the transaction can also include an evaluation of the first participant by the second participant or vice versa, for example an evaluation of the charging process by the motor vehicle or the charging station. This information can be useful, for example, to provide vehicle manufacturers or charging facility operators with information on possible improvements. For example, corresponding data can be evaluated by the vehicle manufacturer in order to supplement information on the charging devices offered by the vehicle or to take corresponding information into account when planning the route.
  • the invention also relates to a motor vehicle that includes a processing device according to the invention, and an infrastructure device, in particular a charging device, that includes a processing device according to the invention.
  • FIG. 1 exemplary embodiments of a motor vehicle according to the invention and an infrastructure device according to the invention, namely a charging device, which each comprise an exemplary embodiment of a processing device according to the invention and are used within the scope of an exemplary embodiment of the method according to the invention,
  • FIG. 3 shows an authorization hierarchy that can be implemented using the method according to the invention.
  • 1 shows an operating situation in which two subscribers 1, 2 in a communication network 11 are to be authorized in relation to the respective other subscriber 1, 2 to carry out a specific function.
  • subscriber 1 is a motor vehicle and subscriber 2 is a charging station.
  • functions 26, 27 of a respective charging controller 24, 25 are to be enabled in each case in order to enable charging of an energy store 59 of subscriber 1, ie of the motor vehicle.
  • the participants 1, 2 are each assigned identification information 7, 8, for example a public key of a key pair of an asymmetric encryption method, via which the respective participant 1, 2 can be identified.
  • identification information 7, 8 for example a public key of a key pair of an asymmetric encryption method, via which the respective participant 1, 2 can be identified.
  • a corresponding authorization can in principle be carried out by other participants 3, 4, 5 in the communication network, in particular by participants 4,
  • the participant 4 can be a backend system of a motor vehicle manufacturer and authorizations for motor vehicles 1 manufactured by him or their users 6 and revoked.
  • the subscriber 5, on the other hand, can be an operator of charging devices who can issue and revoke authorizations for charging devices operated by him.
  • the respective identification information 7, 8 is first transmitted by the other of the participants 1, 2 to that participant 1, 2 who is to provide the corresponding function 26, 27.
  • This is shown schematically in FIG. 1 by the arrows 9, 10, with this data exchange taking place via respective communication devices 20, 21 from processing devices 12, 13 of the participants 1, 2.
  • the exchange of information can take place via the communication network 11 or also via a separate communication path, for example via a short-range wireless communication path or, if charging operation is desired, also via the charging cable.
  • a known approach to checking authorization when identification information 7, 8 is known is to query a central facility as to whether authorization for this identification information 7, 8 is present.
  • This requires the operation of a relatively complex central facility and, in addition, a robust communication link to this central facility is required for authorization. Therefore, in the method explained, a different approach is used for authorizing the participants 1, 2 in relation to the respective other participant 1, 2.
  • the authorization takes place locally through the processing device 12, 13 of the respective participant.
  • this has a memory device 18, 19 in which, in addition to the respective own identification information 7, 8, which in the example is a public key, secret information, in the example a private key 14 , 15, and a data structure 16, 17 is stored.
  • the data structure 16, 17 can implement a decentralized transaction database.
  • the processing steps are carried out by a respective arithmetic unit 22, 23.
  • the respective data structure 16, 17 comprises a plurality of data blocks 34 which are linked to one another in such a way that the content of the respective subsequent data block 34 depends on the content of the preceding data block 34.
  • this is implemented in that all data blocks 34 except for the first data block store a cryptographic hash value 35 of the preceding data block.
  • the data structure is highly tamper-proof. Possible approaches for this have already been discussed in the general part and are well known in particular from the area of blockchains or cryptocurrencies.
  • At least parts of the data blocks 34 each store at least one transaction 36, i.e. a process that is carried out by one of the participants 1 to 6 or automatically by controlling the programs 48, 54, 56 controlling the data structure.
  • a charging data record 37 can be stored as a transaction 36, which describes a previous charging process of the motor vehicle 1 at the charging device 2.
  • the charging data record 37 can include, for example, the identification information 7 of the motor vehicle, a signature 38 created using the private key 14 of the motor vehicle, the identification information 8 of the charging station, an amount of electricity 39 transmitted during this charging process, additional information 40, for example an evaluation of the charging process , and a timestamp 41 . If, for example, corresponding loading data sets 37 are provided both by the motor vehicle and by the loading device, which are then stored in one of the blocks 34 of the data structures 16, 17, a tamper-proof documentation of the loading process is thereby achieved.
  • the data structures 16, 17 stored by the individual participants or processing devices 12, 13 are generally identical, at least as far as older data blocks 34 are concerned.
  • it can be queried whether there is a data structure with a higher number of blocks in the communications network 11 than the locally stored data structure 16, 17 is still available. If this is the case, the validity of this data structure can be checked and, if the data structure with a larger number of blocks is valid, it can be saved in order to replace the data structure 16, 17 used up to now.
  • Such a data structure 16, 17 is used in the method according to the invention in order to store authorization data 42, 49 for the respective subscribers 1 to 6. This is done in the following example regarding authorization of the participant 2 explained, but can also be transferred to the authorization of other participants.
  • the processing device 12 of the participant 1 After the identification information 8 of the participant 2 has been transmitted to the processing device 12 of the participant 1, the latter checks whether the locally stored data structure 16 contains authorization data 42, 49 that are assigned to this identification information 8, whether they are valid and whether they have a View participant 2 authorization.
  • the authorization condition 47 can be checked in particular by a program 48 which is stored as part of the data structure 16, 17. As a result, a high degree of protection against manipulation for the program 48 can be achieved.
  • the authorization condition 47 can initially only take account of the most recent authorization data 42 relating to the subscriber 2 or his or her identification information 8 .
  • the respective authorization data 42, 49 to summarize the identification information 8 to which they are assigned, an identification information 43 of that participant 1 to 6, which has triggered the creation or the change in the authorization data 42, 49, a signature 44 of this participant, a status 45 of the authorization and a timestamp 46.
  • the status 45 can be, for example, a flag that indicates whether there is authorization or not and can have, for example, the value 1 or 0 or "True" or "False".
  • a first step it is checked whether the respective authorization data 42, 49 are valid.
  • the signature 44 is valid, which is possible using conventional cryptographic signature methods.
  • the status information 45 is read out, which indicates whether the subscriber 2 is authorized or not. If the status information 45 indicates an authorization, then the function 27 in the motor vehicle is enabled.
  • the check for the earlier authorization data 49 is repeated and a corresponding procedure is followed. If the earlier authorization data 49 is also invalid and there is no further authorization data for the identification information 8 in the data structure 16, then the authorization condition 47 is not fulfilled and the function 27 remains blocked since the subscriber 2 is not authorized for a charging process.
  • the check as to whether the user identified by the identification information 43 was authorized to create or change the authorization data 42, 49 can be checked, for example, by the program 54, which is also provided by the respective data structure 16, 17.
  • authorization to create and change authorization data 42, 49 can be granted or revoked as needed in order to designate them as administrators 28, 29 or to remove them from the pool of administrators 28, 29.
  • FIG. 3 schematically showing the authorization pyramid used.
  • motor vehicles or their users in the example participants 1 and 6, and charging devices, in the example participant 2, are ultimately to be authorized to carry out charging processes.
  • the dashed line 58 a clear separation can be made here, so that on the one hand administrators 28, for example, can
  • backend systems of charging facility operators can serve as administrators 29 who authorize the charging facilities they operate.
  • a change in the authorization of the participants 4, 5 as an administrator 28, 29 is preferably not carried out directly by an individual participant 1-6, but by a program 56, which can also be provided in particular via the data structure 16, 17, and which stores of authorization data 50, 55 in the data structure 16, 17 when corresponding voting data 57 from participants 1 to 6 entitled to vote are present.
  • voting weights are able to depend in particular on the economic interest in the robustness of the data structure 16, 17, for example on the number of participants 1 to 6 authorized by you, on sales generated by loading processes or similar.
  • the voting weights can thus be derived directly from the data structure itself. In other configurations, however, it would also be possible for voting rights to be independent of the administrator status.
  • the retrieval of the voting data 57 by the program 56 can take place, for example, in that the program 56 is run locally by a sub- participant is called, who then sends corresponding requests to other participants entitled to vote, who can, for example, express their agreement by signed replies. If, for example, a sufficient number of yes votes and in particular a smaller number of no votes is recorded by the program 56, new authorization data 50, 55 can be created as a transaction by this new authorization data, which can be used immediately or at a later date as part of a additional data blocks 34 attached to the data structure 16, 17 who the. Since this leads to a larger number of blocks in the data structure 16, 17, the correspondingly extended data structure 16, 17 is adopted by the other participants and the changes in authorization are thus communicated to them.
  • the authorization condition 47 e.g. by the program 54, it can also be checked whether the subscriber 1 to 6 identified by the identification information 43 was authorized to create the respectively evaluated authorization data 42, 49.
  • the program 54 can check whether authorization data 50, 55 assigned to this identification information 43 are present in the data structure 16, 17.
  • the authorization data 50, 55 each include the identification information 43 to which they are assigned, and status information 51, which is represented, for example, by a 0 or 1 value or a “true” or “false” value. value indicates whether such permission exists. Additional information can be stored for which of the participants 1 to 6 or for which type of participants 1 - 6 this authorization applies.
  • authorization data 50 is invalid, for example due to incorrect signatures, earlier authorization data 55 is used and the corresponding procedure is repeated. If no valid authorization data is found in the data structure 16, 17, it is assumed that the subscriber 1 to 6 designated by the identification information 43 was not authorized to create the authorization data 42, 49, which means that these are considered invalid.
  • corresponding data can be encrypted with the public keys of those participants 1 to 6 who are to have read access to the corresponding data, with which only these participants 1 to 6 can read the data, since the assigned private key 14, 15 is known.
  • the individual participants 1 to 6 are preferably only identified by their identification information 7, 8 and other metadata, such as addresses, account details or the like, are managed by respective administrators 28, 29, for example backend servers from vehicle manufacturers or charging facility operators.

Abstract

Verfahren zur Autorisierung eines ersten Teilnehmers (1 – 6) in einem Kommunikationsnetz (11), über das mehrere Teilnehmer (1 – 6) kommunizieren, wobei den Teilnehmern (1 – 6) jeweils eine Identifikationsinformation (7, 8, 43) zugeordnet ist, umfassend die Schritte: - Übertragen der Identifikationsinformation (7, 8, 43) des ersten Teilnehmers (1 – 6) an einen zweiten Teilnehmer (1 – 6) in dem Kommunikationsnetz (11), der eine Verarbeitungseinrichtung (12, 13, 30, 31) ist oder umfasst, - Prüfen, ob in einer Datenstruktur (16, 17) der Identifikationsinformation (7, 8, 43) zugeordnete Autorisierungsdaten (42, 49) vorhanden sind, durch die Verarbeitungseinrichtung (12, 13, 30, 31), wobei eine Datenstruktur (16, 17) verwendet wird, die auf mehreren als Teilnehmer (1 – 6) über das Kommunikationsnetz (11) kommunizierenden Verarbeitungseinrichtungen (12, 13, 30, 31) repliziert ist und die mehrere Datenblöcke (34) umfasst, die in einer Abfolge geordnet und derart miteinander verknüpft sind, dass der Inhalt eines jeweiligen nachfolgenden Datenblocks (34) vom Inhalt wenigstens eines vorangehenden Datenblocks (34) abhängt, - Freigabe einer Funktion (26, 27) des zweiten Teilnehmers (1 – 6) ausschließlich bei Erfüllung einer die Autorisierungsdaten (42, 49) auswertenden Autorisierungsbedingung (47), die nur dann erfüllbar ist, wenn der Identifikationsinformation (7, 8, 43) zugeordnete Autorisierungsdaten (42, 49) vorhanden sind.

Description

Verfahren zur Autorisierung eines ersten Teilnehmers in einem Kommunikati onsnetz, Verarbeitungseinrichtung, Kraftfahrzeug und Infrastruktureinrichtung
BESCHREIBUNG:
Die Erfindung betrifft ein Verfahren zur Autorisierung eines ersten Teilneh mers in einem Kommunikationsnetz, über das mehrere Teilnehmer kommu nizieren, wobei den Teilnehmern jeweils eine Identifikationsinformation zuge ordnet ist. Daneben betrifft die Erfindung eine Verarbeitungseinrichtung, ein Kraftfahrzeug und eine Infrastruktureinrichtung.
Es ist zweckmäßig, wenn Kraftfahrzeuge Interaktionen mit Infrastrukturein richtungen, bei den auch Bezahlvorgänge relevant sein können, weitgehend automatisiert abwickeln können. Besonders relevant kann dies beispiels- weise beim Laden eines Kraftfahrzeugs an einer öffentlichen Ladeeinrichtung sein, da dieser Vorgang beispielsweise regelmäßig beim Parken im öffentli chen Raum durchgeführt werden soll und somit möglichst wenig Aufwand für einen Nutzer erzeugen soll. Eine Automatisierung kann es beispielsweise auch ermöglichen, dass ein vollautomatisiertes Fahrzeug eine Ladeeinrich- tung selbst anfährt und den Ladevorgang ohne Nutzereingriff ausführt oder Ähnliches.
Auch für andere Vorgänge, beispielsweise für das Befahren von nur einge schränkt oder beispielsweise gegen Zahlung einer Gebühr befahrbaren Be- reichen, beispielsweise von Parkhäusern oder bestimmten Innenstadtberei chen, ist es vorteilhaft einen entsprechenden Vorgang zu automatisieren. Zu gleich soll jedoch vermieden werden, dass an eine Vielzahl von unter Um ständen nicht vertrauenswürdigen Einrichtungen persönliche Daten eines Fahrzeughalters, Kontodaten oder Ähnliches bereitgestellt werden. Ein möglicher Ansatz, um zumindest den Zahlungsvorgang zu automatisie ren und hierbei eine hohe Datensparsamkeit zu erreichen, ist es, ein Block- chain-basiertes Bezahlsystem zu nutzen, wie es beispielsweise aus der Druckschrift DE 10 2017 212 904 A1 bekannt ist. Der Vorteil solcher Bezahl systeme ist, dass bei hoher Datensparsamkeit Transaktionen innerhalb der Blockchain durch die verwendete Datenstruktur gesichert sind, sodass bei spielsweise sichergestellt werden kann, dass ein einem Benutzer zugeordne tes Guthaben nur einmal ausgegeben werden kann.
Es bleibt jedoch einerseits der Nachteil, dass es sich systembedingt um ein guthabenbasiertes System handelt, das heißt, dass Nutzer vorab Guthaben in die Blockchain, insbesondere in eine dem Nutzer zugeordnete sogenannte „Wallet“, transferieren müssen und beispielsweise keine direkte Abbuchung von einem externen Konto möglich ist. Zudem können durch eine Blockchain nur Transaktionen innerhalb der Blockchain selbst abgesichert werden, so dass beispielsweise eine tatsächliche bereitgestellte Lademenge, die Einhal tung vorgegebener Parameter, eine Einhaltung von Sicherheitsstandard etc. zwischen Transaktionsteilnehmern, beispielsweise beim Laden eines Fahr zeugs, strittig sein können.
Das zweite Problem lässt sich weitgehend vermeiden, wenn für die einzelnen Teilnehmer eine Zertifizierung erfolgt, die beispielsweise eine Messgenauig keit für eine Energiemengenerfassung und weitere technische Parameter be treffen kann. Um eine solche Zertifizierung automatisiert prüfen zu können, sind beispielsweise digitale Zertifikate nutzbar, die insbesondere mit Hilfe von asymmetrischen Kryptographieverfahren generiert werden können.
Soll es jedoch möglich sein, entsprechende Zertifikate zu wiederrufen, bei spielsweise wenn ein technischer Defekt oder ein gezielter Missbrauch er kannt wird, ist eine zentrale Zertifikatverwaltung erforderlich. Bei dieser han delt es sich jedoch um einen „Single Point of Failure“, womit sie hoch verfüg bar und hoch redundant ausgelegt sein muss. Hierdurch entstehen hohe Be triebskosten. Zudem führt die Nutzung einer zentralen Zertifikatverwaltung auch zu potentiellen Problemen, wenn beispielweise eine Betreiber deren Betrieb unerwartet einstellt.
Der Erfindung liegt somit die Aufgabe zugrunde, ein demgegenüber verbes sertes Verfahren zur Autorisierung eines Teilnehmers in einem Kommunikati onsnetz anzugeben, das insbesondere die Nachteile einer zentralen Zertifi katsverwaltung vermeidet.
Die Aufgabe wird durch ein Verfahren der eingangs genannten Art gelöst, dass die folgenden Schritte umfasst:
- Übertragen der Identifikationsinformation des ersten Teilnehmers an einen zweiten Teilnehmer in dem Kommunikationsnetz, der eine Ver arbeitungseinrichtung ist oder umfasst,
- Prüfen, ob in einer Datenstruktur der Identifikationsinformation zuge ordnete Autorisierungsdaten vorhanden sind, durch die Verarbei tungseinrichtung, wobei eine Datenstruktur verwendet wird, die auf mehreren als Teilnehmer über das Kommunikationsnetz kommuni zierenden Verarbeitungseinrichtungen repliziert ist und die mehrere Datenblöcke umfasst, die in einer Abfolge geordnet und derart mitei nander verknüpft sind, dass der Inhalt eines jeweiligen nachfolgen den Datenblocks vom Inhalt wenigstens eines vorangehenden Da tenblocks abhängt,
- Freigabe einer Funktion des zweiten Teilnehmers ausschließlich bei Erfüllung einer die Autorisierungsdaten auswertenden Autorisie- rungsbedingung, die nur dann erfüllbar ist, wenn der Identifikationsin formation zugeordnete Autorisierungsdaten vorhanden sind.
Der Erfindung liegt die Idee zugrunde, eine Autorisierung nicht mehr mit Hilfe einer zentralen Einrichtung durchzuführen, sondern die hierfür erforderlichen Daten lokal in der jeweiligen Verarbeitungseinrichtung vorzuhalten, indem die erforderliche Datenstruktur in verschiedenen Verarbeitungseinrichtungen, insbesondere in möglichst allen Verarbeitungseinrichtungen in dem Kommu nikationsnetz, repliziert ist. Durch die beschriebene Verkettung der Datenblö cke kann zugleich erreicht werden, dass durch die dezentralen Speicherung der Datenstruktur diese weitgehend manipulationssicher ist, indem geeignete Ansätze zum Anfügen weiterer Datenblöcke bzw. zur Replikation der Daten struktur genutzt werden. Verschiedenen Implementierungsmöglichkeiten hierfür sind insbesondere aus dem Bereich der Blockchains bzw. Krypto- Währungen bekannt, wobei dort statt Autorisierungsdaten Guthaben bzw. Fi nanztransaktionen gespeichert werden.
Da somit ein dezentrales und insbesondere manipulationssicheres System zur Prüfung einer Autorisierung genutzt wird, kann darauf verzichtet werden, eine vertrauenswürdige zentrale Zertifikatsverwaltung zu nutzen. Stattdessen kann die erforderliche Datensicherheit und somit das Vertrauen in den Inhalt der Datenstruktur durch technische Maßnahmen erreicht werden. Hierdurch bleibt das System auch beim Ausscheiden einzelner Teilnehmer stets robust und es entfallen die Kosten für eine zentrale Zertifikatsverwaltung.
Die Abfolge der Datenblöcke kann allgemein durch einen ein- oder mehrdi mensionalen azyklischen Graphen definiert sein. Im einfachsten Fall wird eine eindimensionale Anordnung genutzt, sodass eine eindeutige Reihen folge der Blöcke festgelegt ist. Hierbei kann ein nachfolgender Datenblock insbesondere von dem in dieser Reihenfolge unmittelbar vorangehenden Da tenblock abhängen.
Die Abhängigkeit des nachfolgenden Datenblocks vom Inhalt des wenigstens einen vorangehenden Datenblocks kann insbesondere darin bestehen, dass der nachfolgende Datenblock einen Hashwert, insbesondere einen krypto- grafischen Hashwert, des vorangehenden Datenblocks bzw. der vorange henden Datenblöcke oder eine hiervon abhängende Information umfasst. Hierdurch ist es allenfalls mit sehr hohem Rechenaufwand möglich, eine Mo difikation eines Datenblocks aufzufinden, die nicht zur Änderung des Hash- wertes und somit zu einer Inkonsistenz mit dem nachfolgenden Datenblock führt. Möchte somit ein Angreifer einen Datenblock verändern, muss er auch alle nachfolgenden Datenblöcke neu generieren. Ist ein Hinzufügen gültiger Datenblöcke zur Datenstruktur beispielsweise re lativ rechenaufwändig, was bezüglich Blockchains als „Proof of Work“ be zeichnet wird, oder aufgrund von weiteren Anforderungen eingeschränkt, ins besondere durch einen sogenannten „Proof of Stake“, und wird jeweils die Datenstruktur mit der höchsten Blockzahl durch die Verarbeitungseinrichtun gen als aktuell gültige Datenstruktur identifiziert und repliziert, kann insge samt eine sehr hohe Manipulationssicherheit erreicht werden.
Die weitere Anforderung kann beispielsweise so gewählt sein, dass ein be stimmter Teilnehmer in einem bestimmten Zeitintervall nur eine bestimmte Anzahl von Blöcken generieren kann. Wie häufig Blöcke durch einen be stimmten Teilnehmer generierbar sind, kann insbesondere von einem ökono mischen Interesse des jeweiligen Teilnehmers an der Verlässlichkeit der Da tenstruktur abhängen. Das ökonomische Interesse kann beispielweise auf Basis der Datenstruktur selbst, beispielsweise durch Berücksichtigung der darin abgebildeten ökonomischen Werte oder auf Basis eines Transaktions volumens oder Ähnlichem ermittelt werden. Ein solcher Einsatz wird auch als „Proof of Stake“ bezeichnet.
Die Datenstruktur kann insbesondere eine Blockchain und/oder eine verteilte Transaktionsdatenbank („distributed ledger“), die einzelne Transaktionen speichert, sein. Im einfachsten Fall kann eine Transaktion pro Datenblock gespeichert werden. Bei hohen Transaktionszahlen kann es jedoch vorteil haft sein, mehrere Transaktionen in einem Datenblock zusammenzufassen. Insbesondere werden frühere Transaktion in frühen Datenblöcken der Ab folge und spätere Transaktionen in späteren Datenblöcken der Abfolge ge speichert. Ein grober Zeitpunkt der Transaktion ist somit bereits aufgrund des Datenblocks, in dem sie gespeichert ist, abschätzbar. Bevorzugt werden die einzelne Transaktionen jedoch zusätzlich mit Zeitstempeln versehen.
Bevorzugt wird jede Transaktion durch den jeweiligen Teilnehmer mit Hilfe einer Geheiminformation, insbesondere eines geheimen Schlüssels eines Schlüsselpaares in einem asymmetrischen Verschlüsslungsverfahren, sig niert. Transaktionen können auch durch sogenannte „Smart Contracts“, also Computerprogramme, die als Teil der Datenstruktur, insbesondere als ein Datenblock, bereitgestellt werden, ausgelöst und optional signiert werden. Hierbei erfordert das Auslösen einer Transaktion durch einen solchen Smart Contract insbesondere den Nachweis, dass ein Teilnehmer die geheime In formation, also beispielsweise den privaten Schlüssel, besitzt. Dieser Nach weis kann durch Signieren einer Anfrage an den Smart Contract erfolgen, es kann jedoch auch ein Challenge-Response-Verfahren genutzt werden oder Ähnliches.
Die Autorisierungsdaten können in einem einfachen Beispiel die jeweilige Identifikationsinformation und eine Variable bzw. ein Flag umfassen, die bzw. das angibt, ob der Teilnehmer mit dieser Identifikationsinformation autorisiert ist oder nicht. Bevorzugt umfassen die Autorisierungsdaten jedoch zusätzlich Informationen, welcher Teilnehmer die Autorisierungsdaten angelegt und/oder verändert hat, und/oder eine digitale Signatur dieses Teilnehmers und/oder einem Zeitstempel.
Prinzipiell können alle Teilnehmer Verarbeitungseinrichtungen sein oder um fassen. Es können jedoch auch Teilnehmer ohne eigene oder fest zugeord nete Verarbeitungseinrichtung existieren. Beispielsweise kann einem Nutzer eine Identifikationsinformation zugeordnet werden, um diesen auch dann zu identifizieren und zu autorisieren, wenn mehrere Nutzer die gleiche Verarbei tungseinrichtung nutzen bzw. der gleiche Nutzer verschiedene Verarbei tungseinrichtungen nutzt.
Wird die Datenstruktur auch in der Verarbeitungseinrichtung des ersten Teil nehmers repliziert, ist mit dem erfindungsgemäßen Verfahren auch eine beidseitige Autorisierung und damit eine beidseitige Funktionsfreigabe von zwei Teilnehmern möglich. Dies kann es beispielsweise ermöglichen, dass ein Ladebetrieb eines Kraftfahrzeugs an einer Ladeeinrichtung nur dann frei gegeben wird, wenn eine einerseits fahrzeugseitig ermittelt wurde, dass die Ladeeinrichtung autorisiert ist, und andererseits ladeeinrichtungsseitig ermit telt wurde, dass das Kraftfahrzeug autorisiert ist. Es ist möglich, dass alle Teilnehmer stets an dem Kommunikationsnetz an gebunden sind. Es sind jedoch auch Anwendungsfälle möglich, in denen ein zelne Teilnehmer oder alle Teilnehmer vorübergehend vom Kommunikati onsnetz getrennt werden und beispielsweise nach einer erneuten Verbin dung mit dem Kommunikationsnetz zunächst, falls erforderlich, die interne Datenstruktur aktualisieren. Dies kann z.B. erfolgen, falls eine gültige Daten struktur mit einer größeren Blockzahl von einem anderen Teilnehmer bereit gestellt wird. Anschließend kann die nun aktuelle Datenstruktur zur bedarfs gerechten Autorisierung anderer Teilnehmer genutzt werden.
Die Autorisierungsdaten können dadurch in der Datenstruktur angelegt und/oder verändert werden, dass durch eine Verarbeitungseinrichtung, die ein Teilnehmer oder ein Teil eines Teilnehmers ist, ein zusätzlicher Daten block an die Datenstruktur angefügt wird, der von wenigstens einem der vor angehenden Datenblöcke der Datenstruktur abhängt. Dieses Vorgehen ist insbesondere zweckmäßig, wenn die Autorisierungsbedingung stets nur die aktuellsten bzw. die aktuellsten gültigen Autorisierungsdaten auswertet. Be dingungen für die Gültigkeit einer in der Datenstruktur gespeicherten Trans aktion bzw. der Autorisierungsdaten werden später noch erläutert.
Im einfachsten Fall kann das Hinzufügen des Blocks durch jenen Teilnehmer erfolgen, durch den das Anlegen und/oder die Änderung der Autorisierungs daten ausgelöst wird. Es ist jedoch auch möglich und in Implementierungen von Blockchains bzw. verteilten Transaktionsdatenbanken durchaus üblich, mehrere Transaktionen, insbesondere auch Transaktionen von verschiede nen Teilnehmern, in einem Datenblock zusammenzufassen.
Dies kann beispielsweise dadurch realisiert werden, dass der die jeweilige Transaktion bzw. das Anlegen und/oder Ändern der Autorisierungsdaten auslösende Teilnehmer diese Transaktion in einen Transaktionspool schreibt, der zwischen den Teilnehmern oder zumindest zwischen jenen Teil nehmern, die Blöcke erzeugen sollen, repliziert wird. Dort kann optional eine Prüfung der Gültigkeit der Transaktion erfolgen, wobei beispielsweise geprüft werden kann, ob die Transaktion durch den Teilnehmer gültig signiert ist, ob der Teilnehmer für die Durchführung dieses Vorgangs berechtigt ist, etc. Nach erfolgreicher Prüfung bzw. falls eine solche Prüfung nicht erfolgt, kön nen mehrere Transaktionen zu einem Datenblock zusammengefasst werden, der an die Datenstruktur angeführt wird.
Die Autorisierungsdaten können die Identifikationsinformation jenes Teilneh mers, durch den das oder ein Anlegen und/oder Verändern der Autorisie rungsdaten ausgelöst wurde, und/oder eine mit der Identifikationsinformation verknüpfte Signatur umfassen, wobei die Erfüllung der Autorisierungsbedin- gung von der Identifikationsinformation und/oder der Signatur abhängt. Ins besondere können nur bestimmte Teilnehmer zur Anlage und/oder Verände rung von Autorisierungsdaten berechtigt sein. Die Autorisierungsbedingung kann nur dann erfüllt oder erfüllbar sein, wenn die Identifikationsinformation bzw. die Signatur einem solchen berechtigten Teilnehmern zugeordnet ist.
Die Verknüpfung der Signatur mit der Identifikationsinformation kann aus der Datenstruktur entnehmbar sein oder auf Basis der Datenstruktur und/oder der Identifikationsinformation prüfbar sein. Beispielsweise kann die Signatur durch ein kryptographisches Signaturverfahren, von denen verschiedene be kannt sind, unter Verwendung eines privaten Schlüssels erstellt sein. Ent spricht die Identifikationsinformation dem öffentlichen Schlüssel dieses Schlüsselpaares, kann die Signatur unmittelbar auf Basis der Identifikati onsinformation geprüft werden. Da der öffentliche Schlüssel in der Regel re lativ lang ist, kann es vorteilhaft sein, stattdessen als Identifikationsinforma tion ein kürzeres Alias zu verwenden, wobei die Zuordnung dieses Alias zu dem privaten Schlüssel in der Datenstruktur abgelegt sein kann.
Die Autorisierungsbedingung kann nur dann erfüllt werden oder nur dann er füllbar sein, wenn in der Datenstruktur der Identifikationsinformation und/oder der Signatur zugeordnete Berechtigungsdaten vorhanden sind, die eine Be rechtigung des die Autorisierungsdaten anlegenden und/oder verändernden Teilnehmers anzeigen. Die Berechtigungsdaten können hierbei für sich ge nommen eine solche Berechtigung anzeigen. Es ist jedoch auch eine indirekte Berechtigung möglich. Beispielsweise kön nen die Berechtigungsdaten einem Teilnehmer eine übergeordnete Berechti gung geben, die ihn berechtigt, Unterberechtigungsdaten anzulegen bzw. zu ändern. In diesem Fall kann die Autorisierungsbedingung dann erfüllt werden bzw. erfüllbar sein, wenn Unterberechtigungsdaten für den die Autorisie- rungsdaten anlegenden und/oder veränderten Teilnehmer anzeigen, dass dieser hierzu berechtigt ist, wobei die Unterberechtigungsdaten eine Identifi kationsinformation und/oder Signatur eines Teilnehmers aufweist, der durch Berechtigungsdaten zur Anlage bzw. Änderung von Unterberechtigungsda ten berechtigt ist. Auch eine mehrstufige Hierarchie der Berechtigungen ist möglich.
Die Berechtigungsdaten können dadurch in der Datenstruktur angelegt und/oder verändert werden, dass durch eine Verarbeitungseinrichtung, die ein Teilnehmer oder Teil eines Teilnehmers ist, ein zusätzlicher Datenblock an die Datenstruktur angefügt wird, der von wenigstens einem der vorange henden Datenblöcke der Datenstruktur abhängt. Wie obig zu den Autorisie- rungsdaten erläutert, können jeweils nur die aktuellsten gültigen Berechti gungsdaten berücksichtigt werden. Wie ebenfalls zu den Autorisierungsdaten bereits erläutert wurde, kann ein Teilnehmer bzw. dessen Verarbeitungsein richtung die Anlage bzw. Veränderung durch eine Transaktion auslösen, die für sich genommen oder gemeinsam mit anderen Transaktionen als Daten block an die Datenstruktur angehängt wird.
Das oder ein Anlegen und/oder Verändern der Berechtigungsdaten kann au tomatisiert durch ein durch eine Verarbeitungseinrichtung wenigstens eines Teilnehmers ausgeführtes Programm, das insbesondere in der Datenstruktur gespeichert ist, erfolgen. Ein Speichern von Programmen in Datenstrukturen aus verketteten Datenblöcken, beispielsweise in Blockchains, ist an sich be kannt, wobei solche Programme auch als „Smart Contract“ bezeichnet wer den. Der Programmcode ist typischerweise in einer maschinenunabhängigen Skriptsprache abgelegt und kann in einem relativ frühen Datenblock gespei chert sein, um hierdurch eine hohe Manipulationssicherheit zu erreichen. Op- tional kann der Programmcode des Programms für jeden mit der Datenstruk tur bzw. Blockchain interagierenden Teilnehmer einheitlich sein. Dies ermög licht ein festgelegtes Regelwerk und schafft Vertrauen bei den Teilnehmern.
Das Anliegen und/oder Verändern der Berechtigungsdaten kann von Abstim mungsdaten abhängen, die von mehreren Teilnehmern an die das Pro gramm ausführende Verarbeitungseinrichtung, insbesondere als Teil der Da tenstruktur, bereitgestellt werden. Anders ausgedrückt wird das Programm bzw. der Smart Contract durch bestimmte, zum Wählen autorisierter Teilneh mer gesteuert, wodurch auf eine zentrale Autorität vollständig verzichtet wer den kann. Das Programm, das die Berechtigungsdaten automatisiert anlegt und/oder verändert, stellt quasi die zentrale Autorität dar und kann daher auch als „Root Contract“ bezeichnet werden.
Das Sammeln von Abstimmungsdaten kann gezielt ausgelöst werden, bei spielsweise durch Aufruf dieses Programms durch einen Teilnehmer, wo nach beispielsweise entsprechende Anfragen an die abstimmungsberechtig ten Teilnehmer gesendet werden können, wonach diese ihre Stimme abge ben und diese beispielsweise durch eine Signatur authentifizieren.
Ergänzend und alternativ kann es jedoch auch vorteilhaft sein, das Pro gramm automatisch zu bestimmten Zeitpunkten, beispielsweise jedes Mal, wenn ein neuer Datenblock an die Datenstruktur angehängt wird oder nach einer bestimmten Zahl von angehängten Datenblöcken, auszuführen. Die Abstimmungsdaten können durch die stimmberechtigten Teilnehmer vor die sem Zeitpunkt an die Datenstruktur angefügt werden oder in einem Transak tionspuffer abgelegt werden, sodass das Programm die Stimmen automati siert auswerten kann.
Beispielsweise können Berechtigungsdaten nur dann angelegt und/oder ver ändert werden, wenn eine Mindestzahl von Ja-Stimmen und weniger Nein stimmen als Ja-Stimmen vorliegen. Es kann hierbei auch möglich sein, ver schiedenen Teilnehmern ein unterschiedliches Stimmengewicht zuzuordnen, beispielsweise auf Basis ihres wirtschaftlichen Interesses an der Robustheit der Datenstruktur. Das Stimmrecht der Teilnehmer kann ebenfalls über die Datenstruktur verwaltet werden. Beispielsweise können dort für die einzelnen Teilnehmer Stimmrechtsdaten gespeichert sein, die angeben, ob diese stimmberechtigt sind oder nicht bzw. über wie viele Stimmen sie verfügen.
Die Berechtigungsdaten, die Autorisierungsdaten, das Stimmrecht usw. kön nen unabhängig voneinander in der Datenstruktur gespeichert werden. Es ist jedoch auch möglich, mehrere dieser Daten in einem gemeinsamen Daten satz zusammenzufassen, der beispielsweise die Identifikationsinformation des jeweiligen Teilnehmers und dessen Rechte beschreibt. Statt die einzel nen Rechte explizit zu speichern, kann dem einzelnen Teilnehmer auch eine bestimmte Rolle zugeordnet werden, der wiederum, beispielsweise über ei nen Datensatz in der Datenstruktur, bestimmte Rechte zugeordnet sind.
Die Berechtigung, Autorisierungsdatensätze anzulegen und/oder zu verän dern, kann allgemein gelten oder kann sich auf bestimmte Gruppen von Teil nehmern beziehen. Nehmen an dem Verfahren als Teilnehmer beispiels weise Ladestation, Kraftfahrzeuge und Fahrzeugnutzer teil, kann ein Fahr zeughersteller als Teilnehmer beispielsweise nur berechtigt sein, Autorisie rungsdaten, die sich auf Kraftfahrzeuge und/oder deren Nutzer beziehen, an zulegen und/oder zu verändern. Ein Betreiber von Ladeeinrichtungen kann hingegen nur dazu berechtigten sein, Autorisierungsdaten bezüglich dieser Ladestationen anzulegen bzw. zu verändern.
Es kann beispielsweise auch möglich sein, dass nur jener Teilnehmer, der die Autorisierungsdaten eines bestimmten weiteren Teilnehmers angelegt hat, oder optional ein von diesem berechtigter Teilnehmern, diese Autorisie rungsdaten ändern kann. Beispielsweise kann hierdurch ausgeschlossen werden, dass ein Fahrzeughersteller die Autorisierungsdaten eines Fahr zeugs eines anderen Herstellers modifiziert.
Zumindest ein Teil der in der Datenstruktur gespeicherten Daten kann für ei nen Teil der Teilnehmer nicht oder nicht im Klartext lesbar sein, insbeson dere durch Verschlüsselung dieser Daten. Hierdurch können insbesondere unterschiedliche Leserechte für unterschiedliche Teilnehmer implementiert werden.
Beispielsweise können Daten durch die öffentlichen Schlüssel alle Teilneh mer verschlüsselt werden, die Zugriff auf diese Daten haben sollen, und die Daten können nicht im Klartext gespeichert werden. Somit haben nur jener Teilnehmer Zugriff auf die gespeicherten Daten, die einen jeweiligen zuge ordneten privaten Schlüssel kennen.
Ist in der Anwendung sichergestellt, dass bestimmte Programme oder Pro grammteile, beispielsweise Smart Contracts, in einer manipulationssicheren Umgebung ausgeführt werden, kann die Kontrolle von Schreib- bzw. Leser echt auch über das Programm bzw. den Programmteil erfolgen.
Es ist zweckmäßig, Schreibrechte auf die Datenstruktur ebenfalls durch ein Programm, insbesondere einen Smart Contract, zu prüfen, der beispiels weise Signaturen von Transaktion, die bestimmte Aktionen durchführen sol len, prüfen kann. Dies kann beispielsweise erfolgen, wenn verschiedene Transaktionen zu einem Datenblock zusammengefasst werden, wobei nicht oder nicht gültig signierte Transaktionen verworfen werden können.
Unabhängig von einer solchen Prüfung vor dem Ändern der Datenstruktur kann es zweckmäßig sein, die Berechtigung des die Transaktion veranlas senden Teilnehmers bzw. dessen Signatur auch bei der Auswertung, bei spielsweise im Rahmen der Autorisierungsbedingung, zu prüfen, um eine Manipulationssicherheit weiter zu erhöhen.
Es kann zweckmäßig sein, zu der jeweiligen Identifikationsinformation Meta daten vorzuhalten, die beispielsweise persönliche Daten eines Nutzers, der ein Teilnehmer ist, bzw. eines Fahrzeughalters eines teilnehmenden Fahr zeugs betreffen können. Hierbei ist es aus Gründen des Datenschutzes und der Datensparsamkeit wesentlich, dass kein unberechtigter Zugriff auf diese Daten erfolgen kann und das diese, beispielsweise auf Anfrage der Person, die diese Daten betreffen, gelöscht oder zumindest nicht lesbar gemacht werden können.
Falls solche Metadaten In der Datenstruktur gespeichert werden, können sich beispielsweise durch den öffentlichen Schlüssel des Teilnehmers ver schlüsselt werden, sodass sie nur bei Kenntnis dieses privaten Schlüssels dieses Teilnehmers auslesbar sind. Ein Löschen des privaten Schlüssels führt in diesem Fall zu einer Unlesbarkeit der Daten.
Ist eine tatsächliche Löschung der Daten gewünscht oder z.B. aus Daten schutzgründen erforderlich, können entsprechende Metadaten separat von der Datenstruktur gespeichert werden, wobei beispielsweise unmittelbar über die Identifikationsinformation oder über einen in der Datenstruktur gespei cherten Verweis ein Zugriff auf die Metadaten in dieser Datenbank möglich ist, wobei diese vorzugsweise, wie obig erläutert, verschlüsselt sind, um ein unberechtigtes Auslesen auch dann zu verhindern, wenn ein Angreifer Zu griff auf die Datenbank selbst erhält. Ein Löschen des der Identifikationsinfor mation zugeordneten Datensatzes in dieser Datenbank führt somit zu einer vollständigen Löschung der Metadaten.
Teilnehmer können Leserechte für die eigenen öffentlichen Schlüssel und Metadaten haben. Teilnehmer, die, insbesondere wie obig erläutert durch in der Datenstruktur gespeicherte Berechtigungsdaten, berechtigt sind, Autori- sierungsdaten anzulegen und/oder zu verändern, können auch als Adminis tratoren bezeichnet werden. Administratoren können ein Leserecht auf die öffentlichen Schlüssel und Metadaten von Teilnehmern haben, deren Autori- sierungsdaten durch sie angelegt wurden. Sie können zusätzlich ein Leser echt auf die Identifikationsinformation und/oder den öffentlichen Schlüssel von Teilnehmern haben, mit denen von ihnen autorisierte Teilnehmer intera gieren, also beispielsweise von Teilnehmern, zu oder von denen eine Trans aktion erfolgt. Optional kann auch ein Zugriff auf Metadaten dieser Teilneh mer oder zumindest auf Teile der Metadaten dieser Teilnehmer möglich sein. Beispielsweise können Kraftfahrzeughersteller und Betreibe von Ladeeinrich tungen Leserechte für die jeweiligen miteinander interagierenden Objekten und Nutzer, die Teilnehmer bilden, haben. Kraftfahrzeughersteller können je doch vorzugsweise keine Informationen zu Teilnehmern, also insbesondere zu Kraftfahrzeugen bzw. Nutzern, von anderen Kraftfahrzeugherstellen lesen bzw. Ladeeinrichtungsbetreiber können keine Information zu Teilnehmern, insbesondere Ladeeinrichtungen bzw. Nutzen, von anderer Ladeeinrich tungsbetreiber lesen.
Administratoren können eine Identifikationsinformation für einen Teilnehmer erstellen, insbesondere indem ein Schlüsselpaar für diesen Teilnehmer er zeugt wird. Sie können Teilnehmer bzw. diesen zugeordneten Identifikati onsinformationen aktivieren, indem sie entsprechende Autorisierungsdaten anlegen bzw. derart verändern, dass die Funktion freigegeben wird. Als Funktion können hierbei auch verschiedene Funktionen, Dienste, Services, etc. separat oder gemeinsam freigegeben werden. Eine Statusänderung des jeweiligen Teilnehmers kann der jeweilige Administrator dadurch auslösen, dass er die Autorisierungsdaten ändert, beispielsweise einen Flag bzw. eine Variable auf True oder False setzt.
Administratoren können Metadaten der von ihnen autorisierten bzw. angeleg ten Teilnehmer löschen. Mit der Löschung der Metadaten und der Verknüp fung zwischen Metadaten und Identifikationsinformation bzw. öffentlichem Schlüssel wird ein hohes Datenschutzniveau erreicht, da danach keine un mittelbar personenbezogene Informationen mehr vorhanden sind und in der Datenstruktur gespeicherte Transaktionen nicht mehr einer bestimmten Per son zugeordnet werden können.
Als erster Teilnehmer kann ein Kraftfahrzeug und als zweiter Teilnehmer eine Infrastruktureinrichtung verwendet werden oder umgekehrt. Beispiels weise kann eine Einfahrt in einen bestimmten Bereich durch einen Schranke oder Ähnliches versperrt sein und erst nach einer Autorisierung des Kraft fahrzeugs freigegeben werden. Umgekehrt kann beispielsweise eine Zah- lungsanforderung einer Infrastruktureinrichtung, beispielsweise für ein Befah ren eines bestimmten Gebiets oder ein Parken, erst erfüllt werden, nachdem die Infrastruktureinrichtung autorisiert wurde. Eine Autorisierung von Infra struktureinrichtungen kann beispielsweise auch relevant sein, wenn die Kon trolle des Kraftfahrzeugs für einen automatisierten Parkvorgang oder Ähnli ches an die Infrastruktureinrichtung übergeben werden soll, um sicherzustel len, dass die Infrastruktureinrichtung vorgegebene Anforderungen erfüllt. Die Infrastruktureinrichtung kann insbesondere eine Ladeeinrichtung zum Laden eines Energiespeichers des Kraftfahrzeugs sein.
Besonders vorteilhaft kann als erster Teilnehmer ein Kraftfahrzeug und als zweiter Teilnehmer eine Ladeeinrichtung zum Laden eines Energiespeichers des Kraftfahrzeugs verwendet werden oder umgekehrt, wobei die Funktion des zweiten Teilnehmers notwendig für das Laden des Energiespeichers durch die Ladeeinrichtung ist. Wie obig erläutert, kann insbesondere eine beidseitige Autorisierung erfolgen, sodass ein Laden erst dann erfolgt, wenn sowohl die Ladeeinrichtung gegenüber dem Kraftfahrzeug als auch das Kraftfahrzeug gegenüber der Ladeeinrichtung autorisiert ist. Als Funktion der Ladeeinrichtung kann somit eine Stromabgabe bzw. kraftfahrzeugseitig eine Ladesteuerung und/oder eine Bezahlfunktion freigegeben werden.
Die Datenstruktur kann zusätzlich Transaktionen zwischen Teilnehmern, ins besondere bezüglich freigegebener Funktionen, speichern. Eine Transaktion bezüglich eines Ladevorgangs kann beispielsweise eine Kennzeichnung der Transaktion als einen Ladevorgang betreffend, die Identifikationsinformation des Kraftfahrzeugs und der Ladeeinrichtung und eine Menge an übertrage ner Energie umfassen. Zusätzlich kann eine solche Transaktion optional ei nen aktuellen Ladezustand des Energiespeichers des Kraftfahrzeugs, ein Guthaben des Kraftfahrzeugs bzw. eines Nutzers des Kraftfahrzeugs in einer digitalen Währung, Qualitätskriterien der Ladestation, beispielsweise eine Genauigkeit einer Leistungsmessung, die maximal bereitstellbare Leistung oder Ähnliches, etc. umfassen. Die Transaktion kann auch eine Bewertung des ersten Teilnehmers durch den zweiten Teilnehmer oder umgekehrt umfassen, also beispielsweise eine Bewertung des Ladevorgangs durch das Kraftfahrzeug bzw. die Ladesäule. Diese Informationen können zweckmäßig sein, um beispielsweise Fahrzeug herstellern bzw. Ladeeinrichtungsbetreibern Informationen bezüglich mögli cher Verbesserungen bereitzustellen. Beispielsweise können entsprechende Daten fahrzeugherstellerseitig ausgewertet werden, um hierdurch fahrzeug seitig angebotene Informationen zur Ladeeinrichtungen zu ergänzen bzw. entsprechende Informationen bei der Routenplanung zu berücksichtigen.
Neben dem erfindungsgemäßen Verfahren betrifft die Erfindung eine Verar beitungseinrichtung, die zur Teilnahme an dem erfindungsgemäßen Verfah ren als Teilnehmer oder als Teil eines Teilnehmers ausgebildet ist. Die Ver arbeitungseinrichtung kann insbesondere eine Kommunikationseinrichtung zur Kommunikation mit den weiteren Teilnehmern, insbesondere zum Repli zieren der Datenstruktur, eine Speichereinrichtung zur Speicherung der Da tenstruktur und ein Rechenwerk zur Durchführung der Verfahrensschritte umfassen. Die Funktion, die bei Erfüllung der Autorisierungsbedingung frei gegeben wird, kann eine Funktion der Verarbeitungseinrichtung selbst sein, beispielsweise das Durchführen einer Transaktion auf der Datenstruktur. Die Funktion kann jedoch auch das Steuern einer verarbeitungseinrichtungsex ternen Komponente sein oder umfassen, beispielsweise einer Ladesteue rung eines Kraftfahrzeugs bzw. einer Komponente einer Ladeeinrichtung, ei nes Aktors einer Schranke oder einer anderen Sperre, einer Ampelsteuerung oder von ähnlichen Einrichtungen.
Die Erfindung betrifft zudem ein Kraftfahrzeug, das eine erfindungsgemäße Verarbeitungseinrichtung umfasst, und eine Infrastruktureinrichtung, insbe sondere eine Ladeeinrichtung, die eine erfindungsgemäße Verarbeitungsein richtung umfasst.
Weitere Vorteile und Einzelheiten der Erfindung ergeben sich aus den fol genden Ausführungsbeispielen sowie den zugehörigen Zeichnungen. Hierbei zeigen schematisch: Fig. 1 Ausführungsbeispiele eines erfindungsgemäßen Kraftfahrzeugs und einer erfindungsgemäßen Infrastruktureinrichtung, nämlich eine Ladeeinrichtung, die jeweils ein Ausführungsbeispiel einer erfindungsgemäßen Verarbeitungseinrichtung umfassen und im Rahmen eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens genutzt werden,
Fig. 2 ein Beispiel für eine im erfindungsgemäßen Verfahren genutzte Datenstruktur, und
Fig. 3 eine durch das erfindungsgemäße Verfahren realisierbare Be rechtigungshierarchie. Fig. 1 zeigt eine Betriebssituation, in der zwei Teilnehmer 1 , 2 in einem Kom munikationsnetz 11 gegenüber dem jeweils anderen Teilnehmers 1 , 2 autori siert werden sollen, eine bestimmte Funktion durchzuführen. Im gezeigten Beispiel ist der Teilnehmer 1 ein Kraftfahrzeug und der Teilnehmer 2 ist eine Ladestation. Hierbei sollen jeweils Funktionen 26, 27 einer jeweiligen Lade- Steuerung 24, 25 freigegeben werden, um ein Laden eines Energiespeichers 59 des Teilnehmers 1 , also des Kraftfahrzeugs, zu ermöglichen.
Hierbei ist den Teilnehmern 1 , 2 jeweils eine Identifikationsinformation 7, 8, beispielsweise ein öffentlicher Schlüssel eines Schlüsselpaars eines asym- metrischen Verschlüsselungsverfahrens, zugeordnet, über die der jeweilige Teilnehmer 1 , 2 identifizierbar ist. Vor der Freigabe der Funktionen 26, 27 und somit dem Beginn des Ladevorgangs soll geprüft werden, ob die Teil nehmer 1 , 2 auch zur Durchführung des Ladevorgangs autorisiert sind. Eine entsprechende Autorisierung kann prinzipiell durch weitere Teilnehmer 3, 4, 5 im Kommunikationsnetz erfolgen, insbesondere durch Teilnehmer 4,
5, die als Administratoren 28, 29 berechtigt sind, eine solche Autorisierung zu erteilen und zu widerrufen. Hierbei kann beispielsweise der Teilnehmer 4 ein Backend-System eines Kraftfahrzeugherstellers sein und Autorisierungen für durch diesen hergestellte Kraftfahrzeuge 1 beziehungsweise deren Nut zer 6 erteilen und widerrufen. Der Teilnehmer 5 kann hingegen ein Betreiber von Ladeeinrichtungen sein, der Autorisierungen für von ihm betriebene La deeinrichtungen erteilen und widerrufen kann.
Um eine solche Autorisierung zur Freigabe einer jeweiligen Funktion 26, 27 zu ermöglichen, wird zunächst durch den anderen der Teilnehmer 1 , 2 die je weilige Identifikationsinformation 7, 8 an jenen Teilnehmer 1, 2 übertragen, der die entsprechende Funktion 26, 27 bereitstellen soll. Dies ist in Fig. 1 schematisch durch die Pfeile 9, 10 dargestellt, wobei dieser Datenaustausch über jeweilige Kommunikationseinrichtungen 20, 21 von Verarbeitungsein richtungen 12, 13 der Teilnehmer 1, 2 erfolgt. Der Informationsaustausch kann über das Kommunikationsnetz 11 erfolgen oder auch über einen sepa raten Kommunikationspfad, beispielsweise über einen kurzreichweitigen drahtlosen Kommunikationspfad oder im Falle eines gewünschten Ladebe triebs auch über das Ladekabel.
Der Vollständigkeit halber sei angemerkt, dass es für das im Folgenden be schriebene Vorgehen nicht erforderlich ist, dass die einzelnen Teilnehmer 1 bis 6 zu jedem beliebigen Zeitpunkt über das Kommunikationsnetz 11 kom munizieren können, sondern es ist ausreichend, wenn in nicht allzu langen Zeitabständen ein Datenaustausch mit zumindest Teilen der weiteren Teil nehmer 1 bis 6 möglich ist. Für Teilnehmer 6, beispielsweise Nutzer von Kraftfahrzeugen, die keine eigenen Verarbeitungseinrichtungen aufweisen, erfolgt die Kommunikation insbesondere über Datenverarbeitungseinrichtun gen, die auch selbst Teilnehmer mit eigener zugeordneter Identifikationsin formation sein können oder auch nicht.
Ein bekannter Ansatz, eine Autorisierung bei bekannter Identifikationsinfor mation 7, 8 zu prüfen, ist es, bei einer Zentraleinrichtung abzufragen, ob eine Autorisierung für diese Identifikationsinformation 7, 8 vorliegt. Dies erfordert jedoch den Betrieb einer relativ aufwendigen Zentraleinrichtung und zudem ist für eine Autorisierung eine robuste Kommunikationsverbindung zu dieser Zentraleinrichtung erforderlich. Daher wird in dem erläuterten Verfahren ein anderer Ansatz zur Autorisie- rung der Teilnehmer 1 , 2 gegenüber des jeweils anderen Teilnehmers 1 , 2 genutzt. Die Autorisierung erfolgt nämlich jeweils lokal durch die Verarbei tungseinrichtung 12, 13 des jeweiligen Teilnehmers. Diese weist neben der bereits erwähnten jeweiligen Kommunikationseinrichtung 20, 21 eine Spei chereinrichtung 18, 19 auf, in der neben der jeweiligen eigenen Identifikati onsinformation 7, 8, die im Beispiel ein öffentlicher Schlüssel ist, eine ge heime Information, im Beispiel einen privaten Schlüssel 14, 15, und eine Da tenstruktur 16, 17 gespeichert ist. Die Datenstruktur 16, 17 kann eine dezent rale Transaktionsdatenbank implementieren. Die Verarbeitungsschritte wer den durch ein jeweiliges Rechenwerk 22, 23 durchgeführt.
Wie in Fig. 2 schematisch dargestellt ist, umfasst die jeweilige Datenstruktur 16, 17 mehrere Datenblöcke 34, die derart miteinander verknüpft sind, dass der Inhalt des jeweiligen nachfolgenden Datenblocks 34 vom Inhalt des vo rangehenden Datenblocks 34 abhängt. Dies wird im Beispiels dadurch imple mentiert, dass alle Datenblöcke 34 außer des ersten Datenblocks einen kryp- tographischen Hashwert 35 des vorangehenden Datenblocks speichern.
Dies führt dazu, dass zur Veränderung eines der Datenblöcke 34 auch eine Veränderung aller nachfolgenden Datenblöcke erforderlich wäre, um eine Konsistenz der jeweiligen Datenstruktur 16, 17 zu erreichen.
Ist das Erstellen neuer Datenblöcke 34 hinreichend rechenaufwendig und/oder liegen hierbei andere Anforderungen vor, beispielsweise eine Be grenzung der Anzahl von Blöcken die durch einen bestimmten Teilnehmer in einem bestimmten Zeitintervall erstellt werden können, wird hierdurch eine hohe Manipulationssicherheit der Datenstruktur erreicht. Mögliche Ansätze hierfür wurden bereits im allgemeinen Teil diskutiert und sind insbesondere aus dem Bereich der Blockchains beziehungsweise Kryptowährungen wohl bekannt.
Zumindest Teile der Datenblöcke 34 speichern jeweils wenigstens eine Transaktion 36, also einen Vorgang, der durch einen der Teilnehmer 1 bis 6 oder automatisiert durch die Steuerung der Datenstruktur steuernden Pro gramme 48, 54, 56 ausgelöst wurde. Beispielsweise kann als Transaktion 36 ein Ladedatensatz 37 gespeichert sein, der einen vorangehenden Ladevor gang des Kraftfahrzeugs 1 an der Ladeeinrichtung 2 beschreibt.
Der Ladedatensatz 37 kann beispielsweise die Identifikationsinformation 7 des Kraftfahrzeugs, eine Signatur 38, die mithilfe des privaten Schlüssels 14 des Kraftfahrzeugs erstellt wurde, die Identifikationsinformation 8 der La destation, eine bei diesem Ladevorgang übertragene Strommenge 39, Zu satzinformationen 40, beispielsweise eine Bewertung des Ladevorgangs, und einen Zeitstempel 41 umfassen. Werden beispielsweise sowohl durch das Kraftfahrzeug als auch durch die Ladeeinrichtung entsprechende Lade datensätze 37 bereitgestellt, die dann in einem der Blöcke 34 der Daten strukturen 16, 17 gespeichert werden, wird hierdurch eine manipulationssi chere Dokumentation des Ladevorgangs erreicht.
Durch Ansätze, die aus dem Bereich der Blockchains beziehungsweise Kryp- towährungen bekannt sind, kann zudem erreicht werden, dass die durch die einzelnen Teilnehmer beziehungsweise Verarbeitungseinrichtungen 12, 13 gespeicherten Datenstrukturen 16, 17 in der Regel identisch sind, zumindest was ältere Datenblöcke 34 betrifft. Insbesondere kann bei einer Verbindung zum Kommunikationsnetz 11 beziehungsweise in regelmäßigen Abständen durch den jeweiligen Teilnehmer 1 bis 6 beziehungsweise eine durch diesen genutzte Verarbeitungseinrichtung 12, 13 jeweils abgefragt werden, ob im Kommunikationsnetz 11 eine Datenstruktur mit höherer Blockzahl als die lo kal gespeicherte Datenstruktur 16, 17 noch vorhanden ist. Ist dies der Fall, so kann die Gültigkeit dieser Datenstruktur geprüft werden und, falls die Da tenstruktur mit größerer Blockzahl gültig ist, diese gespeichert werden, um die bisher genutzte Datenstruktur 16, 17 zu ersetzen.
In dem erfindungsgemäßen Verfahren wird eine solche Datenstruktur 16, 17 genutzt, um Autorisierungsdaten 42, 49 für die jeweiligen Teilnehmer 1 bis 6 zu speichern. Dies wird im folgenden Beispiel bezüglich der Autorisierung des Teilnehmers 2 erläutert, ist entsprechend jedoch auch auf die Autorisie- rung anderer Teilnehmer übertragbar.
Nach der Übertragung der Identifikationsinformation 8 des Teilnehmers 2 an die Verarbeitungseinrichtung 12 des Teilnehmers 1 , prüft diese, ob in der lo kal gespeicherten Datenstruktur 16 Autorisierungsdaten 42, 49 vorhanden sind, die dieser Identifikationsinformation 8 zugeordnet sind, ob diese gültig sind und ob sie eine Autorisierung des Teilnehmers 2 anzeigen. Die Prüfung der Autorisierungsbedingung 47 kann insbesondere durch ein Programm 48 erfolgen, das als Teil der Datenstruktur 16, 17 gespeichert ist. Hierdurch kann eine hohe Manipulationssicherheit für das Programm 48 erreicht wer den.
Die Autorisierungsbedingung 47 kann zunächst nur die aktuellsten Autorisie rungsdaten 42 berücksichtigen, die den Teilnehmer 2 bzw. dessen Identifika tionsinformation 8 betreffen. Die jeweiligen Autorisierungsdaten 42, 49 um fassen jeweils die Identifikationsinformation 8, der sie zugeordnet sind, eine Identifikationsinformation 43 jenes Teilnehmers 1 bis 6, der das Anlegen be ziehungsweise die Veränderung der Autorisierungsdaten 42, 49 ausgelöst hat, eine Signatur 44 dieses Teilnehmers, ein Status 45 der Autorisierung und ein Zeitstempel 46. Der Status 45 kann beispielsweise ein Flag sein, das anzeigt, ob eine Autorisierung vorliegt oder nicht, und kann beispielsweise den Wert 1 oder 0 oder „True“ oder „False“ aufweisen.
In einem ersten Schritt wird geprüft, ob die jeweiligen Autorisierungsdaten 42, 49 gültig sind. Hierbei kann insbesondere geprüft werden, ob die Signa tur 44 gültig ist, was durch übliche kryptographische Signaturverfahren mög lich ist. Zudem wird, wie später noch genauer erläutert werden wird, geprüft, ob der durch die Identifikationsinformation 43 identifizierte Teilnehmer 1 bis 6 berechtigt war, die der Identifikationsinformation 8 zugeordneten Autorisie rungsdaten 42, 49 anzulegen beziehungsweise zu verändern.
Sind die aktuellsten Autorisierungsdaten 42 gültig, so wird die Statusinforma tion 45 ausgelesen, die angibt, ob der Teilnehmer 2 autorisiert ist oder nicht. Zeigt die Statusinformation 45 eine Autorisierung an, so wird die Funktion 27 im Kraftfahrzeug freigeschaltet.
Sind die aktuellsten Autorisierungsdaten 42 hingegen ungültig, wir die Prü fung für die früheren Autorisierungsdaten 49 wiederholt und entsprechend vorgegangen. Sind auch die früheren Autorisierungsdaten 49 ungültig und liegen auch keine weiteren Autorisierungsdaten zur Identifikationsinformation 8 in der Datenstruktur 16 vor, so ist die Autorisierungsbedingung 47 nicht er füllt und die Funktion 27 bleibt gesperrt, da der Teilnehmer 2 nicht für einen Ladevorgang autorisiert ist.
Die Prüfung, ob der durch die Identifikationsinformation 43 identifizierte Nut zer berechtigt war, die Autorisierungsdaten 42, 49 anzulegen beziehungs weise zu verändern, kann beispielsweise durch das Programm 54 geprüft werden, das ebenfalls durch die jeweilige Datenstruktur 16, 17 bereitgestellt wird.
Hierbei wäre es prinzipiell möglich, dass fest vorgegeben ist, welche Teilneh mer 1 bis 6 berechtigt sind, Autorisierungsdaten anzulegen beziehungsweise zu verändern. Es ist jedoch bevorzugt, wenn die Berechtigung, Autorisie rungsdaten 42, 49 anzulegen und zu verändern, bedarfsgerecht bestimmten Teilnehmern erteilt beziehungsweise entzogen werden kann, um diese zu Administratoren 28, 29 zu bestimmen beziehungsweise sie aus dem Pool der Administratoren 28, 29 zu entfernen.
Ein Ansatz hierzu wird im Folgenden mit zusätzlichem Bezug auf Fig. 3 nä her erläutert, wobei Fig. 3 die genutzte Autorisierungspyramide schematisch darstellt. In dem gezeigten relativ einfachen Beispiel sollen letztlich einerseits Kraftfahrzeug beziehungsweise deren Nutzer, im Beispiel also die Teilneh mer 1 und 6, und andererseits Ladeeinrichtungen, im Beispiel also der Teil nehmer 2, zur Durchführung von Ladevorgängen autorisiert werden. Wie durch die gestrichelte Linie 58 angedeutet ist, kann hierbei eine klare Tren nung erfolgen, so dass einerseits als Administratoren 28 beispielsweise Ba- ckend-Systeme von Kraftfahrzeugherstellern dienen können, über die Kraft fahrzeuge und Nutzer von Kraftfahrzeugen autorisiert werden können, und andererseits als Administratoren 29 Backend-Systeme von Ladeeinrich tungsbetreibern dienen, die die durch sie betriebenen Ladeeinrichtungen au torisieren.
Hierbei können jeweils beispielsweise verschiedene Ladeeinrichtungsbetrei ber nur ihre eigenen Ladeeinrichtungen autorisieren beziehungsweise deren Autorisierungen entziehen und Zusatzinformationen verwalten. Entsprechend können Fahrzeughersteller nur ihre eigenen Kraftfahrzeuge und Nutzer auto risieren, ihre Autorisierungen entziehen beziehungsweise ihre Daten verwal ten.
Eine Veränderung der Berechtigung der Teilnehmer 4, 5 als Administrator 28, 29 erfolgt vorzugsweise nicht unmittelbar durch einen einzelnen Teilneh mer 1 - 6, sondern durch ein Programm 56, das insbesondere ebenfalls über die Datenstruktur 16, 17 bereitgestellt werden kann, und das ein Speichern von Berechtigungsdaten 50, 55 in der Datenstruktur 16, 17 auslöst, wenn entsprechende Abstimmungsdaten 57 von stimmberechtigten Teilnehmern 1 bis 6 vorliegen.
In dem in Fig. 3 gezeigtem Beispiel wird davon ausgegangen, dass alle Teil nehmer 4, 5, die Administratoren 28, 29 sind, stimmberechtigt sind, wobei Stimmgewichte insbesondere vom wirtschaftlichen Interesse an der Robust heit der Datenstruktur 16, 17 abhängen können, also beispielsweise von der Anzahl der durch sie autorisierten Teilnehmer 1 bis 6, von durch Ladevor gänge erzielten Umsätzen oder Ähnlichem. Insbesondere können die Stimm gewichte somit unmittelbar aus der Datenstruktur selbst abgeleitet werden. In anderen Ausgestaltungen wäre es jedoch auch möglich, dass ein Stimmrecht unabhängig von dem Administratorstatus ist.
Die Abfrage der Abstimmungsdaten 57 durch das Programm 56 kann bei spielsweise dadurch erfolgen, dass das Programm 56 lokal durch einen Teil- nehmer aufgerufen wird, der anschließend entsprechende Anfragen an wei tere stimmberechtigte Teilnehmer sendet, die beispielsweise durch signierte Rückantworten ihre Zustimmung ausdrücken können. Wird durch das Pro gramm 56 beispielsweise eine ausreichende Anzahl von Ja-Stimmen und insbesondere eine demgegenüber kleinere Anzahl von Nein-Stimmen er fasst, können durch dieses neue Berechtigungsdaten 50, 55 als Transaktion angelegt werden, die unmittelbar oder zu einem späteren Zeitpunkt als Teil eines zusätzlichen Datenblocks 34 an die Datenstruktur 16, 17 angefügt wer den. Da dies zu einer größeren Blockzahl der Datenstruktur 16, 17 führt, wird die entsprechend verlängerte Datenstruktur 16, 17 durch die weiteren Teil nehmer übernommen und somit die Änderungen der Berechtigung an diese kommuniziert.
Wie obig erwähnt, kann im Rahmen der Autorisierungsbedingung 47, z.B. durch das Programms 54, auch geprüft werden, ob der durch die Identifikati onsinformation 43 identifizierte Teilnehmer 1 bis 6 berechtigt war, die jeweils ausgewerteten Autorisierungsdaten 42, 49 anzulegen. Hierzu kann das Pro gramm 54 prüfen, ob in der Datenstruktur 16, 17 dieser Identifikationsinfor mation 43 zugeordnete Berechtigungsdaten 50, 55 vorliegen.
Im in Fig. 2 gezeigten Beispiel umfassen die Berechtigungsdaten 50, 55 je weils die Identifikationsinformation 43, der sie zugeordnet sind, und eine Sta tusinformation 51 , die beispielsweise durch einen 0- oder 1-Wert bezie hungsweise einen „True“- oder False“-Wert angibt, ob eine solche Berechti gung vorliegt. Zusätzliche können Informationen gespeichert sein, für welche der Teilnehmer 1 bis 6 beziehungsweise für welchen Typ von Teilnehmern 1 - 6 diese Berechtigung gilt.
Um eine Gültigkeit der Berechtigungsdaten 50, 55 prüfen zu können, umfas sen diese zusätzlich ein Autorisierungsfeld 52, das beispielsweise Signatu ren jener Teilnehmer 1 bis 6 umfasst, die für den aktuellen Berechtigungszu stand gestimmt haben. Zudem wird ein Zeitstempel 53 gespeichert. Ähnlich wie obig zu den Autorisierungsdaten 42, 49 erläutert, werden zu nächst nur die aktuellsten Berechtigungsdaten 50 berücksichtigt, die der Identifikationsinformation 43 zugeordnet sind. Sind diese gültig, so gibt der Status 51 vor, ob der durch die Identifikationsinformation 43 identifizierte Teilnehmer 1 bis 6 berechtigt war, die jeweiligen Autorisierungsdaten 45, 49 anzulegen beziehungsweise zu verändern.
Sind die Berechtigungsdaten 50 hingegen ungültig, beispielsweise aufgrund fehlerhafter Signaturen, wird auf frühere Berechtigungsdaten 55 zurückge griffen und das entsprechende Vorgehen wird wiederholt. Werden keine gül tigen Berechtigungsdaten in der Datenstruktur 16, 17 aufgefunden, wird da von ausgegangen, dass der durch die Identifikationsinformation 43 bezeich- nete Teilnehmer 1 bis 6 nicht berechtigt war, die Autorisierungsdaten 42, 49 anzulegen, womit diese als ungültig betrachtet werden.
Um hohe Datenschutzstandards zu erreichen, können einerseits zumindest Teile der in der Datenstruktur 16, 17 gespeicherten Daten nicht für alle Teil nehmer 1 bis 6 lesbar sein. Insbesondere können entsprechende Daten je weils mit den öffentlichen Schlüsseln jener Teilnehmer 1 bis 6 verschlüsselt werden, die einen Lesezugriff auf die entsprechenden Daten haben sollen, womit nur diese Teilnehmer 1 bis 6 die Daten lesen können, da ihnen der zu geordnete private Schlüssel 14, 15 bekannt ist.
Andererseits werden die einzelnen Teilnehmer 1 bis 6 vorzugsweise nur durch ihre Identifikationsinformation 7, 8 identifiziert und weiterer Metadaten, beispielsweise Anschriften, Kontoverbindungen oder Ähnliches, werden durch jeweilige Administratoren 28, 29, beispielsweise Backend-Server von Fahrzeugherstellern oder Ladeeinrichtungsbetreibern, verwaltet.
Diese können als Teilnehmer 4, 5 mit dem Kommunikationsnetz 11 verbun den sein und neben einer jeweiligen Verarbeitungseinrichtung 30, 31 zusätz lich eine Datenbank 32, 33 für entsprechende Metadaten implementieren. Dies ermöglicht es beispielsweise, entsprechende Metadaten zu löschen, wenn dies durch einen Teilnehmer 1 bis 6 angefordert wird oder wenn Aufbe wahrungsfristen abgelaufen sind. Entsprechende Löschungen innerhalb der Datenstruktur 16, 17 wären nicht ohne weiteres möglich, da deren Ausgestal tung wie erläutert darauf abgestellt ist, Änderungen in zeitlich früh angefüg- ten Datenblöcken 34 zu verhindern.

Claims

PATENTANSPRÜCHE:
1. Verfahren zur Autorisierung eines ersten Teilnehmers (1 -6) in einem Kommunikationsnetz (11 ), über das mehrere Teilnehmer (1 - 6) kom munizieren, wobei den Teilnehmern (1 - 6) jeweils eine Identifikati onsinformation (7, 8, 43) zugeordnet ist, umfassend die Schritte:
- Übertragen der Identifikationsinformation (7, 8, 43) des ersten Teil nehmers (1 - 6) an einen zweiten Teilnehmer (1 - 6) in dem Kommu nikationsnetz (11), der eine Verarbeitungseinrichtung (12, 13, 30, 31) ist oder umfasst,
- Prüfen, ob in einer Datenstruktur (16, 17) der Identifikationsinforma tion (7, 8, 43) zugeordnete Autorisierungsdaten (42, 49) vorhanden sind, durch die Verarbeitungseinrichtung (12, 13, 30, 31), wobei eine Datenstruktur (16, 17) verwendet wird, die auf mehreren als Teilneh mer (1 - 6) über das Kommunikationsnetz (11 ) kommunizierenden Verarbeitungseinrichtungen (12, 13, 30, 31) repliziert ist und die mehrere Datenblöcke (34) umfasst, die in einer Abfolge geordnet und derart miteinander verknüpft sind, dass der Inhalt eines jeweili gen nachfolgenden Datenblocks (34) vom Inhalt wenigstens eines vorangehenden Datenblocks (34) abhängt,
- Freigabe einer Funktion (26, 27) des zweiten Teilnehmers (1 - 6) ausschließlich bei Erfüllung einer die Autorisierungsdaten (42, 49) auswertenden Autorisierungsbedingung (47), die nur dann erfüllbar ist, wenn der Identifikationsinformation (7, 8, 43) zugeordnete Autori sierungsdaten (42, 49) vorhanden sind.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Autorisierungsdaten (42, 49) dadurch in der Datenstruktur (16, 17) angelegt oder verändert werden, dass durch eine Verarbeitungsein richtung (12, 13, 30, 31), die ein Teilnehmer (1 - 6) oder Teil eines Teil nehmers (1 -6) ist, ein zusätzlicher Datenblock (34) an die Datenstruk tur (16, 17) angefügt wird, der von wenigstens einem der vorhandenen Datenblöcke (34) der Datenstruktur (16, 17) abhängt. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Autorisierungsdaten (42, 49) die Identifikationsinformation (7,
8, 43) jenes Teilnehmers (1 - 6), durch den das oder ein Anlegen und/oder Verändern der Autorisierungsdaten (42, 49) ausgelöst wurde, und/oder eine mit der Identifikationsinformation (7, 8, 43) verknüpfte Signatur (44) umfassen, wobei die Erfüllung der Autorisierungsbedin- gung (47) von der Identifikationsinformation (7, 8, 43) und/oder der Sig natur (44) abhängt.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die Autorisierungsbedingung (47) nur dann erfüllt wird oder nur dann erfüllbar ist, wenn in der Datenstruktur (16, 17) der Identifikati onsinformation (7, 8, 43) und/oder der Signatur (44) zugeordnete Be rechtigungsdaten (50, 55) vorhanden sind, die eine Berechtigung des die Autorisierungsdaten (42, 49) anlegenden und/oder verändernden Teilnehmers (1 - 6) anzeigen.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Berechtigungsdaten (50, 55) dadurch in der Datenstruktur (16, 17) angelegt und/oder verändert werden, dass durch eine Verarbei tungseinrichtung (12, 13, 30, 31), die ein Teilnehmer (1 - 6) oder Teil eines Teilnehmers (1 - 6) ist, ein zusätzlicher Datenblock (34) an die Datenstruktur (16, 17) angefügt wird, der von wenigstens einem der vorhandenen Datenblöcke (34) der Datenstruktur (16, 17) abhängt.
Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass das Anlegen und/oder Verändern der Berechtigungsdaten (50, 55) automatisiert durch ein durch eine Verarbeitungseinrichtung (12, 13, 30, 31) wenigstens eines Teilnehmers (1 -6) ausgeführtes Programm (56), das insbesondere in der Datenstruktur (16, 17) gespeichert ist, erfolgt.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das oder ein Anlegen und/oder Verändern der Berechtigungsda ten (50, 55) von Abstimmungsdaten (57) abhängt, die von mehreren Teilnehmern (1 - 6) an die das Programm (56) ausführende Verarbei tungseinrichtung (12, 13, 30, 31), insbesondere als Teil der Datenstruk tur (16, 17), bereitgestellt werden.
8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass zumindest ein Teil der in der Datenstruktur (16, 17) gespeicherten Daten für einen Teil der Teilnehmer (1 - 6) nicht oder nicht im Klartext lesbar ist, insbesondere durch Verschlüsselung dieser Daten.
9. Verfahren nach Anspruch einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als erster Teilnehmer (1 - 6) ein Kraftfahrzeug und als zweiter Teilnehmer (1 - 6) eine Infrastruktureinrichtung verwendet wird oder umgekehrt.
10. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als erster Teilnehmer (1 - 6) ein Kraftfahrzeug und als zweiter Teilnehmer (1 - 6) eine Ladeeinrichtung zum Laden eines Energiespei chers (59) des Kraftfahrzeugs verwendet wird oder umgekehrt, wobei die Funktion (26, 27) des zweiten Teilnehmers (1 - 6) notwendig für das Laden des Energiespeichers (59) durch die Ladeeinrichtung ist.
11. Verarbeitungseinrichtung, dadurch gekennzeichnet, dass sie zur Teilnahme an dem Verfahren nach einem der vorangehen den Ansprüche als Teilnehmer (1 - 6) oder als Teil eines Teilnehmers (1 - 6) ausgebildet ist.
12. Kraftfahrzeug, dadurch gekennzeichnet, dass es eine Verarbeitungseinrichtung (12, 13, 30, 31) nach Anspruch 11 umfasst.
13. Infrastruktureinrichtung, insb. Ladeeinrichtung, dadurch gekennzeichnet, dass sie eine Verarbeitungseinrichtung (12, 13, 30, 31) nach Anspruch 11 umfasst.
PCT/EP2022/056140 2021-03-15 2022-03-10 Verfahren zur autorisierung eines ersten teilnehmers in einem kommunikationsnetz, verarbeitungseinrichtung, kraftfahrzeug und infrastruktureinrichtung WO2022194658A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202280021224.3A CN116982332A (zh) 2021-03-15 2022-03-10 用于对通信网络中的第一参与者进行授权的方法、处理器设备、机动车和基础设施设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021106261.6A DE102021106261A1 (de) 2021-03-15 2021-03-15 Verfahren zur Autorisierung eines ersten Teilnehmers in einem Kommunikationsnetz, Verarbeitungseinrichtung, Kraftfahrzeug und Infrastruktureinrichtung
DE102021106261.6 2021-03-15

Publications (1)

Publication Number Publication Date
WO2022194658A1 true WO2022194658A1 (de) 2022-09-22

Family

ID=80999476

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/056140 WO2022194658A1 (de) 2021-03-15 2022-03-10 Verfahren zur autorisierung eines ersten teilnehmers in einem kommunikationsnetz, verarbeitungseinrichtung, kraftfahrzeug und infrastruktureinrichtung

Country Status (3)

Country Link
CN (1) CN116982332A (de)
DE (1) DE102021106261A1 (de)
WO (1) WO2022194658A1 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180272886A1 (en) * 2015-12-03 2018-09-27 Innogy Innovation Gmbh Supply Medium Exchange System for Mobile Units
DE102017212904A1 (de) 2017-07-27 2019-01-31 Bayerische Motoren Werke Aktiengesellschaft Ladesystem zum schnellen und sicheren Laden von Elektrofahrzeugen
DE112017006701T5 (de) * 2016-12-30 2019-09-19 Intel Corporation Internet der Dinge
WO2019215437A1 (en) * 2018-05-09 2019-11-14 Centrica Plc System for protecting integrity of transaction data

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017006572A1 (de) 2017-04-12 2018-10-18 Diehl Defence Gmbh & Co. Kg Verfahren zum Schutz eines vernetzten militärischen Systems
US20200396059A1 (en) 2017-12-19 2020-12-17 Algorand Inc. Fast and partition-resilient blockchains
DE102018109240A1 (de) 2018-04-18 2019-10-24 XQueue GmbH Multi-Chain basiertes Verfahren und System zum dauerhaften, anonymen und manipulationssicheren Verwalten und Nachweisen von Einwilligungen zur Versendung elektronischer Nachrichten
DE102018009949A1 (de) 2018-12-18 2020-06-18 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Übertragungsverfahren zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180272886A1 (en) * 2015-12-03 2018-09-27 Innogy Innovation Gmbh Supply Medium Exchange System for Mobile Units
DE112017006701T5 (de) * 2016-12-30 2019-09-19 Intel Corporation Internet der Dinge
DE102017212904A1 (de) 2017-07-27 2019-01-31 Bayerische Motoren Werke Aktiengesellschaft Ladesystem zum schnellen und sicheren Laden von Elektrofahrzeugen
WO2019215437A1 (en) * 2018-05-09 2019-11-14 Centrica Plc System for protecting integrity of transaction data

Also Published As

Publication number Publication date
DE102021106261A1 (de) 2022-09-15
CN116982332A (zh) 2023-10-31

Similar Documents

Publication Publication Date Title
EP3108610B1 (de) Verfarhen und system zum erstellen und zur gültigkeitsprüfung von gerätezertifikaten
EP3731119B1 (de) Computerimplementiertes verfahren zur zugriffskontrolle
EP2338255B1 (de) Verfahren, computerprogrammprodukt und system zur authentifizierung eines benutzers eines telekommunikationsnetzwerkes
WO2018167253A1 (de) Protokollieren von zustandsdaten einer vorrichtung in einer blockchain
DE102008042262A1 (de) Verfahren zur Speicherung von Daten, Computerprogrammprodukt, ID-Token und Computersystem
EP1185026B2 (de) Verfahren zur Datenübertragung
EP3743844B1 (de) Blockchain-basiertes identitätssystem
DE60027838T2 (de) Beglaubigungsvorrichtung and Verfahren, die anatomische Informationen verwenden
DE102008042582A1 (de) Telekommunikationsverfahren, Computerprogrammprodukt und Computersystem
EP3254432B1 (de) Verfahren zur berechtigungsverwaltung in einer anordnung mit mehreren rechensystemen
EP1652337B1 (de) Verfahren zum signieren einer datenmenge in einem public-key-system sowie ein datenverarbeitungssystem zur durchführung des verfahrens
WO2022194658A1 (de) Verfahren zur autorisierung eines ersten teilnehmers in einem kommunikationsnetz, verarbeitungseinrichtung, kraftfahrzeug und infrastruktureinrichtung
EP3125464B1 (de) Sperrdienst für ein durch einen id-token erzeugtes zertifikat
DE60216056T2 (de) Verfahren und anordnung in einem kommunikationssystem
EP1817752A2 (de) Verfahren zur personalisierung von chipkarten
DE102021004548A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
EP3232640A1 (de) Gültigkeitsprüfung und sperrung von zertifikaten
EP3289507B1 (de) Id-token, system und verfahren zur erzeugung einer elektronischen signatur
EP3215977A1 (de) Verfahren zur änderung einer in einer chipkarte gespeicherten datenstruktur, signaturvorrichtung und elektronisches system
EP3248356B1 (de) Zertifikats-token zum bereitstellen eines digitalen zertifikats eines nutzers
EP4115584A1 (de) Gesicherter und dokumentierter schlüsselzugriff durch eine anwendung
WO2023011756A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
WO2021175372A1 (de) Verfahren und vorrichtung zur zertifizierung eines anwendungsspezifischen schlüssels und zur anforderung einer derartigen zertifizierung

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22713902

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18548373

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 202280021224.3

Country of ref document: CN

122 Ep: pct application non-entry in european phase

Ref document number: 22713902

Country of ref document: EP

Kind code of ref document: A1