METHOD AND SYSTEM FOR ONBOARDING AN IOT DEVICE

Description

[0001] The present invention relates to a method and a computer program product for onboarding an IoT device (IoT; Internet of Things) of a manufacturer into a customer's infrastructure using a first server of a manufacturer's domain and a second server of a customer's domain. Furthermore, the present invention relates to a system for onboarding an IoT device of a manufacturer into a customer's infrastructure.

[0002] An example of onboarding for an IoT device in 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 an IoT device without the need for service technician intervention. This type of onboarding can also be referred to as provisioning or bootstrapping. Such a process requires sufficiently strong security features to ensure that only the correct IoT devices are used in the new domain, i.e., the customer domain. The onboarding process requires communication, in particular, between three parties: 1. An IoT device on which credentials and configuration settings are installed; 2. A first server in a manufacturer domain of the IoT device manufacturer. The first server can also be referred to as a device authority. It is provided by the IoT device manufacturer and can, on the one hand, serve as a guarantor for the authenticity or originality of the IoT device and, on the other hand, provide the IoT device with trustworthy information about the customer domain; 3. A second server in a customer domain of the customer, in which the IoT device is to be onboarded. The second server can also be referred to as a domain onboarding authority. It is operated by the IoT device customer and intends to issue credentials and / or configuration data for the IoT device or possesses them.

[0003] An IoT device that has not yet completed onboarding connects to the second server if network connectivity is available, possibly following a discovery procedure to determine the second server's network address. The second server, in turn, connects to the first server in the manufacturer's domain. If the authenticity of the IoT device is successfully verified, the second server provides a device certificate, in particular comprising credentials and configuration settings from the customer domain, for the IoT device, which the IoT device can then install locally, particularly by relying on its trust relationship with the first server. This typically completes the onboarding process successfully.

[0004] Currently, such onboarding processes are based on cryptographically secured connections, for example TLS (Transport Layer Security) or object-based security, which ensures the confidentiality and integrity of data and the authenticity of the parties involved in the communication.

[0005] To verify the authenticity of IoT devices against the second server or the first server, cryptographic signature methods are traditionally used for authentication. The second server, or a service accessible from it, typically issues a digital device certificate for the IoT device, which the IoT device can use to authenticate itself after onboarding using a cryptographic signature method.

[0006] The security of current asymmetric cryptography, which is used for communication and authenticity verification during the onboarding of an IoT device, will most likely be vulnerable to attack by powerful quantum computers in the future. For example, in US2022038269 A1, the onboarding of an IoT device is secured using conventional signatures.

[0007] Therefore, there is a need for an onboarding system for an IoT device that is secure and, in particular, efficient against quantum computer attacks.

[0008] Against this background, one object of the present invention is to improve the onboarding of a manufacturer's IoT device into a customer's infrastructure. According to a first aspect, a method for onboarding a manufacturer's IoT device (IoT; Internet of Things) into a customer's infrastructure is proposed using a first server of a manufacturer's domain and a second server of a customer's domain. The method comprises the following steps, in particular using a KEM method (KEM; Key Encapsulation Mechanism): a) Establishing an authenticated and encrypted first communication channel between the first server and the second server, comprising deriving a first session key common to the first server and the second server, b) Providing an authenticated and encrypted second communication channel between the IoT device and the second server, comprising deriving a second session key common to the second server and the IoT device, c) Establishing an authenticated and encrypted third communication channel, running via the second server, between the IoT device and the first server, to which a third key common to the IoT device and the first server is assigned, d) Forming authorization information by the IoT device, e) Cryptographically protecting the formed authorization information by the IoT device using the third key,f) transmitting the cryptographically protected authorization information from the IoT device to the second server via the second communication channel, g) transmitting the cryptographically protected authorization information from the second server to the first server via the first communication channel, h) decrypting the cryptographically protected authorization information transmitted from the second server to the first server by the first server using the third key, i) encrypting, and preferably providing integrity protection, the decrypted authorization information by the first server using the first session key, j) transmitting the authorization information encrypted with the first session key and preferably integrity-protected from the first server via the first communication channel to the second server, k) decrypting, and preferably checking the integrity,the authorization information encrypted with the first session key by the second server, l) sending a request to receive a device certificate of the customer domain assigned to the IoT device from the second server to a certification authority, in particular the customer domain, m) transmitting the received device certificate, and preferably configuration data of the customer domain, and the authorization information decrypted by the second server from the second server to the IoT device via the second communication channel, and n) accepting the device certificate transmitted by the second server and, if applicable, configuration data of the customer domain by the IoT device if the authorization information transmitted by the second server corresponds to the generated authorization information.

