Methods and systems for onboarding IoT devices

Abstract

Method and system for onboarding of IoT devices. A method for onboarding of IoT devices (3) of a manufacturer in an infrastructure of a customer in a way that is protected against quantum computer attacks by means of a first server (1) of a manufacturer domain of the manufacturer and a second server (2) of a customer domain of the customer is proposed, wherein the IoT devices are provided with a device certificate of the customer domain on the IoT devices (3) using three authenticated and encrypted communication channels and a key encapsulation method.

Description

Technical Field

[0001] This invention relates to a method and computer program product for loading a manufacturer's IoT (Internet of Things) device into a customer's infrastructure using a first server in the manufacturer's domain and a second server in the customer's customer domain. Furthermore, this invention relates to a system for loading a manufacturer's IoT device into a customer's infrastructure. Background Technology

[0002] An example of loading IoT devices into a customer's infrastructure is zero-touch device onboarding. Zero-touch device onboarding is an automated process in which credentials (e.g., X.509 public key certificates) and configuration settings are installed on the IoT device without the intervention of service technicians. Such onboarding can also be referred to as provisioning or bootstrapping. This process requires sufficiently strong security features to ensure that only the correct IoT devices are reliably used in the new domain, i.e., the customer's domain. For the onboarding process, especially regarding communication between three parties:

[0003] 1. An IoT device, with credentials and configuration settings installed on the IoT device;

[0004] 2. The first server in the manufacturer's domain of the IoT device manufacturer. This first server, also known as the device licensor, is provided by the IoT device manufacturer and serves as a guarantor of the authenticity or originality of the IoT device, while also providing trusted information about the client domain.

[0005] 3. A second server within the customer's customer domain, where the loading of IoT devices should take place. This second server, also known as a domain loading authority, is run by the customer of the IoT devices and will output credentials and / or configuration data for the IoT devices, or possess such credentials and / or configuration data.

[0006] With existing network connectivity, the IoT device, which has not yet undergone loading, connects to a second server, if necessary, after the Discovery-Prozedur process, to determine the network address of the second server. The second server then connects to a first server in the manufacturer's domain. If the originality of the IoT device is successfully verified, the second server provides the IoT device with a device certificate, which specifically includes credentials and configuration settings from the customer's domain. The IoT device can then install this device certificate locally, particularly when tracing its trust relationship with the first server. Thus, the loading process typically concludes successfully.

[0007] This loading process is currently based on encrypted connections, such as TLS (Transport Layer Security) or object-related security, which ensures the confidentiality and integrity of the data and the authenticity of the parties involved in the communication.

[0008] To verify the authenticity of IoT devices relative to a second or first server, cryptographic signature methods are traditionally used for authentication. The second server, or a service implemented by the second server, typically issues digital device certificates to the IoT devices, which the IoT devices can then use to authenticate themselves via cryptographic signature methods after being loaded.

[0009] The security of current asymmetric cryptography, used for communication during the loading of IoT devices and for verifying the authenticity of IoT devices, will be vulnerable to attack with a high probability in the future using highly efficient quantum computers.

[0010] Therefore, there is a need to load data onto IoT devices that are secure against quantum computer attacks and, in particular, efficient. Summary of the Invention

[0011] In this context, the objective of this invention is to improve the loading of manufacturers' IoT devices into customers' infrastructure.

[0012] According to the first aspect, a method is proposed for loading a manufacturer's IoT (Internet of Things) device into a customer's infrastructure using a first server in the manufacturer's domain and a second server in the customer's customer domain. The method includes the following steps, specifically using the KEM (Key Encapsulation Mechanism):

[0013] a) Establishing an authenticated and encrypted first communication channel between the first server and the second server, including deriving a session key shared by the first server and the second server.

[0014] b) Providing an authenticated and encrypted second communication channel between the IoT device and the second server, including deriving a second session key shared by the second server and the IoT device.

[0015] c) Establish an authenticated and encrypted third communication channel between the IoT device and the first server, operating via the second server, wherein a third key shared by the IoT device and the first server is allocated to the authenticated and encrypted third communication channel.

[0016] d) Authorization information is generated through the IoT device.

[0017] e) The authorization information constituted by the IoT device using the third key pair is protected cryptographically.

[0018] f) The password-protected authorization information is transmitted from the IoT device to the second server via the second communication channel.

