Method and system for managing boot

Abstract

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

Description

Technical Field

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

[0002] In recent years, with the rapid development of technology, the number of devices that can be connected to the Internet has increased exponentially, and these devices are being used by users around the world, 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 use to improve accessibility, efficiency, productivity and user experience. However, in order for such IoT devices to operate in the user's environment (or network), such devices need to be "guided".

[0003] The booting of an IoT device 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 booted by a user or other personnel. In some examples, device-specific boot parameters are embedded in a machine-readable code, such as a QR code or a barcode printed on the surface of the IoT device. Here, the IoT device creates a boot network when powered on, and obtains the boot parameters by the user scanning the QR code to join the boot network. However, such an implementation requires external user participation to complete the boot process. Such manual operations cannot enable millions of IoT devices to be onboarded in the next few years, which makes the overall boot operation very time-consuming and expensive.

[0004] There have been some attempts to address the above issues, such as zero-touch booting of IoT devices, where IoT devices automatically boot when "powered on", thereby limiting or excluding any external user involvement. However, since these technical solutions use predefined boot networks, they are not sufficient to prevent the wrong binding of devices during the boot process. Therefore, any device can join the predefined boot network and operate the network to attract devices to join the boot network.

[0005] Therefore, based on the above discussion, there is a need for a system or method for safely, reliably and efficiently managing zero-touch booting of Internet of Things (IoT) devices. Therefore, it is desirable to provide a system and method that solves at least some of the above problems. Summary of the invention

[0006] Aspects of the disclosed embodiments are directed to a method and apparatus for booting an Internet of Things (IoT) device, substantially as shown in and / or described in conjunction with at least one of the accompanying drawings as more fully set forth in the claims. Aspects of the disclosed embodiments provide a zero-touch boot process in which the device is connected to a proper boot network and boots without any user action other than powering on the device.

[0007] According to a first aspect, the above and further implementations and advantages are obtained by a method for managing the booting of an Internet of Things (IoT) device. In one embodiment, the method includes: receiving an ownership change request of the IoT device from a first owner to a second owner, the ownership change request including at least a public key of the second owner; in response to receiving the ownership change request, generating a unique boot parameter for the IoT device, the unique boot parameter including at least a boot network identifier and a boot network credential for joining a boot network; embedding the unique boot parameter in a memory of the IoT device; encrypting the unique boot parameter using the public key of the second owner; storing the encrypted unique boot parameter and the ownership change request in a block of a database, the block having a block ID; transmitting the block ID to the second owner; the boot device of the second owner extracts the encrypted unique boot parameter according to the transmitted block ID; the boot device of the second owner decrypts the encrypted unique boot parameter using the private key of the second owner. Aspects of the disclosed embodiments provide a zero-touch boot process in which a device is connected to a correct boot network and can be booted without any user action other than powering on the device.

[0008] In one possible implementation, the method further includes: the first owner of the IoT device signs the encrypted unique boot parameter using a signature key to generate a signature message; and stores the signature message together with the encrypted unique boot parameter in the block of the database. Aspects of the disclosed embodiments provide a zero-touch boot method for IoT devices to prevent incorrect binding. The IoT device connects to the correct boot network and obtains correct boot without any user operation other than powering on.

[0009] In a possible implementation, the method further includes: the boot device of the second owner verifies the signed message; the boot device of the second owner decrypts the encrypted unique boot parameter in response to the verification of the signed message. The device owner creates a device-specific boot network using the boot parameter and automatically boots the device using other parameters.

[0010] In one 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 the manufacturer's signing key, thereby establishing the manufacturer as the first owner of the IoT device. Using the blockchain as a trust anchor allows the IoT device to establish a secure channel with a boot device to complete the boot process.

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

[0012] In one possible implementation, the method further includes: the IoT device sends a proof request for the block ID of one or more blocks in the database storing the ownership change request to the boot device of the second owner through the boot network; the boot device of the second owner sends the proof request to the database; the database generates proof evidence including information about one or more blocks in the database storing the ownership change request in response to receiving the proof request; the boot device of the second owner receives the proof evidence from the database; the boot device of the second owner sends the proof evidence to the IoT device through the boot network. Various aspects of the disclosed embodiments utilize blockchain technology to facilitate zero-touch booting and prevent incorrect binding. During the boot process, devices use information in the blockchain to verify each other.

[0013] In one possible implementation, the method further includes: the IoT device verifies the proof evidence; in response to the verification of the proof evidence, extracts information about the latest block of the one or more blocks in the database storing the ownership change request; verifies the ownership change request based on 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, establishes a secure connection with the boot device of the second owner. The new owner of the device can extract boot parameters from the relevant blocks in the blockchain, so that the boot device of the new owner can use these parameters to create or join a device-specific, one-time-use boot network to automatically boot the correct device.

[0014] In one possible implementation, the method further includes the IoT device connecting to the operational network of the second owner using the received operational parameters to operate in operational mode. The boot network is unique to each device and can only be used to boot the device once. The device in non-operational mode is designed to only connect to the boot network created according to the boot parameters.

[0015] In a possible implementation, in the case of receiving the ownership change request of the IoT device that is already in the operation mode, the method further includes: generating an alternative unique boot parameter for the IoT device, the alternative unique boot parameter at least including an alternative boot network identifier and an alternative boot network credential for joining an alternative boot network; embedding the generated alternative unique boot parameter into the memory of the IoT device. The device owner uses the boot parameter to create a device-specific boot network and automatically boots the device using other parameters.

[0016] In one 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. During the boot process, the user decrypts the encrypted boot parameters and extracts the encrypted boot parameters from the relevant blockchain transaction.

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

[0018] In a possible implementation manner, the unique boot parameter further includes one or more of a device identifier or a boot network protocol.

[0019] According to a second aspect, the above and further implementations and advantages are obtained by a system for managing booting of an Internet of Things (IoT) device. In one embodiment, the system includes: a database; a first owner device associated with the first owner, the first owner device is used to provide a public key of the first owner; a second owner device associated with the second owner device, the second owner device is used to provide the public key of the second owner; wherein the IoT device is used to generate a unique boot parameter and embed the unique boot parameter in a memory, the unique boot parameter comprising at least a boot network identifier and a boot network credential for joining a boot network. 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 comprising at least the public key of the second owner. The first owner device is also used to: encrypt the generated unique boot parameter using the public key of the second owner according to receiving the ownership change request, and send the encrypted unique boot parameter to the database. The database is used to store the encrypted unique boot parameter in a block with 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 used to extract the encrypted unique boot parameter according to the transmitted block ID, and decrypt the unique boot parameter using the private key of the second owner.

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

[0021] In one possible implementation, the second owner device is used to: use the decrypted unique boot parameter to provide a boot network, and the IoT device in the non-operating mode is used to connect to the provided boot network by using the embedded unique boot parameter in the memory to receive the operating parameters of the operating network of the second owner from the second owner device; the IoT device is used to: use the received operating parameters to connect to the operating network of the second owner to operate in the operating mode.

[0022] In one possible implementation, upon receiving the ownership change request of the IoT device that is already in the operating mode, the IoT device is further configured to: generate alternative unique boot parameters for the IoT device, the alternative unique boot parameters comprising at least an alternative boot network identifier and an alternative boot network credential for joining an alternative boot network; and embed the generated alternative unique boot parameters into the memory of the IoT device. Aspects of the disclosed embodiments use a device-specific, single-purpose boot network. Both participating devices have prior knowledge of the network identifier and credential for joining the boot network and other parameters.

