Method and system for managing booting

Abstract

Managing bootstrapping of an internet-of-things (IoT) device includes receiving a request for a change of ownership of the IoT device from a first owner to a second owner. The request for the change of ownership includes a public key of the second owner. In response to receiving the request for the change of ownership, a unique bootstrapping parameter is generated for the IoT device. To join a bootstrapping network, the unique bootstrapping parameter is embedded in a memory of the IoT device. The unique bootstrapping parameter is encrypted using the public key of the second owner and stored in a block of a database with the request for the change of ownership. The block ID is transmitted to the second owner and the bootstrapping device extracts the encrypted unique bootstrapping parameter from the transmitted block ID. The bootstrapping device decrypts the encrypted unique bootstrapping parameter using a private key of the second owner.

Description

TECHNICAL FIELD

[0001] Aspects of the disclosed embodiments generally relate to device bootstrapping, and more particularly, to systems and methods for managing bootstrapping of internet-of-things (IoT) devices. BACKGROUND

[0002] In recent years, with the rapid development of technology, the number of devices capable of connecting to the Internet has grown exponentially, which are being utilized by users all over the world, thus creating the "Internet of Things (IoT)". Some of these IoT devices include smartphones, smart sensors, refrigerators, home security systems, lighting fixtures, etc., which users can utilize to improve accessibility, efficiency, productivity, and user experience. However, in order for such IoT devices to function in a user's environment (or network), such devices need to be "bootstrapped".

[0003] Bootstrapping of IoT devices refers to the process of assigning an identity to an IoT device and enabling communication with an endpoint (such as a user). Currently, each IoT device needs to be manually bootstrapped by a user or other personnel. In some examples, device-specific bootstrapping parameters are embedded in a machine-readable code, for example, a QR code or a barcode printed on the surface of the IoT device. Here, the IoT device creates a bootstrapping network upon power-on and acquires the bootstrapping parameters by a user scanning the QR code to join the bootstrapping network. However, such an implementation requires external user involvement to complete the bootstrapping process. Such manual operations cannot onboard millions of IoT devices in the next few years, which makes the overall bootstrapping operation very time-consuming and expensive.

[0004] There have been some attempts to address the above-mentioned problems, for example, zero-touch bootstrapping of IoT devices, where the IoT device automatically bootstraps upon "power-on", thus limiting or excluding any external user involvement. However, since these technical solutions use a pre-defined bootstrapping network, these technical solutions are not sufficient to prevent misbinding of devices during the bootstrapping process. Therefore, any device can join the pre-defined bootstrapping network and manipulate the network to attract devices to join the bootstrapping network.

[0005] Therefore, in light of the above discussion, there is a need for a system or method for securely, reliably, and efficiently managing zero-touch bootstrapping of internet-of-things (IoT) devices. Therefore, it is desirable to provide systems and methods that address at least some of the problems mentioned above. SUMMARY

[0006] Aspects of the disclosed embodiments relate to a method and apparatus for bootstrapping an internet-of-things (IoT) device, substantially as hereinafter more fully set forth in the claims, shown in the drawings and / or described in connection with at least one of the drawings. Aspects of the disclosed embodiments provide a zero-touch bootstrapping process in which a device connects to the correct bootstrapping network and is bootstrapped without any action by the user other than powering on the device.

[0007] According to a first aspect, the above mentioned and further implementation forms and advantages are achieved by a method for managing bootstrapping of an internet-of-things (IoT) device. In one embodiment, the method comprises receiving a request for change of ownership of the IoT device from a first owner to a second owner, the request for change of ownership comprising at least a public key of the second owner; in response to receiving the request for change of ownership, generating a unique bootstrapping parameter for the IoT device, the unique bootstrapping parameter comprising at least a bootstrapping network identifier and a bootstrapping network credential for joining a bootstrapping network; embedding the unique bootstrapping parameter in a memory of the IoT device; encrypting the unique bootstrapping parameter using the public key of the second owner; storing the encrypted unique bootstrapping parameter and the request for change of ownership in a block of a database, the block having a block ID; transmitting the block ID to the second owner; a bootstrapping device of the second owner extracting the encrypted unique bootstrapping parameter from the transmitted block ID; the bootstrapping device of the second owner decrypting the encrypted unique bootstrapping parameter using a private key of the second owner. Aspects of the disclosed embodiments provide a zero-touch bootstrapping process in which a device connects to the correct bootstrapping network and is bootstrapped without any action by the user other than powering on the device.

[0008] In one possible implementation form, the method further comprises signing, by the first owner of the IoT device, the encrypted unique bootstrapping parameter using a signing key to generate a signed message; storing the signed message together with the encrypted unique bootstrapping parameter in the block of the database. Aspects of the disclosed embodiments provide a zero-touch bootstrapping method for IoT devices to prevent wrong binding. An IoT device connects to the correct bootstrapping network and gets bootstrapped correctly without any action by the user other than powering on.

[0009] In a possible implementation, the method further includes: the bootstrapping device of the second owner verifying the signed message; the bootstrapping device of the second owner decrypting the encrypted unique bootstrapping parameter in response to the verification of the signed message. The device owner uses the bootstrapping parameter to create a device-specific bootstrapping network and uses other parameters to automatically bootstrap the device.

[0010] In a possible implementation, the method further includes: embedding a trust anchor in the memory of the IoT device during manufacturing to allow the IoT device to verify a manufacturer's signing key to establish the manufacturer as the first owner of the IoT device. Using a block as a trust anchor, the IoT device can establish a secure channel with a bootstrapping device to complete a bootstrapping process.

[0011] In a possible implementation, the method further includes: the bootstrapping device of the second owner providing a bootstrapping network with the decrypted unique bootstrapping parameter; operating the IoT device in a non-operational mode to connect to the bootstrapping network provided by the bootstrapping device of the second owner by using the embedded unique bootstrapping parameter in the memory to receive operational parameters of an operational network of the second owner from the bootstrapping device.

[0012] In a possible implementation, the method further includes: the IoT device sending, to the bootstrapping device of the second owner through the bootstrapping network, a proof request of a block ID of one or more blocks in the database storing the ownership change request; the bootstrapping device of the second owner sending the proof request to the database; the database generating, in response to receiving the proof request, proof evidence including information about the one or more blocks in the database storing the ownership change request; the bootstrapping device of the second owner receiving the proof evidence from the database; and the bootstrapping device of the second owner sending, to the IoT device through the bootstrapping network, the proof evidence. Aspects of the disclosed embodiments facilitate zero-touch bootstrapping and prevent misbinding by utilizing blockchain technology. During the bootstrapping process, devices verify each other using information in the blockchain.

[0013] In a possible implementation, the method further comprises: verifying, by the IoT device, the proof evidence; in response to the verification of the proof evidence, extracting information about the latest block of the one or more blocks in the database storing the ownership change request; verifying the ownership change request according to the information about the latest block of the one or more blocks in the database storing the ownership change request; and in response to the verification of the ownership change request, establishing a secure connection with the bootstrapping device of the second owner. The new owner of the device can extract bootstrapping parameters from the relevant block in the blockchain, so that the bootstrapping device of the new owner can use the parameters to create or join a device-specific, one-time-use bootstrapping network to automatically bootstrap the correct device.

[0014] In a possible implementation, the method further comprises connecting, by the IoT device, to the operation network of the second owner with the received operation parameters to operate in an operation mode. The bootstrapping network is unique for each device and can only be used to bootstrap the device once. A device in a non-operation mode is designed to only connect to the bootstrapping network created according to the bootstrapping parameters.

[0015] In a possible implementation, in the case where the ownership change request of the IoT device that has already been in the operation mode is received, the method further comprises: generating, for the IoT device, alternative unique bootstrapping parameters, the alternative unique bootstrapping parameters including at least an alternative bootstrapping network identifier and an alternative bootstrapping network credential for joining an alternative bootstrapping network; and embedding the generated alternative unique bootstrapping parameters in the memory of the IoT device. The device owner uses the bootstrapping parameters to create a device-specific bootstrapping network and uses other parameters to automatically bootstrap the device.

[0016] In a possible implementation, the database is one or more of a centralized database, a distributed ledger, or a blockchain. The ownership change information from the manufacturer through the retailer to the user is recorded in the blockchain. In the bootstrapping process, the user decrypts the encrypted bootstrapping parameters and extracts the encrypted bootstrapping parameters from the relevant blockchain transaction.

[0017] In a possible implementation, the database is one or more of a public database, a private database, a consortium database, or a hybrid database.

[0018] In a possible implementation, the unique bootstrapping parameters further include one or more of a device identifier or a bootstrapping network protocol.

[0019] According to a second aspect, the above and further implementations and advantages are obtained by a system for managing bootstrapping of an internet-of-things (IoT) device. In one embodiment, the system comprises: a database; a first owner device associated with a first owner, the first owner device configured to provide a public key of the first owner; a second owner device associated with a second owner device, the second owner device configured to provide a public key of the second owner; wherein the IoT device is configured to generate a unique bootstrapping parameter and embed the unique bootstrapping parameter in a memory, the unique bootstrapping parameter comprising at least a bootstrapping network identifier and a bootstrapping network credential for joining a bootstrapping network. The first owner device is configured to: provide, to the database, an ownership change request of the IoT device from the first owner to the second owner, the ownership change request comprising at least the public key of the second owner. The first owner device is further configured to: in response to receiving the ownership change request, encrypt the generated unique bootstrapping parameter using the public key of the second owner, and send the encrypted unique bootstrapping parameter to the database. The database is configured to store the encrypted unique bootstrapping parameter in a block having a block ID, and transmit the block ID to the second owner device in response to the ownership change request. The second owner device is configured to: extract the encrypted unique bootstrapping parameter according to the transmitted block ID, and decrypt the unique bootstrapping parameter using a private key of the second owner.

[0020] In one possible implementation, the first owner device is configured to: embed a trust anchor in the memory of the IoT device during manufacturing to allow the IoT device to verify a public key of a manufacturer, thereby establishing the manufacturer as the first owner of the IoT device.

[0021] In one possible implementation, the second owner device is configured to: provide a bootstrapping network with the decrypted unique bootstrapping parameter, and the IoT device in a non-operational mode is configured to connect to the provided bootstrapping network by utilizing the embedded unique bootstrapping parameter in the memory to receive operational parameters of an operational network of the second owner device from the second owner device; the IoT device is configured to: connect to the operational network of the second owner with the received operational parameters to operate in an operational mode.

[0022] In one possible implementation, in a case where the ownership change request of the IoT device that is already in the operation mode is received, the IoT device is further configured to: generate a replacement unique boot parameter for the IoT device, the replacement unique boot parameter comprising at least a replacement boot network identifier and a replacement boot network credential for joining a replacement boot network; and embed the generated replacement unique boot parameter in the memory of the IoT device. Aspects of the disclosed embodiments use device-specific, single-purpose boot networks. Both participating devices have a priori knowledge of the network identifier and credential and other parameters for joining a boot network.

[0023] In one possible implementation, the database is one of a centralized database, a distributed ledger, or a blockchain. Aspects of the disclosed embodiments facilitate zero-touch bootstrapping by using information in the blockchain to create a unique boot network to prevent misbinding, the devices are programmed to automatically join the unique boot network, and proceed with bootstrapping after mutual authentication.

[0024] In one possible implementation, the database is one of a public blockchain, a private blockchain, a consortium blockchain, or a hybrid blockchain. Aspects of the disclosed embodiments facilitate zero-touch bootstrapping by using information in the blockchain to create a unique boot network to prevent misbinding, the devices are programmed to automatically join the unique boot network, and proceed with bootstrapping after mutual authentication.

