CN115701301A - 在企业环境中区块链，管理组权限和访问的集成 - Google Patents

在企业环境中区块链，管理组权限和访问的集成 Download PDF

Info

Publication number
CN115701301A
CN115701301A CN202180037927.0A CN202180037927A CN115701301A CN 115701301 A CN115701301 A CN 115701301A CN 202180037927 A CN202180037927 A CN 202180037927A CN 115701301 A CN115701301 A CN 115701301A
Authority
CN
China
Prior art keywords
blockchain
token
user
access
key
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202180037927.0A
Other languages
English (en)
Inventor
乔纳森·安德鲁·克罗克特·摩尔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Spectaco
Original Assignee
Spectaco
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 Spectaco filed Critical Spectaco
Priority to CN202310124137.7A priority Critical patent/CN116112274B/zh
Publication of CN115701301A publication Critical patent/CN115701301A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • 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/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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
    • 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/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

定义对机密数据的权限和访问的区块链可以不是加密的，对区块链的访问可以由区块链本身和在企业信息技术(IT)环境中运行的访问控制服务器进行监管。为了包含在多个来源(例如区块链和访问控制服务器)中定义的权限，可以创建一个包含来自多个来源的多层许可(即约束)的令牌。每个额外的许可都会减弱的令牌授予的权限。当控制对区块链的访问的处理器接收到令牌时，处理器可以检查令牌的有效性和由令牌授予的权限，以确定请求者是否被授权访问区块链的至少一部分。

Description

