WO2019033116A1

WO2019033116A1 - Systems and methods for rights control of network-connected or iot devices using information stored in a distributed ledger

Info

Publication number: WO2019033116A1
Application number: PCT/US2018/046547
Authority: WO
Inventors: Niels J. Thorwirth; Ingo Barth; Carsten FINIS; Attila PEKTER; Elias PARDO; Brad Ree
Original assignee: Verimatrix, Inc.; Verimatrix, Gmbh
Priority date: 2017-08-11
Filing date: 2018-08-13
Publication date: 2019-02-14

Abstract

Systems and methods for access rights control of network-connected devices using information from a distributed ledger are disclosed in one embodiment, an access controller device containing an access control manager application for causing the processor to perform: receiving a request for access to a resource from a network- connected device that includes a device identifier of the network-connected device and resource identifier, retrieving at least two pieces of information about the network- connected device from a distributed ledger, where the pieces of information about the network-connected device are each cryptographically signed by a different entity other than the network-connected device, and the information is not unique to a single instance of the network-connected device and is common to other network-connected devices of the same device model, and granting access in the access control manager based on at least the at least two pieces of information retrieved from the distributed ledger.

Description

SYSTEMS AND METHODS FOR RIGHTS CONTROL OF NETWORK-CONNECTED OR IOT DEVICES USING INFORMATION STORED IN A DISTRIBUTED LEDGER

FIELD OF THE INVENTION

[0001] The present invention generally relates to managing access to devices and more specifically to a decentralized infrastructure and system including smart contracts to manage access to, communication with and control over connected devices utilizing a distributed rights ledger technology such as blockchain.

SUMMARY OF THE INVENTION

[0002] Systems and methods for access rights control of network-connected devices using information from a distributed ledger are disclosed. In one embodiment, an access controller device includes a processor, a network interface, and a non-volatile memory containing an access control manager application for managing access of devices on a local network and for causing the processor to perform the steps of receiving a request for access to a resource from a network-connected device, where the request includes a device identifier of the network-connected device and resource identifier of the requested resource, retrieving at least two pieces of information about the network-connected device from a distributed ledger, where: the pieces of information about the network-connected device are each cryptographically signed by a different entity other than the network-connected device, and the information is not unique to a single instance of the network-connected device and is common to other network-connected devices of the same device model, and granting access in the access control manager for the network-connected device based on at least the at least two pieces of information retrieved from the distributed ledger about the network- connected device.

[0003] In a further embodiment, the distributed ledger is a copy of replicated and synchronized data spread across multiple nodes regulated by a consensus algorithm

[0004] In another embodiment, the consensus algorithm is used to agree on the status the majority of participating nodes. [0005] In a still further embodiment, the request for access is a request for access to a network that the access controller controls access to and the resource identifier identifies the network.

[0006] In still another embodiment, the request for access is a request for access to a network-connected resource that the access controller controls access to and the resource identifier identifies the network-connected resource.

[0007] In a yet further embodiment, a copy of the distributed ledger is stored on the access controller device.

[0008] In yet another embodiment, the distributed ledger is a blockchain ledger.

[0009] In a further embodiment again, the information about the network-connected device identifies a manufacturer of the device.

[0010] In another embodiment again, the information about the network-connected device describes capabilities of the device.

[0011] In a further additional embodiment, the information about the network- connected device describes instructions on how to use the device.

[0012] In another additional embodiment, the information about the network-connected device describes firmware versions that are available to the device and locations where they may be downloaded.

[0013] In a still yet further embodiment, the information about the network-connected device describes expected network traffic for the device.

[0014] In still yet another embodiment, the non-volatile memory also contains the distributed ledger.

[0015] In a still further embodiment again, the access control manager application also causes the processor to request the distributed ledger from another entity.

[0016] In still another embodiment again, cryptographically signed by a different entity other than the network-connected device includes being signed by a private key of a public-private key pair associated with the entity.

[0017] In a still further additional embodiment, at least one of the pieces of retrieved information indicates a standard to which the network-connected device is certified and is cryptographically signed by a compliance organization. [0018] In still another additional embodiment, the device identifier is a device model identifier that is not unique to a single instance of the network-connected device and is common to other network-connected devices of the same device model.

[0019] In a yet further embodiment again, the device identifier is an loT device identifier that is unique to that single instance of the network-connected device.

[0020] In yet another embodiment again, the access control manager application is also for causing the processor to: send a request for information about a network- connected device from a transaction on a distributed ledger to a ledger proxy device, where the request for information includes a device identifier of the network-connected device, where the ledger proxy device includes a non-volatile memory containing a ledger proxy application for causing the processor to retrieve the requested information from the distributed ledger by: performing multiple reads of the distributed ledger, and translating the results of the multiple reads of the distributed ledger into a message, and securely sending the message from the proxy server to the access controller device.

[0021] In a yet further additional embodiment, an access controller device includes a processor, a network interface, a non-volatile memory containing an access control manager application for managing access of devices on a local network and for causing the processor to perform the steps of: receiving a request for access to a network- connected resource from a network-connected device within a local network, where the request includes a device identifier of the network-connected device and resource identifier of the requested resource, and the request is digitally signed by a key unique to the network-connected device, where the access controller, network-connected device, and network-connected resource are connected to the same local network, retrieving information about the network-connected device from a distributed ledger, where the information about the network-connected device is cryptographically signed by an entity other than the network-connected device, and is distributed to other copies of the distributed ledger outside the local network, and granting access in the access control manager for the network-connected device to the network-connected resource based on at least the information retrieved from the distributed ledger about the network-connected device. [0022] In yet another additional embodiment, the distributed ledger is a copy of replicated and synchronized data spread across multiple nodes regulated by a consensus algorithm

[0023] In a further additional embodiment again, the consensus algorithm is used to agree on the status the majority of participating nodes.

[0024] In another additional embodiment again, the retrieved information about the network-connected device includes a list of one or more resources to which the access controller device is permitted to give access to approved network-connected devices.

[0025] In a still yet further embodiment again, the retrieved information about the network-connected device includes a list of one or more approved network-connected devices that are permitted to access to the network-connected resource.

[0026] In still yet another embodiment again, the retrieved information includes an identifier of the controller of the network-connected device.

[0027] In a still yet further additional embodiment, granting access in the access control manager for the network-connected device to the network-connected resource based on at least the information retrieved from the distributed ledger about the network-connected device includes: comparing the identifier of the controller of the network-connected device to an identifier of the controller of the access control device, and granting the network-connected device access to the network-connected resource when the identifier of the controller of the network-connected device is the same as the identifier of the controller of the access control device.

[0028] In still yet another additional embodiment, the key is a public key of a public- private key pair assigned to the network-connected device.

[0029] In a yet further additional embodiment again, the retrieved information indicates a standard to which the network-connected device is certified and is cryptographically signed by a compliance organization.

[0030] In yet another additional embodiment again, the retrieved information includes information that describes one or more resources with which the network-connected device is permitted to communicate.

[0031] In a still yet further additional embodiment again, the retrieved information includes a time period in which the information is valid. [0032] In still yet another additional embodiment again, the retrieved information includes the current user ownership of each device.

[0033] In another further embodiment, the retrieved information includes the previous user ownership of a device.

[0034] In still another further embodiment, the device identifier is a device model identifier that is not unique to a single instance of the network-connected device and is common to other network-connected devices of the same device model.

[0035] In yet another further embodiment, the device identifier is an loT device identifier that is unique to that single instance of the network-connected device.

[0036] In another further embodiment again, the access control manager application is also for causing the processor to: send a request for information about a network- connected device from a transaction on a distributed ledger to a ledger proxy device, where the request for information includes a device identifier of the network-connected device, where the ledger proxy device includes a non-volatile memory containing a ledger proxy application for causing the processor to retrieve the requested information from the distributed ledger by: performing multiple reads of the distributed ledger, and translating the results of the multiple reads of the distributed ledger into a message, and securely sending the message from the proxy server to the access controller device.

[0037] In a further embodiment, a ledger proxy device includes a processor, a network interface, an interface to a distributed ledger, a non-volatile memory containing a proxy server application for causing the processor to perform the steps of: receiving a request for information about a network-connected device from a transaction on a distributed ledger from a requesting device, where the request for information includes a device identifier of the network-connected device, retrieving the requested information from the distributed ledger by: performing multiple reads of the distributed ledger, and translating the results of the multiple reads of the distributed ledger into a message to be sent to the requesting device, and securely sending the message from the proxy server to the requesting device.

[0038] In another embodiment, the distributed ledger is on the ledger proxy device and the interface to the distributed ledger is an information path from the processor to the distributed ledger. [0039] In a still further embodiment, the distributed ledger is on a remote server and the interface to the distributed ledger is a communication path from the processor to the remote server through the network interface.

[0040] In still another embodiment, the request for information about a network- connected device describes what type of information about the network-connected device to retrieve and where: performing multiple reads of the distributed ledger includes identifying specific pieces of information from the type of information named in the request for information, and translating the results of the multiple reads of the distributed ledger includes combining the identified specific pieces of information.

[0041] In a yet further embodiment, the proxy server is in communications with an access controller device for network-connected devices, and where the access controller is configured to grant access for a network-connected device to a network- connected resource based on the message containing translated information from the ledger proxy device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0042] FIG. 1 is a system level overview illustrating an IDL (loT Distributed Ledger) system that can provide loT devices with access rights to resources or other devices based on information stored in a distributed ledger in accordance with embodiments of the invention.

[0043] FIG. 2 conceptually illustrates a ledger management device in accordance with an embodiment of the invention.

[0044] FIG. 3 conceptually illustrates an IDL device that can utilize decentralized ledger systems in accordance with an embodiment of the invention.

[0045] FIG. 4 conceptually illustrates blocks in an loT Distributed Ledger (IDL) in accordance with an embodiment of the invention.

[0046] FIG. 5 is a flow chart illustrating a process for creating a blockchain rights ledger in accordance with an embodiment of the invention.

[0047] FIG. 6 is a flow chart illustrating a process for verifying a request received from a device using an IDL in accordance with an embodiment of the invention. [0048] FIG. 6A is a flow chart illustrating a process for verifying a request received from a device using an IDL in accordance with an embodiment of the invention.

[0049] FIG. 7 is a flow chart illustrating a process for entering a device model record with compliance information into an IDL in accordance with an embodiment of the invention.

[0050] FIG. 8 is a flow chart illustrating a process for registering a device using an IDL in accordance with an embodiment of the invention.

[0051] FIG. 9 is a sequence diagram illustrating a process for incorporating information about a particular device into the IDL in accordance with an embodiment of the invention.

[0052] FIG. 10 is a diagram illustrated a process for providing a network-connected device with access to a network-connected resource in accordance with an embodiment of the invention.

DETAILED DESCRIPTION

[0053] Internet connected devices, including small single purpose devices (a.k.a. Internet of Things or loT devices) provide a specific challenge to maintaining and creating secured communication because these devices are typically limited in functionality and originate from a large and diverse base of Manufacturers. This is one of the reasons why the ability to identify a device is often limited and with that it is often difficult to establish if a device can be trusted and what capabilities it has. The lack of security is repeatedly cited as one of the main hurdles to adoption of the loT. Specific reasons that may hinder deployment of loT devices can include:

• Multiple silos - i.e. centralized providers such as larger Manufacturers want to provide their ecosystem only as well as large compliance organizations that coexist and don't directly collaborate. Neither Device Manufacturers nor compliance organizations want to share their database of device models and certifications since there is no single central authority that can be trusted by them or by recipients of the data to distribute the data permanently, reliably and securely. • The resulting incompatibilities result in underlying security mechanisms are not transparent - i.e. no one externally can understand how a Manufacturer, such as Samsung, secures the credentials and hence the trust in it is limited.

• There are no established procedures on how to transfer devices, resulting in difficult to establish trust on used devices or devices installed by a 3rd party that has limited trust from end user such as a landlord.

[0054] Certificate authorities are entities that confirm identities and that established mechanism could be used to help identification of end devices but does not necessarily help to establish how devices can be used, who owns them and what they are entitled to. Also their centralized nature requires a restriction to one or a few authorities whose number may not be easy to increase later, which leads encourages undesirable monopolistic or oligopolistic behavior.

Solution Overview

[0055] The blockchain can be seen as public, decentralized ledger concept implemented with the underlying technology of cryptocurrencies such as bitcoin and Ethereum, but it has also been used to decentralize other tasks such as management of domains (namecoin) or land registration or considered for registration of content rights as disclosed, for example, in U.S. Patent Publication No. 2017/01 16693, the relevant portions of which are hereby incorporated by reference. Blockchain can be seen as a form of distributed ledger technology, where a distributed ledger is typically understood to involve a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites, countries, or institutions. Consensus algorithms are typically used to ensure replication across nodes and/or agree on a status of the majority of participating nodes.

[0056] The benefit is to establish trust between anonymous parties by creating consensus using rules that create security by introducing a difficulty to build consensus on a block of transactions and by chaining blocks in order to improve security of older blocks with each new block. An incentive is created for individuals to maintain a network by being rewarded for distributing blocks they have created (closed) and since there is an incentive to close the blocks (e.g. mining), there is an incentive for several participants to store the ledger or parts thereof and making it publicly available allowing others to use it to look up information stored in it. Although the present application discusses implementations in certain embodiments as utilizing blockchain as a decentralized ledger and terminology commonly used in blockchain technologies, one skilled in the art will recognize that other types of decentralized ledger technologies may be adapted and utilized in accordance with embodiments of the invention as appropriate to a particular application.

[0057] Incentives to mine may be a monetary reward, as is common with cryptocurrencies, or interest in the ecosystem. Other incentives include the right to maintain the ledger or participate in it, such as obtaining the right to create device or model entries. The resulting ledger information is stored by many participating parties, ideally as identical copies or portions thereof, ensuring longevity. These are some of the features that can be used in embodiments of the present invention of the loT (Internet of Things) Distributed Ledger (IDL) to make statements about loT (Internet of Things) devices and other types of devices reproducible and transparent and to decentralize their confirmation and maintenance. An loT device is typically understood to be a network-connected (often to the internet or cloud services) electronic device that performs a specific real-world function(s) and/or is able to transfer data over a network without requiring human interaction.

[0058] Various embodiments of the invention provide mechanisms for tying rights and/or access of loT devices to a distributed ledger and the term loT device is used herein. However, one skilled in the art will recognize that the mechanisms may similarly be utilized to tie types of devices other than loT devices to a distributed ledger as appropriate to a particular application.

