METHOD FOR COMMUNICATION OF IOT NODES OR IOT DEVICES IN A LOCAL NETWORK

Description

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

[0002] To improve automation, more and more network-capable sensors and actuators are being used. Such networks are referred to as the Internet of Things (IoT) or the Industrial Internet of Things (IoT). Communication between the sensors and actuators is typically based on an IP protocol. These sensors and actuators can be deployed in a local network (smart home or in a factory). Alternatively, these IoT sensors and actuators can also be directly connected to the Internet.

[0003] Especially when using IoT sensors in a local network, the security of internal communication must be guaranteed.

[0004] In the priority-establishing German patent application, the German Patent and Trademark Office searched the following documents: US 2020 / 0259667 A1 and WO 2020 / 143982 A1.

[0005] US 2019 / 253243 A1 discloses 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 comprises 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.

[0006] DE 10 2019 126 686 A1 relates to a method for communicating with Internet of Things devices in a network. For this purpose, 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, with the address representing an IPV6 link local address of the IoT device.

[0007] It is therefore an object of the present invention to enable a method for communication of IoT nodes or IoT devices in a local network with improved security.

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

[0009] Thus, a method is provided 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) is an Ethernet network or a Single Pair Ethernet network. The IoT nodes or IoT devices are designed without displays and control elements. They also 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 when the computer sends 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 IoT nodes or IoT devices present in the local network are 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 in the local network.The computer uses the stored root certificate to verify 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.

[0010] Address information that is valid exclusively within 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 achieved indirectly with the help of the manufacturer of the IoT nodes or devices. Furthermore, the effort required for authentication increases because the routable network names are managed by the administrator 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 on the local network, IoT sensors or devices can be configured automatically and independently within the local network. The unique local address information can, for example, be an IPv6 Link Local Address or a Multicast Domain Name Service network name.

[0011] According to one aspect of the present invention, after receiving and saving the root certificate, the computer 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.

[0012] According to one aspect of the invention, 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.

[0013] Thus, there is neither a display nor a control element or input element. Settings and parameters can be changed or adjusted, for example, via a browser on the computer 130.

[0014] 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 has a computer that is at least partially connected to the Internet. Each IoT node or 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 device itself.The computer is designed 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 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, 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 suitable for linking 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 configured to use the stored root certificate to verify whether the first public key of the IoT node or IoT device 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 procedure.

[0015] Further embodiments of the invention are the subject of the subclaims.

[0016] Advantages and embodiments of the invention are explained in more detail below with reference to the drawing. Fig. 1 shows a schematic representation of a local network according to a first embodiment of the invention, Fig. 2 shows an enlarged view of a part of the local network of Fig. 1 , Fig. 3 shows a schematic representation of the local network of Fig. 1 during the checking of the IoT nodes present in the local network, Fig. 4 shows a schematic representation of a local network according to a second embodiment, and Fig. 5 shows a schematic representation of a reset unit according to an embodiment of the invention.

[0017] 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. Furthermore, 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. According to the first exemplary embodiment, 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.

[0018] According to the first embodiment, 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.).

[0019] The first embodiment of the invention thus particularly relates to providing internal security for the local network 100. In particular, 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. In particular, 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.

[0020] According to the first embodiment, automatic authentication (in the sense of a zero-configuration network) of existing or newly added IoT nodes is to be implemented. 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.

[0021] This also enables automated machine-to-machine communication in local networks with a very high number of IoT nodes 110.

[0022] According to the first exemplary embodiment, 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. This is achieved by relocating all security mechanisms to the local network without the need for an active Internet connection for authentication. To this end, 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.

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

[0024] 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. After the active Internet connection of the computer 130 to the Internet 200 has been disconnected, 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.

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

[0026] To verify the IoT nodes 110, 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. For example, 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. The advantage of the authentication of the IoT nodes 110 described above is that this can be done without an active internet connection and can therefore be done anonymously and offline.