在企业环境中区块链，管理组权限和访问的集成
相关申请交叉引用
本申请要求2020年3月24日提交的美国专利申请号16/828,003的优先权和权益，其通过引用整体并入本文。
技术领域
本申请涉及管理对安全文件系统的访问，更具体地，涉及在企业环境中管理组权限和对安全文件系统的访问的方法和系统。
背景技术
我们的计算系统今天面临的主要问题是内部威胁——即来自我们依赖集中式基础架构以及管理和提供它的人员的威胁——是整体威胁模型的一部分。根据微软SharePoint管理员角色文档，“全局管理员和SharePoint管理员没有对所有站点和每个用户的OneDrive的自动访问权，但他们可以给予自己对任何站点或OneDrive的访问权”。我们当前的基础架构方法通过管理员集中管理和提供安全性和访问控制，使人们能够访问信息而无需知道该信息。因此，无权读取存储在他们管理的服务器上的数据的管理员在没有权限的情况下仍然可以访问并读取数据。
概述
本文提供的是一种系统，该系统通过仅将访问权授予被授权访问文件系统的用户来管理安全文件系统和访问文件系统的权限。授予用户的访问权不能超出用户的权限。系统内的用户是使用每个用户独特的密码化密钥来标识的。以线性序列记录用户的权限，类似于分布在多个设备中的区块链。多个设备中的每一个独立地验证线性序列中每个区块的有效性，从而防止失陷(compromised)的中央服务器授予未经授权的访问。线性序列的有效性是通过防止对线性序列进行某些操作来保证的，例如线性序列的分支，线性序列中的区块的删除，以及线性序列中的区块的修改。在向线性序列添加新区块之前，系统中的每个设备都独立计算区块的有效性，以确保请求添加区块的用户具有将区块添加到线性序列的权限，更具体地，执行区块内容规定的操作的权限。
区块链本身可以不是被加密的，对区块链的访问可以由区块链本身和在企业信息技术(IT)环境中运行的访问控制服务器来监管。为了包含在多个来源(例如区块链和访问控制服务器)中定义的权限，可以创建包含来自多个来源的多层许可(即约束)的令牌。每个额外的许可都会减弱的令牌授予的权限。当控制对区块链的访问的处理器接收到令牌时，处理器可以检查令牌的有效性和令牌授予的权限，以确定请求者是否被授权访问区块链的至少一部分。
附图说明
图1示出了在去中心化环境中管理组权限和对密码化安全数据的访问的系统。
图2示出了团队线性序列和空间线性序列。
图3示出了团队线性序列和空间线性序列之间的线性排序。
图4示出了区块的构成。
图5示出了对可存在在系统内的多层策略的验证。
图6示出了系统内存在的多种密码化ID。
图7示出了如何将区块分布到多个设备。
图8示出了包含区块的线性序列。
图9示出了团队线性序列和空间线性序列。
图10A-B示出了在恶意行为者试图渗入系统的情况下的权限计算。
图11A-C示出了如何通过权限撤销控制对加密数据的访问。
图12是通过分布式账本管理权限的方法的流程图，该方法与一个或多个受信设备对加密数据的访问分开，其中受信设备中的每一个对应于至少一个基于密码化密钥的身份。
图13是使用分布式账本管理对加密数据的访问的方法的流程图。
图14示出了根据一个实施例如何将安全文件系统集成到企业信息技术(IT)基础架构中。
图15示出了根据另一实施例如何将安全文件系统集成到企业IT基础架构中。
图16A示出了如何使用区块链来实现时钟(clock)。
图16B示出了时钟区块链的内容。
图17示出了密码化树。
图18示出了令牌的构成。
图19示出了防止重放攻击的令牌。
图20示出了如何使用恢复密钥(recovery key)。
图21示出了当用户设备失陷时限制对加密数据的攻击的拆分密钥系统。
图22示出了对区块链语义解释的更新。
图23是生成提供权限凭证的令牌的方法的流程图。
图24是创建减弱的令牌(attenuated token)的方法的流程图。
图25是计算机系统2500的示例形式的机器的图示代表，其中可以执行一组指令，用于使机器执行本文讨论的方法或模块中的任何一个或多个。
具体实施方式
在去中心化环境中管理组权限和对安全数据的访问
图1示出了在去中心化环境中管理组权限和访问密码化安全数据的系统。服务器100与多个设备110，120，130，140，150(也称为端点)通信。设备110-150中的每一个可以分别与例如Alice，Bob，Carol，Dave，Ellen之类的实体或用户相关联。如本申请后面所述，每个用户Alice-Ellen可以具有独特的密码化用户标识(“ID”)，并且每个设备都可以具有独特的密码化设备ID。每个密码化用户ID可以有一个或多个与它相关联的密码化设备ID。
独特的密码化用户ID可以分成团队，例如团队1和团队2，如图1所示。例如，Alice，Bob和Carol的密码化用户ID可以是团队1的成员，而Dave和Ellen的密码化用户ID可以是团队2的成员，如图2所示。团队1和团队2可以具有互相排斥的成员资格，如图1所示，或者可以有部分重叠的成员资格。团队成员资格可以以线性序列记录，例如团队线性序列160，170(为了简洁仅标记团队线性序列的一个实例)。每个团队1，2可以分别具有一个团队线性序列160，170。线性序列，例如团队线性序列160，170和空间线性序列190，192，194，是类似于账本的密码化数据结构。因为线性序列可以被分布在多个设备上，每个设备独立验证线性序列，线性序列可以代表分布式账本。
每个团队1，2可以具有一个或多个空间180，182，184(为简洁起见，仅标记空间的一个实例)。每个空间180，182，184可以是虚拟隔间，该虚拟隔间包含加密数据和有权访问加密数据的成员。团队成员的子集可以被包括在一个或多个空间180，182，184中，并且被给予访问与一个或多个空间180，182，184相关联的加密数据的权限。例如，团队1有空间180，所有团队成员Alice，Bob和Carol都被邀请到空间180。在另一个示例中，团队2有空间182和184。空间182只有Dave作为成员，而空间184有Dave和Ellen作为成员。每个空间180，182，184可以具有只能由空间成员访问的加密数据。加密数据可以包括内容或数据，或两者。例如，加密数据可以包括文件，文件系统，文档，和/或消息，例如即时消息，电子邮件，聊天消息，文本消息等。
在一个示例中，只有用户Alice，Bob，Carol对与空间180相关联的加密数据具有权限。在另一个示例中，只有用户Dave对与空间182相关联的加密数据具有权限，而用户Dave和Ellen都具有访问与空间184相关联的加密数据的权限。加密数据的权限可以包括读取，写入，和/或修改加密数据的许可。在验证请求访问的密码化用户ID具有包括该访问的权限后，可以授予对加密数据的该访问。
例如，用户Ellen的密码化用户ID可以具有读取加密数据的权限。但是，如果用户Ellen的密码化用户ID请求写入加密数据，则用户Ellen的密码化用户ID将被否定写入加密数据的访问，因为用户Ellen的密码化用户ID缺少权限。换句话说，本文公开的系统中，对加密数据的访问不能超出与加密数据相关联的权限。
在另一个实施例中，团队1，2不存在，并且用户可以被分组到一个或多个空间180，182，184中。要生成空间，可以搜索系统中存在的密码化用户ID的普通池以定义空间的成员。团队线性序列160，170可以集成到相应的空间线性序列190，192，194中(为简洁起见，仅标记空间线性序列的一个实例)。例如，空间线性序列190可以包括团队线性序列160和空间线性序列192，空间线性序列192可以包括团队线性序列170和空间线性序列192，而空间线性序列194可以包括团队线性序列170和空间或列表194。
如本申请中进一步所述的，与加密数据相关联的权限的记录可以通过组合团队线性序列160，170和对应的空间线性序列190，192，194来计算。除了存储权限和成员资格之外，空间线性序列190，192，194还可以存储加密数据和/或对加密数据的引用。
可以将团队线性序列160，170和空间线性序列190，192，194的副本分布到其密码化用户ID是相应团队和空间的成员的所有设备110-160以及服务器100。例如，设备110-130具有团队线性序列160和空间线性序列190的副本，因为与设备110-130相关联的密码化用户ID是团队2和空间180的成员。在另一个示例中，设备140具有团队线性序列170和空间线性序列192和194的副本，因为与设备140相关联的用户Dave的密码化用户ID是团队2和空间182，184的成员。在第三个示例中，设备150具有团队线性序列170和空间线性序列194的副本，因为与设备150相关联的用户Ellen的密码化用户ID是团队2和空间184的成员。
团队线性序列160，170和空间线性序列190，192，194中包含的元数据可以以明文形式存储，而其余数据可以被加密。元数据可以包括存储在团队线性序列160，170和空间线性序列190，192，194内的权限信息，策略信息，角色等。数据的其余部分可以包括机密数据，例如文件，文件系统，消息，和/或其他机密数据。例如，如果加密数据包括文件和/或文件系统，则文件名可以是机密数据的一部分。只有知道用于加密该数据的加密密钥才能访问文件系统，文件，和/或消息。即使攻击者成功得到加密密钥，用户的私钥，和/或被授权的端点设备的控制，系统的失陷也将受到限制。
例如，如果攻击者得到了与空间182相关联的密码化密钥的控制，则攻击者将只能访问空间182内的机密数据，而不能访问空间184和180内的机密数据。如果攻击者获得Ellen的私钥，则攻击者将只能访问空间184内的机密数据，而不能访问空间180和182。因此，通过划分权限和对空间180，182，184的访问，可以限制对系统的破坏。
图2示出了团队线性序列和空间线性序列。团队线性序列200可用于跟踪团队成员的身份和他们在团队中的权限。空间线性序列210可用于形成可接纳团队成员子集的安全隔间。安全隔间用于管理数据并在空间成员之间协商共享密钥。团队线性序列200可以连接到包含系统策略的程序220，以及连接到包含事实的数据库230。空间线性序列210可以依赖团队线性序列200来确定空间内的策略。空间线性序列210可以连接到包含事实的数据库250。
团队线性序列200和空间线性序列210各可包含多个区块205，207，209，215(为了简洁起见，仅标记了4个)。团队线性序列200的初始区块205可以定义团队的策略。策略可以规定角色和与角色相关联的权限。例如，策略可以规定“只有管理员可以在团队中创建空间”。团队策略可以从存储在策略数据库中的策略模板获得和/或可以在实例化第一区块205时被修改。或者，第一区块205可以定义团队策略而不参考策略模板。可以在不同团队之间共享策略程序220。然而，不同的团队可以具有不同的事实数据库230。如果团队策略定义区块205许可修改，则团队策略也可以由添加到团队线性序列200的后面的区块修改。
策略程序220可以存储策略模板，该策略模板可以被包括和/或修改为初始区块205中的策略。事实数据库230可以包含可以定义系统内的用户和用户权限的独特的键值对。例如，在规定Alice是管理员的区块已经被验证之后，可以添加到事实数据库200的键值对可以是“Alice-管理员”。
团队线性序列200的区块207可以包括作为团队200的成员的用户的简档。用户简档可以包括用户的身份240，其可以由密码化用户ID代表，例如在诸如Rivest-Shamir-Adleman(RSA)或Diffie Heilman(DH)的非对称密码化算法中的公钥。只有用户才能拥有私钥。用户简档还可以包括与用户已批准的所有设备相关联的密码化设备ID 242，244。
可以通过多种方式将设备添加到系统中。例如，用户可以通过发送将设备添加到系统的请求来批准设备，其中使用用户的私钥对请求进行签名。在另一个示例中，为了批准设备，用户可以执行多步骤过程。第一步，用户可以使用非对称密码化算法创建一组新的设备密钥。第二步，用户可以用自己的私钥对设备密钥进行签名，并构造包含设备公钥和用户私钥签名的设备证书。在第三步中，设备可以发送请求，其中包括来自第二步的证书，以添加到团队中，其中使用设备私钥对请求进行签名。系统可以通过使用用户的公钥验证请求来认证团队成员是否提出了请求。密码化设备ID可以是非对称密码化算法的公钥的密码化哈希(hash)，而私钥可以只有设备知道，并且可以用于认证设备执行的动作。
团队线性序列200的区块209可以包括例如添加新用户，创建空间线性序列210，改变策略205，移除现有用户，和/或改变用户角色的事件。
空间线性序列210的区块215可以包括例如将用户添加到空间，将加密数据添加到空间，将用户从空间中移除等事件。空间线性序列210中的每个事件215符合团队线性序列200中定义的策略。在一些实施例中，策略不能在空间线性序列210中改变并且必须在团队线性序列200中改变。通过定义不同策略的多种空间类型，一个团队可以有不同策略的多个空间，并确立不同空间类型对应的空间。例如，空间类型可以包括“管理员空间类型”，其中所有用户都具有管理员角色，管理员添加和移除其他用户，并且可以对加密数据进行读写访问。在另一个例子中，空间类型可以包括“分层空间类型”，其中一些用户具有管理员角色，而一些用户具有用户角色，并且管理员角色比用户角色具有更多权限。改变用户权限的团队线性序列210中的事件可以存储在事实数据库250中。
可以定义用户策略205以使匹配某些属性的用户能够在有限的时间内仅有权访问空间线性序列210和空间加密数据。时间的流逝可以通过始终递增的时钟来测量，该时钟可以为空间线性序列210中的每个区块215提供时间戳260，270，280，290。例如，时间戳260可以声明“2019年11月21日上午11:46(太平洋时间)”。在空间线性序列210中，时间戳260，270，280，290总是在后续区块之间进行增加。为了实现对空间线性序列210和相关联的加密数据的受时间限制的访问，用户策略205可以声明“与简档1相关联的用户可以有权访问线性序列，直到2019年12月2日”。
图3示出了团队线性序列和空间线性序列之间的线性排序。因为至少部分定义权限的策略存储在团队线性序列310中，为了计算空间线性序列300中的权限，需要对团队线性序列310进行引用。
例如，在空间线性序列300的区块320中，空间的用户请求添加另一个用户。在团队线性序列310的区块330中，策略定义了空间用户添加另一个空间用户的权限，但是在团队线性序列310的区块340中，修改策略以防止空间用户添加其他空间用户。为确定区块320是否有效并应被加入到空间线性序列300，需要确立团队线性序列310中的区块330，340和空间线性序列300中的区块320，350，360的线性序列。
为了确立线性序列，可以在空间线性序列300中的区块320，350，360和团队线性序列310中的区块330，340之间确立临时关系370，380，390。临时关系370，380，390可以包括从空间区块320，350，360到作为空间区块320，350，360的紧接的前驱或紧接的后继的团队区块的指针。在图3中，临时关系370，380，390从空间区块320，350，360指向紧接在前的团队区块。例如，临时关系370，380表示团队区块330是空间区块320，350的紧接的前驱，这意味着空间区块320，350是在团队区块330之后但在团队区块340之前创建的。类似地，临时关系290表示空间区块360是在团队区块340之后创建的。
图4示出了区块的构成。区块400，410可以包含一个或多个事件1-6。区块400，410中的事件1-6可以是原子的。每个事件1-6在单个区块400，410中被落定(commit)。
事务可以包括一个或多个事件，其中最末事件被签名。事务可以由单个客户端产生，例如图1中的客户端110。当事务包含多个事件时，例如包含事件1和2的事务1，这些事件可以在被发送到服务器之前由客户端排序。使用箭头420，430，440，450表示事件的排序。在从多个客户端接收到事务1-4时，服务器可以根据箭头420，430，440，450表示的次序对事务进行排序。
单个事务中的事件相互指向，最末事件被签名。例如，事件1和2形成单个事务1。类似地，事件5和6形成单个事务4。事件3和事件2之间的箭头420表示服务器应在事件1之后将事件3落定到线性序列。类似地，事件5和6之间的箭头430表示服务器应在事件5之后将事件6落定到线性序列。
在一个实施例中，事件1和2来自单个客户端，而事件3可以来自与事件1和2相同的客户端，或者来自不同的客户端。类似地，事件5和6来自单个客户端，而事件4可以来自同一个客户端或不同的客户端。进一步到该实施例，可以有至少一个和最多四个创建事务1-4的客户端，如图4所示。例如，单个客户端可以发起事务1，包括事件1和2。第二客户端可以发起包括事件3的事务2。第三客户端可以发起包含事件4的事务3，第四客户端可以发起包含事件5和6的事务4。
在需要以原子方式添加多个事件(例如事件1-3)的情况下，可以将事件1-3合并为单个区块400，将区块400存储在线性序列。在区块400，410中，只有最末事件(例如分别为事件3，6)可以被签名，并且区块400，410中的事件1-3，4-6只有在它们全都以预期次序出现在预期区块中时才有效。
如本申请中所述，区块400，410中的事件1-6被密码化地签名并以经认证的线性序列记录。线性序列的结构保证了图1中的接受了具有一些索引n的区块的设备110-160肯定会同意索引小于n的所有区块的内容。在图4中，区块400，410分别具有索引1，2。
一旦区块400，410被最终确定(finalize)，区块400，410就得到区块ID。最终确定区块意味着将区块落定到持久存储而不更改该区块。区块ID是区块索引的元组，以及其内容的密码化哈希。对于给定的区块n，所有预期要被添加到线性序列的区块n+1中的事件都可以包括区块n的区块ID。这确保了设备110-160的事件的预期排序被维护。此外，只有同意区块0到n的区块次序和内容的设备才能接受区块n+1中的事件。
图5示出了对可存在在系统内的多层策略的验证。使用要么拒绝事件500要么接受事件500并且可选地更新事实510，520的数据库的正式策略来处理事件500。事实数据库510，520是关于策略的线性序列上的索引。索引是键值对的集合。例如，事实数据库510，520可以记录由事件500产生的事实以及对它授权的策略规则。可以在决定事件500是否有效并且应被接受在线性序列(例如团队线性序列或空间线性序列)中时由策略处理器读取事实数据库510，520。
当图1中的服务器100接收到事件500时，服务器可以将事件500包含在下一个区块中。当设备110-160接收到事件500时，设备可以基于业务需要处理事件500。
系统策略530由设备110-160和服务器100实现。所有协作设备110-160在处理相同区块时必须使用相同的系统策略530。在一个实施例中，系统策略530可以被实现为例如Rust，Python，Go，或专有策略语言之类的编程语言的源代码。系统策略530描述了区块本身的结构。系统策略530描述了线性序列的核心协议，例如“区块n中的所有事件都必须引用区块n-1”。
用户策略540可以是图2中的团队策略205。团队策略205可以由客户提供并且可以针对客户的组织进行调节。为了确保所有各方都同意用户策略540，用户策略540可以以线性序列存储，例如图3中的团队线性序列310，并且保证对于在特定线性序列上协作的所有用户都是相同的。团队策略规则的一个示例是“只有团队管理员可以向团队添加新成员”。
应用策略550可以按图1中的团队160，170来定义。应用策略与其他策略的主要区别在于，应用策略在任何密文被解密后运行。因此，服务器无法检查应用策略。应用策略可以不记录权限，可以规定“两个文件不能同名”等低级规则。应用策略550可以对规则进行编码以解决低级冲突，例如“如果两个文件具有相同的名称，则忽略第二个文件”。包括系统策略530，用户策略540和/或应用策略550的策略可以在程序中固定或使用线性序列管理，例如图2中的团队线性序列200和空间线性序列210。
图6示出了系统内存在的多种密码化ID。身份是安全的基础。身份由密码化标识(ID)代表，例如使用RSA，DH或其他非对称算法离线生成的非对称密钥对。来自非对称密钥对的公钥被用作实体的密码化身份，而来自非对称密钥对的私钥只有实体知道。离线生成根非对称密钥对(the root asymmetric key pairs)可保护密钥对免受不良行为者使其失陷。设备密钥可以在线生成，但可存储在硬件安全模块(HSM)中。
密码化ID，例如密码化设备ID或密码化用户ID，分别代表系统中的单个实体，例如设备或用户。因此，使用密码化ID确立的身份是全局不同的。在一个实施例中，即使没有管理员区分用户，用户在团队中也是独特的。即使在不协作的组之间，例如不共享任何成员的团队，使用密码化ID确立的身份仍然是全局不同的。
密码化用户ID可用于签名/授权在系统中操作使用的设备密钥。设备可以使用密码化设备ID，它可以包括三种密钥类型：管理签名密钥，消息签名密钥，和设备加密密钥。所有这些密钥类型都是非对称密钥对，可以在应用外部，操作系统(OS)密钥存储或硬件安全模块(HSM)中进行管理。
身份证书600可以从恢复保密中确定性地生成，从而在提供新设备时允许高效地手动转录恢复保密。
管理签名密钥610可以用于高风险操作并且可以要求任何签名请求的用户存在证明。高风险操作的示例是添加用户或更改许可。
消息签名密钥620可用于对由图1中的设备110-160传输的大多数数据进行签名并且不需要在场证明。消息签名密钥620的示例使用是对在聊天中发送的消息进行签名，或者对要上传的文件进行签名。
当需要向设备发送机密消息时，可以使用设备加密密钥630。设备加密密钥630可以经常轮换以提供设备到设备通信的前向保密性。
图7示出了如何将区块分布到多个设备。设备700，710，720可以属于同一个空间和/或团队。它们都可以具有线性序列730的副本。当设备中的一个(例如设备700)将新区块740添加到线性序列700时，设备700将新区块740发送到服务器750。
服务器750还具有线性序列730的副本。服务器750可以通过计算用户是否有执行区块740中代表的操作的权限来计算区块740是否有效。为了确定用户是否拥有权限，服务器750可以从线性序列730计算权限。下面解释了权限计算。
一旦服务器750验证该区块是有效的，服务器可以将区块740分布给设备710，720，其继而可以基于记录在线性序列730中的权限来计算区块740是否有效。如果设备710，720确定该区块不是有效的，则设备可以关闭，因为可能已经发生了对系统的破坏。
如果设备700，710，720在相同空间中，则它们可以共享加密数据760。加密数据760是使用至少一个密码化密钥加密的，例如机密会话密钥，如下所述。不同的设备700，710，720可以对加密数据760具有不同的权限，例如只读，只写，和读写权限。
服务器750还可以存储加密的机密数据760，但是服务器750不存储任何密码化密钥，包括机密会话密钥。服务器750对加密数据760没有任何权限。服务器750具有加密数据750的副本以确保数据的可用性。例如，如果设备700，710离线，并且设备720作为空间新添加的成员，请求加密的机密数据760，则即使设备700，710离线，服务器750也可以将加密的机密数据760提供给设备720。
图8示出了包含区块的线性序列。线性序列800至少包含区块810，820，830。区块810包含多个事件812，814，而区块820包含事件822，824。区块810是线性序列800中的初始区块并且包含定义线性序列800的权限的策略816。可以验证后续区块(例如区块820)中的每个事件，以确保事件822，824与策略816一致。
初始区块后续的每个区块，例如区块820，包括先前区块的密码化哈希826，对于区块820，它是区块810的哈希。通过包括先前区块的密码化哈希，可以保证线性序列800中的区块的排序，并且可以检测和自动拒绝现有区块的重新排序或编辑，和/或线性序列800中新区块的插入。
线性序列800不需要运作证明来验证区块的有效性，因为线性序列800是线性序列，没有任何分支。此外，当区块被添加到列表中时，已经检查了该区块的有效性以符合记录在线性序列800中的策略和权限，并且该区块不能被删除。换句话说，次序列表800无法回滚。
在初始区块810中，事件812将Alice确立为用户。该事件由Alice签名，这意味着Alice使用她的私钥来加密声明“Alice是用户”。为了验证Alice确实请求被确立为用户，处理器可以使用Alice的公钥验证签名过的声明“Alice是用户”，如果验证成功，则处理器可以知道Alice确实已请求确立用户。
事件814将Alice确立为管理员。类似地，事件被签名并且处理器可以验证Alice的身份，如上所述。因为区块810是初始区块，所以确立线性序列的策略816。例如，策略816可以声明“只有管理员可以添加用户”。一旦区块810被落定给线性序列800，系统的生效角色是Alice是管理员且Alice是用户。
区块820中的事件822确立了Bob是用户。为了计算Alice是否有添加用户的权限，处理器可以检查策略816和Alice在由事件812，814确立的系统中的角色。因为策略规定只有管理员才能添加用户，所以处理器会检查Alice是否是管理员。在验证Alice是管理员后，处理器可以验证Alice是否有将Bob添加为用户的权限。可以对照策略816检查初始区块812，814中包含的事件后续的每个事件，并且可以记录授权该事件的策略。例如，对于事件822，区块820可以指向声明“只有管理员可以添加用户”的策略，并且处理器可以检查在事实数据库中存储了“Alice是管理员”的事实。
如上所述，事件824将Carol添加为用户，并且还必须由Alice签名。事件822还可以指向授权该事件的策略，即声明“只有管理员可以添加用户”的策略，这是由“Alice是管理员”事实支持的。哈希826创建区块810，820的线性序列。在区块820被落定给线性序列800之后，系统中的生效角色是Alice是管理员，且Alice，Bob和Carol是用户。
可以在团队中定义其他角色，例如法律，技术，销售等。每个角色都可以被授予访问相应空间类型的访问。例如，如果Alice具有“法律”角色，则可以授予Alice访问所有类型为“法律”的空间的访问。如果Alice的“法律”角色被撤销，Alice会自动失去对“法律”类型空间的访问。
图9示出了团队线性序列和空间线性序列。在该示例中，团队线性序列900和区块线性序列包含仅包括一个事件的区块。团队线性序列900用初始区块910和使用链接到策略920的连接915来初始化，该策略920为团队和任何空间确立策略。在区块930中，Alice将Bob添加为用户，并且该事件可以使用连接935链接到授权它的策略920。
在方框940中，Bob创建空间“Planning”，并将事件链接到策略920以确保Bob作为用户拥有创建空间的权限。默认情况下，只有空间的创建者被授予空间线性序列970上的空间的管理权限。如果策略920授权用户创建空间，则区块930有效，使用连接945将事件链接到策略920，并且将区块940添加到团队线性序列900。当Bob创建空间“Planning”时，确立空间线性序列970，初始区块980指向区块940以表示该列表是在区块940之后但在区块950之前创建的，如下所述。
在方框950中，Alice将空间创建限制到管理员。这个动作改变了策略920。为了验证区块950是否有效，处理器需要检查策略920以查看该策略是否允许管理员修改该策略。如果策略920允许管理员修改策略，则使用连接955将该事件链接到允许管理员修改策略的策略920的一部分，并且确立新策略925。因为Bob在区块942中具有创建空间的权限，即使在方框950之后，Bob不能创建空间，但Bob创建的空间是有效的。在区块960中，Alice添加了Carol，并且根据新策略925检查了该事件。一旦事件被新策略925授权批准，连接965就被建立到新策略925中授权该事件的那部分。
在空间线性序列970的区块990中，Bob将Carol添加为用户。为了验证区块990是否有效，处理器需要检查新策略925以查看策略925是否允许空间用户添加其他空间用户。策略925允许用户添加用户，并且使用连接995将该事件链接到授权事件的策略925的一部分。
如前所述，只有团队成员可以被添加到空间中。如果Bob试图在区块950之前添加Carol，处理器将不会授权添加区块990，因为在检查了事实库和/或团队线性序列900之后，处理器可以确定Carol不是团队成员。但是，如果Bob尝试将Carol添加到在区块960之后的空间线性序列970，处理器将授权添加区块990，因为策略允许空间用户添加空间用户，并且因为Carol是团队的成员。
图10A-B示出了在恶意行为者试图渗入(infiltrate)系统的情况下的权限计算。该示例说明了服务器1000的失陷如何不会使设备1010，1020，1030失陷，因为每个设备1010-1030独立地检查并保证线性序列1040的有效性和线性序列1040中记录的权限。
例如，如果恶意服务器管理员使服务器1000失陷，该恶意服务器管理员强制服务器1000错误地验证欺诈区块1050并将其分布给设备1010-1030，则每个设备1010-1030可以独立地验证区块1050的有效性。
在图10B中，每个设备1010-1030可以独立地验证线性序列1040中最末区块的哈希1060有效。每个设备1010-1030可以验证用户是有效角色。每个设备1010-1030可以验证Mal的签名有效，因为在提交区块1050之前，Mai已请求服务器1000为他生成公钥和私钥并将公钥分布给设备1010-1030。然而，设备1010-1030可以确定区块1050无效，因为根据系统策略，只有例如管理员或用户之类的现有成员可以添加新用户，并且Mal不是管理员或用户。因为区块1050不满足策略，所有设备1010-1030都可以拒绝区块1050。此外，一旦从服务器1000接收到无效事务，设备1010-1030就可以关闭，因为设备1010-1030可以断定服务器1000已经失陷。
图11A-C示出了如何在权限撤销时控制对加密数据的访问。设备1100，1110，1120可以通过例如成为同一空间的一部分来共享加密数据1130。加密数据1130可以使用高级加密标准(AES)被加密，AES是一种对称密钥算法，使用相同的密钥来加密和解密数据。加密的机密数据1130可以被存储在设备1100-1120和服务器1140上。只有拥有访问加密数据1130的权限的设备1100-1120才能知道AES密钥。
假设Alice是管理员并有移除用户的权限，Alice可以向服务器提交区块1150，声明“Carol不是用户”，从而撤销Carol对Alice和Bob之间共享的任何未来加密数据的权限。如图11B所示，服务器1140可以将区块1150分布给所有设备1110-1120。
在区块1150有效后，通过设备1110-1120，Carol和她的设备1120失去访问任何未来加密数据的权限。为了确保Carol和她的设备1120不能访问Alice和Bob之间共享的任何未来加密数据，设备1100，1110生成新的通道会话密钥。
可以使用诸如椭圆曲线密码术之类的密码化方法来生成新的通道会话密钥，例如使用P-384椭圆曲线。可以使用保密密钥生成材料1170来生成通道会话密钥，例如在椭圆曲线密码术的情况下的域参数。域参数可以包括定义椭圆曲线Y2＝X3+AX+B的常数A，B。
基于线性序列1160计算共享密钥的新设备组。使用属于新设备组中剩余的设备的非对称密码化算法的每个公钥来加密保密密钥生成材料1170。加密的保密密钥生成材料1170被分布到组中的所有设备。设备1100，1110可以使用它们自己的非对称密码化算法的私钥来解密接收到的加密消息。结果，只有具有与在加密中使用的公钥相对应的私钥的设备1100，1110可以计算新的通道会话密钥。
接收保密密钥生成材料1170的设备1100，1110可以计算通道会话密钥的私有部分1172和通道会话密钥的公共部分1174，并且可以将通道会话密钥的公共部分1174记录到线性序列1160。作为将通道会话密钥的公共部分1174落定给线性序列1160的结果，具有对线性序列1160的访问的客户端可以访问公共部分1174并且对线性序列1160具有只写访问。客户端不能读取与线性序列1160相关联的任何加密数据，因为客户端没有保密密钥生成材料1170和/或通道会话密钥的私有部分1172。通道会话密钥的私有部分1172没有被记录在线性序列1160中。
因为线性序列1160不需要运作证明，并且复制线性序列1160在计算上是可行的，所以失陷的服务器1140可以向两组用户呈现两个不同的线性序列1162，1164，如图11C所示。例如，失陷的服务器1140可以拒绝将区块1150分布给设备1120，从而导致设备1120相信它仍在该组中，并尝试与设备1100和1110共享设备1120的加密数据1190。因此，可以基于线性序列1160中最末区块1150的哈希来计算新的通道会话密钥1180。例如，可以通过执行HKDF(图11B中的通道会话密钥，区块1150的哈希)来获得新的通道会话密钥1180。结果，由于设备1100和1110不与设备1120共享相同的最末区块，因此设备1120不能计算相同的通道会话密钥1180。
除了位于同一空间的用户Alice和Bob外，访客用户还可以临时被授予对与Alice和Bob相同的空间中包含的加密数据的访问。访客用户无权访问团队线性序列1160并且不能使空间线性序列1160内的用户的权限有效。然而，访客用户仍然可以与Alice和Bob协商通道会话密钥，并被授予对加密数据1130的临时访问。
图12是通过分布式账本管理与一个或多个受信设备对加密数据的访问分开的权限的方法的流程图，其中每个受信设备对应于至少一个基于密码化密钥的身份。在步骤1200，处理器可以创建定义用户权限的区块。该区块可以包括独特地标识该用户的密码化用户ID和与密码化用户ID相关联的权限。权限可以至少定义与密码化用户ID相关联的在加密数据上执行的操作。操作可以包括只读，只写，或读写。与需要批准运作的比特币账本不同，该区块不需要条目批准运作，因此与平均需要10分钟的处理器时间来为区块生成运作证明的比特币相比，生成区块的处理器密集度更低。
在步骤1210中，处理器可以将区块附加到线性序列的末尾，包括定义与加密数据相关联的权限的多个区块，并维护多个区块中每个区块的成员资格和排序。为了维护区块的成员资格，不能删除线性序列中的区块。也就是说，不允许对线性序列进行删除操作。为了维护多个区块中每个区块的排序，回滚不是线性序列的允许操作。换句话说，线性序列不能被分支，并且一旦将区块添加到线性序列中，线性序列中的区块的内容就不能被修改和/或编辑。禁止删除和修改区块确保了线性序列的完整性。换句话说，一旦将区块添加到线性序列中，该区块就永久处于线性序列中。此外，在将区块添加到线性序列之前，必须验证区块的内容以确保它们与线性序列中的前面的区块一致。
在步骤1220，处理器可以接收访问加密数据的请求。该请求可以包括与发出请求的用户相关联的密码化用户ID。对加密数据的访问可以包括只读，只写，或读写访问。
在步骤1230中，处理器可以通过计算记录在如图8，9和10A-B所示的线性序列中的权限来确定发出请求的用户是否具有访问加密数据的权限。为了计算权限，处理器可以检查从初始区块到最末区块的线性序列，以确定用户角色和与每个角色相关联的权限，并将来自用户的请求与用户角色进行比较。换句话说，处理器可以通过检查密码化用户ID的访问是否被记录在线性序列中的权限所许可，来管理密码化用户ID对加密数据的访问。
在步骤1240中，在确定发出请求的用户拥有访问加密数据的权限时，处理器可以向发出请求的用户授予对加密数据的访问。
处理器可以在线性序列中创建初始区块，该初始区块定义了规定角色和与角色相关联的权限的策略。例如，图8中的初始区块810定义了图8中的策略816。此外，处理器可以在定义与密码化用户ID相关联的角色的线性序列中创建区块。该区块可以是初始区块810，如图8所示，其除了定义策略之外，还定义了Alice是图8中的事件814中的管理员，或者，该区块可以是后续区块，例如图8中的区块820，其将Bob和Carol定义为用户。
为了维护多个区块中的每个区块的排序，处理器可以在每个后续区块中包括每个先前区块的密码化哈希(“哈希”)，从而能够检测排序序列中的任何变化，如图8中所解释的。例如，处理器可以计算包含在多个区块中的第二区块中的数据的第二密码化哈希。第二区块可以是线性序列中的初始区块或任何区块。处理器可以将第二密码化哈希存储在第二区块内，并且可以将第二密码化哈希包括在包含在第二区块后续的区块中的数据中。
为了维护线性序列内的区块的成员资格，处理器可以定义一组要在线性序列上执行的操作，其中定义集合之外的任何操作都不能在线性序列中执行。定义的集合可以排除例如线性序列的删除，分支，和/或线性序列内的数据的修改之类的操作。
为了减少故障(例如由失陷的中央服务器损坏线性序列和/或加密数据)的可能性，处理器可以将线性序列分布到多个设备。多个设备中的每个设备可以通过与线性序列相关联的密码化用户ID进行密码化验证，如图2中所解释的。例如，为了将设备添加到授权设备列表中，已经授权的密码化用户ID需要请求对该设备的访问，如图2中所解释的。在接收到请求后，处理器可以通过使用密码化用户ID的公钥解密该请求来验证密码化用户ID确实提出了该请求。在验证后，处理器可以将密码化设备ID分配给设备。
具有密码化设备ID的多个设备中的每个设备可以根据基于线性序列计算的权限独立地验证请求的有效性，如图10A-B所解释的。如果设备不能基于计算出的权限验证该区块有效，则该设备可以拒绝添加该区块。验证失败后，设备可以关闭以防止篡改设备上的加密数据。
出于效率目的，处理器可以定义密码化用户ID的团队，以便不必搜索所有密码化ID来找到可以在他们之间共享加密数据的一组人。为了创建团队，处理器可以创建包括多个区块的团队线性序列。多个区块可以包括一个或多个策略区块，一个或多个简档区块，以及一个或多个权限区块。一个或多个策略区块可以定义确立角色和与角色相关联的权限的策略，一个或多个简档区块可以确立密码化用户ID和与密码化用户ID相关联的密码化设备ID，并且一个或多个权限区块可以定义与密码化用户ID相关联的角色。团队线性序列是本申请中所述的线性序列的一个实例，并且具有与该线性序列相同的属性。
如果记录在初始区块中的策略许可修改，则可以修改记录在线性序列(例如团队线性序列)的初始区块中的策略。如果初始区块中记录的策略不许可修改，则试图修改策略的任何区块都不会被多个设备验证。
为了修改策略，处理器可以获得修改在一个或多个策略区块中定义的策略的请求以及发出请求的用户的密码化ID。处理器可以通过从团队线性序列中确定与密码化ID相关联的权限来检查密码化用户ID是否被授权修改策略。通常只允许管理员修改策略，处理器可以检查密码化用户ID是否具有管理员或用户的角色。如果密码化用户ID具有用户的角色，处理器可以拒绝验证该区块。在确定密码化用户ID被授权后，处理器可以创建规定修改的策略区块，并且可以将定义修改的策略区块附加到团队线性序列的末尾。
一旦处理器定义了团队，处理器就可以在团队内定义空间，其具有可以私下共享加密数据的团队成员子集。空间成员资格可以与团队成员资格相同，也可以小于团队成员资格。空间是定义加密数据和对加密数据的访问的虚拟隔间。空间可以包括使用只有空间成员知道的密码化密钥的加密数据。
为了定义空间，处理器可以通过创建空间线性序列来代表成员和加密数据。为了效率，空间线性序列可以被细分为多个线性序列。例如，空间线性序列可以被细分为权限线性序列和加密数据线性序列。权限线性序列可以在密码化用户ID的空间内定义角色。密码化用户ID是空间的成员，角色与团队的一个或多个策略区块中定义的策略一致。加密数据线性序列可以记录对加密数据执行的操作，例如对加密数据的至少一部分的添加，删除或修改。
加密数据可以包括多种类型的加密数据，例如文件，电子邮件，消息等。处理器可以为加密数据类型中的每一个创建线性序列。因此，处理器可以创建文件的线性序列，电子邮件的线性序列和消息的线性序列，而不是创建加密数据线性序列。
通过为权限和每种类型的加密数据创建单独的线性序列，处理器可以加快权限的计算，因为为了计算权限，处理器只需要审查包含与权限相关的数据的区块的线性序列，而不是审查包含权限区块和加密数据区块的线性序列。假设权限区块与加密数据区块一样多，通过将空间线性列表拆分为权限线性列表和加密数据线性列表，处理器可以将权限计算速度提高两倍。类似地，处理器可以将加密数据的检索速度提高大约2倍，因为要检索加密数据，处理器只需要审查加密数据的线性序列，而不是同时包含加密数据区块和权限区块的线性序列。
处理器可以撤销与空间相关联的密码化用户ID的成员资格。当成员资格被撤销时，必须阻止密码化用户ID访问和在密码化用户ID成员资格撤销后空间内共享的加密数据。为了防止密码化用户ID访问撤销后添加到空间中的加密数据，处理器可以生成成员资格已被撤销的密码化用户ID未知的密码化会话密钥，并且可以使用密码化会话密钥在撤销后对添加到空间后的加密数据进行加密。在撤销之前包含在空间中的数据也可以使用新的密码化会话密钥进行加密。
新的密码化会话密钥可以是使用以下4个步骤计算的AES密钥。在步骤1中，可以使用例如P-384之类的椭圆曲线算法计算AES密钥。在步骤2中，从空间线性序列计算剩余的设备组，例如，空间内的权限线性序列。在步骤3中，使用仍在该空间中的每个设备的公共设备密钥对AES密钥进行加密，并将加密的AES密钥分布给该空间内的每个设备。每个设备都可以解密被加密的AES密钥，因为每个设备都知道自己的私有设备密钥。由于没有其他设备知道设备的私钥，因此没有窃听者可以解密被加密的AES密钥。在步骤4中，使用AES加密的消息可以被分布给空间内的设备，以确保每个人都可以解密消息。
在一些情况下，例如在图11C中所述的，会话密钥的计算可以包括在步骤3之前执行的附加步骤，其中会话密钥的计算还包括空间线性序列(例如空间的权限线性序列)中最末区块的密码化哈希。具体地，一旦在步骤1中计算了AES密钥，为了生成最终密钥，可以执行将AES密钥和最末区块的密码化哈希进行组合的附加步骤。可以使用HKDF密码化函数计算该组合，该函数将AES密钥和最末区块的密码化哈希作为对象(argument)来生成最终密钥。然后将最终密钥进行加密并分布给所有设备。
除了在从列表中移除成员后计算新的会话密钥外，还可以在添加新成员时计算新的会话密钥，其目的是防止成员访问在成员加入之前在空间内共享的加密数据。
处理器可以通过在属于团队线性序列的多个团队区块和属于空间线性序列的多个空间区块之间确立临时关系来实现团队线性序列在空间线性序列中的线性排序，如图3中所解释的。可以有多种类型的临时关系，例如空间区块可以绑定到紧接在空间区块之前的团队区块，或者空间区块可以绑定到紧接在空间区块之后的团队区块等。确立线性次序在权限计算和审计中很重要。
例如，为了确定权限，需要引用在添加区块之前的时刻在团队空间中定义的当前策略。在另一个示例中，在对线性序列执行审计时，为了确定区块是否正确地添加到空间线性序列中，需要计算当前权限，该权限可以部分地定义在团队线性序列上。为了确定当前的策略，需要确定空间线性序列和团队线性序列内的区块的线性次序，以便计算添加区块之前记录在团队列表中的权限。
因此，每次将区块添加到空间线性序列时，该区块都会被绑定到团队线性序列以确定团队线性序列和空间线性序列之间的线性次序。不需要确立两个空间线性序列之间的线性次序，因为一个空间线性序列内的权限不影响另一空间线性序列内的权限。
图13是使用分布式账本管理对加密数据的访问的方法的流程图。在步骤1300中，处理器可以通过检查包括被排布的多个区块的线性序列中记录的权限许可访问来管理对加密数据的访问，其中线性序列中的初始区块定义规定角色和与角色相关联的权限的策略。
在步骤1310，处理器可以通过密码化地标识与线性序列相关联的用户来维护记录在线性序列中的权限的有效性，从而防止授权用户访问线性序列。在将与用户权限关联的区块添加到多个区块之前，处理器可以检查线性序列以确保用户权限与策略一致。在确保用户权限与策略一致后，处理器可以将与用户权限相关联的区块添加到多个区块中。
处理器可以确定与用户相关联的用户角色，与用户角色相关联的权限，并且可以确保与区块相关联的用户权限在与用户角色相关联的权限限制内。
例如，要添加到序列中的区块可以请求对策略进行修改。在将区块添加到序列之前，处理器可以检查策略是否许可验证，以及什么角色可以修改策略。例如，策略可以声明可以修改策略，但只有管理员才能修改策略。如果是这种情况，处理器可以检查请求修改的用户是否是管理员。
为了防止失陷的中央服务器对数据的未授权访问，处理器可以将线性序列分布给与多个用户相关联的多个设备，其中多个设备中的每个设备由多个用户中的用户密码化地认证。是否将区块添加到线性序列的确定可以由每个设备独立做出，而不是由中央服务器做出，这会产生单点故障。
处理器可以使用密码化用户ID对每个用户进行认证，其可以是使用非对称密码化算法生成的公钥。密码化用户ID可以是2048位的字符串。非对称密码化算法可以是RSA或DH，可以生成两个密钥，一个公钥和一个私钥。处理器可以将非对称密码化密钥对中的第一密钥(即私钥)仅提供给用户，并将非对称密码化密钥对中的密码化用户ID(即公钥)提供给多个用户到整个系统。处理器可以使用公钥是一种在整个系统中标识用户的方式。因此，用户可以在不同的团队或空间中使用不同的名称，并且可以将多种名称绑定到一个密码化用户ID。
例如，为了验证用户的身份，处理器可以接收文本消息，并且可以使用用户的私钥对文本消息进行签名。为了验证用户的身份，处理器可以使用用户的公钥(即密码化用户ID)来反转签名过程。然后，处理器可以比较文本消息和通过反转签名过程获得的消息。如果文本消息和通过反转签名过程获得的消息完全匹配，处理器可以验证用户的身份。否则，处理器不能验证用户的身份。
出于效率目的，处理器可以创建团队。为了创建团队，处理器可以获得标识多个用户的多个密码化用户ID。处理器可以创建包括以线性序列排布的多个区块的线性序列，其中线性序列中的初始区块定义了规定角色和与角色相关联的权限的策略，并且其中多个区块中的区块定义了角色，该角色与在标识多个用户中的用户的多个密码化用户ID中的密码化用户ID相关联。
要在团队内创建空间，处理器不必搜索系统中的所有密码化ID，而只需搜索团队中包含的密码化ID，从而节约CPU周期。例如，如果团队包含10个用户，整个系统包含数以万计的用户，则用于创建空间的处理器周期数减少了大约1000个。空间可以包含团队的密码化用户ID的子集。空间可以包括使用只有空间成员知道的密码化密钥加密的数据。空间可以包括代表成员和加密数据的空间线性序列。
如本申请中所解释的，出于效率原因，空间线性序列可以包含两个或更多个子序列。空间线性序列可以包括权限线性序列，该权限线性序列包含修改系统内权限的区块，例如添加或移除用户和/或管理员。加密数据线性序列可以包括在系统内增加，删除，和修改加密数据的线性序列。加密数据线性序列可以进一步细分为取决于加密数据的类型(例如文件和/或消息)的多个线性序列。
可以将团队线性序列，空间线性序列，和加密数据存储在存储器中，该存储器被配置为通过网络连续供一台或多台计算机使用，例如中央服务器。因此，在空间内的大多数设备离线的例子中，空间内的设备可以请求加密数据和/或可以从中央服务器向空间有序序列添加区块。
在企业环境中区块链管理组权限和访问的集成
图14示出了根据一个实施例的如何将安全文件系统集成到企业信息技术(IT)基础架构中。服务器1400可以存储加密数据1410，其可以包括机密数据，例如文件系统，电子邮件，即时消息等。服务器1400还可以存储可以代表团队线性序列或空间线性序列的区块链1402，1404，1406，1408，1412，如本申请中所述。区块链是一个不断增长的记录列表，称为区块，使用密码术将其进行链接。每个区块包含先前区块的密码化哈希，例如图8中的826，以及例如图8中的数据812，814，816，822，824。区块还可以包括时间戳，例如图2中的260，270，280，290。
如本申请中所解释的，区块链1402，1404，1406，1408，1412可以记录与密码化用户ID相关联的权限。区块链1402，1404，1406，1408，1412可以以明文存储，并且服务器1400可以通过仅允许授权请求者访问明文来控制对区块链1402，1404，1406，1408，1412的访问。为了授权请求者，服务器1400可以发布和管理令牌，如下所述。
系统1420可以作为企业IT基础架构的一部分在客户场地实施。系统1420可以包括访问控制服务器1430，令牌发布者1440和用户设备1450。
访问控制服务器1430可以通过基于一组企业策略授予或拒绝对用户设备1450的许可来控制用户设备1450对企业基础架构上运行的网络应用，服务和/或文件的访问。访问控制服务器1430可以运行多种软件，例如Microsoft Active Directory或Apple OpenDirectory。
令牌发布者1440可以充当访问控制服务器1430，用户设备1450和服务器1400之间的中间件。令牌发布者1440可以从用户设备1450接收请求访问区块链1402，1404，1406，1408，1412的一部分的令牌请求1460。令牌请求1460可以包括与发出请求的用户相关联的密码化用户ID，以及被请求的区块链1402，1404，1406，1408，1412的部分的规格。例如，令牌请求1460可以包括字母数字串形式的密码化用户ID，例如“9EDaleMN9CUylV7VSYyAUTkfEGC7MUDMkugmXV VsM7Z5r01Wpg”，以及团队区块链1402，1408或空间区块链1404，1406，1412的标识。
令牌发布者1440可以从服务器1400发送对令牌的请求1470，向用户设备1450授予访问区块链的规定部分的许可。令牌请求1470可以包括在令牌请求1460中包含的密码化用户ID和团队区块链1402，1408或空间区块链1404，1406，1412的标识。
在接收到令牌请求1470后，服务器1400可以基于存储在区块链1402，1404，1406，1408，1412中的成员资格信息计算密码化用户ID是否有访问区块链1402，1404，1406，1408，1412的被请求部分的权限。例如，如果密码化用户ID请求访问空间区块链1404，则服务器1400可以检查密码化用户ID是否是空间区块链1404的成员。如果密码化用户ID是空间的成员，则服务器1400可以确定密码化用户ID具有必要的权限并且可以发布令牌1480。否则，服务器1400可以确定密码化用户ID未被授权访问空间区块链1404并且可以拒绝发布令牌1480。
令牌1480可以授予对区块链(例如空间区块链1404)的被请求部分的无限制读取访问。换句话说，每当服务器1400和/或令牌发布者1440从任何来源接收令牌1480时，服务器1400不执行上述权限计算，并紧接着授予对令牌1480中规定的区块链部分的访问，例如空间区块链1404。实际上，令牌1480通过允许服务器1400在每次密码化用户ID请求访问空间区块链1404时不执行计算权限的昂贵计算来创建效率增益。而是，令牌1480允许服务器1400执行简单地验证令牌1480的成本较低的计算，如下所述。
在将令牌1480传递给用户设备1450之前，令牌发布者1440可以与企业访问控制服务器1430检查用户设备1450对于空间区块链1404具有何种许可。为了执行检查，用户设备1450可以向访问控制服务器1430发送票证请求1490。票证请求1490可以包含访问控制服务器用户标识，例如用户的登录ID和用户的密码。用于向访问控制服务器1430标识用户的用户登录ID和用户密码与用于向服务器1400标识用户的密码化用户ID不同。
在验证用户的标识，例如登录ID和密码后，访问控制服务器1430可以根据公司策略检查用户具有的许可，并将包括该许可的票证1492发送到令牌发布者1440。例如，公司策略可以规定当用户休假时，用户无权访问电子邮件。因此，许可可以规定多种制约因素，例如“仅当用户在特定位置时，例如在公司大楼内时，才允许用户访问”，“仅在特定时间允许用户访问”，和/或“只有当用户设备1450连接到特定网络时，用户才被允许访问”，例如公司网络。
令牌发布者1440可以将票证1492中规定的许可包含到令牌1480中以获得减弱的令牌。票证1492中规定的许可可能不会增加由令牌1480授予的许可，但可以保持许可不变或减弱，即减少令牌1480授予的许可。
此外，令牌发布者1440可以向减弱的令牌添加附加制约因素，例如减弱的令牌何时到期(例如，在3或5分钟内)，位置制约因素，互联网地址制约因素等。可以将附加制约因素添加到减弱的令牌以产生减弱的令牌1494，其被发送到用户设备1450。
用户设备1450可以请求被添加到团队区块链1402，1408。为了被添加到团队中，用户设备1450可以向访问控制服务器1430认证其自身，访问控制服务器1430可以将认证用户的票证1492发送到令牌发布者1440。此外，令牌发布者1440可以通过要求服务器计算存储在团队区块链1402，1408中的与用户相关联的密码化用户ID的权限来向服务器1400认证用户。如果访问控制服务器1430和服务器1400都授权该用户，则可以将该用户添加到团队区块链1402，1408。
即使访问控制服务器1430被敌对方控制，由于访问控制服务器1430不能增加令牌1480所授予的许可，敌对方仍将仅具有区块链1402，1404，1406，1408，1412中的并由令牌1480授予的权限。如果敌对方控制令牌发布者1440，则敌对方只能控制令牌发布者1440已从服务器接收到的团队的令牌1480。在这两种例子中，敌对方只能读取明文数据，而不能读取加密数据1410。此外，敌对方将无法修改明文数据。
令牌发布者1440可以接收访问控制服务器1430受信程度的表示。如果访问控制服务器1430不受信任，则在不涉及访问控制服务器1430的情况下，可以发布令牌1494或者可以将用户添加到团队1，2。
图15示出了根据另一实施例的如何将安全文件系统集成到企业IT基础架构中。可以在没有图14中的访问控制服务器1430的情况下管理对区块链1502，1504，1506，1512的访问。由访问控制服务器1430实施的公司策略可以被记录在区块链1520上，或者可以是事实数据库1530的一部分。区块链1520和事实数据库1530可以独立于团队1，2或空间1，2而存在。服务器1500和令牌发布者1540可以是企业IT基础架构的一部分，和/或可以作为云服务提供。移除访问控制服务器1430减少了许多潜在的安全问题并且即使访问控制服务器1430不受信任也使系统能够运行。
当用户设备1550使用令牌请求1560请求令牌时，令牌发布者可以将令牌请求1560转发到服务器1500。令牌请求1560可以包含密码化用户ID和正在请求访问的区块链1502，1504，1506，1508，1512的一部分的标识。例如，区块链的一部分的标识可以标识团队区块链1508。
服务器1500可以计算记录在团队区块链1508中的密码化用户ID的权限，以确定密码化用户ID是否是团队的成员。如果密码化用户ID不是团队成员，则服务器1500可以拒绝向令牌发布者1540发送令牌。如果密码化用户ID是团队成员，则服务器1500可以检查事实数据库1530和/或公司策略区块链1520以确定公司策略是否对密码化用户ID的访问施加任何制约因素。在这种例子中，可以使用单个密码化用户ID来检查与服务器1500相关联的许可和与公司策略相关联的许可，而不是需要单独认证，如图14中所解释的。
服务器1500可以向令牌发布者1540发送消息1580。消息1580可以包括授予对团队区块链1508的无制约地读取访问的令牌，以及与公司策略相关联的许可。令牌发布者1540可以通过组合令牌和与公司策略相关联的许可来创建减弱的令牌1594，并将减弱的令牌1594转发给用户设备1550。
用户设备1550可能想进一步减弱该减弱的令牌1594以授予第三方访问团队区块链1508的许可。为此，用户设备1550可以向令牌发布者1540发送请求，该请求包含减弱的令牌1594和施加在减弱的令牌上的附加许可，例如临时许可。令牌发布者1540可以将附加许可包含到减弱的令牌1594中，并且发布新令牌以发送到用户设备1550，用户设备1550可以将其转发给第三方。
时钟
图16A示出了如何使用区块链来实现时钟。为了包含临时许可，在图15中所讨论的，处理器可以创建始终递增的时钟，例如在图2中所解释的，其中在区块链1610，1615，1620，1625中的每个区块1635，1645(为简洁起见仅标记两个)被加上时间戳，使得区块1635，1645内的可选的时间戳1630，1640总是在增加。
令牌中的临时许可可以用时间戳来表达，例如令牌在时间戳1630后5分钟有效。因此，如果时间戳1640比时间戳1630晚5分钟以上，则不允许令牌持有者对区块1645的读取访问。区块1635，1645可以在团队和序列内排序，但可能不能在两个不同团队或两个不同序列之间排序。时间戳1630，1640可以分别放置在区块1635，1645的头部内。
替代地或附加地，时钟可以使用区块链1600来实现。时钟区块链1600可以包括区块1650，1660，1670等，每个区块代表时钟的一个滴答，例如1秒，1分钟，5分钟，半小时，一小时。区块1650，1660，1670的频率可以与企业的计算资源相关。计算资源越高，区块1650，1660，1670的频率越高，计算资源越低，区块1650，1660，1670的频率越低。
团队区块链1610，1615中的每个区块1625，1635，1645(为了简洁仅标记了三个)可以分别具有到时钟区块链1600中的对应区块1650，1660，1670的绑定1628，1638，1648。例如，团队区块1625具有到区块1650的绑定1628，这意味着团队区块1625是在创建区块1650之后，创建区块1660之前被创建的。
空间区块链1620，1625中的区块1680，1690(为了简洁仅标记了两个)可以分别具有到团队区块链1610，1615的对应区块1635，1625的绑定1682，1692。例如，绑定1682表示区块1680是在区块1635之后但在区块1645之前被创建的。
因此，空间区块链1620，1625中的每个区块1680，1690被绑定到团队区块链1610，1615中的相应区块，并且间接绑定到时钟区块链1600中的区块1650，1660，1670。例如，基于图16A所示的绑定，区块1690是在区块1650之后但在区块1660之前被创建的。
令牌中的临时许可可以用时钟区块链1600，区块1650，1660，1670，或壁钟来表达。时钟区块链1600可以对应于壁钟，具有时钟区块链1600中的区块1650，1660，1670总是在增加的约束。
例如，当临时许可以壁钟的形式制定时，临时许可可以声明令牌有效期至2020年12月1日。具有在规定日期之后的时间戳的第一区块1650，1660，1670指明了时间，在该时间以及在该时间之后，令牌不再有效。令牌持有者不可访问被绑定到指明了此类时间的第一区块的所有区块。
在另一示例中，当根据区块1650，1660，1670制定临时许可时，临时许可可以声明令牌在区块1650之后的1 1/2小时内有效。具有在规定时间之后的时间戳的第一区块1660，1670指明了时间，在该时间以及该之间之后，令牌不再有效。令牌持有者不可访问被绑定到指明了此类时间的第一区块的所有区块。
图16B示出了时钟区块链的内容。时钟区块链1600的区块1650，1660，1670可以包含几个字段，包括壁钟字段1652，1662，1672，序列时钟字段1654，1664，1674和密码化哈希树字段的根1656，1666，1676。
壁钟字段1652，1662，1672可以是存储时钟区块链1600的服务器的时钟所表示的时间的记录。壁钟字段1652，1662，1672不必总是在增加，因此字段1652，1662可以具有相同的值，或者字段1672可以表示在字段1652所表示的时间之前的时间。
序列时钟1654，1664，1674一直在增加。可以由测量并同意当前时间的多个服务器表示序列时钟。多台服务器提供冗余，使得如果一台服务器出现故障，时钟区块链1600可以继续测量时间。同意的当前时间具有大于先前当前时间的特性。当前时间可以是多台服务器测量的最晚时间，也可以是大多数服务器同意的时间，只要当前时间大于先前同意的当前时间即可。
密码化哈希树字段的根1656，1666，1676可以是默克尔(Merkle)根，并且可以包括绑定到区块1650，1660，1670的区块链中所有最新区块的密码化哈希。例如，密码化哈希树字段1662可以包含区块1635和区块1685的密码化哈希。提供密码化哈希树的根而不是所有最新区块的列表的原因可以是为了节约带宽和存储资源，因为传送和存储根比传送和存储所有区块的列表更便宜。另一个原因可以是通过只提供来自所有区块的列表的根，以及一些附加信息，可以计算所有区块的列表，而将所有区块的列表保密。
图17示出了密码化树。端点代表区块1700，1710，1720，1730，它们是绑定到图16中的时钟区块链1600中的区块的区块链中的所有最新区块。密码化树1740通过在每个节点计算诸如子节点的SHA的密码化哈希来构造。例如，节点1750是通过计算区块1710的密码化哈希来计算的，而节点1792是通过计算节点1770，1780的密码化哈希来计算的。最后，通过计算节点1792，1794的密码化哈希来计算根1790。
根1790可以被存储在时钟区块链1600中。根1790的值对于生成密码化树1740的区块1700，1710，1720，1730的序列是独特的。与存储所有区块1700，1710，1720，1730的值相比，在时钟区块链1600中存储单个值，例如根1790，节约了带宽和存储空间。此外，存储根1790并未公开用于构造密码化树1740的所有区块1700，1710，1720，1730。
为了检查区块是否是密码化树1740的一部分，只需要提供密码化树1740中所有元素的子集。例如，如果有N个端点，即用于构造密码化树1740的N个区块，则只需要提供log(N)个元素来检查是否根1790包含了特定元素。
在更具体的示例中，为了检查区块1710是否是根1790的成员，只需要提供区块1710和节点1760，1792。一旦被提供，节点1750的值可以从区块1710的值计算。节点1794的值除了可以从节点1750和1760的值计算外，也可以通过例如计算SHA(节点1760，节点1750)来计算。根节点可以从节点1794和1792的值计算出来。如果如此计算的根节点与存储在时钟区块链1600中的根1790匹配，则可以确认区块1710在密码化树1740中的成员资格。
令牌
图18示出了令牌的构成。令牌1800可以是图14中的令牌1480，图15中的1580，其由例如存储了图14中的权限定义区块链1402，1404，1406，1408，1412和图15中的1502，1504，1506，1508，1512的图14中的服务器1400和图15中的1500的第一权限源授予。
令牌1800可以包括标识保密根密钥的密钥标识符(ID)1810，许可1820以及许可1820和保密根密钥的密码化哈希1830。服务器1400，1500和/或图14中的令牌发布者1440，图15中的1540可以知道保密根密钥。使用密钥标识符1810，服务器1400，1500和/或令牌发布者1440，1540可以取得保密根密钥。密码化哈希1830可以是HMAC，有时扩展为密钥哈希消息认证码或基于哈希的消息认证码。与任何MAC一样，HMAC可用于同时验证数据完整性和消息的真实性。任何密码化哈希函数，例如SHA-256或SHA-3，都可以用于计算HMAC。与所有密码化哈希一样，密码化哈希1830是不可逆的，这意味着给定密码化哈希1830的输出，确定密码化哈希的输入在计算上是不可行的。
令牌1800，加上第二许可1850，可以变成减弱的令牌1840。减弱的令牌1840可以是图14中的令牌1494，图15中的1594。第二许可1850可以由第二权限源授予，例如图14中的访问控制服务器1430或记录在图15中的区块链1520中的公司策略。令牌1800可以包含任意数量的许可，也称为约束或警告(caveats)。
为了获得减弱的令牌1840，服务器1400，1500可以将第二许可1850添加到令牌1840，计算第一密码化哈希1830和第二许可1850的第二密码化哈希1860并且从令牌中移除第一密码化哈希1830，从而获得减弱的令牌1840。
第二许可1850被解释为仅减少第一许可1820。通过从第一令牌中移除密码化哈希1830，令牌1840被创建，其中第一许可1820受到第二许可1850的限制。因为密码化哈希1860是不可逆的，攻击者无法猜出密码化哈希1830，并且令牌1840是安全的。因此，最大的权限由原始令牌1800授予，只有一个许可1820。
例如，第一许可1820可以规定密码化用户ID被允许读与区块链1402，1404，1408，1412，1502，1504，1508，1512相关联的元数据。第二许可1850可以规定密码化用户ID有权访问的团队区块链，例如团队区块链1402，1408，1502，1508。可以将额外的许可添加到减弱的令牌1840以制作更加减弱的令牌1870。
在一个实施例中，减弱的令牌1870可以根据用户设备的请求生成。例如，第三许可1880可以规定密码化用户ID可以有权访问团队区块链1402，1408，1502，1508内的空间区块链1404，1406，1412，1504，1506，1512。第三密码化哈希1890可以被包括在减弱的令牌1870中，或者密码化哈希1890可以是密码化哈希1860和第三许可1880的密码化哈希。可以将密码化哈希1860从令牌1870中移除。
在另一个实施例中，用户设备可以将减弱的令牌1870授予第三方。例如，第三方可以拥有专有的视频处理算法，并且减弱的令牌1870可以授予对用户设备有权访问的视频的访问。授予第三方访问的原因可以是第三方可以有权访问比用户设备更快的网络连接。减弱的令牌1870可以包含第三许可1880，该第三许可1880规定减弱的令牌1870授予访问的视频。
为了请求视频，第三方可以将减弱的令牌1870发送到服务器1400，1500和/或令牌发布者1440，1540。服务器可以使用保密根密钥验证令牌，如下面所解释的，并且可以将对视频的访问授予第三方。
图19示出了防止重放攻击的令牌。为了防止攻击者通过获得令牌并将令牌的副本提供给图14中的令牌发布者1440，图15中的1540，和/或图14中的服务器1400，图15中的1500来执行重放攻击。图18中的减弱的令牌1840，1870可以包括单次使用许可1900，1910以获得减弱的令牌1940，1970。密码化哈希1920可以是图18中的密码化哈希1860和第三许可1900的密码化哈希，而密码化哈希1930可以是图18中的密码化哈希1890和第四许可1910的密码化哈希。如果令牌1940，1970在请求时被拦截，则重放令牌1940，1970不会授予攻击者任何访问，因为在满足一个请求后令牌1940，1970无效。
恢复密钥
图20示出了如何使用恢复密钥。区块链2000可以包含区块2010。区块2010可以是区块链2000的初始区块，也可以是区块链2000中的任何其他区块。区块2010可以包含多个事件2012，2014，2016。区块链2000中的大多数事件，例如事件2012和2014，都由进入事件的用户(例如Alice)的公钥签名。但是，可以由恢复密钥2050对事件(例如事件2016)进行签名。
恢复密钥2050是绕过整个权限和策略计算的特殊密钥。甚至在处理器确定策略是否授权事件2016之前，处理器可以确定该事件是否由恢复密钥2050签名。如果使用恢复密钥2050对事件进行签名，则处理器确定无论授权和策略如何都允许该事件。因此，恢复密钥2050优先于整个权限和策略。
恢复密钥2050需要得到非常好的保护。因此，恢复密钥2050可以被拆分成多个部分2052，2054，2056(为了简洁仅标记了三个)，例如30个部分。不同的部分2052，2054，2056可以被放在不同的安全地方，例如不同的HSM，每个都有不同的操作过程。可以对不同的部分2052，2054，2056进行加密，一个人可以有将密钥部分2052，2054，2056存储在文件中的密码，另一个人可以有从文件取得密钥部分2052，2054，2056的密码。恢复密钥2050的组装可能需要具有恢复密钥2050的2052，2054，2056的部分的所有或至少大多数设备和用户的参与，从而防止意外使用恢复密钥2050。
恢复密钥2050的存在和使用可以是可选的。可以将恢复密钥设置为预定值，例如全零，这向处理器表示恢复密钥2050尚未被生成并且不存在。处理器可以忽略由设置为预定值的恢复密钥2050签名的任何事件。
拆分密钥
图21示出了当用户设备失陷时限制对加密数据的攻击的拆分密钥系统。用户设备2100可以存储使用多个密钥(例如本申请中所述的通道会话密钥2120，以及拆分密钥2130)加密的数据2110。拆分密钥2130可以被分成至少两个部分2132，2134。第一密钥部分2132可以被存储在服务器2140上，而第二密钥部分2134可以被存储在用户设备2100上。
为了加密数据，用户设备2100可以从服务器2140请求第一密钥部分2132。在接收到第一密钥部分2132时，用户设备2100可以计算作为第一密钥部分2132和第二密钥部分2134的组合的密钥导出函数(KDF)，以获得用于加密数据的拆分密钥2130。类似地，为了解密加密数据2110，用户设备2100可以从服务器2140请求第一密钥部分2132并使用KDF计算拆分密钥2130，该KDF是第一密钥部分2132和第二密钥部分2134的组合。
一旦用户设备2100计算出拆分密钥2130，用户设备2100可以基于预定规则忘记第一密钥部分2132。预定规则可以声明每次用户设备2100被暂停使用和/或重启时，第一密钥部分2132被忘记；对于使用拆分密钥2130打开的每三个文件，第一密钥部分2132被忘记；每次关闭与密钥导出函数相关联的应用时，第一密钥部分2132被忘记；每次用户设备2100的地理位置和/或IP地址在预定空间之外时，第一密钥部分2132被忘记；等等。
因为用户设备2100基于预定规则忘记了第一密钥部分2132，所以服务器2140可以对用户设备2100撤销访问。例如，如果服务器2140被通知用户设备2100已经失陷，例如被攻击者偷窃和/或侵入，则服务器2140可以记录来自用户设备2100的对第一密钥部分2132的请求应该被拒绝。下次用户设备2100请求第一密钥部分2132时，服务器2140可以拒绝提供第一密钥部分2132。因此，加密数据2110在用户设备2100上仍是加密的并且攻击者不可使用该加密数据2110。
为了增加第一密钥部分2132的安全性，服务器2140可以在提供第一密钥部分2132之前要求多因素认证。例如，服务器2140可以要求第二设备2150向服务器2140提供认证。一旦服务器2140从第二设备2150接收到认证，服务器2140就可以将第一密钥部分2132提供给用户设备2100。
系统升级
图22示出了对区块链语义解释的更新。区块链2200可以包含区块2210，2220，2230等。用于解释区块链2200的语义的规则可以被编码在区块2210，2220，2230中，并且可以被代表为例如Rust，Python，Go，或专有语言之类的编程语言的源代码。更新对区块链2200的语义的解释(包括权限，策略等)可以在区块链2200中发生。
例如，区块2210可以包含更新如何解释后续于区块2210的区块2230的源代码。通过将语义放入区块链2200，系统的遍布在多个客户端并包含不同的区块链的每个实例可以在它们接收到区块2210时更新用于解释区块链语义的本地规则。因此，根据第一组规则解释区块2210之前的区块2220，而根据区块2210确立的第二组规则解释区块2210后续的区块2230。
例如，解释区块链2200语义的规则可以控制竞争条件如何被解决。这样的规则可以在图5中的系统策略530，图5中的用户策略540，或图5中的应用策略550中规定。因此，区块2210可以更新系统530，用户540，和/或应用550策略。
为了防止在解释区块链2200的语义的规则中引入漏洞(bug)，可以形式地验证策略引擎530，540，550。形式验证是使用形式数学方法证明策略530，540，550关于某个形式规范或属性的正确性的行为。形式验证可以提供策略530，540，550中没有漏洞的保证。
流程图
图23是生成提供授权凭证的令牌的方法的流程图。在步骤2300，处理器可以通过创建定义用户将区块附加到区块链末尾的权限的区块来创建包括多个区块的区块链。区块可以包括标识用户的密码化用户ID和与密码化用户ID相关联的权限。权限可以定义至少与密码化用户ID相关联的操作以在区块链上执行。例如，操作可以包括对区块链和/或与区块链相关联的加密数据的读访问，写访问和/或读/写访问。区块链可不被加密。
在步骤2310，处理器可以从请求设备接收访问区块链的请求。该请求可以包括与发出请求的用户相关联的密码化用户ID，其中密码化用户ID可以被区块链授权以执行某些操作。请求设备可以是用户设备。
在步骤2320中，处理器可以通过计算记录在区块链中的权限来确定发出请求的用户是否具有访问区块链的权限，包括从初始区块到最末区块检查区块链。执行权限计算可能很昂贵。
在步骤2330中，处理器可以在确定发出请求的用户具有访问区块链的权限时生成向发出请求的用户授予对区块链的访问的令牌。令牌可以是证明处理器已经完成昂贵操作的证书，该操作例如计算区块链上的权限，或者检查用户的密码。因此，下次处理器接收到令牌时，处理器不必执行昂贵的操作，而是可以检查令牌，其可以是比例如计算区块链中的权限更便宜的操作。在步骤2340，处理器可以将令牌发送到请求设备。
令牌可以包括消息和采用两个对象的HMAC，即消息和保密根密钥，如本申请中所解释的。例如，消息可以是标识被授权访问区块链的用户的许可。
在一个实施例中，当用户想读取区块链时，用户可以发送签名消息，该签名消息提供密码化用户ID并标识用户想读取的区块链(例如团队和/或空间)的一部分。有权访问区块链的处理器可以检查与密码化用户ID，签名和事实数据库相关联的公钥，以确认密码化用户ID有访问所请求的团队和/或空间的许可。如果处理器没有做出确认，处理器可以拒绝用户访问。如果处理器确认用户有访问团队和/或空间的权限，则处理器可以创建包括密码化用户和所请求团队和/或空间的表示的令牌。令牌可以授予密码化用户ID读许可。
为了生成令牌，处理器可以创建标识保密根密钥的密钥标识符。密钥标识符可以实现为与服务器相关联的数据库的索引。可以使用公共密钥或保密密钥加密进一步保护保密根密钥。处理器可以创建令牌授予的对区块链的许可，例如用户ID或团队和/或空间ID。此外，处理器可以创建保密根密钥和许可的密码化哈希。密码化哈希可以是HMAC。处理器可以将密钥标识符，许可和密码化哈希添加到令牌。令牌可以向团队和/或空间给予读许可。
为了确定发出请求的用户是否具有作为区块链的权限，处理器可以在不计算区块链中记录的权限的情况下确定请求是否使用恢复密钥进行签名。如本申请所解释的，恢复密钥可以覆盖记录在区块链中的权限。处理器可以生成第二令牌，在确定请求用恢复密钥签名后，向发出请求的用户授予对区块链的无限制访问。
为了防止攻击者得到对恢复密钥的访问，可以将恢复密钥分成多个部分，其中每个部分使用不同的保密加密密钥进行加密，每个加密部分分布在例如HSM之类的多个设备中。
为了防止攻击者通过使端点(例如用户设备)失陷来得到对系统的访问，可以使用拆分密钥对加密数据进行额外加密。拆分密钥可以分为两部分，存储在服务器上的第一部分，存储在用户设备上的第二部分。为了解密加密数据，用户设备必须向服务器请求拆分密钥的第一部分，即第一密码化密钥。在接收到对第一密码化密钥的请求时，服务器可以确定用户设备是否被许可接收第一密码化密钥。
例如，用户设备可被报告为被盗，因此不被许可接收第一密码化密钥。服务器可以在确定用户设备不被许可接收第一密码化密钥时拒绝发送第一密码化密钥。如果用户设备接收到密码化密钥，则用户设备可以计算密钥导出函数，该函数是第一和第二密码化密钥的组合，例如HMAC，以获得可以用于解密加密数据的密钥。
对存储在区块链中的权限和/或策略计算的软件更新本身可以被存储在区块链中。服务器可以接收关于区块链语义解释的更新。服务器可以通过将更新存储在区块链中来确保在多个用户设备中的区块链语义解释的一致性。
图24是创建减弱的令牌的方法的流程图。在步骤2400，处理器可以获得授予对区块链的访问的令牌。对区块链的访问可以由区块链定义的第一权限源来许可。也就是说，第一权限源可以是记录权限和策略的区块链本身。令牌可以包括标识保密根密钥的密钥标识符，访问由第一授权源授权的区块链的第一许可，以及保密根密钥和许可的第一密码化哈希。可以基于请求者是否具有对加密数据的读访问，或者在所请求的团队和/或空间中的成员资格来授予对区块链的访问。
第一许可可以包括被授予第一许可的密码化用户ID，以及密码化用户ID有权访问的区块链的至少一部分的标识，例如团队或空间。第一许可可以包括被许可由密码化用户ID执行的操作，或者可以不包括被许可的操作且可以认为该操作是只读的。
在步骤2410中，处理器可以从请求设备接收访问区块链的请求，具有来自限制与请求设备相关联的访问的第二权限源的第二许可。第二权限源可以是访问控制服务器，例如活动目录。访问控制服务器可以是企业IT系统的一部分。
第二许可可以包括时间限制或地理位置限制。例如，第二许可可以规定轴被许可的时间窗口，或访问被许可的地理位置。在更具体的示例中，如果用户离开建筑物，则可以撤销对区块链的访问。第二许可还可以包括互联网地址限制，例如，只要请求设备的互联网协议(IP)地址在规定的IP地址范围内，就许可对请求设备的访问。
在步骤2420中，处理器可以通过将来自企业的第二许可添加到令牌，计算第一密码化哈希和第二许可的第二密码化哈希，以及从令牌中移除第一密码化哈希来减弱由令牌授予的访问，从而获得减弱的令牌。分别从第一权限源和第二权限源获得的第一许可和第二许可可以转化为令牌和减弱的令牌中的多个许可和条目。在步骤2430中，处理器可以将减弱的令牌发送到请求设备，例如用户设备。
为了获得令牌，处理器可以计算存储在区块链中的权限。区块链可以包括多个区块，其中区块链中的区块定义了密码化用户ID的权限。权限可以定义与密码化用户ID相关联的至少一个操作以在区块链上执行。为了确定发出请求的用户是否具有访问区块链的权限，处理器可以计算记录在区块链中的权限，包括检查从初始区块到最后区块的区块链。处理器可以在确定发出请求的用户具有访问区块链的权限时生成向发出请求的用户授予对区块链的访问的令牌。
处理器可以在收到有效令牌后授予对区块链的访问。处理器可以接收访问区块链的一部分的请求和减弱的令牌。处理器可以使用存储在减弱的令牌中的密钥ID获得保密根密钥。处理器可以计算保密根密钥和第一许可的密码化哈希以获得第三密码化哈希。处理器可以计算第三密码化哈希和第二许可的密码化哈希以获得第四密码化哈希。处理器可以通过比较包括在减弱的令牌中的第二密码化哈希和第四密码化哈希来确定包括在减弱的令牌中的第二密码化哈希是否匹配第四密码化哈希。在确定包括在减弱的令牌中的第二密码化哈希和第四密码化哈希匹配时，处理器可以授予访问区块链的该部分的请求。如果第二密码化哈希和第四密码化哈希不匹配，则处理器可以拒绝授予请求，因为减弱的令牌无效。
可以通过向减弱的令牌添加额外的许可(即约束或警告)来进一步减弱该减弱的令牌。例如，减弱的令牌的持有者可能想将他对区块链的访问的一部分委托给第三方。因此，减弱的令牌的持有者可以请求创建额外的减弱的令牌，将部分访问授予第三方。例如，令牌持有者可以规定团队中第三方可以有权访问的特定区块。
为了创建更进一步的减弱的令牌，处理器可以接收减弱的令牌和对第三许可的请求。在一个实施例中，处理器可以确定第三许可是否被第一许可和第二许可授权。例如，第一许可和第二许可可以授予团队1用户Alice的访问，而第三许可可以请求对团队2的访问。处理器可以确定用户Alice无权访问团队2，并且可以拒绝创建减弱的令牌。在另一个示例中，在确定第三许可由第一许可和第二许可授权时，处理器可以创建第二减弱的令牌，通过计算第二密码化哈希和第三许可的密码化哈希，从减弱的令牌删除第二密码化哈希，将第三许可添加到减弱的令牌，并将第三密码化哈希添加到减弱的令牌，从而创建第二减弱的令牌。
在另一个实施例中，处理器不确定许可的有效性，而是仅创建减弱的令牌。可以在确定令牌的有效性时确定许可的有效性。如果第三许可请求第一和第二许可未授予的数据，则可以向请求者提供空响应。
处理器可以根据恢复密钥授予令牌。处理器可以通过确定请求是否使用恢复密钥进行签名而无需计算区块链中记录的权限，来确定发出令牌请求的用户是否有权访问区块链。处理器可以生成第二令牌，在确定请求是用恢复密钥签名后，向发出请求的用户授予对区块链的无限制访问。如本申请中所述，处理器可以将恢复密钥分解为多个部分，例如30个部分，对每个部分进行加密，将加密的密钥部分分布给多个设备，并且需要至少大多数设备的参与来组装来自多个部分的恢复密钥。
为了防止攻击者通过使用户设备失陷来侵入系统，处理器可以实现拆分密钥，其中第一密码化密钥存储在服务器上，第二密码化密钥存储在用户设备中。当处理器从用户设备接收到对第一密码化密钥的请求时，处理器可以在接收到请求时确定用户设备是否被许可接收第一密码化密钥。例如，如果用户设备被报告为被盗，则处理器不许可用户设备接收存储在服务器上的第一密码化密钥。如果用户设备接收到密码化密钥，则用户设备可以执行作为第一和第二密码化密钥(例如HMAC)的组合的KDF，以获得可以用于解密加密数据的密钥。
处理器可以接收关于区块链语义解释的更新。处理器可以通过将更新存储在区块链内来确保跨多个用户设备的区块链语义解释的一致性。
为了强制执行时间敏感许可，例如存储在令牌中的时间敏感许可，处理器可以创建包括多个区块的时钟区块链。多个区块中的每个区块可以包括大于前一区块的时间戳的时间戳。处理器可以在区块链中的区块和时钟区块链中的时钟区块之间创建临时关系。例如，区块与时钟区块之间的链接可以表示该区块已被创建在时钟区块之前，时钟区块之后，与时钟区块同时，在时钟区块之后和/或之前的规定时间内，等。
处理器可以接收包括限时许可的令牌，以及访问区块链的部分的请求。处理器可以确定时限许可是否由与区块链的被请求部分相关联的时钟区块链授权。处理器可以在确定时限许可未被时钟区块链授权时，拒绝访问该部分区块链的请求。例如，时钟区块链中的最新区块可以超过限时许可，或者区块链的被请求部分已在限时许可窗口之外创建，等等。
计算机
图25是计算机系统2500的示例形式的机器的图解代表，其中可以执行一组指令，用于使机器执行本文讨论的任何一个或多个方法或模块。
在图25的示例中，计算机系统2500包括处理器，存储器，非易失性存储器，和接口设备。为说明简单起见，省略了多种常见部件(例如，高速缓存存储器)。计算机系统2500旨在说明硬件设备，其上实现有图1-24的示例中所述的任何部件(以及本说明书中所述的任何其他部件)。计算机系统2500可以是任何适用的已知或方便的类型。计算机系统2500的部件可以经由总线或通过一些其他已知或方便的设备耦接在一起。
计算机系统2500可以代表服务器，例如图1中的100，图7中的750，图10A中的1000，图11A-C中的1140，图14中的1400，图15中的1500。计算机系统2500可以代表设备，例如图1中的110-116，图7中的700-720，图10A中的1010-1030，图11A-11C中的1100-1120，图14中的1440，图15中的1540，图15中的1450，图15中的1550。系统2500的处理器可以执行本申请中所述的多种方法和指令。系统2500的主存储器，非易失性存储器，和/或驱动单元可以存储要由处理器执行的指令。设备1110-1160，700-720，1010-1030，1100-1120，和服务器100，750，1000，1140，1400，1500，1440，1540可以使用系统2500的网络接口设备相互通信。例如，图14中的令牌1480，1494，图15中的1580，1594可以经由系统2500的网络接口进行通信。
本技术考虑采用任何合适的物理形式的计算机系统2500。作为示例而非限制，计算机系统2500可以是嵌入式计算机系统，片上系统(SOC)，单板计算机系统(SBC)(如，例如，计算机模块(COM)或系统级模块(SOM))，台式计算机系统，膝上型计算机或笔记本计算机系统，交互式自助服务终端，大型机，计算机系统网格，移动电话，个人数字助理(PDA)，服务器，或其中两个或多个的组合。在适合的情况下，计算机系统2500可以包括一个或多个计算机系统2500；是单一的或分布式的；跨多个位置；跨多台机器；或驻留在云中，该云可能包括一个或多个网络中的一个或多个云部件。在适合的情况下，一个或多个计算机系统2500可以在没有实质空间或临时限制的情况下执行本文描述或说明的一种或多种方法的一个或多个步骤。作为示例而非限制，一个或多个计算机系统2500可以实时或以批处理模式执行本文描述或说明的一种或多种方法的一个或多个步骤。在适合的情况下，一个或多个计算机系统2500可以在不同时间或在不同位置执行本文描述或说明的一种或多种方法的一个或多个步骤。
例如，处理器可以是传统的微处理器，例如英特尔奔腾微处理器或摩托罗拉powerPC微处理器。相关领域的技术人员将认识到，术语“机器可读(存储)介质”或“计算机可读(存储)介质”包括处理器可访问的任何类型的设备。
存储器通过例如总线耦接到处理器。作为示例但非限制，存储器可以包括随机存取存储器(RAM)，例如动态RAM(DRAM)和静态RAM(SRAM)。存储器可以是本地的，远程的，或分布式的。
总线还将处理器耦接到非易失性存储器和驱动单元。非易失性存储器通常是磁软盘或硬盘，磁光盘，光盘，只读存储器(ROM)，例如CD-ROM，EPROM，或EEPROM，磁卡或光卡，或用于大量数据的另一种存储形式。在计算机2500中的软件执行期间，这些数据中的一些通常通过直接存储器访问过程写入存储器中。非易失性存储可以是本地的，远程的，或分布式的。非易失性存储器是可选的，因为可以使用存储器中可用的所有适用数据创建系统。典型的计算机系统通常至少包括处理器，存储器，和将存储器耦接到处理器的设备(例如总线)。
软件通常存储在非易失性存储器和/或驱动单元中。事实上，在存储器中存储整个大型程序甚至是不可能的。然而，应该理解，为了运行软件，如有必要，它会被移动到适合处理的计算机可读位置，为了说明的目的，该位置在本文中称为存储器。即使软件被移到存储器中执行，处理器通常也会使用硬件寄存器来存储与软件相关联的值，以及理想情况下用于加速执行的本地缓存。如本文所用，当软件程序被称为“在计算机可读介质中实现”时，假定软件程序是存储在任何已知或方便的位置(从非易失性存储器到硬件寄存器)。当与程序关联的至少一个值存储在处理器可读的寄存器中时，处理器被认为是“被配置为执行程序”。
总线还将处理器耦接到网络接口设备。该接口可以包括调制解调器或网络接口中的一个或多个。应当理解，调制解调器或网络接口可以被认为是计算机系统2500的一部分。该接口可以包括模拟调制解调器，isdn调制解调器，缆线调制解调器，令牌环接口，卫星传输接口(例如“直接PC”)，或用于将计算机系统耦接到其他计算机系统的其他接口。该接口可以包括一个或多个输入和/或输出设备。作为示例但非限制，I/O设备可以包括键盘，鼠标或其他指点设备，磁盘驱动器，打印机，扫描仪，和其他输入和/或输出设备，包括显示设备。作为示例但非限制，显示设备可以包括阴极射线管(CRT)，液晶显示器(LCD)，或一些其他适用的已知或方便的显示设备。为简单起见，假设图25的示例中未描绘的任何设备的控制器驻留在接口中。
在操作中，计算机系统2500可以由包括文件管理系统的操作系统软件控制，例如磁盘操作系统。具有相关联的文件管理系统软件的操作系统软件的一个示例是来自华盛顿州雷德蒙德的微软公司的被称为
Figure BDA0003962642670000461
的操作系统家族及其关联的文件管理系统。操作系统软件及其相关联的文件管理系统软件的另一个示例是LinuxTM操作系统及其相关联的文件管理系统。文件管理系统通常存储在非易失性存储器和/或驱动单元中，并使处理器执行操作系统所需的多种行为以输入和输出数据并将数据存储在存储器中，包括将文件存储在非易失性存储器和/或驱动单元中。
详细描述的一些部分可以根据算法和对计算机存储器内的数据位的操作的符号代表来呈现。这些算法描述和代表是数据处理领域的技术人员用来最有效地将他们的工作内容传达给本领域的其他技术人员的手段。算法在这里，并且通常被认为是导致期望结果的有条理的操作序列。操作是那些需要对物理量进行物理操作的操作。通常，尽管不是必须的，这些量采用能够被存储，传输，组合，比较，和以其他方式操作的电或磁信号的形式。主要出于常用的原因，已被证明有时将这些信号称为位，值，元素，符号，字符，术语，数字等是方便的。
然而，应该记住，所有这些和类似的术语都将与适合的物理量相关联，并且只是应用于这些量的方便标签。除非从下面的讨论中明确指出，否则应理解，在说明书通篇中，使用诸如“处理”或“计算”或“算出”或“确定”或“显示”或“生成”等术语的讨论，指计算机系统或类似电子计算设备的动作和过程，它操纵计算机系统的寄存器和存储器中被代表为物理(电子)量的数据并将其转换为计算机系统存储器或寄存器或其他此类信息存储，传输，或显示设备中类似地被代表为物理量的其他数据。
本文提出的算法和显示与任何特定的计算机或其他装置没有内在的关系。多种通用系统可以与根据本文的教导的程序一起使用，或者可以证明构造更专业的装置来执行一些实施例的方法是方便的。多种这些系统所需的结构将在下面的描述中出现。此外，这些技术没有参考任何特定的编程语言来描述，因此可以使用多种编程语言来实现多种实施例。
在替代实施例中，机器作为独立设备操作或可以连接(例如，联网)到其他机器。在网络化部署中，机器可以在客户端-服务器网络环境中以服务器或客户端机器运行，或者在对等(或分布式)网络环境中作为对等机器运行。
机器可以是服务器计算机，客户端计算机，个人计算机(PC)，平板PC，膝上型计算机，机顶盒(STB)，个人数字助理(PDA)，蜂窝电话，iPhone，黑莓，处理器，电话，网络设备，网络路由器，交换机或桥接器，或任何能够执行规定该机器要采取的动作的一组指令(顺序或其他)的机器。
虽然机器可读介质或机器可读存储介质在示例性实施例中被示为单个介质，但术语“机器可读介质”和“机器可读存储介质”应理解为包括存储一组或多组指令的单个介质或多个介质(例如，集中式或分布式数据库，和/或相关的缓存和服务器)。术语“机器可读介质”和“机器可读存储介质”还应被理解为包括能够存储，编码或携带一组指令以供机器执行并且使机器执行本文公开的技术和创新的任何一种或多种方法或模块。
通常，为实现本公开的实施例而执行的例程可以被实现为操作系统或称为“计算机程序”的特定应用，部件，程序，对象，模块或指令序列的一部分。计算机程序通常包括在不同时间设置在计算机中的多种存储器和存储设备中的一条或多条指令，当被计算机中的一个或多个处理单元或处理器读取和执行时，使计算机执行操作以执行涉及本技术的多个方面的元素。
此外，虽然已经在全功能计算机和计算机系统的情境中描述了实施例，但是本领域技术人员将理解多种实施例能够以多种形式作为程序产品被分布，并且本技术同样适用无论用于实际实现分布的特定类型的机器或计算机可读介质如何。
机器可读存储介质，机器可读介质，或计算机可读(存储)介质的进一步示例包括但不限于可记录类型介质，例如易失性和非易失性存储器设备，软盘和其他可移动磁盘，硬盘驱动器，光盘(例如，光盘只读存储器(CD ROMS)，数字多功能光盘(DVD)等)等，以及诸如数字和模拟通信链路之类的传输类型介质。
在一些情况下，存储器设备的操作，例如从二进制一到二进制零或反之的状态改变，例如可以包括变换，例如物理变换。对于特定类型的存储器设备，这样的物理变换可以包括将物品物理变换到不同的状态或事物。例如，但不限于，对于一些类型的存储器设备，状态变化可涉及电荷的累积和储存或储存电荷的释放。同样，在其他存储器设备中，状态变化可以包括磁取向的物理变化或转变或者分子结构的物理变化或转变，例如从结晶到无定形或反之亦然。前述内容并非旨在详尽列出其中存储器设备中二进制一到二进制零或反之的状态变化可包括变换，例如物理变换。而是，前述内容旨在作为说明性示例。
存储介质通常可以是非暂时性的或包括非暂时性设备。在此情境中，非暂时性存储介质可以包括有形的设备，这意味着该设备具有具体的物理形式，尽管该设备可以改变其物理状态。因此，例如，非暂时性是指尽管状态发生了这种变化，设备仍然是有形的。
评论
说明书中使用的语言主要是为了可读性和指导目的而选择的，并且可以不是为了描述或限制本技术主题而选择的。因此，意欲本技术的范围不受此详细描述限制，而是受基于此的申请发布的任何权利要求限制。因此，多种实施例的公开旨在说明而非限制在所附权利要求中阐述的实施例的范围。