[0059] In some embodiments, a transaction or entry in the loT Distributed Ledger (IDL) to contains information that pertains to a specific physical device and the transaction/entry can be referred to as an loT device record. In additional embodiments, a transaction or entry in the distributed ledger contains information that pertains to a device model (i.e., all physical instances of devices of a device model are manufactured to have substantially similar components and/or characteristics) and the transaction/entry can be referred to as a device model record. The information about the specific device within an loT device record or about the device model within a device model record can be referred here below as "statements." A gateway or other controller device that configures the connectivity of an loT device can read statements from the distributed ledger and use that information to determine whether to grant access or connection rights to a resource or to another device on the network governed by the gateway or controller device. Systems and methods for granting rights and/or access to resources to a specific device or a device model in accordance with embodiments of the invention are discussed below.

Granting Access Rights to Devices using a Decentralized Ledger

[0060] Many embodiments of the present invention include a decentralized, distributed ledger that documents the origin, capabilities, and transfer of devices referred to here as loT Distributed Ledger (IDL). In many embodiments of the invention, the ledger is stored, modified and maintained on several independent nodes and trust is established by rules on the format for transactions on the ledger rather than the source and origin of the information. In several embodiments, the rules are established with cryptographic principles that make modification of the data difficult. In further embodiments, no centralized third party of trust is needed for transactions involving assignment, restriction and transfer or registration of information about the device, metrics analytics, and/or auditing. In many embodiments, the information stored on the ledger is verified and used to establish trust in devices by verification of statements from other trusted sources about this device stored in the IDL. This information is then used to trust interactions with this device and e.g. enable communication with it. In certain embodiments, devices can include, but are not limited to, home appliances, monitor equipment, sensors, displays, and/or gateways, but can include any electronic device.

[0061] In a number of embodiments, the IDL is stored and verified in a decentralized fashion, i.e., replicated to different entities (that may be referred to as nodes) that are independently able to verify past transactions. In further embodiments, the ownership and manufacturer of a device as well as its capabilities can be proven using cryptographic principles by verifying information stored in the ledger. In many embodiments, the chaining of transactions, cryptographic verification and the hash challenge utilizes a blockchain system based on principles and/or mechanisms similar to those in the art of cryptocurrency. Techniques for managing blockchains in the context of currency are described in "Bitcoin: A Peer-to-Peer Electronic Cash System" by Satoshi Nakamoto, published in 2008 and Ethereum white paper and yellow paper, the disclosures of which relevant to blockchain management are hereby incorporated by reference in its entirety.

[0062] A DLT (Distributed Ledger Technology) can typically be understood to be a distributed database that maintains a continuously-growing list of transactions grouped in blocks. Each block contains a link to a previous block generated using a hash of the previous block, and often includes mechanisms for protection from tampering and revision. The blockchain is distributed so that copies are replicated among participating nodes in the system. As transactions are added, blocks are added and the longest chain of blocks that follow a rule and provide according proof is trusted. Nodes may be any of a variety of hardware devices or loT devices, such as, but not limited to, servers, workstations, desktop computers, mobile devices, and/or tablets, configured to participate in the IDL system as discussed further below. More specifically, nodes can include ledger management devices and loT devices as described in greater detail further below.

[0063] Proof of work may be performed using CPU, GPU or dedicated processors. Proof of identity to proof stake or assigned authority may be provided with using private keys to proof their possession.

[0064] The ledger as common, secure platform allows components to establish trust in order to communicate, e.g. for local networks in a house, car or business. Communication between devices may also include a discovery process for information about the device, its capabilities and location which can co-exist and integrate with the trust and secure communication enabled by this invention.

[0065] In many embodiments, an IDL system has a benefit of being pseudonymous, i.e., the transaction cannot be traced to an individual or location but a pseudonym (key) and are therefore protecting consumer's privacy and other embodiments the identity of the pseudonyms may be required and know or even published to confirm the source of the data increase trust but also to discourage behavior that would burden the IDL with a high amount of transactions of data that is not relevant or even illegal to store and distribute.

IDL Systems

[0066] An IDL (may be single or multi-purpose ledger) system in accordance with an embodiment of the invention is illustrated in FIG. 1 . The ledger system 100, includes a ledger management device 1 10. It is a node that can communicate with one or more other nodes via a network 120. Additionally, the IDL system 100 includes a variety of devices that may run on hardware such as personal computers 130, mobile phones 170, personal computing devices 160, some of which may communicate on the network 120 via a wireless access point 150. Some of the devices may be loT devices on a local network. The local network may include a gateway or controller 140 that provides rights or access of loT devices to resources or to other devices on the local network.

[0067] The IDL system 100 includes a ledger management device 1 10 configured to create an initial genesis block in a ledger file. This new ledger file may be transmitted over the network 120 to other nodes including devices 130, 160, 170 and other ledger management devices 1 12. In many embodiments, the IDL ledger system 100 is decentralized in that entire copies of a particular ledger file are stored on multiple nodes. In other embodiments, some copies may be a pruned or partial copy of the ledger file. Participating nodes may utilize a copy of the ledger and make the transaction history available for download to others by default via network 120 such as by utilizing peer-to-peer protocols. As will be discussed further below, ledger management devices 1 10 and 1 12 can be machines under the control of a device manufacturer or compliance organization. In certain embodiments, a device manufacturer or compliance organization is not permitted to create a genesis block but may add blocks to an existing ledger. It would be understood that where the text below describes a device manufacturer or compliance organization performing an action would mean that the action is carried out through a ledger management device that is permitted to modify or add blocks to an IDL ledger. [0068] In some embodiments, ledger management devices 1 10 and 1 12 can be machines that act as proxies that access the distributed ledger (e.g., to read or write) on behalf of another entity when it receives a request to access the ledger, similar to a web proxy but with ledger operations. As will be discussed further below, an IDL proxy can receive a request to access the ledger and respond by retrieving or writing the requested information, e.g., in a transaction.

[0069] In many embodiments of the invention, the consistency of the data in the ledger can be confirmed from miners that close blocks to be offered for consensus; these may be trusted per default if in a closed controlled network using a consensus algorithm like RAFT or clique that enables leading nodes to decide on the consensus. Other systems require a proof that is applied when closing a block. In various embodiments, blocks are closed in intervals that can be predefined or self-regulating to converge to a mean transaction time for a number of previous transactions.

[0070] While a variety of decentralized IDL ledger systems are described above with reference to FIG. 1 , the specific components utilized within a decentralized ledger system and the manner in which ledgers are stored and maintained may vary in accordance with the requirements of specific applications. Ledger management device systems that can be utilized in decentralized IDL ledger systems in accordance with various embodiments of the invention are discussed further below.

IDL Management Devices

[0071] A ledger management device, also referred to as node, that can be used to create and/or modify an IDL ledger in accordance with embodiments of the invention is illustrated in FIG. 2. The ledger management device 210 includes a processor 220, network interface 230, network input/output 260, system bus 250, and memory 280. Memory 280 includes a ledger creation application 281 , ledger modification application 282, and ledger block closing application 283. Ledger creation application 281 can configure processor 220 to perform processes to generate an IDL ledger such as those discussed further below. Ledger modification application 282 can configure processor 220 to perform processes to modify an IDL ledger such as those discussed further below to add transactions to the ledger. Ledger block closing application 283 can configure processor 220 to perform processes to close an IDL ledger block such as those discussed further below. Ledger block storage application 284 can configure processor 220 to perform processes to store the transactions in a ledger or copy a ledger status of processed transactions and allow retrieval of stored information for propagation of the information to other nodes or for queries on the ledger information from devices that are interested in the ledger content but don't store the entire ledger, possibly because ledger storage and processing is resource intensive. Ledger block verification application 285 can configure processor 220 to perform processes to verify transactions in the block, including those that add or modify information or close blocks. Blocks and blockchains may be received from and/or distributed to other ledger management devices and/or loT devices using network 120.

[0072] A decentralized IDL ledger system may include additional ledger management devices 21 1 with components similar to ledger management device 210. While a specific architecture of a ledger management device is discussed above with respect to FIG. 2, ledger management devices in accordance with embodiments of the invention may utilize any of a variety of architectures as appropriate to the particular application. Devices that may utilize a rights ledger in accordance with embodiments of the invention are discussed above. In particular, some of the nodes may not have the ledger creation application 281 as there are not use to create a ledger or the block closing application 283 if they are not used to close blocks or even modify blocks. The ledger may be reduced to storing application 284 and verification application 285 and can be used as IDL proxy that relays IDL information to devices such as loT devices using network interface 260.

Devices Utilizing loT Ledgers

[0073] In many embodiments of the invention, an IDL device is a platform that has resources that are interacted with remotely using information encoded in the IDL ledger to determine a level of trust. That may include information about the device manufacturer, its behavior, history or certification status. As will be discussed further below, IDL devices that can access, read, and/or write to an IDL ledger can include access control devices and IDL proxies. [0074] An IDL device that can utilize decentralized ledger systems in accordance with an embodiment of the invention is illustrated in FIG. 3. The IDL device 300 may include a processor 310, input/output (I/O) device 330, mass storage 340, network interface 350, system bus 360, and memory sub-system 370. The memory subsystem contains an operating system 371 and ledger module 380. Many embodiments of the invention include a device 300 which has a ledger module 380 that further includes a verification application 383 which can utilize a ledger to retrieve and/or verify information about the device. In addition, ledger module 380 can contain a ledger modification application 382 that can add new data/transactions to the ledger, as well as a storage application to store ledger information and an optional ledger block closing application that configures the processor to perform the computational work to close a block in the ledger. In some embodiments, this ledger module is remote, communicating via network interface 350, e.g., on a local gateway or replaced with a trusted IDL proxy as described further below. Certain embodiments of the invention may have an IDL device 300 that utilizes the decentralized ledger system via an interface with a communication network including, but not limited to, the Internet. Additionally, further embodiments of the invention can include user I/O (input/output) 301 to provide a user interface for interacting with device 300.

[0075] While a variety of device systems are described above with reference to FIG. 3, other devices incorporating any of a variety of architectures and/or hardware enabling the utilization of a decentralized IDL ledger system in accordance with various embodiments of the invention. For example, in certain embodiments, a copy of the ledger may be stored locally in the device 300 and utilized when the device has no connection to other nodes in the ledger system. These periods of disconnected "offline" mode are typically limited in time to enforce connection to the latest updated ledger.

[0076] In many embodiments, a distributed network of ledger management devices and optionally loT devices process and synchronize the blockchain by consensus across multiple POPs (points of presence) across geographic regions or globally. The devices may respond to queries from other devices in the network in a peer-to-peer nature to validate information. In further embodiments, access to the blockchain may be limited to some organizations. These self-govern and vote on accepting new or rejecting existing members. In several embodiments, a member is represented by a public-private key pair that can be associated with a node and participate in the distributed ledger. Voting criteria may include contributions to the ledger in mining, data replication and node operation, creating an incentive for operator nodes, distributing data and/or participation in mining. Other incentives to encourage this behavior can include monetary in fiat and/or crypto currency or tokens to interact with the ledger.

IDL Ledger Blockchain Structure

[0077] In many embodiments of the invention, the fundamental DLT structure often includes blocks which are linked together to form a blockchain. Each block in the blockchain contains a reference to the previous block in the chain, with the exception of the genesis block which is the first block created and contains no reference. Ledger blocks contain similar components but may vary in size due to the amount of transactions that are recorded within each block. The size and frequency of blocks can vary.

[0078] IDL ledger transactions typically contain identifying information of the submitter and other entities such as Device Manufacturer, compliance organization, device owner and/or user as an identity, such as derived from a public key and/or an individual device or model.

[0079] A conceptual illustration of a ledger blockchain file structure in accordance with embodiments of the invention is illustrated in FIG. 4. In many embodiments, the ledger blockchain segment 400 contains a first block N 410 and a subsequent block N+1 420. In a number of embodiments, each block contains a hash of the previous block in the chain. The block N hash 430 contains a hash depending on the previous block N-1 in the ledger blockchain 400, while the block N+1 hash 440 also depends on the previous block N in the ledger blockchain 400. Block N also contains a block N hash solution 450 which is a calculated solution to a cryptographic challenge. Each completed block requires a solution, including block N+1 420 which contains a block N+1 hash solution 460 and is not yet linked to a newer block in the current ledger blockchain 400. Techniques for managing blockchains in the context of currency are described in "Bitcoin: A Peer-to-Peer Electronic Cash System" by Satoshi Nakamoto, published in 2008, the disclosure of which relevant to blockchain structure is hereby incorporated by reference in its entirety. The transactions are often processed and resulting information is stored. Processing may occur, using DLT as e.g. implemented in the Ethereum or IOTA blockchain.

[0080] In many embodiments, a new statement or information about a device may be submitted to the ledger by an IDL device, to make a statement about an loT device. In some embodiments of the invention, block N 410 also includes a group of transactions, transaction N1 490, transaction N2 491 , and transaction N3 493. Likewise, in several of those embodiments, block N+1 420 has a separate group of transactions N1 +1 495, transaction N2+1 496, and transaction N3+1 497. In further embodiments, these transactions are discrete and not necessarily coupled with the new resource being registered or with each other. One or more transactions can include a statement, such as, but not limited to ownership of the resource, who may control the resource, compliance of the device to a standard, firmware version of the device, instructions for operation of the device, and/or expected network traffic patterns.

[0081] Although specific representations of ledger block structures are described above with reference to FIG. 4, any of a variety of structures can be implemented using available data structures or hardware equivalents as appropriate to the requirements of specific applications in accordance with various embodiments of the invention.

LEDGER ACCESS AND SECURITY

[0082] The IDL leverages and builds upon concepts established in crypto currency applications. Currency transactions from one ID to another are similar to the registration of trust between entities, and trust is established by agreement in participating in the process but the data can be verified and maintained collectively.

[0083] To enable broad distribution, reading the blockchain may be open without requiring permissions.

[0084] The reliance on the keys for authentication of the actors creates a strong security but can also be a single point of failure. In several embodiments of the invention, smart contract mechanisms in IDL may enable a backup process, called mediation that establishes security by allowing two other, predetermined and registered mediators to recover a third party from the loss of control over its keys and associated identity. [0085] The distributed nature of the DLT that includes easy addition of nodes can help thwart denial of service (DoS) attacks that aim to overload the blockchain network with traffic. Overloading of individual nodes does not impact the overall network. Denial of service attacks that inflate the blockchain with registration of transactions may be discouraged by the cost of transactions or limited by requiring certain permissions. The local query of trusted clients by the resource does not require use of the consensus network, and thus is not impacted by a denial of service attack.

