CONCEPT FOR THE EXCHANGE OF CRYPTOGRAMIC KEY INFORMATION

Description

[0001] The present invention relates to computer-implemented methods, devices and computer programs for exchanging cryptographic key information.

[0002] Asymmetric cryptography is a popular method in cryptography for encrypting data to be sent to a recipient without first agreeing on a secret key that must be exchanged between the two communication partners in a way that is secure against eavesdropping and manipulation. In this method, each participant generates a key pair consisting of a private and a public key.

[0003] As the name suggests, the public key contains no secret, but can be distributed publicly (for this purpose, for example, there are public key servers through which one can make one's own public key accessible to the general public).

[0004] If a sender wants to transmit information to a recipient in encrypted form, they request the recipient's public key from the recipient (or from one of the public key servers described above), which can be used to encrypt a message to them (and only to them).

[0005] The special feature of asymmetric cryptography is that a message encrypted with a public key can only be decrypted with the corresponding private key. Therefore, the private key of such a key pair should be kept strictly secret.

[0006] In contrast, symmetric cryptography uses the same key for both encryption and decryption of a message. Therefore, this type of encrypted communication requires the exchange of such a key beforehand via a secure channel (e.g., a face-to-face meeting). This also highlights the advantage of asymmetric cryptography, as the public nature of the public key eliminates the need for such a secure exchange. If two people wish to communicate with each other using encryption, they only need to know each other's public key, which is generally straightforward.

[0007] Another feature of asymmetric cryptography is the signing of messages. If the sender of a message wants to digitally sign it to prove that it actually originates from them, they can sign it with their private key. The recipient can then verify the signature of the message—thus ensuring its authenticity—using the sender's public key. Since the private key is secret, the recipient can be relatively certain that the message actually comes from the expected person.

[0008] In the future, more and more devices connected to a network (such as the internet) – so-called "IoT devices" (Internet of Things devices) – will provide data, for example, in process networks (such as those in the context of supply chains). One challenge here can be ensuring that the received data actually originates from the expected device and not from a sender that is merely impersonating the device from which the data appears to have come.

[0009] This is possible in some systems using certified signatures. However, if the IoT device is to operate as independently / autonomously as possible and, above all, be able to establish and maintain communication relationships that cannot be compromised or intercepted, even by the device manufacturer (or the institution that equips the device with key material), then a secure key exchange must be implemented. If only a few devices are involved in such scenarios, a key exchange between two participants can be carried out in the conventional, direct manner: the two communication parties exchange their keys directly and securely against tampering and eavesdropping (such as in a personal and private meeting).However, if many devices (or "process instances") act as data providers in the affected deployment scenario, and these devices are no longer individually known or reachable, this approach quickly becomes impractical. This is especially true for scenarios where the number of recipients of such information, or more generally, the number of communication partners, is high. In such cases, a communication network with many one-to-one communication channels and potentially additional communication groups quickly emerges, making direct and secure key exchange between all participating parties impractical.

[0010] One application of such key exchange is communication between vehicles and other road users, or between a vehicle and its manufacturer. If data from connected vehicles or other road users (such as traffic infrastructure) is to be trusted without reservation in the future, there should be a way to securely exchange key material between road users. This material should not only secure the transmission path via standard mechanisms, but also ensure that the sender is indeed the device or person it claims to be. This would allow consumers of the data to securely authenticate its origin.

[0011] From US patent 2018 / 0343238 A1, a system and method for securing communication are disclosed. In this process, device data is encrypted from a device using a public key of an authentication counterpart and, if necessary, signed with a private key of the device. This encryption is performed using a virtual communication kernel, which is transmitted from the authentication counterpart to the device and performs the authentication.

[0012] From US patent 2017 / 0180128 A1, a method for managing a trusted device identity is disclosed. In this method, the result of the digital identity verification is stored by a trusted identity issuer on a distributed ledger so that it can be retrieved for review by verification authorities.

[0013] There is a need to provide an improved concept for key exchange between different parties, especially between road users.

[0014] The present invention is described by interrelated methods according to claims 1 and 11, programs according to claims 10 and 13, and devices according to claims 14 and 15. Preferred embodiments are defined in the dependent claims.

[0015] Exemplary embodiments of the present disclosure are based on the finding that key exchange can be secured by storing a shared secret signed by a central authority on a newly initialized device. The shared secret can be verified using the signature, then signed by the device, encrypted with a public key of the central device, and delivered to the central authority. This verifies to the central authority that it is the "correct" device. The signed and encrypted shared secret can then be used to transmit, on the one hand, the address of an electronic mailbox on the device and, on the other hand, a public key of the device to the central authority. The central authority can then sign the device's public key and make it available for retrieval.Furthermore, the address of the electronic mailbox can be made accessible to other communication partners. This creates a fully secure key exchange for newly initialized (Internet of Things) devices.

[0016] For such scenarios, further developments of the invention particularly benefit from solutions based on distributed networks, such as Distributed Ledger Technology (DLT), since the distributed data structure reduces (or practically eliminates) the susceptibility to manipulation, increases transparency for all participants, and thus eliminates the need for trusted intermediaries (so-called "trust authorities"). This is advantageous because such trust authorities must be trusted not only for their integrity but also for the robust protection of their own information technology systems to prevent third parties from causing harm. Further developments of the present invention therefore benefit from the use of Distributed Ledger Technology; however, the underlying concept can also provide security gains without the use of such networks.

[0017] Exemplary embodiments of the present disclosure provide a (first) computer-implemented method for exchanging cryptographic key information between a device and a central authority. The method is executed by the device. The method includes obtaining a cryptographic secret. The cryptographic secret is known to the central authority. The device receives the cryptographic secret from the central authority. The method includes obtaining a public key of the central authority, for example, from an electronic mailbox of the central authority. The method includes generating a cryptographic key pair for the device, consisting of a private key of the device and a public key of the device. The method further includes signing the cryptographic secret with the private key of the device.The procedure involves encrypting the cryptographic secret, signed with the device's private key, with the central authority's public key. The procedure then includes providing the encrypted and signed cryptographic secret, the address of an electronic mailbox belonging to the device, and the device's public key to the central authority via the central authority's electronic mailbox. The encrypted and signed cryptographic secret is transmitted to the central authority to prove that the device possesses the cryptographic secret. This allows the device to securely disclose itself to the central authority.

[0018] For example, obtaining the central authority's public key could involve obtaining the address of the central authority's electronic mailbox and retrieving the central authority's public key from the central authority's electronic mailbox. This would allow the currently valid public key of the central authority to be obtained.

[0019] For example, the central office's electronic mailbox and the device's electronic mailbox can be accessed via a distributed database. A distributed database can offer greater security because redundancy avoids a single point of failure that could be exploited to thwart key exchange. Furthermore, any manipulations can be traced.

[0020] For example, the distributed database can be based on distributed ledger technology. Accordingly, the addresses of the central office's electronic mailbox and the device's electronic mailbox can be addresses on the distributed ledger. Distributed ledger technology combines the redundancy of distributed databases with protection against manipulation of individual nodes.

[0021] For example, the distributed database can be based on a plurality of nodes. Sending and / or receiving data via an electronic mailbox through the distributed database can be based on a random selection of one or more nodes from the plurality of nodes for sending and / or receiving the information. This random selection prevents data exchange from being sabotaged by manipulating a few pre-selected nodes. Using multiple nodes increases redundancy and thus also the reliability of data transmission.

[0022] In some embodiments, the cryptographic secret is signed by a private key of the central authority. The procedure can further include verifying the signature of the cryptographic secret based on the central authority's public key. This allows the authenticity of the signature, and thus also of the cryptographic secret, to be verified.

[0023] The verification of the signature and / or the generation of the cryptographic key pair can be performed, at least partially, in a trusted execution environment (also known as a "Trusted Execution Environment") on the device. This provides additional security for the verification of the signature and / or the generation and / or storage of the device's key pair.

[0024] For example, verifying the signature of the cryptographic secret may involve verifying the signature of the cryptographic secret through a Certificate Authority (CA). Involving a CA can further complicate the manipulation of the key exchange.

[0025] In some embodiments, the method further includes generating the address of the device's electronic mailbox based on another cryptographic secret. In other words, the device's electronic mailbox address can be derived from a cryptographic secret.

[0026] The procedure may also include obtaining a version of the device's public key signed by the central authority. The central authority's signature serves to attest to the authenticity of the device's public key to third parties.

[0027] For example, the procedure may also include providing the signed version of the device's public key via the device's electronic mailbox. Alternatively, the central authority itself may place the signed version of the device's public key in the device's electronic mailbox. Third parties can then retrieve the signed public key from the device's electronic mailbox.

[0028] In at least some embodiments, the method can further include providing the address of the device's electronic mailbox to one or more other electronic mailboxes of one or more of the device's communication partners. This allows the device's electronic mailbox to be made known to the communication partners.

[0029] For example, the method may further involve receiving one or more messages for the device via the device's electronic mailbox and decrypting the one or more messages using the device's private key. In other words, the method may involve encrypted communication based on the device's key pair.

[0030] Embodiments of the present disclosure further provide a (second) computer-implemented method for exchanging cryptographic key information between a device and a central authority. The method is executed by the central authority. The method comprises providing a cryptographic secret to the device. The method further comprises providing a public key of the central authority to the device, for example, via an electronic mailbox of the central authority. The method further comprises receiving from the device a version of the cryptographic secret encrypted with the public key of the central authority and signed with a private key of the device, an address of an electronic mailbox of the device, and a public key of the device.The encrypted and signed cryptographic secret is transmitted from the device to the central authority to prove to the central authority that the device possesses the cryptographic secret. The procedure further includes verifying the received version of the cryptographic secret using the central authority's private key and the cryptographic secret itself. The procedure also includes encrypted communication with the device via its electronic mailbox using the device's public key. By transmitting the signed and encrypted version of the cryptographic secret, the device's identity can be verified to the central authority.

[0031] In some embodiments, the method may further include signing the device's public key with the central authority's private key and providing the signed public key to the device. This verifies the device's public key through the central authority.

[0032] Further embodiments of the present disclosure provide a program with program code for carrying out at least one of the methods when the program code is executed on a computer, a processor, a control module or a programmable hardware component.

[0033] Embodiments of the present disclosure further provide a computer-implemented device for exchanging cryptographic key information between a device and a central authority. The device is suitable for exchanging the cryptographic key information from the device's side. The device includes an interface for communication with the central authority. The method further comprises one or more processors configured to execute the first method. Embodiments further provide the device with the device.

[0034] Embodiments of the present disclosure further provide a computer-implemented device for exchanging cryptographic key information between a device and a central entity. The device is suitable for exchanging the cryptographic key information from the central entity. The device includes an interface for communication with the device. The device further includes one or more processors configured to execute the second method. Embodiments further provide the central entity with the device.

[0035] Further advantageous embodiments are described in more detail below with reference to the exemplary embodiments shown in the drawings, to which the exemplary embodiments are generally, but not entirely, limited. The drawings show: Fig. 1a shows a flowchart of an embodiment of a method for exchanging cryptographic key information between a device and a central authority from the device's perspective; Fig. 1b shows a block diagram of an embodiment of a device for exchanging cryptographic key information between a device and a central authority from the device's perspective; Fig. 2a shows a flowchart of an embodiment of a method for exchanging cryptographic key information between a device and a central authority from the central authority's perspective; Fig. 2b shows a block diagram of an embodiment of a device for exchanging cryptographic key information between a device and a central authority from the central authority's perspective; Fig.Figure 3a shows a flowchart of an embodiment of a method for providing encrypted data from a data source to a plurality of devices; Figure 3b shows a block diagram of an embodiment of a device for providing encrypted data from a data source to a plurality of devices; Figure 4 shows a schematic overview of keys and mailbox addresses in the distributed ledger; Figure 5 shows a schematic diagram of equipping a vehicle with a cryptographic secret; Figure 6 shows a schematic diagram of verifying a signature of the cryptographic secret; Figure 7 shows a schematic diagram of generating an electronic mailbox address; Figure 8 shows a schematic diagram of generating a key pair by the vehicle; Figure 9 shows a schematic diagram of an exchange of information between the vehicle and the central authority; and Figure 10.Figure 10 shows a schematic diagram of the authentication of vehicle information by the central authority.

[0036] Various embodiments will now be described in more detail with reference to the accompanying drawings, in which some embodiments are illustrated.

[0037] In the following description of the accompanying figures, which only show some exemplary embodiments, identical reference numerals can denote identical or comparable components. Furthermore, collective reference numerals can be used for components and objects that appear multiple times in an embodiment or in a drawing, but are described jointly with respect to one or more features.

[0038] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning that an average person skilled in the field to which the examples of implementation belong would ascribe to them. Furthermore, it should be clarified that expressions, e.g., those defined in commonly used dictionaries, are to be interpreted as having the meaning consistent with their meaning in the context of the relevant technology, and not in an idealized or overly formal sense, unless expressly defined herein.

[0039] Fig. 1a Figure 1 shows a flowchart of an embodiment of a (computer-implemented) method for exchanging cryptographic key information between a device 100 and a central authority 200 from the device's side. In other words, the method is executed by the device, for example, by a processor of the device. The method includes obtaining 110 a cryptographic secret, wherein the cryptographic secret of the central authority is known. The method includes obtaining 120 a public key of the central authority. The method includes generating 130 a cryptographic key pair for the device, consisting of a private key of the device and a public key of the device. The method includes signing 140 the cryptographic secret with the device's private key.The procedure comprises encrypting the cryptographic secret, signed with the device's private key, with the central authority's public key. The procedure further comprises providing the encrypted and signed cryptographic secret, the address of an electronic mailbox of the device, and the device's public key to the central authority via an electronic mailbox of the central authority.

[0040] Fig. 1b Figure 1 shows a block diagram of an embodiment of a device 10 for exchanging cryptographic key information between a device and a central authority. The device includes an interface 12 for communication with the central authority (e.g., via a distributed database). The device further includes one or more processors 14 that are coupled to the interface. In general, the functionality of the device is provided by the one or more processors, for example, via the interface. For instance, the one or more processors can be configured to perform internal calculations of the device and to coordinate communication with the central authority or other communication partners. The interface can be used to carry out the communication. The one or more processors are configured to execute the method of Fig. 1a , for example in conjunction with the interface. Consequently, the device, and in particular the one or more processors of the devices, is further developed by the features of the method. Fig. 1b Furthermore, the device 100 with the device 10 is shown.

[0041] Some embodiments of the present disclosure relate to a computer-implemented method, a computer-implemented device, and / or a computer program for exchanging cryptographic key information between the device 100 and the central entity 200 from the device 100's side. In principle, the device can be, for example, an Internet of Things (IoT) device. This generally includes devices that communicate (autonomously) with other devices; that is, an Internet of Things device can be characterized as a device that is "networked," meaning it is designed to communicate with one or more other devices. In the following, the device is specifically described as a vehicle; that is, the device 100 can be a vehicle, such as a motor vehicle. However, the same concept can also be applied to components of the vehicle, such as control units.In other words, the device could be, for example, a control unit for a vehicle. The device communicates with a central entity. This central entity could be, for example, a central server, i.e., a server designed to communicate with multiple devices. For instance, the central entity could be a server belonging to the manufacturer or operator / customer of the device, such as a vehicle manufacturer or a fleet operator.

[0042] In principle, the present method is used to enable secure encrypted communication between the device and a counterpart, such as between the device and other devices (which can act as a data source for the device) or between the device and the central authority. The device can also be considered a data source for other devices, and other devices can act as data sources for the device. Therefore, a data source, as referenced in the present disclosure, can also be the device itself, and accordingly, the method can be used. Fig. 1a The encrypted, signed cryptographic secret is transmitted to the central authority to prove that the device possesses the cryptographic secret. Furthermore, the device's public key is transmitted to the central authority so that it can a) be signed by the central authority and b) be used by the central authority to encrypt messages to the device.

[0043] Basically, key exchange is based on two components - the device's key pair and the cryptographic secret.

[0044] The procedure therefore includes obtaining the cryptographic secret. The cryptographic secret is known to the central authority. Consequently, the cryptographic secret is obtained from the central authority, or at least from an intermediary who also provides the cryptographic secret to the central authority. In general, the cryptographic secret can be read from a memory of the device, such as a secure memory of the device. For example, the cryptographic secret may be contained in the device's firmware (hardware programming). Obtaining the cryptographic secret can involve reading the cryptographic secret from the (secure) memory / firmware. For example, the cryptographic secret may be stored in a secure execution environment (also called a Trusted Execution Environment) of the device / equipment and read from there.

[0045] The procedure further includes obtaining the central authority's public key, for example, by retrieving it from the central authority's electronic mailbox or by reading the central authority's public key from a (secure) memory / firmware location on the device. For example, obtaining the central authority's public key could involve obtaining the address of the central authority's electronic mailbox and retrieving the central authority's public key from that mailbox. The mailbox address could be stored in the device's (secure) memory / firmware, such as in the secure execution environment. In another implementation, obtaining the central authority's public key could involve retrieving it from a public key server.

[0046] The central authority's public key can be used, for example, to encrypt messages for the central authority and to verify the cryptographic secret's authenticity. For instance, the cryptographic secret can be signed by the central authority's private key. In other words, the central authority can sign the cryptographic secret. The central authority's signature can be verified using the central authority's public key. For example, the procedure can further include verifying the cryptographic secret's signature based on the central authority's public key. Additionally or alternatively, the cryptographic secret's signature can be verified using a Certificate Authority (CA).The device's (secure) storage / firmware can include a data structure with addresses of trusted CAs that can be contacted to verify the signature of the cryptographic secret. Verifying the signature of the cryptographic secret can involve checking it via a certification authority, for example, by submitting the signature to the certification authority and receiving a verification result from the authority. Communication with the certification authority can also take place via interface 12.

[0047] The procedure further includes generating the cryptographic key pair for the device. This cryptographic key pair comprises the device's private key and its public key. The cryptographic key pair is, for example, a key pair for use in asymmetric cryptography. The private key is preferably known only to the device (e.g., stored in the trusted execution environment), and the public key can be used by other devices / the central authority to encrypt messages for the device and / or to verify the device's signature. The device's public key can be provided (in a version signed by the central authority) via the device's electronic mailbox.

[0048] Once the device's cryptographic key pair has been generated, and optionally the signature of the central authority of the cryptographic secret has been verified, the cryptographic secret can be transmitted to the central authority. To later demonstrate to the central authority that the device's public key, which is also transmitted, is authentic, the cryptographic secret is also signed by the device using its private key. The central authority can verify this signature using the device's public key, thereby simultaneously proving the authenticity of the device's public key. Therefore, the procedure involves signing the cryptographic secret with the device's private key.In asymmetric cryptography, the private key is used to sign messages and to decrypt encrypted messages based on the public key. The public key is used to verify the signature and to encrypt messages for the respective device. Generally, a signature is a value based on both the data being signed and the private key. The signature is the result of a cryptographic operation performed on the data being signed (or on a hash value of the data being signed), where the cryptographic operation is based on the private key. The signature can then be verified using the public key (via another cryptographic operation based on the public key).At the same time, the integrity of the signed message can be verified, since the signature must match the signed data. The signature process generally leaves the data being signed untouched; the signature is usually simply added.

[0049] The procedure further includes encrypting the cryptographic secret, signed with the device's private key, with the central authority's public key, for example, to prevent interception or manipulation of the cryptographic secret signed with the device's private key by an intermediary. Through encryption, the data to be encrypted—in this case, the cryptographic secret signed with the device's private key—is converted into a format based on the recipient's public key using a cryptographic calculation, so that the encrypted data can only be decrypted using the corresponding private key.

[0050] The procedure further includes providing (i.e., transmitting) the encrypted and signed cryptographic secret, the address of the device's electronic mailbox, and the device's public key to the central authority via the central authority's electronic mailbox. In other words, the aforementioned data is transmitted to the central authority's electronic mailbox. Part of the data may be provided by reference. For example, the device's public key may be stored in the device's electronic mailbox, and the device's electronic mailbox address may be transmitted as a reference to the central authority's electronic mailbox without transmitting the actual public key to the central authority's electronic mailbox.

[0051] In order to transmit the device's electronic address to the central authority's mailbox, the procedure may further include generating the device's electronic mailbox address based on another cryptographic secret. Alternatively, the electronic mailbox address may be generated by another device, such as the central authority (which would also eliminate the need to transmit the address) or by an administrative entity of the decentralized database.

[0052] In at least some embodiments, the method further comprises receiving a version of the device's public key signed by the central authority from the central authority. The signature is based, for example, on the central authority's private key. The method may also include making the signed version of the device's public key available via the device's electronic mailbox, for example, to provide the public key to other devices for signature verification and / or for signed communication with the device. For this purpose, the version of the device's public key signed by the central authority may, for example, be transmitted to the device's electronic mailbox. Subsequently (or before / simultaneously), the address of the electronic mailbox may be made public so that other devices can send encrypted data / messages to the device.The procedure may also include providing (e.g., transmitting) the address of the device's electronic mailbox to one or more other electronic mailboxes of one or more communication partners of the device and / or to a central register of electronic mailbox addresses.

[0053] Based on the public key, the central authority and / or one or more other devices can now send encrypted messages to the device. The procedure can further include receiving (e.g., retrieving) one or more messages (encrypted with the device's public key) for the device via the device's electronic mailbox. The procedure can further include decrypting the one or more messages with the device's private key. To communicate with the central authority, the device can encrypt the relevant data / messages with the public keys of the respective devices / the central authority. Cryptographic keys from group communication can also be used for encrypted communication. This is discussed in the context of the Fign. 3a and / or 3b further explained, but also applies to the method / device of Fign. 1a and / or 1b applicable.

[0054] The following describes the communication process using the example of receiving data from a data source. For instance, the procedure might involve receiving a message from a data source via an electronic mailbox (which may be accessible through the decentralized database). The message may contain data that is individually encrypted for the device by the data source. For example, the message may be received via the data source's electronic mailbox or via a group electronic mailbox. In this case, the procedure may further involve receiving a notification of the message via the device's electronic mailbox. Alternatively, the message may be received directly via the device's electronic mailbox. The procedure may also involve decrypting the data based on a cryptographic key of the device. This process, as well as the related... Fign. 3a and / or 3b, different types of cryptographic keys are considered. For example, the data may be encrypted based on a device-specific public key. In this case, the data can be decrypted based on a device-specific private key. Alternatively or additionally, the data may be encrypted based on a group cryptographic key. In this case, the data can be decrypted based on a symmetric key for the group or based on a private key for the group.

[0055] As previously mentioned, communication between the device and the central office and / or other communication partners (such as other devices) is based on so-called electronic mailboxes. These electronic mailboxes can be hosted outside the respective devices / central office, for example, via a distributed (decentralized) database or a centralized database. In principle, the mailboxes can be publicly accessible, so that, for example, any device with access to the distributed database can write to and / or read from the respective mailbox. In other words, the central office's electronic mailbox and the device's electronic mailbox can be accessed via a distributed database or, alternatively, via a centralized database.A distributed database is characterized by the fact that it is not controlled by a single entity, but rather distributed across a plurality of (computing) nodes. In other words, the distributed database can be based on multiple nodes. Data in the distributed database is replicated between the computational nodes of this plurality of nodes. Data can be added to the distributed database by the nodes and then replicated to the other nodes. One possible implementation of such a distributed database is based on distributed ledger technology. Various distributed ledger technologies are conceivable for this purpose, such as blockchain or a directed acyclic graph.The addresses of the central authority's electronic mailbox and the device's electronic mailbox can therefore be addresses on the distributed ledger.

[0056] The electronic mailboxes in question can be, for example, data storage provided by the distributed or centralized database. These data storage locations can be accessed by the participating process partners, such as the device and the central entity, as well as by other devices with access to the distributed or centralized database, for example, with the ability to read data from and write data to the data storage location.To send a message / data to another entity, this message / data can either be stored in the data storage corresponding to the other entity's electronic mailbox, or the message / data can be stored in a data storage corresponding to the sending entity's electronic mailbox, and a notification can additionally be stored in the data storage corresponding to the other entity's electronic mailbox. The electronic mailboxes are located outside of the respective devices, in the distributed or centralized database. In the context of distributed ledger technology, an electronic mailbox is a data storage location accessible via an address on the distributed ledger, and where data can be stored via the distributed ledger.

[0057] Consequently, the data exchanged via the mailboxes will be stored in the distributed ledger. To increase reliability, two approaches can be chosen. Firstly, the respective data can be inserted into the distributed database on multiple nodes. Secondly, the nodes can be selected based on a random procedure. In other words, sending and / or receiving data via an electronic mailbox through the distributed database can be based on a random selection of one or more nodes from the plurality of nodes for sending and / or receiving the information. In other words, the device for sending / transmitting data via a mailbox can send the relevant data to (a random selection of) multiple nodes of the distributed database.To retrieve data from a mailbox, the device can receive the relevant data from (a random selection of) multiple nodes in the distributed database, and then compare the data from the different nodes to obtain unmodified data.

[0058] In general, operations requiring particularly high security can be performed in the device's trusted execution environment. For example, verifying the signature of the cryptographic secret and / or generating the cryptographic key pair can be performed, at least partially, in a trusted execution environment of the device. For example, the trusted execution environment can be provided by a processor or system-on-a-chip (SoC) of the device, such as a processor / SoC 14 of Device 10. Other cryptographic operations, such as signing and / or encrypting the cryptographic secret, can also be performed in the trusted execution environment.

[0059] Interface 12 can, for example, correspond to one or more inputs and / or one or more outputs for receiving and / or transmitting information, such as digital bit values ​​based on a code, within a module, between modules, or between modules of different entities. For instance, interface 12 can be configured to communicate via the distributed database. The distributed database can be accessed via a computer network, such as a public network like the internet, or via a private network. Accordingly, interface 12 can be configured to access the distributed database via a computer network.Access to the distributed database can be achieved by sending and receiving digital data packets, for example by using provided interfaces by computing nodes that provide the distributed database.

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

[0061] More details and aspects of the procedure and device of Fign. 1a and / or 1b are mentioned in connection with the concept or examples that precede or follow (e.g. Fig. 2a bis 10 ) will be described. The method and apparatus of the Fign. 1a and / or 1b may include one or more additional optional features that correspond to one or more aspects of the proposed concept or the examples described, as described before or after.

[0062] Fig. 2a Figure 1 shows a flowchart of an embodiment of a method for exchanging cryptographic key information between a device 100 and a central authority 200 from the perspective of the central authority 200. In other words, the method is carried out by Fig. 2a carried out by the central authority. The procedure includes providing a cryptographic secret to the device. The procedure includes providing a public key of the central authority to the device. The procedure includes receiving from the device a version of the cryptographic secret encrypted with the public key of the central authority and signed with a private key of the device, an address of an electronic mailbox of the device, and a public key of the device. The procedure includes verifying the received version of the cryptographic secret based on a private key of the central authority and based on the cryptographic secret itself. The procedure includes encrypted communication with the device via the electronic mailbox of the device based on the public key of the device.

[0063] Fig. 2b Figure 1 shows a block diagram of an exemplary embodiment of a corresponding (computer-implemented) device 20 for exchanging cryptographic key information between a device and a central entity. In other words, the device 20 is suitable for exchanging cryptographic key information from the central entity. The device includes an interface 22 for communication with the device and / or with one or more other devices, for example, via the distributed database. The device also includes one or more processors 24 that are coupled to the interface. In general, the functionality of the device is provided by the one or more processors, for example, via the interface.For example, the one or more processors can be configured to perform internal calculations of the device and to coordinate communication with the device or other communication partners. The interface can be used to carry out the communication. The one or more processors are configured to execute the procedure of [missing information]. Fig. 2a , for example in conjunction with the interface. Consequently, the device, and in particular the one or more processors of the devices, is further developed by the features of the method.

[0064] While in connection with the Fign. 1 a bis 1b The exchange of cryptographic key information, previously described from the device's perspective, is now being discussed in the context of the Fign. 2a bis 2b The perspective of the central authority is adopted. In this process, the central authority and the device interact, either with a time delay (by providing data that is stored in the device's firmware) or through time-linked communication, for example, to provide a signed version of the device's public key.

[0065] As previously explained, the central point can be, for example, a device such as a computer, a computer instance, a server, a server instance, or a data processing unit designed to communicate with multiple devices. In other words, the central point can be responsible for multiple devices and / or be connected to multiple devices via data communication. For example, the central point could be a server belonging to a manufacturer or operator / customer of the device, such as a vehicle manufacturer or a fleet operator. In some implementations, this can be done via a distributed database. The central point can be configured to access the distributed database via a computer network, such as the internet or a private computer network.

[0066] The procedure involves providing the cryptographic secret to the device. For example, providing the cryptographic secret may involve generating the cryptographic secret, perhaps based on a cryptographic random function. Furthermore, providing the cryptographic secret may involve signing the cryptographic secret based on a private key of the central authority. Thus, the central authority, like the device, can possess a cryptographic key pair consisting of a private key and a public key. The cryptographic secret may be provided to the device during manufacturing. For example, the cryptographic secret may be included in the device's firmware or transferred to the device's memory through an initial data write operation.The central authority can integrate the (signed) cryptographic secret into the firmware or into the data for the initial data upload.

[0067] The procedure further includes providing the central authority's public key to the device. The central authority's public key can also be integrated into the firmware or the data for the initial data upload. Alternatively, the central authority's public key can be provided via a central authority mailbox. For example, the device can also be provided with the central authority's mailbox address, perhaps via the firmware or the data for the initial data upload.

[0068] The procedure further includes receiving from the device the version of the cryptographic secret encrypted with the central authority's public key and signed with the device's private key, the device's electronic mailbox address, and the device's public key. The three components mentioned serve different purposes. For example, the data can be obtained from the central authority via the central authority's electronic mailbox. Part of the data can be provided by reference. For instance, the device's public key can be stored in the device's electronic mailbox, and the device's electronic mailbox address can be transmitted as a reference to the central authority's electronic mailbox without transmitting the actual public key to the central authority's electronic mailbox.

[0069] The cryptographic secret is primarily obtained to verify that the entity providing the data is indeed the device in question. Therefore, the procedure involves verifying the obtained version of the cryptographic secret using the central authority's private key and the cryptographic secret itself. The central authority is aware of the cryptographic secret and can therefore compare it to the cryptographic value provided to the central authority by the device.

[0070] The public key, in turn, is used to send encrypted messages to the device and to verify the authenticity of signed messages sent by the device. Accordingly, the procedure involves encrypted communication with the device via its electronic mailbox based on the device's public key. The device's electronic mailbox can then be accessed using its mailbox address. As already mentioned in connection with the Fign. 1a and 1b As described, the central office's electronic mailbox and the device's electronic mailbox can be accessible via a distributed database, or alternatively via a centralized database. Furthermore, the central office can transmit data to (a random selection of) several nodes of the distributed database to provide / transmit data via a mailbox.

[0071] To enable other devices to trust the device, the device's public key can be signed by the central authority. In other words, the procedure can involve signing the device's public key with the central authority's private key. The procedure can also involve making the signed public key available to the device, for example, via the device's electronic mailbox.

[0072] Interface 22 can, for example, correspond to one or more inputs and / or one or more outputs for receiving and / or transmitting information, such as digital bit values ​​based on a code, within a module, between modules, or between modules of different entities. For instance, interface 22 can be configured to communicate via the distributed database. The distributed database can be accessed via a computer network, such as a public network like the internet, or via a private network. Accordingly, interface 22 can be configured to access the distributed database via a computer network.Access to the distributed database can be achieved by sending and receiving digital data packets, for example by using provided interfaces by computing nodes that provide the distributed database.

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

[0074] More details and aspects of the procedure and device of Fign. 2a and / or 2b are mentioned in connection with the concept or examples that precede or follow (e.g. Fig. 1a bis 1b , 3a bis 10 ) will be described. The method and apparatus of the Fign. 2a and / or 2b may include one or more additional optional features that correspond to one or more aspects of the proposed concept or the examples described, as described before or after.

[0075] Fig. 3a Figure 1 shows a flowchart of an exemplary embodiment of a computer-implemented method for providing encrypted data from a data source to a plurality of devices. The method comprises obtaining one or more addresses from one or more electronic mailboxes of the plurality of devices. The method comprises obtaining cryptographic keys from the plurality of devices. The method comprises generating one or more messages for the plurality of devices based on the data. Individually encrypted messages are generated for the devices of the plurality of devices based on the cryptographic keys. The method comprises providing the one or more encrypted messages via at least one electronic mailbox based on the one or more addresses of the one or more electronic mailboxes of the plurality of devices.

[0076] Fig. 3b Figure 1 shows a block diagram of an embodiment of a corresponding computer-implemented device 30 for the encrypted provision of data from a data source 300 to a plurality of devices 100. The device includes an interface 32 for communication with the plurality of devices. The method further includes one or more processors 34 coupled to the interface. In general, the functionality of the device is provided by the one or more processors, for example, via the interface. For instance, the one or more processors may be configured to perform internal calculations of the device and to coordinate communication with the plurality of devices. The interface may be used to carry out the communication. The one or more processors are configured to execute the method of Fig. 3a , for example in conjunction with the interface. Consequently, the device, and in particular the one or more processors of the devices, is further developed by the features of the method. Fig. 3b further shows data source 300 with device 30.

[0077] Various embodiments of the present invention relate to a computer-implemented method, a computer-implemented device, and a computer program for providing data from a data source to a plurality of devices from the perspective of the data source. In principle, both the data source and the one or more devices can be, for example, Internet of Things (IoT) devices. These generally include devices that communicate (independently) with other devices; that is, an Internet of Things device can be characterized as a "networked" device, meaning it is designed to communicate with one or more other devices. In the following, particular reference is made to vehicles. Thus, the data source can be, for example, a vehicle, or one or more of the plurality of devices can be vehicles.In particular, the data source can also be a vehicle component, and the majority of devices can likewise be (other) vehicle components, such as the vehicle's control units. The data source and the majority of devices communicate with each other, for example, via a distributed database. This distributed database can be accessible, for instance, via a computer network.

[0078] The procedure involves receiving messages from one or more addresses on one or more electronic mailboxes belonging to multiple devices. In principle, multiple devices can be accessed via two different types of electronic mailboxes. Firstly, each device can have its own electronic mailbox, meaning each device is assigned a device-specific electronic mailbox. Secondly, multiple devices can also communicate via so-called group mailboxes, i.e., mailboxes used by multiple devices to receive messages. Each device can either monitor the group mailbox to receive newly received messages, or it can receive a notification about the arrival of a message in the group mailbox via its own device-specific electronic mailbox.Another possibility is that messages are stored in the electronic mailbox of the data source, and the respective device receives a notification of the message in its device-specific electronic mailbox. Therefore, the one or more addresses of the one or more electronic mailboxes can include addresses of the device-specific electronic mailboxes of the devices and / or addresses of one or more group electronic mailboxes used by the majority of devices.

[0079] The procedure further includes obtaining the cryptographic keys of the majority of devices. Analogous to mailboxes, two types of cryptographic keys are distinguished here. For example, the cryptographic keys can comprise one or more device-specific public keys of the majority of devices. These could be, for example, the respective public keys of an asymmetric key pair of the devices. Alternatively, the cryptographic keys for each device in the majority of devices could comprise a device-specific key. For example, obtaining the cryptographic keys of the majority of devices could involve retrieving a (device-specific) public key of the respective device from the device's electronic mailbox.Alternatively or additionally, the cryptographic keys can comprise one or more cryptographic keys for a group of devices, such as a cryptographic group key. The cryptographic group key can be, for example, a public group key of an asymmetric key pair for the respective group, or it can be a symmetric group key that is exchanged in encrypted form between the data source and the majority of devices (for example, based on asymmetric encryption using the public keys of the devices and the data source).

[0080] In general, the device addresses and / or cryptographic keys can be obtained in several ways. For example, the one or more addresses and / or cryptographic keys can be read from a memory of the data source, such as from the data source's firmware or from a trusted execution environment (TEO) of the data source. Alternatively or additionally, the one or more addresses and / or cryptographic keys can be obtained from a trusted central authority. Alternatively or additionally, the one or more addresses and / or cryptographic keys can be disclosed by the respective devices, for example, by notifying the data source via the data source's electronic mailbox.

[0081] The process further includes generating one or more messages for the majority of devices based on the data. For the majority of devices, individually encrypted messages are generated based on the cryptographic keys (and based on the data). The data can be, for example, data generated by the data source. For instance, the data source can be a sensor or include a sensor, such as a vehicle sensor, and the data can be sensor data from the sensor. Alternatively, the data source can be a vehicle control unit, and the data can be status information from the control unit. The data is encrypted individually for the majority of devices.

[0082] In some embodiments, "individually encrypted" does not necessarily mean that the data is encrypted separately for each device. For example, the data can be provided via one or more messages in such a way that the accessibility of the data within each encrypted message for the majority of devices is controlled by the encryption of the messages. In some embodiments, the data for a group of vehicles (i.e., a true subset of the majority of vehicles) can be encrypted with a group key, while for other vehicles the data can be encrypted with the respective device-specific public key. In other embodiments, however, the data for each device within the majority of devices is encrypted individually (e.g., separately). Furthermore, there are also several possibilities for generating the one or more messages.In one variant, a separate message can be generated for each vehicle in a group of multiple vehicles (which can be encrypted, for example, based on the vehicle's device-specific public key). The entire message content can be encrypted using a single cryptographic key. This approach can also be described as "data set-level encryption," since the entire data set (content) of the message is encrypted with the same key. An individually encrypted message can be generated for each device in a group of multiple devices. The individually encrypted message can contain the data that should be accessible to the respective device. Alternatively, a single message can contain multiple components, with the different components being encrypted differently.In other words, a single message can be generated for multiple devices. The data within the message can be individually encrypted for each of these devices. In other words, the components of the message can be intended for different devices within the range of devices and, accordingly, encrypted differently.

[0083] In some embodiments, the one or more messages are further signed by the data source using the data source's private key. The devices to which the messages are provided can then verify the authenticity of the messages based on the data source's public key. Accordingly, the method may include signing the one or more messages.

[0084] The method further comprises making the one or more encrypted messages available via at least one electronic mailbox based on the one or more addresses of the one or more electronic mailboxes of the plurality of devices. As previously described, several implementations are possible. For example, the one or more messages can be made available via an electronic mailbox of the data source or via a group electronic mailbox. In these cases, the method can further comprise making notifications about the making available of the one or more messages to the devices via the devices' electronic mailboxes (based on the addresses of the devices' electronic mailboxes). In other words, the data source can make the data available in a publicly accessible mailbox (of the data source or the group) and notify the individual devices accordingly.The respective devices can then retrieve the messages from the publicly accessible mailbox. Alternatively, one or more messages can be delivered (directly) via the devices' electronic mailboxes.

[0085] As previously mentioned, communication between the data source and the majority of devices is based on so-called electronic mailboxes. These electronic mailboxes can be hosted outside the data source / the respective devices, for example, via a distributed (decentralized) database or a centralized database. In principle, the electronic mailboxes can be publicly accessible, so that, for example, any device with access to the distributed database can write to and / or read from the respective mailbox. In other words, the electronic mailbox of the data source and the one or more electronic mailboxes of the majority of devices can be accessed via a distributed database or, alternatively, via a centralized database.The concept of electronic mailboxes and distributed databases, which is related to the . Fign. 1a bis 2b was presented.

[0086] Interface 32 can, for example, correspond to one or more inputs and / or one or more outputs for receiving and / or transmitting information, such as digital bit values ​​based on a code, within a module, between modules, or between modules of different entities. For instance, interface 32 can be configured to communicate via the distributed database. The distributed database can be accessed via a computer network, such as a public network like the internet, or via a private network. Accordingly, interface 32 can be configured to access the distributed database via a computer network.Access to the distributed database can be achieved by sending and receiving digital data packets, for example by using provided interfaces by computing nodes that provide the distributed database.

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

[0088] More details and aspects of the procedure and device of Fign. 3a and / or 3b are mentioned in connection with the concept or examples that precede or follow (e.g. Fig. 1a bis 2b , 4 bis 10 ) will be described. The method and apparatus of the Fign. 3a and / or 3b may include one or more additional optional features that correspond to one or more aspects of the proposed concept or the examples described, as described before or after.

[0089] Exemplary embodiments of the present invention relate to the secure key exchange for communication encryption and authentication checks with IoT devices, for example via distributed ledger networks.

[0090] The functionality of the invention is described using an example from the context of "supply chains," but it is relevant and applicable to any scenario exhibiting the features described above. Specifically, the present example concerns the outbound logistics process, i.e., the shipment of finished vehicles. Numerous partners (such as logistics providers, shipping companies, service providers, banks, insurance companies, etc.) and, of course, the vehicles themselves, fresh off the assembly line, participate in this process as process elements.

[0091] A participant within this process network wants to be certain that the received data originates from the vehicle in question and that it is indeed a vehicle belonging to the process partner (i.e., the OEM, Original Equipment Manufacturer). Likewise, the manufacturer / OEM wants to be certain that the received data actually comes from their own vehicle (which acts autonomously with regard to data transmission) and that an attacker has not hijacked its identity. Finally, the vehicle itself also wants to be certain that it has been equipped with key material by the correct institution (i.e., the OEM) and has not been manipulated by an attacker to send data under a false identity (i.e., a vehicle from one manufacturer impersonating a vehicle from another).In summary, no one (not the manufacturer, nor other participants, nor any attacker) should be allowed to send messages on behalf of a data provider (here: vehicle). The aforementioned requirements are met by at least some embodiments of the present disclosure, the implementation of which is described step by step below by way of example. For instance, the vehicle can transmit data to device 100 from... Fig. 1a and / or 1b, the vehicle manufacturer (e.g., a server of the vehicle manufacturer) of the central office 200 of Fig. 2a and / or 2b and the participant of the process network of a data source 300 of Fig. 3a and / or 3b may correspond.

[0092] Section 1.1: As mentioned above, some embodiments of the invention take advantage of the decentralized nature of distributed ledger networks. Fig. 4 Figure 400 shows a schematic overview of keys and mailbox addresses in the Distributed Ledger 400. Each participant 41; 42; 4n of such a network (in this example, a participant in a supply chain process network) can generate a pair of private and corresponding public keys (hereinafter referred to as "KP," for "KeyPair") KP T1, KP T2, KP Tn for both trusted authentication and encryption of information sent to them. In addition to this key pair, they use another private key S T1, S T2, S Tn (roughly equivalent to the further cryptographic secret), which represents their identity in the network (also called the "Seed"; hereinafter referred to as "S"). Their addresses in the network (which are technically public keys) are derived from this key "S."One of these addresses is chosen as the mailbox address to which messages addressed to him can be sent. This address is subsequently referred to as "LA" (for "Ledger Address," address in the ledger network). The user's own public key "\KPPubKey" (public key of the key pair), used for encrypting messages, is stored in this mailbox 410, 420, 4n0, so that other participants can send encrypted messages to the mailbox owner. The corresponding private key "KPPrivKey" remains hidden from the network. In some implementations, both the key pair "KP" and the mailbox address "LA" can only be generated once for participation in the network and not per process instance.

[0093] Section 1.2: Fig. 5 Figure 1 shows a schematic diagram of how a vehicle 100 is equipped with a cryptographic secret. When an IoT device (e.g., a vehicle) 100 is built, the manufacturer (e.g., the manufacturer's central office 200) equips it with a new and unique pair of private and corresponding public keys (hereinafter referred to as "KP Manufacturer-Device" (key pair Manufacturer-Device), containing "KPPubKeY Manufacturer-Device" (public key of the key pair Manufacturer-Device) and "KPPrivKey Manufacturer-Device" (private key of the key pair Manufacturer-Device)). This key pair can, for example, contain the cryptographic secret of the Fign. 1a bis 2b These keys (i.e., this cryptographic secret) are, for example, signed by the manufacturer's own Certificate Authority (CA). Additionally, the manufacturer provides the device / vehicle with its own mailbox address, LA Manufacturer. At this address, the IoT device finds the manufacturer's public key (KPPubKey Manufacturer), which it uses to verify the manufacturer's signature and to send encrypted messages to them.

[0094] Section 1.3: Fig. 6 Figure 1 shows a schematic diagram of a signature verification process for a cryptographic secret. Device / vehicle 100 uses the signature and knowledge of known trusted CAs 600 to verify whether the installed keys actually originate from manufacturer 200 (i.e., whether the key signature is valid and authentic).

[0095] The vehicle 100, for example, can use the knowledge of the electronic mailbox address (LA Manufacturer) 610 to retrieve the manufacturer's public key (KP PubKeyManufacturer) from the distributed ledger 400, and have the signature and the cryptographic secret (KP Manufacturer-Device) checked by the CA 600, which can confirm or deny whether the signature is authentic. This logic, in turn, is securely protected against manipulation, so that an attacker cannot disable or modify these checks (e.g., by embedding them in a so-called "Trusted Execution Environment").

[0096] Section 1.4: Fig. 7 shows a schematic diagram of the generation of an address for an electronic mailbox 700. Fig. 8 The diagram shows a schematic representation of the generation of a key pair by vehicle 100. Device / vehicle 100 generates the following for participation in the Distributed Ledger Network: a) its own network key (seed, see above) "S Fhzg", b) a mailbox address derived from this key ("LA IoT-Device", IoT-Device stands for Internet of Things device, in this case the vehicle), and c) a key pair for authentication and encryption of messages ("KP Iot-Device" with "KPPubKey IoT-Device" and "KPPrivKey IoT-Device"). Since the device / vehicle generates this new key material itself and does not receive it from the manufacturer, only the vehicle has knowledge of the private keys.