[0009] This creates a method for onboarding a manufacturer's IoT device in a customer's infrastructure that is secure against quantum computer attacks by means of a first server of a manufacturer's domain and a second server of a customer's domain, in which a device certificate of the customer domain for the IoT device is provided on the IoT device using three authenticated and encrypted communication channels and a key encapsulation method.

[0010] This onboarding is specifically a zero-touch device onboarding, and thus an automated process without the need for service technician intervention. The device certificate of the customer domain is transferred to the IoT device, which, in particular, is accepted and installed by the device. Additional configuration settings and / or credentials can be installed on the IoT device with or after the device certificate.

[0011] The KEM procedure is also known as the key encapsulation mechanism (KEM procedure). This onboarding procedure can also be referred to as an onboarding procedure or device onboarding procedure or process. In contrast to conventional solutions, this device onboarding procedure primarily relies on the verification of certificate signatures, particularly with regard to signature procedures. The primary use of KEM-based procedures results in increased protection against quantum computer attacks. In this case, therefore, only signature verifications are performed as part of the certificate validation.

[0012] This device onboarding process offers the technical advantage that no signature generation processes are required outside the certification authority (also called certification authority). Consequently, there is advantageously no need for secure management of private signature keys outside the certification authority, since no private signature keys are required and, consequently, no secure storage is necessary. Furthermore, there is advantageously no need to implement a signature generation process, since no signature generation process is used here. Consequently, a smaller code base is achieved. Therefore, should a signature generation process or the implementation of a signature generation process be affected by a future attack or bug, this device onboarding process will not be affected.

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

[0014] According to one embodiment, the authenticated and encrypted first communication channel and / or the authenticated and encrypted second communication channel is cryptographically protected by means of a KEM method.

[0015] By using a KEM method for cryptographic protection, the present method is particularly advantageous with regard to the use of post-quantum methods and resistance to quantum computer attacks.

[0016] Using a KEM method can result in performance advantages, as KEM methods are often more performant than signature methods. Furthermore, the present onboarding process can be easily made secure against quantum computer attacks by using post-quantum KEM. Post-quantum KEMs are currently being standardized by the US National Institute of Standards and Technology (NIST). Therefore, the present onboarding process can also be considered a post-quantum device onboarding process. Furthermore, hybrid (pre-quantum and post-quantum) KEM methods can be flexibly deployed. Thus, the present process can also be referred to as a hybrid pre- / post-quantum device onboarding process.

[0017] After successfully completing step n), the IoT device is configured for communication within the customer domain, meaning onboarding is successfully completed. Optionally, the IoT device can use the configured device certificate, specifically the KEMTLS device certificate, to establish a KEMTLS connection to the second server. This allows the second server to verify that the IoT device's onboarding has been successfully completed.

[0018] The IoT device derives its trust in the new domain, in this case the customer domain, by the fact that only the first server is able to determine the authorization information, for example in the form of a nonce (https: / / en.wikipedia.org / wiki / Cryptographic_nonce), as well as by the respective checks and authentications and the protected communication channels, in this case the first, second and third communication channels.

[0019] The second server derives its trust in the IoT device through various checks and, in particular, through its ability to validate the associated device certificate during channel establishment, especially KEMTLS channel establishment, and to verify the identity information contained therein, for example, using an inventory list.

[0020] Through the authenticated key exchange, the first server can verify whether the second server can present an encrypted string, in this case the cryptographically protected authorization information, from an authorized IoT device.

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

[0022] KEMTLS establishes an authenticated and encrypted communication channel similar to traditional TLS. However, different cryptographic primitives are used internally, i.e., KEM instead of a digital signature and instead of a traditional key exchange procedure.

