CN115812292A

CN115812292A - Method and device for equipment pre-configuration

Info

Publication number: CN115812292A
Application number: CN202080102818.8A
Authority: CN
Inventors: 刘蜀宁; 姚亦峰
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2020-07-07
Filing date: 2020-07-07
Publication date: 2023-03-17
Also published as: WO2022006736A1

Abstract

A method for provisioning a device is disclosed. An example method may include determining transaction data for a device provisioning, and sending the transaction data to a decentralized ledger system. Related apparatus and computer readable media are also disclosed.

Description

Method and device for equipment pre-configuration

Technical Field

Various example embodiments relate to a method and apparatus for device provisioning.

Background

Friendly Wi-Fi settings may be enabled based on the Device Provisioning Protocol (DPP), which may also maintain or improve the security level of growth and continued penetration of Wi-Fi technology, for example.

Disclosure of Invention

In a first aspect, a method is disclosed that includes determining transaction data for a provisioning of a device and sending the transaction data to a decentralized ledger (leeger) system.

In some example embodiments, the transaction data may include bootstrap (bootstrap) information. In some example embodiments, the method may further include receiving a request from the decentralized ledger system to verify an identity of a registrant of the bootstrap information, determining a signature for the identity verification, and sending the signature to the decentralized ledger system.

In some example embodiments, the transaction data may include an authentication response to the at least one authentication request. In some example embodiments, the method may further include receiving at least one authentication request from the decentralized ledger system, and receiving an authentication confirmation from the decentralized ledger system after sending the transaction data.

In some example embodiments, the transaction data may include a configuration request. In some example embodiments, the method may further include receiving a configuration response to the configuration request from the decentralized ledger system.

In some example embodiments, the decentralized ledger system may comprise at least one of a blockchain network, an IOTA, and/or the like. In some example embodiments, the at least one communication with the decentralized ledger system may be based on Masked Authenticated Messaging (Masked Authenticated Messaging).

In some example embodiments, the at least one communication with the decentralized standing system may be via at least one smart contract (smart contract) deployed in the decentralized standing system and/or at least one smart contract automatically deployed in the decentralized standing system.

In some example embodiments, the transaction data may approve at least two tip (tip) sites in the decentralized ledger system after verifying that at least one directly or indirectly approved transaction data provisioned for a device in the decentralized ledger system is valid.

In a second aspect, an apparatus is disclosed. The apparatus may be configured to perform at least the method of the first aspect. For example, the configuration of the device may include means for determining transaction data for provisioning of the device, and means for sending the transaction data to the decentralized ledger system.

In some example embodiments, the transaction data may include bootstrap information. In some example embodiments, the apparatus may further include means for receiving a request from the decentralized ledger system to verify an identity of a registrant of the bootstrap information, means for determining a signature for the identity verification, and means for sending the signature to the decentralized ledger system.

In some example embodiments, the transaction data may include an authentication response to the at least one authentication request. In some example embodiments, the apparatus may further include means for receiving at least one authentication request from the decentralized ledger system, and means for receiving an authentication confirmation from the decentralized ledger system after sending the transaction data.

In some example embodiments, the transaction data may include a configuration request. In some example embodiments, the apparatus may further include means for receiving a configuration response to the configuration request from the decentralized ledger system.

In some example embodiments, the decentralized ledger system may comprise at least one of a blockchain network, an IOTA, and/or the like. In some example embodiments, the at least one communication with the decentralized ledger system may be based on a masked authentication message.

In some example embodiments, the at least one communication with the decentralized ledger system may be via at least one intelligent contract deployed in the decentralized ledger system and/or at least one intelligent contract automatically deployed in the decentralized ledger system.

In some exemplary embodiments, the transaction data may approve at least two tip sites in the decentralized ledger system after verifying that at least one directly or indirectly approved transaction data provisioned for a device in the decentralized ledger system is valid.

In a third aspect, an apparatus is disclosed that includes at least one processor and at least one memory. The at least one memory may include computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus at least to perform the method of the first aspect. For example, the at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus to perform at least: transaction data for device provisioning is determined and sent to the decentralized ledger system.

In some example embodiments, the transaction data may include bootstrap information. In some example embodiments, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to perform receiving a request from the decentralized ledger system to verify an identity of a registrant of the bootstrap information, determining a signature for the identity verification, and sending the signature to the decentralized ledger system.

In some example embodiments, the transaction data may include an authentication response to the at least one authentication request. In some example embodiments, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to perform receiving at least one authentication request from the decentralized ledger system, and receiving an authentication confirmation from the decentralized ledger system after sending the transaction data.

In some example embodiments, the transaction data may include a configuration request. In some example embodiments, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to perform receiving a configuration response to the configuration request from the decentralized ledger system.

In some example embodiments, the at least one communication with the decentralized ledger system can be via at least one intelligent contract deployed in the decentralized ledger system and/or at least one intelligent contract automatically deployed in the decentralized ledger system.

In some example embodiments, the transaction data may approve at least two tip sites in the decentralized ledger system after validating at least one directly or indirectly approved transaction data provisioned for a device in the decentralized ledger system.

In a fourth aspect, a computer-readable medium is disclosed. The computer readable medium may comprise instructions stored thereon for causing an apparatus to perform the method of the first aspect. For example, the instructions may cause the apparatus to perform at least determining transaction data for a device provisioning and sending the transaction data to a decentralized ledger system.

In some example embodiments, the transaction data may include bootstrap information. In some example embodiments, the apparatus may further cause the apparatus to perform receiving a request from the decentralized ledger system to verify an identity of a registrant of the bootstrap information, determining a signature for identity verification, and sending the signature to the decentralized ledger system.

In some example embodiments, the transaction data may include an authentication response to the at least one authentication request. In some example embodiments, the instructions may further cause the apparatus to perform receiving the at least one authentication request from the decentralized ledger system, and receiving an authentication confirmation from the decentralized ledger system after sending the transaction data.

In some example embodiments, the transaction data may include a configuration request. In some example embodiments, the instructions may further cause the apparatus to perform receiving a configuration response to the configuration request from the decentralized ledger system.

In some example embodiments, the transaction data may approve at least two tip sites in the decentralized ledger system after verifying that at least one directly or indirectly approved transaction data provisioned for a device in the decentralized ledger system is valid.

In a fifth aspect, a method is disclosed that includes receiving transaction data for device provisioning from a decentralized ledger system.

In some example embodiments, the transaction data may include bootstrapping information. In some example embodiments, the method may further include sending a request to the decentralized ledger system to verify an identity of the registrant of the bootstrap information, receiving a response to the request from the decentralized ledger system, and determining the identity of the registrant based on the bootstrap information and information in the response.

In some example embodiments, the transaction data may include an authentication response to the at least one authentication request. In some example embodiments, the method may further include sending at least one authentication request to the decentralised ledger system, and sending an authentication confirmation to the decentralised ledger system after receiving the transaction data.