[0027] This ensures device attestation, i.e. verification of the IoT nodes 110.

[0028] 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 Thus, a plurality of IoT nodes 110 are coupled to one another and to a computer 130 via a network 120. In the second exemplary embodiment, those IoT nodes 110 which functionally belong together are to be combined to form virtual local networks 101, 102. This is achieved 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. Such virtual local networks can be put together depending on the required application. According to the second exemplary embodiment, a second cryptographic key pair can be generated in the IoT node 110 or loaded onto the IoT node 110 for this purpose. 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, the PKI certificate can be used as a host certificate. Using this host certificate, other IoT nodes 110 in the network can verify the node's identity and establish encrypted communication if necessary.

[0029] In a further example based on the second embodiment, the IoT node 110 can function both as a server and as a client. In this case, the IoT node 110 can function, for example, as a Message Queuing Telemetry Transport MQTT subscriber / publisher (client) or broker (server) or HTTP server. In this case, 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. In this case, 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.

[0030] According to the second embodiment, a local PKI can be provided for M2M (machine-to-machine) communication based on mTLS (Mutual Transport Layer Security).

[0031] According to one aspect of the second embodiment, 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).

[0032] According to one aspect of the present invention, 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. For example, a human user can identify themselves within the local PKI structure using a device (Secure Stick) independent of the IoT node 110 used.

[0033] According to one aspect of the present invention, the local root PKI instance may represent an IoT node 110. Thus, such 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.

[0034] According to one aspect of the present invention, 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. Thus, 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.

[0035] According to a further aspect of the present invention, 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.

[0036] According to one embodiment of the invention, 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. Such a packet is typically invalid but can contain individual information of the node. Advantageously, in an 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.

[0037] Thus, according to the invention, 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.

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

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

[0040] Fig. 5shows 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. By means of 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 conditions is a supply voltage that is too low in the absence of a T1 link. The IoT 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.With regard to the security feature "obtaining access rights by fraud," the use of second key pairs generated on the IoT node is particularly advantageous, as these cannot be restored after a reset. Furthermore, after a reset, the IoT node 110 must always be reintegrated into a virtual local network, which means that the operator of the virtual local network is always aware of the reset process.

[0041] By resetting the node according to the invention, all key pairs and certificates of the node can be deleted. This means that the IoT node can neither be registered with a server of the local PKI structure, nor can a client access this reset IoT node. This ensures that a firmware reset or the resulting possibility of unauthorized access to the local network cannot occur unnoticed. Instead, the node must be reintroduced into the network environment.

[0042] According to one aspect of the present invention, 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.

[0043] According to one aspect of the present invention, the authenticity of an IoT node can be verified using local address information (e.g., an mdns hostname) and a device-specific private key.

[0044] According to one aspect of the present invention, 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.

[0045] According to one aspect of the present invention, 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.

[0046] According to one aspect of the present invention, the IoT nodes can represent network-capable smart home devices or building automation devices.

Claims

1. Method for communication of loT nodes (110) or loT devices in a local network (100), which is at least temporarily connected to the Internet (200) solely via a computer (130), wherein the local network (100) is an Ethernet network or a single pair Ethernet network, wherein the loT nodes (110) or the loT devices each have a first interface for communication in the local network (120) with other loT nodes (110) or with the computer (130), wherein each loT node (110) or each loT device has a first public cryptographic key and a first private cryptographic key, the first private key being stored in advance or generated by the loT node (110) or the loT device itself, having the step: authentication of IoT nodes (110) or loT devices in a local network (100), characterized by - sending a request for a root certificate (Z) to a root-certificate server (210) on the Internet (200) by means of the computer (130), said root-certificate server having at least one root certificate (Z) from a manufacturer of the loT nodes (110) or the loT devices, - receiving and storing the root certificate (Z) by means of the computer (130), and - checking by means of the computer (130) whether the loT nodes (130) or loT devices are original and unmodified devices by using the received root certificate (Z), wherein the root certificate (Z) is suitable for linking the first public key of the loT nodes (110) or loT devices to unique address information of the loT node (110) or the loT device that is valid exclusively in the local network, wherein the computer (130) uses the stored root certificate (Z) to check whether the public key of the loT node (110) or the loT device is signed by the manufacturer of the loT node (110) or the loT device, wherein the first private key of the loT node (110) or the loT device is checked based on a cryptographic method, wherein the loT nodes (110) or the loT devices are designed to be display-free and operating-element-free.