[0023] According to a further embodiment, the authenticated and encrypted third communication channel is formed as a direct communication channel between the IoT device and the first server.

[0024] According to a further embodiment, the authenticated and encrypted third communication channel is formed 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 in particular as a forwarding instance with regard to steps f) and g).

[0025] According to a further embodiment, before performing step a), the first server is provided with a root certificate of the manufacturer domain, a root certificate of the customer domain, a user certificate of the manufacturer domain for the first server, comprising a public key of the first server, and a private key of the first server. Before performing step a), the second server is preferably provided with the root certificate of the manufacturer domain, the root certificate of the customer domain, a user certificate of the customer domain for the second server, comprising a public key of the second server in the customer domain, and a private key of the second server.Before performing step b), the IoT device is preferably provided with the root certificate of the manufacturer domain, with a user certificate of the manufacturer domain for the IoT device comprising a public key of the IoT device in the manufacturer domain and with a private key of the IoT device.

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

[0027] According to a further embodiment, step d) comprises that a random number or a quasi-random number is formed by the IoT device as authorization information.

[0028] For example, the IoT device creates a nonce as authorization information. The IoT device is the actuator and the location where the nonce is created.

[0029] According to a further embodiment, step m) is implemented by: transmitting the received device certificate together with the authorization information from the second server within a single session via the second communication channel to the IoT device, wherein the authorization information is preferably transmitted as part of a certificate extension of the device certificate from the second server via the second communication channel to the IoT device.

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

[0031] Preferably, the second server sends a cryptographic hash value of the root certificate it wants to use for the IoT device to the first server. The first server can then transmit this hash value back to the IoT device, particularly after verification, by encrypting it for the IoT device, including another shared secret, and sending it back to the second server, which then transmits this message to the IoT device. The IoT device thus has another way to verify the root certificate of the customer domain.

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

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

[0034] According to a further embodiment, the IoT device only allows the loading of exactly one set of configuration data comprising the device certificate based on the generated authorization information.

[0035] According to a further embodiment, the first server, the second server, and the IoT device are each equipped with a KEM-based protocol stack. The KEM-based protocol stack of the IoT device is preferably additionally equipped with provisional acceptance capability. The KEM-based protocol stack is preferably configured to implement KEMTLS or KEMTLS-PDK.

[0036] Provisional Accept is a mechanism from RFC 8995 in which 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 during the initial verification of the server certificate. This error is the absence of a trusted root certificate, in this case the root certificate of the customer domain, in its store of trusted root certificates. Subsequently, no arbitrary communication is permitted through the thus established channel, but only a reduced process according to a linear automaton (see the detailed description of the Fig. 2 ). As soon as an error occurs during the described process or as soon as the described process is deviated from, the communication channel is terminated and the client, in this case the IoT device, returns to the state it had before the communication channel was established (so-called rollback).

[0037] After successfully completing step n), the IoT device preferably resolves the provisional accept and transfers the device certificate, in particular a KEMTLS device certificate, to its persistent storage. Optionally, additional certificates, in particular the certificate chain or the associated root certificate or other configuration settings and / or configuration information, can also be written to the persistent storage by the IoT device. The associated root certificate can be marked as trusted.

[0038] According to a further embodiment, step c) is implemented by: establishing the authenticated and encrypted third communication channel between the IoT device and the first server, running via the second server, comprising deriving a third session key common to the IoT device and the first server.

[0039] According to a further embodiment, a device-specific PIN (or PIN code) is securely stored in the first server and the IoT device before performing step c). The PIN is used to establish the authenticated and encrypted third communication channel running via the second server.

[0040] The authorization information and the PIN are preferably encrypted using the KEM method described above, thus preferably directly forming the secret protected by encapsulation. In this case, both KEM methods and PKE methods (PKE; Public Key Encryption) can preferably be used. The PIN is stored confidentially both by the first server and within the IoT device. In embodiments, the first server uses a master key method to derive device-specific PINs in order to minimize the amount of data that must be stored confidentially.

[0041] According to a second aspect, a computer program product is proposed which causes the method as explained above according to the first aspect or one of the embodiments of the first aspect to be carried out on a program-controlled device.