In some example embodiments, the transaction data may include a configuration request. In some example embodiments, the method may further include sending a configuration response to the configuration request to the decentralized ledger system.

In some example embodiments, the method may further include obtaining an identifier of the registrant through an out-of-band mechanism (out-of-band mechanism) to receive transaction data for device provisioning from the decentralized ledger system based on the obtained identifier.

In a sixth aspect, an apparatus is disclosed. The apparatus may be configured to perform at least the method of the fifth aspect. For example, the apparatus may include means for receiving transaction data for the provisioning of the apparatus from the decentralized ledger system.

In some example embodiments, the transaction data may include bootstrap information. In some example embodiments, the apparatus may further include means for sending a request to the decentralized ledger system to verify an identity of a registrant of the bootstrap information, means for receiving a response to the request from the decentralized ledger system, and means for determining the identity of the registrant based on the bootstrap information and information in the response.

In some example embodiments, the transaction data may include an authentication response to the at least one authentication request. In some example embodiments, the apparatus may further include means for sending at least one authentication request to the decentralized ledger system, and means for sending an authentication confirmation to the decentralized ledger system after receiving the transaction data.

In some example embodiments, the transaction data may include a configuration request. In some example embodiments, the apparatus may further include means for sending a configuration response to the configuration request to the decentralized ledger system.

In some example embodiments, the apparatus may further include means for obtaining an identifier of the registrant through an out-of-band mechanism to receive transaction data for device provisioning from the decentralized ledger system based on the obtained identifier.

In a seventh aspect, an apparatus comprising at least one processor and at least one memory is disclosed. The at least one memory may include computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus at least to perform the method of the fifth aspect. For example, the at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus at least to perform receiving transaction data for device provisioning from a decentralized ledger system.

In some example embodiments, the transaction data may include bootstrap information. In some example embodiments, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to perform sending a request to the decentralized ledger system for verifying an identity of a registrant of the bootstrapping information, receiving a response to the request from the decentralized ledger system, and determining the identity of the registrant based on the bootstrapping information and information in the response.

In some example embodiments, the transaction data may include an authentication response to the at least one authentication request. In some example embodiments, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to perform sending the at least one authentication request to the decentralized ledger system, and sending an authentication confirmation to the decentralized ledger system after receiving the transaction data.

In some example embodiments, the transaction data may include a configuration request. In some example embodiments, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to perform sending a configuration response to the configuration request to the decentralized ledger system.

In some example embodiments, the at least one communication with the decentralized ledger system may be via at least one intelligent contract deployed in the decentralized ledger system and/or automatically deploying the at least one intelligent contract in the decentralized ledger system.

In some example embodiments, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to perform obtaining an identifier of a registrant through an out-of-band mechanism to receive transaction data for device provisioning from the decentralized ledger system based on the obtained identifier.

In an eighth aspect, a computer-readable medium is disclosed. The computer readable medium may comprise instructions stored thereon for causing an apparatus to perform the method of the fifth aspect. For example, the instructions may cause the apparatus to perform at least receiving transaction data for a device provisioning from a decentralized ledger system.

In some example embodiments, the transaction data may include an authentication response to the at least one authentication request. In some example embodiments, the instructions may further cause the apparatus to perform sending the at least one authentication request to the decentralized ledger system, and sending an authentication confirmation to the decentralized ledger system after receiving the transaction data.

In some example embodiments, the transaction data may include a configuration request. In some example embodiments, the instructions may further cause the apparatus to perform sending a configuration response to the configuration request to the decentralized ledger system.

In some example embodiments, the decentralized ledger system may comprise at least one of a blockchain network, an IOTA, and/or the like. At least one communication with the decentralized ledger system in some example embodiments may be based on a masked authentication message.

In some example embodiments, the instructions may further cause the apparatus to obtain an identifier of the registrant through an out-of-band mechanism to receive transaction data for device provisioning from the decentralized ledger system based on the obtained identifier.

Drawings

Some example embodiments will now be described, by way of non-limiting examples, with reference to the accompanying drawings.

Fig. 1 shows an example of device provisioning in DPP.

Fig. 2 shows an example of device provisioning in an example embodiment.

FIG. 3 illustrates an example method for device provisioning in an example embodiment.

FIG. 4 shows an example of transaction data for device provisioning in an example embodiment.

FIG. 5 illustrates an example of a decentralized ledger system in an example embodiment.

FIG. 6 illustrates an example of a decentralized ledger system in an example embodiment.

FIG. 7 illustrates an example method for device provisioning in example embodiments.

Fig. 8 shows an example of bootstrapping in an example embodiment.

FIG. 9 illustrates an example method for device provisioning in an example embodiment.

Fig. 10 shows an example of authentication in an example embodiment.

FIG. 11 illustrates an example method for device provisioning in example embodiments.

Fig. 12 shows an example of authentication in an example embodiment.

FIG. 13 illustrates an example method for device provisioning in an example embodiment.

FIG. 14 illustrates an example method for device provisioning in an example embodiment.

FIG. 15 illustrates an example method for device provisioning in an example embodiment.

FIG. 16 illustrates an example method for device provisioning in example embodiments.

Fig. 17 shows an example of device provisioning in an example embodiment.

FIG. 18 illustrates an example apparatus for device provisioning in example embodiments.

FIG. 19 shows an example device for device provisioning in example embodiments.

FIG. 20 illustrates an example device for device provisioning in example embodiments.

FIG. 21 shows an example device for device provisioning in an example embodiment.

Detailed Description

According to the DPP, for example, as illustrated by the one-way dashed arrow in fig. 1, device 100 (e.g., a mobile device or a logical entity of a mobile device) may register and provision device 110 (e.g., a mobile device) and device 120 (e.g., an access point) to establish device-to-device communication between device 110 and device 120, as illustrated by the two-way dashed arrow in fig. 1.

In DPP, a public key may be used to identify and authenticate a device, and a private key associated with the public key may be generated within the respective device and protected from disclosure. Trust in a public key is a guarantee that the private key is known only to the entity that presents or responds to the public key, which can be obtained by bootstrapping. The authenticity of the key can then be checked, for example, by a hash table of the public key.

For example, device 100 may obtain bootstrap information from

devices

110 and 120 using out-of-band (OOB) mechanisms such as Quick Response (QR) code scanning, near Field Communication (NFC) taps, tag strings, and Bluetooth Low Energy (BLE) exchanges, among others. Bootstrap information from device 110 (e.g., information included in the QR code of device 110) may include the public key from device 110, and bootstrap messages from device 120 (e.g., information included within the QR code of device 120) may include the public key from device 120.

