WO2022006736A1 - Procédés et appareils de provisionnement de dispositif - Google Patents

Procédés et appareils de provisionnement de dispositif Download PDF

Info

Publication number
WO2022006736A1
WO2022006736A1 PCT/CN2020/100628 CN2020100628W WO2022006736A1 WO 2022006736 A1 WO2022006736 A1 WO 2022006736A1 CN 2020100628 W CN2020100628 W CN 2020100628W WO 2022006736 A1 WO2022006736 A1 WO 2022006736A1
Authority
WO
WIPO (PCT)
Prior art keywords
ledger system
decentralized ledger
transaction data
decentralized
request
Prior art date
Application number
PCT/CN2020/100628
Other languages
English (en)
Inventor
Shuning Liu
Yifeng Yao
Original Assignee
Nokia Shanghai Bell Co., Ltd.
Nokia Solutions And Networks Oy
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Shanghai Bell Co., Ltd., Nokia Solutions And Networks Oy, Nokia Technologies Oy filed Critical Nokia Shanghai Bell Co., Ltd.
Priority to PCT/CN2020/100628 priority Critical patent/WO2022006736A1/fr
Priority to CN202080102818.8A priority patent/CN115812292A/zh
Publication of WO2022006736A1 publication Critical patent/WO2022006736A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security