[0025] These and other aspects, implementations, and advantages of the exemplary embodiments will become apparent from the embodiments described herein as considered in connection with the accompanying drawings. It should be understood, however, that the description and drawings are for purposes of illustration only and should not be construed as limiting the application; any limitation with respect to the application should only be as set forth in the appended claims. Additional aspects and advantages of the application will be set forth in the description to follow, and in part will become apparent to those skilled in the art from the description, or can be learned by practice of the application. Moreover, the aspects and advantages of the application can be realized and obtained by means of the instrumentalities and combinations pointed out in the appended claims. BRIEF DESCRIPTION OF DRAWINGS

[0026] In the following detailed portion of the specification, the application will be explained in greater detail with reference to the example embodiments illustrated in the drawings, wherein like reference characters indicate like elements and:

[0027] Figure 1 a block diagram of an example system zero-touch bootstrapping for internet-of- things (IoT) devices provided for embodiments of the application;

[0028] Figure 2A flowchart listing steps included in a method for booting an internet-of- things (IoT) device is provided for embodiments of the present application;

[0029] Figure 3 An exemplary flowchart of a system 100 or method 200 for booting an IoT device from a first owner to a second owner is provided for embodiments of the present application;

[0030] Figure 4 A flowchart of a message flow sequence of a process for transferring a unique boot parameter from a first owner to a second owner is provided for embodiments of the present application;

[0031] Figure 5 A flowchart of a message flow sequence of a process for transferring a unique boot parameter from a first owner to another second owner is provided for embodiments of the present application;

[0032] Figure 6 A flowchart of a message flow sequence of a booting process of a system of Figure 1 or a method of Figure 2 provided for embodiments of the present application;

[0033] Figure 7 A flowchart of a message flow sequence of a zero-touch booting process using Wi-Fi technology is provided for embodiments of the present application;

[0034] Figure 8 A flowchart of a message flow sequence of a zero-touch booting process using Bluetooth technology is provided for another embodiment of the present application.

[0035] In the drawings, underlined numerals are used to designate items in the figures by the numerals being underlined or items adjacent to the numerals being underlined. Un- underlined numerals are associated with items identified by the items linked to the numerals by the lines. When a numeral is un-underlined but has an associated arrow, the un- underlined numeral is used to identify the general item to which the arrow is pointing. DETAILED DESCRIPTION

[0036] The following detailed description illustrates embodiments of the application and methods through which these embodiments can be implemented. While some embodiments of the application have been disclosed, those skilled in the art will recognize that other embodiments for implementing or practicing the application can be implemented.

[0037] Reference is made to Figure 1 , a block diagram of an exemplary system 100 for managing booting of an internet-of-things (IoT) device 102 transferred from a first owner to a second owner is shown in accordance with aspects provided by embodiments of the present application. As shown in Figure 1As shown, the system 100 generally includes an IoT device being transferred from a first owner to a second owner. A first owner device associated with the first owner is used to provide a public key of the first owner. A second owner device associated with the second owner is used to provide a public key of the second owner. The IoT device is used to: generate a unique bootstrapping parameter, the unique bootstrapping parameter including at least a bootstrapping network identifier and a bootstrapping network credential for joining a bootstrapping network. The unique bootstrapping parameter is embedded in a memory of the IoT device.

[0038] In one embodiment, the first owner device is used to provide the database with an ownership change request of the IoT device from the first owner to the second owner. The ownership change request includes at least the public key of the second owner. In response to receiving the ownership change request, the generated unique bootstrapping parameter is encrypted using the public key of the second owner and the encrypted unique bootstrapping parameter is sent to the database.

[0039] In one embodiment, the database is used to store the encrypted unique bootstrapping parameter in a block, the block having a block ID. For example, a processor can be used to cause the database to store the encrypted unique bootstrapping parameter. In response to the ownership change request, the block ID is transmitted to the second owner device. The second owner device is used to: extract the encrypted unique bootstrapping parameter from the transmitted block ID and decrypt the unique bootstrapping parameter using a private key of the second owner.

[0040] The term “bootstrapping” used herein refers to a process of assigning an identity to an IoT device 102 and enabling communication with an endpoint (e.g., a first owner, a second owner). The system 100 is used to manage bootstrapping operations, such as factory bootstrapping, media-based bootstrapping, or remote bootstrapping, for example. The system 100 is used to manage bootstrapping information, i.e., information required for an IoT device 102 to initiate communication with other elements within a network, such as but not limited to bootstrapping network creation parameters, credentials, device IDs, media access control (MAC) addresses, internet protocol (IP) addresses, and other information that facilitates bootstrapping, is embedded into the IoT device 102 via a bootstrapping device 104.

[0041] The term “IoT device” used herein refers to a physical object (or a group of such objects) that includes hardware, software, and / or firmware for connecting and exchanging data with other devices and / or systems over any communication network, such as the Internet. Some examples of IoT devices include, but are not limited to, lighting fixtures, thermostats, home security systems, cameras, and other home appliances that can be controlled via a controller device (e.g., a smartphone, a controller, a smart speaker, etc.).

[0042] Generally, the bootstrapping operation (or process) of any device (e.g., the IoT device 102) requires the device to be able to establish a connection to a bootstrapping device, where the device and the bootstrapping device are connected to each other over a bootstrapping network. Currently, each IoT device needs to be manually initiated by a user or some other personnel, which makes it very time consuming, expensive and unscalable to initiate millions of IoT devices in the coming years. Moreover, the bootstrapping operation using a well-known bootstrapping network is vulnerable to a misbinding attack.

[0043] Further, in case of a zero-touch bootstrapping operation, the device and the bootstrapping device automatically join the bootstrapping network and establish a bootstrapping session with each other upon power up. A conventional approach to facilitate zero-touch bootstrapping is to create a well-known bootstrapping network, which the device joins to bootstrap. For example, a well-known SSID is used to create a bootstrapping network for Wi-Fi TM based devices, or a well-known friendly name is used to automatically connect for Bluetooth TM devices. However, existing zero-touch bootstrapping solutions use a well-known bootstrapping network and are vulnerable to a potential misbinding attack.

[0044] In view of the above problems, the present invention provides a novel system 100 for a zero-touch bootstrapping operation of an IoT device 102, which prevents a misbinding vulnerability. Specifically, the system 100 enables the IoT device 102 to connect to the correct bootstrapping network and obtain accurate bootstrapping without any operation from the user other than powering or initiating the IoT device 102. Here, the system 100 is used to provide a temporary, customized (or device-specific) bootstrapping network depending on the type of the device 102 being bootstrapped during the operation. This implementation is achieved by providing the participating devices with a priori knowledge of the bootstrapping parameters (i.e., network identifiers and credentials) and other bootstrapping parameters required to join the bootstrapping network. Advantageously, the system 100 is misbinding-proof and enables zero-touch bootstrapping of the IoT device 102 by creating a unique set of bootstrapping parameters associated with the IoT device 102 and shared between the IoT device 102 and the bootstrapping device. Further, the system 100 of the present invention utilizes blockchain technology to securely and confidentially transfer the unique bootstrapping parameters to the owner (i.e., the user) of the IoT device, who uses the generated unique bootstrapping parameters to create a device-specific bootstrapping network (and uses other parameters) to automatically and without any intervention bootstraps the device, making the system 100 faster and efficient.

[0045] As Figure 1As shown, the system 100 includes a database 104. The term “database” refers to an organized collection of structured information (or data), typically stored and accessed electronically. For example, databases include relational databases, centralized databases, distributed databases, and the like. However, conventional databases are susceptible to security risks such as, but not limited to, intrusion or unwanted access by malicious actors, crashes or failures, unwanted alterations of data, accidental deletion of data, and the like. Accordingly, in view of the aforementioned risks, the database 104 is selected based on implementation needs to efficiently and securely manage boot operations.

[0046] In one embodiment, the database 104 is a centralized database. The term “centralized database” refers to a type of database that is located, stored, and managed at a single location. For example, a central computer (e.g., CPU or mainframe computer) or a database system (e.g., MySQL, Oracle, PostgreSQL, dBASE, FoxPro, IBM DB2). Advantageously, such centralized database 104 provides several advantages over other types of conventional databases, including: increased data integrity, reduced data redundancy, enhanced data reliability, easier availability, data portability, and database management, and reduced costs.

[0047] In another embodiment, the database 104 is a distributed ledger. The term “distributed ledger” (also referred to as a shared ledger or distributed ledger technology or DLT) as used herein refers to a consensus or database of replicated, shared, and synchronized digital data that is geographically distributed (i.e., decentralized) across multiple entities (e.g., sites, countries, or institutions). Some examples of distributed ledger databases 104 include blockchain, hashgraph, DAG, Holochain, and Tempo (Radix). Here, the system 100 can also utilize cryptographic keys and / or digital signatures to provide authorization for the distributed ledger to improve security and reliability.

[0048] In yet another embodiment, the database 104 is a blockchain. The term “blockchain” refers to a type of distributed ledger that functions as a decentralized database of information about transactions between parties. Typically, the blockchain database 104 (also referred to as, a blockchain network, or simply a blockchain) is populated in chronological order with operations and stored as a series of blocks, with an interlinked chain formed between the series of blocks, with each block referencing a previous block, thereby creating the blockchain database 104. Here, the database 104 is used to replicate across multiple distributed ledgers or blocks, accessed by the system 100 and / or the owner (or user), where the multiple distributed ledgers are distributed across multiple nodes on a peer-to-peer communication network, where each node can replicate and hold a same copy of at least one of the multiple distributed ledgers and independently make updates.

[0049] In blockchain storage, data is first broken down into shards through a process called sharding, where each shard is replicated to prevent loss of data in the event of an error during transmission. Additionally, files are encrypted using a private or public key to prevent access by other nodes in the communication network. The replicated shards are distributed among decentralized nodes, where interactions are recorded in the blockchain database 104, enabling the system 100 to confirm and synchronize transactions across nodes. Advantageously, the blockchain database 104 provides a decentralized storage and authorization system 100 with improved security and reliability. In other words, during any update to the multiple distributed blocks of the blockchain database 104, each node can build new transactions according to a consensus algorithm (e.g., proof of work, proof of stake, voting system, hashgraph, etc.) regarding the authenticity or correctness of a copy of the distributed ledger. Additionally, the blockchain database 104 reduces the associated production costs and also improves the processing speed of the system 100. Furthermore, it can optionally provide smart contracts with additional inherent advantages.

[0050] In one or more embodiments, the database 104 is one of a public database, a private database, a consortium database, or a hybrid database. Alternatively, the database is any of a public blockchain, a private blockchain, a consortium blockchain, or a hybrid blockchain. Those skilled in the art will appreciate that the terms “blockchain” and “database” can be used interchangeably without limiting the scope of the present invention.

[0051] In one embodiment, the database 104 is a public database or blockchain. In such an embodiment, the database 104 is accessible to the general public and does not include any restrictions, i.e., anyone with a computer and internet access (or owner) can participate in the network, where the public database 104 is fully distributed, i.e., every node in the network holds a copy of other nodes or blocks present in the network for validating transactions or records. Advantageously, the public database 104 provides a trusted, secure storage and distributed medium that is decentralized and anonymous in nature.

[0052] In another embodiment, the database 104 is a private database or blockchain. In such an embodiment, the database 104 is not fully decentralized and only allows selected nodes to participate or access the network. For example, a network in an organization where only a subset of nodes are authorized for access. Advantageously, the private database 104 provides increased privacy, reliability, and security for the system 100.

[0053] In another embodiment, the database 104 is a hybrid database or consortium database. In such an embodiment, the database 104 is formed by merging components of public and private blockchains, where transactions or records in the hybrid blockchain 104 are private but verifiable when required, for example, by allowing access through a smart contract. Advantageously, the hybrid database 104 enables the system 100 to establish a private permissioned system alongside a public permissionless system, thereby enabling efficient management of access to each data or block stored in the database 104, i.e., whether the data is public or private as required.