2. Method for communication of loT nodes (110) or loT devices in a local network (100) according to Claim 1, wherein after receiving the root certificate (Z) from the root-certificate server (210), the computer (130) disconnects from the Internet (200) before the loT nodes (110) or the IoT device are checked.

3. Method for communication of loT nodes (110) or loT devices in a local network (100) according to Claim 1 or 2, wherein each loT node (110) or loT device has a local and unique host name, in particular an IPv6 link local address or a multicast domain name system mDNS network name.

4. Method for communication of loT nodes (110) or loT devices in a local network (100) according to any of Claims 1 to 3, having the additional steps: integrating loT nodes (110) or loT devices into a virtual local network (101, 102) in the form of a local public-key infrastructure, wherein each of these loT nodes (110) or loT devices is assigned a second cryptographic key pair.

5. Method for communication of loT nodes (110) or loT devices in a local network (100) according to any of Claims 1 to 4, having the additional steps: resetting an IoT node (110) or an loT device by means of a reset unit (300), which has a first interface (301) designed to be connected to a single pair Ethernet hybrid cable, wherein the reset unit (300) resets the loT node (110) or the loT device if invalid states occur on the single pair Ethernet hybrid line.

6. Method for communication of loT nodes (110) or loT devices in a local network (100) according to any of Claims 1 to 5, wherein at least one of the loT nodes (110) or one of the loT devices has a client certificate in which usage rights, in particular read and / or write rights, of the loT node (110) or the loT device are stored.

7. Local Internet-of-Things loT network (100) having a plurality of loT nodes (110) or loT devices, which each have a first interface for communication in the local network (120) in form of an Ethernet-network or a single pair Ethernet network with other loT nodes (110) or a computer (130) in the local network, at least one computer (130) which is at least temporarily connected to the Internet (200), wherein each loT node (110) or each loT device has a first public cryptographic key and a first private cryptographic key, the first private key being stored in advance or generated by the loT node (110) or the loT device itself, characterized in that the computer (130) is designed to authenticate loT nodes (110) or loT devices in a local network (100) by sending a request for a root certificate (Z) by means of the computer (130) to a root-certificate server (210) on the Internet (200), said root-certificate server having at least one root certificate (Z) of a manufacturer of the loT nodes (110) or the loT devices, by receiving and storing the root certificate (Z) by means of the computer (130) and by checking by means of the computer (130) whether the loT nodes (130) or loT devices are original and unmodified devices by using the received root certificate (Z), wherein the root certificate (Z) is suitable for linking the first public key of the loT nodes (110) or loT devices to unique address information of the loT node (110) or the loT device that is valid exclusively in the local network, wherein the computer (130) is designed to use the stored root certificate (Z) to check whether the first public key of the loT node (110) or the loT device is signed by the manufacturer of the loT node (110) or the loT device, wherein the first private key of the loT node (110) or the loT device is checked based on a cryptographic method, wherein the plurality of loT nodes (110) or loT devices are designed to be display-free and operating-element-free.

8. Local Internet-of-Things IoT network according to Claim 7, also having at least one reset unit (300) which has a first interface (301), by means of which the reset unit (300) can be coupled to a single pair Ethernet hybrid line, wherein the reset unit (300) is designed to reset a connected loT node (110) or a connected IoT device if invalid states occur on the single pair Ethernet hybrid line.