Definitions

  • Various example embodiments relates to methods and apparatuses for device provisioning.
  • a friendly Wi-Fi setup may be enabled based on Device Provisioning Protocol (DPP) , which may also maintain or increase security level for the growth and continued penetration of Wi-Fi technology, for example.
  • DPP Device Provisioning Protocol
  • a method including determining transaction data for device provisioning, and transmitting the transaction data to a decentralized ledger system.
  • the transaction data may include bootstrapping information.
  • the method may further include receiving from the decentralized ledger system a request for verifying an identity of an enrollee of the bootstrapping information, determining a signature for the identity verification, and transmitting the signature to the decentralized ledger system.
  • the transaction data may include an authentication response to at least one authentication request.
  • the method may further include receiving the at least one authentication request from the decentralized ledger system, and receiving an authentication confirmation from the decentralized ledger system after transmitting the transaction data.
  • the transaction data may include a configuration request.
  • the method may further include receiving a configuration response to the configuration request from the decentralized ledger system.
  • the decentralized ledger system may include at least one of a block chain network, IOTA, and so on. In some example embodiments, at least one communication with the decentralized ledger system may be based on Masked Authenticated Messaging.
  • At least one communication with the decentralized ledger system may be via at least one smart contract deployed in the decentralized ledger system and/or automated the at least one smart contract deployed in the decentralized ledger system.
  • 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 for device provisioning in the decentralized ledger system are valid.
  • an apparatus in a second aspect, is disclosed.
  • the apparatus may be configured to perform at least the method in the first aspect.
  • the apparatus a configuration may include means for determining transaction data for device provisioning, and means for transmitting the transaction data to a decentralized ledger system.
  • the transaction data may include bootstrapping information.
  • the apparatus may further include means for receiving from the decentralized ledger system a request for verifying an identity of an enrollee of the bootstrapping information, means for determining a signature for the identity verification, and means for transmitting the signature to the decentralized ledger system.
  • the transaction data may include an authentication response to at least one authentication request.
  • the apparatus may further include means for receiving the at least one authentication request from the decentralized ledger system, and means for receiving an authentication confirmation from the decentralized ledger system after transmitting the transaction data.
  • the transaction data may include a configuration request.
  • the apparatus may further include means for receiving a configuration response to the configuration request from the decentralized ledger system.
  • the decentralized ledger system may include at least one of a block chain network, IOTA, and so on. In some example embodiments, at least one communication with the decentralized ledger system may be based on Masked Authenticated Messaging.
  • At least one communication with the decentralized ledger system may be via at least one smart contract deployed in the decentralized ledger system and/or automated the at least one smart contract deployed in the decentralized ledger system.
  • 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 for device provisioning in the decentralized ledger system are valid.
  • an apparatus including 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 to perform at least the method in the first aspect.
  • 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 determining transaction data for device provisioning, and transmitting the transaction data to a decentralized ledger system.
  • the transaction data may include bootstrapping information.
  • 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 from the decentralized ledger system a request for verifying an identity of an enrollee of the bootstrapping information, determining a signature for the identity verification, and transmitting the signature to the decentralized ledger system.
  • the transaction data may include an authentication response to at least one authentication request.
  • 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 the at least one authentication request from the decentralized ledger system, and receiving an authentication confirmation from the decentralized ledger system after transmitting the transaction data.
  • the transaction data may include a configuration request.
  • 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.
  • the decentralized ledger system may include at least one of a block chain network, IOTA, and so on. In some example embodiments, at least one communication with the decentralized ledger system may be based on Masked Authenticated Messaging.
  • At least one communication with the decentralized ledger system may be via at least one smart contract deployed in the decentralized ledger system and/or automated the at least one smart contract deployed in the decentralized ledger system.
  • 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 for device provisioning in the decentralized ledger system are valid.
  • a computer readable medium may include instructions stored thereon for causing an apparatus to perform the method in the first aspect.
  • the instructions may cause the apparatus to perform at least determining transaction data for device provisioning, and transmitting the transaction data to a decentralized ledger system.
  • the transaction data may include bootstrapping information.
  • the instructions may further cause the apparatus to perform receiving from the decentralized ledger system a request for verifying an identity of an enrollee of the bootstrapping information, determining a signature for the identity verification, and transmitting the signature to the decentralized ledger system.
  • the transaction data may include an authentication response to at least one authentication request.
  • 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 transmitting the transaction data.
  • the transaction data may include a configuration request.
  • the instructions may further cause the apparatus to perform receiving a configuration response to the configuration request from the decentralized ledger system.
  • the decentralized ledger system may include at least one of a block chain network, IOTA, and so on. In some example embodiments, at least one communication with the decentralized ledger system may be based on Masked Authenticated Messaging.
  • At least one communication with the decentralized ledger system may be via at least one smart contract deployed in the decentralized ledger system and/or automated the at least one smart contract deployed in the decentralized ledger system.
  • 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 for device provisioning in the decentralized ledger system are valid.
  • a method including receiving transaction data for device provisioning from a decentralized ledger system.
  • the transaction data may include bootstrapping information.
  • the method may further include transmitting to the decentralized ledger system a request for verifying an identity of an enrollee of the bootstrapping information, receiving a response to the request from the decentralized ledger system, and determining the identity of the enrollee based on the bootstrapping information and information in the response.
  • the transaction data may include an authentication response to at least one authentication request.
  • the method may further include transmitting the at least one authentication request to the decentralized ledger system, and transmitting an authentication confirmation to the decentralized ledger system after receiving the transaction data.
  • the transaction data may include a configuration request.
  • the method may further include transmitting a configuration response to the configuration request to the decentralized ledger system.
  • the decentralized ledger system may include at least one of a block chain network, IOTA, and so on. In some example embodiments, at least one communication with the decentralized ledger system may be based on Masked Authenticated Messaging.
  • At least one communication with the decentralized ledger system may be via at least one smart contract deployed in the decentralized ledger system and/or automated the at least one smart contract deployed in the decentralized ledger system.
  • 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 for device provisioning in the decentralized ledger system are valid.
  • the method may further include obtaining an identifier of an enrollee through out-of-band mechanism to receive transaction data for device provisioning from the decentralized ledger system based on the obtained identifier.
  • an apparatus in a sixth aspect, is disclosed.
  • the apparatus may be configured to perform at least the method in the fifth aspect.
  • the apparatus may include means for receiving transaction data for device provisioning from a decentralized ledger system.
  • the transaction data may include bootstrapping information.
  • the apparatus may further include means for transmitting to the decentralized ledger system a request for verifying an identity of an enrollee of the bootstrapping information, means for receiving a response to the request from the decentralized ledger system, and means for determining the identity of the enrollee based on the bootstrapping information and information in the response.
  • the transaction data may include an authentication response to at least one authentication request.
  • the apparatus may further include means for transmitting the at least one authentication request to the decentralized ledger system, and means for transmitting an authentication confirmation to the decentralized ledger system after receiving the transaction data.
  • the transaction data may include a configuration request.
  • the apparatus may further include means for transmitting a configuration response to the configuration request to the decentralized ledger system.
  • the decentralized ledger system may include at least one of a block chain network, IOTA, and so on. In some example embodiments, at least one communication with the decentralized ledger system may be based on Masked Authenticated Messaging.
  • At least one communication with the decentralized ledger system may be via at least one smart contract deployed in the decentralized ledger system and/or automated the at least one smart contract deployed in the decentralized ledger system.
  • 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 for device provisioning in the decentralized ledger system are valid.
  • the apparatus may further include means for obtaining an identifier of an enrollee through out-of-band mechanism to receive transaction data for device provisioning from the decentralized ledger system based on the obtained identifier.
  • an apparatus including 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 to perform at least the method in the fifth aspect.
  • 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 receiving transaction data for device provisioning from a decentralized ledger system.
  • the transaction data may include bootstrapping information.
  • 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 transmitting to the decentralized ledger system a request for verifying an identity of an enrollee of the bootstrapping information, receiving a response to the request from the decentralized ledger system, and determining the identity of the enrollee based on the bootstrapping information and information in the response.
  • the transaction data may include an authentication response to at least one authentication request.
  • 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 transmitting the at least one authentication request to the decentralized ledger system, and transmitting an authentication confirmation to the decentralized ledger system after receiving the transaction data.
  • the transaction data may include a configuration request.
  • 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 transmitting a configuration response to the configuration request to the decentralized ledger system.
  • the decentralized ledger system may include at least one of a block chain network, IOTA, and so on. In some example embodiments, at least one communication with the decentralized ledger system may be based on Masked Authenticated Messaging.
  • At least one communication with the decentralized ledger system may be via at least one smart contract deployed in the decentralized ledger system and/or automated the at least one smart contract deployed in the decentralized ledger system.
  • 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 for device provisioning in the decentralized ledger system are valid.
  • 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 an enrollee through out-of-band mechanism to receive transaction data for device provisioning from the decentralized ledger system based on the obtained identifier.
  • a computer readable medium may include instructions stored thereon for causing an apparatus to perform the method in the fifth aspect.
  • the instructions may cause the apparatus to perform at least receiving transaction data for device provisioning from a decentralized ledger system.
  • the transaction data may include bootstrapping information.
  • the instructions may further cause the apparatus to perform transmitting to the decentralized ledger system a request for verifying an identity of an enrollee of the bootstrapping information, receiving a response to the request from the decentralized ledger system, and determining the identity of the enrollee based on the bootstrapping information and information in the response.
  • the transaction data may include an authentication response to at least one authentication request.
  • the instructions may further cause the apparatus to perform transmitting the at least one authentication request to the decentralized ledger system, and transmitting an authentication confirmation to the decentralized ledger system after receiving the transaction data.
  • the transaction data may include a configuration request.
  • the instructions may further cause the apparatus to perform transmitting a configuration response to the configuration request to the decentralized ledger system.
  • the decentralized ledger system may include at least one of a block chain network, IOTA, and so on. In some example embodiments, at least one communication with the decentralized ledger system may be based on Masked Authenticated Messaging.
  • At least one communication with the decentralized ledger system may be via at least one smart contract deployed in the decentralized ledger system and/or automated the at least one smart contract deployed in the decentralized ledger system.
  • 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 for device provisioning in the decentralized ledger system are valid.
  • the instructions may further cause the apparatus to perform obtaining an identifier of an enrollee through out-of-band mechanism to receive transaction data for device provisioning from the decentralized ledger system based on the obtained identifier.
  • FIG. 1 illustrates an example of device provisioning in DPP.
  • FIG. 2 illustrates an example of device provisioning in an example embodiment.
  • FIG. 3 illustrates an example method for device provisioning in an example embodiment.
  • FIG. 4 illustrates an example of transaction data for device provisioning in an example embodiment.
  • FIG. 5 illustrates an example of the decentralized ledger system in an example embodiment.
  • FIG. 6 illustrates an example of the decentralized ledger system in an example embodiment.
  • FIG. 7 illustrates an example method for device provisioning in an example embodiment.
  • FIG. 8 illustrates an example of bootstrapping in an example embodiment.
  • FIG. 9 illustrates an example method for device provisioning in an example embodiment.
  • FIG. 10 illustrates an example of authentication in an example embodiment.
  • FIG. 11 illustrates an example method for device provisioning in an example embodiment.
  • FIG. 12 illustrates 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 an example embodiment.
  • FIG. 17 illustrates an example of device provisioning in an example embodiment.
  • FIG. 18 illustrates an example apparatus for device provisioning in an example embodiment.
  • FIG. 19 illustrates an example apparatus for device provisioning in an example embodiment.
  • FIG. 20 illustrates an example apparatus for device provisioning in an example embodiment.
  • FIG. 21 illustrates an example apparatus for device provisioning in an example embodiment.
  • a device 100 may enroll and provision a device 110 (e.g. a mobile device) and a device 120 (e.g. an access point) so as to establish a device-to-device communication between the device 110 and the device 120 as illustrated by a two-way dotted arrow in FIG. 1.
  • a device 100 may enroll and provision a device 110 (e.g. a mobile device) and a device 120 (e.g. an access point) so as to establish a device-to-device communication between the device 110 and the device 120 as illustrated by a two-way dotted arrow in FIG. 1.
  • public keys may be used to identify and authenticate devices, and a private key associated with a public key may be generated within respective device and protected from disclosure.
  • Trust in the public key is the assurance that the private key is known only by the entity that is presenting or responding to the public key, which may be obtained through bootstrapping. Then, for example, the genuineness of the key may be checked by a hash table of the public key.
  • the device 100 may obtain bootstrapping information from the device 110 and the device 120 by using an out-of-band (OOB) mechanism such as Quick Response (QR) codes scan, Near Field Communication (NFC) tap, Label Strings and Bluetooth Low Energy (BLE) exchange, or the like.
  • OOB out-of-band
  • QR Quick Response
  • NFC Near Field Communication
  • BLE Bluetooth Low Energy
  • a QR code that encodes a public key may be affixed to the transmitting entity or accompany the transmitting entity, for instance as part of a packing list.
  • Subversion of this exchange may include substituting a QR code that encodes the attacker's public key for the honest transmitting entity’s public key by affixing a QR encoded public key as a sticker on top of the transmitting entity’s QR code sticker, or by exchanging a packing list that contains the attacker’s QR encoded public key, or by replacing the scanning application with a malicious version.
  • a service attack is possible when the attacker sees the hash table of the public key and constructs bogus DPP Authentication Request frames to flood the device responding to the initiation of the DPP Authentication protocol (or the Responder herein) by inducing it to perform Diffie-Hellman exponentiations.
  • FIG. 2 illustrates an example device provisioning in an example embodiment, where communications between the device 100 and the devices to be provisioned (e.g. the devices 110, 120, and so on) during the device provisioning are performed via a decentralized ledger system 200.
  • the devices to be provisioned e.g. the devices 110, 120, and so on
  • FIG. 2 illustrates an example device provisioning in an example embodiment, where communications between the device 100 and the devices to be provisioned (e.g. the devices 110, 120, and so on) during the device provisioning are performed via a decentralized ledger system 200.
  • the decentralized ledger system 200 may be implemented based on any suitable techniques, for example, based on block chain technology.
  • the decentralized ledger system 200 may be a block chain network.
  • the decentralized ledger system 200 may be based on IOTA which is an open-source distributed ledger and crypto currency designed for the Internet of Things (IoT) , so as to achieve a faster and free implementation.
  • IOTA Internet of Things
  • Masked Authenticated Messaging (MAM) which is an extension module of IOTA, may be utilized for communications among various devices, so that, for example, different operators or device groups may isolate and encrypt/decrypt information by using different channels and/or side keys.
  • the device 110 may publish or provide its bootstrapping information including a public key of the device 110 to the decentralized ledger system 200, to replace the manner of providing (for example, affixing somewhere) a QR code which encodes its public key, and the device 100 may access the decentralized ledger system 200 to obtain the bootstrapping information of the device 110, to replace the manner of scanning the QR code affixed somewhere which may have been tampered.
  • the device 120 may also publish its bootstrapping information including its public key to the decentralized ledger system 200 so that the device 100 may obtain the bootstrapping information of the device 120 from the decentralized ledger system 200 during bootstrapping.
  • the information delivered to the decentralized ledger system 200 may be immutable, so that the trust in the public key and secure communication between devices in turn may be ensured.
  • one or more of devices 100, 110, and 120 may also access the decentralized ledger system 200 via one or more intermediate devices such as gateways 210, 220, and 230 in FIG. 2.
  • one or more of devices 100, 110, and 120 may communicate with the one or more intermediate devices such as gateways 210, 220, and 230 through any suitable communication protocols, and the one or more intermediate devices such as gateways 210, 220, and 230 may forward information from one or more of devices 100, 110, and 120 to the decentralized ledger system 200 and may also obtain information from the decentralized ledger system 200 according to the requests from one or more of devices 100, 110, and 120.
  • the devices 100, 110, 120, 210, 220, 230, and so on in FIG. 2 may include any suitable devices, such as an access point (AP) , a base station (BS) , a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , an Access Terminal (AT) , or the like.
  • AP access point
  • BS base station
  • UE user equipment
  • SS Subscriber Station
  • MS Mobile Station
  • AT Access Terminal
  • NodeB or NB node B
  • eNodeB or eNB evolved NodeB
  • NR NB also referred to as a gNB
  • RRU Remote Radio Unit
  • RH radio header
  • RRH remote radio head
  • IAB Integrated and Access Backhaul
  • low power node such as a femto, a pico
  • NTN non-terrestrial network
  • NPN non-ground network device
  • GEO geosynchronous earth orbit
  • an aircraft network device a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras
  • the number of devices enrolled in a procedure of device provisioning and the relationship among these devices may be not limited to the example as shown in FIG. 2.
  • more devices may be configured through the device 100; the device 110 and the device 100 may the same one; the device 100 may be any suitable logical entity with capabilities to enroll and provision devices for device-to-device communication or Infrastructure communication; the device 100 may delegate its management to another device to share management and provide a backup of the capabilities to enroll and provision devices for device-to-device communication or Infrastructure communication; or the like.
  • FIG. 3 illustrates an example method 300 for provisioning devices in an example embodiment, which may include a step 310 of determining transaction data for device provisioning and a step 320 of transmitting the transaction data to a decentralized ledger system 200.
  • the example method 300 may be performed by one or more of the devices 110, 120, 210, 230, and so on which are to be provisioned by the device 100, and the transaction data may include bootstrapping information.
  • the bootstrapping information may include information such as bootstrapping public key, a global operating class channel, a channel list for DPP Authentication, and so on.
  • the bootstrapping information of the device 110 (or other devices to be provisioned such as the device 120) may include a public key of the device 110.
  • the transaction data determined in the step 310 may have any suitable format and include any suitable contents.
  • the transaction data determined in the step 310 may include, but not limited to, one or more bundles in IOTA, one or more blocks in the block chain, or any other data unit in other decentralized ledger system.
  • the transaction data determined in the step 310 may correspond to one or more transactions included in one or more blocks (or transaction blocks herein) of the block chain.
  • the transaction data determined in the step 310 may correspond to one or more transactions included in one or more bundles (or transaction bundles herein) of the IOTA.
  • FIG. 4 illustrates an example of format and contents of the transaction data determined in the step 310 in a case where the decentralized ledger system 200 is implemented for example based on IOTA.
  • IOTA is an example of the decentralized ledger system 200, and the disclosure is not limited to IOTA.
  • the bootstrapping information may be encoded in the “signatureMessageFragment” field 410, which may, for example, include 2187 trytes (about 1.27 Kbytes) . More than one bundle may be utilized for the transaction data determined in the step 310 through message fragmentation of IOTA, for example when one bundle is not enough to include the whole bootstrapping information.
  • the raw tryte message may be restored by concatenating the multiple fragments, for example in an order of the “currentIndex” field in respective bundle.
  • the “tag” field 420 may include a protocol type for indicating the protocol or procedure (e.g. bootstrapping, or authentication, or configuration, or the like) for which the information included in this bundle is to be used.
  • the “tag” field 420 may also include an identifier of a device such as an access point.
  • the “tag” field 420 may include 27 trytes so as to support 27 27 possible values, which may provide a space large enough for device identifier.
  • format and contents of the transaction data determined in the step 310 may be not limited to the example as illustrated in FIG. 4.
  • the information encapsulated/encoded in the transaction data may also include one or more of information on the frame usage, information on vendor specific usage, information on Wi-Fi Alliance specific Organizationally Unique Identifier (OUI) , information on OUI type, information on the crypto suite to use, information on the type of the protocol or procedure (e.g. bootstrapping, or authentication, or configuration, or the like) for which the information included in this bundle is to be used, information on one or more DPP attributes, and so on.
  • OUI Organizationally Unique Identifier
  • the aforementioned example information may be encapsulated/encoded in an IEEE (Institute of Electrical and Electronics Engineers) 802.11 DPP Action frame further with head information such as destination address and source address, and then the IEEE 802.11 DPP Action frame may be further encapsulated/encoded in the transaction data.
  • IEEE 802.11 DPP Action frame may be further encapsulated/encoded in Transmission Control Protocol (TCP) packet, and the TCP packet may be further encapsulated/encoded in the transaction data.
  • TCP Transmission Control Protocol
  • contents and fields in various transaction data may be based on the DPP action frames for example defined in the device provisioning protocol specification of the Wi-Fi Alliance, but may be with modifications/variations.
  • information such as device identifier and protocol type may be encoded in the “tag” field 420, in addition to or in lieu of being coded in the “signatureMessageFragment” field 410.
  • any other suitable arrangement of the transaction data may be adopted, for example depending on the adopted decentralized ledger system, communication protocols, or the like. It is appreciated that any suitable information for DPP may be encapsulated/encoded in the transaction data in any suitable format and based on any suitable protocols, but are not limited to the above and the following examples.
  • a device to be provisioned by the device 100 may transmit the transaction data to a decentralized ledger system 200 in the step 320.
  • the transaction data determined in the step 310 may be transmitted or published or deployed to the decentralized ledger system 200 in any suitable manners in the step 320.
  • the transaction data may be transmitted or deployed to the decentralized ledger system 200 so as to approve at least two tip 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 are valid.
  • FIG. 5 illustrates an example of the decentralized ledger system 200 which is implemented based on IOTA, where blocks 501 ⁇ 511 represent transaction data for device provisioning which have been deployed in the decentralized ledger system 200.
  • block 501 may correspond to a bootstrapping associated with the device 110 and the transaction data including bootstrapping information of the device 110
  • block 502 may correspond to an authentication (to be described below) associated with the device 110
  • block 503 may correspond to a configuration (to be described below) associated with the device 120, or the like.
  • the block 512 may be deployed to verify at least two directly or indirectly approved transaction data for device provisioning in the decentralized ledger system 200, and then to approve the tip sites, e.g. block 511 and block 513, where the block 513 is not a transaction for device provisioning but approves indirectly at least one transaction data for DPP such as block 508.
  • an overlay Tangle for DPP of the decentralized ledger system 200 may be shown as in FIG. 6.
  • any suitable manners may be adopted to deploy or transmit the transaction data to the decentralized ledger system 200, for example by using Markov Chain Monte Carlo (MCMC) method.
  • MCMC Markov Chain Monte Carlo
  • any device may obtain bootstrapping information including the public key of the enrollee device (or enrollee, e.g. the devices 110, 120, or the like, which are enrolled and provisioned for device-to device communication or infrastructure communication) for example by using a pre-installed application such as an IOTA wallet in a case where the decentralized ledger system 200 which is implemented based on IOTA, instead of through scanning QR code or by utilizing NFC, BTLE, and the like which may be attacked or tampered.
  • the device 100 may obtain an identification of the device 110 by using an OOB mechanism such as QR codes scan, NFC tap, BLE exchange, or the like.
  • the device 110 may further obtain bootstrapping information including the public key of the device 110 from the decentralized ledger system 200, for example based on the obtained identification of the device 110.
  • the public key of a device to be provisioned may be trusted. Further, the public key of a device to be provisioned may be updated by publishing new keys on the decentralized ledger system 200. Further, for example, reliability and availability of communication channel may be improved.
  • the example method 300 may also includes step 710 of receiving from the decentralized ledger system 200 a request for verifying an identity of the enrollee of the bootstrapping information, a step 720 of determining a signature for the identity verification, and a step 730 of transmitting the signature to the decentralized ledger system 200.
  • step 710 of receiving from the decentralized ledger system 200 a request for verifying an identity of the enrollee of the bootstrapping information
  • step 720 of determining a signature for the identity verification a step 730 of transmitting the signature to the decentralized ledger system 200.
  • a proof of possession of a private key of an enrollee of the bootstrapping information such as the device 110, 120, or the like which is to be provisioned for example by the device 100, may be supported.
  • the device 100 may obtain an identification of the device 110 for example by using an OOB mechanism such as QR codes scan, NFC tap, BLE exchange, or the like.
  • the device 100 may be equipped with camera for scanning QR code provided by the device 110, so as to the identification of the device 110.
  • the device 110 may further obtain bootstrapping information including the public key of the device 110 from the decentralized ledger system 200, based on the obtained identification of the device 110.
  • OOB mechanism such as QR codes scan, NFC tap, BLE exchange, or the like.
  • the device 100 may be equipped with camera for scanning QR code provided by the device 110, so as to the identification of the device 110.
  • the device 110 may further obtain bootstrapping information including the public key of the device 110 from the decentralized ledger system 200, based on the obtained identification of the device 110.
  • the device 100 may request (830) to verify the identity of the device 110 to prove that the public key is really possessed by the device 110. For example, at 830, the device 100 may perform the step 310 of the example method 300 to determining transaction data including the request for verifying the identity of the device 110. For example, the request may include random challenge such as a random number or a random text. Then, at 830, the device 100 may perform the step 310 of the example method 300 to transmit the transaction data including the verification request to the decentralized ledger system 200.
  • the device 110 may perform the step 710 of the example method 300 to receive the verification request from the decentralized ledger system 200. Then, the device 110 may perform the step 720 of the example method 300 to determine a signature, for example, by using the random challenge in the request and the private key of the device 110. Then, the device 110 may perform the step 730 of the example method 300 to transmitting the signature to the decentralized ledger system. For example, similar to the steps 310 and 320, in the step 730, the transaction data including the signature may be determined and then transmitted or deployed to the decentralized ledger system 200.
  • the device 100 may acquire (840) the signature from the decentralized ledger system 200, and then may verify (850) the signature for example by the random challenge and the public key of the device 110.
  • the proof of the identity of the device 110 may also be initiated by the device 110.
  • a smart contract 810 may be deployed in advance to the decentralized ledger system 200, and they may be utilized during the proof of the identity of the device 110, for example, to forward information to be exchanged between the devices 100 and 110, such as the signature.
  • the actions/operations of the devices 100 and 110 may be tracked and recorded in the decentralized ledger system 200.
  • the proof of the identity of an enrollee device or the possession of a private key may be initiated by the smart contract 810, instead of the device 100.
  • the smart contract 810 may be called on acquiring the public key, and the will ask the device 100 to initiate a random challenge and then forward the random challenge to the device 110 which is the owner of the public key. Then, the smart contact 810 may forward the signature of the device 110 to the device 100 to make verification in the device 100, or may verify the signature in the smart contract 810.
  • the smart contract 810 may be implemented in any suitable manners.
  • the smart contract 810 may be written in any suitable smart contract programming languages such as Serpent , Solidity, and so on, and then may be compiled into Contract ByteCode, and then may be deployed to the decentralized ledger system 200.
  • a contract address may be assigned to the smart contract 810, and may be called or executed automatically during the later transactions.
  • smart contract is not limited to the proof of the identity of an enrollee device.
  • a smart contract may be configured on the decentralized ledger system 200 for any other data/information (e.g. bootstrapping information) exchange between the devices 100 and 110.
  • the Masked Authenticated Messaging may be utilized, which may support a plurality of modes such as Public mode, Private mode, and Restrict mode.
  • MAM Masked Authenticated Messaging
  • different operators or device groups may use different channel identity and side key to isolate and encrypt/decrypt information.
  • the channel identity and the side key may be distributed by deploying one or more smart contracts.
  • bootstrapping message including the bootstrapping information may be encapsulated as payload of the transaction data determined in the step 310. If the bootstrapping message is long, the message or data may be fragmented into one or more parts, for example into one or more blocks when the decentralized ledger system 200 is implemented based on the block chain technology, or into one or more bundles when the decentralized ledger system 200 is implemented based on the IOTA.
  • the contents in the message may be encrypted and digitally signed; the “tag” field may be utilized to implement message filtering; or the like.
  • the device 110 is provisioned by the device 100
  • one or more devices such as devices 110, 120, and so on may be provisioned or configured by any one or more suitable devices with capabilities to enroll and provision devices for device-to-device communication or infrastructure communication.
  • the device 110 may be a logical entity of another device such as the device 110 or 120 or the like.
  • the above examples are described for the bootstrapping, one or more features and aspects described above may also applied to the other procedures in the device provisioning, such as authentication and configuration.
  • MAM and/or smart contract may be also utilized for authentication, configuration, and any other procedures in the device provisioning.
  • the proof of possession of a private key of an enrollee may be initiated by any device in the device provisioning such as the device 110, 120, 210, 220, and so on, and is not limited to be initiated by the configurator device (or configurator) such as device 100 with capabilities to enroll and provision one or more devices for device-to-device communication or infrastructure communication.
  • the transaction data determined in the step 310 and transmitted in the step 320 may include an authentication response to at least one authentication request.
  • the example method 300 may also include a step 910 of receiving the at least one authentication request from the decentralized ledger system 200, and a step 920 of receiving an authentication confirmation from the decentralized ledger system 200 after transmitting the transaction data.
  • the authentication may be initiated by either the configurator device (e.g. device 100) or an enrollee device (e.g. device 110) , which may be also called as an initiator device or an initiator herein.
  • the device that responds to the initiation of the authentication by the initiator may be also called as a responder device or a responder herein.
  • FIG. 10 illustrates an example where the device 100 acts as an initiator of the authentication and the device 110 acts as a responder of the authentication.
  • the device 100 as the initiator may transmit (1010) at least one authentication request to the decentralized ledger system 200, for example by performing the steps 310 and 320. Then, the device 110 may perform the step 910 to receive the authentication request from the device 110 from the decentralized ledger system 200.
  • the at least one authentication request may include any information suitable for the authentication, such as an initiator protocol key attribute indicating its public protocol key, a wrapped data attribute that contains the initiator nonce attribute and the initiator capabilities attribute, and so on.
  • the device 110 as the responder may perform any suitable operations after receiving the authentication request.
  • the device 110 may perform the steps 310 and 320 to transmit the authentication response to the decentralized ledger system 200.
  • the authentication response may include information such as DPP status and some wrapped data which may depend on the DPP status.
  • the device 100 may perform any suitable operations after receiving (1020) the authentication response from the decentralized ledger system 200.
  • the device 100 may checks the DPP status, for example, whether the DPP status is set to STATUS_OK, and so on.
  • the device 100 may perform the steps 310 and 320 to transmit (1030) the authentication confirmation to the decentralized ledger system 200.
  • the authentication confirmation may include information such as DPP Status, bootstrapping key hash of the responder and the initiator of the authentication request corresponding to the authentication confirm, and so on.
  • the responder may check the DPP status. For example, if DPP status is STATUS_NOT_COMPATIBLE or STATUS_AUTH_FAILURE, the responder may unwrap the wrapped data portion in the authentication confirmation to obtain the reason for the failure.
  • the information/message exchange may be via a smart contract 1040 deployed in advance to the decentralized ledger system 200, so that one or more actions during the authentication may be tracked and recorded.
  • MAM may be utilized.
  • the transaction data determined in the step 310 and transmitted in the step 320 may include a configuration request.
  • the example method 300 may also include a step 1110 of receiving a configuration response to the configuration request from the decentralized ledger system 200.
  • FIG. 12 illustrates an example of the configuration procedure in the device provisioning where the device 110 initiates the provisioning phase by performing the step 310 and 320 to transmit a configuration request to the decentralized ledger system 200.
  • the configuration request may include information such as a DPP configuration attributes object generated by the device 110.
  • the device 100 may receive (1210) the configuration request from the device 110 from the decentralized ledger system 200.
  • the device 100 may perform the steps 310 and 320 to transmit (1220) the configuration response to the decentralized ledger system 200.
  • the configuration response may include configuration information for the device 110, a value to identify the request/response transaction which may be copied from the configuration request, information on the status, and so on.
  • device 110 may receive the configuration response from the decentralized ledger system 200 at the step 1110, and may be provisioned with the information in the response so as to establish a secure access to the access point, for example.
  • the information/message exchange may be via a smart contract 1230 deployed in advance to the decentralized ledger system 200, so that one or more actions during the configuration may be tracked and recorded.
  • MAM may be utilized.
  • FIG. 13 illustrates an example method 1300 corresponding to 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, e.g. the above decentralized ledger system 200.
  • a device may obtain an identification of an enrollee device by using an OOB mechanism such as QR codes scan, NFC tap, BLE exchange, or the like. Then, the device may obtain the transaction data for device provisioning from the decentralized ledger system 200, for example based on the obtained identification of the enrollee device.
  • OOB mechanism such as QR codes scan, NFC tap, BLE exchange, or the like.
  • the step 1310 may include the operation/step 820 or 710 or 840 as illustrated in FIG. 8, the operation/step 910 or 1020 or 920 as illustrated in FIG. 10, and the operation/step 1210 or 1110 as illustrated in FIG. 12.
  • the step 1310 may include the operation 820 as illustrated in FIG. 8.
  • the example method may further include a step 1410 of transmitting to the decentralized ledger system 200 a request for verifying an identity of an enrollee of the bootstrapping information, which may include the operation 830 in FIG. 8, a step 1420 of receiving a response to the request from the decentralized ledger system 200, which may include the operation 840 in FIG. 8, and a step 1430 of determining the identity of the enrollee based on the bootstrapping information and information in the response, which may include the operation 850 in FIG. 8.
  • the step 1310 may include the operation 1010 as illustrated in FIG. 10.
  • the example method 1300 may further include a step 1510 of transmitting the at least one authentication request to the decentralized ledger system, which may include the operation 1010 in FIG. 10, and a step 1520 of transmitting an authentication confirmation to the decentralized ledger system after receiving the transaction data, which may include the operation 1030 in FIG. 10.
  • the step 1310 may include the operation 1210 as illustrated in FIG. 12.
  • the example method 1300 may further include a step 1610 of transmitting a configuration response to the configuration request to the decentralized ledger system, which may include the operation 1220 in FIG. 12.
  • FIG. 17 illustrates an example of device provisioning by utilizing the above example method 300 and 1300 where the device 110 is an example of enrollee to be provisioned by the device 100 as an example of configurator.
  • both devices 100 and 110 may perform the steps in the example methods 300 and 1300 to implement the device provisioning.
  • the steps 310 and/or 320 of the example method 300 may be utilized in a case of transmitting information to the decentralized ledger system 200 in both example methods 300 and 1300, and thus may be unitized by both devices 100 and 110.
  • the step 1310 of the example method 1300 may be utilized in a case of receiving information from the decentralized ledger system 200 in both example methods 300 and 1300, and thus may be unitized by both devices 100 and 110.
  • the device 110 as an enrollee to be provisioned by the device 100 as an example of configurator may perform the steps 310 and 320 of the example method 300 to transmit the bootstrapping information to the decentralized ledger system 200.
  • the device 100 may perform the step 1310 of the example method 1300 to receive the bootstrapping information of the device 1100 from the decentralized ledger system 200.
  • the device 100 may perform the step 1410 (which may, for example, include or be similar to the steps 310 and 320 of the example method 300) of the example method 1300 to transmit a request for verifying the identity of the device 110 to the decentralized ledger system 200.
  • the device 110 may perform the step 710 (which may, for example, include or be similar to the step 1310 of the example method 1300) of the example method 300 to receive the request for verifying the identity. Then, the device 110 may perform the step 710 of the example method 300 to determining a signature for the identity verification, and may perform the step 730 (which may, for example, include or be similar to the steps 310 and 320) of the example method 300 to transmit the signature to the decentralized ledger system 200.
  • the step 710 which may, for example, include or be similar to the step 1310 of the example method 1300
  • the device 110 may perform the step 710 of the example method 300 to determining a signature for the identity verification, and may perform the step 730 (which may, for example, include or be similar to the steps 310 and 320) of the example method 300 to transmit the signature to the decentralized ledger system 200.
  • the device 100 may perform the step 1420 (which may, for example, include or be similar to the step 1310) of the example method 1300, and perform the step 1430 to determine the identity of the device 110 or whether the device 110 is the possessor of the private key corresponding to the public key obtained in the bootstrapping information.
  • the step 1420 which may, for example, include or be similar to the step 1310
  • the step 1430 to determine the identity of the device 110 or whether the device 110 is the possessor of the private key corresponding to the public key obtained in the bootstrapping information.
  • smart contract may be utilized during the information exchange for the bootstrapping.
  • MAM may be utilized.
  • identity verification may also be initiated for example by the smart contract.
  • the device 100 may perform the step 1510 (which may, for example, include or be similar to the steps 310 and 320 of the example method 300) of the example method 1300 to transmit at least one authentication request to the decentralized ledger system 200.
  • the device 110 may perform the step 910 (which may, for example, include or be similar to the step 1310 of the example method 1300) of the example method 300 to receive the at least one authentication request from the decentralized ledger system 200, and may perform the steps 310 and 320 to transmit the authentication response to the decentralized ledger system 200.
  • the device 100 may perform the step 1310 of the example method 1300 to receive the authentication response from the decentralized ledger system 200, and may perform the step 1520 (which may, for example, include or be similar to the steps 310 and 320 of the example method 300) of the example method 1300 to transmit the authentication confirmation to the decentralized ledger system 200.
  • the device 110 may perform the step 920 (which may, for example, include or be similar to the step 1310 of the example method 1300) of the example method 300 to receive the authentication confirmation from the decentralized ledger system 200.
  • smart contract may be utilized during the information exchange for the authentication.
  • MAM may be utilized.
  • the authentication may be initiated by the device 110.
  • the device 110 may perform the steps 310 and 320 of the example method 300 to transmit a configuration request to the decentralized ledger system 200.
  • the device 100 may perform the step 1310 of the example method 1300 to receive the configuration request from the decentralized ledger system 200, and may perform the step 1610 (which may, for example, include or be similar to the steps 310 and 320 of the example method 300) of the example method 1300 to transmit the configuration response to the decentralized ledger system 200.
  • the device 110 may perform the step 1110 (which may, for example, include or be similar to the step 1310 of the example method 1300) of the example method 300 to receive the configuration response from the decentralized ledger system 200.
  • smart contract may be utilized during the information exchange for the configuration.
  • MAM may be utilized.
  • FIG. 18 illustrates an example apparatus 1800 for device provisioning in an embodiment.
  • the example apparatus 1800 may be at least a part of any of the device such as the device 100, 110, 120, 210, 220, 230, or the like in the above examples.
  • 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 at least to perform at least the steps of at least one of the example method 300 and the example method 1300 described above.
  • the at least one processor 1810 in the example apparatus 1800 may include, but not limited to, at least one hardware processor, including at least one microprocessor such as a central processing unit (CPU) , a portion of at least one hardware processor, and any other suitable dedicated processor such as those developed based on for example Field Programmable Gate Array (FPGA) and Application Specific Integrated Circuit (ASIC) . Further, the at least one processor 1810 may also include at least one other circuitry or element not shown in FIG. 18.
  • at least one hardware processor including at least one microprocessor such as a central processing unit (CPU) , a portion of at least one hardware processor, and any other suitable dedicated processor such as those developed based on for example Field Programmable Gate Array (FPGA) and Application Specific Integrated Circuit (ASIC) .
  • FPGA Field Programmable Gate Array
  • ASIC Application Specific Integrated Circuit
  • the at least one memory 1820 in the example apparatus 1800 may include at least one storage medium in various forms, such as a volatile memory and/or a non-volatile memory.
  • the volatile memory may include, but not limited to, for example, a random-access memory (RAM) , a cache, and so on.
  • the non-volatile memory may include, but not limited to, for example, a read only memory (ROM) , a hard disk, a flash memory, and so on.
  • the at least memory 1820 may include, but are not limited to, an electric, a magnetic, an optical, an electromagnetic, an infrared, or a semiconductor system, apparatus, or device or any combination of the above.
  • the example apparatus 1800 may also include at least one other circuitry, element, and interface, for example at least one I/O interface, at least one antenna element, and the like.
  • the circuitries, parts, elements, and interfaces in the example apparatus 1800 may be coupled together via any suitable connections including, but not limited to, buses, crossbars, wiring and/or wireless lines, in any suitable ways, for example electrically, magnetically, optically, electromagnetically, and the like.
  • the structure of the apparatus for device provisioning is not limited to the above example apparatus 1800.
  • FIG. 19 illustrates another example apparatus 1900 for device provisioning in an embodiment.
  • the example apparatus 1900 may be configured to perform at least the steps of the example method 300.
  • the example apparatus 1900 may include means 1910 for performing the step 310 of the example method 300 and means 1920 for performing the step 320 of the example method 300.
  • at least one I/O interface, at least one antenna element, and the like may also be included in the example apparatus 1900.
  • the example apparatus 1900 may further include one or more means for performing one or more additional steps in the example method 300, such as the steps 710, 720, 730, 910, 920, 1110, and so on.
  • examples of means may include circuitries.
  • an example of means 1910 may include a circuitry configured to perform the step 310 of the example method 300
  • an example of means 1920 may include a circuitry configured to perform the step 320 of the example method 300.
  • examples of means may also include software modules and any other suitable function entities.
  • circuitry throughout 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 circuits and software, such as (as applicable) (i) a combination of analog and/or digital hardware circuit (s) with software/firmware and (ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) ; and (c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
  • hardware-only circuit implementations such as implementations in only analog and/or digital circuitry
  • combinations of hardware circuits and software such as (as applicable) (i) a
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, 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 server, a cellular network device, or other computing or network device.
  • FIG. 20 illustrates another example apparatus 2000 for device provisioning in an embodiment.
  • the example apparatus 2000 may be configured to perform at least the steps of the example method 1300.
  • the example apparatus 2000 may include means 2010 for performing the step 310 of the example method 1300.
  • at least one I/O interface, at least one antenna element, and the like may also be included in the example apparatus 2000.
  • the example apparatus 2000 may further include one or more means for performing one or more additional steps in the example method 1300, such as the steps 1410, 1420, 1430, 1510, 1520, 1610, and so on.
  • examples of means may include circuitries.
  • an example of means 2010 may include a circuitry configured to perform the step 1310 of the example method 1300.
  • examples of means may also include software modules and any other suitable function entities.
  • FIG. 21 illustrates another example apparatus 2100 for device provisioning in an embodiment, which includes means (e.g. means 1910 and means 1920) in the example apparatus 1900 and means (e.g. means 2010) in the example apparatus 2000.
  • the apparatus for device provisioning may include at least one of the above example apparatus 1800, 1900, 2000, and 2100.
  • Another example embodiment may relate to computer program codes or instructions which may cause an apparatus to perform at least respective methods described above.
  • Another example embodiment may be related to a computer readable medium having such computer program codes or instructions stored thereon.
  • a computer readable medium may include at least one storage medium in various forms such as a volatile memory and/or a non-volatile memory.
  • the volatile memory may include, but not limited to, for example, a RAM, a cache, and so on.
  • the non-volatile memory may include, but not limited to, a ROM, a hard disk, a flash memory, and so on.
  • the non-volatile memory may also include, but are not limited to, an electric, a magnetic, an optical, an electromagnetic, an infrared, or a semiconductor system, apparatus, or device or any combination of the above.
  • the words “comprise, ” “comprising, ” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to. ”
  • the word “coupled” refers to two or more elements that may be either directly connected, or connected by way of one or more intermediate elements.
  • the word “connected” refers to two or more elements that may be either directly connected, or connected by way of one or more intermediate elements.
  • conditional language used herein such as, among others, “can, ” “could, ” “might, ” “may, ” “e.g., ” “for example, ” “such as” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states.
  • 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 and/or states are included or are to be performed in any particular embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne des procédés de provisionnement d'un dispositif. Un procédé donné à titre d'exemple peut consister à déterminer des données de transaction pour le provisionnement d'un dispositif, et à transmettre les données de transaction à un système de registre décentralisé. Des appareils et des supports lisibles par ordinateur associés sont également divulgués.
PCT/CN2020/100628 2020-07-07 2020-07-07 Procédés et appareils de provisionnement de dispositif WO2022006736A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2020/100628 WO2022006736A1 (fr) 2020-07-07 2020-07-07 Procédés et appareils de provisionnement de dispositif
CN202080102818.8A CN115812292A (zh) 2020-07-07 2020-07-07 用于设备预配的方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/100628 WO2022006736A1 (fr) 2020-07-07 2020-07-07 Procédés et appareils de provisionnement de dispositif

Publications (1)

Publication Number Publication Date
WO2022006736A1 true WO2022006736A1 (fr) 2022-01-13

Family

ID=79553496

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/100628 WO2022006736A1 (fr) 2020-07-07 2020-07-07 Procédés et appareils de provisionnement de dispositif

Country Status (2)

Country Link
CN (1) CN115812292A (fr)
WO (1) WO2022006736A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017108783A1 (fr) * 2015-12-22 2017-06-29 Gemalto Sa Procédé de gestion d'une identité de confiance
US20180167394A1 (en) * 2016-12-14 2018-06-14 Wal-Mart Stores, Inc. Controlling access to a locked space using cryptographic keys stored on a blockchain
EP3364363A1 (fr) * 2017-02-21 2018-08-22 Mastercard International Incorporated Cryptogramme de transaction
CN110049141A (zh) * 2019-05-24 2019-07-23 南京工程学院 基于区块链的物联网分布式认证方法及其架构
WO2019179533A2 (fr) * 2019-07-02 2019-09-26 Alibaba Group Holding Limited Système et procédé d'émission de revendications vérifiables

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017108783A1 (fr) * 2015-12-22 2017-06-29 Gemalto Sa Procédé de gestion d'une identité de confiance
US20180167394A1 (en) * 2016-12-14 2018-06-14 Wal-Mart Stores, Inc. Controlling access to a locked space using cryptographic keys stored on a blockchain
EP3364363A1 (fr) * 2017-02-21 2018-08-22 Mastercard International Incorporated Cryptogramme de transaction
CN110049141A (zh) * 2019-05-24 2019-07-23 南京工程学院 基于区块链的物联网分布式认证方法及其架构
WO2019179533A2 (fr) * 2019-07-02 2019-09-26 Alibaba Group Holding Limited Système et procédé d'émission de revendications vérifiables

Also Published As

Publication number Publication date
CN115812292A (zh) 2023-03-17

Similar Documents

Publication Publication Date Title
US11039311B2 (en) Profile download method and apparatus for use in wireless communication system
KR102570563B1 (ko) 무선 통신 시스템에서 프로파일을 다운로드 하는 방법 및 장치
CN101777978B (zh) 一种基于无线终端的数字证书申请方法、系统及无线终端
KR101941049B1 (ko) 암호화된 통신을 위한 방법 및 시스템
US20180160294A1 (en) APPARATUS AND METHOD FOR INSTALLING AND MANAGING eSIM PROFILES
CA3051938C (fr) Communications sans fil
US10791106B2 (en) Digital credential with embedded authentication instructions
JP2018512822A (ja) 無線通信システムで端末のプロファイルを管理する方法及び装置
US20220295269A1 (en) Network access authentication method and device
KR20130026958A (ko) 내장 ｕｉｃｃ의 인증정보를 이용한 인증방법과, 그를 이용한 프로비저닝 및 ｍｎｏ 변경 방법, 그를 위한 내장 ｕｉｃｃ, ｍｎｏ 시스템 및 기록매체
KR102657876B1 (ko) Ssp 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치
ES2743576T3 (es) Procedimiento y aparato de gestión de un perfil de un terminal en un sistema de comunicación inalámbrica
CN111092820B (zh) 一种设备节点认证方法、装置和系统
US10158993B2 (en) Wireless communications
KR101802588B1 (ko) 세션 키 및 인증 토큰에 기반한 상호 인증 장치들 간의 상호 인증 방법 및 상호 인증 장치들
EP3320647B1 (fr) Authentification à base de jeton
US20240129727A1 (en) Method and apparatus for managing event for smart secure platform
CN115868189A (zh) 建立车辆安全通信的方法、车辆、终端及系统
KR20190117302A (ko) eUICC 버전을 협상하는 방법 및 장치
WO2022006736A1 (fr) Procédés et appareils de provisionnement de dispositif
CN108370369B (zh) 使用重定向促进客户端设备和应用服务器之间安全通信的网关、客户端设备和方法
KR20200102902A (ko) SSP 단말의 번들 다운로드 과정과 eSIM 프로파일 다운로드 과정 호환 연동 방법
EP4009601B1 (fr) Etablissement de vpn
EP3512229B1 (fr) Procédé, système, et dispositif d'authentification d'accès au réseau
US20220095095A1 (en) Method and apparatus for moving profiles with different versions during device change

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20944435

Country of ref document: EP

Kind code of ref document: A1