[0019] g) The password-protected authorization information is transmitted from the second server to the first server via the first communication channel.

[0020] h) The first server decrypts the cryptographically protected authorization information transmitted from the second server to the first server using the third key.

[0021] i) The decrypted authorization information is encrypted by the first server using the first session key and preferably equipped with integrity protection.

[0022] j) The authorization information, encrypted using the first session key and preferably protected by integrity, is transmitted from the first server to the second server via the first communication channel.

[0023] k) The authorization information encrypted using the first session key is decrypted by the second server, and preferably, an integrity check is performed.

[0024] 1) A request to obtain a device certificate for the customer domain assigned to the IoT device is sent from the second server to a certification authority, specifically for the customer domain.

[0025] m) The obtained device certificate, along with the configuration data of the preferred client domain and the authorization information decrypted by the second server, are transmitted from the second server to the IoT device via the second communication channel.

[0026] n) If the authorization information transmitted from the second server corresponds to the constituted authorization information, then the IoT device accepts the device certificate transmitted from the second server and, if necessary, the configuration data of the customer domain.

[0027] This creates a method for loading a manufacturer's IoT device into a customer's infrastructure in a quantum computer-resistant manner, using a first server in the manufacturer's domain and a second server in the customer's customer domain. The method involves providing the IoT device with a device certificate in the customer domain using three certified and encrypted communication channels and key encapsulation methods.

[0028] Current onboarding, particularly zero-touch device onboarding, is an automated process requiring no intervention from service technicians. In this process, the customer domain's device certificate is transmitted to, and specifically accepted and installed by, the IoT device. Other configuration settings and / or credentials may be installed on the IoT device along with or after the device certificate.

[0029] The KEM method is also known as the key encapsulation mechanism (KEM). The method used for loading can also be called a loading method, device loading method, or process. Compared to traditional solutions, this device loading method, especially in terms of signature verification, primarily uses certificate signature verification. Enhanced protection against quantum computer attacks is achieved by mainly using a KEM-based approach. Currently, only signature verification is performed within the scope of certificate verification.

[0030] This device loading method offers the following technical advantages: no signature generation method is required outside of a certification authority (also known as a Certification Authority). Therefore, advantageously, there is no need for secure management of private signing keys outside of a certification authority, as private signing keys are not required and therefore secure storage is also unnecessary. Furthermore, advantageously, there is currently no need to implement a signature generation method, as it is not currently used. This results in a smaller codebase. Therefore, if the signature generation method or its implementation is affected by future attacks or bugs, the current device loading method remains unaffected.

[0031] If an error occurs during the execution of steps a) to n), the method is preferably aborted and restarted.

[0032] According to one implementation, the authenticated and encrypted first communication channel and / or the authenticated and encrypted second communication channel are cryptographically protected by means of the KEM method.

[0033] By using the KEM method for cryptographic protection, this approach becomes particularly advantageous in terms of post-quantum methods and resistance to quantum computer attacks.

[0034] Because the KEM method typically outperforms signature methods, its performance advantage can be derived. Furthermore, the current loading method can be made secure against quantum computer attacks quite easily by using post-quantum KEM. Post-quantum KEM is currently standardized by the US NIST (National Institute of Standards and Technology). Therefore, the current loading method can also be viewed as a post-quantum device loading process. Moreover, hybrid (pre-quantum and post-quantum) KEM methods can be flexibly used. Therefore, this method can also be referred to as a hybrid pre- / post-quantum device loading process.

[0035] After successfully executing step n), the IoT device is set up for communication within the client domain, i.e., the loading is successfully completed. Optionally, the IoT device can use the established device certificate, especially the KEMTLS device certificate, to establish a KEMTLS connection to the second server. This allows the second server to check whether the loading of the IoT device has been successfully completed.

[0036] By having only the first server able to determine the authorization information (which is, for example, constructed as a one-time random number (https: / / en.wikipedia.org / wiki / Cryptographic_nonce)), and through appropriate verification and authentication, as well as protected communication channels (currently the first, second, and third communication channels), the IoT device gains its trust in the new domain, currently the client domain.

[0037] Through various verifications, and especially through a second server that can verify the belonging device certificate during channel establishment, particularly KEMTLS channel establishment, and can cross-verify the identity information contained therein, for example, against a list, the second server gains its trust in the IoT device.