[0097] Section 1.5: Fig. 9 Figure 100 shows a schematic diagram of an information exchange between the vehicle and the central authority. The device / vehicle 100 signs the KPPrivKey manufacturer's device received from the manufacturer with its newly generated KPPrivKey IoT device (the vehicle / device 100's private key), encrypts it with the manufacturer's public key (KPPubKey manufacturer, the central authority's public key), and sends it—together with its own mailbox address (LA IoT device, the address of the vehicle / device 100's electronic mailbox) and its own self-generated public key KPPubKey IoT device (the vehicle / device 100's public key)—to the manufacturer's mailbox address 610 (LA manufacturer, the central authority's electronic mailbox address) on the Distributed Ledger 400.

[0098] Section 1.6: Fig. 10 Figure 1 shows a schematic diagram of the authentication of information from vehicle 100 by the central authority 200. The manufacturer downloads the data transmitted by the IoT device / vehicle from its mailbox 610 (a), decrypts it using its KPPrivKey Manufacturer, and checks (b) whether the secret KPPrivKey Manufacturer-Device is included in the message. This allows the manufacturer to authenticate the sender of the message, as only the genuine sender knows this secret. As a result of this successful verification, (c) the manufacturer 200 (the manufacturer's central authority) signs the public key of device / vehicle 100 (KPPubKey IoT-Device), which is also transmitted in this message, and sends it to the mailbox address of device / vehicle (LA IoT-Device) 700. Other participants can also use this signature to verify the authenticity of the data provider (i.e., the device / vehicle).At this point, if necessary, the KP manufacturer device, i.e., the initial key pair created by the manufacturer and passed to the IoT device, can be revoked, as it is no longer needed.

[0099] Section 1.7: The manufacturer, as the initiator of the process, typically specifies the other process participants and their roles (if necessary, further new participants may be defined by other participants in the process as the process progresses). In all cases, the new participant's email address can then be propagated to the email inboxes (electronic mailboxes) of all other participants (such as communication partners), thus successfully integrating the new participant into the process and making them known to all process participants, since only then can all other participants (and thus also the device / vehicle as the primary data provider) address and inform them. If a participant being added knows the addresses of the participants already involved, they can even carry out this onboarding process independently.

[0100] Section 1.8: The device / vehicle can now send authenticatable data to consumers or other process participants, secured by encryption. This data is signed with the KP PrivKeyIoT device. Consumers of this data can verify this signature using the KP PubKeyIoT device (which is provided by the Hersteller mit The device verifies that the data to be propagated is signed by the KP PrivKey manufacturer and the KP PubKey manufacturer. It then encrypts the data to be propagated using the respective public keys of the recipients (KPPubKey X) and sends it to the mailboxes (LA X) of the participants (or stores the data to be propagated in its own mailbox and notifies the participants via the mailboxes of the participants).

[0101] The following describes a possible implementation of data provision by other process participants. In such a network, it is possible that data is not only shared by the main data provider (i.e., the IoT device 100), but that other participants also contribute data (e.g., additions such as status changes, etc.). In such cases, the following procedure can be used: Section 2.1: The provider of the data (hereinafter referred to as "BD"; with its own mailbox LA BD, for example, data source 300 of Fign. 3a and / or 3b) creates a new address on the Distributed Ledger (i.e., a kind of additional mailbox, hereinafter referred to as "LA additionalDate"). This can happen either for each date to be distributed or once per process instance for multiple dates (in principle, this could also happen only once per process participant, but since there are usually different process participants per process instance, the data is mixed there). As described later, this step is optional. Section 2.2: The BD reads the mailbox addresses (LAX) of all other process participants (e.g., the majority of devices of the Fign. 3aand / or 3b) from its own mailbox LA BD (see sections 1.1 and 1.7 above) and retrieves the public key of each process participant from each mailbox, and thus also the public key of the IoT device (or, in the example, the vehicle). Section 2.3: The BD generates one message per process participant (device of the plurality of devices), containing the information to be distributed, and encrypts it with the respective public key of the corresponding participant. These messages are all sent, for example, to the address LA AdditionalDate. Section 2.4: The BD sends a notification about the new information stored in LA AdditionalDate (including the address) to the mailboxes of all process participants (e.g., the electronic mailboxes of the plurality of devices) in Section 2.5: The IoT device can optionally publish this information to its own messaging channel (for documentation purposes or to reach additional recipients who may not be known to BD). This approach also allows other process participants to contribute data. The detour via the LA AdditionalDate address (see sections 2.1 and 2.4) is intended (solely) for documentation purposes. Instead of channeling the messages about a new date into LA AdditionalDate and informing the process participants via a message to their mailboxes, it is of course also possible to propagate the new information directly to the mailboxes of the process participants.

[0102] Note: Section 1.7 describes how the process initiator determines the process participants. This gives this process participant, acting as a "man-in-the-middle," certain control options. To reduce this risk, communication partners regularly participating in such process networks can exchange their public keys and mailbox addresses directly.

[0103] Some implementations further enable visibility control at the "record" and "attribute" levels. Security in distributed ledger networks (DLTs) is achieved through a large number of decentralized copies of the same data, meaning an attacker would have to compromise a large portion of the network or its copies to manipulate the network's data. Public DLTs tend to have a large number of copies. However, even though transparency is a fundamental principle of such networks, one may not want, be able, or even be permitted to distribute data unencrypted.

[0104] The procedure described in this disclosure allows data visibility to be controlled both at the data record level (i.e., for a single data entry with typically several related attributes) and at the attribute level. For example, if an IoT device sends a specific status message, business or security requirements may dictate that not everyone should be able to see the entire status message, but rather that it should only be decryptable by specific participants in the process network (control of visibility at the data record level). Alternatively, the message itself might be visible to all network participants, but individual attributes of such a message (e.g., the GPS position (position according to a Global Positioning System), or similar) might only be visible to selected participants (control of visibility at the attribute level). Hybrid approaches are also possible.Since the data is encrypted with each participant's respective public key, only that participant can decrypt it (with their private key). This allows the data creator / distributor to control, based on roles, visibility groups, or individual permissions, which attributes are visible to which participant / role, as the data packets are distributed individually and encrypted.

[0105] If there are large overlaps, i.e., different process participants have the same visibility permissions for the same data records or attributes, it makes sense to assign such permissions a common key pair in order to reduce data redundancy on the exchange medium (e.g., the distributed ledger).

[0106] This can be done, for example, as follows: Section 3.1: The data provider (hereinafter referred to as "BD") generates a symmetric key (SGX) and a group mailbox (LA-GX) for each role / rights group and sends the key and the LA-GX address, encrypted with the respective participant's public key, to that group participant. Section 3.2: The BD encrypts data and / or attributes based on roles / rights groups. Data visible to multiple participants is encrypted with the group key SGX. The remaining data is encrypted on a participant-specific basis using the respective participant's public key. Section 3.3: The BD sends the data encrypted with the group key to the group mailbox LA-GX and the data encrypted with the participants' public keys to the participants' individual mailboxes.4: Each participant checks not only their personal mailbox but also the group mailbox for new messages. They decrypt the group mailbox messages using the provided group key, and messages to their personal mailbox using their private key. They then reassemble the data received through the different channels, if necessary.

[0107] Some embodiments of the present disclosure further reduce vulnerability through random distribution. DLT networks are characterized, among other things, by the existence of numerous decentralized entry points into the network (so-called "nodes"). Each node (at least the so-called "full nodes") stores the entire transaction history of the network, thus protecting it from manipulation. If a participant wishes to use such a network for data storage, they select a node and submit the data to be stored.

[0108] A node cannot modify the data if it did not create it itself (since this is usually signed with the sender's private key and any manipulation would therefore be quickly noticed), but it could discard individual transactions passed to it before inserting them into the ledger.

[0109] Furthermore, if the same node were chosen as the entry point into the DLT network for all transactions emitted by an IoT device, external attackers could potentially identify these nodes and disable them through an attack, thus preventing the distribution of data from the affected IoT device. To minimize the risk of manipulation through such attacks, in some implementations the emitted transactions are placed by the IoT device at randomly selected nodes (i.e., a random selection of one or more nodes from a plurality of nodes) for recording in the ledger, so that the communication between the device and the network is unpredictable.

[0110] At least some embodiments can be used outside of distributed ledger networks. As described above, the use of embodiments of this disclosure is not necessarily tied to distributed ledger networks. Even in an environment where data exchange takes place via a centralized architecture, the described procedure for secure key exchange can ensure the authenticity of messages and their senders. Security may be reduced in this case, however, because the central component, acting as a "man in the middle," has more extensive intervention capabilities than in a decentralized network structure. Compared to centralized "trust authorities," embodiments, especially those based on decentralized databases, offer significantly increased immunity to external and malicious influences.Examples of implementation can be used, for instance, in V2X communication (communication between vehicles and other communication partners, where X represents various types of communication partners). Further examples can be used in cases where data is exchanged with partners / (sub-)suppliers in process networks (in the supply chain).

[0111] Another embodiment is a computer program for carrying out at least one of the methods described above, provided the computer program runs on a computer, a processor, or a programmable hardware component. Another embodiment is a digital storage medium that is machine- or computer-readable and that contains electronically readable control signals which can interact with a programmable hardware component to execute one of the methods described above.

[0112] The features disclosed in the foregoing description, the following claims and the accompanying figures can be important and implemented individually or in any combination for the realization of an embodiment in its various configurations.

[0113] Although some aspects have been described in connection with a device, it is understood that these aspects also constitute a description of the corresponding process, so that a block or component of a device can also be understood as a corresponding process step or as a feature of a process step. Similarly, aspects described in connection with or as a process step also constitute a description of a corresponding block, detail, or feature of a corresponding device.

[0114] Depending on specific implementation requirements, embodiments of the invention can be implemented in hardware or in software. The implementation can be carried out using a digital storage medium, for example a floppy disk, DVD, Blu-ray disc, CD, ROM, PROM, EPROM, EEPROM or FLASH memory, hard disk or other magnetic or optical storage medium, on which electronically readable control signals are stored that can interact with, or interact with, a programmable hardware component in such a way that the respective method is carried out.

[0115] A programmable hardware component can be a processor, a computer processor (CPU = Central Processing Unit), a graphics processor (GPU = Graphics Processing Unit), a computer, a computer system, an application-specific integrated circuit (ASIC = Application-Specific Integrated Circuit), an integrated circuit (IC = Integrated Circuit), a system-on-a-chip (SOC = System on Chip), a programmable logic element, or a field-programmable gate array with a microprocessor (FPGA = Field Programmable Gate Array).

[0116] The digital storage medium can therefore be machine-readable or computer-readable. Some embodiments thus include a data carrier containing electronically readable control signals capable of interacting with a programmable computer system or programmable hardware component to execute one of the methods described herein. An embodiment is therefore a data carrier (or a digital storage medium or a computer-readable medium) on which the program for performing one of the methods described herein is recorded.

[0117] In general, embodiments of the present invention can be implemented as a program, firmware, computer program, or computer program product with program code or as data, wherein the program code or data is / are effective in carrying out one of the methods when the program runs on a processor or a programmable hardware component. The program code or data can, for example, also be stored on a machine-readable medium or data carrier. The program code or data can be in the form of, among other things, source code, machine code, bytecode, or other intermediate code.

[0118] Another embodiment is a data stream, a signal sequence, or a sequence of signals that represents the program for carrying out one of the methods described herein. The data stream, signal sequence, or sequence of signals can be configured, for example, to be transferred via a data communication link, such as the Internet or another network. Other embodiments include signal sequences representing data that are suitable for transmission via a network or data communication link, where the data represents the program.

[0119] A program according to one embodiment can implement one of the methods during its execution, for example, by reading memory locations or writing data to them, thereby potentially triggering switching operations or other processes in transistor structures, amplifier structures, or other electrical, optical, magnetic, or otherwise operating components. Similarly, by reading a memory location, a program can acquire, determine, or measure data, values, sensor values, or other information. Therefore, by reading from one or more memory locations, a program can acquire, determine, or measure quantities, values, measured values, and other information, and by writing to one or more memory locations, it can initiate, trigger, or execute an action, as well as control other devices, machines, and components.

[0120] The embodiments described above merely illustrate the principles of the present invention. It is understood that modifications and variations of the arrangements and details described herein will be obvious to other people skilled in the art. Therefore, it is intended that the invention be limited only by the scope of protection set forth in the following claims and not by the specific details presented herein by way of description and explanation of the embodiments. Reference symbol list

[0121] 10 Device for a device 12 Interface 14 One or more processors 20 Device for a central authority 22 Interface 24 One or more processors 30 Device for a data source 32 Interface 34 One or more processors 41, 42, 4n Participant in a process network 100 Device 110 Obtaining a cryptographic secret 120 Obtaining a public key from a central authority 125 Verifying a signature of the cryptographic secret 130 Generating a cryptographic key pair 135 Generating an electronic mailbox address of the device 140 Signing the cryptographic secret 150 Encrypting the signed cryptographic secret 160 Providing the encrypted signed cryptographic secret170 Obtaining a signed version of the device's public key 175 Providing the signed version of the device's public key 180 Providing the device's electronic mailbox address 190 Receiving one or more messages 195 Decrypting the one or more messages 200 Central Authority 205 Signing a cryptographic secret 210 Providing the cryptographic secret for a device 220 Providing a central authority's public key for the device 230 Obtaining a signed and encrypted version of the cryptographic secret, an electronic mailbox address of the device, and a public key of the device from the device , 240Verifying the signed and encrypted version of the cryptographic secret 250Encrypted communication with the device 260Signing the device's public key 300Data source 310Receiving device electronic mailbox addresses 320Receiving device cryptographic keys 330Generating one or more messages for the devices 335Signing the one or more messages 340Providing the one or more messages via an electronic mailbox 350Providing notifications 400Distributed Ledger 410, 420, 4n0Participant's postcards on the Distributed Ledger 600Trusted Certificate Authority 610Manufacturer's electronic mailbox 700Vehicle's electronic mailbox

Claims

1. A computer-implemented method for exchanging cryptographic key information between an apparatus (100) and a central entity (200), wherein the method is executed by the apparatus, the method comprising: receiving (110) a cryptographic secret, wherein the cryptographic secret is known to the central entity, wherein the apparatus receives the cryptographic secret from the central entity; receiving (120) a public key of the central entity; generating (130) a cryptographic key pair for the apparatus, comprising a private key of the apparatus and a public key of the apparatus; signing (140) the cryptographic secret using the private key of the apparatus; encrypting (150) the cryptographic secret signed using the private key of the apparatus using the public key of the central entity; providing (160) the encrypted and signed cryptographic secret, an address of an electronic mailbox of the apparatus and the public key of the apparatus to the central entity via an electronic mailbox of the central entity, wherein the encrypted and signed cryptographic secret is transmitted to the central entity to prove to the central entity that the apparatus has the cryptographic secret.

2. The method according to claim 1, wherein receiving (120) the public key of the central entity comprises receiving an address of the electronic mailbox of the central entity and retrieving the public key of the central entity from the electronic mailbox of the central entity.

3. The method according to either of claims 1 or 2, wherein the electronic mailbox of the central entity and the electronic mailbox of the apparatus are accessible via a distributed database.

4. The method according to claim 3, wherein the distributed database is based on a distributed ledger technology, wherein addresses of the electronic mailbox of the central entity and of the electronic mailbox of the apparatus are addresses on the distributed ledger.

5. The method according to either of claims 3 or 4, wherein the distributed database is based on a plurality of nodes, wherein providing and / or receiving data via an electronic mailbox via the distributed database is based on a random selection of one or more nodes of the plurality of nodes for providing and / or receiving the information.

6. The method according to any of claims 1 to 5, wherein the cryptographic secret is signed by a private key of the central entity, wherein the method further comprises verifying (125) the signature of the cryptographic secret on the basis of the public key of the central entity.

7. The method according to claim 6, wherein verifying the signature and / or generating the cryptographic key pair is performed at least partially in a trusted execution environment of the apparatus.

8. The method according to any of claims 1 to 7, comprising generating (135) the address of the electronic mailbox of the apparatus on the basis of a further cryptographic secret.

9. The method according to any of claims 1 to 8, comprising receiving (170) a version of the public key of the apparatus signed by the central entity from the central entity, and providing (175) the signed version of the public key of the apparatus via the electronic mailbox of the apparatus.

10. A program having a program code for performing the method according to any of the preceding claims if the program code is executed on a computer, a processor, a control module, or a programmable hardware component.

11. A computer-implemented method for exchanging cryptographic key information between an apparatus and a central entity, wherein the method is executed by the central entity, the method comprising: providing (210) a cryptographic secret for the apparatus; providing (220) a public key of the central entity for the apparatus; receiving (230) a version of the cryptographic secret encrypted using the public key of the central entity and signed using a private key of the apparatus, an address of an electronic mailbox of the apparatus, and a public key of the apparatus from the apparatus, wherein the encrypted and signed cryptographic secret is transmitted from the apparatus to the central entity to prove to the central entity that the apparatus has the cryptographic secret; verifying (240) the received version of the cryptographic secret on the basis of a private key of the central entity and on the basis of the cryptographic secret; communicating (250) in an encrypted manner with the apparatus via the electronic mailbox of the apparatus on the basis of the public key of the apparatus.

12. The method according to claim 11, comprising signing (260) the public key of the apparatus using the private key of the central entity, and providing (265) the signed public key for the apparatus.

13. A program having a program code for performing at least the method according to either of claims 11 or 12 if the program code is executed on a computer, a processor, a control module, or a programmable hardware component.

14. A computer-implemented device (10) for exchanging cryptographic key information between an apparatus and a central entity, wherein the device is suitable for exchanging the cryptographic key information from the apparatus side, the device comprising: an interface (12) for communication with the central entity; and one or more processors (14) configured to execute the method according to any of claims 1 to 9.

15. A computer-implemented device (20) for exchanging cryptographic key information between an apparatus and a central entity, wherein the device is suitable for exchanging the cryptographic key information from the central entity side, the device comprising: an interface (22) for communication with the apparatus; and one or more processors (24) configured to execute the method according to claim 11 or 12.