Claims (22)

1.一种计算机实现的方法，包括：
通过以下方式创建包括多个区块的区块链：
创建定义用户的权限的区块，所述区块包括标识所述用户的密码化用户ID和与所述密码化用户ID相关联的所述权限，所述权限定义与所述密码化用户ID相关联的在所述区块链上执行的至少一个操作；
将所述区块附加到所述区块链的末尾，其中所述区块链未被加密；
从请求设备接收访问所述区块链的请求，所述请求包括与发出所述请求的所述用户相关联的密码化用户ID；
通过计算记录在所述区块链上的权限，确定发出所述请求的所述用户是否有访问所述区块链的所述权限；
在确定发出所述请求的所述用户具有访问所述区块链的所述权限后，生成授予发出所述请求的所述用户访问所述区块链的权限的令牌；以及
将所述令牌发送到所述请求设备。
2.根据权利要求1所述的方法，所述生成所述令牌包括：
创建标识保密根密钥的密钥标识符；
创建由所述令牌授予的对所述区块链的许可；
创建所述保密根密钥和所述许可的密码化哈希；以及
将所述密钥标识符，所述许可和所述密码化哈希添加到所述令牌中。
3.根据权利要求1所述的方法，所述确定发出所述请求的所述用户是否具有所述权限包括：
通过确定所述请求是否使用恢复密钥来签名来确定发出所述请求的所述用户是否有访问所述区块链的所述权限，无需计算所述区块链中记录的所述权限，包括检查所述区块链从初始区块到最后一个区块；以及
在确定所述请求已使用所述恢复密钥签名后，生成向发出所述请求的所述用户授予对所述区块链的无限制访问的第二令牌。
4.根据权利要求3所述的方法，包括：
将所述恢复密钥分成多个部分；
加密所述多个部分中的至少一个部分子集；以及
将所述加密的部分子集和所述多个部分的其余部分分布给多个设备。
5.如权利要求1所述的方法，包括：
将第一密码化密钥存储在服务器上；
向用户设备发送第二密码化密钥；
从所述用户设备接收对所述第一密码化密钥的请求；
在接收到所述请求时，确定所述用户设备是否被许可接收所述第一密码化密钥；以及
在确定所述用户设备不被许可接收所述第一密码化密钥时拒绝发送所述第一密码化密钥。
6.根据权利要求1所述的方法，包括：
接收关于所述区块链的语义解释的更新；
通过将所述更新存储在所述区块链中，确保跨多个用户设备的所述区块链的所述语义解释的一致性。
7.一种计算机实现的方法，包括：
获得授予对区块链的访问的令牌，对所述区块链的所述访问由所述区块链定义的第一权限源许可，所述令牌包括标识保密根密钥的密钥标识符，访问所述区块链的第一许可由所述区块链定义的所述第一权限源授权，以及所述保密根秘钥和所述第一许可的第一密码化哈希；
接收来自请求设备的访问所述区块链的请求和来自限制与所述请求设备相关联的访问的第二权限源的第二许可；
通过将来自所述第二权限源的所述第二许可添加到所述令牌，计算所述第一密码化哈希和所述第二许可的第二密码化哈希，并从所述令牌中移除所述第一密码化哈希，从而获得减弱的令牌，来减弱由所述令牌授予的所述访问；以及
将所述减弱的令牌发送给所述请求设备。
8.根据权利要求7所述的方法，其中所述区块链包括多个区块，其中所述区块链中的区块定义了密码化用户ID的权限，所述权限至少定义了要在所述区块链上执行的与所述密码化用户ID相关联的操作，所述获得所述令牌包括：
通过计算记录在所述区块链中的所述权限，包括从初始区块到最末区块检查所述区块链，来确定发出所述请求的用户是否具有访问所述区块链的权限；以及
在确定发出所述请求的所述用户具有访问所述区块链的所述权限后，生成授予发出所述请求的所述用户访问所述区块链的所述令牌。
9.根据权利要求7所述的方法，所述第一许可包括被授予所述第一许可的密码化用户ID，以及所述密码化用户ID有权访问的所述区块链的至少一部分的标识。
10.根据权利要求7所述的方法，所述第二许可包括时间限制或地理位置限制。
11.根据权利要求7所述的方法，包括：
接收访问所述区块链和所述减弱的令牌的第二请求；
获得所述保密根密钥；
计算所述保密根密钥和所述第一许可的密码化哈希来获得第三密码化哈希；
计算所述第三密码化哈希和所述第二许可的所述密码化哈希来获得第四密码化哈希；
通过比较包括在所述减弱的令牌中的所述第二密码化哈希和所述第四密码化哈希来确定包括在所述减弱的令牌中的所述第二密码化哈希是否与所述第四密码化哈希匹配；以及
在确定所述减弱的令牌中包含的所述第二密码化哈希和所述第四密码化哈希匹配时，授予所述第二请求访问所述区块链。
12.根据权利要求7所述的方法，包括：
接收所述减弱的令牌和第三许可请求；
创建第二减弱的令牌，通过计算所述第二密码化哈希和所述第三许可的密码化哈希来获得第三密码化哈希，从所述减弱的令牌中删除所述第二密码化哈希，将所述第三许可添加到所述减弱的令牌，并将所述第三密码化哈希添加到所述减弱的令牌，从而创建所述第二减弱的令牌。
13.根据权利要求7所述的方法，其中所述区块链包括多个区块，其中所述区块链中的区块定义了与用户相关联的密码化用户ID的权限，所述权限至少定义了与所述密码化用户ID相关联的在所述区块链上执行的操作，所述获得所述令牌包括：
通过确定所述请求是否用恢复密钥签名来确定发出所述请求的所述用户是否有访问所述区块链的权限，无需计算所述区块链中记录的所述权限，包括从初始区块到最末区块检查所述区块链；以及
在确定所述请求是用所述恢复密钥签名后，生成授予发出所述请求的所述用户对所述区块链的无限制访问的第二令牌。
14.根据权利要求13所述的方法，包括：
将所述恢复密钥分成多个部分；
加密所述多个部分中的至少一个部分子集；以及
将所述加密的部分子集和所述多个部分的其余部分分布给多个设备。
15.如权利要求7所述的方法，包括：
在服务器上存储第一密码化密钥；
将第二密码化密钥发送给用户设备；
接收来自所述用户设备的对所述第一密码化密钥的请求；
在接收到所述请求时，确定所述用户设备是否被许可接收所述第一密码化密钥；以及
在确定所述用户设备不被许可接收所述第一密码化密钥时，拒绝发送所述第一密码化密钥。
16.根据权利要求7所述的方法，包括：
接收关于所述区块链的语义解释的更新；
通过将所述更新存储在所述区块链中，确保跨多个用户设备的所述区块链的所述语义解释的一致性。
17.一种系统，包括：
至少一个处理器；以及
耦接到所述至少一个处理器的存储器，所述存储器包括计算机可执行指令，当该指令由所述至少一个处理器执行时，执行一种方法，该方法包括：
获得授予对区块链的访问的令牌，对所述区块链的所述访问由所述区块链定义的第一权限源许可，所述令牌包括标识保密根密钥的密钥标识符，由所述区块链定义的所述第一权限源授权的访问所述区块链的第一许可，以及所述保密根秘钥和所述第一许可的第一密码化哈希；
接收来自用户设备的访问所述区块链的请求和来自限制与所述用户设备相关联的访问的第二权限源的第二许可；
通过将来自所述第二权限源的所述第二许可添加到所述令牌，计算所述第一密码化哈希和所述第二许可的第二密码化哈希，并从所述令牌中移除所述第一密码化哈希，从而获得减弱的令牌，来减弱由所述令牌授予的所述访问；以及
将所述减弱的令牌发送给所述用户设备。
18.如权利要求17所述的系统，所述第二权限源包括企业访问控制服务器。
19.根据权利要求17所述的系统，所述处理器执行所述方法包括：
创建包括多个区块的时钟区块链，其中所述多个区块中的每个区块包括大于前面的区块的时间戳的时间戳；以及
在所述区块链中的区块和所述时钟区块链中的区块之间创建临时关系。
20.根据权利要求19所述的系统，所述处理器执行所述方法包括：
接收包括限时许可的所述令牌，和访问所述区块链的第二请求；
确定所述限时许可是否被与所述区块链相关联的所述时钟区块链授权；以及
在确定所述限时许可未被所述时钟区块链授权后，拒绝访问所述区块链的所述请求。
21.根据权利要求17所述的系统，所述处理器执行所述方法包括：
接收访问所述区块链和所述减弱的令牌的第二请求；
获得所述保密根密钥；
计算所述保密根密钥和所述第一许可的密码化哈希来获得第三密码化哈希；
计算所述第三密码化哈希和所述第二许可的所述密码化哈希来获得第四密码化哈希；
通过比较包括在所述减弱的令牌中的所述第二密码化哈希和所述第四密码化哈希来确定包括在所述减弱的令牌中的所述第二密码化哈希是否与所述第四密码化哈希匹配；以及
在确定所述减弱的令牌中包含的所述第二密码化哈希和所述第四密码化哈希匹配时，授予所述第二请求访问所述区块链。
22.根据权利要求17所述的系统，所述处理器执行所述方法包括：
接收所述减弱的令牌和对第三许可的请求；
确定所述第三许可是否被所述第一许可和所述第二许可授权；
在确定所述第三许可被所述第一许可和所述第二许可授权时，创建第二减弱的令牌，通过计算所述第二密码化哈希和所述第三许可的密码化哈希来获得第三密码化哈希，从所述减弱的令牌删除所述第二密码化哈希，将所述第三许可添加到所述减弱的令牌，并将所述第三密码化哈希添加到所述减弱的令牌，从而创建所述第二减弱的令牌。
CN202180037927.0A 2019-04-05 2021-03-23 在企业环境中区块链，管理组权限和访问的集成 Pending CN115701301A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310124137.7A CN116112274B (zh) 2019-04-05 2021-03-23 在企业环境中区块链，管理组权限和访问的集成

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201962830002P 2019-04-05 2019-04-05
US16/828,003 US11341261B2 (en) 2019-04-05 2020-03-24 Integration of a block chain, managing group authority and access in an enterprise environment
US16/828,003 2020-03-24
PCT/US2021/023633 WO2021195052A1 (en) 2019-04-05 2021-03-23 Integration of a block chain, managing group authority and access in an enterprise environment

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202310124137.7A Division CN116112274B (zh) 2019-04-05 2021-03-23 在企业环境中区块链，管理组权限和访问的集成