[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 booting by using information in the blockchain to create a unique boot network to prevent incorrect binding, the device is programmed to automatically join the unique boot network, and continues booting 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 booting by using information in the blockchain to create a unique boot network to prevent false binding, the device is programmed to automatically join the unique boot network, and continues booting after mutual authentication.

[0025] These and other aspects, implementations and advantages of the exemplary embodiments will become apparent from the embodiments described herein when considered in conjunction with the accompanying drawings. It should be understood, however, that such description and drawings are for illustrative purposes only and are not intended to limit the invention; any limitations of the invention should be understood by reference to the appended claims. Additional aspects and advantages of the invention will be set forth in the subsequent description, and some aspects and advantages will be apparent from the description or may be learned by practicing the invention. In addition, aspects and advantages of the invention may be realized and obtained by the means or combinations specifically indicated in the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In the following detailed description of the invention, the invention will be explained in more detail with reference to example embodiments shown in the accompanying drawings, wherein like references indicate like elements, and:

[0027] Figure 1 A block diagram of an exemplary system zero-touch boot for an Internet of Things (IoT) device provided in accordance with an embodiment of the present invention;

[0028] Figure 2A flowchart listing the steps included in a method for booting an Internet of Things (IoT) device is provided for an embodiment of the present invention;

[0029] Figure 3 An exemplary flow chart of a system 100 or method 200 for guiding an IoT device from a first owner to a second owner provided by an embodiment of the present invention;

[0030] Figure 4 A flow chart of a message flow sequence for a process of transmitting unique boot parameters from a first owner to a second owner provided for an embodiment of the present invention;

[0031] Figure 5 A flowchart of a message flow sequence for a process of transmitting unique boot parameters from a first owner to another second owner provided by an embodiment of the present invention;

[0032] Figure 6 The IoT device 102 provided in the embodiment of the present invention is Figure 1 system or Figure 2 A flowchart of a message flow sequence of a boot process of a method;

[0033] Figure 7 A flowchart of a message flow sequence for a zero-touch boot process using Wi-Fi technology provided by an embodiment of the present invention;

[0034] Figure 8 A flowchart of a message flow sequence of a zero-touch boot process using Bluetooth technology provided by another embodiment of the present invention.

[0035] In the drawings, underlined numbers are used to indicate the item in which the underlined number is located or the item adjacent to the underlined number. Non-underlined numbers are associated with the item identified by the line linking the non-underlined number to the item. When a number is not underlined but has an associated arrow, the non-underlined number is used to identify the general item to which the arrow points. DETAILED DESCRIPTION

[0036] The following detailed description describes embodiments of the invention and ways in which these embodiments may be implemented. Although some embodiments of the invention have been disclosed, those skilled in the art will recognize that other embodiments may be implemented to implement or practice the invention.

[0037] refer to Figure 1 , a block diagram of an exemplary system 100 for managing the booting of an Internet of Things (IoT) device 102 transferred from a first owner to a second owner according to aspects of embodiments of the present invention is shown. Figure 1As shown, the system 100 generally includes an IoT device transferred from a first owner to a second owner. The first owner device associated with the first owner is used to provide a public key of the first owner. The second owner device associated with the second owner is used to provide the public key of the second owner. The IoT device is used to: generate unique boot parameters, the unique boot parameters including at least a boot network identifier and a boot network credential for joining a boot network. The unique boot parameters are embedded in a memory of the IoT device.

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

[0039] In one embodiment, the database is used to store the encrypted unique boot parameter in a block, and the block has a block ID. For example, the processor can be used to enable the database to store the encrypted unique boot 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 boot parameter according to the transmitted block ID, and decrypt the unique boot parameter using the private key of the second owner.

[0040] The term "booting" as used herein refers to the 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 boot operations, such as factory booting, media-based booting, or remote booting, such as boot information, i.e., information required for the IoT device 102 to initiate communication with other elements within a network, such as but not limited to boot network creation parameters, credentials, device ID, media access control (MAC) address, Internet protocol (IP) address, and other information that facilitates booting, is embedded in the IoT device 102 via the boot device 104.

[0041] As used herein, the term "IoT device" refers to a physical object (or group of such objects), including hardware, software, and / or firmware, that is used to connect and exchange 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 by a controller device (e.g., a smartphone, a controller, a smart speaker, etc.).

[0042] Typically, the bootstrap operation (or process) of any device (e.g., the IoT device 102) requires that the device be able to establish a connection to a bootstrap device, wherein the device and the bootstrap device are connected to each other via a bootstrap network. Currently, each IoT device needs to be manually booted by a user or some other person, which makes booting millions of IoT devices in the next few years very time-consuming, expensive, and unscalable. In addition, the use of a well-known bootstrap network for the bootstrap operation is susceptible to false binding attacks.

[0043] Furthermore, in the case of a zero-touch boot operation, the device and the boot device automatically join the boot network at power-on and establish a boot session with each other. A traditional approach to facilitate zero-touch boot is to create a well-known boot network that the device joins to boot. TM devices create bootstrap networks using well-known SSIDs, or for Bluetooth TM Devices automatically connect using well-known friendly names. However, existing zero-touch boot technology solutions use well-known boot networks and are vulnerable to potential misbinding attacks.

[0044] In view of the above problems, the present invention provides a novel system 100 for zero-touch boot operation of IoT device 102, which prevents incorrect binding vulnerabilities. Specifically, system 100 enables IoT device 102 to connect to the correct boot network and obtain accurate boot without any operation from the user other than powering or starting IoT device 102. Here, system 100 is used to provide a temporary, customized (or device-specific) boot network according to the type of device 102 being booted during operation. This implementation is achieved by providing participating devices with prior knowledge of boot parameters (i.e., network identifiers and credentials) and other boot parameters required to join the boot network. Advantageously, system 100 is anti-error binding and achieves zero-touch boot of IoT device 102 by creating a unique boot parameter set associated with IoT device 102 and shared between IoT device 102 and the boot device. In addition, the system 100 of the present invention utilizes blockchain technology to confidentially and securely transmit unique boot parameters to the owner (i.e., user) of the IoT device, wherein the owner utilizes the generated unique boot parameters to create a device-specific boot network (and uses other parameters) to automatically and without any intervention boot the device, so as to make the system 100 faster and more efficient.

[0045] like Figure 1As shown, the system 100 includes a database 104. The term "database" refers to an organized collection of structured information (or data), that is, usually stored and accessed electronically. For example, databases include relational databases, centralized databases, distributed databases, etc. However, traditional databases are susceptible to security risks, such as but not limited to intrusion or unwanted access by malicious actors, crashes or failures, unwanted changes to data, accidental deletion of data, etc. Therefore, considering the above risks, the database 104 is selected based on the needs of the implementation to efficiently and securely manage the boot operation.

[0046] In one embodiment, database 104 is a centralized database. The term "centralized database" refers to a type of database that is located, stored, and managed in a single location. For example, a central computer (e.g., a CPU or mainframe) or a database system (e.g., MySQL, Oracle, PostgreSQL, dBASE, FoxPro, IBM DB2). Advantageously, such a centralized database 104 provides several advantages over other types of traditional 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, 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 digital data that is replicated, shared, and synchronized across multiple entities (e.g., sites, countries, or institutions) that is geographically distributed (i.e., decentralized). Some examples of distributed ledger databases 104 include blockchain, hashgraph, DAG, Holochain, and Tempo (Radix). Here, system 100 may also utilize cryptographic keys and / or digital signatures to provide authorization for distributed ledgers to improve security and reliability.

[0048] In yet another embodiment, the database 104 is a blockchain. The term "blockchain" refers to a distributed ledger that acts as a decentralized database of information about transactions between parties. Typically, operations populate the blockchain database 104 (also referred to as a blockchain network, or simply a blockchain) in chronological order and are stored as a series of blocks, where an interconnected chain is formed between the series of blocks, and each block references the block before it, thereby creating the blockchain database 104. Here, the database 104 is used to be replicated 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 save an identical copy of at least one of the multiple distributed ledgers and update them independently.

[0049] In blockchain storage, data is first broken down into shards through a process called sharding, where each shard is replicated to prevent data loss in the event of an error during transmission. In addition, the file is encrypted using a private key or a 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, allowing 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 multiple distributed blocks of the blockchain database 104, each node can construct a new transaction based on a consensus algorithm (e.g., proof of work, proof of equity, voting system, hash graph, etc.) regarding the authenticity or correctness of a copy of the distributed ledger. In addition, the blockchain database 104 reduces the associated production costs and also increases the processing speed of the system 100. In addition, optionally, it can provide smart contracts with more inherent advantages.

[0050] In one or more embodiments, the database 104 is a public database, a private database, a consortium database, or a hybrid database. Alternatively, the database is any one 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, database 104 is a public database or blockchain. In such an embodiment, database 104 is accessible to the general public and does not include any restrictions, i.e., anyone (or owner) with a computer and the Internet can participate in the network, wherein public database 104 is fully distributed, i.e., each node in the network holds a copy of other nodes or blocks present in the network for verifying transactions or records. Advantageously, public database 104 provides a trusted, secure storage and distribution medium, i.e., decentralized and anonymous in nature.

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

[0053] In another embodiment, the database 104 is a hybrid database or a consortium database. In such an embodiment, the database 104 is formed by merging components of public and private blockchains, wherein transactions or records in the hybrid blockchain 104 are private but verifiable when required, such as by allowing access through smart contracts. Advantageously, the hybrid database 104 enables the system 100 to establish a private permission-based system alongside a public permissionless system, thereby being able to effectively manage 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. Furthermore, the hybrid blockchain provides greater security to the system because external actors cannot launch a 51% attack on the network due to operating 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 bootstrapping operations through the system 100, a preliminary step of device registration is required, whereby upon 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 IDs, device types, configuration details, manufacturer details, etc., of all IoT devices in the network.

[0056] exist Figure 1 As further shown in FIG. 1 , the system 100 further includes a server 101 in communication with a database 104. The term "server" refers to a structure and / or module including programmable and / or non-programmable components for storing, processing and / or sharing information or data to guide the IoT device 102 from the first owner to the 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 safely and efficiently guide the IoT device 102. Alternatively, the server 101 is responsible for causing the boot operation through the method, and is used to send commands, requests and messages to the connected elements (i.e., the IoT device 102, the first owner device 106, the second owner device 108 and the database 104), wherein each element can perform the actions on its own or according to a request or command from the server 101. It should be understood that the server 101 can be a part of any one of the IoT device 102, the database 104, the first owner device 106, the second owner device 108, or a part of performing the boot operation without any limitation.

[0057] Optionally, server 101 includes a device capable of augmenting information to perform various computing tasks, physical or virtual computing entities. In addition, it will be understood that server 101 can be implemented as a hardware server and / or multiple hardware servers running in parallel or in a distributed architecture. Optionally, the servers in server 101 are supplemented with additional computing systems, such as neural networks, and hierarchical clusters of pseudo-simulated variable state machines that implement artificial intelligence algorithms.

[0058] In one embodiment, the server 101 may include components such as a memory, a processor, a data communication interface, a 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 devices. In addition, the server 101 refers to a computing element that can operate to respond to and process instructions to perform boot operations.

[0059] For example, the server 101 may be a cloud server, an application server, a file server, a database server, or a blockchain server. Optionally, the server 101 includes, 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 circuit, such as described above. In addition, the server 101 is arranged in various architectures for responding to and processing instructions for directing 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 a public key of a first owner from a first owner device 106. The first owner device 106 is configured to provide the public key of the first owner to the server 101. Additionally, the server 101 is configured to receive a public key of a second owner from a 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] As used herein, the term "owner device" refers to a structure and / or module including programmable and / or non-programmable components for storing, processing and / or sharing information and / or signals for managing boot operations and / or associated with an owner or user (e.g., a first owner and a second owner). The owner device 106 or 108 may be a controller having a display, control buttons or joysticks, a processor, a memory, and other elements. In this example, the owner device 106 or 108 may include components such as a memory, a processor, a network adapter, and the like 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 smart phone, a personal digital assistant (PDA), a Wi-Fi access point, a Bluetooth transmitter, a web server or a backend server (operated by the first owner such as a manufacturer, a retailer, and a distributor), etc. It should be understood that the first owner device 106 and the second owner device 108 can be used as a boot device for performing the boot of the IoT device 102 through the system 100.