[0086] In many embodiments of the invention, contributions to the ledger are accompanied with credentials, such as a public-private key pair where the public key is registered in the ledger. Accordingly, in several embodiments, credentials are kept secure and protected with a password but can also be stored in a location that is hard to access such as a HSM (Hardware security module) or other hardware or mechanisms that have the ability to use private keys while protecting against access to them. Private keys are used to sign transactions or otherwise prove identity when submitting transactions to the ledger. Ledger nodes can now verify validity of the submission by verification of access rights and ownership of resources, token or information that the transactions address.

[0087] Verifying information on the IDL may follow rules to ensure security, such as, but not limited to, a required minimum block age to trust information in a block or minimum requirements to the proof brought to close the block such as difficulty of proof of work to trust information in a block.

[0088] Ledger consistency and trust in the information from the ledger or IDL proxy may also be increased by verification of know data in the blockchain, e.g., device creation, i.e. querying the blockchain for a piece of information already known by the device and permanently stored by the device.

[0089] The security is not only established by secured entry of association but also by allowing a secure communication, i.e. the devices that are known and trusted have a public key that can be used to target communication to them secure from eavesdropping by others. This is true for any entities registered with the public key in the blockchain and also important in communication with the IDL proxy. [0090] Public and private key pairs are in the context of asymmetric encryption using schemes, such as, but not limited to, RSA or Elliptic curve, but encryption may be alternatively implemented with symmetric secret keys as appropriate, such as where it is more efficient. For unilateral authentication Direct Anonymous Attestation (DAA) algorithm or Intel's EPID may be used.

[0091] Cryptographic authentication, such as, but not limited to, establishing using X.509 certificates and common certification hierarchies can help in understanding identity of devices.

Restoring Keys with Mediation

[0092] In many embodiments of the invention, IDL records are controlled by their respective owners: Manufacturers can correct or update their model information and standards certifiers can change the status of compliance of a device to a particular standard, though any prior update is irrevocably stored with the transaction used to register it.

[0093] To enable broad distribution in several embodiments, reading the blockchain is not limited with permissions. Meta information for models including name and version are typically public but could be encrypted if required. Registration of device model name may be replicated by bad actors, but can still become trusted when endorsed with a trusted certification or issues by a trusted Manufacturer. Trust here can be established with prior knowledge of the public key, supporting verifications that know of the certification organization only and want to verify legacy device models that only provide their make and model.

[0094] The reliance on the keys for authentication of the actors creates a strong security but also a single point of failure. Loss or theft of the keys prevents control of the device or certification information. The smart contract of this IDL in many embodiments enables a backup process, called mediation that establishes security by allowing two other parties to recover a third party from the loss of control over its record.

[0095] In cases where the compliance certifier and Manufacturer are collaborating, they can register a single, commonly trusted third party called the mediator. If the mediator and Manufacturer agree, the mediator can reassign control of the compliance record for a model and vice versa. In case of loss of the private key of the Manufacturer, the Manufacturer would directly contact the compliance certifier to convince it of the loss. The compliance certifier then sets a flag to mediation that would allow the mediator to assign a new owner to the Manufacturer. This model assumes that the compliance certifier and Manufacturer trust each other because they both have an incentive to maintain the compliance record and the independent third party is an insurance against bad actors if the trust is broken.

Establishing trust in security credentials

[0096] In many embodiments of the invention, trust in an entity registered in the blockchain may be established by a combination of any of:

[0097] - Certificate from a known certification authority (CA), e.g., IdenTrust, Comodo, DigiCert, etc.

[0098] - Usage in combination with a trusted device. Example: A Manufacturer (as represented by a public key) may be trusted because this key has been used in transactions such as in creation of a known device that is already trusted.

[0099] - Usage in combination with a trusted entity. Example: A Manufacturer (as represented by a public key) may be trusted because its devices have been endorsed by a known compliance organization.

[00100] - Popularity, status or reputation. Example: A Manufacturer (as represented by a public key) may be trusted because it has been involved in many or old transactions.

[00101] - Other sources of explicit trust. Example: A Manufacturer (as represented by a public key) may be trusted because a user expresses explicit trust, possibly via a user interface that confirms that this is a trusted device. The user may have used other databases or online trust systems as prior verification.

[00102] The above can be viewed in different contexts, as described below.

Local Context

[00103] Similar to the concept of: 'the friends of my friends are my friends' friendships are traced.

[00104] This could be an endorsement function: For example, if a Manufacturer like Samsung endorses Zigbee and Zigbee endorses Open Connectivity Foundation (OCF), the friend's network of trust scales through several entities. This may allow a device to only trust its Manufacturer and then securely scale to all endorsed compliance organizations.

Global Context

[00105] According to the concept: 'if you have many connections, you are trusted.' In the global context, trust can involve counting the number of connections (endorsements or certified devices) and the importance of the connections (measured again by number of connections of the referencing node) to judge trust of an entity.

[00106] This could be further enhanced to weight of stake: 'if you have many credible connection, you're likely trusted': The connections an entity has in this case is used to judge credibility and your connection is more valuable to judge trust in connected entities.

[00107] This could also be enhanced to weight of activity:

[00108] This combines an uncontrolled open system with a layer of reputation that allows a trust score and confidence. This may be useful to avoid phishing or fake entries as common in the online world.

Analysis of Reputation

[00109] While reputation information can be helpful to judge the amount of trust to be used to communicate with devices, it is also interesting in a broader analysis context.

[00110] The analysis of data in and interactions with the blockchain can help to increase security, maintenance and may be valuable for others to improve service and product offerings or provide other intelligence for the enterprise.

[00111] Some information about certain devices may be publicly and securely observable and help to establish trusts. As the same device or model that is represented with an identity in the blockchain can be addressed from different participants who can make statements about this device, an analysis of the IDL can reveal how many participants made statements and of what nature they are. If many participants made a statement about a model or device it may be more trusted as it is more likely to be real and usable. If the statements are similar and or of similar nature it can be trusted that they are true. If statements are made from several sources that are known by either a connection to the real world or known identity they are likely to be correct. Examples: [00112] - A second hand device I am buying has a long chain of owners that certified a time of possession the minimum age can be estimated.

[00113] - If several known compliance organizations made a statement about a device, certifying it, it can be trusted to be of high quality.

LEDGER CREATION PROCESS

[00114] A process for creating a decentralized ledger system in accordance with an embodiment of the invention is shown in FIG. 5. In certain embodiments, the process may be performed by a ledger management device or other node configured by a ledger creation application. The process 500 may include generating (502) a ledger genesis block file structure in which the rest of the block data will be stored. A genesis block is unique from all other blocks in a blockchain as it is the only block to not point to a previous block in the chain. Initial data can be incorporated (504) into the genesis block to allow for restrictions or information to provide to following blocks. In some embodiments, the genesis block may also include tokens that allow for ledger interactions that are transferable. The creation may further determine limitations of control of ledger interactions such as who is allowed to close blocks (i.e. mining). To complete the genesis block, the genesis block is closed (506) just like any other block. This closing may come in the form of a proof, including proof of work, stake or authority. A closed block is then distributed (508) to other nodes in the network.

[00115] Although specific processes for creating rights ledgers are described above with reference to FIG. 5, any of a variety of processes can be implemented using available ledger management devices and/or loT devices as appropriate to the requirements of the specific applications in accordance with various embodiments of the invention. Techniques for managing blockchains are described in "Bitcoin: A Peer-to- Peer Electronic Cash System" by Satoshi Nakamoto, published in 2008, the disclosure of which relevant to ledger management is hereby incorporated by reference in its entirety. Other relevant documentation describe the system of Ethereum, Hyperledger Fabric and Quorum. Once created, additional new blocks can be formed in order to create a blockchain from the genesis block. A process for creating new blocks in a blockchain in an IDL ledger in accordance with embodiments of the invention is discussed below. PROCESSES FOR VERIFYING A REQUEST USING THE LEDGER

[00116] A access controller device having access to the IDL can utilize information in the ledger to verify trusted devices. A process in accordance with embodiments of the invention is illustrated in FIG. 6. The process 600 includes receiving (602) a resource request, which can be a command to do something from another entity by accessing the ledger. The request may come via any of a variety of methods, including but not limited to, request via broadcast message/network, unicast message/network, local network or the internet. In several embodiments, the request includes a device identifier of a network-connected device and a resource identifier of the requested resource. In many embodiments, the request is sent from the network-connected device to an access controller device that controls access to the resource.

[00117] The process 600 can include retrieving (604) information about the network- connected device from the IDL ledger. In some embodiments, the information can include identification of a controller associated with the network-connected device. In various embodiments, a controller can be a user, owner, gateway device, or other entity that is represented to have some right of control over the target network-connected device. In several embodiments, the pieces of information retrieved from the IDL ledger are cryptographically signed by different entities other than the network-connected device. The information can be signed, for example, using the private key from a public- private key pair of an entity or by attaching a certificate signed by the private key.

[00118] In some embodiments, the information retrieved from the ledger is common to all network-devices of the same model. In further embodiments, the information is not unique to a single instance of network-connected device. The information can be a characteristic of the device, such as, but not limited to, the manufacturer of the device, capabilities that the device has, instructions on how to use the device, firmware versions that are available to the device and locations where they may be downloaded, and/or expected network traffic for the device.

[00119] The process 600 includes evaluating (606) the retrieved information. In some embodiments, this involves verifying the source of the request, e.g. another device. Verification can be, for example, a lookup to confirm if the device that sent the request has the same controller (identified earlier) as the receiving access controller device. This may occur directly or via another trusted source that performs the lookup (e.g., a proxy) or may be a lookup on cached information.

[00120] The process 600 includes executing (608) the command if verification was successful. In many embodiments, the command is granting access for the network- connected device to the requested resource. In some embodiments, the requested resource is a network segment, such as a local network or sub-network, that the access controller device has control over access to. In such embodiments, the resource identifier can be used to identify the network.

[00121] While a specific process for managing loT devices using an IDL ledger is described above with respect to FIG. 6, any of a variety of processes may be utilized in accordance with the invention.

[00122] A similar process for verifying a request from a network-connected device using a unique identifier for the device in accordance with embodiments of the invention is illustrated in FIG. 6A. The process 650 includes receiving (652) a resource request. The request may come via any of a variety of methods, including but not limited to, request via broadcast message/network, unicast message/network, local network or the internet. In several embodiments, the request identifies the network-connected device (e.g., with a device identifier), identifies the requested resource (e.g., with a resource identifier), and is digitally signed by a key unique to the network-connected device (e.g., with a private key of a public-private key pair). In many embodiments, the request is sent from the network-connected device to an access controller device that controls access to the network-connected resource. In some embodiments, the access control device, the network-connected device, and the network-connected resource are connected to the same local network or sub-network.

[00123] The process 600 can include retrieving (654) information about the network connected device from the IDL ledger. In some embodiments, the information can include identification of a controller associated with the network-connected device. In various embodiments, a controller can be a user, owner, gateway device, or other entity that is represented to have some right of control over the target network-connected device. In several embodiments, the piece(s) of information retrieved from the IDL ledger is cryptographically signed by an entity other than the network-connected device. The information can be signed, for example, using the private key from a public-private key pair of an entity or by attaching a certificate signed by the private key. In some embodiments, the piece of information is also distributed to other copies of the distributed ledger that are outside of the network (e.g., local network or sub-network) the access control device is connected to.

[00124] The process 600 includes evaluating (606) the retrieved information. In some embodiments, this involves verifying the source of the request, e.g. another device. Verification can be, for example, a lookup to confirm if the device that sent the request has the same controller (identified earlier) as the receiving access controller device. This may occur directly or via another trusted source that performs the lookup (e.g., a proxy) or may be a lookup on cached information. In several embodiments, verifying can involve retrieving pieces of information from the IDL ledger that are cryptographically signed by different entities other than the network-connected device. The information can be signed, for example, using the private key from a public-private key pair of an entity or by attaching a certificate signed by the private key.

[00125] In some embodiments, the information retrieved from the ledger is common to all network-devices of the same model. In further embodiments, the information is not unique to a single instance of network-connected device. The information can be a characteristic of the device, such as, but not limited to, the manufacturer of the device, capabilities that the device has, instructions available to the device, firmware versions that are available to the device and locations where they may be downloaded, and/or expected network traffic for the device.

[00126] In various embodiments, the piece(s) of retrieved information is a list of one or more resources that the access controller device is permitted to give access to approved network-connected devices, a list of one or more approved network- connected devices that are permitted to access to the network-connected resource, an identifier of a standard to which the network-connected device is certified, information that describes one or more resources with which the network-connected device is permitted to communicate, a time period in which the information is valid, the current user ownership of the access controller device and/or network-connected device, and/or the previous user ownership of the network-connected device. [00127] The process 650 includes executing (658) the command if verification was successful. In many embodiments, the command is granting access for the network- connected device to the requested resource. In some embodiments, the requested resource is a network segment, such as a local network or sub-network, that the access controller device has control over access to. In such embodiments, the resource identifier can be used to identify the network.

[00128] While a specific process for managing loT devices using an IDL ledger is described above with respect to FIG. 6A, any of a variety of processes may be utilized in accordance with the invention.

Blockchain Choice

[00129] A token, used to derive device control, may be registered in existing ledgers, such as, but not limited to, Bitcoin or Ethereum to leverage existing mining, security, cryptocurrency and traffic capabilities. Some systems may offer a functionality to enable other technologies like the IDL to run. A token could be represented by a fraction of a cryptocurrency coin that is marked as such and any owner of a fraction of that coin has control over the associated record, such as a device record. A Manufacturer could create this token to register creation of a device or model and shows she has control of the device. This transaction can also receive some cryptocurrency that signifies control over information about this device. The possession of the currency or parts thereof signal ownership or control to any reader of the blockchain. Different fractions / amounts could have predefined meanings and the amount can signal the duration or scope of the control.

[00130] For an explicit implementation of this functionality a more flexible DLT may be used such as Ethereum smart contract approach that allows management of associations using byte code running in the Ethereum virtual machine, as described in "Ethereum: A Secure Decentralised Generalised Transaction Ledger" by Gavin Wood

