EP4662830A1 - Verfahren zur prüfung einer authentizität einer nachricht und gerät - Google Patents

Verfahren zur prüfung einer authentizität einer nachricht und gerät

Info

Publication number
EP4662830A1
EP4662830A1 EP24717109.3A EP24717109A EP4662830A1 EP 4662830 A1 EP4662830 A1 EP 4662830A1 EP 24717109 A EP24717109 A EP 24717109A EP 4662830 A1 EP4662830 A1 EP 4662830A1
Authority
EP
European Patent Office
Prior art keywords
key
message
swu
provider
dev
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24717109.3A
Other languages
English (en)
French (fr)
Inventor
Fabrizio De Santis
Andreas Furch
Malek Safieh
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP23176420.0A external-priority patent/EP4436098A1/de
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP4662830A1 publication Critical patent/EP4662830A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the invention relates to a method for checking the authenticity of a message with the aid of a provider of a device through this device as well as to a device.
  • Post-quantum cryptography is becoming increasingly relevant for numerous industrial products and solutions. However, many industrial devices still implement conventional cryptographic algorithms. Post-quantum algorithms, e.g.
  • the device In the method according to the invention for checking the authenticity of a message with the aid of a provider of a device by means of this device, the device generates a first markup and a cipher from the message using an asymmetric cryptographic method that can be reversed with a private key of the provider, with a public key of the provider and with the message, and the cipher is sent to the provider sent and a second certificate is received from the provider using the private key and the ciphertext by reversing the cryptographic process, whereby, preferably exclusively, if the first certificate and the second certificate match, the authenticity is concluded, i.e. the authenticity, and if there is no match, a warning signal is preferably generated.
  • checking the authenticity of a message can preferably also be understood to mean or be considered to include authentication of a sender of this message.
  • the verification of the authenticity of the message can preferably also be understood as a verification of the authenticity and integrity of the message. If an essentially authentic message has been changed, the verification of the authenticity of the message according to the invention would expediently fail, so that at the same time the integrity of the message is also verified using the method according to the invention.
  • the method according to the invention is advantageously suitable for pre- and post-quantum applications.
  • the proposed protocols in this invention benefit from operations to generate a shared secret between two parties, which is used to calculate an authentication tag, i.e. a markup. This markup is then used to provide cryptographic security with regard to the authentication and proof of integrity of the message on the device side.
  • Pre-quantum applications are applications that do not have to be resistant to attacks using quantum computers.
  • Post-quantum applications or post-quantum cryptography include applications and methods that are designed to be particularly resistant to attacks using quantum computers.
  • the asymmetric cryptographic method is designed such that it generates a cipher and a first session key from the message by means of a key encapsulation method with a public key of the provider, wherein the first markup dependent on the first session key and on the message is generated by means of the first session key together with the message.
  • the method according to the invention can also advantageously be carried out using industrial devices with limited resources.
  • the computational complexity of calculations that must be carried out using the device is kept particularly low in the method according to the invention.
  • KEM methods i.e. key encapsulation methods, and/or encryption and/or authenticated encryption with associated data calculations can advantageously be used for authentication and proof of integrity on industrial devices.
  • KEMs Key encapsulation mechanisms
  • Cryptology ePrint Archive Paper 2020/ 534, 2020. Therefore, KEM methods for the post-quantum area advantageously place significantly lower demands on industrial devices than signature-based methods.
  • the reversal of the cryptographic method is preferably carried out in such a way that a second session key is generated using the cipher and the private key of the provider and the second certificate is generated using the second session key and the message.
  • the cryptographic asymmetric method is a key encapsulation method and the inversion of the cryptographic method is a key decapsulation method corresponding to the key encapsulation method.
  • the message is expediently a user request, in particular a provisioning and/or configuration request.
  • checking the authenticity of a message with the help of a provider of the device by this device is particularly advantageous and offers improved security compared to the prior art.
  • the message is a software and/or a software update.
  • the method according to the invention also advantageously enables a check of authenticity.
  • the invention is therefore conveniently divided into various use cases, a first of which comprises secure configuration or secure loading of firmware or secure software update of the device.
  • a second use case comprises secure device onboarding and/or bootstrapping in a user domain.
  • the device carries out authentications before preferably by means of asymmetric encryption and particularly preferably by means of KEM methods, in particular by means of the methods known as Kyber and/or Classic McEliece and/or FrodoKEM.
  • the method according to the invention does not require any signature processes on the device side, so that the method according to the invention does not place any special requirements on the hardware of the device.
  • the method according to the invention can also be used for other additional applications.
  • the second award is obtained via a user, in particular via a user of the user request.
  • the device is preferably an industrial device of an industrial network, in particular an Internet of Things network, and/or a manufacturing device and/or a maintenance device and/or a logistics device.
  • the device is expediently an IT device and/or an IoT device.
  • the device according to the invention is designed and configured to carry out a method according to the invention as described above.
  • Fig. 1 shows a schematic diagram of an embodiment of the method according to the invention
  • Fig. 2 shows an exemplary embodiment of a data-centric network according to the invention of a production plant according to the invention.
  • the embodiment shown in Fig. 1 shows a protocol for a secure software update SWU.
  • a configuration or firmware can also take the place of the software update SWU.
  • SWU secure software update protocol
  • DEV industrial device
  • MAN manufacturer
  • KEM key encapsulation mechanism
  • each of the two parties has a trustworthy certificate for a public KEM key, which contains at least the public KEM key and was generated by a trustworthy party, in the present embodiment by a certification authority of the manufacturer's PKI domain, before the start of the inventive method.
  • Such certificates can be used, for example, to establish a mutual authentication process and to derive session keys in order to implement a secure channel.
  • a secure channel is used, for example, in the KEMTLS protocol. If these certificates themselves have not already been determined to be trustworthy, digital signature validations (not shown in the illustrated embodiment) are required to validate the certificate chains up to the trustworthy public key, i.e. the root certificate.
  • the manufacturer's public KEM key or a certificate of the manufacturer's public KEM key is securely and integrated during the manufacture of the DEV device. stored in a secure manner in the device DEV.
  • an associated root certificate or associated public key could also be stored in this device DEV during the manufacture of the device DEV.
  • the method according to the invention checks the authenticity and integrity of the software update SWU. To do this, the protocol explained step by step below is carried out:
  • the manufacturer MAN of the device DEV uses the public KEM key PKD of the device DEV for encapsulation.
  • the encapsulation of the public key PKD of the device DEV results in a first cipher CT1 and a first secret SS I.
  • a first session key Kl is derived from the first secret SS I using a key derivation function KDF.
  • the first secret SS I itself can also be used as a session key.
  • This first session key Kl derived using the key derivation function KDF, is used to encrypt the software update based on an AEAD algorithm (English: “Authenticated Encryption with Associated Data", AEAD) to form an encrypted software update AEADSWU and to protect it with regard to integrity.
  • AEAD Authenticated Encryption with Associated Data
  • the first session key Kl thus guarantees the integrity, authenticity and confidentiality of the software update SWU.
  • Both the encrypted software update SWU and the first cipher CT1 are sent to the industrial device DEV.
  • the previous method steps are optional in the method according to the invention and are only aimed at sending an encrypted, authenticated and integrity-protected software update SWU to a specific device DEV. If only integrity and authenticity protection is required, ous without confidentiality being guaranteed, in a further embodiment not specifically shown, in addition to the software update, a tag can be calculated and sent, which can be obtained from the software update using an AEAD algorithm or a message authentication code, i.e. a MAC or HMAC. If, in a further embodiment not specifically shown, the software update SWU is to be sent in plain text, i.e. without integrity, authenticity and confidentiality protection of the software update SWU, all of the previous steps are not necessary, i.e. the software update SWU can simply be sent to the industrial device DEV without any further measures.
  • the device DEV receives the software update SWU in encrypted form and the device DEV must decapsulate the first cipher CT1 with its private key SKD in order to obtain the first secret SS I. Only the device DEV can therefore reconstruct the same secret SS I because the private KEM key SKD of the device DEV is required.
  • the device DEV derives the first session key Kl from the first secret SS I using a key derivation function KDF.
  • the first secret SS I itself can in principle also be used as the session key, so that the key derivation function KDF is not required.
  • the first session key Kl is then used to decrypt the software update SWU with an AEAD algorithm.
  • a MAC or HMAC calculation can be used if confidentiality protection for the software update SWU is not required. However, if the software update SWU has not been encrypted, the device DEV can ignore all previous calculations.
  • the DEV device then performs plausibility and conformity checks on the software update SWU, for example to check the validity and suitability of the software update SWU.
  • the device DEV Before installing the software update SWU, the device DEV must authenticate the software update SWU as coming from the responsible manufacturer MAN. To do this, the device DEV uses the public KEM key PKM of its manufacturer MAN for encapsulation.
  • the public key PKM of the manufacturer MAN is stored in an integrity-protected manner during production of the device DEV.
  • the encapsulation of the public key PKM of the manufacturer MAN results in a second secret SS2 and a second cipher CT2.
  • the second cipher CT2 can be sent directly to the manufacturer MAN, while the second secret SS2 is passed to a key derivation function KDF to obtain a second session key K2.
  • This second session key K2 is used to obtain a first authentication tag TAG1 using an AEAD algorithm and the software update SWU.
  • the second secret can also be used directly as the second session key.
  • a MAC or HMAC calculation can be used to obtain this first authentication tag TAG1.
  • the second session key K2 and the second secret SS2 are no longer required and can be deleted from the device DEV.
  • the first authentication tag TAG1 must be stored securely, i.e. with integrity and confidentiality protected, for later authentication of the response from the manufacturer MAN.
  • the manufacturer MAN Since the second secret SS2 from the second cipher CT2 is encapsulated with the manufacturer’s public KEM key PKM , it is only possible for the manufacturer MAN to determine the second secret SS2 from the second cipher CT2 using the manufacturer MAN's private KEM key SKM, which is known only to the manufacturer MAN. Therefore, the manufacturer MAN is the only party that can decapsulate the second secret SS2 from the second cipher CT2. Accordingly, the manufacturer MAN receives the second cipher CT2 and decapsulates it using its private KEM key SKM, and then receives the second secret SS2. The manufacturer MAN then calculates the second session key K2 using a key derivation function KDF. As already mentioned above, in other examples the second secret SS I itself can in principle be used as the session key, so that the key derivation function KDF is not necessary.
  • the manufacturer MAN receives a second authentication tag TAG2 using its second session key K2 and the software update SWU and an AEAD algorithm and sends the second authentication tag TAG2 to the device DEV.
  • the calculations using the key derivation function KDF and the AEAD algorithm can alternatively be replaced by MAC or HMAC calculations in embodiments not shown.
  • the industrial device DEV receives the second authentication tag TAG2 and compares it with the previously calculated and securely stored first authentication tag TAG1 . If the first TAG1 and the second authentication tag TAG2 are the same, the device DEV authenticates that the software update SWU comes from the manufacturer MAN . This is because only the manufacturer MAN could have obtained the secret SS2 . It can also be concluded that the software update SWU has not been modified or changed, i.e. the software update SWU is intact, because the first TAG1 and the second authentication tag TAG2 are the same. However, if the first TAG1 and the second authentication tag TAG2 are not the same, the software update SWU is not accepted and an error message or alarm is triggered.
  • the manufacturer MAN or an end user or operator can be informed purely optionally when the software update SWU has been accepted by the device DEV and will be or has been installed.
  • This change can be made, for example, as follows: In the method step explained above, in which the manufacturer MAN decapsulates the second secret SS2 from the second cipher CT2, the manufacturer MAN additionally generates a nonce N and encrypts this nonce N with the previously generated first session key Kl and sends the result to the device DEV. The device DEV decrypts the nonce N and returns this nonce N to the manufacturer MAN when the software update SWU has been accepted and is installed.
  • This first session key Kl would not be available to the manufacturer MAN in this method step if the software update SWU was initially sent to the device DEV in plain text or only with integrity protection.
  • the manufacturer MAN must additionally encapsulate the device's public key KEM PKD and use a key derivation function KDF to obtain a session key such as the first session key Kl and encrypt the nonce N.
  • KEM PKD public key
  • KDF key derivation function
  • the previously described embodiments can optionally be extended to extend an operating environment by a second layer of protection by encapsulating the software update SWU a second time with credentials belonging to the end user or operator of the device DEV.
  • additional parameters from the operator, such as an installation time or a sequence of module updates if several module updates are included in the software update SWU, or information about further boundary conditions of the operation. operating environment. These additional parameters can also be used to authorize the installation of the SWU software update.
  • onboarding for a secure device is carried out in a trustworthy manner.
  • three parties cooperate, in the embodiment shown, the industrial device DEV itself, an end user USE, i.e. an operator of the device DEV, and the manufacturer MAN of the device DEV. All three parties must be equipped with at least one KEM key pair.
  • all three entities should each have a trustworthy KEM certificate for their own public KEM key, which each contains at least this public KEM key and was generated by a trustworthy entity before the embodiment of the method according to the invention shown in Figure 2 is started.
  • a trustworthy entity is formed, for example, by a trustworthy certification authority.
  • the public KEM key or the KEM certificate of the manufacturer MAN is securely stored in the industrial device during production so that its integrity is protected.
  • the user USE who wants to integrate the industrial device DEV into an industrial network, for example a manufacturing network, starts by generating and sending a user request URE including the root certification authority of the user domain and the public KEM key PKE of the user USE and possibly a certificate chain of the associated KEM certificate.
  • the device DEV receives the user request URE and checks it.
  • the device DEV verifies the KEM certificate and stores the root certification authority and the public KEM key PKE of the user USE as well as the certificate chain.
  • the device DEV does not yet know the user USE and will directly request its manufacturer MAN as a third party to prove and confirm trustworthiness towards the user USE.
  • the device DEV encapsulates the public KEM key PKM of its manufacturer MAN, which the device DEV already stored in an integrity-protected manner during its manufacture.
  • the first secret SSI is then passed on as input to a key derivation function KDF to calculate a first session key Kl.
  • the device DEV uses the first session key Kl and an AEAD algorithm, for example AES-GCM, to calculate a first authentication tag TAG1 from the U- ser request, the root certificate, the user's public KEM key PKE USE and the device's public KEM key PKD.
  • a MAC or HMAC calculation can be used to obtain this first authentication tag TAG1. This would replace the key derivation function and the AEAD algorithm.
  • the first authentication tag TAG1 obtained in this way must be kept secure, i.e. confidential and integrity-protected.
  • the first authentication tag TAG1 is required to verify the subsequent confirmation from the manufacturer MAN. If both integrity and confidentiality are not guaranteed, an attacker can extract or modify the first authentication tag TAG1 from the device DEV and send it back as a fake authentication.
  • the user USE receives both the first cipher CT1 and the public KEM key PKD of the device DEV and adds the first cipher CT1 and the public KEM key PKD in its user request URE and also inserts a public KEM key PKE of the user USE including the associated certificate chain. The user USE then forwards the completed user request URE to the manufacturer MAN.
  • the manufacturer MAN receives the user request URE with the above-mentioned information from the user USE and checks it, for example by checking the certificate chain of the public KEM key using a root certificate. If the check is positive, the manufacturer MAN concludes that the user USE is trustworthy. The manufacturer MAN then generates a confirmation of the user request URE from the user USE to the device DEV. To do this, the manufacturer MAN first decapsulates the ciphertext CT1 with its own private KEM key SKM, which corresponds to the public KEM key PKM stored in the device DEV during production of the device DEV. If successful, the manufacturer generates the secret SSI in this way.
  • the manufacturer MAN uses a key derivation function KDF to derives the session key Kl from the secret SSI. Finally, the manufacturer MAN uses the session key Kl with an AEAD algorithm to calculate a second authentication tag TAG2 from the user request URE of the user USE, the root certificate of the user USE, the public KEM key PKE of the user USE and the public KEM key PKD of the device DEV. Alternatively, a MAC or HMAC calculation can be used to obtain this second authentication tag TAG2, which would replace the key derivation function KDF and the AEAD algorithm. This authentication tag TAG2 is sent to the user USE.
  • the user USE forwards the second authentication tag TAG2 to the device DEV.
  • the device DEV receives the second authentication tag TAG2 from the user USE and compares it with the previously calculated and securely, i.e. confidentially and with integrity-protected, stored first authentication tag TAG1. If the first TAG1 and second authentication tag TAG2 are the same, the DEV device authenticates that the user request URE has been checked and accepted by the manufacturer MAN of the DEV device, who is considered trustworthy per se, since only the manufacturer MAN can receive the SSI secret. In addition, the authentication ensures that the user request URE has not been modified or changed, i.e. is integral, since the first TAG1 and second authentication tag TAG2 are the same. However, if the first TAG1 and second authentication tag TAG2 are not the same, the entire protocol is repeated.
  • the DEV device rejects onboarding because the user USE cannot be confirmed as trustworthy to the DEV device.
  • a warning message is also issued, for example in the form of a warning tone.
  • the manufacturer MAN can be informed when the correct device DEV has been successfully integrated into the user domain.
  • the protocol described above must be modified accordingly:
  • the manufacturer MAN encapsulates the public KEM key of the device PKD when generating the confirmation of the user request URE.
  • the secret SS2 is stored securely by the manufacturer MAN, i.e. confidentially and with integrity protected, while the ciphertext CT2 is sent to the user USE together with the authentication tag TAG2. Otherwise, an attacker can read this secret SS2 and send it back to the manufacturer MAN as a fake confirmation in order to falsely confirm that the device DEV has undergone correct onboarding.
  • the user USE not only sends the second authentication tag TAG2 to the device DEV, but the user USE also forwards the second ciphertext CT2 to the device DEV.
  • the device DEV also decapsulates the second cipher CT2 with its own private KEM key SKD . From this, the device DEV calculates a third secret SS2 ' and forwards this third secret SS2 ' to the manufacturer MAN .
  • the manufacturer MAN compares the third secret SS2 ' with the previously calculated second secret SS2 . If the second SS2 and third secret SS2 ' are the same, the manufacturer MAN guarantees that the correct device DEV has gone through the onboarding .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Bei dem Verfahren zur Prüfung einer Authentizität einer Nachricht (SWU, URE) mithilfe eines Bereitstellers eines Geräts (DEV) durch dieses Gerät (DEV) wird durch das Gerät aus der Nachricht (SWU, URE) mittels eines mit einem privaten Schlüssel (SKM) des Bereitstellers umkehrbaren asymmetrischen kryptographischen Verfahrens mit einem öffentlichen Schlüssel des Bereitstellers (PKM) und mit der Nachricht (SWU) eine erste Auszeichnung (TAG1) und ein Chiffrat (CT2) generiert, wobei das Chiffrat (CT2) nachfolgend an den Bereitsteller gesendet wird und wobei vom Bereitsteller mittels des privaten Schlüssels (SKM) und des Chiffrats (CT2) mittels der Umkehrung des kryptographischen Verfahrens eine zweite Auszeichnung (TAG2) erhalten wird, wobei, vorzugsweise ausschließlich, bei einer Übereinstimmung der ersten Auszeichnung (TAG1) und der zweiten Auszeichnung (TAG2) miteinander auf die Authentizität geschlossen wird.

Description

Beschreibung
Verfahren zur Prüfung einer Authenti zität einer Nachricht und Gerät
Die Erfindung betri f ft ein Verfahren zur Prüfung einer Authenti zität einer Nachricht mithil fe eines Bereitstellers eines Geräts durch dieses Gerät sowie ein Gerät .
Für zahlreiche industrielle Produkte und Lösungen wird Post- Quanten-Kryptographie zunehmend relevant . In vielen industriellen Geräten sind j edoch bislang herkömmliche kryptographische Algorithmen implementiert . Post-Quantum-Algorithmen, z .
B . digitale Signaturen, sind rechenintensiv, insbesondere für ressourcenbeschränkte industrielle Geräte .
Es ist daher Aufgabe der Erfindung, ein verbessertes Verfahren zur Prüfung einer Authenti zität einer Nachricht anzugeben, welches sich ef fi zient und sicher, vorzugsweise postquantum-sicher, einsetzen lässt . Ferner ist es Aufgabe der Erfindung, ein verbessertes Gerät anzugeben, mit welchem sich das verbesserte Verfahren einsetzen lässt .
Diese Aufgabe der Erfindung wird mit einem Verfahren zur Prüfung einer Authenti zität einer Nachricht mit den in Anspruch 1 angegebenen Merkmalen und mit einem Gerät mit den in Anspruch 10 angegebenen Merkmalen gelöst . Bevorzugte Weiterbildungen der Erfindung sind in den zugehörigen Unteransprüchen, der nachfolgenden Beschreibung und der Zeichnung angegeben .
Bei dem erfindungsgemäßen Verfahren zur Prüfung einer Authenti zität einer Nachricht mithil fe eines Bereitstellers eines Geräts durch dieses Gerät werden durch das Gerät aus der Nachricht mittels eines mit einem privaten Schlüssel des Bereitstellers umkehrbaren asymmetrischen kryptographischen Verfahrens mit einem öf fentlichen Schlüssel des Bereitstellers und mit der Nachricht eine erste Aus zeichnung und ein Chi f frat generiert und das Chi f frat wird an den Bereitsteiler gesendet und vom Bereitsteiler wird mittels des privaten Schlüssels und des Chi f frats mittels der Umkehrung des kryptographischen Verfahrens eine zweite Aus zeichnung erhalten, wobei , vorzugsweise ausschließlich, bei einer Übereinstimmung der ersten Aus zeichnung und der zweiten Aus zeichnung miteinander die , d . h . auf die , Authenti zität geschlossen wird und bei einer fehlenden Übereinstimmung vorzugsweise ein Warnsignal generiert wird .
Es versteht sich, dass eine Aus zeichnung im Sinne der vorliegenden Erfindung auch als sogenannter Tag bezeichnet werden kann .
Unter einer Prüfung einer Authenti zität einer Nachricht kann im Rahmen dieser Erfindung bevorzugt auch eine Authentisie- rung eines Senders dieser Nachricht verstanden werden oder als umfasst angesehen werden .
Im Rahmen der vorliegenden Erfindung kann vorzugsweise die Prüfung einer Authenti zität der Nachricht auch als Prüfung einer Authenti zität und Integrität der Nachricht verstanden werden . Wenn eine an sich authentische Nachricht verändert worden ist , so würde die erfindungsgemäße Prüfung der Authenti zität der Nachricht zweckmäßig fehlschlagen, sodass zugleich auch die Integrität der Nachricht mittels des erfindungsgemäßen Verfahrens geprüft wird .
Das erfindungsgemäße Verfahren eignet sich vorteilhaft für Prä- und Post-Quantum-Anwendungen . Im Gegensatz zu anderen Verfahren profitieren die vorgeschlagenen Protokolle in dieser Erfindung von Operationen, um ein gemeinsames Geheimnis zwischen zwei Parteien zu erzeugen, das zur Berechnung eines Authenti fi zierungstags , also einer Aus zeichnung, verwendet wird . Diese Aus zeichnung wird nun herangezogen, um eine kryptografische Sicherheit hinsichtlich der Authentisierung und des Integritätsnachweises der Nachricht auf der Seite des Geräts bereitzustellen . Unter Prä-Quantum-Anwendungen sind Anwendungen zu verstehen, welche nicht resistent gegenüber Angri f fen mittels Quanten- Computern ausgebildet sein müssen . Post-Quantum-Anwendungen oder Post-Quantum-Kryptographie hingegen umfasst solche Anwendungen und Verfahren, welche als besonders resistent gegenüber Angri f fen mit Quanten-Computern ausgebildet sind .
Bevorzugt ist bei dem erfindungsgemäßen Verfahren das asymmetrische kryptographische Verfahren derart ausgebildet , dass es aus der Nachricht mittels eines Schlüsselkapselungsverfahrens mit einem öf fentlichen Schlüssel des Bereitstellers ein Chi f frat und einen ersten Sitzungsschlüssel generiert , wobei mittels des ersten Sitzungsschlüssels gemeinsam mit der Nachricht , die vom ersten Sitzungsschlüssel und von der Nachricht abhängige erste Aus zeichnung generiert wird .
Vorteilhaft kann das erfindungsgemäße Verfahren auch mit ressourcenbeschränkten industriellen Geräten ausgeführt werden . Die Rechenkomplexität von Rechnungen, welche mittels des Geräts durchgeführt werden müssen, ist bei dem erfindungsgemäßen Verfahren besonders gering gehalten .
Vorteilhaft können in dieser Weiterbildung der Erfindung KEM- Verfahren, also Schlüsselkapselungsverfahren, und/oder eine Verschlüsselung und/oder eine authenti fi zierte Verschlüsselung mit zugehörigen Datenberechnungen für die Authenti fi zierung und den Integritätsnachweis auf industriellen Geräten herangezogen werden .
Schlüsselkapselungsverfahren, auch als ( engl . ) „Key Encapsulation Mechanisms" (KEMs oder KEM-Verf ahren oder Schlüsselkapselungsverfahren) bezeichnet , lassen sich im Vergleich zu anderen Post-Quantum-Algorithmen häufig ef fi zienter einsetzten als digitale Signaturen, vgl . P . Schwabe , D . Stebila und T . Wiggers : Post-Quantum TLS ohne Handshake-Signaturen . In : Cryptology ePrint Archive , Paper 2020/ 534 , 2020 . Daher stellen KEM-Verf ahren für den Post-Quantum-Bereich vorteilhaft deutlich geringere Anforderungen an industrielle Geräte als signaturbasierte Verfahren .
Bei dem erfindungsgemäßen Verfahren erfolgt die Umkehrung des kryptographischen Verfahrens vorzugsweise derart , dass mittels des Chi f frats und des privaten Schlüssels des Bereit- stellers ein zweiter Sitzungsschlüssel generiert wird und mittels des zweiten Sitzungsschlüssels und der Nachricht die zweite Aus zeichnung generiert wird .
Geeigneterweise ist bei dem erfindungsgemäßen Verfahren das kryptographische asymmetrische Verfahren ein Schlüsselkapselungsverfahren und die Umkehrung des kryptographischen Verfahrens ein mit den Schlüsselkapselungsverfahren korrespondierendes Schlüsselentkapselungsverfahren .
Zweckmäßig ist bei dem erfindungsgemäßen Verfahren die Nachricht eine Nutzeranfrage , insbesondere eine Provisionierungs- und/oder Konfigurationsanfrage . Insbesondere für diese Anwendungs fälle ist eine Prüfung einer Authenti zität einer Nachricht mithil fe eines Bereitstellers des Geräts durch dieses Gerät besonders vorteilhaft und bietet eine verbesserte Sicherheit gegenüber dem Stand der Technik .
In einer vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens ist die Nachricht eine Software und/oder ein Softwareupdate . Auch für diesen Anwendungs fall ermöglicht das erfindungsgemäße Verfahren vorteilhaft eine Prüfung einer Authenti zität .
Die Erfindung gliedert sich somit zweckmäßig in verschiedene Anwendungs fälle , von denen ein erster eine sichere Konfiguration oder ein sicheres Einspielen einer Firmware oder eine sichere Softwareaktualisierung des Geräts umfasst . Ein zweiter Anwendungs fall umfasst ein sicheres Geräte-Onboarding und/oder ein Bootstrapping in einer Nutzerdomäne . In beiden Anwendungs fällen führt das Gerät Authenti fi zierungen bevor- zugt mittels asymmetrischer Verschlüsselung und besonders bevorzugt mittels KEM-Verf ahren durch, insbesondere mittels der als Kyber und/oder Classic McEliece und/oder FrodoKEM bekannten Verfahren . Besonders vorteilhaft sind bei dem erfindungsgemäßen Verfahren keine Signaturvorgänge auf Geräteseite erforderlich, sodass das erfindungsgemäße Verfahren keine besonderen Voraussetzungen an die Hardware des Geräts stellt . In weiteren vorteilhaften Ausgestaltungen lässt sich das erfindungsgemäße Verfahren auch für sonstige weitere Anwendungs fälle einsetzen .
Alternativ oder zusätzlich und ebenfalls bevorzugt wird bei dem erfindungsgemäßen Verfahren die zweite Aus zeichnung über einen Nutzer erhalten, insbesondere über einen Nutzer der Nutzeranfrage .
Bei dem erfindungsgemäßen Verfahren ist das Gerät vorzugsweise ein industrielles Gerät eines industriellen Netzwerks , insbesondere eines Internet-der-Dinge-Net zwerks , und/oder ein Fertigungsgerät und/oder ein Wartungsgerät und/oder ein Logistikgerät . Zweckmäßig ist das Gerät ein IT-Gerät und/oder ein loT-Gerät .
Das erfindungsgemäße Gerät ist ausgebildet und eingerichtet zur Aus führung eines erfindungsgemäßen Verfahrens wie vorhergehend beschrieben .
Nachfolgend wird die Erfindung anhand eines in der Zeichnung dargestellten Aus führungsbeispiels näher erläutert . Es zeigen :
Fig . 1 einen Ablauf eines Aus führungsbeispiels des erfindungsgemäßen Verfahrens schematisch in einer Prinzipski z ze sowie
Fig . 2 ein Aus führungsbeispiel für ein erfindungsgemäßes datenzentrisches Netzwerk einer erfindungsgemäßen Fertigungsanlage . Das in Fig. 1 dargestellte Ausführungsbeispiel zeigt ein Protokoll für ein sicheres Software-Update SWU. In weiteren, nicht eigens dargestellten Ausführungsbeispielen, welche im Übrigen dem dargestellten Ausführungsbeispiel entsprechen, kann an die Stelle des Software-Updates SWU auch eine Konfiguration oder eine Firmware treten.
Bei dem Protokoll für das sichere Software-Update SWU kooperieren zwei Parteien, um das sicheres Software-Update SWU durchzuführen: einerseits ein industrielles Gerät DEV und ein Hersteller MAN des Geräts DEV. Beide Parteien müssen mit mindestens einem Schlüsselpaar für ein Schlüsselkapselungsverfahren (engl. „Key Encapsulation Mechanism", KEM) , d. h. einem KEM-Schlüsselpaar mit einem öffentlichen KEM-Schlüssel und dem dazugehörigen privaten KEM-Schlüssel, ausgestattet sein .
Im dargestellten Ausführungsbeispiel besitzt jede der beiden Parteien ein vertrauenswürdiges Zertifikat für einen öffentlichen KEM-Schlüssel, welches mindestens den öffentlichen KEM-Schlüssel enthält und vor dem Start des erfindungsgemäßen Verfahrens von einer vertrauenswürdigen Partei, im vorliegenden Ausführungsbeispiel von einer Zertifizierungsstelle der PKI-Domäne des Herstellers, generiert worden ist. Solche Zertifikate können beispielsweise verwendet werden, um ein gegenseitiges Authentifizierungsverfahren zu etablieren und Sitzungsschlüssel abzuleiten, um einen sicheren Kanal zu realisieren. Ein solcher sicherer Kanal wird beispielsweise im KEMTLS-Protokoll genutzt. Wenn diese Zertifikate selbst nicht bereits als vertrauenswürdig festgestellt worden sind, sind digitale Signaturvalidierungen (im dargestellten Ausführungsbeispiel nicht gezeigt) zur Validierung der Zertifikatsketten bis hin zum vertrauenswürdigen öffentlichen Schlüssel, d. h. dem Stammzertifikat, erforderlich.
Darüber hinaus wird der öffentliche KEM-Schlüssel oder ein Zertifikat des öffentlichen KEM-Schlüssels des Herstellers während der Herstellung des Geräts DEV sicher und integri- tätsgeschüt zt im Gerät DEV gespeichert . Alternativ oder zusätzlich und allgemeiner könnte auch ein zugehöriges Wurzelzerti fikat oder zugehöriger öf fentlicher Schlüssel während der Herstellung des Geräts DEV in diesem Gerät DEV gespeichert werden .
Bei dem erfindungsgemäßen Verfahren wird die Authenti zität und auch die Integrität des Software-Updates SWU geprüft . Dazu wird das im Folgenden schrittweise erläuterte Protokoll durchgeführt :
In einem ersten Verfahrensschritt nutzt der Hersteller MAN des Geräts DEV den öf fentlichen KEM-Schlüssel PKD des Geräts DEV zur Kapselung . Die Kapselung des öf fentlichen Schlüssels PKD des Geräts DEV resultiert in einem ersten Chi f frat CT1 und einem ersten Geheimnis SS I .
Aus dem ersten Geheimnis SS I wird ein erster Sitzungsschlüssel Kl unter Verwendung einer Schlüsselableitungs funktion KDF abgeleitet . Grundsätzlich kann in weiteren Aus führungsbeispielen auch das erste Geheimnis SS I selbst als Sitzungsschlüssel verwendet werden . Dieser erste Sitzungsschlüssel mittels der Schlüsselableitungs funktion KDF abgeleitete Sitzungsschlüssel Kl wird verwendet , um das Software-Update basierend auf einem AEAD-Algorithmus ( engl . : „Authenticated Encryption with Associated Data" , AEAD) zu einem verschlüsselten Softwareupdate AEADSWU zu verschlüsseln und hinsichtlich der Integrität zu schützen . Somit garantiert der erste Sitzungsschlüssel Kl die Integrität und die Authenti zität und die Vertraulichkeit des Software-Updates SWU . Sowohl das verschlüsselte Software-Update SWU als auch das erste Chi f frat CT1 werden an das industrielle Gerät DEV gesendet .
Die bisherigen Verfahrensschritte sind bei dem erfindungsgemäßen Verfahren optional und zielen lediglich darauf ab, ein verschlüsseltes , authentisiertes und integritätsgeschütztes Software-Update SWU an ein bestimmtes Gerät DEV zu senden . Wenn lediglich Integritäts- und Authenti zitätsschutz erfor- derlich sind, ohne dass eine Vertraulichkeit zu gewährleisten ist , kann in einem weiteren, nicht eigens dargestellten, Ausführungsbeispiel zusätzlich zum Software-Update ein Tag berechnet und gesendet werden, welches aus dem Software-Update mittels eines AEAD-Algorithmus oder einem Message Authentication Code , d . h . einem MAC oder HMAC, bezogen werden kann . Wenn das Software-Update SWU in einem weiteren, nicht eigens dargestellten, Aus führungsbeispiel im Klartext , d . h . ohne Integrität , Authenti zität und Vertraulichkeitsschutz des Software-Updates SWU gesendet werden soll , sind sämtliche bisherigen Schritte nicht erforderlich, d . h . das Software- Update SWU kann einfach ohne weitere Maßnahmen an das industrielle Gerät DEV gesendet werden .
In einem nachfolgenden Verfahrensschritt erhält das Gerät DEV das Software-Update SWU in verschlüsselter Form und das Gerät DEV muss das erste Chi f frat CT1 mit seinem privaten Schlüssel SKD entkapseln, um das erste Geheimnis SS I zu erhalten . Nur das Gerät DEV kann also das gleiche Geheimnis SS I rekonstruieren, da der private KEM-Schlüssel SKD des Geräts DEV benötigt wird . In einem weiteren Verfahrensschritt leitet das Gerät DEV den ersten Sitzungsschlüssel Kl vom ersten Geheimnis SS I mithil fe einer Schlüsselableitungs funktion KDF ab . Wie oben bereits erwähnt kann in weiteren Aus führungsbeispielen grundsätzlich auch das erste Geheimnis SS I selbst als Sitzungsschlüssel verwendet werden, sodass die Schlüsselableitungs funktion KDF entbehrlich ist . Der erste Sitzungsschlüssel Kl wird dann verwendet , um das Software-Update SWU mit einem AEAD-Algorithmus zu entschlüsseln . Alternativ kann eine MAC- oder HMAC-Berechnung verwendet werden, wenn der Vertraulichkeitsschutz für das Software-Update SWU nicht benötigt wird . Wenn das Software-Update SWU j edoch nicht verschlüsselt worden ist , kann das Gerät DEV alle bisherigen Berechnungen ignorieren .
Anschließend führt das Gerät DEV Plausibilitäts- und Konfor- mitätsprüfungen am Software-Update SWU durch, um beispiels- weise die Gültigkeit und Eignung des Software-Updates SWU zu prüfen .
Vor der Installation des Software-Updates SWU muss das Gerät DEV das Software-Update SWU als vom zuständigen Hersteller MAN stammend authenti fi zieren . Dazu nutzt das Gerät DEV den öf fentlichen KEM-Schlüssel PKM seines Herstellers MAN zur Kapselung . Der öf fentliche Schlüssel PKM des Herstellers MAN ist während der Produktion des Geräts DEV integritätsgeschützt gespeichert . Die Kapselung des öf fentlichen Schlüssels PKM des Herstellers MAN resultiert in einem zweiten Geheimnis SS2 und einem zweiten Chi f frat CT2 . Das zweite Chi f frat CT2 kann direkt an den Hersteller MAN gesendet werden, während das zweite Geheimnis SS2 einer Schlüsselableitungs funktion KDF übergeben wird, um einen zweiten Sitzungsschlüssel K2 zu erhalten . Dieser zweite Sitzungsschlüssel K2 wird verwendet , um mittels eines AEAD-Algorithmus und des Software-Updates SWU ein erstes Authenti fi zierungs-Tag TAG1 zu erhalten . Auch hier kann in weiteren Aus führungsbeispielen das zweite Geheimnis auch direkt als zweiter Sitzungsschlüssel verwendet werden . Alternativ kann eine MAC- oder HMAC- Berechnung verwendet werden, um dieses erste Authentisie- rungs-Tag TAG1 zu erhalten . Nachfolgend werden der zweite Sitzungsschlüssel K2 und das zweite Geheimnis SS2 nicht mehr benötigt und können vom Gerät DEV gelöscht werden . Das erste Authenti fi zierungs-Tag TAG1 muss j edoch für eine spätere Authenti fi zierung der Antwort des Herstellers MAN sicher, das heißt integritäts- und vertraulichkeitsgeschützt , aufbewahrt werden . Denn wenn Integrität und Vertraulichkeit des ersten Authentisierungs-Tags TAG1 nicht gewährleistet wären, könnte ein Angrei fer das erste Authenti fi zierungs-Tag TAG1 vom Gerät DEV extrahieren und als gefälschtes erstes Authenti f i zie- rungs-Tag TAG1 zurücksenden und so fälschlich vorspiegeln, dass das Software-Update SWU vom zuständigen Hersteller MAN stammt und nicht verändert worden ist .
Da das zweite Geheimnis SS2 aus dem zweiten Chi f frat CT2 mit dem öf fentlichen KEM-Schlüssel PKM des Herstellers gekapselt worden ist , ist es nur dem Hersteller MAN möglich, das zweite Geheimnis SS2 aus dem zweiten Chi f frat CT2 mit dem nur dem Hersteller MAN bekannten privaten KEM-Schlüssel SKM des Herstellers MAN zu bestimmen . Daher ist der Hersteller MAN die einzige Partei , die das zweite Geheimnis SS2 vom zweiten Chi f frat CT2 entkapseln kann . Dementsprechend erhält der Hersteller MAN das zweite Chi f frat CT2 und entkapselt dieses mit seinem privaten KEM-Schlüssel SKM und erhält darauf das zweite Geheimnis SS2 . Anschließend berechnet der Hersteller MAN den zweiten Sitzungsschlüssel K2 mit Hil fe einer Schlüsselableitungs funktion KDF . Wie oben bereits erwähnt kann in weiteren Beispielen grundsätzlich auch das zweite Geheimnis SS I selbst als Sitzungsschlüssel verwendet werden, sodass die Schlüsselableitungs funktion KDF entbehrlich ist .
Schließlich erhält der Hersteller MAN ein zweites Authenti fizierungs-Tag TAG2 unter Verwendung seines zweiten Sitzungsschlüssels K2 und des Software-Updates SWU und eines AEAD- Algorithmus und sendet das zweite Authenti fi zierungs-Tag TAG2 an das Gerät DEV . Die Berechnungen mittels der Schlüsselableitungs funktion KDF und des AEAD-Algorithmus können in nicht dargestellten Aus führungsbeispielen alternativ durch MAC- oder HMAC-Berechnungen ersetzt werden .
Das industrielle Gerät DEV empfängt das zweite Authenti f i zie- rungs-Tag TAG2 und vergleicht dieses mit dem zuvor berechneten und sicher gespeicherten ersten Authenti fi zierungs-Tag TAG1 . Wenn erstes TAG1 und zweites Authenti fi zierungs-Tag TAG2 gleich sind, authenti fi ziert das Gerät DEV, dass das Software-Update SWU vom Hersteller MAN stammt . Denn nur der Hersteller MAN konnte das Geheimnis SS2 erhalten . Zudem kann geschlossen werden, dass das Software-Update SWU nicht modifi ziert oder geändert wurde , das Software-Update SWU also integer ist , da das erste TAG1 und das zweite Authenti f i zie- rungs-Tag TAG2 gleich sind . Wenn j edoch das erste TAG1 und das zweite Authenti fi zierungs-Tag TAG2 nicht gleich sind, wird das Software-Update SWU nicht akzeptiert und eine Fehlermeldung oder ein Alarm ausgelöst . Rein optional kann bei den vorhergehend beschriebenen Aus führungsbeispielen der Hersteller MAN oder ein Endbenutzer oder Bediener informiert werden, wenn das Software-Update SWU vom Gerät DEV akzeptiert worden ist und installiert werden wird oder wurde . Dies erfordert eine Änderung des in Figur 1 dargestellten Protokolls . Diese Änderung kann beispielsweise wie folgt erfolgen : Im vorhergehend erläuterten Verfahrensschritt , in welchem der Hersteller MAN das zweite Geheimnis SS2 aus dem zweiten Chi f frat CT2 entkapselt , erzeugt der Hersteller MAN zusätzlich eine Nonce N und verschlüsselt diese Nonce N mit dem zuvor generierten ersten Sitzungsschlüssel Kl und sendet das Ergebnis an das Gerät DEV . Das Gerät DEV entschlüsselt die Nonce N und gibt diese Nonce N an den Hersteller MAN zurück, wenn das Software-Update SWU akzeptiert worden ist und installiert wird . Dieser erste Sitzungsschlüssel Kl wäre vom Hersteller MAN in diesem angesprochenen Verfahrensschritt nicht verfügbar, wenn das Software-Update SWU zu Beginn im Klartext oder lediglich integritätsgeschützt an das Gerät DEV gesendet wurde . In diesem Fall muss der Hersteller MAN zusätzlich den öf fentlichen KEM-Schlüssel PKD des Geräts kapseln und eine Schlüsselableitungs funktion KDF verwenden, um einen Sitzungsschlüssel wie den ersten Sitzungsschlüssel Kl zu erhalten und die Nonce N zu verschlüsseln . Somit erkennt der Hersteller MAN, dass das Gerät DEV das SWU erfolgreich akzeptiert hat . Ein Endbenutzer oder Bediener wird dann vom Hersteller MAN über diesen Erfolg informiert .
Die vorhergehend beschriebenen Aus führungsbeispiele können optional dahingehend erweitert werden, dass eine Betriebsumgebung durch eine zweite Schutzschicht erweitert wird, indem das Software-Update SWU ein zweites Mal mit Anmeldeinformationen gekapselt wird, die dem Endbenutzer oder Bediener des Geräts DEV gehören . Auf diese Weise ist es möglich, zusätzliche Parameter vom Betreiber bereitzustellen, etwa eine Installations zeit oder eine Reihenfolge von Modulupdates , falls mehrere Modulupdates in dem Software-Update SWU enthalten sind, oder Informationen über weitere Randbedingungen der Be- triebsumgebung . Diese zusätzlichen Parameter können auch zur Autorisierung zur Installation des Software-Updates SWU verwendet werden .
Bei dem in Figur 2 dargestellten Aus führungsbeispiel wird ein Onboarding für ein sicheres Gerät vertrauenswürdig durchgeführt . Hier kooperieren drei Parteien, im dargestellten Ausführungsbeispiel das industrielle Gerät DEV selbst , ein Endnutzer USE , d . h . ein Betreiber des Geräts DEV, sowie der Hersteller MAN des Geräts DEV . Alle drei Parteien müssen mit mindestens einem KEM-Schlüsselpaar ausgestattet sein . Vorzugsweise sollten alle drei Entitäten j eweils ein vertrauenswürdiges KEM-Zerti f ikat für ihren eigenen öf fentlichen KEM- Schlüssel besitzen, das j eweils mindestens diesen öf fentlichen KEM-Schlüssel enthält und von einer vertrauenswürdigen Entität generiert wurde , bevor das in Fig . 2 dargestellte Aus führungsbeispiel des erfindungsgemäßen Verfahrens gestartet wird . Eine solche vertrauenswürdige Entität wird beispielsweise durch eine vertrauenswürdige Zerti fi zierungsstelle gebildet .
Darüber hinaus wird der öf fentliche KEM-Schlüssel oder das KEM-Zerti f ikat des Herstellers MAN während der Herstellung sicher im Industriegerät gespeichert , so dass dessen Integrität geschützt ist .
Das Onboarding erfolgt mit den nachfolgend erläuterten Verfahr ensschritten :
Zunächst beginnt der Nutzer USE , der das industrielle Gerät DEV in ein industrielles Netzwerk, beispielsweise ein Fertigungsnetzwerk, einbinden möchte , mit der Generierung und dem Senden einer Benutzeranforderung URE einschließlich der Stammzerti fi zierungsstelle der Nutzerdomäne und des öf fentlichen KEM-Schlüssels PKE des Nutzers USE und möglicherweise einer Zerti fikatskette des zugehörigen KEM-Zerti f ikats . Das Gerät DEV empfängt die Benutzeranforderung URE und prüft sie. Das Gerät DEV verifiziert das KEM-Zertif ikat und speichert die Stammzertifizierungsstelle und den öffentlichen KEM-Schlüssel PKE des Nutzers USE sowie die Zertifikatskette. Zu diesem Zeitpunkt kennt das Gerät DEV den Nutzer USE noch nicht und wird seinen Hersteller MAN als dritte Partei direkt auffordern, die Vertrauenswürdigkeit gegenüber dem Nutzer USE zu beweisen und zu bestätigen. Zu diesem Zweck kapselt das Gerät DEV den öffentlichen KEM-Schlüssel PKM seines Herstellers MAN, welchen das Gerät DEV bereits während seiner Herstellung integritätsgeschützt gespeichert hat. Dies führt zu einem ersten Chiffrat CT1 und einem ersten Geheimnis SSI, wobei das Chiffrat CT1 zusammen mit dem öffentlichen KEM- Schlüssel PKD des Geräts DEV direkt an den Nutzer USE zurückgesendet werden kann. Das erste Geheimnis SSI wird dann als Eingabe an eine Schlüsselableitungsfunktion KDF weitergeleitet, um einen ersten Sitzungsschlüssel Kl zu berechnen. Schließlich verwendet das Gerät DEV den ersten Sitzungsschlüssel Kl und einen AEAD-Algorithmus , beispielsweise AES- GCM, um einen ersten Authentifizierungs-Tag TAG1 aus dem U- ser-Request, dem Stammzertifikat, dem öffentlichen KEM- Schlüssel PKE des Nutzers USE sowie dem öffentlichen KEM- Schlüssel des Geräts PKD zu berechnen. Alternativ kann eine MAC- oder HMAC-Berechnung herangezogen werden, um dieses erste Authentifizierungs-Tag TAG1 zu erhalten. Dies würde die Schlüsselableitungsfunktion und den AEAD-Algorithmus ersetzen. Der so erhaltene erste Authentifizierungs-Tag TAG1 muss sicher, d. h. vertraulich und integritätsgeschützt, aufbewahrt werden. Der erste Authentifizierungs-Tag TAG1 ist erforderlich, um die spätere Bestätigung des Herstellers MAN zu überprüfen. Wenn sowohl die Integrität als auch die Vertraulichkeit nicht gewährleistet sind, kann ein Angreifer den ersten Authentifizierungs-Tag TAG1 vom Gerät DEV extrahieren oder ändern und als gefälschte Authentifizierung zurücksenden .
Der Nutzer USE erhält sowohl das erste Chiffrat CT1 als auch den öffentlichen KEM-Schlüssel PKD des Gerätes DEV und fügt das erste Chiffrat CT1 und den öffentlichen KEM-Schlüssel PKD in seinen User-Request URE ein und fügt darüber hinaus auch einen öffentlichen KEM-Schlüssel PKE des Nutzers USE einschließlich der zugehörigen Zertifikatskette ein. Der Nutzer USE leitet nachfolgend den so vervollständigten User-Request URE an den Hersteller MAN weiter.
Der Hersteller MAN erhält den User-Request URE mit den erwähnten Informationen vom Nutzer USE und prüft sie, beispielsweise mittels einer Prüfung der Zertifikatskette des öffentlichen KEM-Schlüssels anhand eines Stammzertifikats. Fällt die Prüfung positiv aus, so schließt der Hersteller MAN, dass der Nutzer USE vertrauenswürdig ist. Der Hersteller MAN generiert daraufhin eine Bestätigung des User-Requests URE des Nutzers USE gegenüber dem Gerät DEV. Dazu entkapselt der Hersteller MAN zunächst den Chiffrat CT1 mit seinem eigenen privaten KEM-Schlüssel SKM, welcher mit dem während der Herstellung des Geräts DEV im Gerät DEV gespeicherten öffentlichen KEM-Schlüssel PKM korrespondiert. Im Erfolgsfall generiert der Hersteller so das Geheimnis SSI. Mit einer Schlüsselableitungsfunktion KDF leitet der Hersteller MAN den Sitzungsschlüssel Kl vom Geheimnis SSI ab. Schließlich verwendet der Hersteller MAN den Sitzungsschlüssel Kl mit einem AEAD- Algorithmus, um einen zweiten Authentifizierungs-Tag TAG2 aus dem User-Request URE des Nutzers USE, dem Stammzertifikat des Nutzers USE, dem öffentlichen KEM-Schlüssel PKE des Nutzers USE sowie dem öffentlichen KEM-Schlüssel PKD des Geräts DEV zu berechnen. Alternativ kann eine MAC- oder HMAC-Berechnung verwendet werden, um diesen zweiten Authentifizierungs-Tag TAG2 zu erhalten, welcher die Schlüsselableitungsfunktion KDF und den AEAD-Algorithmus ersetzen würde. Dieser Authentifizierungs-Tag TAG2 wird an den Nutzer USE gesendet.
Der Nutzer USE leitet den zweiten Authentifizierungs-Tag TAG2 an das Gerät DEV weiter.
Das Gerät DEV erhält den zweiten Authentifizierungs-Tag TAG2 vom Nutzer USE und vergleicht ihn mit dem zuvor berechneten und sicher, d. h. vertraulich und integritätsgeschützt, gespeicherten ersten Authentifizierungs-Tag TAG1. Wenn erster TAG1 und zweiter Authentifizierungs-Tag TAG2 gleich sind, authentifiziert das Gerät DEV, dass die Benutzeranfrage URE vom, per se als vertrauenswürdig geltenden, Hersteller MAN des Geräts DEV geprüft und akzeptiert worden ist, da nur der Hersteller MAN das Geheimnis SSI erhalten kann. Zudem stellt die Authentifizierung sicher, dass die Benutzeranfrage URE nicht modifiziert oder geändert worden ist, also integer ist, da erster TAG1 und zweiter Authentifizierungs-Tag TAG2 gleich sind. Wenn jedoch erster TAG1 und zweiter Authentifizierungs- Tag TAG2 nicht gleich sind, wird das gesamte Protokoll wiederholt. Wenn keine Übereinstimmung zwischen erstem TAG1 und zweitem Authentifizierungs-Tag TAG2 erzielt werden kann, lehnt das Gerät DEV das Onboarding ab, da der Nutzer USE nicht als vertrauenswürdig gegenüber dem Gerät DEV bestätigt werden kann. In diesem Fall wird zudem eine Warnmeldung, beispielsweise in Gestalt eines Warntons, ausgegeben.
Optional kann in weiteren, nicht eigens dargestellten Ausführungsbeispielen der Hersteller MAN informiert werden, wenn das richtige Gerät DEV erfolgreich in die Nutzerdomäne integriert wurde. Hierzu ist das oben beschriebene Protokoll entsprechend abzuändern: Dazu kapselt der Hersteller MAN beim Generieren der Bestätigung der Benutzeranfrage URE den öffentlichen KEM-Schlüssel des Geräts PKD. Das Geheimnis SS2 wird vom Hersteller MAN sicher, d. h. vertraulich und integritätsgeschützt, gespeichert, während das Chiffrat CT2 zusammen mit dem Authentifizierungs-Tag TAG2 an den Nutzer USE gesendet wird. Andernfalls kann ein Angreifer dieses Geheimnis SS2 auslesen und als gefälschte Bestätigung an den Hersteller MAN zurücksenden, um fälschlicherweise zu bestätigen, dass das Gerät DEV ein korrektes Onboarding durchlaufen hat. Zudem sendet der Nutzer USE nicht allein den zweiten Authentifizierungs-Tag TAG2 an das Gerät DEV, sondern der Nutzer USE leitet zusätzlich das zweite Chiffrat CT2 an das Gerät DEV weiter . Weiterhin entkapselt das Gerät DEV das zweite Chi f frat CT2 zusätzlich mit seinem eigenen privaten KEM-Schlüssel SKD . Daraus berechnet das Gerät DEV ein drittes Geheimnis SS2 ' und leitet dieses dritte Geheimnis SS2 ' an den Hersteller MAN weiter . Der Hersteller MAN vergleicht das dritte Geheimnis SS2 ' mit dem zuvor berechneten zweiten Geheimnis SS2 . Sind zweites SS2 und drittes Geheimnis SS2 ' gleich, so garantiert der Hersteller MAN, dass das richtige Gerät DEV das Onboarding durchlaufen hat .

Claims

Patentansprüche
1. Verfahren zur Prüfung einer Authentizität einer Nachricht (SWU, URE) mithilfe eines Bereitstellers eines Geräts (DEV) durch dieses Gerät (DEV) , bei welchem durch das Gerät aus der Nachricht (SWU, URE) mittels eines mit einem privaten Schlüssel (SKM) des Bereitstellers umkehrbaren asymmetrischen kryptographischen Verfahrens mit einem öffentlichen Schlüssel des Bereitstellers (PKM) und mit der Nachricht (SWU) eine erste Auszeichnung (TAG1) und ein Chiffrat (CT2) generiert werden, wobei das Chiffrat (CT2) nachfolgend an den Bereitsteiler gesendet wird und wobei vom Bereitsteiler mittels des privaten Schlüssels (SKM) und des Chiffrats (CT2) mittels der Umkehrung des kryptographischen Verfahrens eine zweite Auszeichnung (TAG2) erhalten wird, wobei, vorzugsweise ausschließlich, bei einer Übereinstimmung der ersten Auszeichnung (TAG1) und der zweiten Auszeichnung (TAG2) miteinander auf die Authentizität geschlossen wird.
2. Verfahren nach dem vorhergehenden Anspruch, bei welchem bei einer fehlenden Übereinstimmung von erster (TAG1) und zweiter Auszeichnung (TAG2) ein Warnsignal, insbesondere eine Warnmeldung und/oder ein akustisches Warnsignal und/oder ein optisches Warnsignal, generiert wird.
3. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem das asymmetrische kryptographische Verfahren derart ausgebildet ist, dass es aus der Nachricht mittels eines Schlüsselkapselungsverfahrens mit einem öffentlichen Schlüssel des Bereitstellers das Chiffrat (CT2) und einen ersten Sitzungsschlüssel (Kl) generiert, wobei mittels des ersten Sitzungsschlüssels (Kl) gemeinsam mit der Nachricht (SWU, URE) die vom ersten Sitzungsschlüssel (Kl) und von der Nachricht (SWU, URE) abhängige erste Auszeichnung (TAG1) generiert wird.
4. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem die Umkehrung des kryptographischen Verfahrens derart erfolgt, dass mittels des Chiffrats (CT2) und des privaten Schlüssels (SKM) des Bereitstellers (MAN) ein zweiter Sitzungsschlüssel (K2) generiert wird und mittels des zweiten Sitzungsschlüssels (K2) und der Nachricht (SWU) die zweite Auszeichnung (TAG2) generiert wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem das kryptographische asymmetrische Verfahren ein Schlüsselkapselungsverfahren ist und bei welchem die Umkehrung des kryptographischen Verfahrens ein mit den Schlüsselkapselungsverfahren korrespondierendes Schlüsselentkapselungsverfahren ist.
6. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem die Nachricht (URE) eine Nutzeranfrage, insbesondere eine Provisionierungs- und/oder Konfigurationsanfrage ist.
7. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem die Nachricht (SWU) eine Software und/oder ein Softwareupdate ist.
8. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem die zweite Auszeichnung (TAG2) über einen Nutzer
(USE) erhalten wird, insbesondere über einen Nutzer (USE) der Nutzeranfrage (URE) .
9. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem das Gerät (DEV) ein industrielles Gerät (DEV) eines industriellen Netzwerks, insbesondere eines Internet-der- Dinge-Net zwerks , ist und/oder ein Fertigungsgerät und/oder ein Wartungsgerät und/oder ein Logistikgerät ist.
10. Gerät, ausgebildet und eingerichtet zur Ausführung eines Verfahrens nach einem der vorhergehenden Ansprüche.
EP24717109.3A 2023-03-21 2024-03-19 Verfahren zur prüfung einer authentizität einer nachricht und gerät Pending EP4662830A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP23163182 2023-03-21
EP23176420.0A EP4436098A1 (de) 2023-03-21 2023-05-31 Verfahren zur prüfung einer authentizität einer nachricht und gerät
PCT/EP2024/057247 WO2024194292A1 (de) 2023-03-21 2024-03-19 Verfahren zur prüfung einer authentizität einer nachricht und gerät

Publications (1)

Publication Number Publication Date
EP4662830A1 true EP4662830A1 (de) 2025-12-17

Family

ID=90719315

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24717109.3A Pending EP4662830A1 (de) 2023-03-21 2024-03-19 Verfahren zur prüfung einer authentizität einer nachricht und gerät

Country Status (2)

Country Link
EP (1) EP4662830A1 (de)
WO (1) WO2024194292A1 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030211842A1 (en) * 2002-02-19 2003-11-13 James Kempf Securing binding update using address based keys
US12284270B2 (en) * 2021-04-27 2025-04-22 Qusecure, Inc Systems and methods for providing signatureless, confidential and authentication of data during handshake for classical and quantum computing environments

Also Published As

Publication number Publication date
WO2024194292A1 (de) 2024-09-26

Similar Documents

Publication Publication Date Title
DE60302276T2 (de) Verfahren zur ferngesteuerten Änderung eines Kommunikationspasswortes
DE60119857T2 (de) Verfahren und Vorrichtung zur Ausführung von gesicherten Transaktionen
DE102013203415B4 (de) Erstellen eines abgeleiteten Schlüssels aus einem kryptographischen Schlüssel mittels einer physikalisch nicht klonbaren Funktion
EP1080557B1 (de) Verfahren und anordnung zum rechnergestützten austausch kryptographischer schlüssel zwischen einer ersten computereinheit und einer zweiten computereinheit
DE112015002927B4 (de) Generierung und Verwaltung geheimer Chiffrierschlüssel auf Kennwortgrundlage
DE102013206185A1 (de) Verfahren zur Erkennung einer Manipulation eines Sensors und/oder von Sensordaten des Sensors
DE102022203725A1 (de) Verfahren zum Austausch kryptographischer Schlüssel zwischen Kommunikationsteilnehmern
DE102015202935A1 (de) Verfahren zum Manipulationsschutz
EP1368929A2 (de) Verfahren zur authentikation
EP2684312B1 (de) Verfahren zur authentisierung, rf-chip-dokument, rf-chip-lesegerät und computerprogrammprodukte
EP3276911B1 (de) Authentifizierte verbindung zwischen mindestens zwei kommunikationspartnern
EP3525414A1 (de) Verfahren zur verschlüsselten übertragung von daten auf einer kryptographisch geschützten, unverschlüsselten kommunikationsverbindung
EP3726798A1 (de) Kryptographisch geschütztes bereitstellen eines digitalen zertifikats
WO1998010559A1 (de) Anordnung und verfahren zur kryptographischen bearbeitung eines digitalen datenstroms, der eine beliebige anzahl von daten aufweist
EP3759958B1 (de) Verfahren, vorrichtung und computerprogrammprodukt zur überwachung einer verschlüsselten verbindung in einem netzwerk
EP3697019A1 (de) Verfahren zur bereitstellung eines herkunftsortnachweises für ein digitales schlüsselpaar
EP1468520B1 (de) Verfahren zur datenverkehrssicherung in einer mobilen netzumgebung
EP4662830A1 (de) Verfahren zur prüfung einer authentizität einer nachricht und gerät
EP4436098A1 (de) Verfahren zur prüfung einer authentizität einer nachricht und gerät
WO2024194087A1 (de) Beglaubigung von daten eines authentisierungs- und schlüsselvereinbarungsprotokoll-ablaufs
DE102019216203A1 (de) Auf Blockverschlüsselung basierender Proof-of-Work
EP2154625B1 (de) Sichere personalierung eines einmalpasswort-generators
DE102004001490A1 (de) Verfahren zur Authentifizierung einer Nachricht
DE102020202879A1 (de) Verfahren und Vorrichtung zur Zertifizierung eines anwendungsspezifischen Schlüssels und zur Anforderung einer derartigen Zertifizierung
DE102014212219A1 (de) Verfahren zur Authentifizierung und Anbindung eines Geräts an ein Netzwerk sowie hierzu eingerichteter Teilnehmer des Netzwerks

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250910

AK Designated contracting states

Kind code of ref document: A1

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