[0042] A computer program product, such as a computer program means, can be provided or delivered, for example, as a storage medium, such as a memory card, USB stick, CD-ROM, DVD, or in the form of a downloadable file from a server in a network. This can be done, for example, in a wireless communications network by transmitting a corresponding file with the computer program product or the computer program means.

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

[0044] The embodiments and features described for the proposed method apply accordingly to the proposed system.

[0045] Further possible implementations of the invention also include combinations of features or embodiments described above or below with respect to the exemplary embodiments that are not explicitly mentioned. In this case, the person skilled in the art will also add individual aspects as improvements or additions to the respective basic form of the invention.

[0046] Further advantageous embodiments and aspects of the invention are the subject of the dependent claims and the exemplary embodiments of the invention described below. The invention will be explained in more detail below using preferred embodiments with reference to the accompanying figures. Fig. 1 shows a schematic flow diagram of an embodiment of a method for onboarding a manufacturer's IoT device into a customer's infrastructure; and Fig. 2 shows a schematic communication diagram of an embodiment of a system for onboarding an IoT device.

[0047] In the figures, identical or functionally equivalent elements have been given the same reference numerals unless otherwise stated.

[0048] Fig. 1 shows a schematic flow diagram of an embodiment of a method for onboarding an IoT device 3 of a manufacturer in a customer infrastructure 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. The embodiment according to Fig. 1 is made with reference to the Fig. 2 explained. Here, the Fig. 2 a schematic communication diagram of an embodiment of an onboarding system for the IoT device 3.

[0049] The communication diagram of the Fig. 2 shows channel setup and communication between the first server 1, the second server 2 and the IoT device 3.

[0050] The procedure according to Fig. 1 comprises steps S1 to S14. These steps S1 to S14 are also included in the Fig. 2 Before performing steps S1 to S14, the first server 1 is provided with a root certificate Z1 of the manufacturer domain, a root certificate Z2 of the customer domain, a user certificate Z5 of the manufacturer domain for the first server 1 comprising a public key of the first server 1 and a private key P1 of the first server 1. The second server 2 is provided with the root certificate Z1 of the manufacturer domain, the root certificate Z2 of the customer domain, a user certificate Z4 of the customer domain for the second server 2 comprising a public key of the second server 2 in the customer domain and a private key P2 of the second server 2.The IoT device 3 is equipped with the root certificate Z1 of the manufacturer domain, with a user certificate Z3 of the manufacturer domain for the IoT device 3 comprising a public key of the IoT device 3 in the manufacturer domain and with a private key P3 of the IoT device 3.

[0051] In particular, the first server 1, the second server 2, and the IoT device 3 are each equipped with a KEM-based protocol stack. The KEM-based protocol stack of the IoT device 3 is preferably additionally equipped with the capability for provisional acceptance. The KEM-based protocol stack is particularly configured to implement KEMTLS or KEMTLS-PDDK and is used in particular for carrying out the method according to the Fig. 1 and 2 used.

[0052] Now to the sequence of process steps S1 to S14 according to the Fig. 1 and 2: 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 includes, in particular, deriving a session key K1 common to the first server 1 and the second server 2 (see Fig. 2 ).