(h;tps://qllhub com/eihereuir /wiki/ iki the relevant portions of which are hereby incorporated by reference.

[00131] The mechanisms of communication, storage of info in the blockchain, smart contracts are described in "A Next Generation Smart Contract & Decentralized Application Platform" by Vitalik Buterin (https://github.com/ethereum/wiki/wiki/White- Paper), the relevant portions of which are hereby incorporated by reference.

Blockchain Implementation

Incentivize Mining

[00132] In some embodiments, the IDL incentivizes mining by providing miners (i.e. those that manage to close blocks, often after providing a required proof) the right to submit information to the blockchain to e.g. register devices or models.

[00133] Miner can have ability to create several devices by writing their device identifier (ID) in the last block before closing it (by proof of work or stake) these devices can now be referred to in future transactions.

[00134] Transactions in the ledger may express statements about devices, such as, but not limited to, assigning control, returning control, notification of the device, certification or behavior.

[00135] Mining may also be incentivized with transaction fees that are provided with each transaction and given to the miner of this block. An additional incentive may be a token in the blockchain currency (e.g. ether for Ethereum blockchain) or any other form of payment such as other cryptocurrency.

[00136] Transactions can make up the next block and are verified by miners.

[00137] While crypto currencies may adjust the mining difficulty to maintain or modify the frequency of new blocks, here the difficulty may be constant (or with slight increase) to maintain ability to vary traffic. That is, with more participants, more devices and transactions are issued and a more successful system can grow faster. For this, unlike currencies, there is not the same risk of inflation and the difficulty of proof can remain the same, while the frequency of creating new blocks increases. Alternatively, blocks can become larger, while the frequency remains the same as difficulty increases.

[00138] In several embodiments, the right or ability to register a device into the ledger is represented by a transaction registration token that is earned by finding solutions to a hash challenge (e.g., the hash challenge required to close a block). Each solution may reward the solver with transaction registration tokens, where the number of tokens (RN) granted per solution is configurable as an aspect of regulating the rate at which devices can be registered into the rights ledger. The reward can be a single token, fraction thereof, or multiple.

[00139] For example, if the frequency at which devices are registered should be decreased, the number of tokens RN granted can be decreased allowing less registration.

[00140] Similar to the hash challenge in bitcoin the adjustment can be automated by changing it in accordance with a targeted frequency of closing a block. A higher frequency will have more overhead but is quicker to secure the transactions, which is important to verify a license transfer for immediate actions.

[00141] In several embodiments, this can be an alternative to adjusting the difficulty of the hash challenge itself. A work registration token may be represented as a unique value and associated with a private key holder by publishing the public key. In several embodiments of the invention, one token grants the ability to register one device into the ledger. Fractional tokens can be combined and a combination of token quantities resulting in more than one result in a residual token quantity that can be used to issue other rights. This is similar to combining bitcoin transaction values to match a desired transaction value.

[00142] In a number of embodiments, parallel ledger systems may exist and either work together or be indexed alongside each other. The registered devices may be restricted to not be interchangeable between independent ledgers and devices could look into several different databases for its owners. The decentralized ledger may work with external web services or individual clients to provide information about the ledger including, but not limited to, device contents, size, scope and/or measures for popularity.

IDL Proxy

[00143] Verification of the status and ledger may be cached or part of a standard communication when establishing a connection or issuing a command to a device. Alternatively, in certain embodiments a proxy is used to facilitate access by simplifying it, combining data sources and reducing complexity and storage requirement on the interacting device. [00144] The proxy may be operated by trusted party. Trust in this party can be established with in ways independent of the loT distributed ledger using secure communications protocols such as https that can be used to exchange and verify cryptographic certificates to establish identities of communicating parties and can be used to encrypt and keep communication secure.

[00145] This proxy maybe a cloud application or a location-specific device like a cell phone or gateway. It can be a device that also includes other functionality and additionally enables communication using the IDL. For example, the device illustrated in Fig. 3 can be used as such a proxy when the network interface 300 is used to receive trusted queries or submissions to the ledger and used to reply with information from the IDL.

[00146] Intermediate logic, modules, applications or devices may also be used to connect the system described to other systems. Those systems includes established standards such as created by OPEN CONNECTIVITY FOUNDATION, Bluetooth Special Interest Group, Zigbee alliance, or Z-Wave Alliance or companies such as Apple, Google, Amazon. These systems may present a system of rules and communication infrastructure, script formats, interfaces and/or APIs that can be used to establish interoperability of the described systems with different eco systems to enhance each with the established trust and security between devices including bridging devices within different ecosystems. The system can also be used to include some functionality of these standards to, e.g., store standard specific information such as resource information and/or other data.

[00147] While in some cases existing mechanisms may be enhanced, in other cases the system may exist in parallel enabling a different, additional communication with different properties for security, privacy, complexity and interoperability.

[00148] Inversely the IDL can serve as a backend of different ecosystems. For example, the device can ask its ecosystem cloud for availability of and trust with resources and the ecosystem cloud will look up the information in the IDL ledger and translate this to the client device.

[00149] A large number of rejections or invalid queries could be aggregated and trigger alerts if they exceed a certain threshold that may indicate a systematic attack or fault. [00150] An IDL proxy shifts the cost and complexity of accessing the IDL from the end device to a centralized node. The centralized node is often connected on the Internet and is accessible to devices which may need information from the IDL. The protocol(s) used to communicate between the devices and the proxy may be constrained such as through a low bandwidth wireless network. Further, these devices may be battery powered, and thus total communication time may need to be optimized. Thus, one protocol can be used to communicate from the devices to the proxy. The proxy can then translate the first protocol into a series of read and/or writes to the IDL using another protocol. In one embodiment, the proxy would use CoAP (Constrained Application Protocol) in which the device would issue a GET command in which the resource identifier is the device model number/ID. The proxy would then perform a series of read commands between the CoAP server interface and the IDL, for example, GET /Devicelnfo/Modelld?X. These reads can include a request for pieces of information, such as, but not limited to, compliance status, manufacturer identity, and/or the expected network traffic pattern for the device model. The multitude of IDL reads can be translated into a single message and sent back to the device using CoAP. While specific implementation details of an IDL proxy are discussed above, one skilled in the art will recognize that several components and/or protocols may be adapted within the scope of the invention for different environments. For example, while CoAP may be used, any of a variety of other protocols may be utilized between an IDL proxy and a requesting device or the IDL in accordance with embodiments of the invention as appropriate to a particular application.

Additional Proxy Services

[00151] In addition to facilitating access to the IDL, the proxy may add information derived from the IDL or other sources that may be interesting for entities that want to query the ledger as this information may provide details, help to build trust or enables additional functionality by the recipient. Examples include:

[00152] - Notification of recipients such as home gateways of status changes for devices in the network managed by the gateway, such as new available software updates, security threats, updates in manuals or usage instructions, warranty limitations [00153] - Information about usage instructions (pdf, video, pictures), availability (where devices can be bought), pricing (comparison of different stores and prices) and user ratings (aggregated or individual descriptions) derived from other databases or derived from online lookup on web-services when the query occurs.

Proxy Analytics

[00154] The proxy may also be used to aggregate data from queries such as:

[00155] - Number of inquiries for a device model to derive how popular a device is, when it first came to marked. This information may be sectioned by region.

[00156] - Popular combinations of device installations

[00157] - Estimate on deployment for devices if commonly activated in batch or individually

[00158] - Frequency of updates for, e.g., devices, documentation software and certifications.

IDL Contents and usage

[00159] In many embodiments of the invention, the information stored in the IDL can be about functionality of a device model such as specified by a product code or SKU (Stock Keeping Unit that identifies a device model) number. These pieces of information can be used to establish trust in a device. Statements about the device can be made from entities such as a Device Manufacturer or compliance organization. Device Manufacturer may be an entity manufacturing the device or ordering and paying for the manufacturing or components thereof. A device model may have different variations and configurations and may also be a component of another device or network. Compliance organization may be industry organizations such as Bluetooth, thread or Zigbee that perform activities such as specify, test and/or certify devices or certifications (such as Τϋν, UL, CE, EMC, FCC and CSA), government bodies, or other parties that may have an interest in or knowledge about the device. They may or may not be associated with the device Manufacturer. This could include companies looking to deploy the devices or individuals and organizations that have an interest in published information about the devices. Information about device models stored as a transaction in an IDL can include, but is not limited to: [00160] - The device model's certification status, including nature, scope, level and validity of certification.

[00161] - Test results from test houses, independent testers or other agencies that evaluated functionality, energy consumption, emissions, or similar properties.

[00162] - Opinions and ratings from users of the device

[00163] - Manufacturer usage description (or MUD) that provides typical use properties and can help to differentiate from abnormal functionality including information like typical memory consumption, processor load, network traffic, operating temperature and other features of input or output.

[00164] - Information about the lasts firmware, its version number, functionality and location to download

[00165] - Security updates and patches to be used, including code

[00166] - Updates on information on known operating risks potential attacks or exploits of the device

[00167] - Instruction on how to use, operate, maintain and install the device

[00168] - Information about the Manufacturer (possibly in levels of components, materials, modules), availability, Manufacturer dates of a batch, sales channel and availability (including pricing and order information that could be updated regularly)

[00169] - Reference and links to other ledgers or records containing any of the above in the IDL or other distributed ledger or database.

[00170] - Links to records about individual devices.

[00171] - Information to allow verification of the entries, such as public keys of parties involved or parties certifying their identity.

[00172] - Links to databases or URL pointing to e.g. internet locations for display or download of the information above

[00173] - Hash code of information which may be retrieved outside of the IDL record.

[00174] -instructions, configuration data, sequence of commands to be executed based on specified triggers [00175] In one embodiment that may use the same or different IDL as above, individual devices are registered, commonly many instances of one model. This allows registration and tracking of individual devices and allow in addition to information about the model, information about the individual device, including:

[00176] - Owner or controller of the device or any of its resources and permissions a controller such as update, revoke or replace certificates, and assign, add, remove other Controllers, Owners or sub controllers. Other rights may include use, disable, enable any resource (incl activity, network access, communication intervals, battery usage, device trust, passwords).

[00177] - Domain and association with the device

[00178] - Rights permissions

[00179] - Location

[00180] - Individual IDs to identify the device

[00181] - Information about Hardware Manufacturer, controller, owner, sub Ctrl.

[00182] - Information about available software updates

[00183] - Information about revoked certs

[00184] - Information about keys, Manufacturer, date

[00185] - Information about how to reach the device and its capabilities may be useful as they include the information relevant for discovery together with information about trust to the device.

[00186] - Links to device model information in IDL , DB or other location and any information from the device model as above

[00187] The ledger information, retrieved directly or indirectly, from the IDL is used to determine the level of trust and resulting interaction by another entity such as another device. Examples for resulting actions include:

[00188] - Establish or terminate communication to the device

[00189] - Trigger updates to the device

[00190] - Receive commands from or send commands to the device

[00191] - Accept device into the network and share network keys [00192] The workflow to register and verify transactions differ between the two mechanisms and are described below.

Management of Device Models

[00193] The IDL can provides information about specific device models. A portion of the model record may be written by the device Manufacturer, while another portion of the record may be written by one or more compliance organizations. In several embodiments, the primary data contained in the model record, is the identity of the Manufacturer, version of firmware, and which compliance certificates the model has achieved.

[00194] Compliance information about device models that benefits from public and automated verification to be registered in the IDL includes applications like certification for a communications or emissions standard, membership of an organization, installation by a certified professional, or delivery through an authorized distribution channel. In some embodiments, the certification is a transaction issued by any certification authority and validity of compliance is established by the trust in the digital signature of the certifying authority. E.g. using prior knowledge by the verifying device of the certifier's public key.

[00195] For example, a gateway could verify that a device complies with a communications standard before allowing it in the network. In this case, the gateway can verify the IDL compliance record using the public key of the compliance certifier. Trust may also be established through extension e.g. by a trust authority that is extended to certificates endorsed by this CA.

[00196] Trust in the compliance record can also extend to the devices listed in it and to the Manufacturer creating these devices so that the Manufacturer description about how to use and update the device is trusted because it comes from a source that's trusted by the compliance organization.

Ledger Interactions

[00197] The basic transactions register compliance of device models and add information to them. A typical workflow as outlined in Fig. 7 starts with a compliance organization (1 ) creating a record of a certified device (2). The compliance can be binary information or include information that provides compliance details, limits and/or conditions. It may also point to a smart contract that can codify the limitations and evaluates the status of the device compliance. The compliance organization can use similar entries to certify compliance of other devices (3). In addition, the compliance organization is also able to manage entries and submit transactions that change or remove the compliance status.

[00198] The Manufacturer (4) can extend the record with information (5) such as the current firmware version and download location for updates.

[00199] Manufacturers and compliance certifiers can also transfer the records to new owners if organizations or responsibilities changes.

[00200] Any verifying systems can now rely on reading the latest certification status of individual device models from the ledger with simple and efficient read operations. In embodiments of the invention that involve compliance certifications of device models, the ledger or IDL can also be referred to as a compliance ledger or compliance IDL.

Use Cases

[00201] Compliance verification of device models can be used in a variety of applications: Ecosystems can verify the compliance to the device safety, security or communications standard before interacting and relying on its security. Ecosystems could include compliance standards for in home control of light or sound, safety systems that are allowed to trigger expensive alarms or can reduce insurance premiums, or devices that need to be relied on for personal health. Monitoring applications can rely on a single source to verify the capability of devices and if a devices' communication behavior complies with the behavior that is registered in the compliance ledger for this device.

[00202] Manufacturers have a location that allows them to communicate firmware updates in an effortless way that is accessible to systems assembled from diverse devices. They are able to maintain security standards that ecosystem or legal regulations require. In addition, they are able to publish Manufacturer usage descriptions that specify a range of expected traffic and would allow monitoring of network traffic to provide extra security against malicious takeover of devices. [00203] With a growing number or certifications, active Manufacturers and registered devices, the trust and reputation of each of these entities increases as they have multiple independent confirmations, such as a device that is trusted to be from the expected Manufacturer as multiple compliance organizations certify it or the Manufacturer that has more credibility if several of its products are certified.

Authenticity of Device Manufacturer and Compliance

[00204] Authenticity of the Device Manufacturer for a specific device model can be achieved by the device Manufacturer programming a model key pair into each device. In many embodiments, the key pair would be common across all instances of the model. However, the Manufacturer may register multiple key pairs per model to reduce the potential exposure if a key pair is extracted by an attacker. The compromised key pair can be retired from use and a different preprogrammed key pair used for the future.

[00205] Prior to production, the Manufacturer generates the key pair and programs the pair into a sample device which is used for compliance testing. The Manufacturer also registers the public key for the model into the Compliance IDL. Once the device has passed compliance testing, and the compliance organization has validated the identity of the Manufacturer, the compliance organization registers the compliance data into the Compliance IDL for the device model.

[00206] During production, the Manufacturer programs the model key pair into each instance of the device. They also may program unique serial numbers per device, which may be used in the cloning use case. The private key must be protected from attacker extraction, as this would allow an attacker to produce clone models. In another embodiment, the manufacturer may generate a certificate for the device, in which a device-specific key pair is signed by the model key pair.

[00207] When the device first communicates on the network through the gateway, the gateway authenticates the model key pair. The gateway then reads the compliance IDL to determine the identity of the Manufacturer, and which compliance testing the device has passed. Based on the rule of the system and information retrieved from the IDL, the gateway puts the device into a whitelist, graylist, or blacklist in many embodiments of the invention. The device may be controlled in different manners based on the list. Device Registration

[00208] A process for device registration using an IDL ledger in accordance with embodiments of the invention is illustrated in Fig. 8. Whenever a new device is connected to a gateway, the service provider/gateway may optionally read the IDL and retrieve (802) the registration URI (uniform resource identifier). The gateway may then attempt to register (804) the device to the owner/gateway by sending a request that identifies the device (e.g., device ID) and the owner/gateway (e.g., user ID) to the registration URI. The registration database would receive the registration request, and if the device has been registered to another owner/user or gateway, the database would return (806) an "already registered" status. This status would then be used to indicate that this device may be a clone, stolen, improperly transferred to another owner, current owner may be attempting to attack the device through multiple registrations. If the device has not been previously registered, it can be registered to the owner/gateway indicated in the request and a status of "successful registration" can be returned.

[00209] Optionally, the owner's contact information could be registered with the device. This information could then be used to send a notification to the owner if another owner is attempting to register the specific device. If the original owner has truly transferred he device, they would be able to approve the registration database update. However, if the transfer is not valid, the gateway would be able to prevent the onboarding of the device to the wrongful owner. Although a specific process for registration is illustrated in Fig. 8, any of a variety of processes may be utilized in accordance with embodiments of the invention.

Firmware Updates

[00210] Device Manufacturers may use the IDL to notify and distribute device model firmware updates. The firmware version number and update URI (uniform resource identifier) are protected from modification by the DLT such that only the Device Manufacturer may modify these fields. Thus this information can be a trusted source for service providers. Whenever a new update is available, the Manufacturer can update post the file to the update URI, and write the new version number to the IDL. The service provider can periodically poll the IDL models which are being managed by their service. Whenever a new version is detected, they retrieve the image from the Manufacturer's update site. They may optionally perform regression testing of the image, and then push the image to all impacted gateways and devices.

[00211] A change to the IDL virtual machine running the smart contract could be made to allow the contract to send a notification of change in firmware versions to a list of subscribers. This would remove the requirement of the subscribers to poll the smart contract for updates.

[00212] Another variant of a notification system would include the monitoring of the blocks and transactions being distributed throughout the IDL network. The transactions include the contract ID (Address), Manufacturer ID (Address), and the raw input data to the contract. A process running on the service provider's ledger node could monitor this information to determine when the firmware version update function in the smart contract has been evoked, and then generate the appropriate actions.

Image signature

[00213] Signing of images for use with secure boot typically involves two keys: a signing key and a verification key. In several embodiments, the signing key is secret and held by the signer of the images, but the verification key must be immutable and accessible by the device. The verification key may be stored in the IDL with write access limited to the signing entity.

[00214] In many business arrangements, there are at least three entities: supplier, customer, and arbiter. The signing key could be encrypted and stored in the compliance IDL with the encryption key (used to encrypt the signing key) held by both the supplier and arbiter. If the supplier goes out of business, or meets a predefined condition for transfer of the signing key to the customer, the supplier may send the encryption key to the customer. However, if the transfer of the encryption key is not agreed upon by the supplier, the transaction may be moved to the arbiter. Based on the outcome of arbitration, the arbiter may release the encryption key to the supplier.

[00215] Another improvement to the single arbiter model would be a distributed arbitration model in which multiple nodes in the IDL system would hold portions of the encryption key. Based on a set of actions and potential payments, the customer may be granted the entire key by accessing the nodes holding all the portions.

Authenticity of public key/ID

[00216] In several embodiments, prior to using the public key from a device to reference data in the IDL, the gateway (or link partner) must authenticate the public key being presented. This authentication process may follow a sequence similar to a TLS (Transport Layer Security) handshake, in which ethereal data is transferred between the link partners to validate that the device presenting the public key truly holds the private key. Further, a certificate may be passed from the device to the gateway, which may contain conditions in which the public key may be trusted. For example, the certificate may include an expiration date.

[00217] When a user of the IDL is writing data into the smart contract, the DLT can validate that the user holds the private key and password for the public key being presented. However, the smart contract uses the authenticated ID to then provide protection of data field associated with the device model. For example, once a device model has been registered by a Manufacturer, the Manufacturer's ID is stored in the model number's record. Whenever a request to change data in the record, which is controlled by the Manufacturer, is received the smart contract authenticated ID is compared with the stored Manufacturer's ID and rejected if the IDs do not match.

Variations

Approved compliance labs ledger

[00218] An approved labs record on the IDL could be used to manage which test labs are approved to issue a stamp of compliance to device models. The compliance organization would have write/delete access to the list of public keys (or IDs) of approved labs. A gateway/service provider would first read the IDL to determine which lab has confirmed the compliance of the device model. The gateway would then read the approved labs record to determine if the lab has truly been approved to issue the stamp of compliance. Business uses of Compliance information

[00219] The authenticity and compliance status of customer deployed devices may be used by a business to adjust pricing and features. For example, an insurance company may reduce premiums for auto insurance if the customer's cars contain safety devices which have passed specific compliance testing. Service providers may allow a limited number of non-compliant or authentic device into their network based on fees paid by the consumer. Another business model may adjust rebates or warranty agreements based on the inclusion of non-compliant devices on the managed network.

Black/White/Gray List operation

[00220] In managed ecosystems, specific model numbers are allowed into the network. The condition of acceptance into the network may solely be based on compliance to at least one standard. The IDL provides a means to identify the model number, Manufacturer, and state of compliance for each model being enrolled by the end user into the network. A white list may be, for example, an explicit list of model numbers allowed onto the network or a set of conditions which the model number must meet to be allowed onto the network. The conditions may be a combination of information contained in the IDL and/or local rules embedded in the gateway (or backend cloud server).

[00221] A model on the blacklist could be rejected access onto the network based on, for example, an explicit list of model numbers or lack of compliance to at least one standard. The model may also be rejected based on a combination of data from the IDL and conditions determined by the gateway or backend servers.

[00222] A model on the gray list could be granted limited access to the network. For example, a device which has not passed compliance may be allowed onto a home network and used for lifestyle operations, but not life safety operations. For example, a motion sensor that has not passed compliance testing might be able to turn on a light when motion is detected, but not trigger the home security system when motion is detected.

[00223] Another variant of the gray list, would be grouping of devices based on the IDL information. For example, the device may be placed in a lighting group, or an egress group. The device would be allowed to communicate with other devices inside its group, such as light switches could communicate with light bulbs when both are included in the lighting group. However, light switches would be prevented from communicating with door locks when each are in different groups.

[00224] The meta data associated with attachment of a compliance organization's ID into the device model record, may include conditions or details regarding the specific compliance in which the model has passed. For example, a compliance lab may attach a condition that the compliance test was only approved for deployments in a specific geographic region. Another condition which may be recorded is a time period in which the compliance is valid. At which point, the Manufacturer may be required to submit another model to the compliance organization for updated testing and recertification. Other conditions may include information such as compliance valid only when the device is used with other compliant devices.

Store X.509 certificate data in ledger to save bandwidth

[00225] In some embodiments, the IDL simply stores the model public key. However, some devices may have limited resources, such as being on constrained networks, or have constrained memory. For those situations, the X.509 certificate could also be stored in the IDL. The gateway in which the device is trying to join, could use the verified public key from the device to then retrieve the certificate from the IDL. The gateway would be able to benefit from a full certificate, while the constrained device/network would not be required to store and transmit the full certificate.

[00226] The certificate could be refreshed by the Manufacturer, certificate management service, or service provider based on access rules configured in the IDL.

Identification of a Device

[00227] Devices can use a device identifier (ID) to establish their uniqueness. This allows the system to:

• trace the history (through a sequence of different registration of the same device ID in different contexts, from different locations or users). • identify previous use if the device ID has been registered before

• identify the device for security reasons to make sure it is unique and has not been copied, i.e., cloned

• Cross reference known device IDs to registered device IDs to make sure that the devices are authentic by knowing the device IDs of Manufactured IDs and registered IDs to identify fakes with a mismatch.

[00228] In various embodiments of the invention, device IDs can be derived from any of:

- Serial ID, of any device component

- including wifi module, security chip or module, key ID, graphics card, IDs for other connectors or network modules

- MAC address

- ID from secure element

- Registration information

- including registration location, network, surrounding and environment (incl measures of other networks, radio signals, visual or audible environment)

- IDs associated with purchase record from different resellers

- Hash of hardware configuration

- any other information that results from inconsistencies in Manufacturer process and: is long enough to be likely unique, can be transformed into stable consistent information, and includes imperfections in a printed pattern, e.g., on box, variations in power consumption, errors or imperfections from HD or memory read.

Sequence Description

[00229] A sequence diagram illustrating a process for incorporating information about a particular device into the IDL is shown in FIG. 9. The process 900 includes a new device model being provisioned (901 ) by the Device Manufacturer. In several embodiments, the device model is assigned a number identifying the device model (device model ID), such as a SKU, and in some embodiments could also be assigned a public-private key pair (device model public key and device model private key). The device model ID and/or public-private key pair can be used to identify the device and if embedded in the device could also be used to authenticate itself. The key pairs may be endorsed by other entities such as a Manufacturer, using certificates. In some embodiments, the key pair is exclusive to the device model and the device may only store a private key unique to the specific device (device-specific private key of a device- specific public-private key pair) that is endorsed by the model key, using a certificate, and not store the device model private key itself. Allowing the device to authenticate itself without the need to store the device model private key reduces the risk of the device model private key being compromised. In some embodiments, a particular instance of a device can be assigned an loT device identifier that uniquely identifies that instance of the device.

[00230] In other embodiments, the device model is first submitted to the ledger by a compliance organization that creates the record and then allowing the known device manufacturer to contribute by adding information about the device model.

[00231] Next the device and its device model identifier (ID) including the public key is registered (902) in the IDL. In some embodiments this is done from the Device Manufacturer but in some embodiments it could also be from another known source, such as compliance organization (e.g., Zigbee alliance). In various embodiments, the registration can include writing any or all of: the device model ID, the manufacturer ID (unique identifier for the manufacturer of the device), clone URI (address where clone database may be found), firmware version, and/or firmware URI (address where firmware may be accessed).

[00232] The compliance organization may enter a statement 903 about this device model, using its own credentials, to the IDL.

[00233] The device public key that is unique to the device may be written 904 to a clone database by the device manufacturer. While it may be written to the IDL, a separate database may be faster, easier to maintain and better able to protect the data of, e.g., the manufactured quantity.

[00234] The Manufacturer may also register the availability of the current firmware image known in the IDL. This can be repeated for any firmware update.

[00235] The device may try to start joining and request a network credentials from the gateway it can reach in order to join the network (905), for example, when it is sold and installed by an end user. Network credentials can include a network key, security password, and/or other credential that allows the device to connect to the network (e.g., a local network or subnet). It can provide (906) the certificates that prove its identity to the gateway and the gateway can now verify its identity and look up (907) other trustworthy information stored in the IDL (for example: manufacturer ID, clone URI, firmware version, firmware URI, and/or compliance information). Using this retrieved information about the device, the gateway can decide if the device is allowed to join the network and what rights it will be granted. It can also verify (908) with the clone DB whether another device has already been registered with the same identification (certificates) and, if that is the case, conclude that a clone exists, deny the device access to the network, and warn the user. If all verifications are satisfactory, the network key is provided (909) to the device either immediately or after installation of the latest firmware update (910).

[00236] Although a specific sequence diagram is discussed above with respect to FIG. 9, one skilled in the art will recognize that variations may be made within various embodiments of the invention that may omit or modify certain parts as appropriate to a particular application.

Selected Workflows

[00237] The following workflows are examples for execution of use cases and interactions with the IDL. They may be under the condition of verification of authority of the contributor and may require a fee that is provided in order for the transactions to be executed. For read access no gas fees may be charged even if these are required for writing to the ledger.

Manufacturer set up

[00238] Manufacturer prepares to join IDL network. In this embodiment, the Manufacturer becomes the holder of their credentials, and directly accesses the ledger. It may involve the following steps:

• The Manufacturer downloads the DLT fabric onto their computer from the DLT repository, creates an account with locally stored wallet (thereby creating the credentials), and follows the directions from the IDL repository to access the smart contract. • The Manufacturer acquires tokens or requests authority to contribute to the ledger.

Registration of model number

[00239] In one embodiment, the Manufacturer submits a new model into the IDL. The model may or may not be compliant to any compliance organization. In this use case the Manufacturer holds their credentials and directly accesses the IDL. In another embodiment, the compliance organization submits models it certified and allows Manufacturers to apply additional statements to it. It may involve the following steps:

• The Manufacturer or compliance organization connects to the smart contract (ledger) and submits the data for a new model number.

• The compliance smart contract (ledger) verifies the device model identifier has not already been claimed by a Manufacturer.

• The model information is written into the smart contract, and the Manufacturer account number is saved to the model record.

Manufacturer identity is transferred

[00240] In some embodiments, the Manufacturer identifier is transferred to a new Manufacturer identifier for a model record. This embodiment may cover the transfer from a proxy hosted Manufacturer identifier to a privately held Manufacturer identifier, or the transfer to a new identifier held by the Manufacturer. This may include the steps of:

• Original owner calls the transfer Manufacturer identity function in the Compliance Block network with the new Manufacturer identifier.

• IDL verifies that the device model record is registered to the original owner's identifier, performs the transfer, and charges the gas fees to the original owner.

Compliance organization identity is transferred

[00241] In some embodiments, the compliance identifier can be transferred to a new compliance identifier for a device model record. A compliance identifier can be a unique identifier specifying a standard or certification governed by a compliance organization. In this embodiment the compliance organization holds their credentials and directly access the IDL. This may include the steps of: • Original owner calls the transfer compliance identity function in the IDL network with the new compliance identifier.

• IDL verifies that the device model record is registered to the original owner's identifier, performs the transfer.

Compliance organization applies meta data to a model record

[00242] In some embodiments, a Manufacturer submits passing test results for a model number to a compliance organization. The compliance organization then applies their identifier and compliance specific meta data into the IDL for the specific device model record. In this embodiment the compliance organization holds their credentials and directly accesses the IDL. This may include the steps of:

• Manufacturer submits all supporting data required by the compliance organization for a specific model number. This transfer of data does not occur through the IDL. In further embodiments, the data shall also include the hash of the Manufacturer's identifier and hash of the device model identifier.

• The compliance organization submits the meta data associated with the compliance of the model record, along with the compliance organization's identifier into the IDL.

• The IDL either creates a new compliance entry for the device model record if the compliance identifier has not already been applied to the device model record. Otherwise, the IDL will replace the old meta data with the new meta data if the compliance identifier has already been registered with the device model record

Manufacturer updates model record

[00243] In some embodiments, the Manufacturer of the device model record can change at least one data field in the device model record in the ledger which is only writeable by the Manufacturer. In this use case, the Manufacturer holds the credentials, and directly access the IDL. This may include the steps of:

• Manufacturer provides the Manufacturer's portion of the device model record to the IDL smart contract functionality to update Manufacturer. • The IDL validates that the model record is currently assigned to the Manufacturer making the request.

• The IDL modifies the data, and charges the gas fee to the Manufacturer making the request.

Compliance organization updates meta data for a model record

[00244] In some embodiments, the compliance organization changes at least one data field which is only writable by the compliance organization. In this embodiment, the compliance organization holds the credentials, and directly access the IDL. This may include the steps of:

• Compliance organization provides the compliance organization's portion of the device model record to the IDL's update compliance API.

• The IDL validates that the model record is currently assigned to the compliance organization making the request.

• The IDL modifies the data, and charges the gas fee to the compliance organization making the request.

Manufacturer issues firmware update

[00245] In some embodiments, the Manufacturer produces new firmware, which needs to be certified by the compliance organization, and then releases it to the ledger. In this embodiment, the Manufacturer holds the credentials to directly access the ledger. Further, this use case describes how an ecosystem operator may receive the update information, and then pull the firmware for their deployment process. This may include the steps of:

• The Manufacturer and compliance organization have registered and certified the initial device.

• The ecosystem operator has a process in which they periodically access the IDL for the model records which are active in their ecosystem.

• The Manufacturer produces a new firmware image.

• The Manufacturer registers the firmware image number in the latest Manufacturer data field in the IDL. • The Manufacturer submits the latest compliance test results to the compliance organization.

• The compliance organization validates compliance, and then updates the latest certified firmware version in the compliance organizations data fields of the model record. The IDL charges the compliance organization gas fees for the modifications.

• The ecosystem operator detects the change in the latest compliant version, and retrieves the firmware image from the Manufacturer's supplied firmware update link in the IDL.

Ecosystem operator joins compliance network

[00246] Certain embodiments describe how an ecosystem operator may join the IDL, which provides direct access to the public Manufacturer and compliance organization's data fields in the model record. Further, the operator's node would participate as a miner. This may involve the steps of:

• The Ecosystem operator installs the node and genesis block.

• The node will periodically synchronize the data and transactions between all IDL nodes.

• The node may operator on a lossy network, in which it would synchronize whenever connected back to the internet. However, the status would be readable when disconnected from the network.

Ecosystem operator verifies compliance status of a device

[00247] In some embodiments, an ecosystem operator has a node running on the IDL. The node may be running in a gateway, or in the cloud connected to the operator's device onboarding services. As a new device is entering the network, the ecosystem operator verifies the status of compliance, and either fully allows the device onto the network (Whitelist), fully blocks access (Block List), or allows limited functionality (Gray list). This may involve the steps of:

• The device starts to join the network, and is detected by the onboarding service of the ecosystem. • The onboarding service retrieves the model identifier from the device either through an asymmetric key exchange, in which the public key is the model identifier, or through a hashing of the device Manufacturer name and model number provided by the device.

• The model identifier is then sent to the IDL node, which performs a compliance read of the model identifier.

• The onboarding service determines if the device should be whitelisted, blacklisted, or gray listed based on the data contained in the model record.

Ledger access through a proxy

[00248] In certain embodiments, participants create an account through a proxy service. The proxy service can maintain the security credentials for them, and perform their transactions in their behalf. This may include a creation of a unique public-private key pair that is used on behalf of the participant.

[00249] Transactions may include any of the embodiments above and mentioned workflows. Additional information and analysis may be provided as mentioned above.

Management of Individual Devices

[00250] In several embodiments, the IDL is a distributed trusted database that contains information about a registered device, their resources and trust relationships such as an associated controller that is in control of a device or some of the device's resources. When multiple resources are controlled by the same controller, then they are trusted and e.g. allowed to communicate and receive instructions or information from each other as they are part of the same domain in which devices are trusted.

[00251] The IDL records a trust relationship, and then validates the registration through the distributed consensus mechanism. This way, trust relationships can be established without the need for a monopolistic entity that determines the ledger status. Thus, trust between devices can be established without a central entity and thus ecosystems for which collaborations are otherwise hindered by the lack of trust in each other can use this role based ledger to allow trust between their devices - across ecosystem boundaries. A diagram showing a process for providing a network-connected device with access to a network-connected resource in accordance with several embodiments of the invention is illustrated in Fig. 10.

[00252] While a bidirectional trust relationship can be useful, a unidirectional relationship often allows for more control. In this case, two different components of loT devices are registered in the ledger: Resources, i.e., services that a device is offering, like opening a lock or notification of detected motion (e.g., camera 1 in Fig. 10) and Clients that are consumers of Resources (e.g., monitor 4 in Fig. 10). Also present are Owners or Controller, often representing a physical person that is controlling a Resource using an access controller device.

[00253] Trust starts with the simple registration that a Resource trusts a Controller (Fig. 10, 1 ), which is then registered in the ledger. The trusted Controller can extend the trust to Clients, with this relationship also being stored in the ledger (Fig. 10, 4). Whenever the Resource receives a request from a Client, the ledger is queried to determine if there is a trusted relationship with the Client.

[00254] Further, an Owner may extend the Resource's trust to other Owners (Fig. 10, 2). Thus, allowing for shared ownership or complete transfer of ownership of this Resource.

[00255] Secure communication is enabled as the ledger also serves as a public key registry. Public visibility in the ledger and persistence enhances security since device status can be easily observed. Personal information does not need to be published, thus maintaining privacy.

[00256] The loT distributed ledger can be optimized to reduce the complexity and power consumption for devices, as they only need to perform ledger lookups. Owners perform all transactions, which require registration into the ledger and could require more complexity. In order to allow complex control structures the trust relationship can be applied on the Resource level where device Resources can verify trust in connecting Clients.

Ledger Interactions Overview

[00257] In many embodiments of the invention, the ledger is used to register trust relationships of one entity in another. The trust can be represented by a link that is secured by using an identifying secret (e.g., a private key) to endorse another ID (e.g., a public key). This simple concept can be implemented securely and enables many different use cases.

[00258] The actors in the ledger can be referred to as Resources, Owners/Controllers, Clients, and Certifiers. A device often includes multiple resources, or roles in an loT network. Further, resource level rights can provide a more direct mapping to legacy access list systems. In several embodiments, trust relationships are formed around the Resource. The owner of a Resource may represent more than one physical person. Owners can then extend trust to devices referred to as Clients, which may then access the Resource. Finally, Certifiers (Fig. 10, 7) are entities which may place their stamp of approval on the Resource by certifying it. The certification may carry different meaning based on the Resource and the Certifier. Certification may be the compliance organization that extends certification of models to individual devices but, since every device is registered individually it also allows for statements about this specific device, including supply chain, point and time of sale, installation details (time, installer, location) and certification of a network (or environment such as a building) that this device is in (Fig. 10, 6).

[00259] In the registration process, a device extends trust of a Resource to an Owner (1 ), who then extends trust to a Client (4). For example, a camera has a resource that serves a video stream. The video stream resource initially trusts an Owner (1 ). The Owner then extends the video steam resource's trust to a video monitor (4). When the video monitor requests the video stream, the camera queries the ledger and verifies that the video monitor is trusted to view the video stream (8). In some embodiments, the camera may not be required to verify that it is trusting the camera but may have the functionality to consume content from any device.

[00260] The initial trust of an Owner by a Resource can be established by the Resource endorsing the Owner - a transaction that is only necessary to be performed once per Resource. E.g., the Owner's public key is signed by the resource's private key. The initial owner can vary as described below.

[00261] An Owner may extend the trust of the resource to other Owners (2), thus enabling multiple Owners to edit the list of trusted Clients for this resource. To remove an Owner, she must relinquish ownership (3). These two operations enable multiple owners, Resource transfer from one owner to another owner, and/or the release of all ownership of a Resource.

[00262] The Clients that are connected to a resource can be in a different location and they are not required to be controlled by the Owner of the resource. However, only the Resource Owner is allowed to modify the Resource's client list. Further, each Client may have a different set of access rights associated with the Resource.

[00263] The certifier list provides a means for any third party certifiers to place a stamp of approval on the resource (6) and only this certifier may remove their own certification (7). The meaning and use of the certification can be used outside the ledger, as it does not directly impact the trust model between the resource, owner, and client.

[00264] Meta data may also be associated with any of the Resource, each Client, and/or the certification. The creation of Resource and Client meta data is restricted to the owner of the Resource, with the ledger transaction fees being paid by the submitter. The creation of the certification's meta data is restricted to the certifier. However, the reading of the data is often unrestricted.

[00265] In summary, interactions with the ledger can include the following actors and transactions:

Actor Action Nr Comment

Resourc Extend trust to initial (1 ) (Registered by Owner)

e owner

Owner Add new owner (2)

Relinquish ownership (3)

Extend trust to a client (4)

device

Remove trust to client (5)

device

Certifier Certify device model (6)

Remove certification of (7)

device model

Client Request access to (8) (Lookup only - not registered in ledger) resource Use Cases

Access Control

[00266] Certain embodiments of the present invention can limit the access to a device, resource or resource functionality with the trusted ledger allowing only trusted devices access to a network or resource. Functionality like access control can also be made available at a corporation from multiple entities only, e.g., firmware upgrade may require consent from Manufacturer and owner, i.e., two controllers need to cryptographically consent.

Right Encoded in Ledger Represents Device or Resource Control

[00267] The token in ledger could represent a device, i.e. this will establish trust to another device. E.g. a trusted entity (controller), as encoded in the ledger can give instructions to the device. The entity may be a person or device or application logic

(mobile app).

[00268] In another embodiment, the token may represent a resource, i.e. this will establish trust to control a resource of a device, e.g. different tokens for the same device to manage control over firmware upgrade instructions and instructions to perform an action e.g. turn on light. The association may also have a finer control than that, i.e. associating a controller with an action to a resource, incl read, write, modify, update, remove.

Device Registration

[00269] In many embodiments of the invention, the resource is made known to the ledger with a registration process where the identity is stored. This may be performed with making an identifier public, such as a public key.

[00270] The registration can also include a proof of the possession of the private key such as, e.g., signed public key. This may be done to prevent others from trying to register devices quickly after the first registration to obscure the registration, since the concurrency is not certain for small time resolutions, someone could observe a registration and register the same device with a chance of her second registration being included first. Registration of other information may also occur.

[00271] Registration may be performed by the Owners or other entities. Components could register explicitly or with the first transaction they are included in. Link Owner to Device

[00272] This transaction links a device (or resource or resource function) to a person (or other controlling entity). This can be done by the device cryptographically endorsing the owner, e.g. by signing a transaction including the owner's public key in the ledger.

Owner Change

[00273] The current owner has the ability to give up ownership by signing a corresponding transaction into the ledger. She also has the ability (could be in addition to the device) to create a new device owner. This could be done by passing a token (e.g. parts of cryptocurrency) or signing a transaction including a public key of an additional owner / controller.

[00274] The combination of relinquishing and creating new ownership can be combined to pass on ownership - alternatively it can be done explicitly.

[00275] Variations include Controllers that have different status such that only some can create new controllers / owners and can revoke rights as well.

[00276] Transactions may also encode a time limit to limit the controller access in time, useful for example for rental use cases. Alternatives for limited access are use of certificates that have an expiration time.

Implementation Details

Secure Communication

[00277] In several embodiments of the invention, secure communication is enabled with availability of public keys of all devices to send them confidential messages and certified trust including some age established by signed associations.

[00278] In some embodiments, messages to a group can be enabled with messages encrypted with multiple keys to communicate information about a device to authorized devices only.

[00279] For example, a device can find a list of trusted devices, e.g., by finding all devices controlled by its controller and leaving a message for them exclusively by encrypting it in a way that only accessible to those authorized devices (those controlled by the same controller), e.g., by encrypting a secret shared key to the message with public key of each trusted device. The message may contain information like how to reach devices, join the network, network maintenance information including passwords for individual devices, network or device status information and/or other information relevant for other devices or the controller.

Device rights connected to authentication service

[00280] To reduce the addition of new messages required for a device to participate in the device rights system, certificate management protocols could be connected into the rights system. Specifically, an example is the Online Certificate Status Protocol (OCSP) that provides an interface between a device and the certificate authority for the device to verify that a second device trying to communicate with the first device using the second device's certificate is still valid. If the certificate is not valid, then the OCSP protocol will return an invalid certificate message. If this request were to be processed by the device rights system, the system could return success if both device have the same controller, or invalid certificate if they do not share a common controller. This method has the advantage of not needing new interfaces to be coded for each device. However, it has the limitation that the access would be at a device level, as the resource information may not be known at the time of the initial TLS/DTLS handshake.

Device Identity

[00281] The identification registered in the ledger is pseudonymous i.e. not associated with other information about the device but the same identifier is used for the same device. I.e. the device is registered in the ledger, e.g. by public key that allows the device to prove its association and can be made public by publishing meta data about the registered device.

[00282] E.g. the device registers a public key to the public ledger. While this is observable and permanent, there is no other information about the device required, such as its brand, certifications status, location or status. However these other pieces of information may be published to allow some use cases:

[00283] Device recognition: a standardized name of the device (or resource) could be used to enable lookup of characteristics, such as its capabilities, allowed actions, mandatory properties and/or resources.

[00284] Certification in ecosystem: a certification verifying implementation standards may be expressed by a public transaction in the ledger, e.g., certificate authority is using signing device ID making the cert public and observable. This includes other devices that may require only talking to certified devices.

[00285] Anti-cloning: Hardware Manufacturer can publish a list of all unique ids of devices that it Manufactured. In this way, the brand becomes publicly identifiable.

[00286] For many embodiments it can be desirable that the Manufacturer is now known, e.g., for privacy reasons. While the Hardware Manufacturer may have the information on all devices it may be protected, e.g., destroyed. The device however may have an ability to reveal and prove its origin by, e.g., showing a Hardware Manufacturer signature of its certificate to controllers.

[00287] In order to renew a device identity, its existing ledger entry may be abandoned by ceasing to use it or explicitly transferring it. A device can create a new identify and register again. This may occur with proof of physical possession of the device, e.g., interaction such as button press or near field communication or by reading information on the device, e.g., barcode or printed password or serial number or something displayed on a screen or combination thereof.

Upgrades

[00288] Devices sometimes need software updates for improved functionality and security. Updates are a source of possible attacks and may only come from trusted sources. If encoded in a distributed ledger, a central repository could flag available upgrades. This could also be associated with the device controller, for example whenever a device has an update available the controller sets a flag and possibly location. When device scans ledger it knows of update allowing notification without requiring the ability to actively notify the device, preserving the device privacy.

[00289] A convention could also be established that the device trusts updates from its first controller, assuming this is a Hardware Manufacturer or trusted entity or that the current controller registers consent in the IDL, e.g., with including the Manufacturer in the trusted domain for the device update resource.

[00290] The Hardware Manufacturer here may have established a different controller for each device, model or make. The association may also be established in connection with records about the device model that may be registered in the IDL. Revocation

[00291] In many embodiments, revocation can be done by stopping control of the device identity in the ledger. The Hardware Manufacturer could notify current controllers of the device to stop using it. The device could also be explicitly set to a controller without controlling entity, e.g. 0, such that it's public that the device id can no longer be controlled.

[00292] This revocation may also be used in reverse logistics to prove a device has been disabled as a requirement for refund. Revocation could be enabled with expiration date in certificate. Any of these methods can be used to enable temporary domains, e.g., rental that foresee a revocation after a predetermined time.

Ownership Controlling

[00293] The proof of owning or controlling the device can be proven by the registered association with the device / resource to the owner / controller in a transaction (e.g., loT device record) in the ledger. This may be by a signature by the private key in the device to the public key of the owner. Subsequently the owner may include controllers or owners by signing their keys in a defined transaction.

[00294] In some embodiments, a method for ownership transfer includes also creating another owner and relinquishing control implicit or explicitly.

[00295] In some situations, a device may be owned by one party, and controlled by another. A set top box is an example of this type of arrangement. The cable company owns the device, and the home owner is the controller. There are at least two methods to address this business model. In the first, the device would have two resource groups, with the cable company being the controller of one set of resources, while the end user would be the controller of the second set of resources. The resource which allows the creation of controllers and assignment of resource rights would only be controlled by the cable companies group.

[00296] The second method is for the ledger to add the concept of an owner. The owner would have the ability to allow controllers to be added, and resources to be allowed. The primary difference is that only the owner has the ability to transfer ownership to another owner. [00297] Devices may come from different eco systems and have still means to establish a common trust base. They may be grouped into domains and be controlled by different entities such as landlord, building owner, monitoring and security company, renter, building user such as employee, financing entity such as a bank providing a loan to allow different use cases such as switching off devices to save energy, switching devices on after alarm, controlling access during off hours, limiting device use to known devices, granting limited building access to individuals or companies, analyzing past building access and device usage. In another use case, the service provider may have access to specific resources, such as a kill switch, which only the service provider can toggle based on the end customer's billing status.

Initial Controller

[00298] The initial control or ownership of a device may be by one of the following entities: Manufacturer, Device, Retailer, Service Provider, cloud provider, installer or end user. The easiest form of initial control is for the Manufacturer to claim control. This has the advantage of proving the authenticity of the Manufacturer of a device. For example, Philips could be the initial controller for their light bulbs they manufactured. Then any future controller of the device could access the ledger, and verify that the device truly was produced by Phillips, and not counterfeit. The Manufacturer or the device would then have a method for the next controller in the chain of control to be issued control of the device (e.g. retailer, installer or end user). A slight variation of this method is for the Manufacturer to create a Manufacturer control group per device model number. This provides the ability for Manufacturer to query the ledger and identify all current controllers of a specific model number, which is useful for firmware upgrades, recalls, or targeted marketing messages. In this model, quantities of device manufactured by a specific Manufacturer, or model number may become public knowledge. Further, Manufacturers that license their brand and don't want to reveal device origin may choose not to release their ID, and thus a consumer would not be able to determine the true Manufacturer of products.

[00299] Assigning control of the device to the device itself is a method to address the desire of a Manufacturer to remain anonymous or to ensure no further involvement is required. In this case, the number of initial controllers will be the number of devices, and thus determining the number of devices a Manufacturer produced would be masked. Setting control of the device to the device is preferable over setting the control to null, as it would leave the initial control vulnerable to an attacker identifying null controllers and then attempting to gain control of those devices. In this case, the device may have the cryptographic ability to transfer control from itself to a new controller.

[00300] Alternatively, the device may store a transaction of initial claiming the device by the manufacturer that is cryptographically prepared and ready to be submitted to the ledger. In many embodiments, this would be submitted on first use of the device. Other means to hide the Manufacturers identity is by using multiple keys possibly one per device, making analysis of the key origin harder and does not allow conclusion about origin from one device key to another. The origin of the key can still be queried by individual devices if signed by a known manufacturer key. However, this endorsement (e.g., as certificate) is not required to be stored on the ledger but could be separately on the device or available for lookup provided by a database filled by the Manufacturer.

[00301] In many instances, the service provider for the device is known at the time of manufacturing. A service provider could be an organization, which is providing services in which the device participates. In several embodiments, the service provider typically provides a cloud service, and/or mobile phone control of the devices in the supported ecosystem. The service provider may also wish to retain some control, which is described in the service provider section. For these devices, the Manufacturer could issue initial control to the service provider if they were given the appropriate credentials, or they could use one of the above initial control methods, but transfer control to the service provider some time prior to the device being received by the service provider.

[00302] In some instances, the Manufacturer may have a direct relationship with the wholesaler, retailer or end user who receives the device. In these cases, the Manufacturer could transfer control along with the device.

[00303] Control transfer (e.g. from a Manufacturer) may be automated, if the receiver can provide proof of possession of the device, e.g., using a token, which could be located on or in the device using a number, barcode or signal other means for readout. The receiver may issue a token to the Manufacturer, who then populates the device ID, and then transfers the token back to the end controller. It may also be performed in batch.

Transfer of control

[00304] There are two possible methods to store control in accordance with embodiments of the invention. In one embodiment, a token representing the device would be passed to the controller. Any holder of the token would have control over the device. A controller could also issue sub-tokens to other controllers who would then also have control of the device. In another embodiment, the device would hold a set of tokens for each controller. A controller of a device could then grant other controllers the ability to control the device. If the controller wishes to sell the device, they would add the new controller to the device list, and then remove their token. There are several permutations of these methods, which optimizes different operations with the ledger. For example, when the device holds the list of controllers, the search for a device's own controller is quick. However, finding other devices with the same controller would increase. However, transfer of rights become more difficult when the device maintains the list of controllers, as this creates a one deep relationship with the device and controller. In other words, controllers transferring to controllers directly would not be allowed.

Privacy

[00305] Knowledge of and about the device is often helpful but can in some instances also be harmful, where privacy is negatively affected. For example, it is useful for a Manufacturer to know where its devices are, to offer maintenance and improve its services but can be harmful if outsiders can identify the location of devices in a given location as this may be a first step in a digital or physical attack. Depending on the use case, the fitting trade-off between privacy and usefulness can be determined. These use cases may by be cryptographically enabled and secured:

[00306] While the association of devices (domain) by a controller can be observed publicly, this information may only reveal the number of connected resources and may maintain privacy because information about their type, activity and location is not available. [00307] Note that even the activity of domain lookup is anonymous when a query is applied to one of many databases and the information interesting to the reader is not clear from the data read from the database.

[00308] The Manufacturer can create a different owner for each device. I.e. the Manufacturer does not have to initially register the device to a single controller (although that may be useful in some cases). If individual instances are used any owner of the device cannot learn about other owners or the amount of devices Manufactured, i.e., the device count and amount remain confidential although individual associations are public.

[00309] Similarly the Manufacturer may maintain a list of the devices manufactured but can also destroy the list to protect the association and aggregation information. The Manufacturer may want to maintain a way of contacting and querying every device (for intelligence or services) but could alternatively leave a message in the ledger for the device such that the device can query for existing messages. Since anyone could do that query and a decentralized database means there are several locations to query, this query cannot be associated easily with the device and anonymity can be preserved.

[00310] Another embodiment utilizes group keys from using a Direct Anonymous Attestation (DAA) algorithm (or the EPID version that Intel has developed). It is a digital signature algorithm supporting anonymity by providing a common group public verification key associated with several unique private keys. DAA can be used such that a device can prove it is an authentic model without revealing an ID that is specific to this device.

[00311] Zero knowledge proof algorithms may be used that allow for verification of a fact without requiring any additional information as proof. In this case a device may prove that is certified, from a certified manufacturer or has mutual ownership with another device without being required to reveal the device model, manufacturer or owner respectively.

[00312] To limit the availability of information about the device (e.g., make and/or model) the device may store this information and proof thereof (e.g. Manufacturer signature of device public key or model information) and sending info to the owner only. This communication may be secure by encrypting with owner public key (as determined by IDL lookup) so only the controller can read it. This may also be published and updated accordingly and used for other information, such as analytics, i.e., information that leaves the device is encrypted with (a subset of the) public keys of the controllers.

[00313] In further embodiments, the association between the hardware Manufacturer and device can be used to prevent counterfeiting. E.g. where a brand name is used illegally. Prevention can be enforced when the association is cryptographically secured, publicly for verification for anyone or privately for verification by a limited set of entities, e.g., any controller.

[00314] Access to the ledger may be via networks enabling anonymous communication like TOR by the Tor Project using onion routing, the relevant portions of which are hereby incorporated by reference.

Controller / Owner

[00315] The role of the associated controller may differ, depending on authorized actions, including combinations of:

• a controller may send commands to the device

• a controller may assign control or revoke control from others

• a controller may relinquish control

• a sub-controller may have received limited (in time, actions count or commands nature) control

[00316] The device may be the controller e.g. after initial provisioning or when the control is returned back to the device to be sold or stored. This could be a temporary indication that the device is without controller.

Domains

[00317] In several embodiments, trust between devices is established if they are part of the same domain. The domain can be established by devices that share a controller. For example, if devices are controlled by the same entity they assume they can accept commands from each other.

[00318] The domain may be limited to selected devices and resources out of a total network and a physical controller (person) may have control over several domains. [00319] Domains can be managed for temporary lengths of time, i.e. for an afternoon to enable communication limited in time and can be merged or split depending on demand. This may be managed by individuals or in an automated way.

Application Examples

loT Smart Home

[00320] Devices in a home that may need to have a trusted communication enables use cases such as:

• Lighting control

• Energy management with appliances and climate control

• Smart notification for watch or cell phone

• Fire safety monitor and notify

• Keyless entry

• Health and security monitor and notify

• Analytics and consumption display and notification

• Appliance ordering supplies, e.g. fridge re-ordering milk if it's connected to a trusted retailer

• Appliance checking its warranty if connected to Manufacturer who doesn't need to know the appliance location or status.

[00321] Including virtual and physical devices assembled from any of the above.

Firmware updates

[00322] Firmware update interfaces could be represented as a resource, and have a firmware update service as a controller of the resource. This update service could be managed by the Manufacturer, service provider, or industry alliance. Whenever devices need to be updated, the service could either directly issue the update, or use a messaging service in the device to communicate the request for update to the other controllers of the device. Once each controller has approved the update, the messaging service would then inform the firmware update service that the device is ready for update. Meta Data

[00323] In many embodiments of the invention, meta data may be added to the IDL. In cases where transactions or meta data is short, should be accessible and also secure, it can be stored in directly in the ledger. Examples include duration of the control e.g. for car rental or information about activity and consumption that may be relevant for insurance reasons.

[00324] Other meta data may be used for other operations beyond rights control. For example, protocol and routing information could be added to the device token. This data could then be used by devices with the same controller to locate other compatible devices. Further, firmware versions could be maintained in the ledger, which would help update services to identify when a device may need to be updated.

Anti -Counterfeiting

[00325] An example usage in another embodiment of the invention is to prove that a device is a genuine device. A verifier wishing to know that a device is genuine could ask the device to produce a signature by the Manufacturer of its public key using the trust and logic of a PKI (public key infrastructure) and certificate authority.

[00326] The verifier could also ask the device to sign a cryptographic nonce with its private key to prove it's the device associated with the corresponding public key. The verifier is checking the validity of the signature would know that the part was genuine. Revocation may be added as described above.

Compliance with Financial Regulations

[00327] Regulations for banks such as Know Your Customer (KYC) and anti-money laundering (AML) legislation are an important component of verifications and transactions that require significant overhead.

[00328] In some embodiments of the invention, interactions and financial transactions may be executed based on the confirmation from IDL that a trusted entity (e.g. a known bank or branch) has verified a customer identity and possibly source of funds. Regulatory entities (compliance organizations) would be able to verify the scale and frequency of transactions (without necessarily connection to individuals involved), could use the ledger to implement automated verification of reporting and would be able to spot check if transactions are registered in the ledger for the purpose of enforcing registration of transactions.

[00329] Other regulations such as Basel II, BRRD (UK, EU), Dodd-Frank (US) and the Bank Secrecy Act (US) require banks to keep track of data to for compliance.

Content Protection

[00330] The system can be used to attest that a platform can securely stream digital rights management (DRM)-protected content because it is a trusted device and may have been publicly registered and certified. This enables a higher security standard for the application describing content protection using a distributed ledger (reference Rae/Thorwirth) and many other common DRM applications in existence today. An IDL ledger system that may be utilized in accordance with embodiments of the invention is discussed in U.S. Patent Publication No. 2017/01 16693, the disclosure of which relevant to linking content rights to a distributed ledger is hereby incorporated by reference in its entirety.

Securing Transactions

[00331] Using hardware roots of trust based on described authentication, can enable devices that are trusted with a high level and secure enough to store and manage transactions, including financial transactions.

Cloud to Cloud Online Services

[00332] The model of trust can be used to e.g. establish trust between websites that have a common owner, e.g. if a utility company and online bank have the same owner, the utility company may be trusted by the bank to retrieve funds from the owners account.

Additional Applications

[00333] Additional use cases can include all scenarios where trust should be establish between entities and there is not a central authority to provide that information in a trusted, verifiable and reliable way. Mediation

[00334] In many embodiments of the invention, statements issued by entities on the IDL regarding models (or devices) may only be updated by the entity which first made the statement. For example, a manufacturer will obtain a public-private key pair. They will then sign all statements about a device model that they manufactured onto the IDL with their key pair. In some embodiments, this key pair is stored in a wallet on the employee's computer who is submitting the statements to the IDL. However, if the employee leaves the company or loses the wallet, they will not be able to make new statements (such as firmware update notifications) regarding the model. As the IDL is distributed without central authority regarding the data contained in the ledger, or the key pairs used to submit transactions, another means may be proved to recover control of the statements on the IDL. In one embodiment, mediators may be assigned to a statement by the entity who submitted the statement. In order to safeguard against a rogue mediator, at least two different mediators should be assigned to the statement. If the entity has lost their key pair, they may generate a new key pair, and request the mediators vote for control of the statement to be transferred to the new key pair. Once the mediators approve, such as by a majority vote, for the new key pair, the code running on the IDL would submit a transaction and transfer control of the statement to the new key pair.

[00335] In many embodiments, all nominations of the mediators, voting of a new key pair, and transfer of control would be stored on the IDL and publicly available to all users. Thus, an audit trail is produced, and invalid transfer could be identified, and updated through another round of mediation.

Exemplary Systems

[00336] Several embodiments of the invention describes a way for devices to be controlled based on statements stored on a DLT. The initial point of control is allowing a device to join a network. This network may be managed by a network operator, or an end consumer. Prior to the installer (or end consumer) attempting to join the network, there may be a multitude of statements recorded on the DLT for at least two parties. This information may include items such as, but not limited to, the identity of the manufacturer, model information, compliance and conformance records, test records, available firmware versions, instructions which may be displayed to the user or installer, expected network traffic patterns, and/or configuration commands. However, other data may be written to the ledger regarding the device, as long as it comes from a trusted source. A trusted source is an entity that produces cryptographically signed statements onto the DLT, which may be associated with the model or individual device.

[00337] In many embodiments, when a device is attempting to join the network, the identity of the model (device model ID) is first used to retrieve statements regarding the model. This data would then be evaluated to determine if the device should be allowed onto the network, and what rights it may have on said network. The network may be, for example, a local network in a house whose network operator is the owner of the house. For example, a network operator may require a model to be compliant to one or more compliance standards. If a device attempting to join the network meets these requirements, the network operator would configure the device such that it may participate in network communications. The configuration of the device may be direct communications to the device, or indirect such that device information is passed to other nodes or gateway in the network. This information is then used to grant access to the network, or portions of the network. In either case, the network operator is controlling the device such that it may communicate to at least one node in the network. Device control may be direct control of device actions, configuration settings of the device, or indirection control such as configuration of network attached devices to allow communications between said device and network attached devices.

[00338] In another embodiment of the invention, statements regarding the individual devices may be used for device control, configuration, or configuration of network attached devices. For example, a controller of the individual device may be recorded on the DLT in an loT device record. This controller may be the manufacturer who produced the device, in which case the DLT could record the transfer of control from one controller to another controller would be recorded. Some of the potential controllers may be: the manufacturer, retailer, network operator, end user, user (or network operator) management interface device, or a new user. In some instances, the manufacturer may assign an anonymous controller to the device on the DLT. When the end user purchases the device, the end user would transfer control from the anonymous controller to themselves. In another embodiment, the manufacturer may assign the initial controller to a service provider.

[00339] In many embodiments, the controller identity on the DLT would be used by the device, such that only the controller (or controllers) specified on the DLT may configure access rights to resources being hosted by the device. For example, a camera may be under control of the end user. The end user may then configure the camera's access control list to allow a TV to request a video stream from the camera. In another embodiment, the access control list would be maintained on the DLT. For example, the end user would be the controller of the camera's configuration resource. The end user could then add the TV to the camera's video stream resource control list. Whenever the TV requests video from the camera, the camera would then verify the request against the DLT.

[00340] The IDL may be hosted inside memory on the device, or remotely accessible through a trusted proxy. The proxy may include multiple interfaces to allow constrained devices access to the IDL, cloud to cloud interfaces for network operators, and/or human readable interfaces for end user controller. At minimum, the proxy only needs to provide a single interface to the IDL. The proxy could provide access to model information and/or device information. The proxy may also monitor the DLT for specific models (or devices), and detect new transactions regarding these devices. In several embodiments, whenever these transactions are detected, the proxy could then notify end users, network operators, and/or other network attached systems of the change. These user or systems could then read the new statements and potentially send new control commands to the device. In one embodiment, the network operator would configure their device firmware update system to receive notifications of new firmware versions being posted by the manufacturer of models currently deployed in the operator's network. Whenever the manufacturer of the model has a new firmware version, the firmware update system would retrieve the latest firmware from either the DLT or the location provided in the DLT. The update system would then follow the business rules configured by the operator, and ultimately instruct the device to enter firmware update mode, and apply the patch. [00341] In another embodiment, network identity and/or location of the individual device may be recorded on the IDL. A server device which serves multiple resources to client devices may periodically monitor the IDL for new devices being controlled by a common controller. The server device would then use the network identity and/or location to grant access to the client device to common resources. For example, a light bulb may be a server of the light state (on/off). Whenever the light bulb detects a light switch with a common controller, the light bulb would grant access to the light state resource to the light switch. However, other statements on the ledger may be used in the configuration of this control condition. For example, an installer may add the room in which each device is located to the IDL as an loT device record. In which case, switches in the same room with the light bulb would be allowed to turn off the light bulb.

[00342] Time periods may be recorded in the IDL along with the statement. For example, a compliance record may have an expiration date. In another example, an installer may be listed as a controller for a device only between specific dates. In such embodiments, the systems controlling the device based on these statements would verify the current time prior to taking action on the device. In another embodiment, the IDL could block controlling statements which are outside their valid time periods.

[00343] For managed devices, there may be multiple controller levels recorded on the IDL. In certain embodiments, the service provider's controller level would be allowed to enable/disable the device based on end user billing information, while the end user's controller level would be allow to operate the device's user interfaces (such as turning on/off the light bulb). Statements regarding controller groups may be directly associated with the device, such as users A, B, and C may all control device X. However, statements may be nested with other statements. For example, Group M may have control over device X, and Group M comprises the users A, B, and C.

[00344] Once a device has reached the end of its useful life, the controller may wish to discard the device and block access to any other user. In which case, the current user/owner may make a statement on the IDL that the device has been discarded and no new controller may take possession of the device. In order to recycle this device, the device could allow a factory reset in which all user data would be deleted from the device. Further, the device would generate a new device identity, which would be recorded on the IDL. All future statements would be written for the new device identity, and the device would ignore statements against the prior identity.

[00345] Although the present invention has been described in certain specific aspects, many additional modifications and variations would be apparent to those skilled in the art. In particular, any of the various processes described above can be performed in alternative sequences and/or in parallel (on the same or on different computing devices) in order to achieve similar results in a manner that is more appropriate to the requirements of a specific application. It is therefore to be understood that the present invention can be practiced otherwise than specifically described without departing from the scope and spirit of the present invention. Thus, embodiments of the present invention should be considered in all respects as illustrative and not restrictive. It will be evident to the person skilled in the art to freely combine several or all of the embodiments discussed here as deemed suitable for a specific application of the invention. Throughout this disclosure, terms like "advantageous", "exemplary" or "preferred" indicate elements or dimensions which are particularly suitable (but not essential) to the invention or an embodiment thereof, and may be modified wherever deemed suitable by the skilled person, except where expressly required.

Claims

WHAT IS CLAIMED IS:

1 . An access controller device comprising:

a processor;

a network interface;

a non-volatile memory containing an access control manager application for managing access of devices on a local network and for causing the processor to perform the steps of:

receiving a request for access to a resource from a network- connected device, where the request includes a device identifier of the network- connected device and resource identifier of the requested resource;

retrieving at least two pieces of information about the network- connected device from a distributed ledger, where:

the pieces of information about the network-connected device are each cryptographically signed by a different entity other than the network- connected device; and

the information is not unique to a single instance of the network-connected device and is common to other network-connected devices of the same device model; and

granting access in the access control manager for the network- connected device based on at least the at least two pieces of information retrieved from the distributed ledger about the network-connected device.

2. The access controller device of claim 1 , where the distributed ledger is a copy of replicated and synchronized data spread across multiple nodes regulated by a consensus algorithm

3. The access controller device of claim 1 , where the consensus algorithm is used to agree on the status the majority of participating nodes.

4. The access controller device of claim 1 , where the request for access is a request for access to a network that the access controller controls access to and the resource identifier identifies the network.

5. The access controller device of claim 1 , where the request for access is a request for access to a network-connected resource that the access controller controls access to and the resource identifier identifies the network-connected resource.

6. The access controller device of claim 1 where a copy of the distributed ledger is stored on the access controller device.

7. The access controller device of claim 1 where the distributed ledger is a blockchain ledger.

8. The access controller device of claim 1 where the information about the network-connected device identifies a manufacturer of the device.

9. The access controller device of claim 1 where the information about the network-connected device describes capabilities of the device.

10. The access controller device of claim 1 where the information about the network-connected device describes instructions on how to use the device.

1 1 . The access controller device of claim 1 where the information about the network-connected device describes firmware versions that are available to the device and locations where they may be downloaded.

12. The access controller device of claim 1 where the information about the network-connected device describes expected network traffic for the device.

13. The access controller device of claim 1 where the non-volatile memory further contains the distributed ledger.

14. The access controller device of claim 1 , wherein the access control manager application further causes the processor to request the distributed ledger from another entity.

15. The access controller device of claim 1 , wherein cryptographically signed by a different entity other than the network-connected device comprises being signed by a private key of a public-private key pair associated with the entity.

16. The access controller device of claim 1 , wherein at least one of the pieces of retrieved information indicates a standard to which the network-connected device is certified and is cryptographically signed by a compliance organization.

17. The access controller device of claim 1 , wherein the device identifier is a device model identifier that is not unique to a single instance of the network-connected device and is common to other network-connected devices of the same device model.

18. The access controller device of claim 1 , wherein the device identifier is an loT device identifier that is unique to that single instance of the network-connected device.

19. The access controller device of claim 1 , wherein the access control manager application is also for causing the processor to:

send a request for information about a network-connected device from a transaction on a distributed ledger to a ledger proxy device, where the request for information comprises a device identifier of the network-connected device;

where the ledger proxy device comprises a non-volatile memory containing a ledger proxy application for causing the processor to retrieve the requested information from the distributed ledger by:

performing multiple reads of the distributed ledger, and translating the results of the multiple reads of the distributed ledger into a message; and

securely sending the message from the proxy server to the access controller device.

20. An access controller device comprising:

a processor,

a network interface,

receiving a request for access to a network-connected resource from a network-connected device within a local network, where the request includes a device identifier of the network-connected device and resource identifier of the requested resource, and the request is digitally signed by a key unique to the network-connected device;

where the access controller, network-connected device, and network- connected resource are connected to the same local network;

retrieving information about the network-connected device from a distributed ledger, where the information about the network-connected device is cryptographically signed by an entity other than the network-connected device, and is distributed to other copies of the distributed ledger outside the local network; and

granting access in the access control manager for the network-connected device to the network-connected resource based on at least the information retrieved from the distributed ledger about the network-connected device.

21 . The access controller device of claim 20, where the distributed ledger is a copy of replicated and synchronized data spread across multiple nodes regulated by a consensus algorithm

22. The access controller device of claim 20, where the consensus algorithm is used to agree on the status the majority of participating nodes.

23. The access controller device of claim 20, where the retrieved information about the network-connected device comprises a list of one or more resources to which the access controller device is permitted to give access to approved network-connected devices.

24. The access controller device of claim 20, where the retrieved information about the network-connected device comprises a list of one or more approved network- connected devices that are permitted to access to the network-connected resource.

25. The access controller device of claim 20, where the retrieved information comprises an identifier of the controller of the network-connected device.

26. The access controller device of claim 20, where granting access in the access control manager for the network-connected device to the network-connected resource based on at least the information retrieved from the distributed ledger about the network-connected device comprises:

comparing the identifier of the controller of the network-connected device to an identifier of the controller of the access control device; and

granting the network-connected device access to the network-connected resource when the identifier of the controller of the network-connected device is the same as the identifier of the controller of the access control device.

27. The access controller device of claim 20, where the key is a public key of a public-private key pair assigned to the network-connected device.

28. The access controller device of claim 20, where the retrieved information indicates a standard to which the network-connected device is certified and is cryptographically signed by a compliance organization.

29. The access controller device of claim 20, where the retrieved information comprises information that describes one or more resources with which the network- connected device is permitted to communicate.

30. The access controller device of claim 20, where the retrieved information comprises a time period in which the information is valid.

31 . The access controller device of claim 20, where the retrieved information comprises the current user ownership of each device.

32. The access controller device of claim 20, where the retrieved information comprises the previous user ownership of a device.

33. The access controller device of claim 20, wherein the device identifier is a device model identifier that is not unique to a single instance of the network-connected device and is common to other network-connected devices of the same device model.

34. The access controller device of claim 20, wherein the device identifier is an loT device identifier that is unique to that single instance of the network-connected device.

35. The access controller device of claim 20, wherein the access control manager application is also for causing the processor to:

36. A ledger proxy device comprising:

a processor;

a network interface;

an interface to a distributed ledger;

a non-volatile memory containing a proxy server application for causing the processor to perform the steps of:

receiving a request for information about a network-connected device from a transaction on a distributed ledger from a requesting device, where the request for information comprises a device identifier of the network-connected device;

retrieving the requested information from the distributed ledger by:

performing multiple reads of the distributed ledger, and

translating the results of the multiple reads of the distributed ledger into a message to be sent to the requesting device; and

securely sending the message from the proxy server to the requesting device.

37. The ledger proxy device of claim 36, where the distributed ledger is on the ledger proxy device and the interface to the distributed ledger is an information path from the processor to the distributed ledger.

38. The ledger proxy device of claim 36, where the distributed ledger is on a remote server and the interface to the distributed ledger is a communication path from the processor to the remote server through the network interface.

39. The ledger proxy device of claim 36, where the request for information about a network-connected device describes what type of information about the network- connected device to retrieve and where:

performing multiple reads of the distributed ledger comprises identifying specific pieces of information from the type of information named in the request for information; and

translating the results of the multiple reads of the distributed ledger comprises combining the identified specific pieces of information.

40. The ledger proxy device of claim 36, where the proxy server is in communications with an access controller device for network-connected devices; and where the access controller is configured to grant access for a network- connected device to a network-connected resource based on the message containing translated information from the ledger proxy device.