WO2019161412A1 - Systems and methods for decentralized certificate hierarchy using a distributed ledger to determine a level of trust - Google Patents

Systems and methods for decentralized certificate hierarchy using a distributed ledger to determine a level of trust Download PDF

Info

Publication number
WO2019161412A1
WO2019161412A1 PCT/US2019/018641 US2019018641W WO2019161412A1 WO 2019161412 A1 WO2019161412 A1 WO 2019161412A1 US 2019018641 W US2019018641 W US 2019018641W WO 2019161412 A1 WO2019161412 A1 WO 2019161412A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
lot
ledger
trust
internet
Prior art date
Application number
PCT/US2019/018641
Other languages
French (fr)
Inventor
Petr Peterka
Niels J. Thorwirth
Ramanaiah UPPALA
Original Assignee
Verimatrix, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Verimatrix, Inc. filed Critical Verimatrix, Inc.
Publication of WO2019161412A1 publication Critical patent/WO2019161412A1/en

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/20—Individual registration on entry or exit involving the use of a pass
    • G07C9/21—Individual registration on entry or exit involving the use of a pass having a variable access code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/308—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using the Internet of Things
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/20—Individual registration on entry or exit involving the use of a pass
    • G07C9/27—Individual registration on entry or exit involving the use of a pass with central registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2145—Inheriting rights or properties, e.g., propagation of permissions or restrictions within a hierarchy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • the present invention generally relates to authenticating digital certificates and more specifically to a decentralized infrastructure system providing information to establish trust in digital certificates utilizing a distributed rights ledger technology such as blockchain.
  • 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.
  • loT devices 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 trust a manufacturer 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. 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:
  • Certificate authorities are entities that confirm identities and this established mechanism could be used to establish trust between all devices. But either there is only a single (or few) of these CAs in which case their centralized monopolistic or oligopolistic position gives them a disproportionate and exploitable market power, or there are many of them, in which case again, it will be difficult to keep track of who can be trusted, in particular if the group of trusted CAs is frequently changing with entities added and removed over time.
  • an loT (internet of things) access controller device includes a processor, a network interface, and a non-volatile memory containing an application to quantify a trust level in a digital certificate causing the processor to perform the steps of receiving a request for permissions on a local network from an loT device, where the request includes a digital certificate chain, where the digital certificate chain includes a digital certificate associated with the loT device and one or more digital certificates in a hierarchy associated with the digital certificate associated with the loT device, scanning a distributed certification ledger (DCL) for past transactions related to the digital certificates of the digital certificate chain in order to: retrieve transaction data including information characterizing past usage of any of the digital certificates in the digital certificate chain in transactions in the DCL, and information about transactions including the digital certificate that have been posted to the DCL by another trusted entity, calculate a trust level in the digital certificates in the digital certificate chain including the digital
  • DCL distributed certification ledger
  • the digital certificate within the request for permissions on a local network is signed by a signing key and certification data further includes information about the signing certificate associated with the signing key.
  • the calculated trust level is higher when considering factors including frequency of use of the signing key, distribution of use of the signing key over time, and use of the signing key in important transactions.
  • the calculated trust level is higher when a cryptographic statement about the signing certificate is a signature using a trusted key endorsing the signing certificate.
  • the application further causes the processor to: determine an additional trust level for the signing certificate associated with the signing key iteratively using transaction data retrieved for the signing certificate.
  • the calculated trust level is higher when the signing certificate is used in transactions that have been signed by other trusted users.
  • the request for permissions is a request for access to the local network.
  • the request for permissions is a request to execute commands.
  • the request for permissions is a request for information.
  • the request for permissions is a request for access to a resource on the local network.
  • the application further causes the processor to: retrieve information about the digital certificate from another source besides the distributed certification ledger.
  • the certificate chain is processed according to rules specified in the x.509 format.
  • the another source is a certificate revocation list.
  • the another source is an OCSP (online certificate status protocol) server.
  • the application further causes the processor to: retrieve information about whether a trusted entity has signed a digital certificate in the digital certificate chain.
  • FIG. 1 is a system level overview illustrating a DCL (distributed certification ledger) system that can establish trust in loT devices by information stored about them in a distributed ledger in accordance with embodiments of the invention.
  • DCL distributed certification ledger
  • FIG. 2 conceptually illustrates a ledger management device in accordance with an embodiment of the invention.
  • FIG. 3 conceptually illustrates blocks in a distributed certification ledger (DCL) in accordance with an embodiment of the invention.
  • DCL distributed certification ledger
  • FIG. 4 is a diagram illustrating relationships between entities participating in a distributed ledger in accordance with an embodiment of the invention.
  • FIG. 5 is a flow chart illustrating a process for determining trust levels in accordance with an embodiment of the invention.
  • FIG. 6 is a flow chart illustrating a process for entering information about a digital certificate into a distributed certification ledger (DCL) in accordance with an embodiment of the invention.
  • DCL distributed certification ledger
  • FIG. 7 is a flow chart illustrating a process for retrieving information about a digital certificate from a distributed certification ledger (DCL) and establishing a trust level of the digital certificate in accordance with an embodiment of the invention.
  • DCL distributed certification ledger
  • FIG. 8 shows a sample interaction between different devices and the distributed ledger as one device is evaluating the trust to be placed in another device.
  • FIGS. 9A and 9B illustrate sample device manufacturer certificate hierarchies (also called chains) in accordance with an embodiment of the invention.
  • FIG. 10 is a sequence diagram illustrating a process for determining trust between devices in accordance with an embodiment of the invention.
  • PKI Public Key Infrastructure
  • TLS Transport Layer Security
  • CA Certificate Authority
  • each device can create its own self-signed certificate, which is certainly useful for creating encrypted communication channels between devices and does not require third party involvement, but does not contribute to verification of authenticity, trustworthiness or compliance with standards or regulations since it does not provide meaningful information about the trust that should be instilled in that certificate by other parties.
  • Systems and methods for establishing trust in digital certificates using a blockchain ledger as a decentralized, immutable, distributed source of information to estimate trust in accordance with embodiments of the invention are described below. This provides a middle ground to the two extreme scenarios discussed above for establishing trust across loT (Internet of Things) devices: 1 ) a single CA (Certificate Authority) (with complexity and inflexibility) and 2) each device generating its own certificate.
  • aspects of many embodiments of the invention allow trust from CAs but also enable a way to analyze behavior of entities to dynamically adjust the trust level to the observed behavior.
  • the trust in a given cryptographic key can be established by observing its use and history.
  • certificate use that allows for secure and public evaluation of the use of certificates (and related encryption keys) are distributed ledgers such as implemented using blockchain technology. Information in these ledgers is cryptographically secured, reliably accessible and public, and therefore suited to observe and evaluate transactions of its participants by observing the use of their keys and certificates.
  • a transaction or entry in the distributed certification ledger contains information that pertains to a specific cryptographic key and/or a digital certificate associated with and/or signed by the cryptographic key.
  • the information about the cryptographic key can be used in various ways to establish trust levels indicative of how much the cryptographic key is to be trusted by other entities.
  • Transactions in the DCL can include information that can be used to establish a level of trust as discussed further below, such as, but not limited to, device mode compliance record, record about a manufacturer’s membership in a standards organization, liaison between two standards organizations, etc.
  • these records can be referred to as transaction data and may reference certificates associated with the entity being talked about (e.g. device model certificate, manufacturer certificate, standards organization certificate, respectively) and.
  • a DCL is an existing distributed ledger used for purposes such as cryptocurrency (e.g., Bitcoin, Ethereum), rights management, loT device or model information (such as in the patents and patent applications incorporated by reference below), smart contracts, or financial services.
  • a DCL is a dedicated ledger not used for other purposes.
  • the keys described are asymmetric keys where the public key (aka verification key) is used to publish and establish an identity.
  • the private key (aka signing key) is used to encrypt or sign data.
  • Reasons for use vary but are generally to apply or prove the identity in form of an endorsement, verification or agreement.
  • a digital certificate is at least a public key, while in additional embodiments a digital certificate includes a public key combined with meta information about this key such as, but not limited to, an owner’s name, issue data, and/or expiration date.
  • One standard certificate format with meta information that may be utilized in accordance with embodiments of the invention is known as X.509.
  • a certificate is signed (aka issued), the signer vouches for this information to be correct, e.g. a digital certificate certifies the ownership of a public key by the subject named in the certificate.
  • the certificate’s chain is used when using the certificate, such that all certificates directly or indirectly used for signing are considered.
  • Blockchains typically use asymmetric keys to identify accounts and account holders and manage access to them. For example, cryptocurrencies are sent to a public key using a private key.
  • the public keys used in the transaction may directly be used and may be evaluated but often they are not used directly but by association established with separate transactions.
  • the blockchain can be seen as public, decentralized ledger concept implemented as, for example 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), land registration or considered for registration of content rights as disclosed, for example, in U.S. Patent Publication No. 2017/0116693, 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 agreement of the content and status by the majority of the participating nodes.
  • the benefit is to establish trust between anonymous parties by creating consensus using rules that create security by introducing a consensus mechanism that distributes the confirmation of block of data between participating nodes 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 confirming and distributing blocks they have created (closed) and since there is an incentive to not only confirm or close the blocks (e.g. mining) but also to distribute confirmed blocks, 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.
  • DCL distributed certification ledger
  • the DCL 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.
  • 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.
  • a DLT Distributed Ledger Technology
  • a DLT 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, routers, cloud instances, desktop computers, mobile devices, and/or tablets, configured to participate in the DCL system as discussed further below. More specifically, nodes can include ledger management devices and loT devices as described in greater detail further below.
  • the ledger system 100 includes a ledger management device 110. It is a node that can communicate with one or more other nodes via a network 120. Additionally, the DCL 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.
  • the DCL system 100 includes a ledger management device 110, which may be 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 112.
  • the DCL 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.
  • ledger management devices 110 and 112 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.
  • a DCL proxy can receive a request to access the ledger and respond by retrieving or writing the requested information, e.g., in a transaction.
  • 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.
  • 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.
  • a ledger management device also referred to as node, that can be used to create and/or modify a DCL 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 module 281 , ledger modification module 282, and ledger block closing module 283.
  • Ledger creation module 281 can configure processor 220 to perform processes to generate a DCL ledger such as those discussed further below.
  • Ledger modification module 282 can configure processor 220 to perform processes to modify a DCL ledger such as those discussed further below to add transactions to the ledger.
  • Ledger block closing module 283 can configure processor 220 to perform processes to close a DCL ledger block such as those discussed further below.
  • Ledger block storage module 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 module 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.
  • a decentralized DCL ledger system may include additional ledger management devices 211 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 ledger in accordance with embodiments of the invention are discussed above. In particular, some of the nodes may not have the ledger creation module 281 as there are not use to create a ledger or the block closing module 283 if they are not used to close blocks or even modify blocks. The ledger may be reduced to storing module 284 and verification module 285 and can be used as a DCL proxy that relays DCL information to devices such as loT devices using network interface 260.
  • 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.
  • DCL ledger transactions typically contain identifying information of the submitter and other entities such as a 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.
  • the ledger blockchain segment 400 contains a first block N 410 and a subsequent block N+1 420.
  • 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.
  • a new statement or information about a device may be submitted to the ledger by a DCL device, to make a statement about an loT device.
  • block N 410 also includes a group of transactions, transaction N1 490, transaction N2 491 , and transaction N3 493.
  • block N+1 420 has a separate group of transactions N1 +1 495, transaction N2+1 496, and transaction N3+1 497.
  • a ledger aka blockchain
  • Example 1 loT and Compliance Ledger
  • Implementation details are public at the Verimatrix Veriteem project outlined in https://github.com/VehmatnxGen1/Veriteem.
  • As information about a device model is published, certified by a compliance lab, and updated with security and software updates, such an unmodifiable sequence of transactions builds trust in a device over time. The opposite is also true since lack of information or compliance or updates decreases trust in a device.
  • Such information may be observed and used by end users before they decide to purchase a device. It can also be used by other devices, such as home gateways when they discover a new device on the network, which attempts to connect to the home domain, in order to verify its capabilities, compliance with standards and regulations, etc. Individual ecosystems may set up policies or requirements for which devices may join the ecosystem. For instance, a level of security that may be good enough for a backyard lighting system may not be sufficient for a commercial building security system.
  • a manufacturer may decide to create its own self-signed root certificate (e.g., X.509 format as specified here https://tools. ietf. org/htm i/rfc5280) and its corresponding key pair, which signs device model certificates, which in turn is used to sign individual device certificates. Since any legitimate or illegitimate manufacturer can do this, it is certainly not good enough, at least initially, to establish sufficient level of trust in the device. [0060] However, when a manufacturer is added to the blockchain by a trusted standards organization as a legitimate member company, the trust in such a self-signed certificate may increase.
  • the device model certificate trust increases. After enough information about all these entities is published on the blockchain, their certificates will gain collective trust without a centralized CA and may increase that trust as software updates are published and incremental compliance tests are passed.
  • a home gateway detects a connection request from a new device on the home network.
  • the request is accompanied by information about its model number, signed by the device private key and the certificate chain including the model certificate and manufacturer certificate attached.
  • the gateway connects to the blockchain (e.g., directly or via a proxy), looks up the device model, checks its certificate (or a corresponding hash), verifies device compliance and interoperability, further looks up the manufacturer record and the root certificate also included in the blockchain as in the exemplary visualization in Figures 6 and 8.
  • the gateway accepts the connection request and creates a secure TLS (transport layer security standard) channel (or equivalent) with the device. Furthermore, if the manufacturer or its certificate has been endorsed by a standards body or the device model certificate is included in the compliance record, the gateway’s trust in the authenticity of the device increases.
  • TLS transport layer security standard
  • the manufacturer may decide to use a public certificate authority in which case the manufacturer certificate would be a sub-CA certificate signed by the public CA.
  • each manufacturer is free to decide how to manage its own certificates or whether to use a third party to issue certificates.
  • the described system may be even more open.
  • a device manufacturer or a service provider may add a record about itself to the blockchain.
  • the consortium may create a transaction on the blockchain announcing that the manufacturer is an official member.
  • the manufacturer may also add a transaction verifying that the compliance organization is a valid entity.
  • a manufacturer’s reputation increases if it is a member of multiple standards or consortia.
  • two or more standards organizations may create a liaison relationship and record it on the blockchain.
  • FIG. 4 illustrates an example of relationships and responsibilities between entities in establishing certification of a device or certificate in accordance with several embodiments of the invention.
  • This mesh-like arrangement which can also be referred to as a trust graph, allows for revocation of certificates associated with the manufacturer or in general any entity on the blockchain. For instance, when a manufacturer produces noncompliant devices or it fails to provide a mandatory security software update, etc., the other entities can publish information to the blockchain to make these types of failures known.
  • the standards organizations and/or test labs involved can enter information indicating the noncompliance on the blockchain. This may not represent a complete revocation of the certificate, but it certainly lowers the trust associated with the manufacturer’s devices.
  • each entity participating in these relationships may have its own certificate. Transactions that reference another entity not only by its identifier but also by its certificate (or at least its hash) may be more valuable. For instance, when a standards organization approves a test lab, it may include its certificate or hash in that transaction. In turn, when a test lab issues a compliance transaction about a specific device model, it may sign it using its private key. This mechanism makes it more difficult to issue fraudulent transactions in part because different keys are required to manage the certificates and blockchain access and may be secured independently to create additional hurdles to fraud.
  • the mechanisms described above are used to help loT ecosystems to determine a level of trust in order to decide whether to add an otherwise unknown device to its network.
  • One extreme is to handpick and pre-integrate a small number of devices up front; another one is to admit all devices.
  • the former is expensive, does not scale and makes users unhappy by limiting choice; the latter results in unreliable, non-secure networks also resulting in unhappy users.
  • the proposed solution creates a meaningful balance between scalability, security and usability, while leaving policy setting to each ecosystem.
  • a variation to the compliance ledger case described above is a ledger that registers each device individually. Details on such an loT rights ledger are described in PCT Patent Application Serial No. PCT/US 18/46,547 entitled“Systems and Methods for Rights Control of Network-Connected or loT Devices Using Information Stored In a Distributed Ledger” and filed August 13, 2018 (the‘547 patent), the relevant disclosure of which is hereby incorporated by reference in its entirety.
  • the trust can be established with a certificate that is endorsed by multiple other entities, but in addition to the trust in the device model that tries to estimate the device security and reliability, trust can also be determined for individual devices as the ledger history may also show information such as where and by whom and when it has been manufactured, helping to differentiate between devices within one model.
  • the distribution chain may be identified and assigned more trust if handled by popular retailers with a high level of trust. Usage and history of ownership may indicate the use of the device, which may be important for devices with a limited live span and multiple untrusted users with control of the device may have had chances to tamper with the device which can decrease trust for some applications.
  • certificates can be used to represent other parties and the history of use of the certificates can evaluated to determine a level of trust in the business partner. For example, in consideration of a pending transaction a person selling goods is requesting a proof of control of an existing certificate for example by having a document signed electronically. The certificate is then evaluated by considering past use of the certificate as encoded in a distributed ledger, such as a bitcoin blockchain. The private key corresponding to the certificate may have been used in past transaction and the history of their size, date, frequency and/or credibility of counter parties can be used to estimate the reputation and trust in this party.
  • CAs are used today to establish trust in websites that browsers connect to using HTTPS. For example, if the domain at https://online.citi.com/ is using a certificate signed by Digitcert than it is assumed Digicert has done some diligence to verify that the key belongs to Citigroup, Inc., as stated in the certificate endorsed by digital signature from (or issued by) Digicert.
  • This current system is placing binary trust into the certificate that will either warn the user of a missing root authority or assume the counterparty is as stated in the certificate. This binary trust is helpful, but security is never perfect and different levels of trust may apply.
  • the trust is determined with additional factors.
  • the factors may be the credibility of the site, as measured by features such as its first appearance, how many other sites link to it and their trust level, its frequency of updates and the trust in partner sites that use certificates endorsed by the same root.
  • Identity of individuals is often managed by centralized entities, such as the government that issues identification documents or companies that manage login credentials like e.g. Facebook. Credentials may be shared, possibly via a centralized marketplace like a TV Everywhere (https://en.wikipedia.org/wiki/TV_Everywhere) system. In this system the verification allows e.g. content providers like HBO to verify if a customer that wants to access their content is a paying cable TV subscriber and has therefor the right to access the content. Other systems allow verification of age, licenses or residence. [0076] In the approach proposed in several embodiments of the invention, identities are registered in the blockchain and gain value through either an entity that confirms at least parts of the ID like examples above and/or history and usage of the ID and transactions involved.
  • IDs can be registered, and elements can be associated later, e.g. adding a birthdate to the identity or single elements are used differently, such that there is a different record for a person's age than birthplace, possibly with different visibility and access rights.
  • trust in the ID possible actions may be to allow entry, access, operation or other decisions to the holder of the identity.
  • the overall trust level is a linear combination of elements of:
  • h, d and t determine the importance of each factor and could be equal to 1/3 in a simple case.
  • the factors are often and weighted differently before they are combined.
  • Non-linear combinations are also possible.
  • Example includes thresholding with required minimum or multiplicative interdependence between these values.
  • the history of the key including information such as, but not limited to, how often it has been used (e.g. average uses per year), time of first use (e.g., measure in months) and/or how regular the use has been (e.g., as standard deviation of intervals between uses) - habits.
  • Other elements may include the standard deviation in transaction size it has been used in.
  • direct endorsements are given by other parties and can be measured additively by the quantity and trust level of endorsers.
  • a known CA will have a high level of trust which can be established from a prior trust in this CA and can be enhanced or replaced with determining the trust as described in embodiments of the invention.
  • the keys that have been used to register devices into the loT ledger are highly trusted, if they have been signed by a known CA and by a trusted entity such as a compliance organization with a trusted score FI and T.
  • Endorsements may be negative if a trusted entity makes a negative statement about the key or user, including certificate revocation.
  • the trust level for an individual identity from direct endorsements can be derived as a sum of the trust levels in the endorsers.
  • Endorsers can be entities that have signed the certificate of the entity to be evaluated. In this way, any endorsers of any of the members of the certificate chain can be taken into account.
  • the importance of transactions that have been signed by a key contributes to the trust in that key are a measure for past behavior.
  • the keys that have been used to register devices into the loT ledger are trusted more if the transactions that they endorsed are also endorsed by other trusted organizations.
  • a manufacturer’s key gains trust if it is used to register a device that then is used in transactions by other trusted entities such as compliance organizations.
  • the involvement of the certificate may be direct if it is used in the transaction, or indirect, if it is posted by an entity identified in a certificate or if it is posted by an entity identified in any of the certificates in the chain.
  • Combinations of these values here serve as examples and many similar ways and combinations can be performed to calculate the level of trust.
  • Machine learning models may help to calculate trust by determining a combination that matches the desired outcome. Typically, these are trained using a set of data that externally provides the desired outcome. These datasets may be derived and/or trained with information regarding trust observed from other source(s) or manual entry of the information.
  • Fig. 5 is a flow chart visually illustrating a process to determine the trust level of digital certificate(s) and how the levels H, D and T can be determined for a digital certificate in accordance with an embodiment of the invention.
  • the digital certificate represents an identity and could be an x.509 certificate or could be reduced to an identifier of a device or person that is unique or pseudo unique such as a public key or hash code.
  • to determine the trust level for an individual certificate trust levels in all certificates are determined. This can be done recursively to update trust levels across the certificates. This allows them to be used to evaluate the importance of transactions they are involved in to ultimately reflect back on a single certificate.
  • iterations can be used to determine interdependencies of trust relationships.
  • trust levels can be added with each transaction that is added to the ledger. Specific steps in an example workflow are discussed below:
  • the trust level attributed to a key or certificate can be determined by an entity other than its owner in order to decide on the use in the key/certificate and its owner. If the trust level in this key or certificate is high because, e.g., it has been used correctly over time and the owner has been identified. The owner will be granted more rights. Examples include:
  • a device may require a trust level above a certain threshold (reputation or trust score) to be, e.g., allowed in a network, i.e. , a gateway is evaluating the trust, allowing communication of this device with the other devices in the network accordingly.
  • a trust level above a certain threshold (reputation or trust score) to be, e.g., allowed in a network, i.e. , a gateway is evaluating the trust, allowing communication of this device with the other devices in the network accordingly.
  • a trust level above a certain threshold e.g., allowed in a network
  • a gateway is evaluating the trust, allowing communication of this device with the other devices in the network accordingly.
  • the trust can also be generalized and be applied to other kind of transactions and interactions. To conduct business, it is helpful to determine a trust level before an offer is made. Since interactions with trusted parties may be more reliable and involve less effort or risk, a trusted party may receive a different offer. Similarly, other decisions like the required prepayment, payment terms, size of the transaction may depend in the level of trust in the other party. For example, am order for goods and services may be placed depending on the trust in the account that is receiving the payments. If the transactions have not been associated with illegal transactions, have been regular with not too much variation, a volume above a certain threshold and the account has existed for a while the transaction may be preferred to choose a supplier with a new account or one that indicates sporadic transactions only.
  • a process for entering information about a digital certificate into a distributed certification ledger (DCL) in accordance with an embodiment of the invention is illustrated in Figure 6. Parts of the process may be performed by a server or other machine in control or used by an entity.
  • the process 600 includes generating (602) transaction data for a device or entity including a reference to the corresponding device or entity’s digital certificate, either a full copy of the certificate or at least a hash of the certificate.
  • this can be a manufacturer creating information such as a model number for a device which is represented by the digital certificate, a standards organization attesting that the manufacturer and/or device is a member of the organization, or a test lab certifying that the device is in compliance with a particular standard, (e.g.
  • device mode compliance record record about a manufacturer’s membership in a standards organization, liaison between two standards organizations, etc.
  • these records may reference certificates associated with the entity being talked about (e.g. device model certificate, manufacturer certificate, standards organization certificate, respectively). Additional types of representations by any of a variety of entities may also be utilized in accordance with embodiments of the invention. Negative or neutral information may also be generated in additional embodiments. For example, decertification or deregistration of a device can be indicated by such information.
  • the process proceeds to write (604) the transaction data associated with the digital certificate to a distributed certification ledger.
  • this involves creating a new block in the ledger using mechanisms such as those described further above and in documents incorporated by reference herein.
  • FIG. 7 is a flow chart illustrating a process for retrieving information about a digital certificate from a distributed certification ledger (DCL) and establishing a trust level of the digital certificate in accordance with an embodiment of the invention. Parts of the process may be performed by a device or other machine in control or used by an entity.
  • the process 700 includes receiving (702) a request for action, where the request includes one or more digital certificate(s). For example, one digital certificate may be signed by or associated with another. Furthermore, the digital certificate(s) may be received from another device.
  • DCL distributed certification ledger
  • the request for action is a request for permissions by an internet of things (loT) device, where they request for permissions may be any of a variety of functions, such as, but not limited to, allowing the loT device to access the local network, allowing commands received from the loT device to be executed, providing certain information to the loT device, or allowing the loT device to access a specified resource on the local network.
  • LoT internet of things
  • the process includes retrieving (704) information about the digital certificate(s) from a distributed certification ledger.
  • certification information in the digital ledger can be information about a device or manufacturer of the device, certification status of the device, or any of a variety of similar information pertaining to the device that can be used to formulate a trust level.
  • the process includes retrieving (706) information about the digital certificate(s) from additional sources.
  • additional sources can include certificate authorities or other centralized repositories.
  • the process includes establishing (708) a trust level in digital certificate(s) based on retrieved information.
  • a trust level can be calculated by a number of factors using information from the distributed certification ledger about the certificate in question.
  • Various embodiments may include processes similar to that illustrated and described with respect to Figure 5 further above.
  • the process includes taking action based on the established trust level of digital certificate(s).
  • the action can involve any of a variety of decisions, such as but not limited to those described further above, e.g., allowing access for a device to a router or network, connecting one device to another for control purposes, etc.
  • Figure 8 shows a sample interaction between different devices and the ledger as Device D2 is evaluating the trust to be placed in Device D1 in accordance with an embodiment of the invention.
  • Device D1 presents its unique device certificate C1 that has been signed by owner of signing certificate S1 (which is also presented) and hence inherited the trust in S1.
  • S1 may be a certificate used for many or all other devices of this model.
  • the chain may extend to multiple predecessors, including, e.g., not only model certificates but, in a higher hierarchy, manufacturer certificates used for all models, as described in Fig 9 A and B.
  • FIG. 9A illustrates a sample device manufacturer certificate hierarchy or chain in accordance with an embodiment of the invention.
  • the Device Certificate C is signed by the one Device Model Certificate Sc that is used for its model.
  • Other Device Model Certificates may exist from one of several Business Unit Certificates Sb from a large Manufacturer represented by a Manufacturer root certificate Sa, which may be the top of this certificate hierarchy and self-issued by the Manufacturer or it may in turn be signed by a CA.
  • the chain may also have branches in which one certificate is signed by multiple others or is used to sign several others.
  • Fig 9B the chain is shorter, and C is signed by Sc which in this case is the top of the chain.
  • C is signed by Sc which in this case is the top of the chain.
  • a single certificate or key pair is used to identify a ledger participant, as is the case in bitcoin transactions.
  • loT rights ledger as described in the‘547 patent) in which every device (not only device models) has its own identity and its history is observed only by actions on this device as in example above.
  • the ledger L1 is queried about S1 with factors such as, but not limited to: What other models have been registered by S1 , how they have been certified, rated, reviewed and/or if S1 or any of the certificates signed with it or any signers of it have ever been revoked.
  • This query may be using the public key in the certificate, a blockchain key derived from it, or information such as make and model name communicated in the certificate S1 or C1.
  • the device is trusted to report the correct name because, e.g., it may have been purchased from a trusted dealer or has physical features that allow some authenticity verification.
  • the device presenting C1 as its identity can be commonly verified to be the holder of the private key corresponding to the public key in the certificate by a cryptographic challenge such as encrypting a given piece of information.
  • FIG. 10 is a communication sequence diagram illustrating a process for determining trust between devices using a DCL in accordance with an embodiment of the invention. Illustrated are communications between Device D1 , Device D2, certificate ledger CL and potentially other devices.
  • Device D1 attempts to establish a level of trust with device D2.
  • Device D1 provides its ID along with certificates, if available: C1 (D1 Cert), and S1 to the verifying device D2.
  • C1 D1 Cert
  • S1 may include not only the direct signing certificate but can be extended to the complete certificate chain, including entities in Fig. 9A.
  • D2 queries the ledger for history and use of collected information concerning D1. This query can rely on the identity provided by device D1 and the C1 and S1 certificate if provided in previous step.
  • D2 can determine trust factors such as, but not limited to, if this model has been tested to meet industry standards, if firmware updates are available or have been made available in the past, if the certificate has been used for other models or if a certificate has been revoked. Additionally the evaluation is not limited to S1 but can include other certificates in the complete chain, including digital certificates of, e.g., manufacturer and root CA.
  • D2 may also query other sources such as a traditional CA to access a certificate revocation list (CRL), other ledgers, its own history of devices approved externally and using comparable credentials, or databases for trust factors for D1 , S1 , or C1. D2 can use this information to establish a trust level and to compare this against a required trust level specified in its policy and will accept or reject the D1s request based upon the trust level.
  • the policy may be preprogrammed in the device D2 or derived from a trusted source by D2. It may be set statically and change infrequently or be dynamic, e.g., relative to the other devices such that the, e.g., 85% most trusted devices are allowed in the network.
  • CA Certificate Authority
  • the trust is established between an end-user and a relying (or verifying) party via trusted third party (i.e. Certification Authority).
  • the relying party should verify the validity by checking if a certificate has been revoked, by reviewing Certificate Revocation Lists (CRLs) e.g. using OCSP (online certificate status protocol) servers provided by the Certification Authority prior to trusting the end-user certificate.
  • CTLs Certificate Revocation Lists
  • OCSP online certificate status protocol
  • the end-user certificate is issued by an intermediate CA (i.e. Sub CA)
  • the relying party should download them as well until the full certificate chain is available for certificate chain validation.
  • just one entity provides the certificate health status (i.e. Good or Bad) and ranks the given device based on the device health. Relevant information is retrieved from published information on the ledger.
  • a relying party When a relying party tries to establish communication with multiple end users, the relying party should contact each corresponding certification authority to make sure given end-entity certificate and intermediate CA (i.e. Sub CA) certificates are valid prior to the transaction, requiring multiple connections to different locations for lookup whereas, on the contrary, a ledger node in accordance with embodiments of the invention has all information in one place.
  • end-entity certificate and intermediate CA i.e. Sub CA
  • TTP Trusted Third Party
  • nodes are network components that store a copy in the ledger. They help in distributing the ledger and building the consensus and commonly participate in the consensus. Their reputation can be derived from observation no how current they keep their ledger status, if they participate in consensus and what transactions they originate.
  • Evaluation of the blockchain may be performed directly by the evaluating entity such as a device, by running a full blockchain node that has record of the complete transaction history.
  • that information can be access from a trusted node that provides all relevant transaction for evaluation.
  • this trusted node will not only provide relevant transactions but provide a more aggregated result such as an actual trust score for the evaluated key, possibly variations according to different measures or already thresholded, indicting suitability for certain uses.
  • These may be accessible using a remote API and provided as a service by 3rd parties. These API can enrich the data with outside sources about the identity in question and provide this information in detail or aggregated within an enhanced trust score. Outside information includes public databases, web searches, past queries from this or about this identity to this service. Additional discussion of proxy use in accessing a blockchain ledger that may be utilized in accordance with embodiments of the invention can be found in the‘547 patent incorporated by reference above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Finance (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)

Abstract

Systems and methods for decentralized certificate hierarchy using a distributed ledger to determine a level of trust in accordance with embodiments of the invention are disclosed. In one embodiment, an loT (internet of things) access controller device receives a request for permissions on a local network from an loT device, where the request includes a digital certificate chain, where the digital certificate chain includes a digital certificate associated with the loT device and one or more digital certificates in a hierarchy, scans a distributed certification ledger (DCL) for past transactions related to the digital certificates to: retrieve transaction data including information characterizing past usage of any of the digital certificates, and information about transactions including the digital certificate that have been posted by another entity, calculate a trust level, determine whether to proceed with granting the requested permissions, grant the requested permissions when the determination is affirmative.

Description

SYSTEMS AND METHODS FOR DECENTRALIZED CERTIFICATE HIERARCHY USING A DISTRIBUTED LEDGER TO DETERMINE A LEVEL OF TRUST
FIELD OF THE INVENTION
[0001] The present invention generally relates to authenticating digital certificates and more specifically to a decentralized infrastructure system providing information to establish trust in digital certificates utilizing a distributed rights ledger technology such as blockchain.
BACKGROUND
[0002] 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.
[0003] 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 trust a manufacturer 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. 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 - each of the centralized providers assume that they are known and trusted, but overall they represent a large and fluctuating group and having a-priory knowledge of and trust in each of these providers is not easily feasible to be established for all connected devices all the time.
• These incompatibilities result in making it difficult to establish a trusted relationship to these devices without agreement in a common trusted party that endorses the devices.
[0004] Certificate authorities (CA) are entities that confirm identities and this established mechanism could be used to establish trust between all devices. But either there is only a single (or few) of these CAs in which case their centralized monopolistic or oligopolistic position gives them a disproportionate and exploitable market power, or there are many of them, in which case again, it will be difficult to keep track of who can be trusted, in particular if the group of trusted CAs is frequently changing with entities added and removed over time.
SUMMARY OF THE INVENTION
[0005] Systems and methods for decentralized certificate hierarchy using a distributed ledger to determine a level of trust in accordance with embodiments of the invention are disclosed. In one embodiment, an loT (internet of things) access controller device includes a processor, a network interface, and a non-volatile memory containing an application to quantify a trust level in a digital certificate causing the processor to perform the steps of receiving a request for permissions on a local network from an loT device, where the request includes a digital certificate chain, where the digital certificate chain includes a digital certificate associated with the loT device and one or more digital certificates in a hierarchy associated with the digital certificate associated with the loT device, scanning a distributed certification ledger (DCL) for past transactions related to the digital certificates of the digital certificate chain in order to: retrieve transaction data including information characterizing past usage of any of the digital certificates in the digital certificate chain in transactions in the DCL, and information about transactions including the digital certificate that have been posted to the DCL by another trusted entity, calculate a trust level in the digital certificates in the digital certificate chain including the digital certificate associated with the loT device, based on the retrieved transaction data, determine whether to proceed with granting the requested permissions based on the calculated trust level, grant the requested permissions when the determination to proceed with the requested action is affirmative based on the calculated trust level.
[0006] In a further embodiment, the digital certificate within the request for permissions on a local network is signed by a signing key and certification data further includes information about the signing certificate associated with the signing key. [0007] In another embodiment, the calculated trust level is higher when considering factors including frequency of use of the signing key, distribution of use of the signing key over time, and use of the signing key in important transactions.
[0008] In a still further embodiment, the calculated trust level is higher when a cryptographic statement about the signing certificate is a signature using a trusted key endorsing the signing certificate.
[0009] In still another embodiment, the application further causes the processor to: determine an additional trust level for the signing certificate associated with the signing key iteratively using transaction data retrieved for the signing certificate.
[0010] In a yet further embodiment, the calculated trust level is higher when the signing certificate is used in transactions that have been signed by other trusted users.
[0011] In yet another embodiment, the request for permissions is a request for access to the local network.
[0012] In a further embodiment again, the request for permissions is a request to execute commands.
[0013] In another embodiment again, the request for permissions is a request for information.
[0014] In a further additional embodiment, the request for permissions is a request for access to a resource on the local network.
[0015] In another additional embodiment, the application further causes the processor to: retrieve information about the digital certificate from another source besides the distributed certification ledger.
[0016] In a still yet further embodiment, the certificate chain is processed according to rules specified in the x.509 format.
[0017] In still yet another embodiment, the another source is a certificate revocation list.
[0018] In a still further embodiment again, the another source is an OCSP (online certificate status protocol) server.
[0019] In still another embodiment again, the application further causes the processor to: retrieve information about whether a trusted entity has signed a digital certificate in the digital certificate chain. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] FIG. 1 is a system level overview illustrating a DCL (distributed certification ledger) system that can establish trust in loT devices by information stored about them in a distributed ledger in accordance with embodiments of the invention.
[0021] FIG. 2 conceptually illustrates a ledger management device in accordance with an embodiment of the invention.
[0022] FIG. 3 conceptually illustrates blocks in a distributed certification ledger (DCL) in accordance with an embodiment of the invention.
[0023] FIG. 4 is a diagram illustrating relationships between entities participating in a distributed ledger in accordance with an embodiment of the invention.
[0024] FIG. 5 is a flow chart illustrating a process for determining trust levels in accordance with an embodiment of the invention.
[0025] FIG. 6 is a flow chart illustrating a process for entering information about a digital certificate into a distributed certification ledger (DCL) in accordance with an embodiment of the invention.
[0026] FIG. 7 is a flow chart illustrating a process for retrieving information about a digital certificate from a distributed certification ledger (DCL) and establishing a trust level of the digital certificate in accordance with an embodiment of the invention.
[0027] FIG. 8 shows a sample interaction between different devices and the distributed ledger as one device is evaluating the trust to be placed in another device.
[0028] FIGS. 9A and 9B illustrate sample device manufacturer certificate hierarchies (also called chains) in accordance with an embodiment of the invention.
[0029] FIG. 10 is a sequence diagram illustrating a process for determining trust between devices in accordance with an embodiment of the invention.
DETAILED DESCRIPTION
Centralized Certificate Management
[0030] Public Key Infrastructure (PKI) is broadly used today to establish trust among entities on the internet. This is accomplished by issuing cryptographic certificates to service providers as well as end-user devices that use these certificates to establish secure communication channels with the help of protocols such as the Transport Layer Security (TLS). This solution requires a known and agreed upon root of trust that issues the certificates, a Certificate Authority (CA). If there is a single CA, all certificates have been endorsed (directly or indirectly) by the same root certificate. Several CAs could exist and, in this case, servers and client devices must have the ability to verify certificates issued by a potentially large number of different CAs in order to create trust across otherwise disconnected trust ecosystems. Therefore, a typical browser or a cell phone holds hundreds of root certificates from issuers that most users have never heard of.
[0031] For fragmented ecosystems like the Internet of Things (loT), a diverse set of devices coming from different manufacturers from around the world participate. It is often desirable for them to communicate with each other and trust is required to do so securely. It is unlikely, and certainly undesirable, that there will be a single loT CA creating a monopoly governing a single source of trust. CAs are often commercial entities that charge for their service of verification the issuer and use of the certificate making use in large quantities expensive. Management of a large number of known CAs and dynamic and secure management of this list is complex and therefore a challenge for inexpensive, simple loT devices. Also, the CA endorsement is generally binary (e.g., trusted or not trusted), and that level may not be suited for different applications that require different levels of trust. Issuing and maintaining different trust levels and frequently updating the status by third parties would be cumbersome, error prone and costly. This system is commonly called public key infrastructure (PKI). More details are discussed in the section Comparison to Conventional PKI below.
[0032] Alternatively, each device can create its own self-signed certificate, which is certainly useful for creating encrypted communication channels between devices and does not require third party involvement, but does not contribute to verification of authenticity, trustworthiness or compliance with standards or regulations since it does not provide meaningful information about the trust that should be instilled in that certificate by other parties. [0033] Systems and methods for establishing trust in digital certificates using a blockchain ledger as a decentralized, immutable, distributed source of information to estimate trust in accordance with embodiments of the invention are described below. This provides a middle ground to the two extreme scenarios discussed above for establishing trust across loT (Internet of Things) devices: 1 ) a single CA (Certificate Authority) (with complexity and inflexibility) and 2) each device generating its own certificate. Aspects of many embodiments of the invention allow trust from CAs but also enable a way to analyze behavior of entities to dynamically adjust the trust level to the observed behavior.
[0034] In many embodiments, the trust in a given cryptographic key can be established by observing its use and history. One example of certificate use that allows for secure and public evaluation of the use of certificates (and related encryption keys) are distributed ledgers such as implemented using blockchain technology. Information in these ledgers is cryptographically secured, reliably accessible and public, and therefore suited to observe and evaluate transactions of its participants by observing the use of their keys and certificates.
[0035] In some embodiments, a transaction or entry in the distributed certification ledger (DCL) contains information that pertains to a specific cryptographic key and/or a digital certificate associated with and/or signed by the cryptographic key. The information about the cryptographic key can be used in various ways to establish trust levels indicative of how much the cryptographic key is to be trusted by other entities. Transactions in the DCL can include information that can be used to establish a level of trust as discussed further below, such as, but not limited to, device mode compliance record, record about a manufacturer’s membership in a standards organization, liaison between two standards organizations, etc. Furthermore, these records can be referred to as transaction data and may reference certificates associated with the entity being talked about (e.g. device model certificate, manufacturer certificate, standards organization certificate, respectively) and. In some embodiments, a DCL is an existing distributed ledger used for purposes such as cryptocurrency (e.g., Bitcoin, Ethereum), rights management, loT device or model information (such as in the patents and patent applications incorporated by reference below), smart contracts, or financial services. In other embodiments, a DCL is a dedicated ledger not used for other purposes. Systems and methods for establishing trust using a distributed certification ledger in accordance with embodiments of the invention are discussed below.
Cryptographic Keys
[0036] In many embodiments of the invention, the keys described are asymmetric keys where the public key (aka verification key) is used to publish and establish an identity. The private key (aka signing key) is used to encrypt or sign data. Reasons for use vary but are generally to apply or prove the identity in form of an endorsement, verification or agreement. In several embodiments, a digital certificate is at least a public key, while in additional embodiments a digital certificate includes a public key combined with meta information about this key such as, but not limited to, an owner’s name, issue data, and/or expiration date. One standard certificate format with meta information that may be utilized in accordance with embodiments of the invention is known as X.509. It may also include information different from but tied to the public key such as a truncated or hashed version of it or information signed with the private key. If a certificate is signed (aka issued), the signer vouches for this information to be correct, e.g. a digital certificate certifies the ownership of a public key by the subject named in the certificate. In many embodiments the certificate’s chain is used when using the certificate, such that all certificates directly or indirectly used for signing are considered. Blockchains typically use asymmetric keys to identify accounts and account holders and manage access to them. For example, cryptocurrencies are sent to a public key using a private key. In several embodiments of the invention, the public keys used in the transaction may directly be used and may be evaluated but often they are not used directly but by association established with separate transactions. Such that the key pair used to manage the ledger account in the ledger is different from the one used in e.g. device certification, but they are linked with a transaction where the key pair to manage the ledger account is used to publish the certificate used in device certification. Blockchain as a Distributed Certification Ledger
[0037] The blockchain can be seen as public, decentralized ledger concept implemented as, for example 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), land registration or considered for registration of content rights as disclosed, for example, in U.S. Patent Publication No. 2017/0116693, 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 agreement of the content and status by the majority of the participating nodes.
[0038] The benefit is to establish trust between anonymous parties by creating consensus using rules that create security by introducing a consensus mechanism that distributes the confirmation of block of data between participating nodes 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 confirming and distributing blocks they have created (closed) and since there is an incentive to not only confirm or close the blocks (e.g. mining) but also to distribute confirmed blocks, 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.
[0039] Many embodiments of the present invention include a decentralized, distributed ledger that is used to establish trust in digital certificates, referred to here as distributed certification ledger (DCL). In a number of embodiments, the DCL 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 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.
[0040] 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, routers, cloud instances, desktop computers, mobile devices, and/or tablets, configured to participate in the DCL system as discussed further below. More specifically, nodes can include ledger management devices and loT devices as described in greater detail further below.
Distributed Certification Ledger Systems
[0041] A distributed certification ledger (DCL) system in accordance with an embodiment of the invention is illustrated in FIG. 1. The ledger system 100, includes a ledger management device 110. It is a node that can communicate with one or more other nodes via a network 120. Additionally, the DCL 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. [0042] The DCL system 100 includes a ledger management device 110, which may be 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 112. In many embodiments, the DCL 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.
[0043] In some embodiments, ledger management devices 110 and 112 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, a DCL proxy can receive a request to access the ledger and respond by retrieving or writing the requested information, e.g., in a transaction.
[0044] 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.
[0045] While a variety of decentralized DCL 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 DCL ledger systems in accordance with various embodiments of the invention are discussed further below. DCL Management Devices
[0046] A ledger management device, also referred to as node, that can be used to create and/or modify a DCL 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 module 281 , ledger modification module 282, and ledger block closing module 283. Ledger creation module 281 can configure processor 220 to perform processes to generate a DCL ledger such as those discussed further below. Ledger modification module 282 can configure processor 220 to perform processes to modify a DCL ledger such as those discussed further below to add transactions to the ledger. Ledger block closing module 283 can configure processor 220 to perform processes to close a DCL ledger block such as those discussed further below. Ledger block storage module 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 module 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.
[0047] A decentralized DCL ledger system may include additional ledger management devices 211 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 ledger in accordance with embodiments of the invention are discussed above. In particular, some of the nodes may not have the ledger creation module 281 as there are not use to create a ledger or the block closing module 283 if they are not used to close blocks or even modify blocks. The ledger may be reduced to storing module 284 and verification module 285 and can be used as a DCL proxy that relays DCL information to devices such as loT devices using network interface 260.
DCL Ledger Blockchain Structure
[0048] 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.
[0049] DCL ledger transactions typically contain identifying information of the submitter and other entities such as a 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.
[0050] A conceptual illustration of a ledger blockchain file structure in accordance with embodiments of the invention is illustrated in FIG. 3. 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. [0051] In many embodiments, a new statement or information about a device may be submitted to the ledger by a DCL 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.
[0052] Although specific representations of ledger block structures are described above with reference to FIG. 3, 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.
USE CASES
[0053] Several embodiments of the invention aim to establish a level of trust in an identity associated with cryptographic keys by gathering information about these keys from, e.g., a ledger (aka blockchain). Specific examples include:
Example 1 : loT and Compliance Ledger
[0054] Several standards organizations are working on a mechanism to publish trusted information about device compliance, security level, resistance to vulnerabilities and general device description (aka“food label”) based on the blockchain technology. This solution creates a secure, machine-readable distributed database of device model information where manufacturers may publish device model information, certification labs or standards organizations may publish compliance and interoperability with specifications, and regulatory bodies may check compliance with regulations, without a central authority governing it all. A system like this is described in detail in PCT Patent Application Serial No. PCT/US 18/46,547 entitled“Systems and Methods for Rights Control of Network-Connected or loT Devices Using Information Stored In a Distributed Ledger” and filed August 13, 2018 (the‘547 patent), the relevant disclosure of which is hereby incorporated by reference in its entirety. Implementation details are public at the Verimatrix Veriteem project outlined in https://github.com/VehmatnxGen1/Veriteem. [0055] As information about a device model is published, certified by a compliance lab, and updated with security and software updates, such an unmodifiable sequence of transactions builds trust in a device over time. The opposite is also true since lack of information or compliance or updates decreases trust in a device.
[0056] There is no single source of trust, but rather a gradual building of trust by multiple entities attesting for each other. For instance, a standards organization approving multiple certification or compliance labs makes the labs more trustworthy. Or a test lab conducting tests of device interoperability and conformance to specification helps manufacturers build their reputation of having multiple compliant device models that are maintained with security patches over a long period of time.
[0057] Such information may be observed and used by end users before they decide to purchase a device. It can also be used by other devices, such as home gateways when they discover a new device on the network, which attempts to connect to the home domain, in order to verify its capabilities, compliance with standards and regulations, etc. Individual ecosystems may set up policies or requirements for which devices may join the ecosystem. For instance, a level of security that may be good enough for a backyard lighting system may not be sufficient for a commercial building security system.
[0058] The distributed nature of this mechanism may be even more important considering fragmentation in the loT industry, driven by the large number of loT standards, different government or international regulations, and the fact that many devices will likely interoperate with more than one standard and may fall under multiple regulatory policies. Again, such a diverse environment cannot be governed by a single private organization or governmental agency.
[0059] Without reliance on a central CA (certificate authority), a manufacturer may decide to create its own self-signed root certificate (e.g., X.509 format as specified here https://tools. ietf. org/htm i/rfc5280) and its corresponding key pair, which signs device model certificates, which in turn is used to sign individual device certificates. Since any legitimate or illegitimate manufacturer can do this, it is certainly not good enough, at least initially, to establish sufficient level of trust in the device. [0060] However, when a manufacturer is added to the blockchain by a trusted standards organization as a legitimate member company, the trust in such a self-signed certificate may increase. Once a device made by such a company is certified by a reputable test lab, the device model certificate trust increases. After enough information about all these entities is published on the blockchain, their certificates will gain collective trust without a centralized CA and may increase that trust as software updates are published and incremental compliance tests are passed.
[0061] As a specific example implementation, a home gateway detects a connection request from a new device on the home network. The request is accompanied by information about its model number, signed by the device private key and the certificate chain including the model certificate and manufacturer certificate attached. As the gateway has no prior relationship with the device manufacturer, it does not hold the device root CA certificate. The gateway connects to the blockchain (e.g., directly or via a proxy), looks up the device model, checks its certificate (or a corresponding hash), verifies device compliance and interoperability, further looks up the manufacturer record and the root certificate also included in the blockchain as in the exemplary visualization in Figures 6 and 8. If certificate information matches and compliance policies are satisfied, the gateway accepts the connection request and creates a secure TLS (transport layer security standard) channel (or equivalent) with the device. Furthermore, if the manufacturer or its certificate has been endorsed by a standards body or the device model certificate is included in the compliance record, the gateway’s trust in the authenticity of the device increases.
[0062] Standards organizations, industry alliances, compliance and certification labs, and regulatory bodies may include their certificates in the blockchain registration record as well. The more legitimate transactions they issue on the blockchain or are issued by others about them, the more their reputation increases and the more trustworthy their certificates are.
[0063] When a manufacturer is no longer a member of a standards organization, or a specific device model fails certification, or a particular version of software for that device or communication protocol (such as TLS) is vulnerable to a newly found attack, such entries may be added to the blockchain as well. They may decrease the trustworthiness in such a device until software updates are made available.
[0064] Alternatively, the manufacturer may decide to use a public certificate authority in which case the manufacturer certificate would be a sub-CA certificate signed by the public CA. In other words, each manufacturer is free to decide how to manage its own certificates or whether to use a third party to issue certificates.
[0065] The described system may be even more open. One could start a new organization or a consortium by adding it to the blockchain. Similarly, a device manufacturer or a service provider may add a record about itself to the blockchain. When that manufacturer joins the consortium, the consortium may create a transaction on the blockchain announcing that the manufacturer is an official member. The manufacturer may also add a transaction verifying that the compliance organization is a valid entity. As more and more manufacturers join the consortium, its reputation increases. Similarly, a manufacturer’s reputation increases if it is a member of multiple standards or consortia. Additionally, two or more standards organizations may create a liaison relationship and record it on the blockchain.
[0066] Figure 4 illustrates an example of relationships and responsibilities between entities in establishing certification of a device or certificate in accordance with several embodiments of the invention. This mesh-like arrangement, which can also be referred to as a trust graph, allows for revocation of certificates associated with the manufacturer or in general any entity on the blockchain. For instance, when a manufacturer produces noncompliant devices or it fails to provide a mandatory security software update, etc., the other entities can publish information to the blockchain to make these types of failures known. The standards organizations and/or test labs involved can enter information indicating the noncompliance on the blockchain. This may not represent a complete revocation of the certificate, but it certainly lowers the trust associated with the manufacturer’s devices. When multiple organizations do that, it may result in de-facto revocation. The transactions visualized in Figure 4 as well as other interactions with the ledger mentioned, are represented as digitally secured transactions, typically involving the use of acentric keys that help to establish identity as described herein. [0067] In many embodiments of the invention, each entity participating in these relationships may have its own certificate. Transactions that reference another entity not only by its identifier but also by its certificate (or at least its hash) may be more valuable. For instance, when a standards organization approves a test lab, it may include its certificate or hash in that transaction. In turn, when a test lab issues a compliance transaction about a specific device model, it may sign it using its private key. This mechanism makes it more difficult to issue fraudulent transactions in part because different keys are required to manage the certificates and blockchain access and may be secured independently to create additional hurdles to fraud.
[0068] In some embodiments, the mechanisms described above are used to help loT ecosystems to determine a level of trust in order to decide whether to add an otherwise unknown device to its network. One extreme is to handpick and pre-integrate a small number of devices up front; another one is to admit all devices. The former is expensive, does not scale and makes users unhappy by limiting choice; the latter results in unreliable, non-secure networks also resulting in unhappy users. Thus, the proposed solution creates a meaningful balance between scalability, security and usability, while leaving policy setting to each ecosystem. loT Rights Ledger
[0069] A variation to the compliance ledger case described above is a ledger that registers each device individually. Details on such an loT rights ledger are described in PCT Patent Application Serial No. PCT/US 18/46,547 entitled“Systems and Methods for Rights Control of Network-Connected or loT Devices Using Information Stored In a Distributed Ledger” and filed August 13, 2018 (the‘547 patent), the relevant disclosure of which is hereby incorporated by reference in its entirety. Similar to the above discussion, the trust can be established with a certificate that is endorsed by multiple other entities, but in addition to the trust in the device model that tries to estimate the device security and reliability, trust can also be determined for individual devices as the ledger history may also show information such as where and by whom and when it has been manufactured, helping to differentiate between devices within one model. In a related use case, the distribution chain may be identified and assigned more trust if handled by popular retailers with a high level of trust. Usage and history of ownership may indicate the use of the device, which may be important for devices with a limited live span and multiple untrusted users with control of the device may have had chances to tamper with the device which can decrease trust for some applications.
Example 2: Financial Transactions
[0070] For business transactions trust in another party is very important. The other party needs to be trusted with payment or delivery of good and services. Certificates can be used to represent other parties and the history of use of the certificates can evaluated to determine a level of trust in the business partner. For example, in consideration of a pending transaction a person selling goods is requesting a proof of control of an existing certificate for example by having a document signed electronically. The certificate is then evaluated by considering past use of the certificate as encoded in a distributed ledger, such as a bitcoin blockchain. The private key corresponding to the certificate may have been used in past transaction and the history of their size, date, frequency and/or credibility of counter parties can be used to estimate the reputation and trust in this party.
[0071] For example: has this certificate been used in transactions that have been publicly declared to be involved in illegal funds transfer e.g. used in a crime for which payment was used via bitcoin?
[0072] Flow often has the account been used? Total number of funds managed? Flas the used been continuously or spiked sporadically? The result of the comparison is similar to a credit score and can be used to establish trust to be compared to the trust needed to fulfill the intended transaction.
Example 3: Content Rights Ledger
[0073] Another blockchain ledger application is described in U.S. Patent Publication No. 2017/0116693 entitled“Systems and Methods for Decentralizing Commerce and Rights Management for Digital Assets Using a Blockchain Rights Ledger” and filed October 27, 2015, the relevant disclosure of which is incorporated by reference in its entirety. Parties transacting in this ledger are rights holders (such as content producers), resellers of content rights and end users that want to license, consume and possibly sell their content right. Each of these parties benefits from evaluating trust in a party before transacting with them. They would use the mechanism described here to evaluate if and how they would issue or pay for a license before transacting using the ledger.
Example 4: Domain Certificates
[0074] CAs are used today to establish trust in websites that browsers connect to using HTTPS. For example, if the domain at https://online.citi.com/ is using a certificate signed by Digitcert than it is assumed Digicert has done some diligence to verify that the key belongs to Citigroup, Inc., as stated in the certificate endorsed by digital signature from (or issued by) Digicert. This current system is placing binary trust into the certificate that will either warn the user of a missing root authority or assume the counterparty is as stated in the certificate. This binary trust is helpful, but security is never perfect and different levels of trust may apply. In certain embodiments of the current invention, the trust is determined with additional factors. In this example, the factors may be the credibility of the site, as measured by features such as its first appearance, how many other sites link to it and their trust level, its frequency of updates and the trust in partner sites that use certificates endorsed by the same root.
Example 5: Identity
[0075] Identity of individuals is often managed by centralized entities, such as the government that issues identification documents or companies that manage login credentials like e.g. Facebook. Credentials may be shared, possibly via a centralized marketplace like a TV Everywhere (https://en.wikipedia.org/wiki/TV_Everywhere) system. In this system the verification allows e.g. content providers like HBO to verify if a customer that wants to access their content is a paying cable TV subscriber and has therefor the right to access the content. Other systems allow verification of age, licenses or residence. [0076] In the approach proposed in several embodiments of the invention, identities are registered in the blockchain and gain value through either an entity that confirms at least parts of the ID like examples above and/or history and usage of the ID and transactions involved. IDs can be registered, and elements can be associated later, e.g. adding a birthdate to the identity or single elements are used differently, such that there is a different record for a person's age than birthplace, possibly with different visibility and access rights. Depending on the resulting level, trust in the ID possible actions may be to allow entry, access, operation or other decisions to the holder of the identity.
CALCULATION OF TRUST LEVELS
[0077] Trust, as mentioned above can be determined by several factors. Sample calculations on how to aggregate different factors are provided below.
[0078] In many embodiments of the invention, the overall trust level is a linear combination of elements of:
[0079] 1. The use of the signing key, or history H;
[0080] 2. Cryptographic statements about the signing key, certificate issuance or similar direct endorsements D;
[0081] 3. Information about transactions that have been signed with this key, T;
[0082] To be combined to derive a Trust Score or Trust Level = h*H + d*D + t*T;
[0083] Where h, d and t determine the importance of each factor and could be equal to 1/3 in a simple case. Alternatively, to control the range of values and create a final score within a predetermined interval, the factors are often and weighted differently before they are combined. Non-linear combinations are also possible. Example includes thresholding with required minimum or multiplicative interdependence between these values.
[0084] These factors can be determined as follows:
[0085] H History
[0086] In many embodiments, the history of the key including information such as, but not limited to, how often it has been used (e.g. average uses per year), time of first use (e.g., measure in months) and/or how regular the use has been (e.g., as standard deviation of intervals between uses) - habits. Other elements may include the standard deviation in transaction size it has been used in.
[0087] For example, on the keys that have been used to register devices into the loT ledger, more device registration, more regular registrations and registrations starting at an earlier date will contribute to a higher level of the history component in a final trust score.
[0088] D Direct Endorsements
[0089] In many embodiments, direct endorsements are given by other parties and can be measured additively by the quantity and trust level of endorsers. For example, a known CA will have a high level of trust which can be established from a prior trust in this CA and can be enhanced or replaced with determining the trust as described in embodiments of the invention.
[0090] For example, the keys that have been used to register devices into the loT ledger are highly trusted, if they have been signed by a known CA and by a trusted entity such as a compliance organization with a trusted score FI and T.
[0091] Endorsements may be negative if a trusted entity makes a negative statement about the key or user, including certificate revocation.
[0092] In several embodiments, the trust level for an individual identity from direct endorsements can be derived as a sum of the trust levels in the endorsers. Endorsers can be entities that have signed the certificate of the entity to be evaluated. In this way, any endorsers of any of the members of the certificate chain can be taken into account.
[0093] T Transactions
[0094] In many embodiments, the importance of transactions that have been signed by a key contributes to the trust in that key are a measure for past behavior.
[0095] For example, the keys that have been used to register devices into the loT ledger are trusted more if the transactions that they endorsed are also endorsed by other trusted organizations. Specifically, a manufacturer’s key gains trust if it is used to register a device that then is used in transactions by other trusted entities such as compliance organizations. The involvement of the certificate may be direct if it is used in the transaction, or indirect, if it is posted by an entity identified in a certificate or if it is posted by an entity identified in any of the certificates in the chain. [0096] Combinations of these values here serve as examples and many similar ways and combinations can be performed to calculate the level of trust. Machine learning models may help to calculate trust by determining a combination that matches the desired outcome. Typically, these are trained using a set of data that externally provides the desired outcome. These datasets may be derived and/or trained with information regarding trust observed from other source(s) or manual entry of the information.
[0097] Fig. 5 is a flow chart visually illustrating a process to determine the trust level of digital certificate(s) and how the levels H, D and T can be determined for a digital certificate in accordance with an embodiment of the invention. The digital certificate represents an identity and could be an x.509 certificate or could be reduced to an identifier of a device or person that is unique or pseudo unique such as a public key or hash code. In several embodiments, to determine the trust level for an individual certificate, trust levels in all certificates are determined. This can be done recursively to update trust levels across the certificates. This allows them to be used to evaluate the importance of transactions they are involved in to ultimately reflect back on a single certificate. Hence, in order to derive trust levels from an existing ledger, several iterations can be used to determine interdependencies of trust relationships. Alternatively trust levels can be added with each transaction that is added to the ledger. Specific steps in an example workflow are discussed below:
[0098] To determine the trust level derived from the history of a digital certificate (in 743), all transactions regarding this certificate are counted (741 ) and combined with the date of the earliest transaction (742). To determine D (in 747), all direct endorsements are evaluated according to their assigned trust. Note that in the first iteration these direct endorsements may have trust from a-priori knowledge externally derived (such as from a traditional CA) but not from derived trust. Derived trust will be used as the system has undergone several iterations (764) and derived trust is refined from aggregated trust for all participating certificates (763).
[0099] This is similar for the evaluation of the trust derived from counterparts of a relevant transaction that can be more meaningfully taken into account once all participants have a trust level derived. [00100] For this reason, the loop is performed repeatedly for all involved certificates using several iterations. The specific number of iterations to perform is a tradeoff between precision and available processing time. The results are typically stored and refined over time, and as new transactions occur, they can be evaluated based on the pre-calculated values.
[00101] Once all certificates have an assigned trust level derived in several iterations, the results can be used to evaluate individual certificates, determine their trust level and act accordingly.
[00102] Although processes are discussed above with respect to Figures 5, one skilled in the art will recognize that any of a variety of processes may be utilized in accordance with embodiments of the invention as appropriate to a particular application.
APPLICATION OF TRUST LEVELS
[00103] The trust level attributed to a key or certificate can be determined by an entity other than its owner in order to decide on the use in the key/certificate and its owner. If the trust level in this key or certificate is high because, e.g., it has been used correctly over time and the owner has been identified. The owner will be granted more rights. Examples include:
Trust in a Device
[00104] A device may require a trust level above a certain threshold (reputation or trust score) to be, e.g., allowed in a network, i.e. , a gateway is evaluating the trust, allowing communication of this device with the other devices in the network accordingly. The application is outlined in the Example 1 of loT Ledger above. Other elements read from the ledger that may be combined with the determined trust level are described in the ‘547 patent, incorporated by reference further above.
[00105] Other devices that this device is attempting to connect to can evaluate the trust in order to determine the level of information that would be provided to the device or commands that are accepted from this device. For example, a door lock may require a minimum trust to unlock, a lower level of trust to lock and yet a different level of trust to provide either battery status or usage history. Trust in a Business Partner
[00106] The trust can also be generalized and be applied to other kind of transactions and interactions. To conduct business, it is helpful to determine a trust level before an offer is made. Since interactions with trusted parties may be more reliable and involve less effort or risk, a trusted party may receive a different offer. Similarly, other decisions like the required prepayment, payment terms, size of the transaction may depend in the level of trust in the other party. For example, am order for goods and services may be placed depending on the trust in the account that is receiving the payments. If the transactions have not been associated with illegal transactions, have been regular with not too much variation, a volume above a certain threshold and the account has existed for a while the transaction may be preferred to choose a supplier with a new account or one that indicates sporadic transactions only.
PROCESSES FOR ESTABLISHING TRUST IN A DIGITAL CERTIFICATE USING A DISTRIBUTED CERTIFICATION LEDGER
[00107] Many embodiments of the invention involve writing information to and/or retrieving information from a distributed certification ledger using mechanisms such as those described further above. Processes for manipulating a distributed certification ledger in accordance with embodiments of the invention are discussed below with respect to Figures 6 and 7.
[00108] A process for entering information about a digital certificate into a distributed certification ledger (DCL) in accordance with an embodiment of the invention is illustrated in Figure 6. Parts of the process may be performed by a server or other machine in control or used by an entity. The process 600 includes generating (602) transaction data for a device or entity including a reference to the corresponding device or entity’s digital certificate, either a full copy of the certificate or at least a hash of the certificate. As discussed further above, this can be a manufacturer creating information such as a model number for a device which is represented by the digital certificate, a standards organization attesting that the manufacturer and/or device is a member of the organization, or a test lab certifying that the device is in compliance with a particular standard, (e.g. device mode compliance record, record about a manufacturer’s membership in a standards organization, liaison between two standards organizations, etc. Furthermore, these records may reference certificates associated with the entity being talked about (e.g. device model certificate, manufacturer certificate, standards organization certificate, respectively). Additional types of representations by any of a variety of entities may also be utilized in accordance with embodiments of the invention. Negative or neutral information may also be generated in additional embodiments. For example, decertification or deregistration of a device can be indicated by such information.
[00109] The process proceeds to write (604) the transaction data associated with the digital certificate to a distributed certification ledger. In many embodiments, this involves creating a new block in the ledger using mechanisms such as those described further above and in documents incorporated by reference herein.
[00110] FIG. 7 is a flow chart illustrating a process for retrieving information about a digital certificate from a distributed certification ledger (DCL) and establishing a trust level of the digital certificate in accordance with an embodiment of the invention. Parts of the process may be performed by a device or other machine in control or used by an entity. The process 700 includes receiving (702) a request for action, where the request includes one or more digital certificate(s). For example, one digital certificate may be signed by or associated with another. Furthermore, the digital certificate(s) may be received from another device. In several embodiments, the request for action is a request for permissions by an internet of things (loT) device, where they request for permissions may be any of a variety of functions, such as, but not limited to, allowing the loT device to access the local network, allowing commands received from the loT device to be executed, providing certain information to the loT device, or allowing the loT device to access a specified resource on the local network.
[00111] The process includes retrieving (704) information about the digital certificate(s) from a distributed certification ledger. As discussed further above, certification information in the digital ledger can be information about a device or manufacturer of the device, certification status of the device, or any of a variety of similar information pertaining to the device that can be used to formulate a trust level. [00112] In some embodiments, the process includes retrieving (706) information about the digital certificate(s) from additional sources. As discussed further above, additional sources can include certificate authorities or other centralized repositories.
[00113] The process includes establishing (708) a trust level in digital certificate(s) based on retrieved information. As discussed further above, a trust level can be calculated by a number of factors using information from the distributed certification ledger about the certificate in question. Various embodiments may include processes similar to that illustrated and described with respect to Figure 5 further above.
[00114] The process includes taking action based on the established trust level of digital certificate(s). The action can involve any of a variety of decisions, such as but not limited to those described further above, e.g., allowing access for a device to a router or network, connecting one device to another for control purposes, etc.
[00115] Although processes are discussed above with respect to Figures 6 and 7, one skilled in the art will recognize that any of a variety of processes may be utilized in accordance with embodiments of the invention as appropriate to a particular application.
Workflow
[00116] Figure 8 shows a sample interaction between different devices and the ledger as Device D2 is evaluating the trust to be placed in Device D1 in accordance with an embodiment of the invention. For this purpose, Device D1 presents its unique device certificate C1 that has been signed by owner of signing certificate S1 (which is also presented) and hence inherited the trust in S1. S1 may be a certificate used for many or all other devices of this model. The chain may extend to multiple predecessors, including, e.g., not only model certificates but, in a higher hierarchy, manufacturer certificates used for all models, as described in Fig 9 A and B.
[00117] Figure 9A illustrates a sample device manufacturer certificate hierarchy or chain in accordance with an embodiment of the invention. The certificates can be represented as: Device Cert = C, MRoot = Sa, BusCert = Sb, DeviceModel = Sc. In Figure 9A, the Device Certificate C is signed by the one Device Model Certificate Sc that is used for its model. Other Device Model Certificates may exist from one of several Business Unit Certificates Sb from a large Manufacturer represented by a Manufacturer root certificate Sa, which may be the top of this certificate hierarchy and self-issued by the Manufacturer or it may in turn be signed by a CA. The chain may also have branches in which one certificate is signed by multiple others or is used to sign several others.
[00118] In an alternative scenario Fig 9B the chain is shorter, and C is signed by Sc which in this case is the top of the chain. In a yet shorter version only a single certificate or key pair is used to identify a ledger participant, as is the case in bitcoin transactions. It can also be useful case in an loT rights ledger (as described in the‘547 patent) in which every device (not only device models) has its own identity and its history is observed only by actions on this device as in example above.
[00119] Returning now to Figure 8, to decide the trust in signing certificate S1 (and hence device D1 ), the ledger L1 is queried about S1 with factors such as, but not limited to: What other models have been registered by S1 , how they have been certified, rated, reviewed and/or if S1 or any of the certificates signed with it or any signers of it have ever been revoked. This query may be using the public key in the certificate, a blockchain key derived from it, or information such as make and model name communicated in the certificate S1 or C1. In case the name is used without the cryptographic identity using the keys or certificates, the device is trusted to report the correct name because, e.g., it may have been purchased from a trusted dealer or has physical features that allow some authenticity verification.
[00120] The device presenting C1 as its identity can be commonly verified to be the holder of the private key corresponding to the public key in the certificate by a cryptographic challenge such as encrypting a given piece of information.
[00121] Figure 10 is a communication sequence diagram illustrating a process for determining trust between devices using a DCL in accordance with an embodiment of the invention. Illustrated are communications between Device D1 , Device D2, certificate ledger CL and potentially other devices. Device D1 attempts to establish a level of trust with device D2. Device D1 provides its ID along with certificates, if available: C1 (D1 Cert), and S1 to the verifying device D2. In additional embodiments, S1 may include not only the direct signing certificate but can be extended to the complete certificate chain, including entities in Fig. 9A. D2 then queries the ledger for history and use of collected information concerning D1. This query can rely on the identity provided by device D1 and the C1 and S1 certificate if provided in previous step. Note that the process can also be valuable when only the device ID is provided by D1 , if it can be sufficiently trusted. With the provided information, D2 can determine trust factors such as, but not limited to, if this model has been tested to meet industry standards, if firmware updates are available or have been made available in the past, if the certificate has been used for other models or if a certificate has been revoked. Additionally the evaluation is not limited to S1 but can include other certificates in the complete chain, including digital certificates of, e.g., manufacturer and root CA.
[00122] In additional embodiments, D2 may also query other sources such as a traditional CA to access a certificate revocation list (CRL), other ledgers, its own history of devices approved externally and using comparable credentials, or databases for trust factors for D1 , S1 , or C1. D2 can use this information to establish a trust level and to compare this against a required trust level specified in its policy and will accept or reject the D1s request based upon the trust level. The policy may be preprogrammed in the device D2 or derived from a trusted source by D2. It may be set statically and change infrequently or be dynamic, e.g., relative to the other devices such that the, e.g., 85% most trusted devices are allowed in the network.
COMPARISON TO CONVENTIONAL PKI
[00123] A similar outcome, to establish trust in a digital identity, can be established with a Certificate Authority (CA): an entity which is trusted by all transaction partners. Some differences to the systems described are described below. This is helpful to outline novel elements of the proposed solution, but various embodiments of the invention can include hybrid approaches that either leverage some or all components of each approach.
Certificate Validation
[00124] In the PKI (public key infrastructure) world, the trust is established between an end-user and a relying (or verifying) party via trusted third party (i.e. Certification Authority). The relying party should verify the validity by checking if a certificate has been revoked, by reviewing Certificate Revocation Lists (CRLs) e.g. using OCSP (online certificate status protocol) servers provided by the Certification Authority prior to trusting the end-user certificate. If the end-user certificate is issued by an intermediate CA (i.e. Sub CA), then the relying party should download them as well until the full certificate chain is available for certificate chain validation. But whereas with the ledger system, just one entity provides the certificate health status (i.e. Good or Bad) and ranks the given device based on the device health. Relevant information is retrieved from published information on the ledger.
1-to-N communication
[00125] When a relying party tries to establish communication with multiple end users, the relying party should contact each corresponding certification authority to make sure given end-entity certificate and intermediate CA (i.e. Sub CA) certificates are valid prior to the transaction, requiring multiple connections to different locations for lookup whereas, on the contrary, a ledger node in accordance with embodiments of the invention has all information in one place.
Root CA Key Compromise Impact
[00126] One of the major drawbacks of the traditional CA in a PKI environment is that when the root key is compromised, a hacker gains very broad control over the system including ability to change the revoked certificate serial number details on the CRL/OCSP system, issue digitally signed OCSP responses, issue fake certificates, back date the timestamps (i.e. Not Before and Not After certificate fields). But whereas a ledger system in accordance with embodiments of the invention its highly impossible to change the hash of each ledger node as the system is distributed across the network which is computationally take more time and effort and uses systems to prevent a single party from applying modifications easily. This distribution can be accomplished with, e.g., mechanisms of proof of work, stake, authority, or elapsed time. Speed of Update in CA system
[00127] In PKI, validity of a given certificate is based on the CRL/OCSP time stamps (e.g., fields of Effective date and Next update) updated by the Certification Authority. A relying party needs to trust the end-user certificate until the next update by the Certification Authority. There are ample chances for a given certificate to be revoked between last update and the next update. Even though certificate is revoked, still relying party gets the certificate status as“Good” from the CRL/OCSP system. But whereas on the blockchain model in accordance with embodiments of the invention, hashing and timestamps are available by design and for each transaction timestamps gets updated on the entire chain right after the closing of a block. Hence, the relying party can verify the certificate health and status of the certificate any time on the ledger system and updates occur regularly and frequently.
CRL/OCSP system availability
[00128] When a CRL or OCSP goes offline then it is a single point of failure. Until the system is available there is no way to validate the client certificate validity. But whereas the distributed ledger in accordance with embodiments of the invention, there is no dependency on CA or trusted authority to provide reliable information. It is distributed and many different nodes provide the information and no single node can stop the system. Hence the distributed ledger eliminates the single point of failure.
Need for Trusted Third Party (TTP)
[00129] In the CA system there is a need for a TTP (Trusted Third Party) to verify client certificate is valid prior to the transaction or communication. But whereas in the distributed ledger in accordance with embodiments of the invention, there is no need of the central authority, a party can always validate the client transaction using the distributed ledger. ADDITIONAL IMPLEMENTATION CONSIDERATIONS
Application to Blockchain Nodes
[00130] Trusts graphs, as discussed further below, can also be applied to assign levels for each participating blockchain node and derive actions accordingly. In several embodiments, nodes are network components that store a copy in the ledger. They help in distributing the ledger and building the consensus and commonly participate in the consensus. Their reputation can be derived from observation no how current they keep their ledger status, if they participate in consensus and what transactions they originate.
Proxy
[00131] Evaluation of the blockchain may be performed directly by the evaluating entity such as a device, by running a full blockchain node that has record of the complete transaction history. Alternatively, that information can be access from a trusted node that provides all relevant transaction for evaluation. In certain embodiments, however, this trusted node will not only provide relevant transactions but provide a more aggregated result such as an actual trust score for the evaluated key, possibly variations according to different measures or already thresholded, indicting suitability for certain uses. These may be accessible using a remote API and provided as a service by 3rd parties. These API can enrich the data with outside sources about the identity in question and provide this information in detail or aggregated within an enhanced trust score. Outside information includes public databases, web searches, past queries from this or about this identity to this service. Additional discussion of proxy use in accessing a blockchain ledger that may be utilized in accordance with embodiments of the invention can be found in the‘547 patent incorporated by reference above.
[00132] 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 loT (internet of things) access controller device comprising:
a processor;
a network interface;
a non-volatile memory containing an application to quantify a trust level in a digital certificate causing the processor to perform the steps of:
receiving a request for permissions on a local network from an loT device, where the request includes a digital certificate chain, where the digital certificate chain includes a digital certificate associated with the loT device and one or more digital certificates in a hierarchy associated with the digital certificate associated with the loT device;
scanning a distributed certification ledger (DCL) for past transactions related to the digital certificates of the digital certificate chain in order to:
retrieve transaction data comprising information characterizing past usage of any of the digital certificates in the digital certificate chain in transactions in the DCL, and information about transactions including the digital certificate that have been posted to the DCL by another trusted entity;
calculate a trust level in the digital certificates in the digital certificate chain including the digital certificate associated with the loT device, based on the retrieved transaction data;
determine whether to proceed with granting the requested permissions based on the calculated trust level;
grant the requested permissions when the determination to proceed with the requested action is affirmative based on the calculated trust level.
2. The loT (internet of things) access controller device of claim 1 , where the digital certificate within the request for permissions on a local network is signed by a signing key and certification data further comprises information about the signing certificate associated with the signing key.
3. The loT (internet of things) access controller device of claim 2, where the calculated trust level is higher when considering factors including frequency of use of the signing key, distribution of use of the signing key over time, and use of the signing key in important transactions.
4. The loT (internet of things) access controller device of claim 1 , where the calculated trust level is higher when a cryptographic statement about the signing certificate is a signature using a trusted key endorsing the signing certificate.
5. The loT (internet of things) access controller device of claim 2, where the application further causes the processor to: determine an additional trust level for the signing certificate associated with the signing key iteratively using transaction data retrieved for the signing certificate.
6. The loT (internet of things) access controller device of claim 1 , where the calculated trust level is higher when the signing certificate is used in transactions that have been signed by other trusted users.
7. The loT (internet of things) access controller device of claim 1 , where the request for permissions is a request for access to the local network.
8. The loT (internet of things) access controller device of claim 1 , where the request for permissions is a request to execute commands.
9. The loT (internet of things) access controller device of claim 1 , where the request for permissions is a request for information.
10. The loT (internet of things) access controller device of claim 1 , where the request for permissions is a request for access to a resource on the local network.
11. The loT (internet of things) access controller device of claim 1 , where the application further causes the processor to: retrieve information about the digital certificate from another source besides the distributed certification ledger.
12. The loT (internet of things) access controller device of claim 1 , where the certificate chain is processed according to rules specified in the x.509 format.
13. The loT (internet of things) access controller device of claim 11 , where the another source is a certificate revocation list.
14. The loT (internet of things) access controller device of claim 13, where the another source is an OCSP server.
15. The loT (internet of things) access controller device of claim 11 , where the application further causes the processor to: retrieve information about whether a trusted entity has signed a digital certificate in the digital certificate chain.
PCT/US2019/018641 2018-02-16 2019-02-19 Systems and methods for decentralized certificate hierarchy using a distributed ledger to determine a level of trust WO2019161412A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862710484P 2018-02-16 2018-02-16
US62/710,484 2018-02-16

Publications (1)

Publication Number Publication Date
WO2019161412A1 true WO2019161412A1 (en) 2019-08-22

Family

ID=67619628

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/018641 WO2019161412A1 (en) 2018-02-16 2019-02-19 Systems and methods for decentralized certificate hierarchy using a distributed ledger to determine a level of trust

Country Status (1)

Country Link
WO (1) WO2019161412A1 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112422289A (en) * 2020-09-30 2021-02-26 郑州信大捷安信息技术股份有限公司 Method and system for offline security distribution of digital certificate of NB-IoT (NB-IoT) terminal equipment
WO2021059057A1 (en) * 2019-09-23 2021-04-01 nChain Holdings Limited Computer implemented method and system for storing certified data on a blockchain
US20210166225A1 (en) * 2017-12-14 2021-06-03 Kroin Ag Method for controlling transactions in a distributed ledger
US20210176075A1 (en) * 2019-12-09 2021-06-10 Samsung Electronics Co., Ltd. Cryptographic communication system and cryptographic communication method based on blockchain
GB2596335A (en) * 2020-06-25 2021-12-29 British Telecomm Network access determination for user device
CN114189341A (en) * 2021-12-10 2022-03-15 北京泰尔英福科技有限公司 Digital certificate hierarchical processing method and device based on block chain identification
US11522670B2 (en) * 2019-12-04 2022-12-06 MaataData, Inc. Pyramid construct with trusted score validation
WO2023279059A3 (en) * 2021-06-30 2023-02-23 Artema Labs, Inc Distributed ledgers with ledger entries containing redactable payloads
US11683185B2 (en) * 2020-02-06 2023-06-20 International Business Machines Corporation Entity certification management
US11856109B2 (en) * 2020-02-06 2023-12-26 International Business Machines Corporation Entity certification management

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016178127A1 (en) * 2015-05-03 2016-11-10 Arm Technologies Israel Ltd. System, device, and method of managing trustworthiness of electronic devices
US20160337127A1 (en) * 2015-05-14 2016-11-17 Verizon Patent And Licensing Inc. IoT COMMUNICATION UTILIZING SECURE ASYNCHRONOUS P2P COMMUNICATION AND DATA EXCHANGE
US20170116693A1 (en) * 2015-10-27 2017-04-27 Verimatrix, Inc. Systems and Methods for Decentralizing Commerce and Rights Management for Digital Assets Using a Blockchain Rights Ledger
US20170221288A1 (en) * 2016-02-02 2017-08-03 David Johnson Decentralized virtual trustless ledger for access control
US20170331896A1 (en) * 2016-05-13 2017-11-16 De La Rue International Limited Methods and systems for processing assets

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016178127A1 (en) * 2015-05-03 2016-11-10 Arm Technologies Israel Ltd. System, device, and method of managing trustworthiness of electronic devices
US20160337127A1 (en) * 2015-05-14 2016-11-17 Verizon Patent And Licensing Inc. IoT COMMUNICATION UTILIZING SECURE ASYNCHRONOUS P2P COMMUNICATION AND DATA EXCHANGE
US20170116693A1 (en) * 2015-10-27 2017-04-27 Verimatrix, Inc. Systems and Methods for Decentralizing Commerce and Rights Management for Digital Assets Using a Blockchain Rights Ledger
US20170221288A1 (en) * 2016-02-02 2017-08-03 David Johnson Decentralized virtual trustless ledger for access control
US20170331896A1 (en) * 2016-05-13 2017-11-16 De La Rue International Limited Methods and systems for processing assets

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ABEYRATNE ET AL.: "Blockchain ready manufacturing supply chain using distributed ledger", INTERNATIONAL JOURNAL OF RESEARCH IN ENGINEERING AND TECHNOLOGY, vol. 5, no. 9, September 2016 (2016-09-01), pages 1 - 10, XP0055541754 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210166225A1 (en) * 2017-12-14 2021-06-03 Kroin Ag Method for controlling transactions in a distributed ledger
WO2021059057A1 (en) * 2019-09-23 2021-04-01 nChain Holdings Limited Computer implemented method and system for storing certified data on a blockchain
US11522670B2 (en) * 2019-12-04 2022-12-06 MaataData, Inc. Pyramid construct with trusted score validation
US20210176075A1 (en) * 2019-12-09 2021-06-10 Samsung Electronics Co., Ltd. Cryptographic communication system and cryptographic communication method based on blockchain
US11722316B2 (en) * 2019-12-09 2023-08-08 Samsung Electronics Co., Ltd. Cryptographic communication system and cryptographic communication method based on blockchain
US11683185B2 (en) * 2020-02-06 2023-06-20 International Business Machines Corporation Entity certification management
US11856109B2 (en) * 2020-02-06 2023-12-26 International Business Machines Corporation Entity certification management
GB2596335A (en) * 2020-06-25 2021-12-29 British Telecomm Network access determination for user device
CN112422289A (en) * 2020-09-30 2021-02-26 郑州信大捷安信息技术股份有限公司 Method and system for offline security distribution of digital certificate of NB-IoT (NB-IoT) terminal equipment
CN112422289B (en) * 2020-09-30 2022-02-22 郑州信大捷安信息技术股份有限公司 Method and system for offline security distribution of digital certificate of NB-IoT (NB-IoT) terminal equipment
WO2023279059A3 (en) * 2021-06-30 2023-02-23 Artema Labs, Inc Distributed ledgers with ledger entries containing redactable payloads
CN114189341A (en) * 2021-12-10 2022-03-15 北京泰尔英福科技有限公司 Digital certificate hierarchical processing method and device based on block chain identification

Similar Documents

Publication Publication Date Title
US11025435B2 (en) System and method for blockchain-based cross-entity authentication
US11038670B2 (en) System and method for blockchain-based cross-entity authentication
WO2019161412A1 (en) Systems and methods for decentralized certificate hierarchy using a distributed ledger to determine a level of trust
US11477032B2 (en) System and method for decentralized-identifier creation
US20240144280A1 (en) Blockchain architecture with record security
CA3015695C (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
WO2021000419A1 (en) System and method for blockchain-based cross-entity authentication
Kuhn et al. Introduction to public key technology and the federal PKI infrastructure
WO2019033116A1 (en) Systems and methods for rights control of network-connected or iot devices using information stored in a distributed ledger
JP2023503607A (en) Method and device for automatic digital certificate verification
US11863689B1 (en) Security settlement using group signatures
Garba et al. LightLedger: a novel blockchain-based domain certificate authentication and validation scheme
Saleem et al. ProofChain: An X. 509-compatible blockchain-based PKI framework with decentralized trust
Heiss et al. Non-disclosing credential on-chaining for blockchain-based decentralized applications
Riad et al. A blockchain‐based key‐revocation access control for open banking
US11283623B1 (en) Systems and methods of using group functions certificate extension
Gallersdörfer et al. Mirroring public key infrastructures to blockchains for on-chain authentication
Mohammadzadeh Invoice factoring through blockchain technology
CN116012009A (en) Block chain-based transaction verification method, device, electronic equipment and readable medium

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19754089

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19754089

Country of ref document: EP

Kind code of ref document: A1