[0054] Advantageously, the hybrid blockchain 104 protects the privacy of the owner while enabling communication with third parties. Moreover, the hybrid blockchain provides a higher level of security to the system, as external participants cannot initiate a 51% attack on the network due to the operation in a closed ecosystem. Furthermore, the hybrid blockchain 104 provides cheaper and faster transactions and generates better flexibility and scalability for the system 100.

[0055] In order to enable the bootstrapping operation through the system 100, a preliminary step of device registration is required, so after registration, the IoT device 102 is informed of its communication partners (or nodes) and is typically bound to a specific user or company account, or a virtual representation, to enable other components to query (e.g., a server or platform) metadata about the IoT device 102, such as device ID, device type, configuration details, manufacturer details, etc., of all IoT devices in the network.

[0056] In Figure 1 Further shown in, the system 100 also includes a server 101 in communication with the database 104. The term “server” refers to a structure and / or module comprising programmable and / or non-programmable components for storing, processing, and / or sharing information or data to bootstrap the IoT device 102 from a first owner to a second owner. Here, the server 101 is used to communicate with other elements within the system 100 (i.e., owner devices associated with the first or second owner) and the database 104 to securely and efficiently bootstrap the IoT device 102. Alternatively, the server 101 is responsible for causing the bootstrapping operation through the described method and is used to send commands, requests, and messages to connected elements (i.e., the IoT device 102, the first owner device 106, the second owner device 108, and the database 104), where each element can perform the described actions on its own or upon request or command from the server 101. It will be appreciated that the server 101 can be part of any of the IoT device 102, the database 104, the first owner device 106, the second owner device 108, or a part of no limitation performs the bootstrapping operation.

[0057] Optionally, the server 101 comprises a device of physical or virtual computing entities capable of enhancing information to perform various computing tasks. Further, it will be appreciated that the server 101 can be implemented as a hardware server and / or a plurality of hardware servers running in parallel or in a distributed architecture. Optionally, the servers in the server 101 are supplemented with additional computing systems, such as neural networks, and a hierarchical cluster of pseudo-simulated variable state machines implementing artificial intelligence algorithms.

[0058] In one embodiment, the server 101 can comprise components such as memory, processor, data communication interface, network adapter, etc. to store, process and / or share information with other computing devices, such as the first owner device 106, the second owner device 108 and the database 104. Optionally, the server 101 is implemented as a computer program that provides various services, such as database services, to other devices, modules or apparatuses. Further, the server 101 refers to a computing element operable to respond and process instructions to perform bootstrapping operations.

[0059] For example, the server 101 can be a cloud server, an application server, a file server, a database server or a blockchain server. Optionally, the server 101 comprises, but is not limited to, a microprocessor, a microcontroller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a field programmable gate array (FPGA) or any other type of processing circuitry, such as described above. Further, the server 101 is arranged in various architectures for responding and processing instructions for bootstrapping the IoT device 101 from the first owner to the second owner via the system 100.

[0060] As described herein, the server 101 is configured to receive the first owner’s public key from the first owner device 106. The first owner device 106 is configured to provide the first owner’s public key to the server 101. Further, the server 101 is configured to receive the second owner’s public key from the second owner device 108. The second owner device 108 is configured to provide the public key associated with the second owner to the server 101.

[0061] The term "owner device" as used herein refers to a structure and / or module comprising programmable and / or non-programmable components for storing, processing, and / or sharing information and / or signals associated with managing bootstrapping operations and / or with an owner or user (e.g., a first owner and a second owner). The owner device 106 or 108 can be a controller having a display, control buttons or a joystick, a processor, a memory, and the like elements. In the present example, the owner device 106 or 108 can include a memory, a processor, a network adapter, and the like components to store, process, and / or share information with other computing components such as a remote server, a remote gateway, a network, or a database.

[0062] Examples of the owner device 106 or 108 include, but are not limited to, a workstation, a desktop computer, a mobile computer, a laptop computer, a netbook computer, a tablet computer, a smartphone, a personal digital assistant (PDA), a Wi-Fi access point, a Bluetooth transmitter, a web server or a backend server (operated by a first owner such as a manufacturer, a retailer, and a distributor), and the like. It should be appreciated that the first owner device 106 and the second owner device 108 can be used as a bootstrapping device for performing bootstrapping of the IoT device 102 through the system 100.

[0063] Further, as used herein, the term "owner" refers to a person (i.e., a human) or an entity (e.g., an organization). For example, a seller, a retailer, a manufacturer of the IoT device 102 can be a first owner, while a buyer or an end user of the IoT device 102 can be a second owner.

[0064] In terms of blockchain, the identity of any owner device 106 or 108 comes from the public key provided by its respective owner. For example, the identity of the first owner device 106 derived from the public key of the first owner. The owner can choose to use a different key pair or public key for each purchase to avoid profiling, where an external entity can profile a user based on the purchased device, or based on a group of several purchases. However, maintaining the same identity is beneficial for providing value-added services such as reputation of both the buyer and the seller. Typically, intermediate owners of the device, i.e., the manufacturer, the distributor, and the retailer, will maintain their identity unchanged to allow tracking of counterfeit devices and transactions.

[0065] Accordingly, to enable the bootstrapping operation, a certain level of mutual trust needs to be developed between the first owner and the second owner. The first owner and the second owner share public keys through the first owner device 106 and the second owner device 108, respectively, to enable identification of the owners.

[0066] Further, in the system 100, to initiate the bootstrapping operation, the server 101 is configured to provide the database 104 with an ownership change request of the IoT device 102 from a first owner to a second owner. The ownership change request typically includes at least a public key of the second owner.

[0067] The life cycle (or bootstrapping cycle) of any IoT device 102 involves multiple stages, after or during which the IoT device 102, the unique bootstrapping parameter and the ownership are transferred (or changed) from one party to another, i.e. from a first owner to a second owner. For example, the transfer can occur after or during the manufacturing, selling, deploying or utilizing of the IoT device 102 (by a user or an owner).

[0068] Typically, to have such ownership transfer occur, the server 101 is configured to provide (or trigger) the database 104 with an ownership change request of the IoT device 102 from a first owner to a second owner. The ownership change request includes at least a public key of the second owner. It is noted that the public key of the second owner is transmitted to enable secure transmission of the unique bootstrapping parameter, i.e. to enable encryption of the bootstrapping information before transmission through the first owner device 106 or the server 101. Beneficially, such implementation enables the IoT device 102 to securely transmit the unique bootstrapping parameter directly to the second owner and overcomes the problem of revealing the unique bootstrapping parameter to the first owner as previously proposed.

[0069] In one example, when manufacturing any IoT device 102, the first owner is the manufacturer of the IoT device 102. The manufacturer triggers the ownership change request through a seller or distributor (e.g. an e-commerce platform or an authorized center) of the server 101 for a second owner (i.e. an end user (e.g. a person A) of the IoT device 102. The server 101 is further configured to transmit the ownership change request to the database 104.

[0070] In another example, the first owner is a distributor or seller of the IoT device 102 and provides the server 101 with the ownership change request for a second owner. The server 101 is further configured to transfer the ownership change request to the database 104.

[0071] In yet another example, the first owner is a first user (e.g., person X) who decides to sell or gift the IoT device 102 to a second owner after a period of use. The first owner provides an ownership change request to the server 101. The second owner is a second user (e.g., person Y; a friend of person X) who acquires the IoT device 102 from the first owner. The ownership change request is transferred from the first owner to the second owner when the ownership change request is triggered from the server 101. The IoT device 102 is now required to register or bootstrap according to the identity of the second owner or user, and the second owner device 108 provides the public key of the second owner for the transaction.

[0072] In one embodiment of the system 100, the IoT device 102 is configured to generate unique bootstrap parameters comprising at least a bootstrap network identifier and a bootstrap network credential for joining the bootstrap network 110. The term "unique bootstrap parameters" as used herein refers to a set of parameters associated with the IoT device 102 that are required for the bootstrap operation by the system 100. The unique bootstrap parameters comprise at least the bootstrap network identifier and the bootstrap network credential, and other bootstrap information such as a device identifier, a bootstrap protocol, and a bootstrap credential.

[0073] Generally, in any bootstrap operation, the unique bootstrap parameters enable the IoT device 102 to identify the bootstrap network 110 by the network identifier and to connect or join the bootstrap network 110 using the network credential. The "bootstrap network identifier" refers to a network address of the bootstrap network 110 for identification. For example, this can include a service set identifier (SSID), an internet protocol (IP) address, or an identifier of a Bluetooth-based bootstrap network.

[0074] The "bootstrap network credential" refers to authentication or authorization information required for joining the bootstrap network, such as a username, a password, or a key, among others. Optionally, the bootstrap network credential can be generated at least in part from the bootstrap device identifier and / or the bootstrap network identifier, such that an unauthorized user requesting access cannot use the bootstrap network credential for authentication. It is noted that the generation of the unique bootstrap parameters enables the system 100 to develop a customized bootstrap network 110, i.e., specific to the IoT device 102 that prevents the misbinding attack. Furthermore, the device identifier can be used to sign the bootstrap network credential or to perform other verification functions using public key encryption by the bootstrap network 110.

[0075] The "bootstrapping network" 110 refers to a wireless network used to connect the IoT device 102 and the bootstrapping device 108 for performing the bootstrapping operation by the second owner. The bootstrapping network 110 includes, for example, the Internet, an intranet, an extranet, a wide area network (WAN), a local area network (LAN), a personal area network (PAN), a wired network, a wireless network, or other suitable network or networks, or any combination thereof, to two or more such networks. Further, the bootstrapping device 108 can be in data communication with the first owner device 106 or the server 101 via a communication channel separate from the bootstrapping network 110 (e.g., a cellular network, Wi-Fi, NFC, infrared, and / or other techniques).

[0076] The bootstrapping network 110 is used to facilitate communication between the two connected devices to enable bootstrapping of the IoT device 102, where the bootstrapping network 110 can be established via either of the two devices or via an external entity (e.g., a remote server, a gateway, etc.). Here, the generated unique bootstrapping parameter enables the generation of a temporary device-specific bootstrapping network 110, i.e., used only once during the bootstrapping operation and until reset. Those skilled in the art will appreciate that the bootstrapping network 110 is a device-specific network; however, the system 100 can use a generic, well-known network without limitation.

[0077] The IoT device 102 is further used to embed the unique bootstrapping parameter in the memory 112 of the IoT device 102. Alternatively, the unique bootstrapping parameter is embedded or stored in the memory 112 of the IoT device 102. Upon generation of the unique bootstrapping parameter, the IoT device 102 is used to embed or store the unique bootstrapping parameter in the memory 112 of the IoT device 102, such that the second owner device 108 can further retrieve or extract the bootstrapping parameter from the memory 112 of the IoT device.

[0078] Further, in addition to the unique bootstrapping parameter, the blockchain transaction contains ownership transaction details, such as, for example, vendor information, manufacturer information, distributor information, or user information. Accordingly, each blockchain transaction includes at least the ownership transaction information in the form of an ownership change request, the encrypted bootstrapping parameter, and a previous block ID storing a previous ownership transaction of the IoT device. For example, such a blockchain transaction indicates that the IoT device 102 is being transferred from a first owner (i.e., a manufacturer) to a second owner (i.e., a distributor).

[0079] The memory 112 can be implemented using a non-transitory computer readable medium, such as computer storage medium. Computer readable medium includes at least two types of computer readable medium, which are computer storage medium and communication medium. In addition, computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any system or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage medium includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store data accessed by a computing device. In contrast, communication medium can include computer readable instructions, data structures, program modules or other data in modulated data signals such as carrier waves or other transport mechanisms.

[0080] In one embodiment, the bootstrap network 110 is generated by the second owner device 108 by utilizing the decrypted unique bootstrap parameter associated with the IoT device 102. In one or more embodiments, the server 101 is further configured to cause the second owner device 108 to provide the bootstrap network 110 utilizing the decrypted unique bootstrap parameter. In providing the bootstrap network 110, the server 101 is further configured to cause the IoT device 102 to connect to the provided bootstrap network 110 in a non-operational mode by utilizing the embedded unique bootstrap parameter in the memory 112, receive operational parameters of an operational network 114 of the second owner from the second owner device 108, and connect to the operational network 114 of the second owner utilizing the received operational parameters to operate in an operational mode.

[0081] The decrypted unique bootstrap parameter enables the IoT device 102 to identify the provided bootstrap network 110 by the network identifier present in the unique bootstrap parameter, and at the same time enables the IoT device 102 to connect or join the provided bootstrap network 110 by the network credentials. Advantageously, the decrypted unique bootstrap parameter enables the second owner device 108 (or bootstrap device) to develop a customized bootstrap network 110, i.e., specific to the IoT device 102, to prevent any potential misbinding attacks.

[0082] The term "non-operational mode" refers to a state of the IoT device 102, wherein the IoT is ready for bootstrap by the second owner device 108. For example, a newly purchased IoT device will only connect to the bootstrap network 110 and not to any other network to prevent misbinding attacks.

[0083] The term "operational parameters" as used herein refers to information required for the IoT device 102 to connect to the second owner's operational network 114 (also referred to as the user's IoT network or environment). For example, the operational parameters can include one or more of a network identifier or network credentials.