[0038] The first server can verify through an authenticated key exchange whether the second server can present an encrypted string (in this case, password-protected authorization information) of the authorized IoT device.

[0039] According to another implementation, KEMTLS is used as the KEM method. KEMTLS is a communication protocol designed as an extension for TLS 1.3, and uses a KEM-based method instead of a signature method for authentication and for key exchange.

[0040] Similar to traditional TLS, KEMTLS establishes an authenticated and encrypted communication channel. However, it uses different cryptographic primitives internally: KEM replaces digital signatures and replaces the traditional key exchange method.

[0041] According to another embodiment, an authenticated and encrypted third communication channel is configured as a direct communication channel between the IoT device and the first server.

[0042] According to another embodiment, the authenticated and encrypted third communication channel is constructed as a tunneled communication channel by means of tunneling via the authenticated and encrypted first communication channel and the authenticated and encrypted second communication channel, wherein the second server is used as a forwarding instance, especially given that steps f) and g) are used.

[0043] According to another embodiment, before performing step a), the first server is equipped with a root certificate for the manufacturer's domain, a root certificate for the client's domain, a user certificate for the manufacturer's domain of the first server, and a private key for the first server, wherein the user certificate for the manufacturer's domain of the first server includes the public key of the first server. Before performing step a), the second server is equipped with a root certificate for the manufacturer's domain, a root certificate for the client's domain, a user certificate for the client's domain of the second server, and a private key for the second server, wherein the user certificate for the client's domain of the second server includes the public key of the second server in the client's domain. Before performing step b), the IoT device is equipped with a root certificate for the manufacturer's domain, a user certificate for the manufacturer's domain of the IoT device, and a private key for the IoT device, wherein the user certificate for the manufacturer's domain of the IoT device includes the public key of the IoT device in the manufacturer's domain.

[0044] According to another embodiment, the first session key is known to the first server and the second server, but unknown to the IoT device. The second session key is preferably known to the second server and the IoT device, but unknown to the first server. The third key is preferably known to the first server and the IoT device, but unknown to the second server.

[0045] According to another embodiment, step d) includes generating a random number or quasi-random number from the IoT device as authorization information.

[0046] For example, IoT devices generate one-time random numbers as authorization information. IoT devices are the executors and locations that generate one-time random numbers.

[0047] According to another embodiment, step m) is constructed by: transmitting the obtained device certificate and the authorization information from the second server to the IoT device via the second communication channel within a single session, wherein the authorization information is preferably transmitted from the second server to the IoT device via the second communication channel as part of the certificate extension of the device certificate.

[0048] The hash value of the root certificate of the client domain is preferably transmitted from the first server to the IoT device. In particular, the hash value of the root certificate, together with the authorization information, is encrypted by the first server using a key encapsulation method based on the public KEM key of the IoT device, and transmitted to the IoT device as an extended component of the authorization information.

[0049] The second server preferably sends the cryptographic hash value of the root certificate that it wants to use for the IoT device to the first server. The first server can then transmit this hash value to the IoT device after verification, specifically by encrypting the hash value for the IoT device, including other shared secrets, and sending it back to the second server, which then transmits the message to the IoT device. This provides the IoT device with another verification possibility for the root certificate used in the client domain.

[0050] According to another embodiment, the cryptographically protected authorization information transmitted in steps f) and g) is constructed as a KEM-protected protocol message.

[0051] According to another embodiment, the authenticated and encrypted second communication channel is terminated or invalidated after step m).

[0052] According to another implementation, the IoT device is only allowed to load exactly one set of configuration data based on the constructed authorization information, the configuration data including the device certificate.

[0053] According to another embodiment, the first server, the second server, and the IoT device are each equipped with a KEM-based protocol stack. Here, the KEM-based protocol stack of the IoT device is preferably additionally equipped with provisional-acceptability features. The KEM-based protocol stack is preferably configured to implement KEMTLS or KEMTLS-PDK.

[0054] Temporary acceptance is a mechanism from RFC 8995, where a secure channel is established based on a certificate, with the sole exception that the client (in this case, the IoT device) allows a specific error when initially verifying the server certificate. This error is that the trusted root certificate, in this case, the root certificate of the client domain, is not present in the trusted root certificate's memory. Afterward, arbitrary communication is not permitted through this established channel; instead, a simplified process using a linear automaton is followed (see [reference needed] for this). Figure 2 (Detailed description). Once an error occurs within the scope of the described process or once the process deviates from the described process, the communication channel is dismantled, and the client (here, the IoT device) is placed in the state that the client already had before the communication channel was established (so-called rollback).