[0063] In addition, 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, retailer, or manufacturer of the IoT device 102 may be a first owner, while a purchaser or end user of the IoT device 102 may be a second owner.

[0064] In terms of blockchain, the identity of any owner device 106 or 108 is derived from a public key provided by its respective owner. For example, the identity of the first owner device 106 is derived from the first owner's public key. An owner may choose to use a different key pair or public key for each purchase to avoid profiling, where an outside entity can profile a user based on the device purchased, or based on a group of several purchases. However, maintaining the same identity is beneficial for providing value-added services, such as reputation of buyers and sellers. Typically, intermediate owners of devices, i.e., manufacturers, distributors, and retailers, will keep their identities unchanged to allow tracking of counterfeit devices and transactions.

[0065] Therefore, in order to achieve the boot operation, a certain degree of mutual trust needs to be developed between the first owner and the second owner. The first owner and the second owner share a public key through the first owner device 106 and the second owner device 108 respectively to achieve identification of the owner.

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

[0067] The lifecycle (or boot cycle) of any IoT device 102 involves multiple stages after or during which the IoT device 102, unique boot parameters, and ownership are transferred (or changed) from one party to another, i.e., from a first owner to a second owner. For example, the transfer may occur after or during the manufacture, sale, deployment, or utilization of the IoT device 102 (by a user or owner).

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

[0069] In one example, when any IoT device 102 is manufactured, the first owner is the manufacturer of the IoT device 102. The manufacturer triggers an ownership change request for the second owner (i.e., the end user (e.g., person A) of the IoT device 102) through the first owner device 106 through a seller or distributor (e.g., an e-commerce platform or an authorization center) of the server 101. The server 101 is also used 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 an ownership change request for the second owner to the server 101. 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 give away the IoT device 102 to a second owner after using it for a period of time. The first owner provides a change of ownership request to the server 101. The second owner is a second user (e.g., person Y; a friend of person X) who obtains the IoT device 102 from the first owner. When the change of ownership request is triggered from the server 101, the change of ownership request is transferred from the first owner to the second owner. The IoT device 102 is now required to be registered or bootstrapped according to the identity of the second owner or user, and the second owner device 108 provides the second owner's public key for the transaction.

[0072] In one embodiment of the system 100, the IoT device 102 is configured to generate unique boot parameters, the unique boot parameters including at least a boot network identifier and a boot network credential for joining the boot network 110. The term "unique boot parameters" as used herein refers to a set of parameters associated with the IoT device 102 required for boot operations through the system 100. The unique boot parameters include at least the boot network identifier and the boot network credential, as well as other boot information, such as a device identifier, a boot protocol, and a boot credential.

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

[0074] "Boot network credentials" refer to authentication or authorization information required to join a boot network, such as a username, password, or key. Optionally, the boot network credentials can be generated at least in part based on a boot device identifier and / or the boot network identifier, so that an unauthorized user requesting access cannot use the boot network credentials for authentication. It should be noted that the generation of unique boot parameters enables the system 100 to develop a customized boot network 110, i.e., specific to IoT devices 102 that prevent false binding attacks. In addition, public key encryption is used by the boot network 110, or the device identifier can be used to sign the boot network credential or to perform other verification functions.