[0084] Further, the term "operational network" as used herein refers to a private network operated by the second owner through the second owner device 108. In one example, the operational network 114 is a home-based Wi-Fi network of an end user. In another example, the operational network 114 is a large network of interconnected second owner devices 108, where the second owner can be a manufacturer or a large company. TM

[0085] In particular, in the non-operational mode, the server 101 causes the IoT device 102 to connect to the provided bootstrap network 110 by using the unique bootstrap parameters. Further, this connection with the bootstrap network enables the IoT device 110 to receive the operational parameters of the operational network 114 associated with the second owner, enabling the IoT device to operate and communicate within the operational network 114. Advantageously, the server 101 causes the IoT device 102 to connect to only a specific network, i.e., the bootstrap network 110, where the IoT device 102 can revert to the non-operational mode by resetting the IoT device 102 or sending another ownership change request once bootstrapped.

[0086] In another embodiment, when the IoT device 102 is in the operational mode, upon receiving the ownership change request of the IoT device 102, the IoT device 102 is configured to generate alternative unique bootstrap parameters for the IoT device 102. The alternative unique bootstrap parameters can include at least alternative bootstrap network identifier and alternative bootstrap network credentials for joining the alternative bootstrap network 110A and embedding the generated alternative unique bootstrap parameters in the memory 112 of the IoT device 102. The alternative unique bootstrap parameters are generated since the existing unique bootstrap parameters generated by the manufacturer or retailer (i.e., the old first owner) will not work. The unique bootstrap parameters are associated with the bootstrap network 110 of the current first owner, and hence, a new or alternative unique bootstrap parameter is required for connecting to the alternative bootstrap network 110A for bootstrapping operations.

[0087] ​It is to be understood that the alternative bootstrapping network 110A and the associated alternative unique bootstrapping parameters are similar in structure and operation to the unique bootstrapping parameters and the bootstrapping network 110. The term "operational mode" as used herein refers to the state of the IoT device 102 after successful bootstrapping and can be used by the owner. In the operational mode, the IoT device 102 is used to connect or join the operational network 114 of the second owner that is configured during the bootstrapping operation. Typically, in case of a change of ownership request of the IoT device 102 is received in the operational mode, the IoT device 102 is used to join the operational network 114, i.e. the network environment associated with the second owner.

[0088] However, the provision of the generated unique bootstrapping parameters is vulnerable to external malicious attacks and therefore needs to be securely transmitted to the database 104 by the server 101 or the first owner device 106. Therefore, in order to securely provide the unique bootstrapping parameters, the server 101 is further used to, upon receiving the change of ownership request, encrypt the generated unique bootstrapping parameters using the public key of the second owner and send the encrypted unique bootstrapping parameters to the database 104. Here, the server 101 can be part of the first owner device 106 which can create a blockchain transaction for encrypting the unique bootstrapping parameters. Alternatively, the server 101 can be used to cause the first owner device 106 to create a blockchain transaction and thereby encrypt the unique bootstrapping parameters for further transmission to the database 104.

[0089] Upon generation of the generated unique bootstrapping parameters, the server 101 encrypts the unique bootstrapping parameters using the public key of the second owner. It is to be noted that the bootstrapping parameters are generated within the IoT device 102 and thereby leave the IoT device 102 in an encrypted form, wherein the encryption is done using the public key of the second owner, i.e. the recipient. It is to be noted that in case of a change of ownership without actually interacting with the IoT device 102, such as in case of a transfer from the manufacturer to the first user through distributors and retailers, the unique bootstrapping parameters are encrypted by the first owner, i.e. the manufacturer, and not on the IoT device itself using the public key of the second owner. For this purpose, the first owner needs to have access to a unique set of bootstrapping parameters that are not yet used to bootstrap the IoT device 102.

[0090] For example, the distributor receives the unique bootstrapping parameters by decrypting it from the relevant block using its public key, thereby re-encrypting it using the public key of the retailer. Once the unique bootstrapping parameters are generated, the server 101 is used to encrypt the unique bootstrapping parameters using the public key of the second owner and send it to the database 104 for storage and / or processing.

[0091] It should be noted that the second owner's public key is used as part of the ownership change request to enable the secure transmission of unique boot parameters, i.e., to enable encryption of the boot information before it is transmitted via server 101. Such public-key encryption is essential for determining the decryption key; that is, it is not feasible to perform decryption only when the cryptographic algorithm and encryption key are known, where either the second owner's public or private key can be used for encryption, and the other key is used for decryption.

[0092] Advantageously, due to the public-key cryptography system, the second owner's public key can be freely shared, allowing the first user to easily and conveniently verify the digital signature. The private key is kept secret, ensuring that only the second owner of the IoT device 102, who possesses the private key, can decrypt the bootstrap parameters and create the digital signature required for authorization.

[0093] In one or more embodiments, server 101 is configured to enable first owner device 106 to embed a trust anchor in the memory 112 of IoT device 102 during manufacturing, allowing IoT device 102 to verify the manufacturer's public key, thereby establishing the manufacturer as the first owner of IoT device 102. Typically, because IoT device 102 is a small entity, i.e., has a small footprint, verification of the entire blockchain 104 by IoT device 102 is not feasible. Therefore, an entity or mechanism is needed to verify all blocks in blockchain 104 on behalf of IoT device 102.

[0094] This verification on behalf of IoT device 102 is performed by a trusted node in server 101 (i.e., a node trusted by the IoT device), where IoT device 102 requires a trust anchor to verify the certificate signed by the trusted node. Here, the first owner device 106 embeds at least two trust anchors: a first trust anchor for verifying the manufacturer's public key and a second trust anchor for verifying the certificate signed by the trusted node of server 101. The embedded trust anchors act as verification authorities, enabling IoT device 102 to verify the manufacturer's and / or IoT device 102's signing key, i.e., the signature verification key, in order to establish the manufacturer as the first owner and verify the certificate signed by the trusted node of server 101.

[0095] The term "trust anchor" refers to an entity used to verify the identity of the first owner (e.g., a service provider or manufacturer). In one example, a trust anchor includes a hash of a public key, an authenticated path, or a chain to a trusted root of authority. This implementation of the trust anchor allows IoT device 102 to identify and verify the manufacturer as the first owner by verifying the provided first owner's public key through the trust anchor. Advantageously, system 100 utilizes blocks from database 104 as trust anchors, which enables IoT device 102 to establish a secure channel with boot device 108 to complete the boot process through system 100, thereby improving the reliability and security of system 100.

[0096] After receiving a unique boot parameter from the first owner device 106 or server 101, database 104 stores the encrypted unique boot parameter in block 104A, which has a block ID and transmits the block ID to the second owner device 108 in response to an ownership change request. Typically, operations populate database 104 chronologically and are stored as a series of blocks 104A, 104B, 104C, 104D, etc., across multiple distributed ledgers. An interconnected chain is formed between the series of blocks 104A, 104B, 104C, 104D, where each block references its predecessors to form the blockchain database 104.

[0097] The encrypted, unique bootstrap parameters received from server 101 are stored in block 104A of database 104, where block 104A includes a block ID. Furthermore, database 104 is used to store other information related to the bootstrap information in block 104A, including but not limited to ownership transfer information, previously related block IDs containing information about the transfer of ownership to a second owner, additional bootstrap information, and a signature calculated using the second owner's public key on all previous information.

[0098] For example, such a blockchain transaction indicates that IoT device 102 is being transferred from a first owner (i.e., the manufacturer) to a second owner (i.e., the distributor). Here, the first owner creates the blockchain transaction, in which the first owner declares that IoT device 102 is manufactured or is being manufactured. Therefore, the blockchain transaction is recorded in the initial block 104A, and the next transaction is called the previous block. It should be noted that the previous block ID helps the second owner track the validity of the transaction and indicates how and from whom the first owner received IoT device 102.

[0099] Furthermore, each block in blockchain 104 can contain multiple blockchain transactions, each transaction serving an event, such as the transfer of the exemplary IoT device 102 from one user to another, i.e., from the first owner to the second owner. An owner or user simply creates a blockchain transaction and thereby requests blockchain server 101 to include that transaction in a block of blockchain 104, where nodes in blockchain 104 compete to add a block containing the blockchain transaction, which takes effect upon successful generation.

[0100] The term "block ID" refers to the primary identifier of a block (e.g., block 104A) used to clearly identify the associated block. The block ID is a cryptographic hash (i.e., a digital fingerprint) generated by hashing the block header twice using the SHA256 algorithm to produce a 32-byte hash (i.e., the block hash or block ID). The block ID enables other connected nodes (e.g., the second owner device 108) to recognize block 104A associated with the unique boot parameters and enable retrieval. Furthermore, when an ownership change request is received from the first owner device 106, the database 104 transmits the block ID to the second owner device 108, allowing the second owner device 108 to further retrieve the cryptographically unique boot parameters from the database 104 using the block ID.

[0101] Server 101 is also configured to enable the second owner device 108 to extract the encrypted unique boot parameters based on the transmitted block ID, and to decrypt the unique boot parameters using the second owner's private key. Typically, when the second owner device 108 receives the block ID of block 104A containing the encrypted unique boot parameters, server 101 enables the second owner device 108 to extract the encrypted unique boot parameters based on the transmitted block ID, and to decrypt the unique boot parameters using the second owner's private key via the second owner device 108.

[0102] A "private key" refers to another part or key of the asymmetric key pair generated by the first owner device 106 for the encrypted unique boot parameters. Typically, each second owner has a separate private key to allow decryption of the encrypted unique boot parameters. The new owner, i.e., the second owner of IoT device 102, can extract the unique boot parameters from the relevant block 104A in blockchain 104 to allow the second owner's boot device 108 to use the boot parameters to create or join a device-specific, one-time boot network 110 for the automatic (i.e., without any user intervention) accurate (or authorized) booting of IoT device 102.

[0103] refer to Figure 2The figure shows a flowchart illustrating the steps involved in a method 200 for managing the boot of an Internet of Things (IoT) device 102 according to an embodiment of the present invention. As shown, the method 200 includes steps 202, 204, 206, 208, 210, 212, 214, and 216.

[0104] In step 202, method 200 further includes: receiving an ownership change request for the IoT device 102 from a first owner to a second owner, the ownership change request including at least the public key of the second owner. Herein, server 101 is used to transmit the ownership change request for the IoT device 102 from a first owner (e.g., a manufacturer) to a second owner (e.g., an end user), for example, during the sale of the IoT device from a retailer to an end user. Herein, the ownership change request includes at least the public key of the second owner used to encrypt confidential information. For example, the ownership change request may include IoT device information, retailer information, user information, manufacturer information, etc.

