EP4335078B1 - Verfahren zur kommunikation von iot knoten oder iot geräten in einem lokalen netzwerk - Google Patents

Verfahren zur kommunikation von iot knoten oder iot geräten in einem lokalen netzwerk Download PDF

Info

Publication number
EP4335078B1
EP4335078B1 EP22726736.6A EP22726736A EP4335078B1 EP 4335078 B1 EP4335078 B1 EP 4335078B1 EP 22726736 A EP22726736 A EP 22726736A EP 4335078 B1 EP4335078 B1 EP 4335078B1
Authority
EP
European Patent Office
Prior art keywords
lot
nodes
node
iot
devices
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.)
Active
Application number
EP22726736.6A
Other languages
English (en)
French (fr)
Other versions
EP4335078A1 (de
EP4335078C0 (de
Inventor
Karsten Walther
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.)
Perinet GmbH
Original Assignee
Perinet GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Perinet GmbH filed Critical Perinet GmbH
Publication of EP4335078A1 publication Critical patent/EP4335078A1/de
Application granted granted Critical
Publication of EP4335078C0 publication Critical patent/EP4335078C0/de
Publication of EP4335078B1 publication Critical patent/EP4335078B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H04L9/3073—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • the present invention relates to a method for communication of IoT nodes or IoT devices in a local network and to a local network with a plurality of IoT nodes or IoT devices.
  • IoT Internet of Things
  • IoT Industrial Internet of Things
  • German Patent and Trademark Office searched the following documents: US 2020/0259667 A1 and WO 2020/143982 A1 .
  • US 2019/253243 A1 shows a method for communication between IoT nodes or IoT devices in a local network that is at least partially connected to the Internet via a computer.
  • the local network has a plurality of IoT nodes or IoT devices that have a first interface for communication with the local network.
  • Each of the IoT nodes or IoT devices has a first public cryptographic key and a first private cryptographic key.
  • the IoT nodes or IoT devices in the local network are authenticated.
  • DE 10 2019 126 686 A1 relates to a method for communicating with Internet of Things devices in a network.
  • a browser sends a request for an IoT device to a DNS server.
  • the DNS server transmits an address of the IoT device to a browser, where the address represents an IPV6 link local address of the IoT device.
  • This object is achieved by a method for communication of IoT nodes or IoT devices in a local network according to claim 1 and by a local Internet-of-Things IoT network according to claim 7.
  • a method for communication between IoT nodes or IoT devices in a local network that is at least partially connected to the Internet via a computer.
  • the local network e.g., a Local Area Network LAN
  • the IoT nodes or IoT devices are designed without displays and control elements. Furthermore, they have a first interface for communication in the local network with other IoT nodes or the computer.
  • Each IoT node or IoT device has a first public cryptographic key and a first private cryptographic key. The first private key is stored in advance in the IoT node or IoT device or is generated by it.
  • Authentication of the IoT nodes or IoT devices in the local network occurs by the computer sending a request for a root certificate to a root certificate server on the Internet that has at least one root certificate from a manufacturer of the IoT nodes or IoT devices.
  • the root certificate is received and stored by the computer.
  • the computer checks whether the The IoT nodes or IoT devices present on the local network represent original and unmodified devices. This is done using the received root certificate.
  • the root certificate is suitable for linking the first public key of the IoT nodes or IoT devices with unique address information of the IoT node or IoT device.
  • the unique address information can represent address information that is only valid within the local network.
  • the computer uses the stored root certificate to check whether the public key of the IoT node or IoT device is signed by the manufacturer.
  • the first private cryptographic key of the IoT node or IoT device is verified based on a cryptographic procedure.
  • Address information that is only valid in the local network differs from the usual approach because identification is typically based on global (routable) addresses. However, these addresses depend on the location of use and may therefore not be known to the node manufacturer. Therefore, attestation can only be enabled indirectly with the help of the manufacturer of the IoT nodes or devices. In addition, the effort required for authentication is increased because the routable network names are subject to administrator management and do not follow a ZeroConf (zero configuration) approach, which uses only locally valid address information.
  • a Zero Configuration network is a network that allows autonomous configuration without human intervention. By using address information that is only valid in the local network, automatic and autonomous configuration of the IoT sensors or devices in the local network can be achieved.
  • the unique local address information can, for example, be a Link Local Address IPv6 or a Multicast Domain Name Service network name.
  • the computer after receiving and saving the root certificate, can be disconnected from the Internet, so that no active Internet connection is present. This allows further authentication of the IoT nodes or IoT devices present in the local network to take place anonymously without an active Internet connection. Access to the local network via the Internet and a possible attack on the local network can thus be prevented.
  • the IoT node or the IoT device has only a first interface for communication with the network and optionally a second interface for communication with sensors or actuators coupled to the IoT.
  • the invention also relates to a local Internet of Things (IoT) network.
  • the network comprises a plurality of Internet of Things (IoT) nodes or devices, which are designed without displays and control elements and each have a first interface for communication with the local network, with other IoT nodes, or with a computer.
  • the network comprises a computer that is at least partially connected to the Internet.
  • Each IoT node or each IoT device has a first public cryptographic key and a first private cryptographic key. The first private key is stored in advance or is generated by the IoT node or IoT device itself.
  • the computer is configured to authenticate IoT nodes or IoT devices in the local network by sending a request for a root certificate from the computer to a root certificate server on the Internet, which has at least one root certificate from a manufacturer of the IoT nodes or IoT devices.
  • the root certificate is received and stored by the computer, and the computer uses the received root certificate to verify whether the IoT nodes or IoT devices are original and unmodified devices.
  • the root certificate is designed to link the first public key of the IoT nodes or IoT devices with unique, exclusively locally valid address information of the IoT node or IoT device.
  • the computer is designed to verify, using the stored root certificate, whether the first public key of the IoT nodes or IoT devices is signed by the manufacturer of the IoT node or IoT device.
  • the first private key of the IoT node or IoT device is verified based on a cryptographic method.
  • Fig. 1 shows a schematic representation of a local network according to a first embodiment of the invention and Fig. 2 shows an enlarged view of part of the local network of Fig. 1
  • a local network 100 comprises a plurality of IoT (Internet of Things) nodes 110, which are interconnected by an Ethernet network or a Single Pair Ethernet network 120.
  • a computer 130 is connected to the local network 120.
  • the computer 130 can establish a connection to the Internet 200.
  • This connection to the Internet can be as in Fig. 2 As shown, it can be used to retrieve a root certificate Z for the IoT nodes 110 in the local network 100, for example, from a root certificate server 210 of a manufacturer of the IoT nodes 110.
  • only the at least one computer 130 has the ability to communicate with the Internet 200 and in particular with the root certificate server 210.
  • the IoT nodes 110 can only communicate within the local network 120 with other IoT nodes 110 or with the computer 130. This is intended to reduce the possibility of external unauthorized access to the IoT nodes.
  • the at least one computer 130 which is connectable to the Internet, has sufficient mechanisms for protection against unauthorized access (for example, firewalls, anti-virus software, etc.).
  • the first embodiment of the invention thus particularly relates to providing internal security for the local network 100.
  • it is intended to ensure that the IoT nodes within the network 100 represent original and unmodified devices. This is intended to prevent attacks or unauthorized access from within the local network 100.
  • it is intended to prevent IoT nodes from accessing other IoT nodes and reading and modifying data without this being necessary for fulfilling their intended task.
  • automatic authentication in the sense of a zero-configuration network
  • This is particularly advantageous because it eliminates the need for centralized, certificate-based security mechanisms. Furthermore, it also avoids the need to manually enter a username and password combination for each IoT node.
  • an automatic authentication of the IoT nodes 110 within the local network 100 is to be enabled without the need for a continuously active Internet connection, for example to a root certificate server 210.
  • a continuously active Internet connection for example to a root certificate server 210.
  • at least one computer 130 establishes an active Internet connection to a root certificate server 210 and sends a request for a root certificate from the manufacturer of the IoT nodes 110.
  • the root certificate Z can be stored on the computer 130. In this case, the certificate Z can be installed in a browser on the computer 130.
  • the active Internet connection can then be disconnected, so that the local network 110 or the computer 130 is disconnected from the Internet 200.
  • the IoT nodes or IoT devices are devices that are designed without displays and control elements. This can reduce the costs of the IoT nodes or IoT devices.
  • the IoT nodes or IoT devices can only be controlled via the local network. For example, parameters can be set via a browser on computer 130.
  • Fig. 3 shows a schematic representation of the local network of Fig. 1 during the verification of the IoT nodes 110 present in the local network.
  • the computer 130 can verify the IoT nodes 110 in the local network 100. In doing so, the computer 130 can first verify an authenticity E, ie, it is checked whether the existing IoT nodes 110 represent original and unmodified IoT nodes 110 or IoT devices.
  • Each of the IoT nodes 110 is assigned a first public cryptographic key and a first private cryptographic key.
  • the first private cryptographic key of the IoT nodes 110 can be stored or filed in the IoT node 110 by the manufacturer during device manufacture. This first private key can be stored in such a way that it can no longer be changed. Alternatively, the IoT node 110 can be configured to generate this first private cryptographic key itself.
  • Each IoT node 110 is also provided with unique address information during manufacture by the manufacturer. This unique address information can be a device name valid only in the local network. The unique local address information can be, for example, a Link Local Address IPv6 or a Multicast Domain Name Service network name.
  • the browser of the computer 130 can use the installed root certificate Z to verify whether the public key of the IoT nodes 110 was signed by the manufacturer of the IoT nodes 110.
  • a Transport Layer Security TLS method can be used to verify that the IoT node 110 is an original device based on the first private key.
  • Fig. 4 shows a schematic representation of a local network according to a second embodiment.
  • the local network 100 according to the second embodiment can be based on the local network 100 according to the first embodiment of Fig. 1
  • a plurality of IoT nodes 110 are coupled to one another and to a computer 130 via a network 120.
  • those IoT nodes 110 that functionally belong together are to be combined to form virtual local networks 101, 102.
  • This is done by a local public key infrastructure (PKI).
  • the first virtual local network 101 can thus represent a first local public key infrastructure (PKI) 1.
  • the second virtual local network 102 can represent a second public key infrastructure (PKI) 2.
  • PKI public key infrastructure
  • a second cryptographic key pair can be generated in the IoT node 110 or loaded onto the IoT node 110.
  • the key pair can be signed by a certificate for a local root public key infrastructure (PKI) instance. If an IoT node 110 acts as a server in the desired application, then the PKI certificate can be used as a host certificate. Using this host certificate, other IoT nodes 110 in the network can verify the identity of the node and, if necessary, establish encrypted communication.
  • PKI public key infrastructure
  • the IoT node 110 can function both as a server and as a client.
  • the IoT node 110 can function, for example, as a Message Queuing Telemetry Transport MQTT subscriber/publisher (client) or broker (server) or HTTP server.
  • client Message Queuing Telemetry Transport MQTT subscriber/publisher
  • server broker
  • HTTP server HTTP server
  • a user certificate can be generated for the IoT node 110 based on the cryptographic key pair, which is signed by the local PKI root and can be stored on the IoT node 110.
  • the certificate of such a PKI root can then optionally be stored as a trusted root certificate on the other IoT node 110. This enables automatic connection establishment between the IoT nodes 110 in the local network 100.
  • the IoT nodes 110 that establish the connection it is advantageously possible for the IoT nodes 110 that establish the connection to be able to authenticate each other and establish encrypted communication. In particular, it allows automated authentication and connection establishment without the local network having to be connected to the Internet and without an administrator having to intervene in the process.
  • a local PKI can be provided for M2M (machine-to-machine) communication based on mTLS (Mutual Transport Layer Security).
  • M2M machine-to-machine
  • mTLS Mobile Transport Layer Security
  • rights management of the communication of the IoT nodes 110 can be provided. Thus, it can be determined which of the IoT nodes 110 can read data, modify data, create new data, or configure a server within the local network 100. Each IoT node 110 can have a client certificate in which its authorizations are stored. These authorizations can be verified by a server (the IoT node 110 acting as a server).
  • the second embodiment can be used for machine-to-machine communication and/or for communication between a machine and a human user or between two human users.
  • a human user can, for example, communicate using a device (Secure Stick) independently of the used loT node 110 within the local PKI structure.
  • the local root PKI instance may represent an IoT node 110.
  • an IoT node 110 may automatically monitor the verification of other IoT nodes 110 in the local network 100 or the addition of new IoT nodes 110 to the local network 100.
  • multiple virtual local networks can be provided, which can also overlap, in order to be able to execute multiple applications in the local network 100.
  • a separate PKI root can be used for each application.
  • a virtual local network 101, 102 can be provided for each PKI root. This is advantageous because it enables a separation of the respective applications based on the virtual local networks 101, 102.
  • adding a new node to a virtual local area network of a management node can be semi-automatic.
  • the management node can alert the user to unassigned nodes. The user can decide whether or not to select such a node. After selecting the new node, the node can be automatically assigned or ignored by the management node as described above.
  • one of the IoT nodes 110 performs a reset or resetting when it receives a reset request via a special packet received at the media access level.
  • a packet is typically invalid but can contain individual information of the node.
  • IP protocol-based local network it is only possible to send such packets to the IoT node if the user is directly connected to the IoT node without intermediate stations such as switches. This is because such packets are not forwarded by a switch. This simply ensures that a reset or resetting request is only possible if the user also has actual physical access to the node. For example, in an Ethernet network with a 100 Base T1 cable, the maximum distance from the node is 15 m.
  • a reaction can be made to a loss of the certificate stored on the computer 130. This can occur, for example, if the computer 130 is defective. If access to the required certificate is no longer possible, the local PKI structure must be re-established. In the prior art, this is possible by pressing a reset button on the IoT node or by transmitting a corresponding reset command (unencrypted). However, the use of an unencrypted reset command is undesirable for security reasons, as this could allow the local network to be reset by an unauthorized person. Furthermore, the use of a reset button on the IoT node is associated with additional costs, which the invention aims to avoid.
  • the IoT node according to the invention has neither a display nor control elements nor a reset button.
  • the IoT node only has a first interface for communication with the network 120.
  • a second interface can be used for communication with devices coupled to the IoT node 110.
  • the reset function according to the invention ensures that no attacker can reset the IoT nodes 110 in the local network 100 via the Internet. Rather, the command or request for the reset must be sent from a device that is physically connected directly to the IoT node 110 to be reset via a network cable.
  • the reset request according to the invention thus represents a virtual reset button.
  • Fig. 5 shows a schematic representation of a reset unit according to an embodiment of the invention.
  • the reset unit 300 has an internal power supply 310, for example in the form of a battery or an accumulator unit.
  • the reset unit 300 has a first interface 301, for example for connection to a Single Pair Ethernet hybrid cable.
  • the reset unit 300 has a second interface 302 in the form of a USB charging port.
  • the power supply 310 can be charged via this USB charging port 302.
  • the reset unit 300 which can be connected to an IoT node 110 or can be provided in an IoT node, the IoT node can be reset by means of the reset unit 300. This can occur, for example, if invalid states of the lines exist in a Single Pair Ethernet hybrid connection.
  • An example of such invalid states is a supply voltage that is too low in the simultaneous absence of a T1 link.
  • the loT node 110 must then be disconnected from the network 120 and connected to the reset unit 300. This in turn requires physical access to the IoT node 110.
  • the original, for example, single-pair Ethernet hybrid cable is removed from the IoT node 120, and the node is connected to the reset unit 300.
  • the reset unit 300 then serves as the power supply for the IoT node 110 and can initiate the reset.
  • the reset unit 300 then deletes all second certificates and key pairs installed/generated during operation, as well as other information, on the IoT node 110, and the node must be reintegrated by the management node with a root certificate.
  • the use of second key pairs generated on the IoT node is particularly advantageous, since these cannot be restored after the reset. Furthermore, the IoT node 110 must always be reintegrated into a virtual local network after the reset, whereby the operator of the virtual local network is always aware of the reset process.
  • a method for secure local communication of network-capable IoT nodes within a local network is provided.
  • the network-capable IoT nodes can be set up or installed using cryptographic methods and two cryptographic key pairs. This allows anonymous establishment of secure communication within a local network.
  • a key pair can be generated during production of the IoT nodes or during commissioning.
  • the two key pairs can be verified by a certificate with a network address assigned during production, which is valid in every local network.
  • the authenticity of an IoT node can be verified using local address information (e.g., an mdns hostname) and a device-specific private key.
  • local address information e.g., an mdns hostname
  • a reset of the IoT nodes or IoT devices provided in the local network can be performed by sending special packets to the IoT nodes at the media access layer. This is advantageous because it can prevent attacks such as denial of service.
  • a reset unit can be provided in or on an IoT node that does not require a reset button.
  • a reset command can be issued via a first interface of the reset unit, which is coupled to a single-pair Ethernet hybrid cable.
  • a reset can be initiated by receiving a specific packet or by detecting invalid line states.
  • the IoT nodes can represent network-capable smart home devices or building automation devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zur Kommunikation von loT Knoten oder loT Geräten in einem lokalen Netzwerk sowie ein lokales Netzwerk mit einer Mehrzahl von loT Knoten oder loT Geräten.
  • Zur Verbesserung der Automatisierung werden immer mehr Sensoren und Aktoren eingesetzt, welche netzwerkfähig sind. Derartige Netzwerke werden als Internet der Dinge oder Internet of Things loT oder als industrielles Internet der Dinge Industrial Internet of Things IloT bezeichnet. Eine Kommunikation zwischen den Sensoren und den Aktoren basiert typischerweise auf einem IP Protokoll. Hierbei können diese Sensoren und Aktoren in einem lokalen Netzwerk (Smart Home oder in einer Fabrik) eingesetzt werden. Alternativ dazu können diese loT Sensoren und Aktoren auch unmittelbar mit dem Internet verbunden sein.
  • Insbesondere bei der Verwendung von loT Sensoren in einem lokalen Netzwerk muss die Sicherheit der internen Kommunikation gewährleistet sein.
  • In der prioritätsbegründenden deutschen Patentanmeldung hat das Deutsche Patent- und Markenamt die folgenden Dokumente recherchiert: US 2020/0259667 A1 und WO 2020/143982 A1 .
  • US 2019/253243 A1 zeigt ein Verfahren zur Kommunikation von loT-Knoten oder loT-Geräten in einem lokalen Netzwerk, das über einen Computer zumindest teilweise mit dem Internet verbunden ist. Das lokale Netzwerk weist eine Mehrzahl von loT-Knoten oder loT-Geräten auf, welche eine erste Schnittstelle zur Kommunikation mit dem lokalen Netzwerk aufweisen. Jeder der loT-Knoten oder loT-Geräte weist einen ersten öffentlichen kryptographischen Schlüssel und einen ersten privaten kryptographischen Schlüssel auf. Die loT-Knoten oder loT-Geräte in dem lokalen Netzwerk werden authentifiziert.
  • DE 10 2019 126 686 A1 betrifft ein Verfahren zur Kommunikation mit Internet-of-Things Geräten in einem Netzwerk. Hierzu wird eine Anfrage nach einem loT-Gerät durch einen Browser an einen DNS-Server gesendet. Eine Adresse des loT-Gerätes wird von dem DNS-Server an einen Browser übermittelt, wobei die Adresse eine IPV6 Link Local Adresse des loT-Gerätes darstellt.
  • Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren zur Kommunikation von loT Knoten oder loT Geräten in einem lokalen Netzwerk mit einer verbesserten Sicherheit zu ermöglichen.
  • Diese Aufgabe wird durch ein Verfahren zur Kommunikation von loT Knoten oder loT Geräten in einem lokalen Netzwerk gemäß Anspruch 1 und durch ein Lokales Internet-of-Things IoT Netzwerk nach Anspruch 7 gelöst.
  • Somit wird ein Verfahren zur Kommunikation von loT Knoten oder loT Geräten in einem lokalen Netzwerk vorgesehen, das nur über einen Computer zumindest teilweise mit dem Internet verbunden ist. Das lokale Netzwerk (z.B. ein Local Area Network LAN) stellt ein Ethernet Netzwerk oder ein Single Pair Ethernet Netzwerk dar. Die loT Knoten oder die IoT Geräte sind displaylos und bedienungselementefrei ausgestaltet. Ferner weisen sie eine erste Schnittstelle zur Kommunikation in dem lokalen Netzwerk mit anderen loT Knoten oder dem Computer auf. Jeder loT Knoten oder jedes loT Gerät weist einen ersten öffentlichen kryptographischen Schlüssel und einen ersten privaten kryptographischen Schlüssel auf. Der erste private Schlüssel ist vorab in dem IoT Knoten oder dem loT Gerät abgelegt oder wird von diesem erzeugt. Eine Authentifizierung der loT Knoten oder der loT Geräte in dem lokalen Netzwerk erfolgt durch Senden einer Anfrage nach einem Root-Zertifikat durch den Computer an einen Root-Zertifikat Server im Internet, der mindestens ein Root-Zertifikat eines Herstellers der loT Knoten oder der loT Geräte aufweist. Das Root-Zertifikat wird durch den Computer empfangen und gespeichert. Der Computer überprüft, ob die in dem lokalen Netzwerk vorhandenen IoT Knoten oder loT Geräte originale und unveränderte Geräte darstellen. Dies erfolgt anhand des empfangenen Root-Zertifikats. Das Root-Zertifikat ist dazu geeignet, den ersten öffentlichen Schlüssel der loT Knoten oder der loT Geräte mit einer eindeutigen Adressinformation des loT Knotens oder des loT Gerätes zu verknüpfen. Die eindeutigen Adressinformationen können Adressinformationen darstellen, die ausschließlich in dem lokalen Netzwerk gültig ist. Der Computer überprüft anhand des gespeicherten Root-Zertifikats, ob der öffentliche Schlüssel des IoT Knotens oder des loT Gerätes durch den Hersteller signiert ist. Der erste private kryptographische Schlüssel des loT Knotens oder des loT Gerätes wird basierend auf einem kryptographischen Verfahren überprüft.
  • Eine ausschließlich in dem lokalen Netzwerk gültige Adressinformationen unterscheidet sich von der sonst üblichen Vorgehensweise, da typischerweise die Identifikation basierend auf globalen (routing-fähigen) Adressen erfolgt. Diese Adressen sind jedoch vom Einsatzort abhängig und können somit dem Hersteller des Knotens nicht bekannt sein. Daher kann eine Attestation nur indirekt mit Hilfe des Herstellers der loT Knoten oder Geräte ermöglicht werden. Zudem erhöht sich der Aufwand für Authentifizierungen, da die Routing-fähigen Netzwerknamen einer Verwaltung des Administrators unterliegen und nicht einem ZeroConf-Ansatz (zero configuration) folgen, der ausschließlich lokal gültigen Adressinformationen verwendet. Ein Zero Configuration Netzwerk stellt ein Netzwerk dar, das eine selbstständige Konfiguration ohne Eingriffe eines menschlichen Bedieners erlaubt. Durch die Verwendung von lediglich im lokalen Netzwerk gültige Adressinformationen kann eine automatische und selbstständige Konfiguration der loT Sensoren oder Geräte in dem lokalen Netzwerk erfolgen. Die eindeutige lokale Adressinformation kann beispielsweise eine Link Local Address IPv6 oder einen Multicast Domain Name Service Netzwerknamen darstellen.
  • Gemäß einem Aspekt der vorliegenden Erfindung kann der Computer nach Empfangen und Speichern des Root-Zertifikats vom Internet getrennt werden, so dass keine aktive Internetverbindung vorhanden ist. Damit kann die weitere Authentifizierung der in dem lokalen Netzwerk vorhandenen loT Knoten oder der loT Geräte ohne aktive Internetverbindung und damit anonym erfolgen. Ein Zugriff auf das lokale Netzwerk über das Internet und ein möglicher Angriff auf das lokale Netzwerk kann damit verhindert werden.
  • Gemäß einem Aspekt der Erfindung weist der loT Knoten oder das loT Gerät lediglich eine erste Schnittstelle zur Kommunikation mit dem Netzwerk und optional eine zweite Schnittstelle zur Kommunikation mit Sensoren oder Aktoren auf, die mit dem loT gekoppelt sind.
  • Somit ist weder ein Display noch ein Bedienelement oder Eingabeelement vorhanden. Einstellungen und Parameter können z.B. über einen Browser auf dem Computer 130 geändert oder angepasst werden.
  • Die Erfindung betrifft ebenfalls ein lokales Internet-of-Things loT Netzwerk. Das Netzwerk weist eine Mehrzahl von Internet-of-Things loT Knoten oder Geräten auf, welche Displaylos und Bedienungselemente-frei ausgestaltet sind und jeweils eine erste Schnittstelle zur Kommunikation mit dem lokalen Netzwerk mit anderen loT Knoten oder einem Computer aufweisen. Das Netzwerk weist einen Computer auf, der zumindest teilweise mit dem Internet verbunden ist. Jeder loT Knoten oder jedes loT Gerät weist einen ersten öffentlichen kryptographischen Schlüssel und einen ersten privaten kryptographischen Schlüssel auf. Der erste private Schlüssel ist vorab abgelegt oder wird von dem loT Knoten oder loT Gerät selber erzeugt. Der Computer ist dazu ausgestaltet, loT Knoten oder loT Geräte in dem lokalen Netzwerk zu authentifizieren, indem eine Anfrage nach einem Root-Zertifikat von dem Computer an einen Root-Zertifikat-Server im Internet gesendet wird, der mindestens ein Root-Zertifikat eines Herstellers der loT Knoten oder der loT Geräte aufweist. Das Root-Zertifikat wird durch den Computer empfangen und gespeichert und es wird durch den Computer anhand des empfangenen Root-Zertifikats überprüft, ob die loT Knoten oder loT Geräte originale und unveränderte Geräte sind. Das Root-Zertifikat ist dazu geeignet, den ersten öffentlichen Schlüssel der IoT Knoten oder loT Geräte mit einer eindeutigen ausschließlich lokal gültigen Adressinformation des loT Knotens oder des loT Gerätes zu verknüpfen. Der Computer ist dazu ausgestaltet, anhand des gespeicherten Root-Zertifikats zu überprüfen, ob der erste öffentliche Schlüssel der loT Knoten oder der loT Geräte durch den Hersteller des loT Knotens oder des loT Gerätes signiert sind. Der erste private Schlüssel des loT Knotens oder des loT Gerätes wird basierend auf einem kryptographischen Verfahren überprüft.
  • Weitere Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
  • Vorteile und Ausführungsbeispiele der Erfindung werden nachstehend unter Bezugnahme auf die Zeichnung näher erläutert.
    • Fig. 1
    zeigt eine schematische Darstellung eines lokalen Netzwerkes gemäß einem ersten Ausführungsbeispiel der Erfindung,
    Fig. 2
    zeigt eine vergrößerte Ansicht eines Teils des lokalen Netzwerkes von Fig. 1,
    Fig. 3
    zeigt eine schematische Darstellung des lokalen Netzwerkes von Fig. 1 während der Überprüfung der in dem lokalen Netzwerk vorhandenen loT Knoten,
    Fig. 4
    zeigt eine schematische Darstellung eines lokalen Netzwerkes gemäß einem zweiten Ausführungsbeispiel, und
    Fig. 5
    zeigt eine schematische Darstellung einer Rücksetzeinheit gemäß einem Ausführungsbeispiel der Erfindung.
  • Fig. 1 zeigt eine schematische Darstellung eines lokalen Netzwerkes gemäß einem ersten Ausführungsbeispiel der Erfindung und Fig. 2 zeigt eine vergrößerte Ansicht eines Teils des lokalen Netzwerkes von Fig. 1. Ein lokales Netzwerk 100 weist eine Mehrzahl von loT (Internet of Things) Knoten 110 auf, welche durch ein Ethernet-Netzwerk oder ein Single Pair Ethernet-Netzwerk 120 miteinander verbunden sind. Ferner ist ein Computer 130 mit dem lokalen Netzwerk 120 verbunden. Der Computer 130 kann eine Verbindung mit dem Internet 200 aufbauen. Diese Verbindung mit dem Internet kann wie in Fig. 2 dargestellt dazu verwendet werden, ein Root-Zertifikat Z für die loT Knoten 110 in dem lokalen Netzwerk 100 beispielsweise von einem Root-Zertifikat-Server 210 eines Herstellers der loT Knoten 110 abzurufen. Gemäß dem ersten Ausführungsbeispiel hat somit lediglich der mindestens eine Computer 130 die Möglichkeit, mit dem Internet 200 und insbesondere mit dem Root-Zertifikat-Server 210 zu kommunizieren. Die loT Knoten 110 können lediglich innerhalb des lokalen Netzwerkes 120 mit anderen IoT Knoten 110 oder mit dem Computer 130 kommunizieren. Damit sollen die Möglichkeiten eines externen unerlaubten Zugriffs auf die loT Knoten verringert werden.
  • Gemäß dem ersten Ausführungsbeispiel weist der mindestens eine Computer 130, welcher mit dem Internet verbindbar ist, ausreichende Mechanismen zum Schutz vor unautorisierten Zugriffen (beispielsweise Firewalls, Antiviren-Software etc.) auf.
  • Das erste Ausführungsbeispiel der Erfindung betrifft somit insbesondere das Vorsehen der internen Sicherheit des lokalen Netzwerks 100. Insbesondere soll sichergestellt werden, dass die IoT Knoten innerhalb des Netzwerkes 120 originale und unveränderte Geräte darstellen. Damit soll vermieden werden, dass Angriffe oder unerlaubte Zugriffe aus dem Inneren des lokalen Netzwerkes 100 möglich sind. Insbesondere soll vermieden werden, dass loT Knoten auf andere loT Knoten zugreifen und Daten auslesen und verändern, ohne dass dies für die Erfüllung ihrer vorgesehenen Aufgabe notwendig wäre.
  • Gemäß dem ersten Ausführungsbeispiel soll eine automatische Authentifizierung (im Sinne eines Zero Configuration Netzwerkes) der vorhandenen bzw. neu hinzugekommenen loT Knoten erfolgen. Dies ist insbesondere vorteilhaft, weil damit keine zentralisierten, auf Zertifikaten basierten Sicherheitsmechanismen verwendet werden müssen. Ferner kann auch vermieden werden, dass für jeden loT Knoten eine Kombination aus Benutzername und Passwort händisch eingegeben werden muss.
  • Somit kann auch eine automatisierte Maschine-zu-Maschine Kommunikation auch in lokalen Netzwerken mit einer sehr hohen Anzahl von loT Knoten 110 ermöglicht werden.
  • Gemäß dem ersten Ausführungsbeispiel soll eine automatische Möglichkeit der Authentifizierung der loT Knoten 110 innerhalb des lokalen Netzwerkes 100 ermöglicht werden, ohne dass hierbei eine kontinuierliche aktive Internetverbindung beispielsweise zu einem Root-Zertifikat-Server 210 vorhanden sein muss. Dies wird erreicht, indem alle Sicherheitsmechanismen in das lokale Netz verlegt werden, ohne dass bei der Authentifizierung eine aktive Internetverbindung vorhanden sein muss. Hierzu baut der mindestens eine Computer 130 eine aktive Internetverbindung zu einem Root-Zertifikat-Server 210 auf und schickt eine Anforderung nach einem Root-Zertifikat des Herstellers der loT Knoten 110. Das Root-Zertifikat Z kann auf dem Computer 130 gespeichert werden. Hierbei kann das Zertifikat Z in einem Browser auf dem Computer 130 installiert werden. Danach kann die aktive Internetverbindung getrennt werden, so dass das lokale Netz 110 bzw. der Computer 130 vom Internet 200 getrennt ist.
  • Die IoT Knoten oder loT Geräte stellen Geräte dar, die Display-los und Bedienungselemente-frei ausgestaltet sind. Damit können die Kosten für die loT Knoten oder loT Geräte reduziert werden. Eine Ansteuerung der loT Knoten oder loT Geräte kann nur über das lokale Netzwerk erfolgen. Beispielsweise kann eine Einstellung von Parametern über einen Browser auf dem Computer 130 erfolgen.
  • Fig. 3 zeigt eine schematische Darstellung des lokalen Netzwerkes von Fig. 1 während der Überprüfung der in dem lokalen Netzwerk vorhandenen IoT Knoten 110. Nachdem die aktive Internetverbindung des Computers 130 mit dem Internet 200 getrennt worden ist, kann der Computer 130 die IoT Knoten 110 in dem lokalen Netzwerk 100 überprüfen. Hierbei kann der Computer 130 zunächst eine Echtheit E überprüfen, d. h. es wird überprüft, ob die vorhandenen loT Knoten 110 originale und unveränderte loT Knoten 110 oder loT Geräte darstellen.
  • Jedem der IoT Knoten 110 ist ein erster öffentlicher kryptographischer Schlüssel und ein erster privater kryptographischer Schlüssel zugeordnet. Der erste private kryptographische Schlüssel der loT Knoten 110 kann während der Herstellung des Gerätes durch den Hersteller in dem loT Knoten 110 gespeichert oder abgelegt werden. Dieser erste private Schlüssel kann derart abgelegt werden, dass er nicht mehr verändert werden kann. Alternativ dazu kann der loT Knoten 110 dazu ausgestaltet sein, diesen ersten privaten kryptographischen Schlüssel selber zu erzeugen. Jeder loT Knoten 110 wird ebenfalls bei der Herstellung durch den Hersteller mit einer eindeutigen Adressinformation vorgesehen. Diese eindeutige Adressinformation kann ein ausschließlich im lokalen Netz gültiger Gerätename sein. Die eindeutige lokale Adressinformation kann beispielsweise eine Link Local Address IPv6 oder einen Multicast Domain Name Service Netzwerknamen darstellen.
  • Zur Überprüfung der loT Knoten 110 kann der Browser des Computers 130 das installierte Root-Zertifikat Z verwenden, um zu überprüfen, ob der öffentliche Schlüssel der loT Knoten 110 durch den Hersteller der IoT Knoten 110 signiert wurde. Beispielsweise ein Transport Layer Security TLS Verfahren kann dazu verwendet werden, dass anhand des ersten privaten Schlüssels nachgewiesen werden kann, dass der loT Knoten 110 ein Originalgerät darstellt. Der Vorteil der oben beschriebenen Authentifizierung der loT Knoten 110 ist, dass dies ohne aktive Internetverbindung erfolgen kann und somit anonym und offline erfolgen kann.
  • Damit ist eine Device Attestation, d. h. eine Überprüfung der IoT Knoten 110, gewährleistet.
  • Fig. 4 zeigt eine schematische Darstellung eines lokalen Netzwerkes gemäß einem zweiten Ausführungsbeispiel. Das lokale Netzwerk 100 gemäß dem zweiten Ausführungsbeispiel kann auf dem lokalen Netzwerk 100 gemäß dem ersten Ausführungsbeispiel von Fig. 1 basieren. Somit ist eine Mehrzahl von loT Knoten 110 über ein Netz 120 miteinander sowie mit einem Computer 130 gekoppelt. In dem zweiten Ausführungsbeispiel sollen diejenigen loT Knoten 110, welche funktionell zusammen gehören, zu virtuellen lokalen Netzwerken 101, 102 zusammengefügt werden. Dies erfolgt durch eine lokale Public-Key-Infrastruktur PKI. Das erste virtuelle lokale Netzwerk 101 kann somit eine erste lokale Public-Key-Infrastruktur PKI 1 darstellen. Das zweite virtuelle lokale Netzwerk 102 kann eine zweite Public-Key-Infrastruktur PKI 2 darstellen. Derartige virtuelle lokale Netzwerke können in Abhängigkeit der benötigten Anwendung zusammengestellt werden. Gemäß dem zweiten Ausführungsbeispiel kann hierzu ein zweites kryptographisches Schlüsselpaar in dem loT Knoten 110 erzeugt oder auf den loT Knoten 110 geladen werden. Das Schlüsselpaar kann durch ein Zertifikat für eine lokale Root Public Key Infrastruktur PKI Instanzsigniert sein. Falls ein IoT Knoten 110 in der gewünschten Anwendung als ein Server fungiert, dann kann das PKI Zertifikat als Host-Zertifikat verwendet werden. Anhand dieses Host-Zertifikats können andere loT Knoten 110 in dem Netzwerk die Identität des Knotens überprüfen und können bei Bedarf eine verschlüsselte Kommunikation aufbauen.
  • In einem weiteren Beispiel basierend auf dem zweiten Ausführungsbeispiel kann der loT Knoten 110 sowohl als Server als auch als Client fungieren. Hierbei kann der loT Knoten 110 beispielsweise als Message Queuing Telemetry Transport MQTT Subscriber/Publis-her(Client) oder Broker(Server) oder http-Server fungieren. Hierbei kann für den loT Knoten 110 ein User Zertifikat auf Basis des kryptographischen Schlüsselpaars erzeugt werden, welches der lokale PKI Root signiert und das auf dem loT Knoten 110 gespeichert werden kann. Das Zertifikat eines derartigen PKI Roots kann dann optional als vertrauenswürdiges Root Zertifikat auf dem anderen loT Knoten 110 gespeichert werden. Damit ist ein automatischer Verbindungsaufbau zwischen den loT Knoten 110 in dem lokalen Netzwerk 100 möglich. Hierbei ist es vorteilhafterweise möglich, dass die IoT Knoten 110, welche die Verbindung aufbauen, sich gegenseitig authentifizieren können und eine verschlüsselte Kommunikation aufbauen können. Insbesondere kann damit eine automatisierte Authentifizierung und Verbindungsaufbau erfolgen, ohne dass das lokale Netzwerk mit dem Internet verbunden sein muss und ohne dass ein Administrator in den Vorgang eingreifen muss.
  • Gemäß dem zweiten Ausführungsbeispiel kann eine lokale PKI für eine M2M (Machine-to-Machine) Kommunikation basierend auf einem mTLS (Mutual Transport Layer Security) vorgesehen sein.
  • Gemäß einem Aspekt des zweiten Ausführungsbeispiels kann eine Rechteverwaltung der Kommunikation der loT Knoten 110 vorgesehen sein. Somit kann festgelegt werden, welcher der loT Knoten 110 Daten lesen kann, Daten modifizieren kann, neue Daten anlegen kann oder einen Server innerhalb des lokalen Netzwerkes 100 konfigurieren kann. Jeder loT Knoten 110 kann ein Client Zertifikat aufweisen, in welchem dessen Berechtigungen abgelegt sind. Diese Berechtigungen können durch einen Server (als Server fungierende loT Knoten 110) überprüft werden.
  • Gemäß einem Aspekt der vorliegenden Erfindung kann das zweite Ausführungsbeispiel zur Maschine-zu-Maschine Kommunikation und/oder zur Kommunikation zwischen einer Maschine und einem menschlichen Nutzer oder zwischen zwei menschlichen Nutzern verwendet werden. Ein menschlicher Nutzer kann sich beispielsweise mittels eines Gerätes (Secure Stick) unabhängig von dem verwendeten loT Knoten 110 innerhalb der lokalen PKI Struktur identifizieren.
  • Gemäß einem Aspekt der vorliegenden Erfindung kann die lokale Root PKI Instanz einen loT Knoten 110 darstellen. Somit kann ein derartiger IoT Knoten 110 die Überprüfung von anderen loT Knoten 110 in dem lokalen Netzwerk 100 oder die Aufnahme von neuen loT Knoten 110 in das lokale Netzwerk 100 automatisiert überwachen.
  • Gemäß einem Aspekt der vorliegenden Erfindung können mehrere virtuelle lokale Netzwerke vorgesehen sein, welche sich auch überschneiden können, um mehrere Anwendungen in dem lokalen Netzwerk 100 ausführen zu können. Für jede Anwendung kann ein separater PKI Root verwendet werden. Für jedes PKI Root kann somit ein virtuelles lokales Netzwerk 101, 102 vorgesehen werden. Dies ist vorteilhaft, weil somit eine Trennung der jeweiligen Anwendungen basierend auf den virtuellen lokalen Netzwerken 101, 102 ermöglicht wird.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung kann ein Hinzufügen eines neuen Knotens zu einem virtuellen lokalen Netzwerk eines Verwaltungsknotens halb automatisch erfolgen. Der Verwaltungsknoten kann den Nutzer auf nicht zugeordnete Knoten hinweisen. Der Nutzer kann entscheiden, ob ein derartiger Knoten ausgewählt werden soll oder nicht. Nach Auswahl des neuen Knotens kann der Knoten durch den Verwaltungsknoten wie oben beschrieben automatisch zugeordnet oder ignoriert werden.
  • Gemäß einem Ausführungsbeispiel der Erfindung führt einer der loT Knoten 110 einen Reset oder ein Rücksetzten durch, wenn er eine Reset-Aufforderung mittels eines speziellen Paketes erhält, das auf Medienzugriffsebene empfangen wurde. Ein derartiges Paket ist typischerweise ungültig, kann aber individuelle Informationen des Knotens enthalten. Vorteilhafterweise ist es in einem IP-Protokoll basierten lokalen Netzwerk nur dann möglich, derartige Pakete zum loT Knoten zu senden, wenn der Benutzer direkt ohne Zwischenstationen wie Switche mit dem loT Knoten verbunden ist. Dies rührt daher, weil derartige Pakete nicht von einem Switch weitergeleitet werden. Somit ist auf einfache Art und Weise sichergestellt, dass eine Reset- oder Rücksetz-Anforderung nur dann möglich ist, wenn der Benutzer auch einen tatsächlichen physischen Zugriff auf den Knoten besitzt. Beispielsweise bei einem Ethernet Netzwerk mit einem 100 Base T1 Kabel beträgt der Maximalabstand 15 m zum Knoten.
  • Somit kann erfindungsgemäß auf einen Verlust des auf dem Computer 130 gespeicherten Zertifikats reagiert werden. Dies kann beispielsweise erfolgen, wenn der Computer 130 defekt ist. Wenn kein Zugriff auf das benötigte Zertifikat mehr möglich ist, dann muss die lokale PKI Struktur neu aufgesetzt werden. Dies ist im Stand der Technik durch eine Betätigung eines Reset Knopfes an dem IoT Knoten oder durch die Übermittlung eines entsprechenden Reset Befehls (unverschlüsselt) möglich. Die Verwendung eines unverschlüsselten Reset Befehls ist jedoch aus Sicherheitsaspekten nicht gewünscht, da somit das lokale Netzwerk von einem nicht Autorisierten zurückgesetzt werden kann. Ferner ist die Verwendung eines Reset Knopfes an dem loT Knoten mit weiteren Kosten verbunden, die erfindungsgemäß vermieden werden sollen.
  • Der loT Knoten gemäß der Erfindung weist weder ein Display noch Bedienelemente noch einen Reset Knopf auf. Der loT Knoten weist lediglich eine erste Schnittstelle zur Kommunikation mit dem Netzwerk 120 auf. Eine zweite Schnittstelle kann zur Kommunikation mit Geräten verwendet werden, welche an den loT Knoten 110 gekoppelt sind.
  • Mit der erfindungsgemäßen Rücksetzfunktion kann sichergestellt werden, dass kein Angreifer über das Internet die IoT Knoten 110 in dem lokalen Netzwerk 100 zurücksetzen kann. Vielmehr muss der Befehl bzw. die Aufforderung für das Rücksetzen von einem Gerät gesendet werden, welches physisch direkt über ein Netzwerkkabel mit dem rückzusetzenden loT Knoten 110 gekoppelt ist. Die erfindungsgemäße Rücksetzaufforderung stellt somit einen virtuellen Reset-Knopf dar.
  • Fig. 5 zeigt eine schematische Darstellung einer Rücksetzeinheit gemäß einem Ausführungsbeispiel der Erfindung. Die Rücksetzeinheit 300 weist eine interne Energieversorgung 310 beispielsweise in Form einer Batterie oder einer Akkumulatoreinheit auf. Die Rücksetzeinheit 300 weist eine erste Schnittstelle 301 beispielsweise zum Anschluss an ein Single Pair Ethernet Hybridkabel auf. Die Rücksetzeinheit 300 weist eine zweite Schnittstelle 302 in Form eines USB Ladeanschlusses auf. Über diesen USB Ladeanschluss 302 kann die Energieversorgung 310 aufgeladen werden. Mittels der Rücksetzeinheit 300, welche an einen IoT Knoten 110 angeschlossen werden kann oder in einem loT Knoten vorgesehen sein kann, kann der loT Knoten mittels der Rücksetzeinheit 300 zurückgesetzt werden. Dies kann beispielsweise dann erfolgen, wenn ungültige Zustände der Leitungen bei einer Single Pair Ethernet Hybridverbindung vorliegen. Ein Beispiel für derartige ungültige Zustände ist eine zu niedrige Versorgungsspannung bei gleichzeitiger Abwesenheit eines T1 Links. Der loT Knoten 110 muss dann von dem Netzwerk 120 getrennt und mit der Rücksetzeinheit 300 verbunden werden. Dies erfordert wiederum einen physischen Zugriff auf den loT Knoten 110. Hierbei wird das ursprüngliche beispielsweise Single Pair Ethernet Hybridkabel von dem Knoten loT 120 entfernt und der Knoten wird an die Rücksetzeinheit 300 angeschlossen. Die Rücksetzeinheit 300 dient dann als Energieversorgung für den loT Knoten 110 und kann das Rücksetzen initiieren. Durch die Rücksetzeinheit 300 werden dann alle während des Betriebes installierten/erzeugten zweiten Zertifikate und Schlüsselpaare sowie weitere Informationen auf dem loT Knoten 110 gelöscht und der Knoten muss erneut vom Verwaltungsknoten mit einem Root-Zertifikat eingebunden werden. Hinsichtlich des Sicherheitsmerkmals "Erschleichen von Zugriffsrechten" ist die Verwendung von auf dem loT Knoten erzeugten 2. Schlüsselpaaren besonders vorteilhaft, da diese nach dem Rücksetzen nicht wieder hergestellt werden können. Ferner muss nach dem Rücksetzen stets ein erneutes Einbinden des IoT Knotens 110 in ein virtuelles lokales Netz erfolgen, wodurch der Betreiber des virtuellen lokalen Netzes stets Kenntnis von dem Rücksetzvorgang erlangt.
  • Durch das Rücksetzen gemäß der Erfindung können alle Schlüsselpaare des Knotens sowie Zertifikate gelöscht werden. Dies hat zur Folge, dass der loT Knoten weder bei einem Server der lokalen PKI Struktur angemeldet werden kann, noch kann ein Client auf diesen zurückgesetzten loT Knoten zugreifen. Damit kann sichergestellt werden, dass ein Firmware Reset oder eine sich dadurch ergebende Möglichkeit des unautorisierten Zugriffs auf das lokale Netzwerk nicht unbemerkt erfolgen kann. Vielmehr muss der Knoten erneut in die Netzwerkumgebung eingeführt werden.
  • Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zur sicheren lokalen Kommunikation netzwerkfähiger loT Knoten innerhalb eines lokalen Netzwerks vorgesehen. Eine Einrichtung oder Installation der netzwerkfähigen loT Knoten kann unter Verwendung kryptographischer Verfahren und zwei kryptographischer Schlüsselpaare erfolgen. Hiermit kann eine anonyme Einrichtung einer gesicherten Kommunikation in einem lokalen Netzwerk erlaubt werden. Ein Schlüsselpaar kann während der Produktion der loT Knoten oder während der Inbetriebnahme erzeugt werden. Die zwei Schlüsselpaare können durch ein Zertifikat mit einer bei der Produktion vergebenen Netzwerkadresse, welche in jedem lokalen Netzwerk gültig ist, verifiziert werden.
  • Gemäß einem Aspekt der vorliegenden Erfindung kann die Echtheit eines loT Knotens anhand von lokalen Adressinformationen (beispielsweise eines mdns Hostnamens) sowie eines gerätespezifischen privaten Schlüssels überprüft werden.
  • Gemäß einem Aspekt der vorliegenden Erfindung kann ein Reset der in dem lokalen Netzwerk vorgesehenen loT Knoten oder loT Geräte erfolgen, indem spezielle Pakete auf der Medienzugriffsebene an die loT Knoten versandt werden. Dies ist vorteilhaft, weil damit Angriffe wie Denial of Services vermieden werden können.
  • Gemäß einem Aspekt der vorliegenden Erfindung kann eine Rücksetzeinheit in oder an einem loT Knoten vorgesehen werden, welcher ohne Reset-Knopf auskommt. Ein Befehl zum Reset kann über eine erste Schnittstelle der Rücksetzeinheit erfolgen, welche mit einem Single Pair Ethernet Hybridkabel gekoppelt ist. Ein Reset kann durch Empfangen eines speziellen Paketes oder durch Erfassen von ungültigen Leitungszuständen erfolgen.
  • Gemäß einem Aspekt der vorliegenden Erfindung können die loT Knoten netzwerkfähige Smart-Home Geräte oder Geräte einer Gebäudeautomatisierung darstellen.

Claims (8)

  1. Verfahren zur Kommunikation von loT Knoten (110) oder loT Geräten in einem lokalen Netzwerk (100), das nur über einen Computer (130) zumindest zeitweise mit dem Internet (200) verbunden ist, wobei das lokale Netzwerk (100) ein Ethernet-Netzwerk oder eine Single Pair Ethernet-Netzwerk darstellt, wobei die loT Knoten (110) oder loT Geräte jeweils eine erste Schnittstelle zur Kommunikation in dem lokalen Netzwerk (120) mit anderen loT Knoten (110) oder dem Computer (130) aufweisen, wobei jeder loT Knoten (110) oder jedes loT Gerät einen ersten öffentlichen kryptographischen Schlüssel und einen ersten privaten kryptographischen Schlüssel aufweist, wobei der erste private Schlüssel vorab abgelegt oder von dem loT Knoten (110) oder dem loT Gerät selber erzeugt wird, mit dem Schritt:
    Authentifizierung von loT Knoten (110) oder loT Geräten in einem lokalen Netzwerk (100), gekennzeichnet durch
    - Senden einer Anfrage nach einem Root-Zertifikat (Z) durch den Computer (130) an einen Root-Zertifikat-Server (210) im Internet (200), der mindestens ein Root-Zertifikat (Z) eines Herstellers der loT Knoten (110) oder der loT Geräte aufweist,
    - Empfangen und Speichern des Root-Zertifikats (Z) durch den Computer (130), und
    - Überprüfen durch den Computer (130) anhand des empfangenen Root-Zertifikat (Z), ob die loT Knoten (130) oder loT Geräte originale und unveränderte Geräte sind, wobei das Root-Zertifikat (Z) dazu geeignet ist, den ersten öffentlichen Schüssel der loT Knoten (110) oder loT Geräte mit einer eindeutigen ausschließlich im lokalen Netz gültigen Adressinformation des loT Knotens (110) oder des loT Gerätes zu verknüpfen,
    wobei der Computer (130) anhand des gespeicherten Root-Zertifikats (Z) überprüft, ob der öffentliche Schlüssel des loT Knotens (110) oder des loT Gerätes durch den Hersteller des loT Knotens (110) oder des loT Gerätes signiert ist,
    wobei der erste private Schlüssel des loT Knotens (110) oder des loT Gerätes basierend auf einem kryptografischen Verfahren überprüft wird,
    wobei die loT Knoten (110) oder die loT Geräte Display-los und Bedienungselemente-frei ausgestaltet sind.
  2. Verfahren zur Kommunikation von loT Knoten (110) oder loT Geräten in einem lokalen Netzwerk (100) nach Anspruch 1, wobei
    der Computer (130) nach Empfang des Root-Zertifikats (Z) von dem Root-Zertifikat-Servers (210) die Verbindung mit dem Internet (200) trennt, bevor die Prüfung der loT Knoten (110) oder des loT Gerätes erfolgt.
  3. Verfahren zur Kommunikation von loT Knoten (110) oder loT Geräten in einem lokalen Netzwerk (100) nach Anspruch 1 oder 2, wobei
    jeder loT Knoten (110) oder jedes loT Gerät einen lokalen und eindeutigen Hostnamen, insbesondere eine IPv6 link local Adresse oder einen Multicast Domain Name System mDNS Netzwerknamen, aufweist.
  4. Verfahren zur Kommunikation von loT Knoten (110) oder loT Geräten in einem lokalen Netzwerk (100) nach einem der Ansprüche 1 bis 3, ferner mit den Schritten:
    Einbinden von loT Knoten (110) oder loT Geräten in ein virtuelles lokales Netzwerk (101, 102) in Form einer lokalen Public-Key-Infrastruktur,
    wobei jedem dieser loT Knoten (110) oder loT Geräten ein zweites kryptografisches Schlüsselpaar zugeordnet ist.
  5. Verfahren zur Kommunikation von loT Knoten (110) oder loT Geräten in einem lokalen Netzwerk (100) nach einem der Ansprüche 1 bis 4, ferner mit den Schritten:
    Rücksetzen eines loT Knotens (110) oder eines loT Gerätes mittels einer Rücksetzeinheit (300), welche eine erste Schnittstelle (301) aufweist, welche dazu ausgestaltet ist, an ein Single Pair Ethernet Hybridkabel angeschlossen zu werden, wobei die Rücksetzeinheit (300) den IoT Knoten (110) oder das loT Gerät zurücksetzt, wenn ungültige Zustände auf der Single Pair Ethernet Hybridleitung vorhanden sind.
  6. Verfahren zur Kommunikation von loT Knoten (110) oder loT Geräten in einem lokalen Netzwerk (100) nach einem der Ansprüche 1 bis 5, wobei
    mindestens einer der loT Knoten (110) oder eines der loT Geräte ein Client-Zertifikat aufweist, in welchem Nutzungsrechte, insbesondere Lese- und/oder Schreibrechte, des loT Knotens (110) oder des loT Gerätes gespeichert sind.
  7. Lokales Internet-of-Things loT Netzwerk (100) mit
    einer Mehrzahl von loT Knoten (110) oder loT Geräten, welche jeweils eine erste Schnittstelle zur Kommunikation in dem lokalen Netzwerk (120) in Form eines Ethernet-Netzwerkes oder eines Single Pair Ethernet-Netzwerkes mit anderen loT Knoten (110) oder einem Computer (130) in dem lokalen Netzwerk aufweisen,
    mindestens einem Computer (130), der zumindest zeitweise mit dem Internet (200) verbunden ist,
    wobei jeder loT Knoten (110) oder jedes loT Gerät einen ersten öffentlichen kryptographischen Schlüssel und einen ersten privaten kryptographischen Schlüssel aufweist, wobei der erste private Schlüssel vorab abgelegt oder von dem loT Knoten (110) oder dem loT Gerät selber erzeugt wird.
    dadurch gekennzeichnet, dass der Computer (130) dazu ausgestaltet ist, IoT Knoten (110) oder loT Geräte in einem lokalen Netzwerk (100) zu authentifizieren durch Senden einer Anfrage nach einem Root-Zertifikat (Z) durch den Computer (130) an einen Root-Zertifikat-Server (210) im Internet (200), der mindestens ein Root-Zertifikat (Z) eines Herstellers der loT Knoten (110) oder der loT Geräte aufweist, durch Empfangen und Speichern des Root-Zertifikats (Z) durch den Computer (130) und durch Überprüfen, durch den Computer (130) anhand des empfangenen Root-Zertifikats (Z), ob die loT Knoten (130) oder loT Geräte originale und unveränderte Geräte sind, wobei das Root-Zertifikat (Z) dazu geeignet ist, den ersten öffentlichen Schüssel der loT Knoten (110) oder loT Geräte mit einer eindeutigen ausschließlich lokal gültigen Adressinformation des loT Knotens (110) oder des loT Gerätes zu verknüpfen,
    wobei der Computer (130) dazu ausgestaltet ist, anhand des gespeicherten Root-Zertifikats (Z) zu überprüfen, ob der erste öffentliche Schlüssel des loT Knotens (110) oder des loT Gerätes durch den Hersteller des IoT Knotens (110) oder des loT Gerätes signiert ist,
    wobei der erste private Schlüssel des loT Knotens (110) oder des loT Gerätes basierend auf einem kryptografischen Verfahren überprüft wird,
    wobei die Mehrzahl von loT Knoten (110) oder loT Geräten Display-los und Bedienungselemente-frei ausgestaltet sind.
  8. Lokales Internet-of-Things loT Netzwerk nach Anspruch 7, ferner mit
    mindestens einer Rücksetzeinheit (300), welche eine erste Schnittstelle (301) aufweist, mittels welcher die Rücksetzeinheit (300) an eine Single Pair Ethernet Hybridleitung koppelbar ist,
    wobei die Rücksetzeinheit (300) dazu ausgestaltet ist, einen angeschlossenen loT Knoten (110) oder ein angeschlossenes loT Gerät zurückzusetzen, wenn ungültige Zustände auf der Single Pair Ethernet Hybridleitung vorhanden sind.
EP22726736.6A 2021-05-06 2022-05-03 Verfahren zur kommunikation von iot knoten oder iot geräten in einem lokalen netzwerk Active EP4335078B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021111841.7A DE102021111841B3 (de) 2021-05-06 2021-05-06 Verfahren zur Kommunikation von IoT Knoten oder IoT Geräten in einem lokalen Netzwerk
PCT/EP2022/061746 WO2022233806A1 (de) 2021-05-06 2022-05-03 Verfahren zur kommunikation von iot knoten oder iot geräten in einem lokalen netzwerk

Publications (3)

Publication Number Publication Date
EP4335078A1 EP4335078A1 (de) 2024-03-13
EP4335078C0 EP4335078C0 (de) 2025-06-18
EP4335078B1 true EP4335078B1 (de) 2025-06-18

Family

ID=81854486

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22726736.6A Active EP4335078B1 (de) 2021-05-06 2022-05-03 Verfahren zur kommunikation von iot knoten oder iot geräten in einem lokalen netzwerk

Country Status (6)

Country Link
US (1) US12401527B2 (de)
EP (1) EP4335078B1 (de)
CN (1) CN117242743A (de)
DE (1) DE102021111841B3 (de)
IL (1) IL308275A (de)
WO (1) WO2022233806A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12197595B2 (en) * 2023-01-12 2025-01-14 nTropy.io, Inc. Batch processing of key generation requests
DE102024102789A1 (de) * 2024-01-31 2025-07-31 Perinet GmbH Verfahren zur Interaktion von IoT Knoten in einem lokalen Netzwerk sowie lokales IoT Knoten-Netzwerk

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10623497B2 (en) * 2016-10-11 2020-04-14 Microsoft Technology Licensing, Llc Leveraging pre-existing groups for IoT device access
US10447665B2 (en) * 2017-03-31 2019-10-15 Konica Minolta Laboratory U.S.A., Inc. IPv6 link local secure network with biometric security to secure IOT devices
CN110770695B (zh) * 2017-06-16 2024-01-30 密码研究公司 物联网(iot)设备管理
US10498750B2 (en) * 2017-09-14 2019-12-03 Zscaler, Inc. Systems and methods for security and control of internet of things and zeroconf devices using cloud services
GB2568873B (en) 2017-11-23 2021-09-22 Advanced Risc Mach Ltd Distributed management system for internet of things devices and methods thereof
WO2019127397A1 (en) * 2017-12-29 2019-07-04 Intel Corporation Technologies for internet of things key management
US10587400B2 (en) 2018-02-12 2020-03-10 Afero, Inc. System and method for securely configuring a new device with network credentials
US11303450B2 (en) * 2018-12-19 2022-04-12 Visa International Service Association Techniques for securely performing offline authentication
EP3681102B1 (de) 2019-01-10 2022-03-16 Siemens Aktiengesellschaft Verfahren zur validierung eines digitalen nutzerzertifikats
US12210726B1 (en) * 2019-01-31 2025-01-28 Concentrix Cvg Customer Management Group Inc. System, method, and application programming interface for implementing cloud-based device control
US10873468B2 (en) * 2019-02-22 2020-12-22 Beyond Identity Inc. Legacy authentication for user authentication with self-signed certificate and identity verification
DE102019126686B4 (de) * 2019-10-02 2022-01-20 Perinet GmbH Verfahren zur Kommunikation mit Internet-of-Things Geräten in einem Netzwerk
US11694149B2 (en) * 2019-10-24 2023-07-04 Afero, Inc. Apparatus and method for secure transport using internet of things (IoT) devices
US11350276B2 (en) * 2020-06-02 2022-05-31 Canadian Internet Registration Authority Secure mobile internet-of-things (IOT) device registry management
US12289417B2 (en) * 2021-02-04 2025-04-29 Fortanix, Inc. Establishing provenance of applications in an offline environment
US20240340188A1 (en) * 2022-08-18 2024-10-10 Cisco Technology, Inc. Independent identity provenance and lineage for certificates

Also Published As

Publication number Publication date
US20240243930A1 (en) 2024-07-18
EP4335078A1 (de) 2024-03-13
EP4335078C0 (de) 2025-06-18
CN117242743A (zh) 2023-12-15
IL308275A (en) 2024-01-01
US12401527B2 (en) 2025-08-26
WO2022233806A1 (de) 2022-11-10
DE102021111841B3 (de) 2022-09-08

Similar Documents

Publication Publication Date Title
DE602004010519T2 (de) Fernzugriffs-vpn-aushandlungsverfahren und aushandlungseinrichtung
EP2494759B1 (de) Verfahren und vorrichtung zum sicheren übertragen von daten
DE602004005461T2 (de) Mobile Authentifizierung für den Netzwerkzugang
DE102004045147A1 (de) Einstellungsinformations-Verteilungsvorrichtung, Verfahren, Programm und Medium, Authentifizierungseinstellungs-Transfervorrichtung, Verfahren, Programm und Medium und Einstellungsinformations-Empfangsprogramm
DE60203277T2 (de) Verfahren und system zur authentifizierung eines personal security device gegenüber mindestens einem fernrechnersystem
EP3582033B1 (de) Verfahren zur gesicherten bedienung eines feldgeräts
EP4335078B1 (de) Verfahren zur kommunikation von iot knoten oder iot geräten in einem lokalen netzwerk
EP4255004A1 (de) Verfahren und system zum onboarding für ein iot-gerät
EP2680497B1 (de) Externer Zugriff auf IP-basierte Haussteuereinheit in lokalem Netzwerk
WO2019242947A1 (de) Verfahren zur anbindung eines endgerätes in eine vernetzbare rechner-infrastruktur
EP3267619B1 (de) Verfahren zur herstellung einer ausfallsicherung in einem netzwerk
EP3432539B1 (de) Verfahren zum aufbau eines kommunikationskanals zwischen einer servereinrichtung und einer clienteinrichtung
EP1496664A2 (de) Vorrichtung und Verfahren sowie Sicherheitsmodul zur Sicherung eines Datenzugriffs eines Kommunikationsteilnehmers auf mindestens eine Automatisierungskomponente eines Automatisierungssystems
EP4054143A1 (de) Authentifizieren eines gerätes in einem kommunikationsnetz einer automatisierungsanlage
EP3937451B1 (de) Verfahren zu herstellung einer verschlüsselten verbindung
EP3537654B1 (de) Verfahren und system zum ermitteln einer konfiguration einer schnittstelle
WO2023217645A1 (de) Abgesichertes zugriffssystem
EP4136824B1 (de) Gerät zum einsatz im internet der dinge
WO2019219333A1 (de) Verfahren und zugangsvorrichtung zum bereitstellen eines datentechnischen zugangs zu einem fahrzeugnetz eines spurgebundenen fahrzeugs
DE102021125836A1 (de) Computernetzwerk für sichere ip-zu-nicht-ip-kommunikation und backend-gerät, gateway, frontend-gerät dafür und verfahren zu dessen betrieb
WO2023285039A1 (de) Verfahren und automatisierungssystem zur einbindung eines automatisierungsgeräts
EP1496665B1 (de) Verfahren zur Festlegung von Sicherheitseinstellungen in einem Automatisierungsnetz
EP3907958A1 (de) Verfahren zum aufbau eines sicheren übertragungskanals zur datenübermittlung innerhalb eines industriellen automatisierungssystems
EP4597932A1 (de) Verfahren zur interaktion von iot knoten in einem lokalen netzwerk sowie lokales iot knoten-netzwerk
EP4280647A1 (de) Provisionieren von endgeräten in funkkommunikationsnetzen

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: 20231206

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 MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

INTG Intention to grant announced

Effective date: 20241118

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTC Intention to grant announced (deleted)
INTG Intention to grant announced

Effective date: 20241223

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

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 MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502022004336

Country of ref document: DE

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

U01 Request for unitary effect filed

Effective date: 20250618

U07 Unitary effect registered

Designated state(s): AT BE BG DE DK EE FI FR IT LT LU LV MT NL PT RO SE SI

Effective date: 20250626

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250918

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250919

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250618

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250918

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20251018

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250618

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250618

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250618

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250618

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250618

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

REG Reference to a national code

Ref country code: CH

Ref legal event code: L10

Free format text: ST27 STATUS EVENT CODE: U-0-0-L10-L00 (AS PROVIDED BY THE NATIONAL OFFICE)

Effective date: 20260430