[0055] After successfully executing step n), the IoT device preferably parses the temporary acceptance and transfers the device certificate, especially the KEMTLS device certificate, to its persistent storage. Optionally, other certificates, especially certificate chains or the assigned root certificate, or other configuration settings and / or configuration information, may also be written to the persistent storage by the IoT device. The assigned root certificate may be marked as trusted.

[0056] According to another embodiment, step c) is constructed by establishing an authenticated and encrypted third communication channel between the IoT device and the first server via the second server, the establishment including deriving a third session key shared by the IoT device and the first server.

[0057] According to another embodiment, prior to performing step c), a separate PIN (or PIN code) for the device is securely stored in both the first server and the IoT device. Here, the PIN is used to establish an authenticated and encrypted third communication channel operating via the second server.

[0058] Here, the authorization information and PIN are preferably encrypted using the KEM method described above, thereby preferably directly constituting a secret protected by encapsulation. In this case, it is preferable to use not only the KEM method but also the PKE method (Public Key Encryption). The PIN is confidentially stored not only by the first server but also within the IoT device. In the implementation, the first server uses a master key method to derive the device's individual PIN in order to minimize the amount of data to be confidentially stored.

[0059] According to the second aspect, a computer program product is proposed that causes execution, on a program-controlled device, of the method as described above according to the first aspect or one of the embodiments of the first aspect.

[0060] Computer program products, such as computer program devices, can be provided or supplied by a server on a network, for example, as storage media, such as memory cards, USB sticks, CD-ROMs, DVDs, or also as downloadable files. This can be done, for example, by transmitting the corresponding files using the computer program product or computer program device over a wireless communication network.

[0061] According to a third aspect, a system is proposed for loading a manufacturer's IoT device into a customer's infrastructure. The system includes a first server in the manufacturer's manufacturer domain and a second server in the customer's customer domain, wherein the first server, the second server, and the IoT device are configured to perform a method according to the first aspect or one of the embodiments of the first aspect.

[0062] The implementation methods and features described for the proposed method are accordingly applicable to the proposed system.

[0063] Other possible embodiments of the invention include combinations of features or implementations not explicitly mentioned in the preceding or following descriptions of the embodiments. Those skilled in the art will also add unilateral aspects as improvements or additions to the corresponding basic forms of the invention. Attached Figure Description

[0064] Other advantageous designs and aspects of the invention are the subject of the dependent claims and the embodiments described below. The invention will be further described in more detail with reference to the accompanying drawings and preferred embodiments.

[0065] Figure 1 A schematic flowchart illustrating an embodiment of a method for loading a manufacturer's IoT device into a customer's infrastructure; and

[0066] Figure 2A schematic communication diagram illustrating an embodiment of a system for loading data for IoT devices.

[0067] Unless otherwise specified, the same or equivalent elements in the figures are equipped with the same reference numerals. Detailed Implementation

[0068] Figure 1 A schematic flowchart illustrating an embodiment of a method for loading a manufacturer's IoT device 3 into a customer's infrastructure using a first server 1 in the manufacturer's manufacturer domain and a second server 2 in the customer's customer domain. (Refer to...) Figure 2 Explanation Figure 1 An example of this. In this case, Figure 2 A schematic communication diagram illustrating an embodiment of a system for loading IoT device 3.

[0069] Figure 2 The communication diagram illustrates the communication and channel structure between the first server 1, the second server 2, and the IoT device 3.

[0070] according to Figure 1 The method includes steps S1 to S14. These steps S1 to S14 also... Figure 2 The diagram illustrates the process. Before executing steps S1 to S14, the first server 1 is equipped with a root certificate Z1 for the manufacturer's domain, a root certificate Z2 for the client's domain, a user certificate Z5 for the manufacturer's domain of the first server 1, and a private key P1 for the first server 1. The user certificate Z5 includes the public key of the first server 1. The second server 2 is equipped with a root certificate Z1 for the manufacturer's domain, a root certificate Z2 for the client's domain, a user certificate Z4 for the client's domain of the second server 2, and a private key P2 for the second server 2. The user certificate Z4 includes the public key of the second server 2 in the client's domain. The IoT device 3 is equipped with a root certificate Z1 for the manufacturer's domain, a user certificate Z3 for the manufacturer's domain of the IoT device 3, and a private key P3 for the IoT device 3. The user certificate Z3 includes the public key of the IoT device 3 in the manufacturer's domain.