[0105] In step 204, method 200 further includes: in response to receiving an ownership change request, generating unique boot parameters for IoT device 102, the unique boot parameters including at least a boot network identifier and a boot network credential for joining boot network 110. After receiving the ownership change request from a first owner device via a first owner device 106, method 200 generates unique boot parameters for IoT device 102 in response to receiving the ownership change request. Generating unique boot parameters for IoT device 102 includes, but is not limited to, the boot network identifier, boot network credential, boot device identifier, operation information or configuration information of IoT device 102, and other relevant boot information that method 200 may need for booting IoT device 102 and enabling operation. Optionally, the unique boot parameters also include one or more of a device identifier or a boot network protocol.

[0106] In step 206, method 200 further includes embedding unique boot parameters into the memory 112 of the IoT device 102. Typically, after generating the unique boot parameters, the unique boot parameters are stored in the memory 112 of the IoT device 102. This enables further booting operations to be performed using unique boot parameters directly from the memory 112 of the IoT device.

[0107] In step 208, method 200 further includes encrypting the unique boot parameter using the public key of the second owner. After embedding the unique boot parameter into the memory 112 of the IoT device 102, method 200 also encrypts the unique boot parameter using the public key of the second owner received along with the ownership change request. This public key encryption is to prevent unauthorized access to the unique boot parameter transmitted during operation and to allow for confidential transmission of the parameter via method 200.

[0108] Optionally, method 200 further includes: the first owner of IoT device 102 signing the encrypted unique boot parameters using a signing key to generate a signed message; and storing the signed message along with the encrypted unique boot parameters in block 104A of database 104. Typically, to provide enhanced security and reliability to method 200, the first owner (or manufacturer) generates the signed message using a signing key, i.e., a private signing key. This enables the second owner to verify the initiation of the ownership transfer request.

[0109] When generating the signature message, method 200 also includes storing the signature message, along with unique boot parameters and an ownership change request, in block 104A of the database. The second owner device 108 can further extract the signature message and unique boot parameters during the boot process.

[0110] Optionally, method 200 also includes verifying the encrypted unique bootstrap parameter by verifying the signing key associated with the signed message.

[0111] Optionally, method 200 further includes: the bootstrapping device 108 of the second owner verifying the signature message; and the bootstrapping device 108 of the second owner decrypting the encrypted unique bootstrapping parameter in response to the verification of the signature message. After storing the signature message together with the unique bootstrapping parameter, method 200 is used for the bootstrapping device 108 to verify the signature message to prevent incorrect binding by external participants and any unauthorized access; that is, the bootstrapping device 108 is used to extract and verify the signature message from the blockchain transaction, thereby extracting the unique bootstrapping parameter.

[0112] Furthermore, after successfully verifying the signature message, the boot device 108 decrypts the encrypted unique boot parameters as a response to the successful verification. It should be noted that the second owner device 108 is used to act as the boot device for the boot operation via method 200. Those skilled in the art will understand that the additional second owner boot device can also be used specifically for the boot operation without any limitations.

[0113] In one or more embodiments, the method 200 further includes embedding a trust anchor into the memory 112 of the IoT device 102 during manufacturing. This allows the IoT device 102 to verify the manufacturer's signing key to establish the manufacturer as the first owner of the IoT device 102. Typically, because the IoT device 102 is a small entity, i.e., has a small footprint, verification of the entire blockchain 104 by the IoT device 102 is not feasible; therefore, an entity or mechanism is needed to verify all blocks in the blockchain 104 on behalf of the IoT device 102.

[0114] In one embodiment, the first owner device 106 embeds at least two trust anchors: a first trust anchor for verifying the manufacturer's public key and a second trust anchor for verifying the certificate signed by a trusted node of server 101. This verification on behalf of IoT device 102 is performed by a trusted node in server 101 (i.e., a trusted node for the IoT device). IoT device 102 can request the trust anchors to verify the certificate signed by the trusted node. The embedded trust anchors act as verification authorities, enabling IoT device 102 to verify the manufacturer's and / or IoT device 102's signing key, i.e., the signature verification key, to establish the manufacturer as the first owner and verify the certificate signed by the trusted node of server 101.

[0115] In step 210, method 200 includes storing encrypted unique boot parameters and an ownership change request in a block of a database, the block having a block ID. After encrypting the unique boot parameters and verifying the ownership change request, method 200 stores the encrypted unique boot parameters and ownership change request in block 104A of database 104, block 104A having a block ID. Block 104A of database 104 includes all boot information required by method 200 or the second owner device 108 to bootstrap the IoT device 102. In one embodiment, the boot information in block 104A includes at least the encrypted unique boot parameters, the ownership change request, a signature message, the previous block ID, and other boot information.

[0116] In step 212, method 200 further includes transmitting a block ID to the second owner. To enable the second owner device 108 to access bootstrap information from block 104A of database 104, method 200 transmits the block ID, allowing the second owner to accurately identify the relevant block 104A from database 104 containing the required bootstrap information, and also enabling the IoT device 102 to verify blockchain transactions.

[0117] In step 214, method 200 further includes: the second owner's boot device 108 extracting encrypted unique boot parameters based on the transmitted block ID. When a block ID is received from database 104, method 200 is also used for the second owner's boot device 108 to extract encrypted unique boot parameters based on the transmitted block ID. Here, the boot device 108 is used to extract unique boot parameters based on the block ID, such that the encrypted unique boot parameters are further processed to enable booting operations. It should be understood that in some cases, the boot device 108 may differ from the second owner device 108, without limiting any aspects of the disclosed embodiments.

[0118] In step 216, method 200 further includes: the second owner's boot device 108 decrypting the encrypted unique boot parameter using the second owner's private key. Typically, in order to utilize the encrypted unique boot parameter, the boot device 108 is used to decrypt the encrypted unique boot parameter using a private decryption key from the second owner's encryption key pair (the other keys are public encryption keys used to encrypt the encrypted unique boot parameter).

[0119] Optionally, method 200 further includes: providing a boot network 110 using unique boot parameters decrypted by the boot device 108 of the second owner; and operating the IoT device 102 in a non-operational mode to connect to the boot network 110 provided by the boot device 108 of the second owner by utilizing the unique boot parameters embedded in memory 112, to receive operation parameters of the second owner's operation network 114 from the boot device 108. Here, the second owner using the boot device 108 is used to generate the boot network 110 for booting the IoT device 102. It is assumed that the boot device 108 can access the second owner's blockchain account information and can obtain the relevant block 104A from database 104, and therefore, the boot device 108 can operate, for example, as a Wi-Fi access point (AP).

[0120] The bootloader 108 extracts the public encryption key of the IoT device 102 from the blockchain transaction. Furthermore, the bootloader 108 acts as a Wi-Fi access point to create a boot network 110 with a given boot network identifier information derived from unique boot parameters.

[0121] Furthermore, the bootstrapping device 108 can be used to periodically create bootstrapping networks 110, and only waits for the IoT device 102 to join or begin the process after receiving an instruction (e.g., a voice activation command) from a second owner or user. Therefore, when the IoT device 102 is powered on, it scans for available networks (e.g., Wi-Fi APs) and only joins the bootstrapping network 110 created using unique boot parameters to prevent incorrect binding.

[0122] Optionally, method 200 further includes: the IoT device 102 sending a request via the bootstrapping network 110 to the bootstrapping device 108 of the second owner to prove the block IDs of one or more blocks 104A to 104D in the database 104 storing the ownership change request, and the bootstrapping device 110 of the second owner sending the proof request to the database 104. Alternatively, the IoT device 102 is configured to send the proof request to the bootstrapping device 108 of the second owner via the bootstrapping network 110, wherein the bootstrapping device 108 is configured to further transmit the proof request to the database 104.

[0123] Typically, during the boot process, devices associated with a user or secondary owner are vulnerable to malicious attacks. Boot parameters (i.e., network identifiers and credentials) involve multiple entities (such as manufacturers, distributors, and retailers), making them susceptible to hacking by malicious entities. A malicious attacker could obtain boot parameters from the manufacturer or distributor through exploits and manipulate the boot network to boot IoT device 102. At this point, IoT device 102 needs to ensure that other entities interacting with it are authorized; therefore, it needs to verify the identity of the primary owner, i.e., whether the primary owner is authorized.

[0124] In view of this problem, the method 200 of the present invention provides such verification through proof. The term "proof" as used herein refers to the process of proving all relevant blocks in blockchain 104 (related to transactions of the IoT device 102 from manufacturer to end user). Here, "proof request" refers to the type of request initiated by the IoT device 102 to process blockchain transaction details and verify the credentials of the first owner.

[0125] To enable the transmission of the proof request, method 200 generates a bootstrapping message to IoT device 102 via bootstrapping device 108 to initiate the bootstrapping operation. Furthermore, in the confirmation process, IoT device 102 transmits a proof request for relevant block 104A from blockchain database 104. Here, relevant block 104A includes all blocks that encompass ownership transactions related to the IoT device, and is not limited to a single block or transaction. However, it will be understood that IoT device 102 may or may not request proof evidence from a trusted node.

[0126] For example, in some implementations, the IoT device may trust only trusted nodes to create proof evidence, while in other implementations, the IoT device may trust any node in blockchain 104. In some cases, the IoT device 102 may also be used to indicate the address of a trusted node in blockchain 104 that the IoT device 102 expects proof of relevant blocks 104A to 104D. Accordingly, if the IoT device 102 requires proof from a trusted node, the bootstrapping device 108 is used to send the proof request to the specific node or set of trusted nodes indicated by the IoT device 102.

[0127] In another embodiment, method 200 further includes: in response to receiving a proof request, database 104 generates proof evidence including information about one or more blocks 104A in database 104 storing the ownership transfer request. Typically, the proof evidence is generated by database 104 by verifying one or more relevant blocks 104A to 104D, that is, database 104 verifies that the ownership transfer information in each block is correct and ensures that the current owner information is available in the relevant last block.

[0128] For example, in the case of a malicious attack, where the attacker is a previous owner who provides some previous block IDs to prove that the attacker owned the device at a certain point, the blockchain network generates proof evidence in such a way that it includes the latest relevant block containing information about the actual current owner, rather than information about the attacker or previous owner. Alternatively, server 101 or a trusted node in server 101 is used to create proof evidence, namely, a signed message containing information from all relevant blocks 104A to 104D or a signed statement ensuring that the second owner is the legitimate owner of IoT device 102, and the block ID is associated with the second owner in the latest block containing ownership transfer information. It should be noted that the proof evidence is signed using the proof key of the blockchain server 101 or the trusted node.

[0129] Furthermore, the proof evidence also includes a challenge from IoT device 102 to prevent replay attacks. A "challenge" is a random value used to sign using the private signing key of IoT device 102, indicating that the signature challenge was indeed sent by IoT device 102. A guiding device 108 signs the first challenge and sends a proof request for relevant blocks 104A to 104D to the blockchain database 104. Correspondingly, a second owner signs the challenge to associate themselves with it.

[0130] Further optionally, the method 200 includes: a second owner's guiding device 108 receiving proof evidence from a database 104, and the second owner's guiding device sending the proof evidence to the IoT device via the guiding network. After generating the proof evidence, the blockchain server 101 sends the proof evidence to the IoT device 102 via the guiding device 108 for verification.

[0131] Optionally, method 200 further includes: in response to verification of the proof evidence, extracting information about the latest block in one or more blocks 104A of the database 104 storing ownership change requests. The IoT device 102 is used to verify the proof evidence, wherein it is assumed that the IoT device 102 can establish a trust relationship with the proof key through a stored trust anchor for verifying the proof evidence.

[0132] In addition, IoT device 102 is used to store copies of the latest relevant blocks 104A to 104D. Furthermore, IoT device 102 is used to extract the public key of the first owner from the relevant blocks 104A to 104D, which will be used to establish secure communication with bootstrapping device 108.