[0075] The “boot network” 110 refers to a wireless network for connecting the IoT device 102 and the boot device 108 for performing the boot operation by the second owner. The boot 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 networks, or any combination of two or more such networks. In addition, the boot device 108 can be connected to the boot network 110 via a communication channel (e.g., a cellular network, Wi-Fi, NFC, infrared and / or other technologies) to communicate data with the first owner device 106 or the server 101.

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

[0077] The IoT device 102 is further configured to embed the unique boot parameter in the memory 112 of the IoT device 102. Alternatively, the unique boot parameter is embedded or stored in the memory 112 of the IoT device 102. After generating the unique boot parameter, the IoT device 102 is configured to embed or store the unique boot parameter in the memory 112 of the IoT device 102, so that the second owner device 108 can further retrieve or extract the boot parameter from the memory 112 of the IoT device.

[0078] In addition, in addition to the unique boot parameter, the blockchain transaction also contains ownership transaction details, such as seller information, manufacturer information, distributor information, or user information. Therefore, each blockchain transaction includes at least ownership transaction information in the form of an ownership change request, the encrypted boot parameter, and a previous block ID storing the 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 non-transient computer-readable media, such as computer storage media. Computer-readable media include at least two types of computer-readable media, namely computer storage media and communication media. In addition, computer storage media include volatile and non-volatile, removable and non-removable media implemented in any system or technology for storing information, such as computer-readable instructions, data structures, program modules or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (digital versatile disk, DVD) or other optical storage, cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store access by a computing device. In contrast, communication media can contain computer-readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier wave or other transmission mechanism.

[0080] In one embodiment, the bootstrap network 110 is generated by the second owner device 108 by utilizing the decrypted unique bootstrap parameters 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 utilize the decrypted unique bootstrap parameters to provide the bootstrap network 110. When 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 parameters in the memory 112, receive the operating parameters of the second owner's operating network 114 from the second owner device 108, and connect to the second owner's operating network 114 using the received operating parameters to operate in an operational mode.

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

[0082] The term "non-operational mode" refers to a state of the IoT device 102, wherein the IoT is ready to be bootstrapped 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 false binding attacks.

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

[0084] Additionally, the term “operating network” as used herein refers to a dedicated network operated by the second owner via the second owner device 108. In one example, the operating network 114 is a home-based Wi-Fi network of an end user. TM In another example, the operating network 114 is a large network of interconnected second owner devices 108, where the second owner may be a manufacturer or a large corporation.

[0085] Specifically, in the non-operational mode, the server 101 enables the IoT device 102 to connect to the provided boot network 110 by using unique boot parameters. In addition, such connection to the boot network enables the IoT device 110 to receive the operating parameters of the operating network 114 associated with the second owner, enabling the IoT device to operate and communicate within the operating network 114. Advantageously, the server 101 enables the IoT device 102 to connect only to a specific network, namely the boot network 110, wherein once booted, the IoT device 102 can be restored to the non-operational mode by resetting the IoT device 102 or sending another ownership change request.

[0086] In another embodiment, when the IoT device 102 is in the operation mode, upon receiving an ownership change request of the IoT device 102, the IoT device 102 is configured to generate replacement unique boot parameters for the IoT device 102. The replacement unique boot parameters may include at least a replacement boot network identifier and a replacement boot network credential for joining the replacement boot network 110A and embedding the generated replacement unique boot parameters into the memory 112 of the IoT device 102. Replacement unique boot parameters are generated because the existing unique boot parameters generated by the manufacturer or retailer (i.e., the old first owner) will not be usable. The unique boot parameters are associated with the boot network 110 of the current first owner, and therefore, a new or replacement unique boot parameter is required for the boot operation of connecting to the replacement boot network 110A.

[0087] It should be understood that the alternative boot network 110A and the associated alternative unique boot parameters are similar in structure and operation to the unique boot parameters and boot network 110. The term "operational mode" as used herein refers to the state of the IoT device 102 after a successful boot 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 configured during the boot operation. Generally, in the event that an ownership change request for 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 boot parameter is vulnerable to external malicious attacks, and therefore needs to be securely transmitted to the database 104 through the server 101 or the first owner device 106. Therefore, in order to securely provide the unique boot parameter, the server 101 is also used to: encrypt the generated unique boot parameter using the public key of the second owner according to the receipt of the ownership change request, and send the encrypted unique boot parameter 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 boot parameter. Alternatively, the server 101 can be used to enable the first owner device 106 to create a blockchain transaction, and thereby encrypt the unique boot parameter for further transmission to the database 104.

[0089] After generating the generated unique boot parameters, the server 101 encrypts the unique boot parameters using the public key of the second owner. It should be noted that the boot parameters are generated within the IoT device 102 and thereby leave the IoT device 102 in encrypted form, wherein the encryption is done using the public key of the second owner (i.e., the receiver). It should be noted that in the case of a transfer of ownership without actual interaction with the IoT device 102, such as from the manufacturer to the first user through distributors and retailers, the unique boot parameters are encrypted by the first owner (i.e., the manufacturer) rather than being encrypted on the IoT device itself using the public key of the second owner. To do this, the first owner needs access to a unique set of boot parameters that have not yet been used to boot the IoT device 102.

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

[0091] It should be noted that the public key of the second owner is included as part of the owner change request to enable secure transmission of unique boot parameters, i.e., to enable encryption of the boot information before transmission through the server 101. Such public key encryption is essential for determining the decryption key, i.e., it is not feasible to perform decryption only with the knowledge of the cryptographic algorithm and the encryption key, wherein either the public key or the private key of the second owner may be used for encryption, while the other key is used for decryption.

[0092] Advantageously, due to public key cryptography, 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 with the private key can decrypt the boot parameters and create the digital signature required for authorization.

[0093] In one or more embodiments, the server 101 is configured to cause the first owner device 106 to embed a trust anchor in the memory 112 of the IoT device 102 during manufacturing 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 102. Typically, since the IoT device 102 is a small entity, i.e., has a small footprint, it is not feasible for the IoT device 102 to verify the entire blockchain 104. Therefore, an entity or mechanism is needed to verify all blocks in the blockchain 104 on behalf of the IoT device 102.

[0094] This verification on behalf of the IoT device 102 is done by a trusted node in the server 101 (i.e., a node that the IoT device trusts), where the 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, namely 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 the server 101. The embedded trust anchors act as a verification authority and enable the IoT device 102 to verify the signature key of the manufacturer and / or the IoT device 102, 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 the server 101.

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

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

[0097] The encrypted unique boot parameter received from server 101 is stored in block 104A of database 104, where block 104A includes a block ID. In addition, database 104 is used to store other information related to the boot information in block 104A, including but not limited to ownership transfer information, a previously related block ID containing information about the transfer of ownership to the second owner, additional boot 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 the IoT device 102 is being transferred from the first owner (i.e., the manufacturer) to the second owner (i.e., the distributor). Here, the first owner creates a blockchain transaction in which the first owner states that the IoT device 102 was 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 the IoT device 102.

[0099] Furthermore, each block in the blockchain 104 may contain multiple blockchain transactions, where each transaction is for one event, such as the transfer of the exemplary IoT device 102 from one user to another, i.e., from a first owner to a second owner. An owner or user simply creates a blockchain transaction and thereby requests the blockchain server 101 to include the transaction in a block of the blockchain 104, where the nodes in the blockchain 104 compete with each other to add a block that contains the blockchain transaction and becomes effective upon successful generation.

[0100] The term "block ID" refers to a primary identifier of a block (e.g., block 104A) that is 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 generate a 32-byte hash (i.e., block hash or block ID). The block ID enables other connected nodes (e.g., the second owner device 108) to identify the block 104A associated with the unique boot parameters and enable extraction. In addition, when an ownership change request is received from the first owner device 106, the database 104 is used to transmit the block ID to the second owner device 108, so that the second owner device 108 can further extract the encrypted unique boot parameters from the database 104 via the block ID.