[0053] 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 comprises, in particular, deriving a second session key K2 common to the second server 2 and the IoT device 3 (see Fig. 2 The authenticated and encrypted first communication channel KK1 and / or the authenticated and encrypted second communication channel KK2 are preferably cryptographically protected using a KEM method. KEMTLS, for example, is used as the KEM method.

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

[0055] The second session key K2, however, is known to the second server 2 and the IoT device 3, but unknown to the first server 1 (see K2 in Fig. 2 ).

[0056] In step S3, an authenticated and encrypted third communication channel KK3 is established between the IoT device 3 and the first server 1 via the second server 2. The third communication channel KK3 is assigned a third key K3 common to the IoT device 3 and the first server 1 (see K3 in Fig. 2 ). The third key K3 is known to the first server 1 and the IoT device 3, but is unknown to the second server 2.

[0057] For example, the authenticated and encrypted third communication channel KK3 is designed as a direct communication channel between the IoT device 3 and the first server 1. Alternatively - and as in the example of the Fig. 2 As shown, the third communication channel KK3 is configured as a tunneled communication channel by tunneling over the authenticated and encrypted first communication channel KK1 and the authenticated and encrypted second communication channel KK2. The second server 2 is then used as a forwarding instance.

[0058] In particular, the third key K3 can also be configured as a session key K3. In this case, the step of establishing the authenticated and encrypted third communication channel KK3 between the IoT device 3 and the first server, which runs via the second server 2, can include deriving a third session key K3 common to the IoT device 3 and the first server 1.

[0059] In step S4, authorization information BI is generated by IoT device 3. IoT device 3 is the actuator and the location where authorization information BI is generated. Specifically, a random number or a quasi-random number, for example, a nonce, is generated by IoT device 3 as authorization information BI1.

[0060] In step S5, the generated authorization information BI is cryptographically protected, in particular encrypted, by the IoT device 3 using the third key K3. Cryptographic protection includes, in particular, integrity protection, authenticity, and confidentiality.

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

[0062] In step S7, the cryptographically protected authorization information BI2 is transmitted from the second server 2 to the first server 1 via the first communication channel KK1. Preferably, the cryptographically protected authorization information BI2 transmitted in steps S6 and S7 is embodied as a KEM-protected protocol message.

[0063] In step S8, the cryptographically 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 decrypted authorization information BI3.

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

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

[0066] In step S11, the authorization information BI4 encrypted with the first session key K1 is decrypted by the second server 2, so that a decrypted authorization information BI5 is available at the second server 2.

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

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

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

[0070] Preferably, the authenticated and encrypted second communication channel KK2 is terminated or invalidated after step S13.

[0071] In step S14, the device certificate Z6 transmitted by the second server 2 is accepted by the IoT device 3 if the authorization information BI5 transmitted by the second server 2 corresponds to the authorization information BI1 generated on the IoT device 3 in step S4 and the root certificate Z2 of the customer domain allows the resolution of the provisional accept. For this purpose, the IoT device 3 stores the authorization information BI1 generated in step S4 in a memory unit of the IoT device 3.

[0072] Preferably, based on the generated authorization information BI1, the IoT device 3 only allows the loading of exactly one set of configuration data, comprising the device certificate Z6. Afterward, i.e., after step S14, the generated authorization information BI1 is preferably invalidated.

[0073] Although the present invention has been described using exemplary embodiments, it can be modified in many ways.

Claims

1. Method for onboarding an IoT device (3) of a manufacturer in an infrastructure of a customer 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, involving: a) setting up (S1) an authenticated and encrypted first communication channel (KK1) between the first server (1) and the second server (2), comprising deriving a session key (K1) that is common to 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), comprising deriving a second session key (K2) that is common to the second server (2) and the IoT device (3), c) setting up (S3) an authenticated and encrypted third communication channel (KK3), which runs via the second server (2), between the IoT device (3) and the first server (1), to which a third key (K3) that is common to the IoT device (3) and the first server (1) is assigned, d) forming (S4) permission information (BI1) by way of the IoT device (3), e) cryptographically protecting (S5) the formed permission information (BI1) by way of the IoT device (3) by means of the third key (K3), f) transmitting (S6) the cryptographically protected permission information (BI2) from the IoT device (3) to the second server (2) via the second communication channel (KK2), g) transmitting (S7) the cryptographically protected permission information (BI2) from the second server (2) to the first server (1) via the first communication channel (KK1), h) decrypting (S8) the cryptographically protected permission information (BI2) transmitted from the second server (2) to the first server (1) by way of the first server (1) by means of the third key (K3), i) encrypting (S9) the decrypted permission information (BI3) by way of the first server (1) by means of the first session key (K1), j) transmitting (S10) the permission information (BI4) encrypted with the first session key (K1) from the first server (1) to the second server (2) via the first communication channel (KK1), k) decrypting (S11) the permission information (BI4) encrypted with the first session key (K1) by way of the second server (2), l) sending (S12) a request (A) to obtain a device certificate (Z6), associated with the IoT device (3), of the customer domain from the second server (2) to a certificate authority (4), m) transmitting (S13) the obtained device certificate (Z6) and the permission information (BI5) decrypted by the second server (2) from the second server (2) to the IoT device (3) via the second communication channel (KK2), and n) accepting (S14) the device certificate (Z6) transmitted by the second server (2) by way of the IoT device (3) if the permission information (BI5) transmitted by the second server (2) matches the formed permission information (BI1).

2. 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 / is cryptographically protected by means of a KEM method.

3. Method according to Claim 2, characterized in that the KEM method used is KEMTLS.

4. Method according to any of Claims 1 to 3, characterized in that the authenticated and encrypted third communication channel (KK3) is rendered as a direct communication channel between the IoT device (3) and the first server (1), or in that the authenticated and encrypted third communication channel (KK3) is rendered as a tunnelled communication channel by tunnelling via the authenticated and encrypted first communication channel (KK1) and the authenticated and encrypted second communication channel (KK2), the second server (2) being used in particular as a forwarding instance in respect of steps f) and g) .

5. Method according to any of Claims 1 to 4, characterized in that, before step a) is performed, the first server (1) is equipped with a root certificate (Z1) of the manufacturer domain, a root certificate (Z2) of the customer domain, a user certificate (Z5) of the manufacturer domain for the first server (1), comprising a public key of the first server (1), and a private key (P1) of the first server (1), in that, before step a) is performed, the second server (2) is equipped with the root certificate (Z1) of the manufacturer domain, the root certificate (Z2) of the customer domain, a user certificate (Z4) of the customer domain for the second server (2), comprising a public key of the second server (2) in the customer domain, and with a private key (P2) of the second server (P2), and in that, before step b) is performed, the IoT device (3) is equipped with the root certificate (Z1) of the manufacturer domain, with a user certificate (Z3) of the manufacturer domain for the IoT device (3), comprising a public key of the IoT device (3) in the manufacturer domain, and with a private key (P3) of the IoT device (3).

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

7. Method according to any of Claims 1 to 6, characterized in that step d) comprises a random number or a quasi-random number being formed (S4) by the IoT device (3) as permission information (BI1).

8. Method according to any of Claims 1 to 7, characterized in that step m) is rendered by: transmitting (S13) the obtained device certificate (Z6) together with the permission information (BI5) from the second server (2) to the IoT device (3) via the second communication channel (KK2) within a single session, the permission information (BI5) being transmitted from the second server (2) to the IoT device (3) via the second communication channel (KK2) preferably as part of a certificate extension of the device certificate (Z6).

9. Method according to any of Claims 1 to 8, characterized in that the cryptographically protected permission information (BI2) transmitted in steps f) and g) is rendered as a KEM-protected protocol message.

10. Method according to any of Claims 1 to 9, characterized in that the authenticated and encrypted second communication channel (KK2) is terminated or invalidated after step m).

11. Method according to any of Claims 1 to 10, characterized in that the IoT device (3) takes the formed permission information (BI1) as a basis for permitting only precisely one set of configuration data comprising the device certificate (Z6) to be loaded.

12. Method according to any of Claims 1 to 11, characterized in that the first server (1), the second server (2) and the IoT device (3) are each equipped with a KEM-based protocol stack, the KEM-based protocol stack of the IoT device (3) preferably additionally being equipped with suitability for Provisional Accept, the KEM-based protocol stack preferably being set up to implement KEMTLS or KEMTLS-PDK.

13. Method according to any of Claims 1 to 12, characterized in that step c) is rendered by: setting up the authenticated and encrypted third communication channel (KK3), which runs via the second server (2), between the IoT device (3) and the first server (1), comprising deriving a third session key (K3) that is common to the IoT device (3) and the first server (1).

14. Method according to any of Claims 1 to 12, characterized in that, before step c) is performed, a device-individual PIN is securely stored in each of the first server (1) and the IoT device (3), the PIN being used to set up the authenticated and encrypted third communication channel (KK3) running via the second server (2).

15. Computer program product that causes the method according to any of Claims 1 to 14 to be performed on a program-controlled apparatus.

16. System for onboarding an IoT device (3) of a manufacturer in an infrastructure of a customer, comprising a first server (1) of a manufacturer domain of the manufacturer and a second server (2) of a customer domain of the customer, the first server (1), the second server (2) and the IoT device (3) being set up to perform the method according to any of Claims 1 to 14.