Publications (1)

Publication Number Publication Date
CN115701301A true CN115701301A (zh) 2023-02-07

Family

ID=72662513

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202310124137.7A Active CN116112274B (zh) 2019-04-05 2021-03-23 在企业环境中区块链，管理组权限和访问的集成
CN202180037927.0A Pending CN115701301A (zh) 2019-04-05 2021-03-23 在企业环境中区块链，管理组权限和访问的集成

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202310124137.7A Active CN116112274B (zh) 2019-04-05 2021-03-23 在企业环境中区块链，管理组权限和访问的集成

Country Status (7)

Country Link
US (5) US11341261B2 (zh)
EP (1) EP4127980A4 (zh)
JP (1) JP2023520372A (zh)
CN (2) CN116112274B (zh)
AU (1) AU2021244365A1 (zh)
CA (1) CA3173159A1 (zh)
WO (1) WO2021195052A1 (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102649209B1 (ko) 2016-09-15 2024-03-20 너츠 홀딩스 엘엘씨 암호화된 사용자 데이터 송신 및 저장
CN108306819B (zh) * 2018-04-20 2022-03-04 网易（杭州）网络有限公司 基于区块链的即时通讯系统实现方法、介质和计算设备
US11341259B2 (en) 2018-12-12 2022-05-24 Spideroak, Inc. Managing group authority and access to a secured file system in a decentralized environment
US11341261B2 (en) 2019-04-05 2022-05-24 Spideroak, Inc. Integration of a block chain, managing group authority and access in an enterprise environment
SG11202112915VA (en) * 2019-05-21 2021-12-30 Digifinance Pte Ltd System for restoring lost private key
EP4133397A4 (en) 2020-04-09 2024-04-10 Nuts Holdings Llc NUTS: FLEXIBLE HIERARCHY OBJECT GRAPHS
PL244966B1 (pl) * 2020-07-29 2024-04-08 Dicella Spolka Z Ograniczona Odpowiedzialnoscia Sposób i układ zabezpieczania danych, zwłaszcza danych laboratoriów biotechnologicznych
US11087016B1 (en) 2020-08-20 2021-08-10 Spideroak, Inc. Implementation of a file system on a block chain
US11550307B2 (en) * 2020-08-26 2023-01-10 Accenture Global Solutions Limited Asset management, registry, and tracking on shared blockchain nodes
CN112235301B (zh) * 2020-10-14 2023-06-06 北京金山云网络技术有限公司 访问权限的验证方法、装置和电子设备
CN112468577B (zh) * 2020-11-25 2021-11-02 上海欧冶金融信息服务股份有限公司 一种基于数据映射关系的数据可控共享方法及系统
CN114124499B (zh) * 2021-11-15 2023-08-29 中国科学院沈阳计算技术研究所有限公司 基于区块链的慈善系统隐私保护方法与系统
CN114338034B (zh) * 2021-12-09 2023-07-18 河南大学 一种基于区块链的坝岸监测数据安全共享方法及系统
CN114285865B (zh) * 2021-12-28 2023-08-08 天翼云科技有限公司 共享云硬盘的访问权限控制系统
CN114629684A (zh) * 2022-02-16 2022-06-14 深圳番多拉信息科技有限公司 基于区块链的权限令牌处理方法、系统、装置及存储介质
US11695772B1 (en) * 2022-05-03 2023-07-04 Capital One Services, Llc System and method for enabling multiple auxiliary use of an access token of a user by another entity to facilitate an action of the user
JP2024010419A (ja) * 2022-07-12 2024-01-24 富士通株式会社 アクセス制御方法及びアクセス制御プログラム
CN115964687A (zh) * 2022-12-14 2023-04-14 武汉卓讯互动信息科技有限公司 基于区块链的企业统一账号认证方法和认证平台

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10490304B2 (en) 2012-01-26 2019-11-26 Netspective Communications Llc Device-driven non-intermediated blockchain system over a social integrity network
US10068228B1 (en) * 2013-06-28 2018-09-04 Winklevoss Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
US9397990B1 (en) 2013-11-08 2016-07-19 Google Inc. Methods and systems of generating and using authentication credentials for decentralized authorization in the cloud
WO2015133990A1 (en) * 2014-03-03 2015-09-11 Intel Corporation Methods and apparatus for migrating keys
US9736145B1 (en) * 2014-08-01 2017-08-15 Secureauth Corporation Generation and validation of derived credentials
US9779233B2 (en) * 2015-03-05 2017-10-03 Ricoh Co., Ltd. Broker-based authentication system architecture and design
US10402792B2 (en) 2015-08-13 2019-09-03 The Toronto-Dominion Bank Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers
US20170243209A1 (en) 2016-02-22 2017-08-24 Bank Of America Corporation System for grant of user access and data usage in a process data network
US10289835B1 (en) * 2016-06-13 2019-05-14 EMC IP Holding Company LLC Token seed protection for multi-factor authentication systems
CA3027741C (en) 2016-06-17 2020-07-21 Jonathan WEIMER Blockchain systems and methods for user authentication
US11088855B2 (en) * 2016-07-29 2021-08-10 Workday, Inc. System and method for verifying an identity of a user using a cryptographic challenge based on a cryptographic operation
CN106055993A (zh) * 2016-08-13 2016-10-26 深圳市樊溪电子有限公司 一种用于区块链的加密存储系统及其使用方法
US11018855B2 (en) * 2016-08-17 2021-05-25 Mine Zero Gmbh Multi-factor-protected private key distribution
WO2018039312A1 (en) 2016-08-23 2018-03-01 BBM Health LLC Blockchain-based mechanisms for secure health information resource exchange
JP6888673B2 (ja) * 2016-10-27 2021-06-16 株式会社デンソー デバイスを認証および認可するためのシステムおよび方法
US10438170B2 (en) 2017-01-05 2019-10-08 International Business Machines Corporation Blockchain for program code credit and programmer contribution in a collective
US20180288031A1 (en) * 2017-03-31 2018-10-04 Ca, Inc. Collection point anchored multi-property identity based application specific token origination
US11538031B2 (en) * 2017-03-31 2022-12-27 Vijay Madisetti Method and system for identity and access management for blockchain interoperability
US11750609B2 (en) 2017-04-28 2023-09-05 Cyberark Software Ltd. Dynamic computing resource access authorization
WO2019013818A1 (en) 2017-07-14 2019-01-17 Hitachi Data Systems Corporation METHOD, APPARATUS AND SYSTEM FOR CONTROLLING USER ACCESS TO A DATA STORAGE SYSTEM
US10853772B2 (en) * 2018-04-04 2020-12-01 Vijay K. Madisetti Method and system for exchange of value or tokens between blockchain networks
CN108123936B (zh) * 2017-12-13 2021-04-13 北京科技大学 一种基于区块链技术的访问控制方法及系统
US11315110B2 (en) 2017-12-27 2022-04-26 International Business Machines Corporation Private resource discovery and subgroup formation on a blockchain
WO2019142049A1 (en) * 2018-01-17 2019-07-25 Geeq Corporation Blockchain methods, nodes, systems and products
US10742397B2 (en) 2018-04-26 2020-08-11 Jonathan Sean Callan Method and system for managing decentralized data access permissions through a blockchain
US10965673B2 (en) 2018-05-11 2021-03-30 Civic Technologies, Inc. User ID codes for online verification
CN108768988B (zh) * 2018-05-17 2021-01-05 深圳前海微众银行股份有限公司 区块链访问控制方法、设备及计算机可读存储介质
US11507928B2 (en) 2018-06-05 2022-11-22 International Business Machines Corporation Blockchain and cryptocurrency for real-time vehicle accident management
WO2020003131A1 (en) 2018-06-25 2020-01-02 Blocktest Global Systems and methods to automatically evaluate blockchain-based solution performance
US11294865B2 (en) 2018-08-13 2022-04-05 Citrix Systems, Inc. Using a scan data ledger for distributed security analysis of shared content
US11057366B2 (en) 2018-08-21 2021-07-06 HYPR Corp. Federated identity management with decentralized computing platforms
US20210365584A1 (en) * 2018-08-29 2021-11-25 Visa International Service Association Portable reputation brokering using linked blockchains and shared events
US20200084027A1 (en) 2018-09-06 2020-03-12 Bank Of Montreal Systems and methods for encryption of data on a blockchain
US11341259B2 (en) 2018-12-12 2022-05-24 Spideroak, Inc. Managing group authority and access to a secured file system in a decentralized environment
US11030297B2 (en) * 2019-01-04 2021-06-08 Comcast Cable Communications, Llc Systems and methods for device and user authorization
US11341261B2 (en) 2019-04-05 2022-05-24 Spideroak, Inc. Integration of a block chain, managing group authority and access in an enterprise environment
US11251963B2 (en) 2019-07-31 2022-02-15 Advanced New Technologies Co., Ltd. Blockchain-based data authorization method and apparatus
US11252166B2 (en) 2019-07-31 2022-02-15 Advanced New Technologies Co., Ltd. Providing data authorization based on blockchain
CN110784463B (zh) * 2019-10-24 2021-08-31 深圳市超算科技开发有限公司 一种基于区块链的文件存储和访问方法

Also Published As

Publication number Publication date
EP4127980A1 (en) 2023-02-08
CA3173159A1 (en) 2021-09-30
US11341261B2 (en) 2022-05-24
US20220198046A1 (en) 2022-06-23
US20210224411A1 (en) 2021-07-22
CN116112274B (zh) 2023-11-24
CN116112274A (zh) 2023-05-12
US11074357B2 (en) 2021-07-27
US20210141919A1 (en) 2021-05-13
AU2021244365A1 (en) 2022-11-24
WO2021195052A1 (en) 2021-09-30
US20240135021A1 (en) 2024-04-25
EP4127980A4 (en) 2023-12-27
JP2023520372A (ja) 2023-05-17
US11803654B2 (en) 2023-10-31
US11630910B2 (en) 2023-04-18
US20200320211A1 (en) 2020-10-08

Similar Documents

Publication Publication Date Title
CN116112274B (zh) 在企业环境中区块链，管理组权限和访问的集成
US20210288957A1 (en) Time-based one time password (totp) for network authentication
US11403417B2 (en) Managing group authority and access to a secured file system in a decentralized environment
JP3640338B2 (ja) 安全な電子データ格納、取出しシステムおよび方法
US11841957B2 (en) Implementation of a file system on a block chain
US20130061035A1 (en) Method and system for sharing encrypted content
US11546159B2 (en) Long-lasting refresh tokens in self-contained format
US11604888B2 (en) Digital storage and data transport system
WO2022177964A1 (en) Secure orbit communication
Bećirović et al. Blockchain Redaction in Self-Sovereign Identity
Baig et al. SECURE ROLE BASED ACCESS CONTROL DATA SHARING APPROACH AND CLOUD ENVIRONMENT

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination