Method for carrying out a device-onboarding process which is secured on the basis of a symmetric cryptography process in a device, computer program product, computer-readable storage medium, and onboarding system

Abstract

The invention relates to a method for carrying out a device-onboarding process which is secured on the basis of a symmetric cryptography process, having the steps of: providing the device (38) with a device-individual symmetric onboarding key; receiving, by means of an electronic computing unit (40), an onboarding request, which is secured by means of the onboarding key, wherein the electronic computing unit (40) is assigned to a user to whom the device (38) is to be registered; transmitting the onboarding request from the electronic computing unit (40) to another electronic computing unit (42), said other electronic computing unit (42) being assigned to an onboarding service provider for the device (38); verifying the device (38) on the basis of the transmitted onboarding request; generating an onboarding response on the basis of the verification and transmitting the onboarding response to the electronic computing unit (40); and carrying out the device-onboarding process on the basis of the onboarding response, wherein a secured communication channel is established between the electronic computing unit (40) and the device (38) on the basis of a symmetric secret. The invention additionally relates a computer program product, to a computer-readable storage medium, and to an onboarding system (36).

Description

[0001] Description

[0002] Method for performing a device onboarding process based on symmetric cryptography in a device, computer program product, computer-readable storage medium and onboarding system

[0003] The following invention relates to a method for carrying out a device onboarding process protected on the basis of symmetric cryptography in a device by means of an onboarding system according to the applicable patent claim 1. Furthermore, the invention relates to a computer program product, a computer-readable storage medium and an onboarding system.

[0004] Security in resource-constrained industrial devices, especially embedded devices such as Internet of Things (IoT) devices, is being continually investigated and improved. Modern industrial devices are increasingly being networked with larger, safety-critical networks. Consequently, communication protocols for such devices are constantly being developed to increase the security of the devices and thus the entire network.

[0005] An important process for industrial devices is so-called zero-touch device onboarding, which enables automated initial security onboarding. There are numerous protocols for automating such a process. Credentials (login information), such as public-key certificates / private keys, and configuration settings are installed on an industrial device without the need for a service technician to intervene; this can also be referred to as zero-touch. This type of onboarding is sometimes referred to as "provisioning" or "bootstrapping." The onboarding process requires sufficiently strong security features to ensure that the right devices can be used trustworthy in the new domain. The onboarding process, for example, takes place between three parties.The first party is an industrial device, on which an operator's credentials and configuration settings are to be installed. A second party is a so-called domain registrar, the buyer and operator of the industrial device, which creates the credentials and configuration settings for the device. A third party is the so-called vendor service, which is provided by the manufacturer and can provide the device with trustworthy information about the end customer domain.

[0006] An industrial device that has not yet been onboarded connects to the domain registrar if network connectivity is available, possibly following a discovery procedure to determine the network address of the respective domain registrar. The domain registrar, in turn, connects to the vendor service point assigned to the industrial device. If the authenticity of the device is successfully verified, the domain registrar creates credentials and configuration settings for the device, which then installs them locally, ideally by recalling its trust relationship with the vendor service point. This successfully completes the onboarding process.

[0007] Currently, such automated onboarding protocols are based on cryptographically secured connections, such as TLS, or on ect-based security, which ensures the confidentiality, integrity of data, and authenticity of the parties involved in the communication. Such properties are achieved with the help of asymmetric cryptography.

[0008] Asymmetric cryptography offers the possibility of using digital signatures to protect the integrity of data and the authenticity of the communicating parties, as well as key exchange procedures. However, the computation of asymmetric cryptography methods is very complex compared to symmetric cryptography. Resource-limited industrial devices have difficulty supporting onboarding protocols based on asymmetric cryptography.

[0009] The object of the present invention is to provide a method, a computer program product, a computer-readable storage medium and an onboarding system by means of which an efficient device onboarding method for industrial devices with limited resources can be realized.

[0010] This object is achieved by a method, a computer program product, a computer-readable storage medium, and an onboarding system according to the independent patent claims. Advantageous embodiments are specified in the subclaims.

[0011] One aspect of the invention relates to a method for carrying out a device onboarding process protected on the basis of symmetric cryptography on a device by means of an onboarding system. The device is provided with a symmetric, device-specific onboarding key, which can also be referred to below as a DICE onboarding key. An onboarding request from the device, protected with the onboarding key, is received by means of an electronic computing device, wherein the electronic computing device is assigned to a user with whom the device is to be registered. In particular, the device should be able to be integrated, registered, operated or put into operation in a secure and confidential manner in the user's domain.

[0012] The onboarding request is then transmitted from the electronic computing device to another electronic computing device in the onboarding system using the electronic computing device, the another electronic computing device being assigned to an onboarding service provider for the device. The device is verified on the basis of the transmitted onboarding request using the another electronic computing device. This can include, for example, a cryptographic check of the onboarding request using the symmetric onboarding key and verification of the device based on the transmitted onboarding request. An onboarding response is generated depending on the verification, and the onboarding response is transmitted to the electronic computing device using the another electronic computing device.The device onboarding process is then carried out based on the onboarding response, whereby a protected communication channel based on a symmetric secret is established between the electronic computing device and the device.

[0013] In particular, an onboarding process is proposed which is based in particular on the so-called DICE architecture (Device Identi fier Composition Engine), in which an industrial device should only calculate symmetric cryptography and thus onboarding can be carried out with little computational effort.

[0014] The electronic computing device can essentially be referred to as a so-called domain registrar. The additional electronic computing device can also be referred to as a vendor service.

[0015] In particular, it can be envisaged that, for example, a user purchases a device. The user and the device will then establish a trust relationship with a trusted third party, which is typically the manufacturer. The device, in turn, will be registered in the user's domain.

[0016] DICE is an architecture specifically designed to increase the security of industrial devices with limited resources, especially those without a hardware secure element. DICE implements a so-called Measured Boot, in which a key chain is established between different software levels. DICE can generate keys that are dependent on the next boot layer. This ensures that the correct key hierarchy can only be reproduced on the device with trusted firmware.

[0017] In particular, as mentioned previously, most device onboarding procedures according to the state of the art are based on asymmetric cryptography, for example the use of digital signatures. A device onboarding process that is based purely on symmetric cryptography is expected to be significantly more efficient, especially on resource-limited devices on which asymmetric cryptography cannot be used. One challenge here is key management, including key updates, as the number of devices involved increases. This invention therefore presents a device onboarding process that is based purely on symmetric cryptography. The protocols benefit in particular from the so-called DICE architecture for key generation, which can significantly reduce the effort required.

[0018] The main assumption within the scope of this invention is that the manufacturer of a device, in particular the onboarding service provider (vendor service), can replicate a DICE key hierarchy of its devices. A key requirement here is knowledge of information used for key derivation. This could be, for example, the DICE Unique Device Secret (UDS) of a device or the DICE Compound Device Identifier (GDI) of a defined boot stage. For this purpose, the vendor service must know the specific device instance, including the software running on it.

[0019] By using the DICE architecture, a vendor service can check whether, for example, original software is being run on the device. In particular, the invention thus offers the possibility of using keys from the DICE chain for onboarding processes based on symmetric and efficient cryptography. Furthermore, it is possible to efficiently update these keys uniformly in the vendor service and in the device itself by changing the configuration parameters or software of the device, for example by restricting them to one-time use. During onboarding, the vendor service can determine whether the original or intended software is being run on a device or whether it has been tampered with.

[0020] In contrast to the use of asymmetric keys for a device onboarding process, the protocols of this invention are more efficient to compute while still providing a flexible way to update symmetric keys. The protocols are suitable for industrial devices with limited resources. However, they are also usable for more powerful devices with unlimited resources.

[0021] The proposed device onboarding process within the scope of this invention is particularly suitable for pre- and post-quantum cryptography applications. In post-quantum cryptography applications, a TLS channel between the domain registrar and the vendor service can also be replaced, for example, with a KEMTLS channel for greater efficiency. A device is configured, in particular, as a peer, a client, or generally any computing unit that has limited resources or computing power.

[0022] According to an advantageous embodiment, a unique device secret is provided as the onboarding key. In particular, this unique device secret can correspond to the so-called DICE Unique Device Secret (UDS). This makes it possible for the method to be advantageously carried out using the DICE architecture. It is also advantageous if a compound device identifier is provided as the onboarding key. In particular, the onboarding key thus corresponds to a so-called Compound Device Identifier (GDI) for the DICE architecture. In particular, reliable onboarding can thus also be provided within a defined boot stage.

[0023] It has also proven advantageous to provide the composite device detection in a defined boot stage of the device. In particular, the onboarding key can thus also be dependent on the device firmware and generated in a defined boot stage.

[0024] Another advantageous embodiment provides for the onboarding service provider to additionally perform software verification for the device. This allows the service provider to verify whether the software installed on the device is, for example, genuine and trustworthy firmware. This allows verification that the software installed on the device can be used reliably.

[0025] It is also advantageous if the onboarding request is transmitted from the device to the electronic computing device in a manner that protects its integrity and is confidential. In particular, at least parts of it can be confidential and protected by integrity, while other parts, in turn, do not need to be confidential but are protected by integrity. This allows for reliable onboarding of the device.

[0026] Furthermore, it has proven advantageous if the onboarding request is provided with a random token. The random token can also be referred to as a nonce. This allows, for example, the "freshness" of the onboarding request to be checked. Yet another embodiment provides for a secure channel to be established when forwarding the onboarding request from the electronic computing device to the further electronic computing device. In particular, the so-called domain registrar can receive the device onboarding request and in turn forwards it to the vendor service via the protected channel, in particular the secure channel, for example TLS or KEMTLS or KEMTLS for post-quantum applications. This channel can be established using asymmetric cryptography, since the domain registrar and the vendor service have sufficient computing power.This channel allows additional information to be attached to the device onboarding request from the domain registrar. The domain registrar onboarding request, i.e., the forwarding of the device onboarding request from one electronic computing device to another, can optionally be protected additionally or alternatively by a signature from the domain registrar.

[0027] Furthermore, it has proven advantageous if the secure channel is established using an asymmetric encryption method. In particular, the secure channel can be generated using asymmetric cryptography, for example.

[0028] It is also advantageous if the onboarding response is additionally protected by a signature from the onboarding service provider. In particular, if, for example, an optional signature is available, the vendor service first verifies the signature of the domain registrar onboarding request. The vendor service identifies the device and the current software version. This can be achieved on the basis of the device onboarding request from the device, with the device integrating this information into the device onboarding request, which is integrity-protected but not encrypted. The device sends this to the domain registrar as part of the device onboarding request. The domain registrar forwards it to the vendor service. Identification features can originate from the device with the onboarding request. These can be integrity-protected with the DICE onboarding key.However, they must not be encrypted because they are intended for key derivation. With this information, the vendor service can recreate the DICE key hierarchy and generate the DICE onboarding key. This key is used to verify the authenticity of the device onboarding request and to decrypt the random token, as well as possibly other specific device information. In this step, the vendor service can detect whether the device's software has been tampered with. The vendor service generates a key Alias ​​Key 2 using the DICE key hierarchy and sends this together with the random token via the domain registrar onboarding response back to the domain registrar over the protected channel. The domain registrar onboarding response can also optionally be further protected by a signature from the vendor service.If an optional signature is present, the domain registrar first verifies the signature of the domain registrar onboarding response, specifically the one created by the vendor service. The domain registrar checks whether the Device_ID, i.e. the device identification, was successfully validated by the vendor service and generates a symmetric key (SKI) to be used for the future protected channel with the device. SKI can be generated using a Key Derivation Function (KDF) or a secure key derivation or generation function. A Device Onboarding Response consisting of SKI and the nonce / random token is created, protected with Alias ​​Key 2 based on symmetric cryptography, specifically integrity-protected and confidentiality-protected, and forwarded to the device.The device also generates a DICE Alias ​​Key 2 and uses this to verify and decrypt the device onboarding response. The device verifies whether the random token matches the originally generated random token. In particular, a so-called freshness check is performed. If all steps were successful, the device accepts the newly generated SKI key from the domain registrar for the secure channel between these two parties, thus completing onboarding.

[0029] Furthermore, it has proven advantageous if the onboarding response for the device is protected by a one-time key within the electronic computing device. The advantage is that the one-time key is known to the other electronic computing device. Therefore, this key should only be used once. This key is used for the secure transmission of another long-term key to the device, which is unknown to the other electronic computing device but is known to the electronic computing device.

[0030] Furthermore, it has proven advantageous if the onboarding request is processed depending on a configuration parameter of the onboarding service provider, and the one-time key is generated randomly or via a key derivation function based on a configuration parameter of the device's onboarding request by the onboarding service provider. The additional advantage of using a key derivation function is that the device can already ensure that the one-time key is generated / used only once and that the one-time key is bound to the current onboarding process on the device side.

[0031] The method presented is, in particular, a computer-implemented method. Therefore, a further aspect of the invention relates to a computer program product with program code means which, when the program code means are processed by the electronic computing device, cause an electronic computing device to carry out a method according to the preceding aspect. Furthermore, the invention also relates to a computer-readable storage medium with at least the computer program product according to the preceding aspect.

[0032] Yet another aspect of the invention relates to an onboarding system for carrying out a device onboarding process protected on the basis of symmetric cryptography in a device having at least one electronic computing device and another electronic computing device, wherein the onboarding system is designed to carry out a method according to the preceding aspect. In particular, the method is carried out using the onboarding system.

[0033] Advantageous embodiments of the method are to be regarded as advantageous embodiments of the computer program product, the computer-readable storage medium, and the onboarding system. The onboarding system has the necessary features to enable the corresponding procedural steps to be carried out.

[0034] A computing unit / electronic computing device can be understood, in particular, as a data processing device containing a processing circuit. The computing unit can therefore, in particular, process data to perform computing operations. This may also include operations for performing indexed access to a data structure, for example, a look-up table (LUT).

[0035] The computing unit can in particular contain one or more computers, one or more microcontrollers and / or one or more integrated circuits, for example one or more application-specific integrated circuits (AS ICs), one or more field-programmable gate arrays (FPGAs), and / or one or more single-chip systems (SoCs). The computing unit can also contain one or more processors, for example one or more microprocessors, one or more central processing units (CPUs), one or more graphics processing units (GPUs), and / or one or more signal processors, in particular one or more digital signal processors (DSPs).The computing unit may also include a physical or virtual network of computers or other of the aforementioned units.

[0036] In various embodiments, the computing unit includes one or more hardware and / or software interfaces and / or one or more memory units.

[0037] A memory unit can be a volatile data memory, for example a dynamic random access memory (DRAM) or a static random access memory (SRAM), or a non-volatile data memory, for example a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory or flash EEPROM, a ferroelectric random access memory (FRAM), a magnetoresistive random access memory,MRAM (magnetoresistive random access memory) or phase-change random access memory, PCRAM (phase-change random access memory).

[0038] For use cases or application situations that may arise during the method and which are not explicitly described here, it may be provided that, in accordance with the method, an error message and / or a request to enter user feedback is issued and / or a standard setting and / or a predetermined initial state is set.

[0039] Regardless of the grammatical gender of a particular term, persons with male, female or other gender identity are included.

[0040] Further features and combinations of features of the invention emerge from the figures and their description, as well as from the claims. In particular, further embodiments of the invention do not necessarily have to contain all features of one of the claims. Further embodiments of the invention may have features or combinations of features that are not mentioned in the claims.

[0041] Showing:

[0042] FIG 1 a schematic flow diagram of a DICE-

[0043] Architecture;

[0044] FIG 2 shows a schematic flow diagram according to an embodiment of the method;

[0045] FIG 3 shows a further schematic flow diagram according to a further embodiment of the method; and

[0046] FIG 4 shows a further schematic flow diagram according to yet another embodiment of the method.

[0047] The invention is explained in more detail below with reference to specific exemplary embodiments and the associated schematic drawings. In the figures, identical or functionally equivalent elements may be provided with the same reference numerals. The description of identical or functionally equivalent elements is not necessarily repeated for different figures, if appropriate. FIG. 1 shows a schematic block diagram of a DICE architecture 10. In this regard, FIG. 1 shows a zeroth layer 12, for example at the hardware level, a first layer 14, which in particular represents a first modifiable code, and a third layer 16, which in particular corresponds to firmware. A first measurement 18 takes place between the zeroth layer 12 and the first layer 14. A second measurement 20 takes place between the first layer 14 and the second layer 16.

[0048] The zeroth layer 12, in turn, has a unique device secret 22 (Unique Device Secret - UDS). This is in turn coupled with a one-way function 24 (One-Way Function - OWF). The one-way function 24, in turn, generates a compound device identifier 26, which can also be referred to as a Compound Device Identifier (GDI).

[0049] The first layer 14, in turn, has a configuration 28 coupled to a key derivation function 30, which can also be referred to as a key derivation function (KDF). Furthermore, the composite device recognition 26 is also coupled to the key derivation function. The key derivation function is, in turn, coupled to a key 32 within the first layer 14.

[0050] The second layer 16, in turn, has consumer software 34. The key 32 is, in turn, coupled to the consumer software 34.

[0051] FIG 2 shows a schematic flow diagram according to one embodiment of the method. In particular, an onboarding system 36 is shown here. The onboarding system 36 has at least one device 38, an electronic computing device 40, and a further electronic computing device 42. The electronic computing device 40 can, for example, be assigned to a user who wishes to register the device 38. The electronic computing device 40 can also be referred to as a domain registrar. The further electronic computing device 42 can, in particular, be assigned to an onboarding service provider, for example a manufacturer of the device 38. The further electronic computing device 42 can also be referred to as a vendor service.

[0052] A device 38 is designed in particular as a peer, a client or generally any computing unit that has limited resources or computing power.

[0053] FIG. 2 shows in particular that the device 38 generates the onboarding key from the DICE architecture. Furthermore, the device 38 protects a device onboarding request with the DICE architecture and a corresponding onboarding key. The onboarding key is derived from the DICE architecture. This key is used to protect the device onboarding request. This request contains at least the following three pieces of information: the device identification, the software version, in particular both integrity-protected with the onboarding key, and the random token, in particular confidentiality- and optionally integrity-protected with the onboarding key. In a first step S 1 , the device 38 then sends the device onboarding request to the electronic computing device 40.In a second step S2, a secure channel, in particular a TLS channel, is established between the electronic computing device 40 and the further electronic computing device 42. Subsequently, in a third step S3, in particular when the secure channel has been established, a domain registrar onboarding request is transmitted from the electronic computing device 40 to the further electronic computing device 42. The domain registrar onboarding request contains the information and identification features from the device onboarding request in a protected form. Additional information can possibly be added here from the electronic computing device 40. The further electronic computing device 42 checks a device identification and a software version of the device 38, which are contained in the onboarding request.The further electronic computing device 42 generates an onboarding key based on the identification features from the device onboarding request (integrity-protected). The further electronic computing device 42 decrypts the random token. The device identification and the software version are both integrity-protected with the onboarding key. These are used to generate the key. Subsequently, a one-time key SKI is generated using the DICE architecture. SKI can be generated using a key derivation function (KDF) or a secure key derivation or generation function. In a fourth step S4, a corresponding first device onboarding response is then transmitted by the further electronic computing device 42. The electronic computing device 40 checks whether the device 38 is OK and generates a random session key SK2, regardless of the DICE architecture.The electronic computing device 40 protects the first device onboarding response with a key SKI . In a fifth step S5, a second device onboarding response is then transmitted from the electronic computing device 40 to the device 38. The device 38 in turn decrypts the second device onboarding response containing SK2 using the one-time key SKI . The device 38 then checks and deletes the random token and the key SKI if the check was successful. The device 38 accepts the key SK2 . In a sixth step S6, the secure channel with SK2 is then again established between the device 38 and the electronic computing device 40.

[0054] In particular, FIG. 2 describes a first possible onboarding process. In the delivery state, the device 38 is connected to the user, in particular to the domain registrar, which in this case corresponds in particular to the electronic computing device 40, and can automatically integrate into the new domain using this protocol. This is called booting of the device 38. The device 38 boots and loads the current key hierarchy using the DICE architecture 10. An onboarding key is also generated during this process.

[0055] Through a trigger, in particular generated internally in the device 38 or externally by a user, the onboarding key is used to generate a device onboarding request and to protect it with a symmetric method, in particular with integrity protection and confidentiality protection. For example, this can be an "Authenticated Encryption with Associated Data" (AEAD) method. This request contains at least the following three pieces of information: the device identification, the software version, and the random token. The device identification is used to identify the device 38, and the software version is used to identify the currently used software. Both pieces of information are integrity-protected with the DICE onboarding key, but not encrypted. The random token is used for freshness purposes and must also be encrypted.Depending on the application, further information about the device 38 can be added to the device onboarding request.

[0056] The electronic computing device 40 receives the device onboarding request and forwards it to the so-called vendor service, which in this case corresponds in particular to the onboarding service provider or the further electronic computing device 42. In particular, a secure channel, for example a (TLS) channel, can be used here. This channel can be set up using asymmetric cryptography, since the electronic computing device 40 and the further electronic computing device 42 have sufficient computing power. Additional information from the domain registrar onboarding request can be attached by the electronic computing device 40 via this channel. The domain registrar onboarding request can optionally also be additionally or alternatively protected by a signature of the electronic computing device 40.If the optional signature is present, the further electronic computing device 42 first verifies the signature of the domain registrar onboarding request, in particular created by the electronic computing device 40. The further electronic computing device 42 identifies the device 38 and the current software version. Using this information, the further electronic computing device 42 can recreate the DICE key hierarchy and generate the DICE onboarding key. This key is used to check the integrity / authenticity of the device onboarding request from the device 38 and to decrypt the random token, possibly also other specific device information. In this step, the further electronic computing device 42 can detect whether the software of the device 38 has been tampered with.The further electronic computing device 42 generates a key, a one-time alias key, via the DICE key hierarchy and sends it, together with the random token, back to the electronic computing device 40 via a device onboarding response over the protected channel. The device onboarding response can optionally be further protected by a signature of the further electronic computing device 42.

[0057] If an optional signature is present, the electronic computing device 40 first verifies the signature of the device onboarding response created by the further electronic computing device 42. The electronic computing device 40 checks whether the device identification was successfully validated by the further electronic computing device 42 and generates a symmetric key SKI to be used for the future protected channel with the device 38. A device onboarding response consisting of SKI and the random token is then created, protected with the alias key 2 based on symmetric cryptography and forwarded to the device 38. The device 38 also generates a DICE alias key 2 and uses this to verify and decrypt the device onboarding response.The device 38 verifies whether the random token matches the originally generated random token, thus performing a freshness check. If all steps were successful, the device 38 accepts the newly generated key SKI from the electronic computing device 40 for the secure channel between these parties, thus completing the onboarding process.

[0058] According to the embodiment shown in FIG. 2, in particular in the device onboarding request, the device identification and the software version, in particular both with the onboarding key, are integrity-protected, as are the random token, in particular with the onboarding key, confidentiality-protected and optionally integrity-protected. The domain registrar onboarding request is integrity- and confidentiality-protected with the DICE alias key and the device onboarding request. The device onboarding response from the further electronic computing device 42 with the DICE alias key, the confirmed device identification, and the nonce is integrity- and confidentiality-protected. The device onboarding response from the electronic computing device 40 with the SK2 and the nonce is integrity- and confidentiality-protected.

[0059] FIG 3 shows a further schematic flow diagram according to an embodiment of the method. FIG 3 shows in particular that the device 38 generates the onboarding key with the DICE architecture 10. This request contains at least the following three pieces of information: the device identification, the software version, in particular both integrity-protected with the onboarding key, and the random token, in particular confidentiality-protected and optionally integrity-protected with the onboarding key. A device onboarding request is protected with the onboarding key by the device 38. In a seventh step S7, the device onboarding request is transmitted to the electronic computing device 40. In an eighth step S8, a secure channel is again established between the electronic computing device 40 and the further electronic computing device 42.The electronic computing device 40 in turn generates a one-time key SKI, in particular as a one-time secret, and supplements the device onboarding request to form the domain registrar onboarding request. The domain registrar onboarding request is transmitted in a ninth step S9 from the electronic computing device 40 to the further electronic computing device 42 and can optionally be signed. If it is signed, the vendor service must then first validate the signature upon receipt of this request. The further electronic computing device 42 again checks the device identification and the software version. An onboarding key is generated from the DICE architecture. The device onboarding request is decrypted using the generated onboarding key. The SKI key and the random token are protected using this onboarding key.In a tenth step S 10 , the first device onboarding response is again transmitted from the further electronic computing device 42 to the electronic computing device 40. The electronic computing device 40 checks whether the device identification is correct. In an eleventh step S 11 , the electronic computing device 40 then transmits the second device onboarding response to the device 38. The device 38 decrypts the second device onboarding response with the DICE onboarding key. The device 38 checks and deletes the random token and accepts a key SKI. The electronic computing device 40 then generates a session key SK2 and protects the key SK2 with SKI. The SK2 is then exchanged between the electronic computing device 40 and the device 38 in a twelfth step S 12 . The device 38 decrypts the key exchange SK2 with SKI and accepts SK2.In a thirteenth step S 13, a secure channel is then again established between the device 38 and the electronic computing device 40 with the aid of the SK2.

[0060] In particular, FIG. 3 describes a further variant compared to the variant presented in FIG. 2. In contrast to the method according to FIG. 2, a random symmetric key SKI is used instead of the alias key 2 for the authentication and authorization of the onboarding of the device 38 in the domain of the electronic computing device 40. This avoids having to forward the alias key 2 to the electronic computing device 40 and perform an update of the alias keys, which requires a reboot of the device 38.

[0061] The differences to the method according to FIG 2 are explained in particular below. In particular, when transmitting the device onboarding request, the difference is that the electronic computing device 40 generates a device-specific key SKI and adds this to the device onboarding request. Furthermore, in the device onboarding response, the key SKI and the random token, which can also be referred to as a nonce and is used for freshness checking, are encrypted by the further electronic computing device 42 and added to the device onboarding response and protected with the DICE onboarding key, instead of with the alias key 2 as in FIG 2. In the corresponding first device onboarding response, no alias key 2 is transferred to the further electronic computing device 42.This protects, in particular, the second device onboarding response between the electronic processing unit 40 and the device 38 with a different key. Onboarding then takes place with the difference that the first device onboarding response is verified with the DICE onboarding key, not with the alias key 2.

[0062] In a variant, the SKI is not generated by the electronic computing device 40, but by the further electronic computing device 42 and is transferred to the electronic computing device 40 via the protected channel.

[0063] Furthermore, in an extension of the method shown in FIG 3, the symmetric key SKI can be exchanged by a randomly generated key SK2, whereby the exchange is protected by the SKI.

[0064] According to the embodiment shown in FIG. 3, in particular in the device onboarding request, the device identification and the software version, in particular both integrity-protected with the onboarding key, as well as the random token, in particular confidentiality-protected and optionally integrity-protected with the onboarding key. The domain registrar onboarding request, which is integrity- and confidentiality-protected with the key SKI and the device onboarding request. The first device onboarding response from the further electronic computing device 42 with SKI, the confirmed device identification, and the nonce is integrity- and confidentiality-protected.

[0065] FIG 4 shows yet another alternative flow diagram according to an embodiment of the method. FIG 4 shows in particular that the onboarding key is generated in the device 38 by the DICE architecture 10. A key SKI, in particular as a one-time key, is generated using a random token and securely stored. The device onboarding request is protected by the onboarding key. This request contains at least the following three pieces of information: the device identification, the software version, in particular both integrity-protected with the onboarding key, and the random token, in particular confidentiality- and optionally integrity-protected with the onboarding key. In another variant, the nonce is not required. SKI is generated on the device 38, securely stored, and protected in the device onboarding request.In a fourteenth step S 14, the device 38 then transmits the device onboarding request to the electronic computing device 40. In a fifteenth step S 15, a secure channel, for example a TLS channel, is created between the electronic computing device 40 and the further electronic computing device 42. In a sixteenth step S 16, the device onboarding request is then transmitted from the electronic computing device 40 to the further electronic computing device 42 as a domain registrar onboarding request. The device identification and the software version are then checked by means of the further electronic computing device 42. Furthermore, an onboarding key based on the DICE architecture 10 is generated. The domain registrar onboarding is decrypted using the generated onboarding key.By means of the further electronic computing device 42, a key SKI, in particular as a one-time key, is generated using a random token. Then, in the seventeenth step S17, the corresponding device onboarding response is transmitted from the further electronic computing device 42 to the electronic computing device 40. The electronic computing device 40 checks the correctness of the device 38 and generates a session key SK2. The first device onboarding response is protected with SKI for integrity and confidentiality reasons. The first device onboarding response is protected using the key SKI. In an eighteenth step S18, the second device onboarding response is then transmitted from the electronic computing device 40 to the device 38. The device 38 decrypts the second device onboarding response with the one-time key SKI, in particular as a one-time key, and carries out an integrity check.The key SKI and the random token are deleted after a positive verification. The device 38 accepts the key SK2. In a nineteenth step S19, a secure channel based on the SK2 is then established between the device 38 and the electronic computing device 40.

[0066] According to the embodiment shown in FIG. 4, in particular in the device onboarding request, the device identification and the software version, in particular both with the onboarding key, are integrity-protected, as are the random token, in particular with the onboarding key, confidentiality-protected and optionally integrity-protected. The domain registrar onboarding request is integrity- and confidentiality-protected with the key request and the device onboarding request. The first device onboarding response from the further electronic computing device 42 with SKI and the confirmed device identification is integrity- and confidentiality-protected.

Claims

Patent claims 1. A method for performing a device onboarding process protected on the basis of symmetric cryptography in a device (38) by means of an onboarding system (36), comprising the steps of: - Providing the device (38) with a symmetric device-specific onboarding key; - Receiving an onboarding request of the device (38) protected by the onboarding key by means of an electronic computing device (40) of the onboarding system (36), wherein the electronic computing device (40) is assigned to a user with whom the device (38) is to be registered; - transmitting the onboarding request from the electronic computing device (40) to a further electronic computing device (42) of the onboarding system (36) by means of the electronic computing device (40), wherein the further electronic computing device (42) is assigned to an onboarding service provider for the device (38); - Verifying the device (38) on the basis of the transmitted onboarding request by means of the further electronic computing device (42); - generating an onboarding response depending on the verification and transmitting the onboarding response to the electronic computing device (40) by means of the further electronic computing device (42); and - performing the device onboarding process based on the onboarding response, wherein a protected communication channel based on a symmetric secret is established between the electronic computing device (40) and the device (38).

2. Method according to claim 1, characterized in that a unique device secret (22) is provided as the onboarding key.

3. Method according to claim 1 or 2, characterized in that a composite device identification (26) is provided as the onboarding key.

4. The method according to claim 3, characterized in that the composite device detection (26) is provided in a defined boot stage of the device (38).

5. Method according to one of the preceding claims, characterized in that a software verification for the device (38) is additionally carried out by means of the onboarding service provider.

6. Method according to one of the preceding claims, characterized in that the onboarding request is transmitted from the device (38) to the electronic computing device (40) in an integrity-protected and confidential manner.

7. Method according to one of the preceding claims, characterized in that the onboarding request is provided with a random token.

8. Method according to one of the preceding claims, characterized in that a secure channel is established when forwarding the onboarding request from the electronic computing device (40) to the further electronic computing device (42).

9. The method according to claim 8, characterized in that the secure channel is established by means of an asymmetric encryption method.

10. Method according to one of the preceding claims, characterized in that the onboarding response is additionally protected by a signature of the onboarding service provider.

11. Method according to one of the preceding claims, characterized in that the onboarding response for the device is protected by means of a one-time key by means of the electronic computing device.

12. The method according to claim 11, characterized in that the onboarding request is processed depending on a configuration parameter of the onboarding service provider and the one-time key is generated randomly or is generated by the onboarding service provider via a key derivation function depending on a configuration parameter of the onboarding request of the device.

13. A computer program product comprising program code means which cause an electronic computing device (40, 42) to carry out a method according to one of claims 1 to 12 when the program code means are processed by the electronic computing device (40, 42).

14. A computer-readable storage medium comprising at least one computer program product according to claim 13.

15. Onboarding system (36) for carrying out a device onboarding process protected on the basis of symmetric cryptography in a device (38), with at least one electronic computing device (40) and a further electronic computing device (42), wherein the onboarding system (36) is designed to carry out a method according to one of claims 1 to 12.

Images