However, trust of the public key and thus secure communication between devices may not be ensured. For example, a QR code encoding a public key may be appended to or accompany the sending entity, e.g., as part of a packing slip. The sub-version of the exchange may include replacing the public key of an honest sending entity with a QR code encoding the public key of an attacker by affixing the public key of the QR code as a label on top of the QR code label of the sending entity, or by replacing a packing slip containing the QR code public key of the attacker, or by replacing the scanning application with a malicious version. For example, for DPP authentication and provisioning, a service attack is possible when an attacker sees a hash table of public keys and constructs a false DPP authentication request frame to overwhelm the device (or responder herein) by inducing the device to perform a Diffie-Hellman exponent in response to the initiation of the DPP authentication protocol.

Fig. 2 illustrates an example device provisioning in an example embodiment, wherein during the device provisioning, communication between the device 100 and the devices to be provisioned (e.g.,

devices

110, 120, etc.) is performed via an decentralized ledger system 200.

In various embodiments, the decentralized ledger system 200 can be implemented based on any suitable technique, such as based on block chain techniques. For example, the decentralized ledger system 200 may be a blockchain network. In another example, the decentralized ledger system 200 may be based on IOTA, which is an open source distributed ledger and cryptocurrency designed for the internet of things (IoT) in order to enable faster and freer implementations. Further, for example, a Masked Authentication Message (MAM), which is an extension module of the IOTA, may be used for communication between various devices, such that, for example, different operators or groups of devices may isolate and encrypt/decrypt information by using different channel and/or side keys (side keys).

Then, for bootstrapping, for example, the device 110 (or other device such as the device 120) may publish or provide bootstrap information including the public key of the device 110 to the decentralized ledger system 200 instead of providing (e.g., pasting somewhere) a QR code encoding its public key, and the device 100 may access the decentralized ledger system 200 to obtain bootstrap information for the device 110 instead of scanning a QR code pasted somewhere that may be tampered with. Similarly, device 120 may also publish its bootstrap information, including its public key, to decentralized billing system 200 so that device 100 may obtain bootstrap data for device 120 from decentralized billing system 200 during bootstrapping. The information passed to the decentralized ledger system 200 can be immutable, thereby further ensuring trust of public keys and secure communication between devices.

As shown in fig. 2, in some embodiments, one or more of the

devices

100, 110, and 120 may also access the decentralized ledger system 200 via one or more intermediary devices, such as the

gateways

210, 220, and 230 in fig. 2. Thus, for example, one or more of the

devices

100, 110, and 120 can communicate with one or more intermediate devices, such as the

gateways

210, 220, and 230, via any suitable communication protocol, and one or more intermediate devices, such as the

gateways

210, 220, and 230, can forward information from one or more of the

devices

100, 110, and 120 to the decentralized ledger system 200, and can also obtain information from the decentralized ledger system 200 upon request from one or more of the

devices

100, 110, and 120.

In various embodiments,

devices

100, 110, 120, 210, 220, 230, etc. in fig. 2 may comprise any suitable device, such as an Access Point (AP), a Base Station (BS), a communication device, a User Equipment (UE), a Subscriber Station (SS), a portable subscriber station, a Mobile Station (MS), an Access Terminal (AT), etc. For example, the devices 100, 110, 120, 210, 220, 230, etc. in fig. 2 may include, but are not limited to, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also known as a gNB), a Remote Radio Unit (RRU), a Radio Header (RH), a Remote Radio Header (RRH), a relay, an Integrated and Access Backhaul (IAB) node, a low power node such as a femto node, a pico node, a non-terrestrial network (NTN) or non-terrestrial network device such as a satellite network device, a Low Earth Orbit (LEO) satellite and a geosynchronous orbit (GEO) satellite, an aircraft network device, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable terminal device, a Personal Digital Assistant (PDA), a portable computer, a desktop computer, an image capture terminal device such as a digital camera, a game terminal device, a music storage and playback device, a vehicular wireless terminal device, a wireless end point, a mobile station, a LEE, an installation dog device (LME), a USB, a smart client device, a wearable client device (HMD), a wearable client device, a wearable application, a wearable display device (e) or other wearable vehicle, e.g. a wearable display, tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronics devices, devices operating on commercial and/or industrial wireless networks, and the like.

Further, it is understood that the number of devices registered in the device provisioning process and the relationship between the devices may not be limited to the example as shown in fig. 2. For example, more devices may be configured by device 100; device 110 and device 100 may be the same device; the device 100 may be any suitable logical entity with the ability to register and provision devices for device-to-device or infrastructure communications; the device 100 may delegate its management to another device to share management and provide a backup of the ability to register and provision devices for device-to-device or infrastructure communication; and so on.

Fig. 3 shows an example method 300 for provisioning a device in an example embodiment, which may include a step 310 of determining transaction data for device provisioning and a step 320 of sending the transaction data to the decentralized ledger system 200.

For example, in connection with the example of fig. 2, for bootstrapping, the example method 300 may be performed by one or more of the

devices

110, 120, 210, 230, etc. provided by the device 100, and the transaction data may include bootstrapping information.

The bootstrap information may include information such as a bootstrap public key, a global operation class channel, a DPP authentication channel list, and the like. For example, bootstrap information for device 110 (or other devices to be provided, such as device 120) may include a public key for device 110.

The transactional data determined in step 310 may be in any suitable format and include any suitable content depending on the decentralized ledger system employed. In various embodiments, the transaction data determined in step 310 may include, but is not limited to, one or more bundles in the IOTA, one or more blocks in a chain of blocks, or any other data unit in other decentralized ledger systems. For example, where decentralized ledger system 200 is implemented based on blockchain techniques, the transaction data determined in step 310 can correspond to one or more transactions included in one or more blocks of the blockchain (or transaction blocks herein). For example, where the decentralized ledger system 200 is implemented based on an IOTA, the transaction data determined in step 310 may correspond to one or more transactions included in one or more bundles of the IOTA (or transaction bundles herein).

For example, fig. 4 shows an example of the format and content of the transactional data determined in step 310 in the case where decentralized ledger system 200 is implemented, for example, based on IOTA. It should be understood that the IOTA is an example of the decentralized ledger system 200 and that the present disclosure is not limited to IOTAs. In the example of fig. 4, the bootstrap information may be encoded in a "signature message fragment" field 410, which may include 2187 ternary bytes (tryte) (approximately 1.27 kilobytes), for example. The transaction data determined by the IOTA's message fragments in step 310 may use more than one bundle, for example, when one bundle is insufficient to include the entire bootstrap information. If the message or transaction data determined in step 310 is segmented and stored in multiple bundles, the original ternary byte message may be recovered by concatenating multiple segments, for example, in the order of the "currentIndex" field in the corresponding bundle. Further, for example, a "tag" field 420 may include a protocol type that indicates the protocol or process (e.g., bootstrapping, authentication or configuration, etc.) for which the information contained in the bundle is to be used. In addition, "tag" field 420 may also include an identifier of a device, such as an access point. For example, the "tag" field 420 may include 27 ternary bytes to support 27 ²⁷ This may provide a sufficiently large space for the device identifier.