[0133] Optionally, method 200 further includes: verifying the ownership change request based on information about the latest block in one or more blocks 104A of the database 104 storing ownership change requests, and establishing a secure connection with the bootstrapping device 108 of the second owner in response to the verification of the ownership change request. Typically, the IoT device 102 and the bootstrapping device 108 involve a key exchange protocol to complete secure booting via method 200.

[0134] IoT device 102 and bootloader 108 are used to run a key exchange protocol to establish a secure channel. IoT device 102 and bootloader 108 use boot information indicated in unique boot parameters to select the key exchange protocol and securely complete the boot process. Successful completion of the boot process results in IoT device 102 obtaining operational parameters for joining the second owner's operational network 114.

[0135] Additionally, optionally, once IoT device 102 is booted, new boot parameters must be created for future booting operations with the next second owner (or user). However, the first owner can reset and reuse the unique boot parameters to boot IoT device 102 until ownership of IoT device 102 remains unchanged. Therefore, during each reboot operation with the first owner, the user must provide evidence of ownership status from the new challenge from IoT device 102.

[0136] Optionally, the method 200 further includes the IoT device 102 connecting to the second owner's operating network 114 using received operating parameters to operate in an operating mode. Therefore, once booted up, the IoT device 102 can connect to the second owner's network environment, i.e., the operating network 114.

[0137] Optionally, upon receiving an ownership change request indicating that the IoT device 102 is already in an operating mode, method 200 further includes generating alternative unique boot parameters for the IoT device 102. The alternative unique boot parameters include at least an alternative boot network identifier and alternative boot network credentials for joining the alternative boot network 110A. The generated alternative unique boot parameters are embedded in the memory 112 of the IoT device 102.

[0138] See Figure 3 This diagram illustrates an exemplary process flowchart for transferring ownership of an IoT device from a first owner to a second owner according to one or more embodiments of the present invention. As shown, when the IoT device 102 is manufactured, the IoT device is owned by the manufacturer, i.e., the first owner. The first owner is responsible for generating an ownership transfer request for the IoT device 102 through the first owner device 106.

[0139] The ownership change request is transferred from the first owner's device to server 101 and includes ownership change information from either the manufacturer (i.e., the first owner) or the end user (i.e., the second owner). The request is recorded in database 104.

[0140] During the bootstrapping process, server 101 enables the second owner device 108 to decrypt and extract encrypted boot parameters from the relevant blockchain transaction (i.e., from associated block 104A of database 104). Typically, IoT devices in non-operating mode are used to connect only to the bootstrapping network 110 created based on unique boot parameters associated with the IoT device. Therefore, when IoT device 102 is powered on, IoT device 102 and the second owner's bootstrapping device 108 automatically connect to each other using unique boot parameters.

[0141] Furthermore, during bootstrapping, IoT device 102 and bootstrapping device 108 mutually verify each other using information in blockchain 104, and upon completion, generate a new, customized bootstrapping network 110 for the next bootstrapping operation. Advantageously, the bootstrapping network 110 is unique for each IoT device 102 and can only be used once for a bootstrapping operation. IoT device 102 is used to automatically connect to a specific bootstrapping network 110 to reduce or prevent erroneous bindings.

[0142] refer to Figure 4This diagram illustrates a message flow sequence 400 of a process 400 for transferring unique boot parameters from a first owner to a second owner, as provided in one or more embodiments of the present invention. The process of transferring unique boot parameters generated by an IoT device 102 to a second owner (or consumer) is described. Typically, ownership of the IoT device 102 passes through the manufacturer, distributor, retailer, and ultimately to the user. Each owner extracts and re-encrypts the unique boot parameters and includes them in the transaction details of the next owner. It should be noted that the second owner (or end user) is the sole owner who actually bootstraps the IoT device 102 to enable utilization. Each entity signs and encrypts messages using a separate key pair (public and private keys).

[0143] As shown in the figure, in step 4.1, the first owner (i.e., the manufacturer) generates an ownership change request and transmits it to IoT device 102. The ownership change request includes at least the first owner's public key (PKe_M1), which is associated with the manufacturer's network or server.

[0144] In step 4.2.1 of step 4.2, IoT device 102 verifies the public key of the first owner through an embedded trust anchor. In step 4.2.2, in response to an ownership change request, IoT device 102 generates a unique boot parameter (D1_S0), which includes at least the required boot network identifier and credentials for joining boot network 110, as well as other boot information, such as device identifier, boot protocol, and boot credentials. In step 4.2.3, IoT device 102 encrypts the unique boot parameter for the manufacturer using the public key (PKe_M1) of the second owner, wherein the second owner is the same manufacturer that acquired ownership of the IoT device from itself. Furthermore, IoT device 102 then generates a signed message C1 using its signature key (SKs_D1), wherein the signed message is generated according to C1 = ∑{Enc(PKe_M1,D1_S0)}SKs_D1.

[0145] In step 4.3, IoT device 102 is used to transmit the signature message to the first owner, namely manufacturer M1.

[0146] In step 4.4, the first owner (M1) receives an ownership transfer request, i.e., a purchase request, from the second owner (i.e., the distributor or seller (Dist1)). The ownership transfer request contains the public key (PKe_dist1) of the second owner (i.e., the distributor).

[0147] In substep 4.5.1 of step 4.5, in response to the ownership transfer request, the first owner (M1) verifies the signed message (C1) and thereby uses its decryption key to extract the unique bootstrap parameter. In substep 4.5.2, the first owner (M1) uses the second owner's public key (PKe_Dist1) to encrypt the unique bootstrap parameter, thereby creating another signed message (C2) using its signing key (SKs_M1) to compute the signed message, wherein the computation is based on the following formula: C2 = ∑{Enc(PKe_dist1,D1_S0)}SKs_M1. In substep 4.5.3, the first owner (M1) creates a blockchain transaction (T_a) indicating that ownership of IoT device 102 is transferred from the first owner (M1) to the second owner (Dist1), thereby including C2 in the transaction details.

[0148] In sub-step 4.6.1 of step 4.6, the first owner (M1) requests blockchain server 101 to include the blockchain (T_a) into block 104A of blockchain database 104, whereby blockchain database 104 adds the transaction to the new first block 104A (B_i). Furthermore, in sub-step 4.5.2, once the new block 104A is established within blockchain 104, the second owner or distributor (dist1) obtains the relevant block 104A when requesting the relevant blockchain transaction details (T_a) from server 101.

[0149] In step 4.7, the second owner (Dist1) receives an ownership change request from another second owner or retailer (R1), wherein the ownership change request contains the public key (PKe_R1) of the other second owner.

[0150] In substep 4.8.1 of step 4.8, in response to the ownership transfer request, the first owner (Dist1) extracts another signed message (C2) from the transaction details (T_a), verifies the other signed message (C2), and extracts the unique bootstrap parameter using its decryption key. In substep 4.8.2, the first owner (Dist1) encrypts the unique bootstrap parameter using the second owner's public key (PKe_R1) and thereby creates another signed message (C3) using its signing key (SKs_dist1), where C3 = ∑{Enc(PKe_R1,D1_S0)}SKs_dist1. In substep 4.8.3, the first owner creates a second blockchain transaction (T_b) indicating that ownership of IoT device 102 is transferred from the first owner (Dist1) to the second owner (R1), and includes the third signed message (C3) in the transaction details.

[0151] In substep 4.9.1 of step 4.9, the first owner requests blockchain server 101 to include the second blockchain transaction in block 104B of blockchain 104. Database 104 adds the transaction to the second block 104B (B_j). In substep 4.9.2, once the second block 104B is established within blockchain 104, the second owner (R1) can obtain or retrieve the second block 104, thereby obtaining the details of the second blockchain transaction.

[0152] In step 4.10, the second owner (R1) receives a third ownership change request from the second owner (user U1). The third ownership request contains the second owner's public key (PKe_U1).

[0153] In sub-step 4.11.1 of step 4.11, the first owner (R1) extracts the third signature message (C3) from the second blockchain transaction (T_b), verifies the third signature message, and extracts the unique boot parameters using its decryption key. In sub-step 4.11.2, the first owner encrypts the unique boot parameters using the public key of the second owner (i.e., user U1) and creates a fourth signature message (C4) using its signature key (SKs_R1) as follows: C4 = ∑{Enc(PKe_U1,D1_S0)}SKs_R1. In sub-step 4.11.3, the first owner creates a third blockchain transaction (T_c) indicating the transfer of ownership of IoT device 102 to the second owner (U1) and includes the fourth signature message (C4) in the transaction details.

[0154] In sub-step 4.12.1 of step 4.12, the first owner (R1) requests the blockchain database server 101 to include the third blockchain transaction (T_c) into the third block 104C in blockchain 104. Blockchain server 101 adds the transaction to block 104C. In sub-step 4.12.2, once the third block 104C (B_k) is established within blockchain 104, the second owner (U1) can obtain the third block 104C from blockchain 104, thereby obtaining the third blockchain transaction (T_c). In sub-step 4.12.3, the second owner (U1) extracts a fourth signature message (C4) from the third blockchain transaction, verifies the fourth blockchain transaction, and uses its decryption key to extract a unique boot parameter, which is used to bootstrap the IoT device 102 after receiving it from the first owner (R1).

[0155] refer to Figure 5The diagram illustrates a message flow sequence for a process 500 for transmitting a unique boot parameter from a first owner to another second owner, according to another embodiment of the present invention. Here, the message flow sequence 500 for transmitting the unique boot parameter (D1_S1) generated by the IoT device 102 includes transmission from the first owner (i.e., user U1) to another second user (i.e., user U2) who purchased the device from the current user or the first user (U1).

[0156] As shown in the figure, in step 5.1, the first owner (U1) receives an ownership change request (or purchase request) from the second owner (user U2). The ownership change request includes at least the second owner's public key (PKe_U2).

[0157] In step 5.2, the first owner (U1) creates an ownership change request for IoT device 102. The ownership change request includes a signature message containing the second owner's encrypted public key (PKe_U2), where the signature message is, for example, ∑{ownership change,PKe_U2}SKs_U1.

[0158] In substep 5.3.1 of step 5.3, IoT device 102 verifies the ownership change request using bootstrap information from third block 104C. IoT device 102 stores third block 104C during bootstrap, as further explained herein. In substep 5.3.2, after verification by IoT device 102, IoT device 102 generates a new unique bootstrap parameter (D1_S1), which includes a new network identifier and credentials for joining bootstrap network 110, as well as other bootstrap information such as device identifiers and bootstrap credentials. In substep 5.3.3, IoT device 102 encrypts the generated new bootstrap parameter (or alternative bootstrap parameter) using the second owner's public key and generates a fifth signature message (C5) using a private signing key (SKs_D1). The generated fifth signature message is C5 = ∑{Enc(PKe_U2,D1_S1)}SKs_D1.

[0159] In step 5.4, IoT device 102 is used to transmit the fifth signature message C5 to the first owner (U1).

[0160] In response to the received fifth signature message, in sub-step 5.5.1 of step 5.5, the first owner of the first owner device 106 verifies the fifth signature message and generates a sixth signature message (C6) using the first owner's private signature key (SKs_U1). The sixth signature message is C6 = ∑{C5}SKs_U1. In sub-step 5.5.2, the first owner generates a fourth blockchain transaction (T_d) indicating that ownership of the IoT device is transferred from the first owner (U1) to the second owner (U2), and includes the sixth signature message in the blockchain transaction details.