[0101] The server 101 is further configured to enable the second owner device 108 to extract the encrypted unique boot parameter according to the transmitted block ID, and to decrypt the unique boot parameter using the private key of the second owner. Typically, when the second owner device 108 receives the block ID of the block 104A containing the encrypted unique boot parameter, the server 101 is configured to enable the second owner device 108 to extract the encrypted unique boot parameter according to the transmitted block ID, and to decrypt the unique boot parameter through the second owner device 108 using the private key of the second owner.

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

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

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

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

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

[0107] In step 208, the method 200 further includes encrypting the unique boot parameters using the public key of the second owner. After the unique boot parameters are embedded in the memory 112 of the IoT device 102, the method 200 is further configured to encrypt the unique boot parameters using the public key of the second owner received with the ownership change request. Such public key encryption is to prevent unauthorized access to the unique boot parameters transmitted during operation and to allow confidential transmission of the parameters by the method 200.

[0108] Optionally, the method 200 further includes: the first owner of the IoT device 102 signs the encrypted unique boot parameter using a signature key to generate a signed message; and stores the signed message together with the encrypted unique boot parameter in block 104A of the database 104. Typically, in order to provide enhanced security and reliability to the method 200, the first owner (or manufacturer) is used to generate the signed message using a signature key, i.e., a private signature key. This enables the second owner to verify the initiation of the ownership change request.

[0109] When generating the signed message, the method 200 further includes storing the signed message along with the unique boot parameter and the ownership change request in the block 104A of the database. The second owner device 108 may further extract the signed message along with the unique boot parameter during a boot operation.

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

[0111] Optionally, the method 200 further includes: the boot device 108 of the second owner verifies the signed message; the boot device 108 of the second owner decrypts the encrypted unique boot parameter in response to the verification of the signed message. After the signed message is stored together with the unique boot parameter, the method 200 is used to verify the signed message by the boot device 108 to prevent the external party from wrongly binding and any unauthorized access to it, that is, the boot device 108 is used to extract and verify the signed message from the blockchain transaction, thereby extracting the unique boot parameter.

[0112] In addition, after successfully verifying the signed message, the boot device 108 decrypts the encrypted unique boot parameter as a response to the successful verification. It should be noted that the second owner device 108 is used to act as a boot device for the boot operation through the method 200. Those skilled in the art will understand that the additional second owner boot device can also be used exclusively for the boot operation without any limitation.

[0113] In one or more embodiments, the method 200 further includes embedding the trust anchor into the memory 112 of the IoT device 102 during manufacturing. This may allow 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, since the IoT device 102 is a small entity, i.e., has a small footprint, it is not feasible for the IoT device 102 to verify the entire blockchain 104, and therefore, an entity or mechanism is required 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, namely 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 the server 101. This verification on behalf of the IoT device 102 is done by a trusted node in the server 101 (i.e., a trusted node of the IoT device). The IoT device 102 can ask the trust anchor to verify the certificate signed by the trusted node. The embedded trust anchor acts as a verification authority and enables the IoT device 102 to verify the signing key of the manufacturer and / or the IoT device 102, 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 the server 101.

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

[0116] In step 212, the method 200 further includes transmitting the block ID to the second owner. In order to enable the second owner device 108 to access the boot information from the block 104A of the database 104, the method 200 is used to transmit the block ID so that the second owner can accurately identify the relevant block 104A from the database 104 containing the required boot information, and also enable the IoT device 102 to verify the blockchain transaction.

[0117] In step 214, the method 200 further includes: the boot device 108 of the second owner extracting the encrypted unique boot parameter according to the transmitted block ID. When the block ID is received from the database 104, the method 200 is also used to extract the encrypted unique boot parameter according to the transmitted block ID by the boot device 108 of the second owner. Here, the boot device 108 is used to extract the unique boot parameter according to the block ID, so that the encrypted unique boot parameter is further processed to enable the boot operation. It should be understood that in some cases, the boot device 108 may be different from the second owner device 108, without any limitation on the aspects of the disclosed embodiments.

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

[0119] Optionally, the method 200 further includes: providing a boot network 110 using the unique boot parameter 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 using the embedded unique boot parameter in the memory 112 to receive the operating parameters of the operating network 114 of the second owner 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 blockchain account information of the second owner and can obtain the relevant block 104A from the database 104, and due to this, the boot device 108 can be operated as a Wi-Fi access point (AP), for example.

[0120] The boot device 108 extracts the public encryption key of the IoT device 102 from the blockchain transaction. In addition, the boot device 108 is used to act as a Wi-Fi AP to create a boot network 110 with a given boot network identifier information from the unique boot parameters.

[0121] In addition, the bootstrap device 108 can be used to periodically create the bootstrap network 110 and wait for the IoT device 102 to join or start the process only after receiving an instruction (e.g., a voice activation command) from the second owner or user. Therefore, when the IoT device 102 is powered, the IoT device 102 is used to scan for available networks (e.g., Wi-Fi APs) and thus only join the bootstrap network 110 created using unique bootstrap parameters to prevent incorrect binding.

[0122] Optionally, the method 200 further includes: the IoT device 102 sends a request for proving the block IDs of one or more blocks 104A to 104D in the database 104 storing the ownership change request to the boot device 108 of the second owner through the boot network 110, and the boot device 110 of the second owner sends the certification request to the database 104. Alternatively, the IoT device 102 is used to send the certification request to the boot device 108 of the second owner through the boot network 110, wherein the boot device 108 is used to further transmit the certification request to the database 104.

[0123] Typically, during the boot operation, the device associated with the user or the second owner is vulnerable to malicious attacks. The boot parameters (i.e., network identifiers and credentials) have multiple entities (such as manufacturers, distributors, and sellers) and are vulnerable to hacker attacks from malicious entities. A malicious attacker can obtain the boot parameters from the manufacturer or distributor from some vulnerability exploits and manipulate the boot network to boot the IoT device 102. At this time, the IoT device 102 needs to ensure that other entities interacting with the IoT device 102 are authorized, and therefore, the identity of the first owner needs to be verified, that is, whether the first owner is authorized.

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

[0125] To enable transmission of the attestation request, the method 200 is used to generate a boot initiation message to the IoT device 102 by the boot device 108 to initiate the boot operation. In addition, in confirmation, the IoT device 102 transmits an attestation request for the relevant block 104A from the blockchain database 104. Here, the relevant block 104A includes all blocks that include ownership transactions related to the IoT device and is not limited to a single block or transaction. However, it will be understood that the IoT device 102 may or may not request attestation evidence from a trusted node.

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

[0127] In another embodiment, the method 200 further includes: the database 104 generates, in response to receiving the proof request, a proof evidence including information about one or more blocks 104A in the database 104 storing the ownership change request. Typically, the proof evidence is generated by the database 104 by verifying one or more relevant blocks 104A to 104D, that is, the 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 some point, the blockchain network generates the 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 the previous owner. Alternatively, the server 101 or a trusted node in the server 101 is used to create the proof evidence, i.e., a signed message containing information about all relevant blocks 104A to 104D or a signed statement ensuring that the second owner is the legal owner of the IoT device 102 device, and the block ID is associated with the latest block containing the ownership transfer information of the second owner. It should be noted that the proof evidence is signed using the proof key of the blockchain server 101 or the trusted node.

[0129] In addition, the proof evidence also includes a challenge from the IoT device 102 to prevent replay attacks. The "challenge" refers to a random value to be signed using the private signature key of the IoT device 102, which is used to indicate that the signed challenge is actually sent by the IoT device 102. The boot device 108 is used to sign the first challenge and send a proof request for the relevant blocks 104A to 104D to the blockchain database 104. Accordingly, the second owner signs the challenge to associate himself with the challenge.