It is understood that the format and content of the transaction data determined in step 310 may not be limited to the example shown in FIG. 4. In an example, the information encapsulated/encoded in the transaction data may also include one or more of: information about frame usage, information about vendor-specific and about transaction data, information about Wi-Fi alliance-specific unique identifier (OUI), information about OUI type, information about encryption suite to be used, information about type of protocol or procedure (e.g., bootstrapping, authentication or configuration, etc.) for which information included in the bundle is to be used (information included in the bundle), information about one or more DPP attributes, etc. In another example, the above example information may be further wrapped/encoded in an IEEE (institute of electrical and electronics engineers) 802.11DPP action frame along with header information such as destination address and source address, and then the IEEE 802.11DPP action frame may be further wrapped/encoded in the transaction data. In another example, one or more of the information in the previous examples, such as the IEEE 802.11DPP action frame, may be further encapsulated/encoded in a Transmission Control Protocol (TCP) packet, and the TCP packet may be further encapsulated or encoded in the transaction data.

In some embodiments, the content and fields in the various transaction data may be based on DPP action frames, e.g., as defined in the Wi-Fi alliance's device provisioning protocol specification, but may be modified/varied. For example, as shown in fig. 4, information such as device identifiers and protocol types may be encoded in a "tag" field 420, communication protocols, and the like, in addition to or instead of being encoded in a "signaturessagefragment" field 410. In another example, any other suitable arrangement of transaction data may be employed, e.g., depending on the decentralized ledger system employed, communication protocols, etc. It should be appreciated that any suitable information for the DPP may be wrapped/encoded in the transaction data in any suitable format and based on any suitable protocol, but is not limited to the above and below examples.

After determining transaction data for the device provisioning in step 310, for example, in step 320, the device to be provisioned by device 100, e.g., device 110, may send the transaction data to decentralized ledger system 200. Depending on the decentralized ledger system employed, the transactional data determined in step 310 can be sent or posted or deployed to the decentralized ledger system 200 in step 320 in any suitable manner.

For example, where the decentralized ledger system 200 is implemented based on IOTA, transaction data can be sent or deployed to the decentralized ledger system 200 in order to approve at least two of the outlying sites in the decentralized ledger system 200 after verifying that at least one directly or indirectly approved transaction data for device provisioning in the decentralized ledger system 200 is valid.

For example, FIG. 5 illustrates an example of the decentralized ledger system 200 implemented based on IOTA, where blocks 501-511 represent transactional data that has been provisioned for devices deployed in the decentralized ledger system 200. For example, block 501 may correspond to bootstrapping associated with device 110 and transaction data including bootstrapping information for device 110, block 502 may correspond to authentication associated with device 110 (described below), block 503 may correspond to configuration associated with device 120 (described below), and so on. Then, when a new transaction corresponding to block 512 is deployed or sent to the decentralized ledger system 200, block 512 can be deployed to validate at least two directly or indirectly approved transaction data for equipment provisioning in the decentralized ledger system 200, and then approve the nibble sites, e.g., blocks 511 and 513, where block 513 is not a transaction for equipment provisioning, but indirectly approves at least one transaction data for DPP, e.g., block 508. Thus, for example, overlapping entanglement (overlap Tang) of the DPP of the decentralized standing book system 200 may be as shown in FIG. 6.

In step 310, the transaction data may be deployed or sent to the decentralized ledger system 200 in any suitable manner, such as by using a Markov Chain Monte Carlo (MCMC) method.

Thus, any device, e.g., device 100, may obtain bootstrapping information IOTA that includes the public key of a registrar device (or registrar, e.g.,

devices

110, 120 registered and provisioned for device-to-device or infrastructure communications, etc.) in the case of an IOTA-based implemented decentralized ledger system 200, e.g., by using a pre-installed application such as an IOTA wallet, rather than by scanning QR codes or utilizing NFC, BTLE, etc., that may be subject to attack or tampering. For example, device 100 may obtain the identification of device 110 by using OOB mechanisms such as QR code scanning, NFC taps, BLE exchanges, and the like. Device 110 may then further obtain bootstrap information including the public key of device 110 from decentralized ledger system 200, e.g., based on the obtained identification of device 110.

For example, the public key of the device to be provisioned may be trusted by exchanging information via the decentralized ledger system 200. In addition, the public key of the device to be provisioned may be updated by issuing a new key on the decentralized ledger system 200. Further, for example, reliability and availability of the communication channel may be improved.

Further, as shown in fig. 7, during bootstrapping, the example method 300 can further include a step 710 of receiving a request from the decentralized ledger system 200 to verify an identity of a registrant of the bootstrap information, a step 720 of determining a signature for the identity verification, and a step 730 of sending the signature to the decentralized ledger system 200. Thus, for example, proof of possession of a private key of a registrant, e.g.,

device

110, 120, etc., of the bootstrap information, e.g., provided by device 100, may be supported.

For example, as shown in fig. 8, device 100 may obtain the identity of device 110, e.g., by using OOB mechanisms such as QR code scanning, NFC taps, BLE exchanges, and so on. For example, the device 100 may be equipped with a camera for scanning a QR code provided by the device 110 in order to identify the device 110. The device 110 may then further obtain bootstrap information including the public key of the device 110 from the decentralized ledger system 200 based on the obtained identification of the device 110. As shown in fig. 8, after the device 100 obtains bootstrap information for the device 110 including the device's 110 public key via the decentralized ledger system 200 (820), the device 100 may request verification of the device's 110 identity to prove that the public key is indeed owned by the device 110 (830). For example, at 830, the device 100 may perform step 310 of the example method 300 to determine transaction data that includes a request to verify the identity of the device 110. For example, the request may include a random challenge such as a nonce or random text. Then, at 830, the device 100 may perform step 310 of the example method 300 to send transaction data including the validation request to the decentralized ledger system 200.

The device 110 may then perform step 710 of the example method 300 to receive a validation request from the decentralized ledger system 200. Device 100 may then perform step 720 of example method 300, for example, by using the random challenge in the request and the private key of device 110 to determine the signature. Device 110 may then perform step 730 of example method 300 to send the signature to the decentralized ledger system. For example, similar to

steps

310 and 320, in step 730, transaction data including a signature can be determined and then sent or deployed to the decentralized ledger system 200.

Device 100 may then obtain the signature from decentralized ledger system 200 (840), and may then verify the signature, for example, through a random challenge and the public key of device 110 (850).

In another embodiment, the identification of the device 110 may also be initiated by the device 110.

As shown in fig. 8, smart contracts 810 may be pre-deployed to decentralized ledger system 200 and may be used during the process of certifying the identity of device 110, e.g., forwarding information, such as signatures, to be exchanged between

devices

100 and 110. Thus, for example, actions/operations of

devices

100 and 110 may be tracked and recorded in the decentralized ledger system 200.

In another embodiment, proof of possession of the identity or private key of the registrant device may be initiated by the smart contract 810 rather than the device 100. For example, smart contract 810 may be invoked when a public key is obtained and device 100 will be required to initiate a random challenge and then forward the random challenge to device 110, which is the owner of the public key. Smart contract 810 may then forward the signature of device 110 to device 100 for verification in device 100, or may verify the signature in smart contract 810.

In accordance with the decentralized ledger system 200, the intelligent contracts 810 can be implemented in any suitable manner. For example, the intelligent contracts 810 may be written in any suitable intelligent Contract programming language, such as Serpent, solidity, etc., and may then be compiled into Contract byte code (Contract ByteCode), and may then be deployed to the decentralized ledger system 200. After being deployed to decentralized ledger system 200, a contract address may be assigned to smart contract 810 and may be automatically invoked or executed during a later transaction.

It should be understood that the use of smart contracts is not limited to the identification of registrant devices. For example, an intelligent contract may be configured on the decentralized ledger system 200 for any other data/information (e.g., bootstrap information) exchange between

devices

100 and 110.

Further, for example, in the case of implementing the decentralized ledger system 200 based on IOTA, a Masked Authentication Message (MAM) may be used, which may support a plurality of modes, such as a public mode, a private mode, and a restricted mode. Thus, different operators or groups of devices may use different channel identities and side keys to isolate and encrypt/decrypt information. For example, the channel identity and side keys may be distributed by deploying one or more smart contracts.

Similar to step 310 of the example method 300, when using a MAM, for example, a bootstrap message including bootstrap information may be encapsulated as a payload of the transaction data determined in step 310. If the bootstrap message is long, the message or data may be split into one or more parts, for example into one or more blocks when implementing the decentralized ledger system 200 based on blockchain techniques, or into one or more bundles when implementing the decentralized ledger system 200 based on IOTA. Further, for example, the content in the message may be encrypted and digitally signed; the "tag" field can be used to implement message filtering; and so on.

It is to be appreciated that while the above (and possibly the following) examples illustrate device 110 being provided by device 100, in other examples or embodiments, one or more devices, such as

devices

110, 120, etc., may be provisioned or configured by any one or more suitable devices having the capability to register and provision devices for device-to-device or infrastructure communications. For example, device 110 may be a logical entity of another device, such as

device

110 or 120.

Further, it will be appreciated that although the above examples are described for bootstrapping, one or more features and aspects described above may also be applied to other processes in device provisioning, such as authentication and configuration. For example, MAM and/or smart contracts may also be used for authentication, configuration, and any other processes in device provisioning. Further, for example, proof of possession of the registrant's private key may be initiated by any device in a device provisioning, such as

devices

110, 120, 210, 220, and the like, and is not limited to being initiated by a configurator device (or configurator) such as device 100, which device 100 has the ability to register and provision one or more devices for device-to-device or infrastructure communications.

For example, in one embodiment, for an authentication process in a device provisioning, the transaction data determined in step 310 and transmitted in step 320 may include an authentication response to at least one authentication request. Then, as shown in fig. 9, the example method 300 may further include the step 910 of receiving at least one authentication request from the decentralized accounting system 200, and the step 920 of receiving an authentication confirmation from the decentralized accounting system 200 after sending the transaction data.

For example, authentication may be initiated by a configurator device (e.g., device 100) or a registrar device (e.g., device 110), also referred to herein as an initiator device or initiator. A device that initiates authentication in response to an initiator may also be referred to herein as a responder device or responder. Fig. 10 shows an example in which device 100 acts as the initiator of the authentication and device 110 acts as the responder of the authentication.

As shown in fig. 10, the device 100 as the initiator may send at least one authentication request to the decentralized ledger system 200, for example by performing steps 310 and 320 (1010). The device 110 may then perform step 910 to receive an authentication request from the device 110 from the decentralized ledger system 100. In various embodiments, the at least one authentication request may include any information suitable for authentication, such as an initiator protocol key attribute indicating its public protocol key, a wrapping data attribute containing an initiator random number (nonce) attribute and an initiator capability attribute, and so forth.

Then, in various embodiments, the responder device 110 may perform any suitable operation after receiving the authentication request. For example, when the device 110 determines that the initiator's bootstrap key has been bootstrapped, the device 110 may perform

steps

310 and 320 to send an authentication response to the decentralized ledger system 200. For example, the authentication response may include information such as DPP status and some wrapping data that may depend on DPP status.

Then, in various embodiments, the device 100 may perform any suitable operations after receiving the authentication response from the decentralized ledger system 200 (1020). For example, the apparatus 100 may check the DPP status, e.g., whether the DPP status is set to status _ OK, etc. The device 100 may then perform

steps

310 and 320 to send an authentication confirmation to the decentralized ledger system 200 (1030). For example, the authentication confirmation may include information such as DPP status, a hash of the bootstrapping key of the responder, and the originator of the authentication request corresponding to the authentication confirmation.

Then, for example, if the responder receives an authentication confirmation from the decentralized ledger system 200 in step 920, it can check the DPP status. For example, if the DPP status is status _ NOT _ COMPATIBLE or status _ AUTH _ FAILURE, the responder may unwrap the data portion of the package in an authentication confirmation to obtain the reason for the FAILURE.

As shown in fig. 10, in one embodiment, the information/message exchange may be via smart contracts 1040 previously deployed to decentralized ledger system 200, such that one or more actions may be tracked and logged during authentication. In another embodiment, for example, MAM may be used.

In another embodiment, for example, for a configuration process in a device provisioning, the transaction data determined in step 310 and sent in step 320 may include a configuration request. Then, as shown in FIG. 11, the example method 300 can further include a step 1110 of receiving a configuration response to the configuration request from the decentralized ledger system 200.

Fig. 12 shows an example of a configuration process in a device provisioning, where the device 110 initiates the provisioning phase by performing

steps

310 and 320 to send a configuration request to the decentralized ledger system 200. For example, the configuration request may include information such as a DPP configuration attribute object generated by the device 110. Device 100 can then receive a configuration request from device 110 from decentralized ledger system 200 (1210). Device 100 may perform

steps

310 and 320 to send a configuration response to decentralized ledger system 200 (1220). For example, the configuration response may include configuration information for the device 110, a value identifying request/response transactions that may be replicated from the configuration request, information regarding status, and so forth. Device 110 may then receive a configuration response from decentralized ledger system 200 at step 1110 and may be provided with information in the response, for example, to establish secure access to the access point.

Further, as shown in fig. 12, in one embodiment, the information/message exchange may be via a smart contract 1230 previously deployed to the decentralized ledger system 200 so that one or more actions may be tracked and logged during configuration. In another embodiment, for example, MAM may be used.

Fig. 13 illustrates an example method 1300 corresponding to example method 300. As shown in fig. 13, corresponding to step 320 of the example method 300, the example method 1300 may include a step 1310 of receiving transaction data for device provisioning from a decentralized ledger system, such as the decentralized ledger system 200 described above. For example, the device may obtain the identity of the registrar device by using OOB mechanisms such as QR code scanning, NFC taps, BLE exchanges, and the like. The device may then obtain transaction data for device provisioning from the decentralized ledger system 200, for example, based on the obtained identity of the registrar device.

One or more example aspects and/or features of the example method 1300 have been described above in connection with the example of the example method 300. For example, step 1310 may include operations/

steps

820 or 710 or 840 shown in fig. 8,

steps

910 or 1020 or 920 shown in fig. 10, and operations/

steps

1210 or 1110 shown in fig. 12.

Thus, for example, as shown in fig. 14, where the transaction data received in step 1310 includes bootstrapping information, step 1310 may include operation 820 shown in fig. 8. Further, to prove the identity of device 110, the example method may further include step 1410, step 1420, and step 1430, step 1410 sending a request to decentralized ledger system 200 to verify the identity of the registrant of the bootstrap information, which may include operation 830 in fig. 8, step 1430 receiving a response to the request from decentralized ledger system 200, which may include operation 840 in fig. 8, and step 1430 determining the identity of the registrant based on the bootstrap information and information in the response, which may include operation 850 in fig. 8.

For example, as shown in fig. 15, where the transaction data received in step 1310 includes an authentication response to at least one authentication request, step 1310 may include operation 1010 as shown in fig. 10. Further, as shown in fig. 15, the example method 1300 may also include

steps

1510 and 1520, the step 1510 sending at least one authentication request to the decentralized ledger system, which may include operation 1010 in fig. 10, the step 1520 sending an authentication confirmation to the decentralized ledger system after receiving the transaction data, which may include operation 1030 in fig. 10.

For example, as shown in fig. 16, where the transaction data received in step 1310 includes a configuration request, step 1310 may include operation 1210 shown in fig. 12. Further, as shown in fig. 16, the example method 1300 may also include a step 1610 of sending a configuration response to the configuration request to the decentralized ledger system, which may include operation 1220 in fig. 12.

Fig. 17 illustrates an example of device provisioning implemented by utilizing the

example methods

300 and 1300 described above, where the device 110 is an example of a registrar to be provisioned by the device 100 as a configurator.

As shown in fig. 17, both

devices

100 and 110 may perform the steps in

example methods

300 and 1300 to implement device provisioning. For example, steps 310 and/or 320 of the example method 300 may be used where information is sent to the decentralized ledger system 200 in both the

example methods

300 and 1300, and thus may be utilized by the

devices

100 and 110. Similarly, step 1310 of example method 1300 may be used in instances where information is received from the decentralized ledger system 200 in both of

example methods

300 and 1300, and thus may be used by both

devices

100 and 110.

For example, during a bootstrapping process, as an example of a configurator, device 110, as a registrant to be provisioned by device 100, may perform

steps

310 and 320 of example method 300 to send bootstrapping information to decentralized ledger system 200. Device 110 may perform step 1310 of example method 1300 to receive bootstrap information for device 1100 from decentralized ledger system 200. Further, for example, the device 100 may perform step 1410 of the example method 1300 (which may, for example, include or be similar to

steps

310 and 320 of the example method 300) to send a request to verify the identity of the device 110 to the decentralized ledger system 200. Device 110 may perform step 710 of example method 300 (which may, for example, comprise or be similar to step 1310 of example method 1300) to receive a request to verify identity. The device 110 may then perform step 710 of the example method 300 to determine a signature for authentication, and may perform method 730 of the example method 300 (which may include or be similar to

steps

310 and 320, for example) to send the signature to the decentralized ledger system 200. Device 100 may then perform step 1420 of example method 1300 (which may include or be similar to step 1310), and perform step 1430 to determine the identity of device 110 or whether device 110 is the owner of a private key corresponding to the public key obtained in the bootstrap information.

As shown in fig. 17, in one embodiment, a smart contract may be used during an information exchange for bootstrapping. Also, for example, MAM may be used. Furthermore, as described above, in another embodiment, authentication may also be initiated, for example, by a smart contract.

For example, during an authentication process initiated by the device 100, the device 100 may perform step 1510 of the example method 1300 (which may include or be similar to

steps

310 and 320 of the example method 300, for example) to send at least one authentication request to the decentralized ledger system 200. The device 110 may then perform step 910 of the example method 300 (which may, for example, include or be similar to step 1310 of the example method 1300) to receive at least one authentication request from the decentralized ledger system 200, and may perform

steps

310 and 320 to send an authentication response to the decentralized ledger system. The device 100 may then perform step 1310 of the example method 1300 to receive an authentication response from the decentralized ledger system 200, and may perform step 1520 of the example method 1300 (which may include or be similar to, for example, steps 310 and 320 of the example method 300) to send an authentication confirmation to the decentralized ledger system 200. The device 110 may then perform step 920 of the example method 300 (which may, for example, include or be similar to step 1310 of the example method 1300) to receive an authentication confirmation from the decentralized ledger system 200.

As shown in fig. 17, in one embodiment, a smart contract may be used during the exchange of information for authentication. Also, for example, MAM may be used. Further, it should be understood that in another embodiment, authentication may be initiated by the device 110.

For example, during a configuration process initiated by the device 110, the device 110 may perform

steps

310 and 320 of the example method 300 to send a configuration request to the decentralized ledger system 200. The device 100 may then perform step 1310 of the example method 1300 to receive the configuration request from the decentralized ledger system 200, and may perform step 1610 of the example method 1300 (which may, for example, include or be similar to

steps

310 and 320 of the example method 300) to send a configuration response to the decentralized ledger system 200. Device 110 may then perform step 1110 of example method 300 (which may, for example, comprise or be similar to step 1310 of example method 1300) to receive a configuration response from decentralized ledger system 200.

As shown in FIG. 17, in one embodiment, a smart contract may be used during an exchange of information for a configuration. Also, for example, MAM may be used.

FIG. 18 illustrates an example apparatus 1800 for device provisioning in one embodiment. For example, the example apparatus 1800 may be at least a portion of any device, such as the

devices

100, 110, 120, 210, 220, 230, etc. in the above examples.

As shown in fig. 18, the example apparatus 1800 may include at least one processor 1810 and at least one memory 1820 that may include computer program code 1830. The at least one memory 1820 and the computer program code 1830 may be configured to, with the at least one processor 1810, cause the apparatus 1800 to perform at least the steps of at least one of the example method 300 and the example method 1300 described above.

In various example embodiments, the at least one processor 1810 in the example apparatus 1800 may include, but is not limited to: at least one hardware processor comprising at least one microprocessor, such as a Central Processing Unit (CPU); a portion of at least one processor; and any other suitable special purpose processor, such as a processor developed based on, for example, field Programmable Gate Arrays (FPGAs) and Application Specific Integrated Circuits (ASICs). In addition, the at least one processor 1810 may also include at least one other circuit or element not shown in fig. 18.

In various example embodiments, the at least one memory 1820 in the example apparatus 1800 may include various forms of at least one storage medium, such as volatile memory and/or non-volatile memory. Volatile memory can include, but is not limited to, random Access Memory (RAM), cache memory, and the like. Non-volatile memory may include, but is not limited to, for example, read Only Memory (ROM), hard disk, flash memory, and the like. In addition, at least the memory 1820 can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing.

Moreover, in various example embodiments, the example apparatus 1800 may also include at least one other circuit, element, and interface, such as at least one I/O interface, at least one antenna element, and/or the like.

In various example embodiments, the circuits, components, elements, and interfaces in the example apparatus 1800, including the at least one processor 1810 and the at least one memory 1820, may be coupled together in any suitable manner, e.g., electrically, magnetically, optically, electromagnetically, etc., by any suitable connection including, but not limited to, a bus, a crossbar, wiring, and/or wireless lines.

It is understood that the structure for the equipment provisioning apparatus is not limited to the example apparatus 1800 described above.

Fig. 19 illustrates another example device 1900 for device provisioning in an embodiment. For example, the example apparatus 1900 may be configured to perform at least the steps of the example method 300.

As shown in fig. 19, exemplary device 1900 may include means 1910 for performing step 310 of exemplary method 300 and means 1920 for performing method 320 of exemplary method 300. In one or more other example embodiments, at least one I/O interface, at least one antenna element, etc. may also be included in example device 1900. In one or more other example embodiments, the example apparatus 1900 may further include one or more means for performing one or more additional steps of the example method 300, such as

steps

710, 720, 730, 910, 920, 1110, and/or the like.

In some example embodiments, examples of an apparatus (e.g., apparatuses 1910 and 1920) may include circuitry. For example, examples of the apparatus 1910 may include circuitry configured to perform step 310 of the example method 300, and examples of the apparatus 1920 may include circuitry configured to perform step 320 of the example method 300. In some example embodiments, examples of the apparatus may also include software modules and any other suitable functional entities.

The term "circuitry" in this disclosure may refer to one or more or all of the following: (a) Hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry); (b) Combinations of hardware circuitry and software, such as (if applicable) (i) combinations of analog and/or digital hardware circuitry and software/firmware, and (ii) hardware processors and software (including digital signal processors), software, and any portion of memory that work together to cause an apparatus, such as a mobile telephone or server, to perform various functions; and (c) hardware circuitry and/or a processor, such as a microprocessor or a portion of a microprocessor, that requires software (e.g., firmware) to operate, but may not be present when software is not required to operate. This definition of circuitry applies to one or all uses of the term in this disclosure, including any claims. As a further example, as used in this disclosure, the term circuitry also encompasses embodiments of hardware circuitry alone or a processor (or multiple processors) or a portion of a hardware circuit or microprocessor and its (or its) accompanying software and/or firmware. The term circuitry also encompasses, for example and if applicable to the claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in a server, a cellular network device, or other computing or network device.

Fig. 20 illustrates another example device 2000 for device provisioning in an embodiment. For example, the example apparatus 2000 may be configured to perform at least the steps of the example method 1300.

As shown in fig. 20, exemplary device 2000 may include means 2010 for performing step 310 of exemplary method 1300. In one or more other example embodiments, at least one I/O interface, at least one antenna element, and/or the like may also be included in example apparatus 2000. In one or more other example embodiments, the example apparatus 2000 may also include one or more means for performing one or more additional steps of the example method 1300, such as

steps

1410, 1420, 1430, 1510, 1520, 1610, etc.

Similar to example apparatus 1900, in some example embodiments, an example of an apparatus (e.g., apparatus 2010) may include circuitry. For example, an example of the apparatus 2010 may include circuitry configured to perform step 1310 of the example method 1300. In some example embodiments, examples of the apparatus may also include software modules and any other suitable functional entities.

Fig. 21 illustrates another example device 2100 for device provisioning in an embodiment that includes apparatus (e.g., apparatus 1910 and apparatus 1920) in example device 1900 and apparatus (e.g., apparatus 2010) in example device 2000. In another embodiment, the apparatus for device provisioning may include at least one of the

example devices

1800, 1900, 2000, and 2100 described above.

It should be understood that the present disclosure is not limited to the above-described exemplary embodiments.

Another example embodiment may be directed to computer program code or instructions which may cause an apparatus to perform at least the various methods described above. Another example embodiment may be directed to a computer readable medium having stored thereon such computer program code or instructions. In some example embodiments, such computer-readable media may include various forms of at least one storage medium, such as volatile memory and/or non-volatile memory. Volatile memory can include, but is not limited to, for example, RAM, cache memory, and the like. Non-volatile memory can also include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing.

Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise", "comprising", and the like are to be construed as being inclusive rather than exclusive or exhaustive; that is, the term "coupled," as used generally herein, in the sense of "including, but not limited to," means that two or more elements may be directly connected or may be connected through one or more intervening elements. Also, as generally used herein, the term "connected" refers to two or more elements that may be connected directly or through one or more intermediate elements. Furthermore, the words "herein," "above," "below," and words of similar import, as used in this application, are intended to refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the specification using the singular or plural number may also include the plural or singular number respectively. The word "or" refers to a list of two or more items that covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

Furthermore, conditional language, e.g., "may," "for example," "such as," etc., as used herein, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states unless otherwise specifically stated or otherwise understood in the context of the use. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements or states are included or are to be performed in any particular embodiment.

While some embodiments have been described, these embodiments have been presented by way of example, and are not intended to limit the scope of the disclosure. Indeed, the devices, methods, and systems described herein may be embodied in various other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the disclosure. For example, when blocks are presented in a given arrangement, alternative embodiments may perform similar functions using different components and/or circuit topologies, and some blocks may be deleted, moved, added, subdivided, combined, and/or modified. At least one of these blocks may be implemented in a variety of different ways. The order of these blocks may also be changed. Any suitable combination of the elements and acts of some of the embodiments described above can be combined to provide further embodiments. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the disclosure.

Claims

1. A method, comprising:

determining transaction data for device provisioning; and

and sending the transaction data to a decentralized ledger system.

2. The method of claim 1, wherein the transaction data includes bootstrap information.