[0161] In sub-step 5.6.1 of step 5.6, the first owner requests blockchain server 101 to include the fourth transaction details (T_d) in the fourth block 104D (B_l) of blockchain 104. Blockchain server 101 adds the transaction to the generated fourth block 104D. In sub-step 5.6.2, once the fourth block 104D is established within blockchain 104, the second owner (U2) is able to retrieve the fourth block 104D from blockchain 104. In sub-step 5.6.3, the second owner (U2) extracts and verifies the sixth signature message from the fourth blockchain transaction (T_d). Simultaneously, the second owner extracts and verifies the fifth signature message (C5) before extracting the unique boot parameter (D1_S1) using its decryption key. Then, after receiving the physical IoT device 102 from the first owner (U1), the second owner can use the extracted boot parameter (D1_S1) to bootstrap the IoT device.

[0162] refer to Figure 6 This diagram illustrates a flowchart of the steps involved in a message stream sequence describing a bootstrapping process 600 of system 100 or method 200 for IoT device 102 according to one or more embodiments of the present invention. Here, the message stream sequence for the bootstrapping process 600 includes a first owner (U1) using their bootstrapping device 108 to bootstrap IoT device 102. It is assumed that bootstrapping device 108 can access the user's blockchain account information and can obtain the relevant blocks 104A to 104D, and therefore, bootstrapping device 108 can operate as a Wi-Fi access point (AP).

[0163] In substep 6.1.1 of step 6.1, the bootstrapping device 108 extracts the public key (PKs_D1) of the IoT device 102 from the third blockchain transaction (T_c). In substep 6.1.2, the bootstrapping device 108 extracts and verifies the fourth signature message (C4) from the third blockchain transaction (T_c), and decrypts and extracts the unique boot parameters (D1_S0) using its encrypted private key.

[0164] In sub-step 6.1.3, the bootstrapping device 108 acts as a Wi-Fi AP to create a bootstrapping network 110 with a given bootstrapping network identifier information from a unique bootstrapping parameter (D1_S0). The bootstrapping device 108 can be used to periodically create the bootstrapping network 110 and only wait for the IoT device 102 to join or start the process after receiving an instruction (e.g., a voice activation command) from a second owner or user.

[0165] In step 6.2, when powering on IoT device 102, IoT device 102 scans for available Wi-Fi APs. IoT device 102 may join only the boot network 110 that has already been created using the unique boot parameter (D1_S0).

[0166] In step 6.3, when joining the boot network 110 via IoT device 102, boot device 108 is used to start the boot operation by sending a bootstrap message (init_bootstrap).

[0167] In step 6.4, IoT device 102 confirms the bootstrapping message by creating a first challenge (challenge1), i.e., a first random value (nonce1) signed using its private signing key (SKs_D1). The first signed challenge is then sent back to bootstrapping device 108 via bootstrapping network 110 as a request for proof of block IDs for one or more blocks 104A to 104D in database 104 storing ownership change requests. In some cases, IoT device 102 may also be used to indicate the address of a trusted node in blockchain 104 that IoT device 102 expects proof of the relevant blocks 104A to 104D.

[0168] In step 6.5, the bootstrapping device 108 is used to sign the first challenge and, upon receiving the first signed challenge containing a proof request message, sends a proof request (or proof request) for relevant blocks 104A to 104D to the blockchain server 101. For example, the relevant blocks 104A to 104C used for this bootstrapping operation are the first block (B_i), the second block (B_j), and the third block (B_k). Accordingly, if the IoT device 102 requires proof from a trusted node, the bootstrapping device 108 is used to send the proof request to a specific node or a set of trusted nodes indicated by the IoT device 102.

[0169] In step 6.6, a trusted node in blockchain server 101, in response to receiving a proof request, generates proof evidence by verifying all relevant blocks 104A to 104C. The proof evidence includes a statement indicating that all relevant blocks have been verified, and that block 104C is the latest block containing information about the latest owner of the IoT device. For example, by signing the first challenge using a proof key (AttKey), the trusted node in blockchain server 101 calculates the hash values ​​of relevant blocks 104A, 104B, and 104C and generates a statement as proof evidence, which includes information about one or more blocks 104A to 104C in database 104 storing ownership change requests. Proof evidence (AttEvidence) = ∑{Challenge1,H(B_i,B_j,B_k),Claims}AttKey.

[0170] In sub-step 6.7.1 of step 6.7, the guiding device 108 is used to receive AttEvidence from the blockchain server 101. In sub-step 6.7.2, the guiding device 108 is used to provide AttEvidence to the IoT device 102 for verification.

[0171] In sub-step 6.8.1 of step 6.8, IoT device 102 verifies the AttEvidence. It is assumed that IoT device 102 can establish a trust relationship using the AttKey to verify the AttEvidence. Verification of the AttEvidence confirms to IoT device 102 that the first owner (U1) is the latest owner. Furthermore, in sub-step 6.8.2, IoT device 102 stores a copy of the latest relevant block (B_k), i.e., the third block 104C. Furthermore, in sub-step 6.8.3, IoT device 102 extracts the first owner's public key (PKs_U1) from the third block 104C, which will be used to establish secure communication with bootstrapping device 108 and establish the first owner (U1) as the latest owner.

[0172] In substep 6.9.1 of step 6.9, IoT device 102 and bootloader 108 establish a secure channel by exchanging public keys associated with IoT device 102 (PKs_D1) and the first owner device (PKs_U1) through a key exchange protocol. IoT device 102 and bootloader 108 use boot information indicated in the unique boot parameter (D1_S0) to select the key exchange protocol and securely complete the boot operation.

[0173] In substep 6.9.2, optionally, once IoT device 102 is booted, new boot parameters must be created for future booting operations with the next second owner (or user). However, the first owner (U1) can reset and reuse the unique boot parameter (D1_S0) to boot the IoT device until ownership of IoT device 102 remains unchanged. Therefore, during each reboot operation with the first owner (U1), the user must provide AttEvidence using a new challenge from IoT device 102 to prove the first owner's ownership status.

[0174] refer to Figure 7 The diagram illustrates a message flow sequence of a zero-contact boot process 700 via Wi-Fi technology provided in one or more embodiments of the present invention, wherein an IoT device 102 is used to generate a boot network 110. In process 700, the IoT device 102 is used to create and operate the boot network 110. It should be noted that the IoT device 102 acts as the access point (AP) of the boot network 110, replacing the boot device 108.

[0175] As shown in substep 7.1.1 of step 7.1, in non-operational mode, IoT device 102 is used to boot as a Wi-Fi AP during power-up. IoT device 102 uses parameters from the unique boot parameter (D1_S0) to configure the AP for booting operations. In substep 7.1.2, IoT device 102 is used to create a boot network 110 using the AP. It should be noted that in this process 700, booting device 108 scans for available APs within range, thereby only joining the boot network 110 that has already been created using the unique boot parameter (D1_S0).

[0176] In sub-step 7.2.1, the bootstrapping device 108 extracts the public key (PKs_D1) of the IoT device 102 from the third blockchain transaction (T_c). In sub-step 7.2.2, the bootstrapping device 108 extracts and verifies the fourth signature message (C4) from the third blockchain transaction (T_c) and extracts the unique bootstrapping parameter (D1_S0). Furthermore, in sub-step 7.2.3, the bootstrapping device 108 joins the bootstrapping network 110.

[0177] In step 7.3, the boot device 108 is used to start the boot operation by sending a boot startup message (init_bootstrap).

[0178] In step 7.4, IoT device 102 confirms the bootstrapping message by creating a first challenge (challenge1), i.e., a first random value (nonce1) signed using its private signing key (SKs_D1). The first signed challenge is then sent back to bootstrapping device 108 via bootstrapping network 110 as a request for proof of block IDs for one or more blocks 104A to 104D in database 104 storing ownership change requests. In some cases, IoT device 102 may also be used to indicate the address of a trusted node in blockchain 104 that IoT device 102 expects proof of the relevant blocks 104A to 104D.

[0179] In step 7.5, the bootstrapping device 108 is used to sign the first challenge and, upon receiving the first signed challenge containing a proof request message, sends a proof request (or proof request) for relevant blocks 104A to 104D to the blockchain server 101. For example, the relevant blocks 104A to 104C used for this bootstrapping operation are the first block (B_i), the second block (B_j), and the third block (B_k). Accordingly, if the IoT device 102 requires proof from a trusted node, the bootstrapping device 108 is used to send the proof request to a specific node or a set of trusted nodes indicated by the IoT device 102.

[0180] In step 7.6, a trusted node in blockchain server 101, in response to receiving a proof request, generates proof evidence by verifying all relevant blocks 104A to 104C. The proof evidence includes a statement indicating that all relevant blocks have been verified, and that block 104C is the latest block containing information about the latest owner of the IoT device. For example, by signing the first challenge using a proof key (AttKey), the trusted node in blockchain server 101 calculates the hash values ​​of relevant blocks 104A, 104B, and 104C and generates a statement as proof evidence, which includes information about one or more blocks 104A to 104C in database 104 storing ownership change requests. Proof evidence (AttEvidence) = ∑{Challenge1,H(B_i,B_j,B_k),Claims}AttKey.

[0181] In sub-step 7.7.1 of step 7.7, the guiding device 108 is used to receive AttEvidence from the blockchain server 101. In sub-step 7.7.2, the guiding device 108 is used to provide AttEvidence to the IoT device 102 for verification.

[0182] In sub-step 7.8.1 of step 7.8, IoT device 102 verifies the AttEvidence. It is assumed that IoT device 102 can establish a trust relationship using the AttKey to verify the AttEvidence. The verification of the AttEvidence confirms to IoT device 102 that the first owner (U1) is the latest owner. In sub-step 7.8.2, IoT device 102 stores a copy of the latest relevant block (B_k), i.e., the third block 104C. In sub-step 7.8.3, IoT device 102 extracts the first owner's public key (PKs_U1) from the third block 104C, which will be used to establish secure communication with bootstrapping device 108 and establish the first owner (U1) as the latest owner.

[0183] In substep 7.9.1 of step 7.9, IoT device 102 and bootstrapping device 108 establish a secure channel by exchanging public keys associated with IoT device 102 (PKs_D1) and the first owner device (PKs_U1). IoT device 102 and bootstrapping device 108 use boot information indicated in the unique boot parameter (D1_S0) to select the key exchange protocol and securely complete the bootstrapping operation. Optionally, in substep 7.9.2, once IoT device 102 is booted, a new boot parameter must be created for future bootstrapping operations with the next second owner (or user). However, the first owner (U1) can reset and reuse the unique boot parameter (D1_S0) to boot the IoT device until ownership of IoT device 102 remains unchanged. Therefore, during each bootstrapping operation with the first owner (U1), the user must provide AttEvidence using a new challenge from IoT device 102 to prove the first owner's ownership status.

[0184] refer to Figure 8 The diagram illustrates a flowchart of a message flow sequence for a zero-contact boot process 800 provided in one or more embodiments of the present invention, wherein an IoT device 102 is used to generate a boot network 110 via Bluetooth technology. In process 800, the IoT device 102 is used to create and operate the boot network 110. It should be noted that the IoT device 102 acts as the access point (AP) of the boot network 110, replacing the boot device 108.

[0185] The creation of bootstrap network 110 is performed using a Bluetooth connection instead of Wi-Fi. Bootstrap parameters (D1_S0) are designed to include Bluetooth connection parameters, such as, but not limited to, a Bluetooth-friendly name, credentials, and a GAP profile, which the IoT device 102 and / or bootstrap device 108 are used to create and join the bootstrap network, respectively. Steps 8.3, 8.4, 8.7.2, and 8.9 are performed in the Bluetooth bootstrap network 110, not in the Wi-Fi bootstrap network, for example... Figure 7 The Wi-Fi boot network shown.

[0186] As shown in the figure, in substep 8.1.1 of step 8.1, the IoT device 102 in non-operation mode is used to start the Bluetooth network and enter the query sub-state to discover other Bluetooth devices during power-up. The IoT device 102 uses parameters from the unique boot parameter (D1_S0) to configure the Bluetooth device discovery protocol for the boot operation. In substep 8.1.2, the IoT device 102 is used to create a boot network 110 using Bluetooth radio.