[0130] Further optionally, the method 200 includes: the boot device 108 of the second owner receives the proof evidence from the database 104, and the boot device of the second owner sends the proof evidence to the IoT device through the boot network. After generating the proof evidence, the blockchain server 101 is used to send the proof evidence to the IoT device 102 through the boot device 108 for verification.

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

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

[0133] In addition, optionally, the method 200 further includes: verifying the ownership change request according to information about the latest block in the one or more blocks 104A in the database 104 storing the ownership change request, and establishing a secure connection with the boot device 108 of the second owner in response to the verification of the ownership change request. Typically, the IoT device 102 and the boot device 108 involve a key exchange protocol to complete the secure boot through the method 200.

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

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

[0136] Optionally, the method 200 further includes the IoT device 102 connecting to the operating network 114 of the second owner using the received operating parameters to operate in the operating mode. Therefore, once booted, the IoT device 102 can connect to the network environment of the second owner, that is, the operating network 114.

[0137] Optionally, in the case where the ownership change request is received and the IoT device 102 is already in the operation mode, the method 200 further includes generating a replacement unique boot parameter for the IoT device 102. The replacement unique boot parameter includes at least an alternative boot network identifier and an alternative boot network credential for joining the alternative boot network 110A. The generated replacement unique boot parameter is embedded in the memory 112 of the IoT device 102.

[0138] See also Figure 3 , shows an exemplary process flow chart 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 in the figure, 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 change request for the IoT device 102 through the first owner device 106.

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

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

[0141] Furthermore, during the boot process, the IoT device 102 and the boot device 108 authenticate each other using information in the blockchain 104, and upon completion, a new customized boot network 110 is generated for the next boot operation. Advantageously, the boot network 110 is unique to each IoT device 102 and can only be used once for a boot operation. The IoT device 102 is configured to automatically connect to a specific boot network 110 to reduce or prevent incorrect binding.

[0142] refer to Figure 4, a flowchart of a message flow sequence 400 of a process 400 for transmitting unique boot parameters from a first owner to a second owner provided by one or more embodiments of the present invention is shown. A process of transmitting unique boot parameters generated by an IoT device 102 to a second owner (or consumer) is described. Typically, ownership of an IoT device 102 passes through a manufacturer, a distributor, a retail seller, and ultimately reaches a 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 only owner who actually boots the IoT device 102 to enable utilization. Each entity signs and encrypts messages using a separate key pair (public key and private key).

[0143] As shown, in step 4.1, the first owner (ie, the manufacturer) is used to generate an ownership change request and transmit it to the 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, the IoT device 102 is used to verify the public key of the first owner through the embedded trust anchor. In step 4.2.2, in response to the ownership change request, the IoT device 102 is used to generate unique boot parameters (D1_S0), which include at least the required boot network identifier and credentials to join the boot network 110, and other boot information, such as device identifier, boot protocol, and boot credentials. In step 4.2.3, the IoT device 102 is used to encrypt the unique boot parameters for the manufacturer using the public key (PKe_M1) of the second owner, wherein the second owner is the same manufacturer from which the IoT device ownership is obtained. In addition, the IoT device 102 then generates a signed message C1 using the signing key (SKs_D1) of the IoT device 102, wherein the signed message is generated according to C1=∑{Enc(PKe_M1,D1_S0)}SKs_D1.

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

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

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

[0148] In sub-step 4.6.1 of step 4.6, the first owner (M1) requests the blockchain server 101 to include the blockchain (T_a) into block 104A of the blockchain database 104, wherein the blockchain database 104 adds the transaction into the new first block 104A (B_i). In addition, in sub-step 4.5.2, once the new block 104A is established within the blockchain 104, the second owner or distributor (dist1) obtains the relevant block 104A when requesting the relevant blockchain transaction details (T_a) from the 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 sub-step 4.8.1 of step 4.8, in response to the ownership change 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 boot parameter using its decryption key. In sub-step 4.8.2, the first owner (Dist1) is used to encrypt the unique boot parameter using the public key (PKe_R1) of the second owner, and thereby creates another signed message (C3) using its signature key (SKs_dist1), where C3 = ∑{Enc(PKe_R1, D1_S0)}SKs_dist1. In sub-step 4.8.3, the first owner is used to create a second blockchain transaction (T_b) indicating that the ownership of the 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 sub-step 4.9.1 of step 4.9, the first owner requests the blockchain server 101 to include the second blockchain transaction in block 104B in the blockchain 104. The database 104 adds the transaction to the second block 104B (B_j). In sub-step 4.9.2, once the second block 104B is established in the blockchain 104, the second owner (R1) can obtain or extract the second block 104 and thereby obtain the second blockchain transaction details therefrom.

[0152] In step 4.10, the second owner (R1) is configured to receive a third ownership change request from the second owner (user U1). The third ownership change request includes the public key (PKe_U1) of the second owner.

[0153] In sub-step 4.11.1 of step 4.11, the first owner (R1) is used to extract the third signature message (C3) from the second blockchain transaction (T_b), verify the third signature message, and extract the unique boot parameter using its decryption key. In sub-step 4.11.2, the first owner is used to encrypt the unique boot parameter using the public key of the second owner (i.e., user U1), and create 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 the 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 the blockchain 104. The blockchain server 101 adds the transaction into the block 104C. In sub-step 4.12.2, once the third block 104C (B_k) is established within the blockchain 104, the second owner (U1) can obtain the third block 104C from the blockchain 104, thereby obtaining the third blockchain transaction (T_c). In sub-step 4.12.3, the second owner (U1) is used to extract the fourth signature message (C4) from the third blockchain transaction, verify the fourth blockchain transaction, and use its decryption key to extract the unique boot parameter, i.e., use it to boot the physical IoT device 102 after receiving it from the first owner (R1).

[0155] refer to Figure 5, a flowchart showing a message flow sequence of a process 500 for transmitting a unique boot parameter from a first owner to another second owner provided by another embodiment of the present invention. Here, the message flow sequence 500 of the process for transmitting a unique boot parameter (D1_S1) generated by the IoT device 102 includes transmission from the first owner (ie, user U1) to another second user (ie, 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) is used to receive an ownership change request (or purchase request) from the second owner (user U2). The ownership change request includes at least the public key (PKe_U2) of the second owner.

[0157] In step 5.2, the first owner (U1) is used to create an ownership change request for the IoT device 102. The ownership change request includes a signed message, and the signed message includes the encrypted public key (PKe_U2) of the second owner, wherein the signed message is, for example, ∑{ownership change, PKe_U2}SKs_U1.

[0158] In sub-step 5.3.1 of step 5.3, the IoT device 102 is used to verify the ownership change request using the boot information from the third block 104C. The IoT device 102 stores the third block 104C during booting, as further explained herein. In sub-step 5.3.2, after verification by the IoT device 102, the IoT device 102 is used to generate new unique boot parameters (D1_S1), which include a new network identifier and credentials for joining the boot network 110, as well as other boot information such as a device identifier and boot credentials. In sub-step 5.3.3, the IoT device 102 is used to encrypt the generated new boot parameters (or alternative boot parameters) using the public key of the second owner, and generate a fifth signed message (C5) using the private signature key (SKs_D1). The generated fifth signed message is C5=∑{Enc(PKe_U2,D1_S1)}SKs_D1.