3. The method of claim 2, further comprising:

receiving a request from the decentralized ledger system to verify an identity of a registrant of the bootstrapping information;

determining a signature for the authentication; and

and sending the signature to the decentralized ledger system.

4. The method of claim 1, wherein the transaction data comprises an authentication response to at least one authentication request.

5. The method of claim 4, further comprising:

receiving the at least one authentication request from the decentralized ledger system; and

after sending the transaction data, receiving an authentication confirmation from the decentralized ledger system.

6. The method of claim 1, wherein the transaction data comprises a configuration request.

7. The method of claim 6, further comprising:

receiving a configuration response to the configuration request from the decentralized ledger system.

8. The method of any one of claims 1 to 7, wherein the decentralized ledger system comprises at least one of a blockchain network and an IOTA.

9. The method of claim 8, wherein the at least one communication with the decentralized ledger system is based on a masked authentication message.

10. The method of any of claims 1-9, wherein the at least one communication with the decentralized ledger system is via at least one intelligent contract deployed in the decentralized ledger system and/or the at least one intelligent contract automatically deployed in the decentralized ledger system.

11. The method of any one of claims 1 to 10, wherein the transaction data approves at least two points in the decentralized ledger after verifying that at least one directly or indirectly approved transaction data provisioned for equipment in the decentralized ledger system is valid.

12. A method, comprising:

transaction data for device provisioning is received from the decentralized ledger system.

13. The method of claim 12, wherein the transaction data includes bootstrap information.

14. The method of claim 13, further comprising:

sending a request for verifying the identity of the registrant of the bootstrap information to the decentralized ledger system;

receiving a response to the request from the decentralized ledger system; and

determining an identity of the registrant based on the bootstrapping information and the information in the response.

15. The method of claim 12, wherein the transaction data comprises an authentication response to at least one authentication request.

16. The method of claim 15, further comprising:

sending the at least one authentication request to the decentralized ledger system; and

after receiving the transaction data, sending an authentication confirmation to the decentralized ledger system.

17. The method of claim 12, wherein the transaction data comprises a configuration request.

18. The method of claim 17, further comprising:

sending a configuration response to the configuration request to the decentralized ledger system.

19. The method of any one of claims 12 to 18, wherein the decentralized ledger system comprises at least one of a block chain network and an IOTA.

20. The method of claim 19, wherein the at least one communication with the decentralized ledger system is based on a masked authentication message.

21. The method of any of claims 12 to 20, wherein the at least one communication with the decentralized standing system is via at least one intelligent contract deployed in the decentralized standing system and/or the at least one intelligent contract automatically deployed in the decentralized standing system.

22. The method of any of claims 12 to 21, wherein the transaction data approves at least two points in the decentralized ledger after verifying that at least one directly or indirectly approved transaction data for equipment provisioning in the decentralized ledger system is valid.

23. The method of any of claims 12 to 22, further comprising:

an identifier of a registrant is obtained through an out-of-band mechanism, and transaction data for device provisioning is received from the decentralized ledger system based on the obtained identifier.

24. An apparatus, comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform determining transaction data for a device provisioning and sending the transaction data to a decentralized ledger system.

25. The apparatus of claim 24, wherein the transaction data includes bootstrap information.

26. The apparatus of claim 25, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to perform receiving a request from the decentralized ledger system to verify an identity of a registrant of the bootstrap information, determining a signature for the identity verification, and sending the signature to the decentralized ledger system.

27. The apparatus of claim 24, wherein the transaction data comprises an authentication response to at least one authentication request.

28. The apparatus of claim 27, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to perform receiving the at least one authentication request from the decentralized ledger system and receiving an authentication confirmation from the decentralized ledger system after sending the transaction data.

29. The apparatus of claim 24, wherein the transaction data comprises a configuration request.

30. The apparatus of claim 29, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to perform receiving a configuration response to the configuration request from the decentralized ledger system.

31. The apparatus of any one of claims 24 to 30, wherein the decentralized ledger system comprises at least one of a block chain network and an IOTA.

32. The apparatus of claim 31, wherein at least one communication with the decentralized ledger system is based on a masked authentication message.

33. The apparatus according to any one of claims 24 to 32, wherein the at least one communication with the decentralised ledger system is via at least one intelligent contract deployed in the decentralised ledger system and/or the at least one intelligent contract deployed in the decentralised ledger system automatically.

34. The apparatus of any one of claims 24 to 33, wherein the transaction data approves at least two points in the decentralized ledger system after verifying that at least one directly or indirectly approved transaction data for equipment provisioning in the decentralized ledger system is valid.

35. An apparatus, comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform receiving transaction data for device provisioning from a decentralized ledger system.

36. The apparatus of claim 35, wherein the transaction data includes bootstrap information.

37. The apparatus of claim 36, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to perform sending a request to the decentralized ledger system to verify an identity of a registrant of the bootstrapping information, receiving a response to the request from the decentralized ledger system, and determining an identity of the registrant information based on the bootstrapping information in the response and the bootstrapping information.

38. The apparatus of claim 35, wherein the transaction data comprises an authentication response to at least one authentication request.

39. The apparatus of claim 38, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to perform sending the at least one authentication request to the decentralized ledger system, and sending an authentication confirmation to the decentralized ledger system after receiving the transaction data.

40. The apparatus of claim 35, wherein the transaction data comprises a configuration request.

41. The apparatus of claim 40, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to perform sending a configuration response to the configuration request to the decentralized ledger system.

42. The apparatus of any one of claims 35 to 41, wherein the decentralized ledger system comprises at least one of a blockchain network and an IOTA.

43. The apparatus of claim 42, wherein at least one communication with the decentralized ledger system is based on a masked authentication message.

44. The apparatus of any of claims 35 to 43, wherein the at least one communication with the decentralized ledger system is via at least one intelligent contract deployed in the decentralized ledger system and/or the at least one intelligent contract automatically deployed in the decentralized ledger system.

45. The apparatus of any one of claims 35 to 44, wherein the transaction data approves at least two points in the decentralized ledger after verifying that at least one directly or indirectly approved transaction data for equipment provisioning in the decentralized ledger system is valid.

46. The apparatus of claim 35 or 45, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to perform obtaining an identifier of a registrant through an out-of-band mechanism to receive transaction data for device provisioning from the decentralized ledger system based on the obtained identifier.

47. An apparatus, comprising:

means for determining transaction data for provisioning of the device; and

means for sending the transaction data to a decentralized ledger system.

48. An apparatus, comprising:

means for receiving transaction data for device provisioning from the decentralized ledger system.

49. A computer readable medium comprising instructions stored thereon for causing an apparatus to perform at least the method of any of claims 1 to 11.

50. A computer readable medium comprising instructions stored thereon for causing an apparatus to perform at least the method of any of claims 12 to 23.