[0187] In this process 800, the bootloader 108 broadcasts a device discovery query message to notify other Bluetooth devices within range. When the IoT device 102 receives the query message, both the IoT device 102 and the bootloader 108 execute the Bluetooth discovery protocol using boot parameters, thereby allowing the bootloader 108 to join only the bootloader network 110 that has already been created using unique boot parameters (D1_S0).

[0188] In substep 8.2.1 of step 8.2, the bootstrapping device 108 extracts the public key (PKs_D1) of the IoT device 102 from the third blockchain transaction (T_c). Furthermore, in substep 8.2.2, the bootstrapping device 108 extracts and verifies the fourth signature message (C4) from the third blockchain transaction (T_c) and extracts the unique bootstrapping parameter (D1_S0). In substep 8.2.3, the bootstrapping device 108 joins the bootstrapping network 110.

[0189] In step 8.3, the boot device 108 is used to start the boot operation by sending a boot startup message (init_bootstrap).

[0190] In step 8.4, IoT device 102 confirms the bootstrapping message by creating a first challenge (challenge1), i.e., a first random value (nonce1) signed using its private signing key (SKs_D1). The first signed challenge is then sent back to bootstrapping device 108 via bootstrapping network 110 as a request for proof of the block IDs of one or more blocks 104A to 104D in database 104 storing ownership change requests. In some cases, IoT device 102 may also be used to indicate the address of a trusted node in blockchain 104 that IoT device 102 expects proof of the relevant blocks 104A to 104D.

[0191] In step 8.5, the bootstrapping device 108 is used to sign the first challenge and, upon receiving the first signed challenge containing a proof request message, sends a proof request (or proof request) for relevant blocks 104A to 104D to the blockchain server 101. For example, the relevant blocks 104A to 104C used for this bootstrapping operation are the first block (B_i), the second block (B_j), and the third block (B_k). Accordingly, if the IoT device 102 requires proof from a trusted node, the bootstrapping device 108 is used to send the proof request to a specific node or a set of trusted nodes indicated by the IoT device 102.

[0192] In step 8.6, a trusted node in blockchain server 101, in response to receiving a proof request, generates proof evidence by verifying all relevant blocks 104A to 104C. The proof evidence includes a statement indicating that all relevant blocks have been verified, and that block 104C is the latest block containing information about the latest owner of the IoT device. For example, by signing the first challenge using a proof key (AttKey), the trusted node in blockchain server 101 calculates the hash values ​​of relevant blocks 104A, 104B, and 104C and generates a statement as proof evidence, which includes information about one or more blocks 104A to 104C in database 104 storing ownership change requests. Proof evidence (AttEvidence) = ∑{Challenge1,H(B_i,B_j,B_k),Claims}AttKey.

[0193] In substep 8.7.1 of step 8.7, the guiding device 108 receives AttEvidence from the blockchain server 101. In substep 8.7.2, the guiding device 108 provides AttEvidence to the IoT device 102 for verification.

[0194] In substep 8.8.1 of step 8.8, IoT device 102 verifies the AttEvidence. It is assumed that IoT device 102 can establish a trust relationship using the AttKey to verify the AttEvidence. Verification of the AttEvidence confirms to IoT device 102 that the first owner (U1) is the latest owner. In substep 8.8.2, IoT device 102 stores a copy of the latest relevant block (B_k), i.e., the third block 104C. In substep 8.8.3, IoT device 102 extracts the first owner's public key (PKs_U1) from the third block 104C, which will be used to establish secure communication with bootstrapping device 108 and establish the first owner (U1) as the latest owner.

[0195] In substep 8.9.1 of step 8.9, IoT device 102 and bootloader 108 establish a secure channel by exchanging public keys associated with IoT device 102 (PKs_D1) and the first owner device (PKs_U1) through a key exchange protocol. IoT device 102 and bootloader 108 use boot information indicated in the unique boot parameter (D1_S0) to select the key exchange protocol and securely complete the boot operation. Optionally, in substep 8.9.2, once IoT device 102 is booted, new boot parameters must be created for future boot operations with the next second owner (or user).

[0196] The first owner (U1) can reset and reuse the unique boot parameters (D1_S0) to boot the IoT device until the ownership of the IoT device 102 remains unchanged. Therefore, during each reboot operation with the first owner (U1), the user must provide AttEvidence using a new challenge from the IoT device 102 to prove the ownership status of the first owner.

[0197] The present invention also provides a computer-readable storage medium including instructions that, when executed by a computer, cause the computer to perform the steps of a method 200 for managing the boot of an Internet of Things (IoT) device 102. Examples of implementations of the non-transitory computer-readable storage medium include, but are not limited to, electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), read-only memory (ROM), hard disk drive (HDD), flash memory, secure digital (SD) cards, solid-state drives (SSDs), computer-readable storage media, and / or CPU cache. A computer-readable storage medium for providing non-transitory memory may include, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof.

[0198] Therefore, although the essential novel features of the invention applicable to exemplary embodiments thereof have been shown, described, and pointed out herein, it should be understood that those skilled in the art can make various omissions, substitutions, and changes to the form and details of the illustrated devices and methods, as well as the operation of the setup, without departing from the spirit and scope of the invention. Furthermore, all combinations of those elements that are explicitly desired to perform substantially the same function in substantially the same manner to achieve the same result are within the scope of the invention. Moreover, it should be recognized that structures and / or elements shown and / or described in conjunction with any form or embodiment of the disclosed invention can be incorporated as general design choices into any other form or embodiment disclosed, described, or suggested. Therefore, its intent is limited only as indicated by the scope of the appended claims.

Claims

1. A system (100) for managing the booting of Internet of Things (IoT) devices (102) transferred from a first owner to a second owner, characterized in that, The system includes: Database (104); A server (101) communicating with the database (104), wherein the server (101) is used for: Receive the public key of the first owner from the first owner device (106) associated with the first owner; Receive the public key of the second owner from the second owner's device (108) associated with the second owner. The IoT device (102) is used for: Generate unique boot parameters, which include at least a boot network identifier and a boot network credential for joining the boot network (110); The unique boot parameters are embedded in the memory (112) of the IoT device; The server is used for: The database is provided with a request for a change of ownership of the IoT device from the first owner to the second owner, the request for a change of ownership including at least the public key of the second owner; Upon receiving the ownership change request, the generated unique bootstrap parameter is encrypted using the public key of the second owner; Send the encrypted unique boot parameters to the database; The database is used for: The encrypted unique boot parameters are stored in block (104A), which has a block ID; In response to the ownership change request, the block ID is transmitted to the second owner device; The server is also configured to enable the second owner device to perform the following operations: Extract the encrypted unique boot parameters based on the transmitted block ID; The unique boot parameters are decrypted using the second owner's private key.

2. The system (100) according to claim 1, characterized in that, The server (101) is also configured to enable the first owner device (106) to embed a trust anchor in the memory (112) of the IoT device (102) during manufacturing, so as to allow the IoT device (102) to verify the manufacturer's public key, thereby establishing the manufacturer as the first owner of the IoT device.

3. The system (100) according to claim 1 or 2, characterized in that, The server (101) is also used for: The second owner device (108) uses the decrypted unique boot parameters to provide a boot network (110). The IoT device (102) in non-operation mode connects to the provided boot network (110) by utilizing the embedded unique boot parameters in the memory (112) to receive operation parameters from the second owner's operation network (114) from the second owner device (108); The IoT device (102) is connected to the second owner's operating network (114) using the received operating parameters to operate in operating mode.

4. The system (100) according to claim 3, characterized in that, When the IoT device (102) is in the operating mode, upon receiving the ownership change request from the IoT device (102), the IoT device is configured to: Generate alternative unique boot parameters for the IoT device, the alternative unique boot parameters including at least an alternative boot network identifier and an alternative boot network credential for joining the alternative boot network (110A); The generated alternative unique boot parameters are embedded in the memory (112) of the IoT device.

5. The system (100) according to claim 1 or 2, characterized in that, The database (104) is any one of a centralized database, a distributed ledger, or a blockchain.

6. The system (100) according to claim 5, characterized in that, The database (104) is any one of a public blockchain, a private blockchain, a consortium blockchain, or a hybrid blockchain.

7. A method (200) for managing the boot process of Internet of Things (IoT) devices, characterized in that, The method (200) includes: Receive (202) the ownership change request of the IoT device from the first owner to the second owner, the ownership change request including at least the public key of the second owner; In response to receiving the ownership change request, a unique boot parameter (204) is generated for the IoT device, the unique boot parameter including at least a boot network identifier and a boot network credential for joining the boot network; The unique boot parameter is embedded (206) into the memory of the IoT device; The unique bootstrap parameter is encrypted using the public key of the second owner (208); The encrypted unique boot parameters and the ownership change request are stored (210) in a block of the database, the block having a block ID; Transmit the block ID (212) to the second owner; The second owner's boot device extracts (214) the encrypted unique boot parameters based on the transmitted block ID; The boot device of the second owner uses the private key of the second owner to decrypt the encrypted unique boot parameters (216).

8. The method (200) according to claim 7, characterized in that, Also includes: The first owner of the IoT device uses a signing key to sign the encrypted unique boot parameters to generate a signed message; The signature message, along with the encrypted unique boot parameters, is stored in the block of the database.

9. The method (200) according to claim 8, characterized in that, Also includes: The boot device of the second owner verifies the signature message; The boot device of the second owner decrypts the encrypted unique boot parameters in response to the verification of the signature message.

10. The method (200) according to any one of claims 7 to 9, characterized in that, Also includes: During manufacturing, a trust anchor is embedded in the memory of the IoT device to allow the IoT device to verify the manufacturer's signature key, thereby establishing the manufacturer as the first owner of the IoT device.

11. The method (200) according to any one of claims 7 to 9, characterized in that, Also includes: The second owner's boot device uses the decrypted unique boot parameters to provide a boot network; The IoT device in non-operation mode is connected to the boot network provided by the boot device of the second owner by utilizing the unique boot parameters embedded in the memory, so as to receive operation parameters of the second owner's operation network from the boot device.

12. The method (200) according to claim 11, characterized in that, Also includes: The second owner's guiding device sends a proof request via the guiding network to the IoT device for the block ID of one or more blocks in the database that stores the ownership change request; The second owner's boot device sends the proof request to the database; In response to receiving the proof request, the database generates proof evidence including information about one or more blocks in the database that store the ownership change request; The second owner's boot device receives the proof of evidence from the database; The second owner's guiding device sends the proof of evidence to the IoT device through the guiding network.

13. The method (200) according to claim 12, characterized in that, The method further includes: The evidence presented is verified. In response to the verification of the evidentiary evidence, information about the latest block in the one or more blocks in the database storing the ownership change request is extracted; The ownership change request is verified based on the information regarding the latest block in one or more blocks in the database where the ownership change request is stored; In response to the verification of the ownership change request, a secure connection is established with the boot device (108) of the second owner.

14. The method (200) according to any one of claims 7 to 9, characterized in that, It also includes the IoT device connecting to the second owner's operating network using the received operating parameters to operate in operating mode.

15. The method (200) according to claim 14, characterized in that, Upon receiving the ownership change request from the IoT device already in the operating mode, the method further includes: Generate alternative unique boot parameters for the IoT device, the alternative unique boot parameters including at least an alternative boot network identifier and an alternative boot network credential for joining the alternative boot network; The generated alternative unique boot parameters are embedded in the memory of the IoT device.

16. The method (200) according to any one of claims 7 to 9, characterized in that, The database is one of a centralized database, a distributed ledger, or a blockchain.

17. The method (200) according to any one of claims 7 to 9, characterized in that, The database is one of the following: public database, private database, consortium database, or hybrid database.

18. The method (200) according to any one of claims 7 to 9, characterized in that, The unique boot parameters also include one or more of the device identifier or boot network protocol.

Images