[0159] In step 5.4, the IoT device 102 is used to transmit the fifth signed 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 is used to verify the fifth signature message and generate a sixth signature message (C6) using the private signature key (SKs_U1) of the first owner. The sixth signature message is C6 = ∑{C5}SKs_U1. In sub-step 5.5.2, the first owner is used to generate a fourth blockchain transaction (T_d) indicating that the ownership of the IoT device is transferred from the first owner (U1) to the second owner (U2), and the sixth signature message is included in the blockchain transaction details.

[0161] In sub-step 5.6.1 of step 5.6, the first owner is used to request the blockchain server 101 to include the fourth transaction details (T_d) into the fourth block 104D (B_1) in the blockchain 104. The 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 the blockchain 104, the second owner (U2) is able to obtain the fourth block 104D from the blockchain 104. In sub-step 5.6.3, the second owner (U2) is used to extract the sixth signature message from the fourth blockchain transaction (T_d) and verify the sixth signature message. At the same time, the second owner is used to extract and verify the fifth signature message (C5) before using its decryption key to extract the unique boot parameter (D1_S1). 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 boot the IoT device.

[0162] refer to Figure 6 , a flowchart of steps involved in a message flow sequence describing a boot process 600 of an IoT device 102 via a system 100 or a method 200 according to one or more embodiments of the present invention is shown. Here, a message flow sequence for the boot process 600, in which a first owner (U1) boots the IoT device 102 using its boot device 108. It is assumed that the boot device 108 has access to the user's blockchain account information and can obtain the relevant blocks 104A to 104D, and because of this, the boot device 108 can operate as a Wi-Fi access point (AP).

[0163] In sub-step 6.1.1 of step 6.1, the boot device 108 extracts the public key (PKs_D1) of the IoT device 102 from the third blockchain transaction (T_c). In sub-step 6.1.2, the boot device 108 is used to extract and verify the fourth signature message (C4) from the third blockchain transaction (T_c), and decrypt and extract the unique boot parameter (D1_S0) using its encrypted private key.

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

[0165] In step 6.2, when the IoT device 102 is powered, the IoT device 102 is used to scan for available Wi-Fi APs. The IoT device 102 can only join the bootstrap network 110 that has been created using the unique bootstrap parameter (D1_S0).

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

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

[0168] In step 6.5, the boot device 108 is used to sign the first challenge and send a certification request (or certification request) for the relevant blocks 104A to 104D to the blockchain server 101 upon receiving the first signed challenge containing the certification request message. For example, the relevant blocks 104A to 104C used for this boot 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 certification from a trusted node, the boot device 108 is used to send the certification request to a specific node or a group of trusted nodes indicated by the IoT device 102.

[0169] In step 6.6, the trusted node in the blockchain server 101 is used to generate proof evidence by verifying all relevant blocks 104A to 104C in response to receiving the proof request. The proof evidence includes a statement indicating that all relevant blocks have been verified, and the block 104C is the latest block containing information about the latest owner of the IoT device. For example, by signing the first challenge using the proof key (AttKey), the trusted node in the blockchain server 101 calculates a hash value including relevant blocks 104A, 104B, and 104C, and generates a statement as proof evidence, the proof evidence including information about one or more blocks 104A to 104C in the database 104 storing the ownership change request. 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 boot device 108 is used to receive the attestation evidence (AttEvidence) from the blockchain server 101. In sub-step 6.7.2, the boot device 108 is used to provide the attestation evidence to the IoT device 102 for verification.

[0171] In sub-step 6.8.1 of step 6.8, the IoT device 102 is used to verify the attestation evidence (AttEvidence). It is assumed that the IoT device 102 is able to establish a trust relationship through an attestation key (AttKey) for verifying the attestation evidence. The verification of the attestation evidence confirms to the IoT device 102 that the first owner (U1) is the latest owner. In addition, in sub-step 6.8.2, the IoT device 102 is used to store a copy of the latest relevant block (B_k), i.e., the third block 104C. In addition, in sub-step 6.8.3, the IoT device 102 is used to extract the first owner's public key (PKs_U1) from the third block 104C, which will be used to establish secure communication with the boot device 108 and establish the first owner (U1) as the latest owner.

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

[0173] In sub-step 6.9.2, optionally, once the IoT device 102 is booted, new boot parameters must be created for future boot operations with the next second owner (or user). However, 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 Attestation Evidence using a new challenge from the IoT device 102 to prove the ownership status of the first owner.

[0174] refer to Figure 7 , a flowchart showing a message flow sequence of a zero-touch boot process 700 through Wi-Fi technology provided by one or more embodiments of the present invention, wherein the IoT device 102 is used to generate a boot network 110. In the 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 an access point (AP) of the boot network 110 instead of the boot device 108.

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

[0176] In sub-step 7.2.1, the boot 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 boot device 108 is used to extract and verify the fourth signature message (C4) from the third blockchain transaction (T_c), and extract the unique boot parameter (D1_S0). In addition, in sub-step 7.2.3, the boot device 108 is used to join the boot network 110.

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

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

[0179] In step 7.5, the boot device 108 is used to sign the first challenge and send a certification request (or certification request) for the relevant blocks 104A to 104D to the blockchain server 101 upon receiving the first signed challenge containing the certification request message. For example, the relevant blocks 104A to 104C used for this boot 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 certification from a trusted node, the boot device 108 is used to send the certification request to a specific node or a group of trusted nodes indicated by the IoT device 102.

[0180] In step 7.6, the trusted node in the blockchain server 101 is used to generate proof evidence by verifying all relevant blocks 104A to 104C in response to receiving the proof request. The proof evidence includes a statement indicating that all relevant blocks have been verified, and the block 104C is the latest block containing information about the latest owner of the IoT device. For example, by signing the first challenge using the proof key (AttKey), the trusted node in the blockchain server 101 calculates a hash value including relevant blocks 104A, 104B, and 104C, and generates a statement as proof evidence, the proof evidence including information about one or more blocks 104A to 104C in the database 104 storing the ownership change request. 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 boot device 108 is used to receive the attestation evidence (AttEvidence) from the blockchain server 101. In sub-step 7.7.2, the boot device 108 is used to provide the attestation evidence to the IoT device 102 for verification.

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

[0183] In sub-step 7.9.1 of step 7.9, the IoT device 102 and the boot device 108 are used to run a key exchange protocol by exchanging public keys associated with the IoT device 102 (PKs_D1) and the first owner device (PKs_U1) to establish a secure channel. The IoT device 102 and the boot device 108 use the boot information indicated in the unique boot parameter (D1_S0) to select the key exchange protocol and to securely complete the boot operation. In sub-step 7.9.2, optionally, once the IoT device 102 is booted, new boot parameters must be created for future boot 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 the ownership of the IoT device 102 remains unchanged. Therefore, during each reboot operation with the first owner (U1), the user must provide attestation evidence (AttEvidence) using a new challenge from the IoT device 102 to prove the ownership status of the first owner.

[0184] refer to Figure 8 , a flowchart showing a message flow sequence of a zero-touch boot process 800 provided by one or more embodiments of the present invention is shown, wherein the IoT device 102 is used to generate a boot network 110 through Bluetooth technology. In the 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 an access point (AP) of the boot network 110 instead of the boot device 108.

[0185] The creation of the bootstrap network 110 is performed using a Bluetooth connection instead of Wi-Fi. The bootstrap parameters (D1_S0) are designed to include Bluetooth connection parameters, such as but not limited to Bluetooth friendly name, credentials, and GAP profile, which the IoT device 102 and / or the bootstrap device 108 use 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 instead of in the Wi-Fi bootstrap network, e.g. Figure 7 The Wi-Fi boot network is shown.

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

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

[0188] In sub-step 8.2.1 of step 8.2, the boot device 108 extracts the public key (PKs_D1) of the IoT device 102 from the third blockchain transaction (T_c). In addition, in sub-step 8.2.2, the boot device 108 is used to extract and verify the fourth signature message (C4) from the third blockchain transaction (T_c), and extract the unique boot parameter (D1_S0). In sub-step 8.2.3, the boot device 108 is used to join the boot network 110.

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

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