[0071] In particular, the first server 1, the second server 2, and the IoT device 3 are each equipped with a KEM-based protocol stack. In this case, the KEM-based protocol stack of the IoT device 3 is preferably additionally equipped with suitability for provisional acceptance. The KEM-based protocol stack is specifically designed for implementing KEMTLS or KEMTLS-PDDK and is particularly used to perform operations according to... Figure 1 and 2 The method.

[0072] Now regarding the basis Figure 1 and 2The process flow of steps S1 to S14:

[0073] In step S1, an authenticated and encrypted first communication channel KK1 is established between the first server 1 and the second server 2. This establishment specifically includes deriving a session key K1 shared by the first server 1 and the second server 2 (see [link to documentation]). Figure 2 ).

[0074] In step S2, an authenticated and encrypted second communication channel KK2 is provided between the IoT device 3 and the second server 2. This provision specifically includes deriving a second session key K2 shared by the second server 2 and the IoT device 3 (see [link to documentation]). Figure 2 The authenticated and encrypted first communication channel KK1 and / or the authenticated and encrypted second communication channel KK2 are preferably cryptographically protected by means of the KEM method. For example, KEMTLS is used as the KEM method.

[0075] The first session key K1 is known, in particular, to the first server 1 and the second server 2, but is unknown to the IoT device 3 (see [link]). Figure 2 K1 in the middle).

[0076] The second session key K2 is known to the second server 2 and IoT device 3, but unknown to the first server 1 (see [link]). Figure 2 (K2 in the middle).

[0077] In step S3, an authenticated and encrypted third communication channel KK3, operating via the second server 2, is established between the IoT device 3 and the first server 1. A third key K3 shared by the IoT device 3 and the first server 1 is assigned to the third communication channel KK3 (see [link to documentation]). Figure 2 The third key K3 is known to the first server 1 and IoT device 3, but is unknown to the second server 2.

[0078] For example, an authenticated and encrypted third communication channel KK3 is constructed as a direct communication channel between IoT device 3 and first server 1. Alternatively—and as… Figure 2 As shown in the example, the third communication channel KK3 is constructed as a tunneled communication channel by means of tunneling via the authenticated and encrypted first communication channel KK1 and the authenticated and encrypted second communication channel KK2. In this case, the second server 2 is then used as a forwarding instance.

[0079] In particular, the third key K3 can also be constructed as a session key K3. In this case, the steps of establishing an authenticated and encrypted third communication channel KK3 between the IoT device 3 and the first server via the second server 2 may include deriving a third session key K31 shared by the IoT device 3 and the first server.

[0080] In step S4, authorization information BI is constructed using IoT device 3. IoT device 3 is the executor and location for constructing authorization information BI. In particular, random numbers or quasi-random numbers, such as one-time random numbers, are constructed by IoT device 3 as authorization information BI1.

[0081] In step S5, the constructed authorization information BI is cryptographically protected by the IoT device 3 using a third key K3, specifically encrypted. Cryptographic protection includes integrity protection, authenticity protection, and confidentiality protection.

[0082] In step S6, the password-protected authorization information BI2 is transmitted from the IoT device 3 to the second server 2 via the second communication channel KK2.

[0083] In step S7, the password-protected authorization information BI2 is transmitted from the second server 2 to the first server 1 via the first communication channel KK1. The password-protected authorization information BI2 transmitted in steps S6 and S7 is preferably constructed as a KEM-protected protocol message.

[0084] In step S8, the password-protected authorization information BI2 transmitted from the second server 2 to the first server 1 is decrypted by the first server 1 using the third key K3 to provide the decrypted authorization information BI3.

[0085] In the next step S9, the provided authorization information BI3 is encrypted by the first server 1 using the first session key K1.

[0086] In step S10, the authorization information BI4, encrypted using the first session key K1, is transmitted from the first server 1 to the second server 2 via the first communication channel KK1.

[0087] In step S11, the authorization information BI4 encrypted using the first session key K1 is decrypted by the second server 2, so that the decrypted authorization information BI5 exists at the second server 2.