[0191] In step 8.5, the boot device 108 is used to sign the first challenge and send a certification request (or certification request) for the relevant blocks 104A to 104D to the blockchain server 101 upon receiving the first signed challenge containing the certification request message. For example, the relevant blocks 104A to 104C used for this boot 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 certification from a trusted node, the boot device 108 is used to send the certification request to a specific node or a group of trusted nodes indicated by the IoT device 102.

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

[0193] In sub-step 8.7.1 of step 8.7, the boot device 108 is used to receive the attestation evidence (AttEvidence) from the blockchain server 101. In sub-step 8.7.2, the boot device 108 is used to provide the attestation evidence to the IoT device 102 for verification.

[0194] In sub-step 8.8.1 of step 8.8, the IoT device 102 is used to verify the attestation evidence (AttEvidence). It is assumed that the IoT device 102 is able to establish a trust relationship through an attestation key (AttKey) for verifying the attestation evidence. The verification of the attestation evidence confirms to the IoT device 102 that the first owner (U1) is the latest owner. In sub-step 8.8.2, the IoT device 102 is used to store a copy of the latest relevant block (B_k), i.e., the third block 104C. In sub-step 8.8.3, the IoT device 102 is used to extract the first owner's public key (PKs_U1) from the third block 104C, which will be used to establish secure communication with the boot device 108 and establish the first owner (U1) as the latest owner.

[0195] In sub-step 8.9.1 of step 8.9, the IoT device 102 and the boot device 108 are used to run a key exchange protocol by exchanging public keys associated with the IoT device 102 (PKs_D1) and the first owner device (PKs_U1) to establish a secure channel. The IoT device 102 and the boot device 108 use the boot information indicated in the unique boot parameter (D1_S0) to select the key exchange protocol and to securely complete the boot operation. In sub-step 8.9.2, optionally, once the 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 parameter (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 attestation evidence (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, the computer-readable storage medium including instructions, when the instructions are executed by a computer, the computer performs the steps of the method 200 for managing the booting of an Internet of Things (IoT) device 102. Implementation examples of the non-transient computer-readable storage medium include, but are not limited to, an electrically erasable programmable read-only memory (EEPROM), a random access memory (RAM), a read-only memory (ROM), a hard disk drive (HDD), a flash memory, a secure digital (SD) card, a solid-state drive (SSD), a computer-readable storage medium, and / or a CPU cache. A computer-readable storage medium for providing a non-transient memory may include, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof.

[0198] Therefore, although the basic novel features of the present invention as applied to exemplary embodiments of the present invention have been shown, described and pointed out herein, it should be understood that various omissions, substitutions and changes may be made to the form and details of the illustrated apparatus and methods and the set operations by those skilled in the art without departing from the spirit and scope of the present invention. In addition, it is expressly intended that all combinations of those elements that perform substantially the same functions in substantially the same manner to achieve the same results are within the scope of the present invention. In addition, it should be recognized that the structures and / or elements shown and / or described in conjunction with any form or embodiment of the present invention disclosed may be incorporated into any other form or embodiment disclosed or described or suggested as a general term of design choice. Therefore, it is intended to be limited only as indicated by the scope of the appended claims.

Claims

1. A system (100) for managing the booting of an Internet of Things (IoT) device (102) transferred from a first owner to a second owner, characterized in that The system comprises: Database (104); A server (101) in communication with the database (104), wherein the server (101) is configured to: receiving a first owner's public key from a first owner device (106) associated with the first owner; receiving a public key of the second owner from a second owner device (108) associated with the second owner, The IoT device (102) is used for: generating unique bootstrap parameters, the unique bootstrap parameters comprising at least a bootstrap network identifier and a bootstrap network credential for joining a bootstrap network (110); Embedding the unique boot parameter into a memory (112) of the IoT device; Wherein, the server is used for: providing, to the database, a request for changing ownership of the IoT device from the first owner to the second owner, the request for changing ownership including at least the public key of the second owner; encrypting the generated unique boot parameter using the public key of the second owner in response to receiving the ownership change request; sending the encrypted unique boot parameter to the database; Wherein, the database is used for: storing the encrypted unique boot parameter in a block (104A), the block (104A) having a block ID; In response to the ownership change request, transmitting the block ID to the second owner device; The server is further configured to enable the second owner device to perform the following operations: extracting the encrypted unique boot parameter according to 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 further configured to cause the first owner device (106) to embed a trust anchor into the memory (112) of the IoT device (102) during manufacturing 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: causing the second owner device (108) to provide a boot network (110) using the decrypted unique boot parameter; enabling the IoT device (102) in non-operational mode to connect to the provided boot network (110) by utilizing the embedded unique boot parameters in the memory (112) to receive the operating parameters of the operating network (114) of the second owner from the second owner device (108); The IoT device (102) is caused to connect to the operating network (114) of the second owner using the received operating parameters to operate in an operating mode.

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

5. The system (100) according to any one of the preceding claims, 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 booting of an Internet of Things (IoT) device, characterized in that: The method (200) comprises: receiving (202) an ownership change request of the IoT device from a first owner to a second owner, the ownership change request including at least a public key of the second owner; In response to receiving the ownership change request, generating (204) unique bootstrap parameters for the IoT device, the unique bootstrap parameters comprising at least a bootstrap network identifier and a bootstrap network credential for joining a bootstrap network; embedding (206) the unique boot parameter into a memory of the IoT device; encrypting the unique boot parameter using the public key of the second owner (208); storing (210) the encrypted unique boot parameter and the ownership change request in a block of a database, the block having a block ID; transmitting (212) the block ID to the second owner; The second owner's boot device extracts (214) the encrypted unique boot parameter based on the transmitted block ID; The boot device of the second owner decrypts the encrypted unique boot parameters using the second owner's private key (216).

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

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

10. The method (200) according to any one of claims 7 to 9, characterized in that: Also includes: A trust anchor is embedded in the memory of the IoT device during manufacturing to allow the IoT device to verify a manufacturer's signing 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 10, characterized in that: Also includes: the boot device of the second owner providing a boot network using the decrypted unique boot parameters; The IoT device in the non-operational mode is operated to connect to a boot network provided by the boot device of the second owner by utilizing the embedded unique boot parameters in the memory to receive the operation parameters of the operation network of the second owner from the boot device.

12. The method (200) according to claim 11, characterized in that: Also includes: The boot device of the second owner sends a certification request for block IDs of one or more blocks in the database storing the ownership change request to the IoT device through the boot network; the boot device of the second owner sending the certification request to the database; The database generates, in response to receiving the attestation request, an attestation proof including information about one or more blocks in the database storing the ownership change request; the boot device of the second owner receiving the attestation evidence from the database; The boot device of the second owner sends the attestation evidence to the IoT device through the boot network.

13. The method (200) according to claim 12, characterized in that: The method further comprises: Verifying the evidence; In response to verifying the attestation evidence, extracting information about a latest block of the one or more blocks in the database storing the ownership change request; verifying the ownership change request based on the information about the latest block of the one or more blocks in the database storing the ownership change request; In response to verifying 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 13, characterized in that Also included is the IoT device connecting to the operating network of the second owner using the received operating parameters to operate in an operating mode.

15. The method (200) according to claim 14, characterized in that: In case the ownership change request of the IoT device that is already in the operation mode is received, the method further includes: generating an alternative unique boot parameter for the IoT device, the alternative unique boot parameter comprising 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 15, 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 16, characterized in that The database is one of a public database, a private database, a federated database or a hybrid database.

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

Images