[0088] In step S12, the second server 2 sends a request A for obtaining a device certificate Z6 assigned to the customer domain of the IoT device 3 to the certification authority 4, which is preferably assigned to the customer domain.

[0089] After obtaining device certificate Z6, the second server 2 transmits device certificate Z6 and authorization information BI5, decrypted by the second server, to IoT device 3 via the second communication channel KK2. Here, device certificate Z6 obtained from certification authority 4 is preferably transmitted from the second server 2 to IoT device 3 together with authorization information BI5 within a single session via the second communication channel KK2, wherein authorization information BI5 is preferably transmitted as part of the certificate extension of device certificate Z6.

[0090] Preferably, the hash value of the root certificate Z2 of the client domain is additionally and cryptographically protected and transmitted from the first server 1 to the IoT device 3. The transmitted hash value of the root certificate Z2 can be used by the IoT device 3 to authenticate the second server 2.

[0091] The authenticated and encrypted second communication channel KK2 is preferably terminated or invalidated after step S13.

[0092] In step S14, if the authorization information BI5 transmitted from the second server 2 corresponds to the authorization information BI1 constructed at the IoT device 3 in step S4 and allows the root certificate Z2 of the client domain to be temporarily accepted for resolution, then the device certificate Z6 transmitted from the second server 2 is accepted by the IoT device 3. Therefore, the IoT device 3 stores the authorization information BI1 constructed in step S4 in its storage unit.

[0093] Based on the constructed authorization information BI1, IoT device 3 preferably allows only exactly one set of configuration data to be loaded, the configuration data including device certificate Z6. Then, i.e., after step S14, the constructed authorization information BI1 is preferably invalidated.

[0094] Although the invention has been described with reference to embodiments, various modifications may be made to the invention.

Claims

1. A method for loading a manufacturer's IoT device (3) into a customer's infrastructure using a first server (1) in the manufacturer's manufacturer domain and a second server (2) in the customer's customer domain, the method comprising: a) Establishing (S1) an authenticated and encrypted first communication channel (KK1) between the first server (1) and the second server (2), including deriving a first session key shared by the first server (1) and the second server (2), b) Providing (S2) an authenticated and encrypted second communication channel (KK2) between the IoT device (3) and the second server (2), including deriving a second session key (K2) shared by the second server (2) and the IoT device (3), c) Establish (S3) an authenticated and encrypted third communication channel (KK3) operating via the second server (2) between the IoT device (3) and the first server (1), and allocate a third key (K3) shared by the IoT device (3) and the first server (1) to the authenticated and encrypted third communication channel. d) Authorization information (BI1) is generated by the IoT device (3) (S4). e) The IoT device (3) protects the constructed authorization information (BI1) in a cryptographic manner by means of the third key (K3) (S5). f) The password-protected authorization information (BI2) is transmitted from the IoT device (3) to the second server (2) via the second communication channel (KK2) (S6). g) The password-protected authorization information (BI2) is transmitted from the second server (2) to the first server (1) via the first communication channel (KK1) (S7). h) The first server (1) decrypts the password-protected authorization information (BI2) transmitted from the second server (2) to the first server (1) by means of the third key (K3) (S8). i) The decrypted authorization information (BI3) is encrypted by the first server (1) using the first session key (K1) (S9). j) The authorization information (BI4) encrypted using the first session key (K1) is transmitted from the first server (1) to the second server (2) via the first communication channel (KK1) (S10). k) The authorization information (BI4) encrypted using the first session key (K1) is decrypted by the second server (2) (S11). l) A request (A) for obtaining a device certificate (Z6) for the customer domain assigned to the IoT device (3) is sent from the second server (2) to the certification authority (4) (S12). m) The obtained device certificate (Z6) and the authorization information (BI5) decrypted by the second server (2) are transmitted from the second server (2) to the IoT device (3) via the second communication channel (KK2) (S13), and n) If the authorization information (BI5) transmitted from the second server (2) corresponds to the constituted authorization information (BI1), then the device certificate (Z6) transmitted from the second server (2) is accepted (S14) by the IoT device (3).

2. The method according to claim 1, characterized in that, The authenticated and encrypted first communication channel (KK1) and / or the authenticated and encrypted second communication channel (KK2) are cryptographically protected by means of the KEM method.

3. The method according to claim 2, characterized in that, KEMTLS is used as the KEM method.

4. The method according to any one of claims 1 to 3, characterized in that, The authenticated and encrypted third communication channel (KK3) is configured as a direct communication channel between the IoT device (3) and the first server (1), or The authenticated and encrypted third communication channel (KK3) is constructed as a tunnel communication channel by means of tunneling through the authenticated and encrypted first communication channel (KK1) and the authenticated and encrypted second communication channel (KK2), wherein the second server (2) is used as a forwarding instance in respect of steps f) and g).

5. The method according to any one of claims 1 to 3, characterized in that, Before performing step a), the first server (1) is equipped with a root certificate (Z1) for the manufacturer domain, a root certificate (Z2) for the client domain, a user certificate (Z5) for the manufacturer domain of the first server (1), and a private key (P1) for the first server (1). The user certificate for the manufacturer domain of the first server includes the public key of the first server (1). Before performing step a), the second server (2) is equipped with a root certificate (Z1) for the manufacturer domain, a root certificate (Z2) for the client domain, a user certificate (Z4) for the client domain of the second server (2), and a private key (P2) for the second server. The user certificate for the client domain of the second server includes the public key of the second server (2) in the client domain, and Before performing step b), the IoT device (3) is equipped with a root certificate (Z1) for the manufacturer domain, a user certificate (Z3) for the manufacturer domain of the IoT device (3) and a private key (P3) for the IoT device (3), wherein the user certificate for the manufacturer domain of the IoT device includes the public key of the IoT device (3) in the manufacturer domain.

6. The method according to any one of claims 1 to 3, characterized in that, The first session key (K1) is known to the first server (1) and the second server (2), but unknown to the IoT device (3). The second session key (K2) is known to the second server (2) and the IoT device (3), but unknown to the first server (1), and / or The third key (K3) is known to the first server (1) and the IoT device (3), but unknown to the second server (2).

7. The method according to any one of claims 1 to 3, characterized in that, Step d) includes generating a random or quasi-random number from the IoT device (3) as authorization information (BI1) (S4).

8. The method according to any one of claims 1 to 3, characterized in that, Step m can be constructed in the following way: Within a single session, the obtained device certificate (Z6) and the authorization information (BI5) are transmitted from the second server (2) to the IoT device (3) via the second communication channel (KK2) (S13).

9. The method according to claim 8, characterized in that, The authorization information (BI5) is transmitted from the second server (2) to the IoT device (3) via the second communication channel (KK2) as part of the certificate extension of the device certificate (Z6).

10. The method according to any one of claims 1 to 3, characterized in that, The cryptographically protected authorization information (BI2) transmitted in steps f) and g) is constructed as a KEM-protected protocol message.

11. The method according to any one of claims 1 to 3, characterized in that, The authenticated and encrypted second communication channel (KK2) is terminated or invalidated after step m).

12. The method according to any one of claims 1 to 3, characterized in that, The IoT device (3) is only allowed to load exactly one set of configuration data based on the constituted authorization information (BI1), the configuration data including the device certificate (Z6).

13. The method according to any one of claims 1 to 3, characterized in that, Equip the first server (1), the second server (2), and the IoT device (3) with a KEM-based protocol stack.

14. The method according to claim 13, characterized in that, The KEM-based protocol stack of the IoT device (3) is additionally equipped for temporary acceptance suitability.

15. The method according to claim 13, characterized in that, The KEM-based protocol stack is set up to implement KEMTLS or KEMTLS-PDK.

16. The method according to any one of claims 1 to 3, characterized in that, Step c) can be constructed in the following way: Establish an authenticated and encrypted third communication channel (KK3) between the IoT device (3) and the first server (1) via the second server (2), including deriving a third key shared by the IoT device (3) and the first server (1).

17. The method according to any one of claims 1 to 3, characterized in that, Before performing step c), the individual PINs of the devices are securely stored in the first server (1) and the IoT device (3), respectively, wherein the PINs are used to establish an authenticated and encrypted third communication channel (KK3) running via the second server (2).

18. A computer program product that causes execution of the method according to any one of claims 1 to 17 on a program-controlled device.

19. A system for loading an IoT device (3) of a manufacturer into a customer’s infrastructure, the system comprising a first server (1) of the manufacturer’s manufacturer domain and a second server (2) of the customer’s customer domain, wherein the first server (1), the second server (2) and the IoT device (3) are configured to perform the method according to any one of claims 1 to 17.

Images