Region-based security policy for cloud resources

Abstract

The entity is enabled to access the encrypted resource in response to verifying that the access criteria meet the region-based security policy. For example, a resource request to access an encrypted resource is received from an entity. A determination is made that encrypted resources are allocated to the first region and protection of security policies based on the region. A region attribute attestation is received from the entity indicating that the entity has a region attribute, the region attribute indicating that the entity is associated with the first region. An encrypted version of the region attribute is obtained from a ledger database. The resource request is validated based at least on the attestation of the encryption property and the region property. A verification is made that meets the access criteria of the region-based security policy. An entity is provided with access to the encrypted resource.

Description

Background Technology

[0001] Cloud computing platforms can be used to securely store or manage resources. These resources can be protected using various security policies (e.g., encryption). The system can determine whether to grant users access to resources based on the security policies employed. For example, government authorities may develop security policies to protect the privacy of their residents in accordance with local laws and regulations. Summary of the Invention

[0002] This overview is provided to present, in a simplified form, the selection of concepts further described in the detailed description below. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0003] The embodiments described herein enable an entity to access encrypted resources in response to verification that access criteria based on a region-based security policy are met. For example, an entity receives a resource request to access an encrypted resource. A determination is made that the encrypted resource is allocated to a first region and protected by a region-based security policy. An acknowledgment of a region attribute is received from the entity. The acknowledgment indicates that the entity possesses the region attribute. The region attribute indicates that the entity is associated with a first region. An encrypted attribute is retrieved from a ledger database. The encrypted attribute is an encrypted version of the region attribute. The resource request is authenticated based at least on the acknowledgments of the encrypted attribute and the region attribute. Verification is made as to whether the access criteria based on the region-based security policy are met. Access to the encrypted resource is granted to the entity. As an example, if the acknowledgment of the attribute indicates that the entity is associated with a first region, the embodiments enable the entity to access the encrypted resource. Attached Figure Description

[0004] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments and, together with the description, further serve to explain the principles of the embodiments and enable those skilled in the art to make and use the embodiments.

[0005] Figure 1 A block diagram of an example system for providing access to resources protected by a region-based security policy, according to an example embodiment, is shown.

[0006] Figure 2 A block diagram of a system for storing resources protected by a region-based security policy, according to an example embodiment, is shown.

[0007] Figure 3A A flowchart is shown according to an embodiment of a process for updating a mapping maintained by a ledger database.

[0008] Figure 3B A flowchart is shown, according to an example embodiment, of a process for storing resources protected by a region-based security policy.

[0009] Figure 4 A block diagram of a system for providing access to resources protected by a region-based security policy, according to an embodiment, is shown.

[0010] Figure 5A A flowchart illustrating a process for accessing resources protected by a region-based security policy, according to an embodiment, is shown.

[0011] Figure 5B A flowchart is shown for a process of receiving attribute proofs from an entity according to an embodiment.

[0012] Figure 5C A flowchart is shown, according to an embodiment, of a process for providing decryption resources to an entity.

[0013] Figure 5D A flowchart is shown, according to an embodiment, of a process for an authorized resource processor to provide decrypted resources to an entity.

[0014] Figure 6 A flowchart is shown for a process of retrieving encrypted attributes from a ledger database according to an embodiment.

[0015] Figure 7 A block diagram of an example system for implementing a region-based security policy for cloud resources, according to an example embodiment, is shown.

[0016] Figure 8 A block diagram of an example system for implementing a region-based security policy for cloud resources, according to another example embodiment, is shown.

[0017] Figure 9 A block diagram of an example computer system in which embodiments can be implemented is shown.

[0018] The subject matter of this application will now be described with reference to the accompanying drawings. In the drawings, the same reference numerals denote the same or functionally similar elements. Additionally, the leftmost numeral of the reference numeral(s) identifies the drawing in which the reference numeral(s) first appear. Detailed Implementation

[0019] I. Introduction

[0020] The following detailed description discloses numerous exemplary embodiments. The scope of this patent application is not limited to the disclosed embodiments, but also includes combinations of the disclosed embodiments and modifications thereof. It should be noted that any section / subsection headings provided herein are not intended to be limiting. Embodiments are described throughout this document, and any type of embodiment may be included under any section / subsection. Furthermore, embodiments disclosed in any section / subsection may be combined in any manner with any other embodiments described in the same section / subsection and / or different sections / subsections.

[0021] II. Exemplary Embodiments

[0022] "Cloud computing" refers to the on-demand availability of computer system resources (e.g., applications, services, processors, storage devices, file systems, and databases) via the Internet and the data stored in cloud storage. Servers hosting cloud-based resources can be referred to as "cloud-based servers" (or "cloud servers"). "Cloud computing services" refer to management services (implemented in hardware running in software and / or firmware) that manage the set of cloud computing computer system resources. Cloud computing platforms can be used to securely store or manage resources. These resources can be protected using different security policies (e.g., encryption). The system can determine whether user access to resources should be granted based on the security policies employed.

[0023] In some scenarios, the authorizing party or other entities may wish to protect access to resources based on the region to which they are allocated. For example, a government authorizing party may wish to restrict access to its residents' data based on privacy laws and regulations. For instance, suppose a government authorizing party wants to restrict access to privacy data only to residents of a government region (e.g., city, county, province, state, country, or a group thereof). In this context, the cloud computing platform operates as a "sovereign cloud," configured to provide data access in accordance with local laws and regulations. The sovereign cloud service provider protects each subscriber's data (including metadata) from access by entities unrelated to the government's region and stores the data in accordance with the government authorizing party's privacy mandate. If the sovereign cloud service provider fails a sovereign assessment, it may face penalties or damage reimbursement costs due to fraudulent access.

[0024] In some implementations of sovereign clouds, the sovereign cloud service provider establishes data centers within a region and stores data protected by the security policies of the region's authorized government in those data centers. However, operating data centers in each region served by the sovereign cloud service provider can be expensive (e.g., economically and in terms of required computing resources) due to factors such as, but not limited to, the increased economic costs of building and maintaining data centers, the number of computing resources required to operate the data centers, the services and resources supporting the maintenance and / or otherwise servicing of the data centers, and / or other factors that increase the cost of operating the data centers. Furthermore, some regions may be cheaper or require fewer resources to operate data centers than others. For example, a sovereign cloud service provider that has already established a data center in a first region may wish to use that data center to provide sovereign cloud services to customers / users in multiple regions. As another example, operating a data center in a first region may be cheaper than operating a data center in a second region. As yet another example, a sovereign cloud service provider serving many customers in a first region and a relatively small number of target customers in a second region may wish to use the same data center to store data for customers in both regions.

[0025] Furthermore, some regions pose physical risks to the physical hardware of cloud service providers' facilities and storage entities' data / resources. For example, suppose a region is prone to natural disasters (e.g., earthquakes, tornadoes, tsunamis, etc.). In such cases, a sovereign cloud service provider may have to operate multiple data centers in separate locations within the same region to mitigate the impact should such data centers be disabled or destroyed by such a disaster. In some cases, the region may be too small to operate multiple data centers in a way that effectively mitigates the potential impact of natural disasters (e.g., a tsunami or earthquake affecting part of the region is likely to affect the entire region).

[0026] Therefore, sovereign cloud service providers may wish to store data protected by the region-based security policies of the first region in data centers that are physically located in a second (i.e., different) region.

[0027] A potential security vulnerability exists when an unauthorized entity (e.g., a malicious entity (e.g., a hacker) or an external entity (e.g., a government-authorized party in a second region) compromises the physical location of a data center or otherwise gains access to physical storage devices (e.g., servers, hard drives, computing devices, etc.) storing policy-protected resources in a data center physically located in a second region, where resources protected by a region-based security policy in a first region are stored. Another potential security vulnerability exists if trusted components (e.g., hardware components, applications, and / or combinations of hardware and software components) enforcing policies for accessing protected resources are compromised. Yet another potential security vulnerability exists if trusted components maintaining user access information are compromised. In any case, if an unauthorized entity manages to infiltrate the data center or other trusted components, the unauthorized entity can gain access to resources protected by a region-based security policy.

[0028] The embodiments described herein implement a region-based security policy for cloud resources. For example, a resource request to access an encrypted resource (e.g., private data of a resident of a first region, "Region A") is received from an entity (e.g., a resident of Region A, "Entity A"). It is determined that the encrypted resource is allocated to a first region (e.g., Region A) and protected by a region-based security policy (e.g., established by a government authority of Region A, "Government A"). A certificate of a region attribute is received from the entity, indicating that the entity possesses the region attribute (e.g., a certificate indicating that Entity A is associated with Region A (e.g., as a resident of Region A)). Examples of region attributes include, but are not limited to, attributes indicating that an entity is located in a first region, attributes indicating that an entity is a resident of the first region, attributes indicating that an entity is a household in the first region, attributes indicating that an entity is an organization associated with the first region (e.g., an organization headquartered in the first region, an organization that provides goods and / or services to the first region, and / or an organization that otherwise establishes a business in the first region), attributes indicating that an entity is a service assigned to the first region (e.g., a service operating on behalf of another entity associated with the first region, a service maintaining authorized data on behalf of the first region, etc.), attributes indicating that an entity is a government entity in the first region (e.g., Government A, an employee of Government A, another government of Region A (e.g., a subset of governments of Region A), etc.), and / or any other attributes indicating appropriate region-related characteristics of the entity required for a region-based security policy, as understood by one of ordinary skill in the art benefiting from this disclosure and / or as described elsewhere herein. An encrypted attribute, which is an encrypted version of the region attribute, is obtained from a ledger database. Resource requests are authenticated based at least on proof of the encrypted attribute and the region attribute. Verification is performed to determine whether the access criteria for the region-based security policy are met. Provide an entity (e.g., entity A) with access to encrypted resources (e.g., entity A's private data).

[0029] The techniques described herein provide cryptographic implementation of region-based security policies for cloud resources associated with entities. An entity is any type of user (e.g., individual user, employee user, agent user, customer user, family member user, etc.), user group, organization (e.g., enterprise, nonprofit company, nonprofit body, government body, government agency, and government authorizer, etc.), and / or service (e.g., cloud service, enclave service, service provider, etc.) that stores, requests access to, accesses resources of the cloud platform, and / or otherwise interacts with resources of the cloud platform. An authorizer is any type of individual user, user group, and / or organization that determines whether an entity should be associated with a region associated with the authorizer and / or determines and / or implements region-based security policies. Examples of authorizers include authorizer organizations (e.g., regional government bodies, regional government agencies, regional government authorizers, regional enterprises (or their departments), regional nonprofit bodies, etc.), individual authorizer users (e.g., individual authorizers, agents of authorizer organizations, etc.), and authorizer user groups.

[0030] The techniques described in this paper provide end-to-end cryptographic implementation across various types of data, services, and organizations within a zero-trust model (and other models). Specifically, one or more components (e.g., components(s) that perform request authentication, policy verification, and / or provide resource access) may not be considered “trusted.” Such untrusted components are not entrusted with storing sensitive data, such as decryption keys used to decrypt encrypted resources, due to the risk of sensitive data being compromised on them. Instead, such components(s) simply maintain the information necessary to release such keys. Therefore, the authorizing party does not need to rely on the sovereign cloud service provider to decrypt resources protected by a region-based security policy. In this context, even if an unauthorized entity compromises the services of the sovereign cloud service provider, that unauthorized entity cannot access the decrypted version of the resource protected by the region-based security policy.

[0031] Therefore, the techniques described herein advantageously provide improvements over other techniques (i.e., data encryption, security, and privacy). For example, by utilizing a zero-trust model, access to sensitive resources (e.g., personal or private information) and / or the decryption keys used to decrypt such resources is prevented. Thus, the techniques described herein also block access to a user's network and computing resources (e.g., computing devices, virtual machines, etc.). By mitigating access to such computing resources, unnecessary expenditures on associated central processing units (CPUs), storage devices, memory, power, etc., are also reduced. Therefore, the embodiments described herein also improve the functionality of computing devices that utilize / maintain such computing resources, as these resources are preserved to prevent unauthorized entities from using them.

[0032] Furthermore, unauthorized access to personal and / or confidential information is prevented by associating encryption attributes with the identity of the corresponding entity. Therefore, the techniques described herein prevent unauthorized entities from accessing personal and / or confidential information protected by security policies that utilize encryption attributes but do not possess those attributes. For example, a region-based security policy according to an embodiment requires proof that an entity possesses attributes that meet the access criteria of the region-based security policy before authorized access to resources protected by the security policy. A verifier authenticates this proof, and if the authenticator verifies that the access criteria of the region-based security policy are met, access to the resources protected by the region-based security policy is granted to the entity if the proof is valid and verified. Therefore, the techniques described herein also prevent access to user-accessible network and computing resources (e.g., computing devices, virtual machines, etc.) with corresponding decryption keys and / or data protected by the region-based security policy. By mitigating access to such computing resources, unnecessary expenditures on central processing units (CPUs), storage devices, memory, power, etc., associated with such resources are also mitigated. Therefore, the embodiments described herein also improve the functionality of computing entities that utilize / maintain such computing resources, as these computing resources are preserved to prevent unauthorized entities from utilizing them.

[0033] Furthermore, the parameters by which a sovereign cloud service provider implements a sovereign cloud can vary depending on the policies of the licensor in a particular region. For example, a licensor in a first region may require strict protection of the private data of its residents and households, while a licensor in a second region may allow businesses and individual users to determine how their private data is protected in transit and at rest. As discussed elsewhere herein, in some embodiments, security policies (including region-based security policies) are associated with identifier resources stored by the cloud service provider's systems (e.g., mapped to policy maps) in a way that allows licensors, entities, and users to apply various security policies to resources.

[0034] Figure 1 A block diagram of an example system 100 for providing access to resources protected by a region-based security policy, according to an example embodiment, is shown. Figure 1As shown, system 100 includes one or more physical computing devices 102A (“Physical Computing Device 102A” herein), one or more physical computing devices 102B (“Physical Computing Device 102B” herein), and one or more physical computing devices 102N (“Physical Computing Device 102N” herein) (collectively referred to herein as “Physical Computing Devices 102A to 102N”). System 100 also includes authorization systems 104A to 104N, authentication system 106, one or more database hosts 108 (“DB Host 108” herein), policy manager 110, data source 112, and one or more additional physical computing devices 132 (“Physical Computing Device 132” herein). Physical computing devices 102A to 102N and physical computing device 132 include any type of processing device, including but not limited to desktop computers, servers, mobile or handheld devices (e.g., tablet computers, personal data assistants (PDAs), smartphones, laptops, etc.), Internet of Things (IoT) devices, etc. Authorization systems 104A to 104N are any type of computing system, including but not limited to one or more computing devices, enterprise computing systems, network computing systems, etc. In embodiments, verification system 106 includes one or more server computers or computing devices, which include one or more distributed or "cloud-based" servers. In embodiments, verification system 106 is associated with or is part of a cloud-based service platform, and in some embodiments, in addition to or in place of cloud-based servers, verification system 106 also includes (or multiple) local servers. According to an embodiment, verification system 106 is a trusted verification system. According to another embodiment, verification system 106 is an untrusted verification system. In embodiments, DB host 108 includes one or more server computers or computing devices, which include one or more distributed or "cloud-based" servers. In embodiments, DB host 108 is associated with or is part of a cloud-based service platform, and in some embodiments, in addition to or in place of cloud-based servers, DB host 108 includes one or more local servers. DB host 108 is configured to host and run any type of database server application, such as, but not limited to, Microsoft Azure SQL Database from Redmond, Washington. TMIn this embodiment, physical computing devices 102A to 102N, authorization systems 104A to 104N, authentication system 106, DB host 108, policy manager 110, data source 112, and / or physical computing device 132 are communicatively coupled via one or more networks 114 (“network 114” herein). Network 114 includes one or more of local area networks (LANs), wide area networks (WANs), enterprise networks, the Internet, etc., and includes one or more of wired and / or wireless portions.

[0035] like Figure 1 As shown, DB host 108 executes one or more ledger databases 124 (referred to herein as "ledger database 124"). Each ledger database in ledger database 124 provides tamper-proof evidence capabilities for the database tables (referred to as ledger tables) of the corresponding ledger database, where it can be cryptographically proven to parties such as auditors or others that data maintained by the database has not been tampered with. Ledger database 124 protects data from any attacker or highly privileged user, including database administrators, system administrators, and cloud administrators. As with traditional ledgers, historical data is retained. If a row in a ledger table is updated, its previous value is maintained and protected in the historical table. Each ledger database in ledger database 124 provides a timeline of all changes made to the corresponding database over time. According to an embodiment, historical data is maintained in relational form to support queries (e.g., SQL queries) for auditing, forensics, and other purposes.

[0036] For each of the 124 ledger databases, a data structure such as a Merkle tree is used to cryptographically hash (e.g., SHA-256 hash) any row in the corresponding database modified by a transaction in the ledger table. This data structure creates a root hash representing all rows in the transaction. The transactions processed by each ledger database are then also hashed together using another Merkle tree data structure. The result is the root hash of the block. The block is then hashed using the root hash of the block, along with the root hash of the previous block as input to a hash function. This hash forms the blockchain. The root hash, also referred to herein as a database digest, contains the cryptographically hashed transaction and represents the state of the database at the time the digest is generated. According to an embodiment, individual digests are periodically generated and stored in a tamper-proof storage device outside the corresponding database. The digests are later used to verify the integrity of the corresponding database by comparing the hash value in the corresponding digest with the calculated hash in the corresponding database.

[0037] According to an embodiment, the materialized view of the ledger table is generated at fixed periodic intervals called epochs. According to an embodiment, each ledger database in ledger database 124 is also configured to provide forward integrity, which guarantees that given a materialized view of the ledger table at any time t, it is not permissible to tamper with the ledger table in any subsequent period.

[0038] Each ledger database in ledger database 124 is configured to store and protect any type of data or information, including but not limited to verifiable identity mappings, verifiable attribute mappings, and / or verifiable policy mappings. For additional details regarding verifiable identity mappings, verifiable attribute mappings, and verifiable policy mappings, please refer to [link to relevant documentation]. Figures 2 to 5A And discussed elsewhere in this document. Each ledger database in ledger database 124 is configured to provide users (e.g., users of physical computing devices 102A to 102N, authorization systems 104A to 104N, and / or physical computing devices 132) with access to a corresponding summary representing the state of the respective ledger database. The computing devices and / or systems may store summaries, as described below regarding Figure 2 and Figure 3A Further description. It should be noted that, in this embodiment, the ledger database 124 is configured to provide access to some or all of the summaries of the corresponding summaries generated by the respective ledger database over time.

[0039] Each of the physical computing devices 102A to 102N may include any number of computing devices (e.g., one computing device, more than one computing device, dozens of computing devices, hundreds of computing devices, or even more). For example, as Figure 1 As shown, physical computing devices 102A to 102N include physical computing devices 134A to 134N. Each computing device in physical computing devices 102A to 102N is associated with a user (e.g., a user entity or a user operating on behalf of another entity) and includes a corresponding application and corresponding attribute information. For example, as Figure 1As shown, entity computing device 134A includes entity application 116A (“Application 116A” herein) and entity attribute information 118A. Application 116A is any software application used to access resources (e.g., resources maintained by data source 112), encrypt resources (e.g., generate encrypted resource 126), generate proofs of attributes (e.g., entity attribute information 118A), access ledger databases (e.g., ledger database 124), interface with associated authorization systems (e.g., authorization system 104A), interface with verification system 106, and / or otherwise interact with other computing devices, services, and / or components of system 100. Examples of application 116A include, but are not limited to, messaging applications (e.g., Microsoft Teams published by Microsoft Corporation of Redmond, Washington). TM ), word processing applications (such as Microsoft Word, released by Microsoft Corporation) TM ), database applications, etc. Each of the physical computing devices 102A to 102N may include similar... Figure 1 The corresponding application of 116A is not shown in the figure.

[0040] As described above, application 116A is configured to access resources on behalf of a user (e.g., physical computing device 134A). For example, application 116A accesses encrypted resource 126 maintained by data source 112. Data source 112 also includes a policy ID specified for the resource maintained thereby. According to embodiments, the policy ID is stored as metadata associated with the resource. Examples of data source 112 include, but are not limited to, data storage, file repositories, databases, etc. Examples of resources maintained by data source 112 include, but are not limited to, data files (e.g., documents), database objects (e.g., tables, directories, etc.), structured data, unstructured data, semi-structured data, data containers, decryption keys, etc. Resources may be encrypted (e.g., encoded according to encryption techniques such as, but not limited to, Advanced Encryption Standard (AES)). In this case, application 116A needs to decrypt the data, for example, using a decryption key (e.g., decoding according to decryption techniques such as, but not limited to, AES) in order to access it. If the policy associated with the resource (e.g., a region-based security policy, an attribute-based access policy, and / or another type of access and / or security policy) is satisfied, the data is decrypted.

[0041] As described above, entity computing device 134A includes entity attribute information 118A. Entity attribute information 118A includes information proving that an entity (e.g., “entity A”) associated with entity computing device 134A possesses one or more attributes. For example, in a non-limiting example, entity A is a user of entity computing device 134A. In this example, entity attribute information 118A includes the user's residency, place of residence, employment status, security clearance, administrative status, work location, and / or any other characteristics that can be attributed to the user by authorization as described herein. According to an embodiment, application 116A provides (e.g., all or part) entity attribute information 118A to prove that the entity possesses the attribute. Alternatively, application 116A generates an attribute certificate (e.g., a password) indicating that the entity possesses the attribute. Additionally, details regarding the generation of attribute certificates can be found by referring to... Figure 2 , Figure 3A and Figures 4 to 5B And other parts of this article.

[0042] Each of the licensing systems 104A to 104N corresponds to a specific license. For example, such as Figure 1 As shown, authorization system 104A corresponds to "Authorizer A", authorization system 104B corresponds to "Authorizer B", and authorization system 104N corresponds to "Authorizer N". Authorization utilizes the corresponding authorization systems 104A to 104N to maintain, generate, and / or manage the corresponding ledger database of ledger database 124, and to generate, implement, enforce, and / or manage security policies (e.g., region-based security policies, attribute-based security policies, location-based security policies, identity-based security policies, etc.).

[0043] Each of the licensing systems 104A to 104N may include one or more computing devices that execute applications and / or store data. For example, such as Figure 1 As shown, the licensing system 104A includes a licensed application 120A (e.g., executing on the computing device of the licensing system 104A). Figure 1 (not shown in the image) and authorization attribute information 122A (e.g., stored in a storage device of the authorization system 104A or an external storage device accessible by the authorization system 104A). Figure 1(Not shown in the text). Authorized application 120A (“Application 120A” herein) is any software application used to access resources (e.g., resources maintained by data source 112); encrypt resources (e.g., generate encrypted resource 126); store resources; generate proofs of attributes (e.g., attribute information 122A); maintain, generate, and / or manage ledger databases (e.g., ledger database 124); generate, implement, enforce, and / or manage security policies; interface with associated physical computing devices (e.g., physical computing device 102A), interface with authentication system 106, and / or otherwise interact with other computing devices, services, and / or components of system 100. Examples of Application 120A include, but are not limited to, messaging applications (e.g., Microsoft Teams published by Microsoft Corporation of Redmond, Washington). TM ), word processing applications (such as Microsoft Word, released by Microsoft Corporation) TM ), database applications, etc. Each of the licensing systems 104B to 104N may include similar... Figure 1 The corresponding applications of 120A are not shown in the figure.

[0044] Authorization attribute information 122A includes information proving that an authorization associated with authorization system 104A (e.g., "Authorizer A") possesses one or more attributes. For example, in a non-limiting example, Authorizer A is a user acting on behalf of the government of region A, and authorization attribute information 122A includes attributes belonging to Authorizer A that indicate that Authorizer A is authorized to set up policies on behalf of the government of region A. According to an embodiment, application 120A provides (e.g., all or part) authorization attribute information 122A to prove that the Authorizer possesses the attribute. Alternatively, application 120A generates an attribute certificate (e.g., a password) indicating that the Authorizer possesses the attribute. Additional details regarding the generation of the attribute certificate can be found in [reference needed]. Figure 2 , Figure 3A and Figures 4 to 5B And other parts of this article.

[0045] Policy Manager 110 maintains security policies for resources maintained by Data Source 112. Examples of security policies maintained by Policy Manager 110 include, but are not limited to, zone-based security policies, attribute-based security policies, location-based security policies, and / or any other security policies used to determine whether an entity is authorized to access resources maintained by Data Source 112. For example, such as... Figure 1As shown, policy manager 110 includes a region-based security policy 128 (referred to herein as "security policy 128") for authorizing party A. According to an embodiment, the security policy maintained by policy manager 110 is stored in the corresponding policy map in ledger database 124. In this context, policy manager 110 maintains the security policy on behalf of the authorizing party associated with the corresponding policy. Further details regarding the maintenance of security policies can be found in [reference needed]. Figures 2 to 5A And other parts of this article.

[0046] According to an embodiment, the entity associated with physical computing device 134A (or another physical computing device of physical computing device 102A) is associated with a licensor (e.g., a member of the licensor, an employee of the licensor, a volunteer of the licensor, an owner of the licensor, a subscriber of the licensor's services, a department of the licensor, a branch of the licensor, a partner organization of the licensor, etc.). For example, in a non-limiting example, the user associated with physical computing device 134A is an employee of licensor A. In this context, computing device 134A can be a computing device within an authorized licensing system (e.g., licensing system 104A) or another computing device (e.g., a personal computing device) associated with the user.

[0047] Verification system 106 determines that for entities associated with one or more of the physical computing devices 102A to 102N and / or 132, the entity is stored in data source 112 and / or accessed by application 116A (or other similar application) of one of the licensors associated with licensors 104A to 104N (or applications and / or members associated with those permissions). Figure 1 (Not shown) Whether the policy for attempting to access data is satisfied. For example, according to an embodiment, verification system 106 facilitates the determination of whether a certificate provided by an entity (e.g., an entity associated with any entity computing device 102A to entity computing device 102N and / or entity computing device 132) indicates that the entity possesses a specific region attribute. Upon determining that the certificate is valid, verification system 106 (or another component acting on behalf of verification system 106) stores encrypted resources in data source 112 (e.g., as encrypted resource 126). Alternatively, an authorization (or a user or service acting on behalf of authorization) (e.g., authorization systems 104A to 104N) collects and / or generates resources associated with the entity and stores the resources in data source 112. Additional details regarding the storage of data protected by security policies are available for reference. Figures 2 to 3B And as described elsewhere in this article.

[0048] According to another embodiment, verification system 106 facilitates the determination of whether an authorizing party is authorized to update a security policy (e.g., security policy 128). For example, verification system 106 according to an embodiment receives proof of authorization attributes indicating that the authorization possesses specific authorization attributes, provided by an authorization system (e.g., authorization systems 104A to 104N) or on behalf of an authorization system (e.g., a user or service associated with authorization systems 104A to 104N). Upon determining that the proof of the authorization attributes is valid, verification system 106 updates the security policy (e.g., security policy 128) managed by the authorization system. According to another embodiment, upon determining that the proof is valid, verification system 106 updates the ledger database managed by the authorization system (e.g., the ledger database of ledger database 124). Additional details regarding the updates to the security policy and the ledger database can be found in [reference needed]. Figure 3A And as described elsewhere in this article.

[0049] According to another embodiment, verification system 106 determines whether an entity (e.g., an entity associated with any entity computing devices 102A to 102N and / or 132) possesses the necessary attributes specified by a region-based security policy, and grants the entity access to resources protected by the policy. When the access criteria of the policy are met, verification system 106 acquires (or recovers) a decryption key and / or provides the decryption key to the entity. Alternatively, verification system 106 (or another component coupled thereto) uses the decryption key to decrypt the resource and provides the decrypted resource to the requesting entity. Additional details regarding determining whether an entity possesses the region attributes (and optionally, multiple other attributes) specified by a region-based security policy (and / or other policies) and granting the entity access to resources protected by the policy can be found in [reference]. Figures 4 to 8 And as described elsewhere in this article.

[0050] According to the embodiments, and as Figure 1As shown, authorization systems, computing devices, data sources, and cryptographic resources are associated with a region. Depending on the implementation, authorization systems, computing devices, data sources, and / or cryptographic resources may be physically located in a region (e.g., stored in a region, operated in a region, originating from a region, etc.) and / or allocated to a region. In this context, authorization systems, computing devices, data sources, and / or cryptographic resources allocated to a region may be owned by entities associated with the region (e.g., entities located in the region, entities that are residents of the region, entities that are resident of the region, entities that are another entity in the region or authorized employees of the region, entities that build a business in the region (e.g., organizations headquartered in the region, organizations that have offices in the region, organizations that provide goods and / or services to the region), entities that are services allocated to the region, etc.), leased by entities associated with the region, and / or otherwise allocated to the region without necessarily being physically located in the region. For example, as a non-limiting example, suppose that licensing system 104A and physical computing device 102A are assigned to a first region 130A (“Region A”), licensing system 104B and physical computing device 102B are assigned to a second region 130B (“Region B”), and licensing system 104N and physical computing device 102N are assigned to an Nth region 130N (“Region N”). Any corresponding licensing system and / or physical computing device may be located in its respective assigned region (e.g., a fixed computing device, fixed system, mobile system, or computing device within that region) or in a different region (e.g., a remotely located fixed system or computing device, a mobile computing device (e.g., a mobile device or laptop computer of an entity traveling in another region), etc.). Furthermore, in this example, suppose that data source 112 is physically located in region A. The embodiments described herein enable resources allocated to any region (e.g., region A, region B, region N, etc.) to be securely stored in data source 112 according to the security policies of the corresponding authorizations (e.g., authorization systems 104A, 104B, 104N) for the respective allocated region. Additional non-limiting examples of storing resources protected by region-based security policies are available for reference. Figures 7 to 8 And as described elsewhere in this article.

[0051] III. Example Implementations for Setting Policies and Securely Storing Resources

[0052] In embodiments, the systems, computing devices, and computer storage media described herein can be configured with region-based security policies to protect resources, and the resources protected by the policies can be stored in various ways. For example, continuing to refer to... Figure 1Assume that the authorization system 104A (Authorizer A) implements security policy 128 to protect the data of residents in the first area 130A (Area A). Furthermore, assume that Authorizer A collects data from residents of Area A. In this context, Authorizer A stores the collected data by encrypting the data with an encryption key and storing the encrypted data as an encryption resource 126 in data source 112. In this context, Authorizer A stores the decryption key in a key manager (…). Figure 1 (Not shown in the image). The decryption key is encrypted using a policy key associated with security policy 128, so that when entities prove they possess the appropriate attributes to satisfy security policy 128, the decryption key can be decrypted and used (e.g., by the entity, by the authentication system, by the resource processor, etc.) to access the encrypted resource 126. In an alternative implementation, an entity (e.g., an entity associated with any entity computing devices 102A to 102N and / or 132) stores the entity's resource in a manner that protects the resource as encrypted resource 126 under security policy 128.

[0053] As described above, the licensor can set security policies to protect resources associated with entities in regions associated with the licensor, and can store resources according to the security policies (e.g., by the licensor and / or the entity). The system can be configured in various ways to enable the licensor to set policies and / or enable the storage of resources according to policies. For example, Figure 2 A block diagram of a system 200 for storing resources protected by a region-based security policy, according to an example embodiment, is shown. System 200 includes an authorization system 104A, an authentication system 106, a policy manager 110, a data source 112, and a physical computing device 134A, as described above. Figure 1 The system 100 describes a ledger database 224, which is... Figure 1 A further embodiment of the ledger database 124 includes a resource processor 230 (which processes access to resources and / or keys according to a security policy) and a key manager 284 (which stores one or more decryption keys (e.g., decryption key 286)). According to an embodiment, each of the resource processor 230 and key manager 284 includes one or more server computers or computing devices, which may include one or more distributed or "cloud-based" servers. In an embodiment, in addition to or instead of cloud-based servers, the resource processor 230 and / or key manager 284 include one or more local servers. According to an embodiment, the resource processor 230 is a trusted resource processor. According to another embodiment, the resource processor 230 is an untrusted resource processor. According to an embodiment, the key manager 284 is a trusted key manager. According to another embodiment, the key manager 284 is an untrusted key manager. Figure 2 As shown, the ledger database 224 includes identity mapping 236, attribute mapping 238, and policy mapping 240. Also as... Figure 2 As shown, the authorization system 104A includes an authorized application 120A and authorization attribute information 122A, such as regarding... Figure 1 As described, and the authorization key pair 246A. The authorization application 120A executes the proof generator 242 and the attribute assigner 244. The authorization key pair 246A includes the authorization's public key (known to others) and the authorization's private key (known only to the authorizing party) associated with the authorization system 104A (e.g., authorizing party A). Also as... Figure 2 As shown, the physical computing device 134A includes, as per the description... Figure 1 The described application 116A and entity attribute information 118A, as well as entity key pair 288A. Application 116A executes proof generator 248. Entity key pair 288A includes the public key (which is known to others) of the entity (e.g., entity A) associated with entity computing device 134A and the entity's private key (which is known only to the entity).

[0054] like Figure 2 As further shown, the verification system 106 includes a policy verifier 232, a proof authenticator 234, and a proof requester 290. According to one or more embodiments, a resource processor 230 and / or a key manager 284 are included as part of the verification system 106. Figure 2 As shown, policy validator 232, proof authenticator 234, and proof requester 290 are incorporated into verification system 106. According to another embodiment, policy validator 232, proof authenticator 234, and / or proof requester 290 are components separate from verification system 106 (e.g., software applications). According to an embodiment, policy validator 232, proof authenticator 234, and / or proof requester 290 are integrated (e.g., as a single software application). According to an embodiment, policy validator 232 is a trusted validator. According to another embodiment, policy validator 232 is an untrusted validator. According to an embodiment, proof authenticator 234 is a trusted authenticator. According to another embodiment, proof authenticator 234 is an untrusted authenticator. According to an embodiment, system 200 includes an orchestrator ( Figure 2 (Not shown in the original text), which facilitates communication between entities, authorization systems, authentication systems 106, resource processors 230, data sources 112, policy managers 110, and / or key managers 284. According to an embodiment, authentication system 106 is a secure enclave. According to an embodiment, authentication system 106 is a secure server (e.g., a hardened or locked server) that (e.g., only) loads applications approved by the licensor of the region (e.g., authentication and / or decryption applications).

[0055] According to an embodiment, the verification system 106 is a Location Attribute Policy (LAP) server (e.g., a trusted LAP server trusted by the authorizing party A, an untrusted LAP server, etc.). In this context, the verification system 106 determines whether a user possesses the necessary attributes (e.g., region attributes) specified by a policy (e.g., security policy 128). Furthermore, the LAP server can determine whether an entity possesses static and / or dynamic attributes specified by the policy. In this context, static attributes are attributes assigned to an entity (e.g., by the authorizing party) and not changed until an attribute change event occurs (e.g., the authorizing party modifies the attribute and / or deassociates the attribute from the entity). On the other hand, dynamic attributes include characteristics that change more frequently than static attributes, are not assigned to a specific entity (e.g., are not stored in a ledger as described herein), can be modified without direct entity intervention (e.g., such as by the entity typing on a keyboard instead of "manually"), and / or can be modified alternatively by monitoring devices (e.g., changes in the physical location of an entity tracked by a Global Positioning System (GPS) device). In some examples, dynamic attributes are characteristics that are not associated with the requesting entity, such as the requirement that a resource not be accessed more than a predetermined number of times within a given period of time (e.g., any entity can only access a resource once a week).

[0056] As mentioned above, Figure 2 The ledger database 224 includes identity mappings 236, attribute mappings 238, and policy mappings 240. Identity mappings 236, attribute mappings 238, and policy mappings 240 can be generated and / or maintained by the appropriate authorizing party (e.g., authorizing party A associated with authorizing system 104A) according to any techniques described elsewhere herein or otherwise known for generating and / or maintaining mappings within the ledger database. Although Figure 2 A ledger database 224 is depicted according to an alternative embodiment, storing identity mappings 236, attribute mappings 238, and policy mappings 240; however, separate ledger databases are used to store the respective identity mappings, attribute mappings, and / or policy mappings. Examples of databases that maintain identity mappings 236, attribute mappings 238, and / or policy mappings 240 include, but are not limited to, those from Redmond, Washington. The company's Azure SQL database TM .

[0057] Identity mapping 236 is configured to store each identity among multiple entities (e.g., residents, households, members, employees, organizations, authorized agents, etc.) associated with authorization. Each identity includes information that uniquely identifies the entity associated with authorization. Examples of identities include, but are not limited to, an entity's email address, an entity's phone number, an entity's username, or any other type of information that uniquely identifies the entity. Identity mapping 236 is also configured to store, for each entity, the public key of the entity associated with the entity's identity.

[0058] Attribute map 238 is configured to store one or more attributes for each of a plurality of entities associated with an authorizing party. Each attribute of a particular entity is stored in association with the identity of that entity. For example, attribute map 238 is configured to store one or more cryptographic secrets for each entity (e.g., one or more data encoded according to cryptographic techniques such as, but not limited to, techniques based on a secure hash algorithm (SHA), such as passwords, private keys, public keys, strings, and / or random numbers). Each entity-specific secret of a particular entity is stored in association with the identity of that entity. For example, according to an embodiment, the secret of a particular entity is associated with a reference to the identity of the particular entity. Examples of references to an identity include, but are not limited to, an identity, a copy of an identity maintained outside attribute map 238 (e.g., in identity map 236), and / or a link to an identity maintained outside attribute map 238. Attribute map 238 also associates each cryptographic secret with a corresponding attribute in the attributes stored in attribute map 238. As described elsewhere herein, the cryptographic secrets are used to verify whether an entity is actually associated with the corresponding attribute (e.g., to verify whether an entity possesses the corresponding attribute). According to an embodiment, the secret(s) of an entity stored in attribute map 238 are encrypted using the entity's public key. According to an embodiment, attribute map 238 is also configured to store a public key for each attribute, as described with reference to proof generator 242, proof generator 248, and proof authenticator 234, which is used to generate and verify cryptographic proofs. In this context, attribute map 238 associates each public key with a corresponding attribute and a corresponding share of encrypted secret stored in attribute map 238.

[0059] Policy map 240 is configured to store one or more policies (hereinafter referred to as "policies") for resources maintained by data source 112. For example, policy map 240 stores policy information related to security policy 128 managed by policy manager 110. Each policy specifies one or more conditions that an entity is required to perform a specific action regarding the corresponding resource. Such actions include, but are not limited to, accessing a resource (e.g., reading a resource, acquiring a resource, or modifying a resource), sending a resource to another entity, sending communication associated with a resource to another entity, storing a resource, etc. Conditions include, but are not limited to, a specific region associated with an entity (and / or its associated computing device), a specific region in which the entity (and / or its associated computing device) is required to be located, a specific secret required to perform the action, a specific identity of a specific entity authorized to perform the action, a specific attribute that requires an identity (or entity) to perform the action, a location in which the entity (and / or its associated computing device) is required to perform the action, etc. Examples of regions include, but are not limited to, a specific city, a specific county, a specific state, a specific province, a specific country, one or more specific groups of cities, counties, states, provinces, and / or countries, and / or any other region that the entity will be associated with. Examples of locations include, but are not limited to, a specific room or building, a specific vehicle or vessel (e.g., a specific car, a specific submarine, a specific aircraft carrier, etc.), a specific area, etc. Policy mapping 240 associates each policy with a policy ID, which uniquely identifies the corresponding policy (e.g., security policy 128). According to an embodiment, policy mapping 240 also associates each policy ID with an authorization ID, which uniquely identifies the authorizing party authorized to modify and / or otherwise manage the corresponding policy (e.g., authorizing party A of authorization system 104A). According to an embodiment, policy mapping 240 associates each policy ID with one or more attributes (or corresponding secrets) required to satisfy the policy. For example, according to an embodiment, security policy 128 requires an entity to possess an attribute indicating that the entity is associated with area A, and policy mapping 240 associates the policy ID of security policy 128 with a secret corresponding to that attribute.

[0060] As described above, the system enables authorized parties to set zone-based security policies for protecting resources. For example, the system allows authorized parties (or users and / or services acting on their behalf) to update the ledger database relative to a zone-based security policy. Figure 3A A flowchart 300 is shown, illustrating a process for updating mappings maintained by a ledger database according to an example embodiment. System 200 can operate according to flowchart 300 in the embodiments. Not all steps of flowchart 300 need to be performed in all embodiments. Based on Figure 2 and Figure 3AThe following description, further structural and operational embodiments will be clear to those skilled in the art.

[0061] Flowchart 300 begins at step 302. In step 302, an update request is received from a computing device representing the authorizing party to update an identity mapping, attribute mapping, or policy mapping maintained by the ledger database. For example, authenticator 234 receives update request 250 on behalf of authorizing party A from authorization application 120A (e.g., executed on a computing device of authorization system 104A) to update identity mapping 236, attribute mapping 238, and / or policy mapping 240. In this context, identity mapping 236, attribute mapping 238, and policy mapping 240 are mappings of ledger database 224 managed and / or maintained by authorizing party A. According to an embodiment, update request 250 includes proof indicating that authorizing party A is authorized to update the authorization attributes of identity mapping 236, attribute mapping 238, and / or policy mapping 240. According to an embodiment, update request 250 includes a summary corresponding to ledger database 224, representing identity mapping 236, attribute mapping 238, and / or policy mapping 240. In some embodiments, update request 250 includes requests to add information, remove information, change information, and / or otherwise modify information stored in identity map 236, attribute map 238, and / or policy map 240. In some embodiments, update request 250 includes generating or removing identity map 236, attribute map 238, policy map 240, and / or... Figure 2 A request for another mapping not shown. In an embodiment, update request 250 includes information to be added to or changed in the corresponding mapping (e.g., user identity, attribute information, policy information, etc.).

[0062] In a non-restricted operational example, the authorizing party A is the government of region A. In this example, identity mapping 236 maps the identities of residents and households in region A to their corresponding public keys, attribute mapping 238 maps the identities of residents and households in region A to their corresponding attributes, and policy mapping 240 maps the security and access policies set by authorizing party A to the identities of residents and households in region A and the data stored on behalf of residents and households in region A. According to an embodiment, attribute mapping 238 maps the identities of residents and households in region A to corresponding secrets corresponding to their respective attributes. Attribute allocator 244 (on behalf of authorizing party A) assigns the "resident of region A" attribute to resident user entities, the "household of region A" attribute to household user entities, and "authorizing party of region A" to authorizing party entities (and / or user entities operating on behalf of authorizing party). For example, attribute allocator 244 assigns a secret (“Secret A1”) corresponding to the “Resident of Area A” attribute to the first resident of Area A associated with entity computing device 134A (“Entity A”). In this example, authorizing party A (e.g., via authorizing application 120A) sends update request 250 to update identity mapping 236 to include the identifier of entity A, update attribute mapping 238 to map the identifier of entity A to an encrypted version of secret A1, and update policy mapping 240 to map the policy identifier of security policy 128 to the identifier of entity A. In this example, security policy 128 requires entities requesting access to and / or storage of private data to prove that the requesting entity is a resident of Area A (e.g., proving possession of secret A1), a resident of Area A (e.g., proving possession of a secret (“Secret A2”) corresponding to the “Resident of Area A” attribute), and / or an authorizing party of Area A (e.g., proving possession of a secret (“Secret A3”) corresponding to the “Authorizing Party of Area A” attribute).

[0063] As described above, update request 250 may include proof of an authorization attribute (e.g., authorization attribute information 122A). For example, proof generator 242 is configured to generate a zero-knowledge cryptographic proof based at least on an unencrypted version of the authorization attribute. According to an embodiment, proof generator 248 is configured to generate a zero-knowledge cryptographic proof based at least on an unencrypted version of a secret corresponding to the attribute (e.g., secret A3). According to an embodiment, proof generator 242 is incorporated into authorization application 120A (e.g., ...). Figure 2 (As shown). According to another embodiment, the proof generator 242 is a component separate from the application 120A (e.g., a software application, a hardware-based proof generator, etc.).

[0064] According to the implementation examples, and with reference to the operating examples, Figure 2The proof generator 242 is configured to generate zero-knowledge cryptographic proofs of attributes based at least on secret A3, the authorized public key A, and the cryptographic algorithm used to encrypt the dataset. According to an embodiment, the proof generator 242 generates cryptographic proofs based on a zero-knowledge protocol, such as, but not limited to, the Schnorr protocol. In the example, although the proof generator 242 uses an unencrypted version of secret A3 (which is considered private) to generate a value, the generated value does not include the unencrypted secret. In other words, the generated value of the cryptographic proof cannot be used to reconstruct any unencrypted secret. In this way, the proof generator 242 provides proof that the authorizing party A possesses a given attribute (or a secret corresponding to that attribute), although the attribute or secret is not relayed.

[0065] In various embodiments, a zero-knowledge proof of an authorized attribute (also referred to as an "authorization proof") includes information to prove that the authorizing party (e.g., authorizing party A) possesses a value for the attribute or its corresponding secret (e.g., secret A3), and that if that value is input into an encryption algorithm, an encrypted version of the value of secret A3 will be obtained (e.g., stored in attribute map 238). In various other embodiments, other algorithms, such as a secure hash algorithm (SHA), are used instead of an encryption algorithm. For example, regarding the running example, in this case, the zero-knowledge proof would be used to prove that if the value of secret A3 is input into the SHA, an encrypted version of the value of secret A3 stored in attribute map 238 will be obtained (assuming the value in attribute map 238 is also based on the algorithm). Other techniques are also envisioned herein, and the techniques disclosed for providing zero-knowledge proofs are not limited to these illustrative examples. In some more implementations, zero-knowledge proofs are non-replayable. For example, in some embodiments, the proof authenticator 234 generates a random number for each session (e.g., each new communication session for which the authorization system 104A seeks access to cryptographic resources and / or updates identity mappings, attribute mappings, and / or policy mappings), and provides the randomly generated number to the proof generator 242 as part of the proof generation process. Therefore, even if the same proof is attempted for a subsequent session (either by the same computing device or by a different system in a malicious manner), the proof will not succeed because subsequent sessions will have different randomly generated numbers, which will be used as part of the proof generation process.

[0066] In step 304, the authentication update request is processed. For example, authenticator 234 authenticates update request 250. Authenticator 234 authenticates update request 250 in a manner similar to that used for authentication storage requests and / or resource requests, as described elsewhere herein. For example, authenticator 234 may authenticate update request 250 based on the authorization certificate included in update request 250 and / or the digest included in update request 250 (additional details regarding the digest are available upon request). Figure 6(Description) to authenticate update request 250. Alternatively, verify authenticator 234 request (e.g., by sending a prompt, Figure 2 (Not shown) Authorized application 120A provides an authorization certificate and / or digest for authenticating update request 250. Furthermore, a certificate authenticator 234, according to one or more embodiments, obtains an encrypted version of an attribute (or corresponding secret) from an attribute mapping that maps the identity of the authorizing party to an authorized attribute (or corresponding secret). For example, referring to a non-limiting operational example, update request 250 includes the identity of authorizing party A and a certificate of secret A3 generated by certificate generator 242. In this example, certificate authenticator 234 obtains an encrypted version of secret A3 from attribute mapping 238 based on the identity of authorizing party A included in update request 250. Certificate authenticator 234 determines whether the certificate of secret A3 corresponds to the encrypted version of secret A3. For example, suppose certificate authenticator 234 determines whether the certificate of an attribute corresponds to an encrypted attribute based on at least two or more of the certificate, the encrypted attribute, and the public key corresponding to the encrypted attribute. Alternatively, suppose certificate authenticator 234 authenticates the certificate based on a zero-knowledge protocol, such as, but not limited to, the Schnorr protocol. In one implementation, authentication of the proof is performed by comparing a first value generated by the proof authenticator 234 with a second value of the proof based on secret A3. The first value is determined based on the encrypted version of secret A3 obtained from attribute mapping 238 and the public key corresponding to permission A obtained from identity mapping 236. In response to determining that the proof corresponds to the encrypted attribute, the proof authenticator 234 issues an authentication update request 250, and flowchart 300 continues to step 306.

[0067] According to an embodiment, if the request is not authenticated, the authenticator 234 sends an indication to the authorized application 120A that the update request 250 is invalid. Alternatively, the authenticator 234 sends the indication to another computing device of the authorized system 104A (e.g., the computing device of an administrator user, a computing device of a service team user, a computing device of a security team user, etc.).

[0068] In step 306, the identity mapping, attribute mapping, or policy mapping is updated. For example, the authentication authenticator 234 provides an update signal 252 to the ledger database 224 to update the identity mapping 236, attribute mapping 238, and / or policy mapping 240. The update signal 252 indicates the requested update of the update request 250. According to an embodiment, the update signal 252 includes information that will be added to and / or changed in the corresponding mappings included in the update request 250. Referring again to the non-limiting operational example, the authentication authenticator 234 provides the update signal 252 to the ledger database 224 to cause the ledger database 224 to update the identity mapping 236 to include the identifier of entity A, update the attribute mapping 238 to map the identifier of entity A to the "resident of area A" attribute (e.g., by mapping the identifier of entity A to secret A1), and update the policy mapping 240 to map the policy identifier of security policy 128 to the identifier of entity A.

[0069] According to an embodiment, if the policy mapping stored in the ledger database 224 is changed, the policy manager is notified. For example, such as Figure 2 As shown, ledger database 224 sends notification 254 to policy manager 110. Notification 254 indicates an update to a security policy (e.g., security policy 128) corresponding to policy mapping 240 and managed by policy manager 110. For example, suppose update request 250 includes a request to apply a new security policy (e.g., security policy 128) to resources stored by a cloud service provider representing residents and households of region A. In this context, ledger database 224 updates policy mapping 240 to map the identifier of security policy 128 to residents and households of region A or corresponding secrets (e.g., secret A1 and secret A2); thereby setting security policy 128 to require entities to possess secret A1 and / or secret A2 (or proof thereof) to access policy-protected resources. Ledger database 224 sends notification 254 to policy manager 110, and policy manager 110 updates security policy 128 to indicate the change in security policy.

[0070] According to the embodiments, and as Figure 2 As shown, the authorization system 104 is notified that identity mapping 236, attribute mapping 238, and / or policy mapping 240 have been successfully updated. For example, as Figure 2 As shown, in response to update signal 252, ledger database 224 generates notification 256 indicating that the corresponding mapping has been updated. Authentication authenticator 234 receives notification 256 and provides authorization application 120A with notification 258 indicating that update request 250 has been satisfied.

[0071] In step 308, attribute information is sent to the entity computing device. For example, authorized application 120A sends attribute information 260 to application 116A of entity computing device 134A. Attribute information 260 includes indications of attributes assigned by authorizing party A to the entity corresponding to entity computing device 134A (e.g., "entity A"). For example, referring to the operational example, attribute information 260 includes an indication that secret A1 is assigned to entity A. According to an embodiment, authorized application 120A encrypts attribute information 260 using the public key of the entity corresponding to entity computing device 134A (e.g., entity key pair 288A). According to an embodiment, authorized application 120A obtains the public key from identity mapping 236 using the entity's identifier. By encrypting attribute information 260 in this manner, authorized application 120A is able to securely transmit attribute information 260 to entity computing device 134A (e.g., in a manner that allows a user possessing only the private key of entity key pair 288A to decrypt attribute information 260). According to an embodiment, the authorized application 120A uses the private signature key pair of the authorized key pair 246A to sign the attribute information 260. By signing the attribute information 260 in this way, the application 116A is able to verify that the attribute information 260 was received from the authorizing party A (e.g., using the public signature key of the authorized key pair 246A).

[0072] For example, referring to a non-limiting operational example, authorized application 120A obtains the public key of entity key pair 288A from identity mapping 236, encrypts secret A3 using the public key, and signs the encrypted version of secret A3 using the private signing key of authorized key pair 246A to generate attribute information 260. Authorized application 120A sends attribute information 260 to application 116A. Application 116A obtains the public signing key of authorized key pair 246A from identity mapping 236 and verifies the signature of attribute information 260. According to an embodiment, application 116A stores attribute information 260 in local storage of entity computing device 134A (e.g., as entity attribute information 118A). Alternatively, application 116A stores attribute information 260 in external storage accessible to entity computing device 134A. According to an embodiment, application 116A decrypts the received attribute information 260 (e.g., using the private decryption key of entity key pair 288A).

[0073] As described above, the system enables authorized parties and / or entities to store resources in a manner that protects resources according to a region-based security policy. For example, in some embodiments, an entity (or a user, authorized party, and / or service acting on behalf of the entity) stores the resource in a data source by encrypting the resource with an encryption key of a region-based security policy. In this context, the corresponding decryption key is released to the entity requesting access to the resource when the entity presents attribute proof that satisfies the region-based security policy. Alternatively, the system may verify whether the entity's resource is to be protected by a specific region-based security policy before encrypting and storing the resource. For example, Figure 3B A flowchart 310 is shown, illustrating a process for storing resources protected by a region-based security policy according to an example embodiment. System 200 can operate according to flowchart 300 in the embodiments. Not all steps of flowchart 310 need to be performed in all embodiments. Figure 2 and Figure 3B The following description, further structural and operational embodiments will be clear to those skilled in the art.

[0074] Flowchart 310 begins at step 312. In step 312, a storage request is received from the entity, which includes resources protected by a region-based security policy. For example, Figure 2 The authentication requester 290 receives a storage request 262 from application 116A (e.g., on behalf of entity A). Storage request 262 includes a resource protected by security policy 128 (e.g., to be protected). The resource may be encrypted in a manner that allows a user possessing an appropriate decryption key (e.g., a decryption key corresponding to the encryption key (e.g., decryption key 286)) to decrypt and access the resource. For example, according to one embodiment, the resource is encrypted using a policy encryption key of security policy 128 (e.g., which corresponds to the decryption key of security policy 128 released when the requesting entity meets the access criteria of security policy 128 (e.g., decryption key 286)). According to another embodiment, the resource is encrypted using a data-corresponding encryption key to a data decryption key, which is encrypted in a manner by one or more policy keys (each policy key corresponding to a corresponding security policy) such that the data decryption key can be accessed once (e.g., all) the access criteria of each of the one or more policies are met. Referring to the unrestricted operational example, it is demonstrated that requester 290 receives storage request 262 on behalf of entity A from application 120. In this context, storage request 262 includes resources (e.g., private data) that entity A wants to store and protect under security policy 128 (e.g., a zone-based security policy set by authorizing party A).

[0075] According to an embodiment, and referring to a non-limiting operational example, storage request 262 includes (e.g., an encrypted version) a decryption key (e.g., the decryption key of security policy 128 (e.g., decryption key 286)). Alternatively, the resources included in storage request 262 are encrypted with an encryption key corresponding to the decryption key. According to an embodiment, key manager 284 is a secure key manager, and uses key pairs of key manager 284 ( Figure 2 The decryption key is encrypted using the public key of a security resource processor (e.g., resource processor 230). In this context, an encrypted version of the decryption key can be provided to the authentication system 106 without allowing the authentication system 106 (or its components) (or a malicious entity including the authentication system 106) to access the decryption key and thus decrypt and access the encrypted resource. According to another embodiment, the decryption key is encrypted using the public key of a security resource processor (e.g., resource processor 230). In this context, an encrypted version of the decryption key can be provided to and stored by the cloud service provider without allowing the cloud service provider (or a malicious entity harming the cloud service provider) to access the decryption key and thus decrypt and access the encrypted resource.

[0076] In step 314, the entity is prompted to provide proof of the region attribute, indicating that the entity possesses the region attribute. For example, Figure 2 The proof requester 290 sends a proof request 266 to application 116A to prompt entity A (e.g., via application 116A) to provide proof of region attributes (e.g., authorized storage includes resources in storage request 262). The proof requester 290 may determine how to send the proof request 266. For example, as... Figure 2As shown, the proof requester 290 obtains policy information 264 (e.g., policy information corresponding to security policy 128) from the policy manager 210 and analyzes the policy information 264 to determine the requirements of security policy 128 for accessing resources protected by security policy 128. For example, according to an embodiment, security policy 128 requires entities to prove that they are residents of area A, households of area A, or authorized parties of area A in order to store and / or access private data protected by security policy 128. In this context, the proof requester 290 sends a proof request 266 to prompt the entity to prove that the entity possesses an attribute (or corresponding secret) indicating that the entity is a resident of area A, a household of area A, or an authorized party of area A. For example, in a non-limiting operational example, the proof requester 290 determines that security policy 128 is a area-based security policy for area A that requires entity A to prove that they possess secret A1 (indicating that the entity is assigned the "resident of area A" attribute), secret A2 (indicating that the entity is assigned the "household of area A" attribute), or secret A3 (indicating that the entity is assigned the "authorized party of area A" attribute). Alternatively, security policy 128 requires entity A to prove that they possess secret A4 that indicates the entity's association with region A (e.g., a resident of region A, a household of region A, an authorized party of region A, or associated with region A in a manner that satisfies security policy 128). In either case, proof requester 290 sends proof request 266 to application 116A to prompt entity A to provide corresponding proof of the region's attributes.

[0077] As described above, Proof Request 266 prompts the entity (or an application representing the entity) to provide proof of the zone attribute to authorize the storage of resources protected by a security policy. For example, proof generator 248 is configured to generate zero-knowledge cryptographic proofs based at least on an unencrypted version of the zone attribute. According to an embodiment, proof generator 248 is configured to generate zero-knowledge cryptographic proofs based at least on an unencrypted version of a secret corresponding to the zone attribute (e.g., secret A1). According to an embodiment, proof generator 248 is incorporated into application 116A (e.g., ...). Figure 2 (As shown). According to another embodiment, the proof generator 248 is a component separate from the application 116A (e.g., a software application, a hardware-based proof generator, etc.).

[0078] According to the implementation examples, and with reference to the operating examples, Figure 2The proof generator 248 is configured to generate zero-knowledge cryptographic proofs of attributes based at least on an unencrypted version of secret A1, the public key of entity A, and an encryption algorithm used to encrypt the dataset. According to an embodiment, the proof generator 248 generates cryptographic proofs based on a zero-knowledge protocol, such as, but not limited to, the Schnorr protocol. In the example, although the proof generator 248 uses an unencrypted version of secret A1 (which is considered private) to generate a value, the generated value does not include the unencrypted secret. In other words, the generated value of the cryptographic proof cannot be used to reconstruct any unencrypted secret. In this way, the proof generator 248 provides proof that entity A possesses a given region attribute (or a secret corresponding to that region attribute), although the region attribute or secret is not relayed.

[0079] In various embodiments, zero-knowledge proofs of region attributes (also referred to as "attribute proofs") involve proving that an entity (e.g., entity A) possesses a value for a region attribute or a corresponding secret (e.g., secret A1), and that if that value is input into an encryption algorithm, an encrypted version of the value of secret A1 is obtained (e.g., stored in attribute map 238). In various other embodiments, other algorithms, such as secure hash algorithms (SHA), are used instead of encryption algorithms. For example, regarding the running example, in this case, the zero-knowledge proof would be used to prove that if the value of secret A1 is input into the SHA, an encrypted version of the value of secret A1 stored in attribute map 238 will be obtained (assuming the value in attribute map 238 is also based on the algorithm). Other techniques are also contemplated herein, and the techniques disclosed for providing zero-knowledge proofs are not limited to these illustrative examples. In some more embodiments, zero-knowledge proofs are non-replayable. For example, in some embodiments, the proof authenticator 234 generates a random number for each session (e.g., each new communication session where the entity computing device 134A seeks to store protected cryptographic resources under security policy 128) and provides the randomly generated number to the proof generator 248 as part of the proof generation process. Therefore, even if the same proof is attempted for a subsequent session (either by the same computing device or by a different system in a malicious manner), the proof will not succeed because the subsequent session will have a different randomly generated number, which will be used as part of the proof generation process.

[0080] In step 316, an authentication request is received from the entity, which includes proof of attributes. For example, Figure 2The authenticator 234 receives from application 116A an authentication request 268 that includes, for example, a proof of (the requested) zone attribute (or corresponding secret). The authentication request 268 includes a (zero-knowledge cryptography) attribute proof generated using the proof generator 248, as described above. According to an embodiment, the authentication request includes an entity identifier (ID) (e.g., entity A in the running example).

[0081] In step 318, encrypted attribute information is retrieved from the ledger database. The encrypted attribute information includes encrypted versions of the attributes. For example, Figure 2 The authenticator 234 obtains encrypted attribute information, including an encrypted version of the region attribute (or corresponding secret), from the attribute map 238 via signal 270. According to an embodiment, signal 270 also includes a public key obtained from the identity map 236. The authenticator 234 obtains encrypted attribute information (e.g., an encrypted version of the region attribute, an encrypted version of the secret corresponding to the region attribute (e.g., secret A1), etc.) from the attribute map 238 based on the entity ID that uniquely identifies the entity associated with the verification request 268. The entity ID may be included in the authentication request 268 and / or the storage request 262. The authenticator 234 accesses the attribute map 238 based on the entity ID and obtains the corresponding encrypted attribute information associated with the entity ID. For example, in a running example, the authenticator 234 accesses the attribute map 238 to obtain an encrypted version of secret A1 associated with the entity ID of entity A. Additional details regarding obtaining the encrypted version of attribute information from the attribute map can be found in [reference needed]. Figure 6 And discussed elsewhere in this article.

[0082] In step 320, the authentication request is authenticated based at least on proof of the region attribute and cryptographic attribute information. For example, Figure 2The proof authenticator 234 authenticates the authentication request 268 based at least on the attribute proof included in the authentication request 268 and the encrypted attribute information obtained via signal 270. According to an embodiment, the authentication request 268 is authenticated without decrypting the encrypted attribute information (e.g., an encrypted version of a region attribute, an encrypted secret (e.g., an encrypted version of secret A1), etc.). According to an embodiment and referring to an operational example, the proof authenticator 234 determines whether the proof of the region attribute received in the authentication request 268 corresponds to the encrypted version of secret A1. According to an embodiment, the proof authenticator 234 determines whether the received proof corresponds to the encrypted version of secret A1 based on at least two or more of the received proof, the encrypted version of secret A1, and the public key corresponding to the encrypted attribute information (e.g., the public key of entity key pair 288A or the public key of authorization key pair 246A). According to an embodiment, the proof generator 234 authenticates the corresponding proof based on a zero-knowledge protocol, such as, but not limited to, the Schnorr protocol. If the authenticator 234 authenticates the authentication request 268, the authenticator 234 generates an indication 272 indicating that the request is valid (e.g., the proof of the region attribute indicates that entity A has secret A1), and flowchart 300 continues to step 322.

[0083] In response to determining that the proof does not correspond to the encrypted attribute information, the proof authenticator 234 does not authenticate the authentication request 268. According to an embodiment, in response to the unauthentication of the authentication request 268, the proof authenticator 234 invalidates the authentication request 268. According to an embodiment, in response to the unauthentication of the authentication request 268, the proof authenticator 234 sends a notification to application 116A or entity A (e.g., to another application or computing device associated with entity A) indicating that the authentication request 268 has not been authenticated. Figure 2 (Not shown in the image). According to an embodiment, the authenticator 234 sends a notification indicating that the authentication request 268 was not authenticated to the authorized application 120A or the authenticator A (e.g., to another application of the authorized system 104A, another computing device of the authorized system 104A, or another system associated with the authenticator A). Figure 2 (Not shown in the image). In either case, such a notification may direct the entity associated with authentication request 268 (and / or storage request 262), the policy associated with the storage / authentication request (e.g., security policy 128), and / or any other information associated with the authentication or storage request.

[0084] In step 322, verification of the entity's association with the region is performed. For example, policy verifier 232 receives instruction 272 from proof authenticator 234 and verifies that entity A is associated with region A. According to the embodiment, policy verifier 232 verifies the entity's association with the region to determine whether the storage criteria of security policy 128 are met. For example, policy verifier 232 obtains policy information 274 from policy manager 110. Policy information 274 includes the storage criteria of security policy 128 (e.g., the requirement that the entity is a resident of region A, a household of region A, or an authorized party of region A). Policy verifier 232 analyzes policy information 274 and instruction 272 to determine (e.g., verify) that the storage criteria of security policy 128 are met. For example, in a running example, policy verifier 232 analyzes policy information 274 to determine that entity A should possess secrets A1, A2, and / or A3 to protect entity A's encrypted resources using security policy 128. Policy verifier 232 also analyzes indication 272 to determine (based on authentication performed by proof authenticator 234) that entity A possesses secret A1. Based on the analysis of policy information 274 and indication 272, policy verifier 232 verifies that entity A is associated with region A (and meets the storage criteria of security policy 128), and generates indication 276 indicating that entity A is associated with region A, and flowchart 300 proceeds to step 324.

[0085] In step 324, encrypted resources are allocated to regions based on a region-based security policy. For example, Figure 2 Resource processor 230 allocates resources protected by security policy 128 (e.g., encrypted) to regions based on security policy 128. For example, continuing with the example, resource processor 230 allocates resources of entity A included in storage request 262 to region A. According to an embodiment, resource processor 230 allocates resources to regions by encrypting them using the encryption key of security policy 128. In this context, access to the corresponding decryption key (e.g., decryption key 286) to access the encrypted resource(s) requires association with the policy ID of security policy 128 in policy map 240. In this way, authentication system 106 (or its components (e.g., authenticator 234, policy validator 232, resource processor 230)), entities (or applications and / or computing devices representing entities), licensors (or applications and / or systems representing licensors) and / or other components, users, entities and / or applications can access policy map 240 to determine access criteria (e.g., access-required attributes) for resources protected by security policy 128.

[0086] In step 326, the encrypted resources are stored. For example, Figure 2Resource processor 230 sends storage signal 278 to data source 112 for storing a resource protected by security policy 128 (e.g., encrypted) (e.g., encrypted resource 126). Storage signal 278 includes the resource. According to an embodiment, storage signal 278 also includes an indication of a policy protecting encrypted resource 126 (e.g., a policy identifier (ID) of security policy 128). Alternatively, storage signal 278 includes a resource identifier that uniquely identifies encrypted resource 126. In this context, data source 112 stores encrypted resource 126 with an associated resource identifier. Additional details regarding policy mapping-based authorization of access to resources protected by security policies can be found in [reference]. Figure 4 Figure 5 Figure 7 and Figure 8 And other discussions elsewhere in this article.

[0087] In step 328, the entity is notified that storage of the encrypted resource has been authorized. For example, resource processor 230 sends a successful storage notification 282 (“Notification 282” herein) to application 116A, such as... Figure 2 As shown. Examples of notification 282 include, but are not limited to, Short Message Service (SMS) messages, telephone calls, emails, notifications presented via application 116A and / or another application running on entity computing device 134A and / or another computing device associated with the entity. Alternatively, resource processor 230 may send notification 282 to another computing device associated with the entity (e.g., a personal computing device).

[0088] In the example above, resource processor 230 is described as encrypting a resource in response to instruction 276. Alternatively, policy validator 232 (or another component of verification system 106) encrypts the resource (e.g., using the encryption key of security policy 128) and provides the encrypted resource to resource processor 230 in instruction 276. In another alternative embodiment, policy validator 232 (or another component of verification system 106) stores the encrypted resource in data source 112 (e.g., without sending an instruction to resource processor 230).

[0089] In some embodiments, and as Figure 2 As shown, policy validator 232 provides a (e.g., encrypted) decryption key to key manager 284. For example, policy validator 232 provides the encrypted decryption key to key manager 284 via key storage request 280, such as... Figure 2As shown. Key manager 284 stores the encryption / decryption key (e.g., an encrypted version of the decryption key corresponding to the encryption key of security policy 128) included in key storage request 280 as decryption key 286. According to an embodiment, key manager 284 includes a policy identifier having decryption key 286, which uniquely identifies the policy (e.g., security policy 128) associated with decryption key 286. Alternatively, policy mapping 240 associates the policy ID of security policy 128 with the key identifier that uniquely identifies decryption key 286.

[0090] IV. Example Implementations for Providing Access to Resources

[0091] As described herein, embodiments provide entity access to resources protected by region-based security policies. In embodiments, systems, methods, and computer-readable storage media having program instructions recorded thereon can provide access to resources protected by region-based security policies in various ways. For example, Figure 4 A block diagram of a system 400 for providing access to resources protected by a region-based security policy, according to an embodiment, is shown. Figure 4 As shown, system 400 includes a physical computing device 134N, as described above regarding... Figure 1 As described, the verification system 106 (including a policy validator 232, a proof authenticator 234, and a proof requester 290), the policy manager 110 (storing security policies 128), the data source 112 (maintaining encrypted resources 126), the ledger database 224 (including identity mappings 236, attribute mappings 238, and policy mappings 240), the resource processor 230, and the key manager 284 (maintaining decryption keys 286), as described above regarding... Figure 2 As described. Also, for example... Figure 4 As shown, entity computing device 134N includes application 416N, entity key pair 488N, and attribute information 418N. Application 416N is any software application used to access resources (e.g., resources maintained by data source 112), encrypt resources (e.g., generate encrypted resource 126), generate proofs of attributes (e.g., entity attribute information 418N), access ledger databases (e.g., ledger database 224), interface with associated authorization systems (e.g., authorization system 104A), interface with verification system 106, interface with resource processor 230, and / or otherwise interact with other computing devices, services, and / or components of system 400. Examples of application 120A include, but are not limited to, messaging applications (e.g., Microsoft Teams published by Microsoft Corporation of Redmond, Washington). TM ), word processing applications (e.g., Microsoft Word) TM Microsoft releases (database applications, etc.). Figure 4As shown, application 416N executes proof generator 448. Entity key pair 488N includes the public key (known to others) and the private key (known only to the entity) of the entity (e.g., entity N) associated with entity computing device 134N. Entity attribute information 418N includes information proving that the entity (e.g., entity N) associated with entity computing device 134N possesses one or more attributes. For example, continuing with... Figure 2 Following the non-limiting example discussed in Figure 3, assume that entity N is an employee user representing an organizational operation building a business in region A. In this context, entity N is a resident of region A and owns secret A2. According to an embodiment, system 400 includes an orchestrator ( Figure 4 (Not shown in the image), which facilitates communication between entities, authorization systems, authentication systems 106, resource processors 230, data sources 112, policy managers 110, and / or key managers 284.

[0092] For illustrative purposes, see below. Figure 5A Description system 400. Figure 5A A flowchart 500 is shown, illustrating a process for accessing resources protected by a region-based security policy according to an embodiment. System 400 can operate according to flowchart 500 in the embodiment. Not all steps of flowchart 400 need to be executed in all embodiments. Figure 4 and Figure 5A The following description, further structural and operational embodiments will be clear to those skilled in the art.

[0093] Flowchart 500 begins at step 502. In step 502, a resource request to access encrypted resources is received from the entity. For example, Figure 4 The proof requester 290 receives a resource request 446 from application 416N to access encrypted resource 126. According to an embodiment, resource request 446 includes an entity ID that uniquely identifies an entity (e.g., entity N) associated with application 416N and / or a resource ID that uniquely identifies encrypted resource 126. According to an embodiment and as further discussed with respect to step 506, resource request 446 includes proof of attributes (e.g., generated by proof generator 448). According to an embodiment and as further discussed with respect to step 506... Figure 6 Further discussion reveals that resource request 446 includes a summary representing the state of ledger database 224. Continuing with the non-restrictive running example, assume that entity N is requesting access to encrypted resource 126 (e.g., to verify private information of entity A, or otherwise perform an operation on private information of entity A).

[0094] In step 504, it is determined that the encrypted resource is allocated to a first zone and protected by a zone-based security policy. For example, Figure 4The proof requester 290 determines that the encrypted resource 126 is protected by security policy 128. For example, Figure 4 The proof requester 290 obtains policy information 448 from the policy manager 110. In this context, policy information 448 indicates that the encrypted resource 126 is protected by security policy 128 (e.g., the encrypted resource 126 is encrypted using the encryption key of security policy 128). Alternatively, the proof requester 290 obtains policy information from the policy map 240. For example, and continuing to refer to the non-restrictive operating example, assume that resource request 446 includes a resource identifier that uniquely identifies the encrypted resource 126. In this context, the proof requester 290 accesses the policy map 240 to obtain policy information indicating which policies (if any) protect the encrypted resource 126. Therefore, the proof requester 290 obtains policy information from the policy map 240 ( Figure 4 (Not shown) Receives policy information, determines that encrypted resource 126 is protected by security policy 128, and determines that entity N must present proof of having secret A1, secret A2 or secret A3 in order to be authorized to access encrypted resource 126.

[0095] In step 506, a certificate of the region attribute is received from the entity. The certificate indicates that the entity possesses the region attribute. The region attribute indicates that the entity is associated with a first region. For example, Figure 4 The authenticator 234 receives proof indicating that an entity possesses a regional attribute. Depending on the implementation, the regional attribute indicates that the entity is located in a first region, is a resident of the first region, is an organization headquartered in the first region, is a service assigned to the first region, is a government entity of the first region, and / or is otherwise associated with and / or assigned to the first region, as described elsewhere herein. According to an embodiment, proof of the regional attribute (also referred to as “attribute proof”) is included in resource request 446. According to another embodiment, application 416N is prompted to provide attribute proof to authenticator 234. For example, as... Figure 4 As shown and continuing to refer to the running example, the proof requester 290 (or another component of the verification system 106) sends a proof request 450 to the application 416N, which prompts the application 416N to provide an authentication request 452 (e.g., providing attribute proof via the prompting entity N or generating attribute proof via the proof generator 448). For additional details regarding the prompting entity providing attribute proof, refer to [link to relevant documentation]. Figure 5B discuss.

[0096] Proof generator 448 is associated with application 416N. According to one embodiment, proof generator 448 is incorporated into application 416N. According to another embodiment, proof generator 448 is a component separate from application 416N (e.g., a software application, a hardware-based proof generator, etc.). Proof generator 448 is configured to generate zero-knowledge cryptographic proofs based at least on an unencrypted version of a region attribute (e.g., entity attribute information 418N). According to one embodiment, proof generator 448 generates zero-knowledge cryptographic proofs based at least on an unencrypted version of a secret corresponding to the region attribute (e.g., secret A2). Figure 4 As shown, attribute information 418N is stored locally by physical computing device 134N. Alternatively, attribute information 418N may be stored in external storage accessible to physical computing device 134N (e.g., via a network). As described elsewhere herein, encrypted versions of region attributes (and / or corresponding secrets) are stored in attribute mapping 238 maintained by ledger database 224.

[0097] According to the implementation examples, and with reference to the operating examples, Figure 4 The proof generator 448 is configured to generate zero-knowledge cryptographic proofs of attributes based at least on an unencrypted version of secret A2, the public key of entity N, and an encryption algorithm used for encrypting the dataset. According to an embodiment, the proof generator 448 generates cryptographic proofs based on a zero-knowledge protocol, such as, but not limited to, the Schnorr protocol. In the example, although the proof generator 448 uses an unencrypted version of secret A2 (which is considered private) to generate a value, the generated value does not include the unencrypted secret. In other words, the generated value of the cryptographic proof cannot be used to reconstruct any unencrypted secret. In this way, the proof generator 448 provides proof that entity N possesses a given region attribute (or a secret corresponding to that region attribute), although the region attribute or secret is not relayed.

[0098] In various embodiments, a (zero-knowledge) proof of a region attribute (also referred to as an "attribute proof") includes information used to prove that an entity (e.g., entity N) possesses a value for the region attribute or a corresponding secret (e.g., secret A2), and that if that value is input into an encryption algorithm, an encrypted version of the value of secret A2 will be obtained (e.g., stored in attribute map 238). In various other embodiments, other algorithms, such as a secure hash algorithm (SHA), are used instead of an encryption algorithm. For example, regarding the running example, in this case, the zero-knowledge proof would be used to prove that if the value of secret A2 is input into the SHA, an encrypted version of the value of secret A2 stored in attribute map 238 will be obtained (assuming the value in attribute map 238 is also based on the algorithm). Other techniques are also envisioned herein, and the techniques disclosed for providing zero-knowledge proofs are not limited to these illustrative examples. In some more implementations, zero-knowledge proofs are non-replayable. For example, in some embodiments, the proof authenticator 234 generates a random number for each session (e.g., each new communication session for which the entity computing device 134A seeks access to encrypted resources) and provides the randomly generated number to the proof generator 448 as part of the proof generation process. Therefore, even if the same proof is attempted for a subsequent session (either by the same computing device or by a different system in a malicious manner), the proof will not succeed because the subsequent session will have a different randomly generated number, which will be used as part of the proof generation process.

[0099] In step 508, encrypted attributes are retrieved from the ledger database. The encrypted attribute is an encrypted version of a region attribute. For example, authenticator 234 retrieves encrypted attribute information, including an encrypted version of the region attribute (or corresponding secret), from attribute map 238 via signal 454. According to an embodiment, signal 454 also includes a public key retrieved from identity map 236. Authenticator 234 retrieves encrypted attribute information (e.g., an encrypted version of the region attribute, an encrypted version of the secret corresponding to the region attribute (e.g., secret A2), etc.) from attribute map 238 based on the entity ID that uniquely identifies entity N. The entity ID may be included in authentication request 452 and / or resource request 446. Authenticator 234 accesses attribute map 238 based on the entity ID and retrieves the corresponding encrypted attribute information associated with the entity ID. For example, in the running example, authenticator 234 accesses attribute map 238 to retrieve an encrypted version of secret A2 associated with the entity ID of entity N. Additional details regarding the encrypted version of attribute information retrieved from the attribute map can be found in [reference needed]. Figure 6 And discussed elsewhere in this article.

[0100] In step 510, the resource request is authenticated based at least on proofs of encrypted attributes and zone attributes. For example, the proof authenticator 234 authenticates resource request 446 based on proofs of encrypted attributes (e.g., included in signal 454) and zone attributes (e.g., included in resource request 446 or authentication request 452). According to an embodiment, the proof authenticator 234 authenticates resource request 446 without decrypting encrypted attribute information (e.g., encrypted attributes, encrypted secrets (e.g., encrypted version of secret A2)). According to an embodiment, the proof authenticator 234 determines whether the proof of the attribute provided in authentication request 452 (or included in resource request 446) corresponds to the encrypted version of secret A2. According to an embodiment, the proof authenticator 234 determines whether the proof of the attribute corresponds to the encrypted version of secret A2 based on at least two or more of the proof, the encrypted version of secret A2, and the public key corresponding to the encrypted attribute information (e.g., the public key of entity key pair 488N or the public key of authorization key pair 246A). According to an embodiment, the proof generator 234 authenticates the proof based on a zero-knowledge protocol, such as, but not limited to, the Schnorr protocol. In one implementation, the authentication of the proof is performed by comparing a first value generated by the proof authenticator 234 with a second value based on the proof, the first value being determined based on an encrypted version of secret A2 obtained from attribute mapping 238 and a public key corresponding to entity N obtained from identity mapping 236. In response to determining that the proof corresponds to an encrypted attribute (e.g., an encrypted secret), the proof authenticator 234 authenticates resource request 446 and generates indication 456, indicating that the request is valid (e.g., the proof of the attribute indicates that entity N possesses secret A2), and flowchart 500 continues to step 512.

[0101] In step 512, verification is performed to confirm that the access criteria of the region-based security policy are met. For example, policy verifier 232 verifies that the access criteria of security policy 128 are met (e.g., based on policy information 448). According to an embodiment, in response to receiving instruction 456 from authenticator 234, policy verifier 232 verifies that the access criteria of security policy 128 are met. For example, in a running example, policy verifier 232 analyzes security policy 128 (e.g., a region-based security policy set by authorizing party A in region A), and if resource request 446 is authenticated, determines that the access criteria of the policy are met. If policy verifier 232 verifies that the access criteria are met, policy verifier 232 provides instruction 458 to resource processor 230, and flowchart 500 continues to step 514.

[0102] In step 514, access to the encrypted resource is provided to the entity. For example, resource processor 230 provides access to the encrypted resource 126 to the entity associated with entity computing device 134N. For example, in a running example, resource processor 230 provides entity N with access to the encrypted resource 126 of entity A. According to an embodiment, resource processor 230 acquires the encrypted resource and provides a response 468 including the encrypted resource to application 416N. Alternatively, in response 468, resource processor 230 decrypts the encrypted resource and includes a decrypted version of the resource. According to an embodiment, response 468 includes a decryption key (e.g., decryption key 286) (e.g., its encrypted version) for decrypting the encrypted resource 126. Additional details regarding providing entity access to resources protected by a region-based security policy will be referenced. Figure 5C and Figure 5D Further description.

[0103] As described herein, the proof authenticator 234 is described as authenticating proofs of region attributes. According to embodiments, the proof authenticator 234 (e.g., simultaneously or sequentially) authenticates multiple proofs of attributes (e.g., multiple region attributes or multiple attributes including region attributes). For example, suppose security policy 128 requires an entity to possess multiple attributes (e.g., including region attributes) to access encrypted resource 126. As a non-limiting example, suppose security policy 128 requires an entity to possess a first secret (e.g., secret A1, secret A2, and / or secret A3) corresponding to a region attribute indicating that the entity is associated with region A and a second secret (e.g., "secret B") corresponding to a security permission attribute indicating that the entity has a specific level of security permission. In this context, resource request 446 or authentication request 452 may include proofs of each required secret (e.g., secret A2 and secret B). In this context, the proof authenticator 234 determines whether resource request 446 is valid based on whether each proof indicates that the entity possesses the corresponding attribute. The proof authenticator 234 obtains encrypted versions of secret A2 and secret B from attribute mapping 238. If the authenticator 234 determines that the proof of secret A2 corresponds to the encrypted version of secret A2 and the proof of secret B corresponds to the encrypted version of secret B, then the authenticator 234 authenticates resource request 446 and generates instruction 456. Policy validator 232 receives instruction 456 and determines that security policy 128 is satisfied based on the authentication of the proofs of secret A2 and secret B.

[0104] As described herein, authenticator 234 proves the authentication (e.g., zone) attribute, and policy validator 232 verifies that the verified proof satisfies the security policy. This document further envisions that the resource can be protected by multiple security policies (e.g., including zone-based policies). For example, suppose encrypted resource 126 is subject to security policy 128 specified by authorizing party A and entity-specific security policy specified by entity A. Figure 4 Protection is provided for (not shown in the image). In this context, security policy 128 requires an entity to possess a first secret (e.g., secret A1, secret A2, and / or secret A3) corresponding to the region attribute indicating that the entity is associated with region A, and an entity-specific security policy requires the entity to possess a second secret (e.g., "secret C") corresponding to the authorization attribute indicating that the entity is authorized by entity A to access private information of entity A for authentication purposes. In this context, resource request 446 or authentication request 452 may include proofs for each required secret (e.g., secret A2 and secret C). In this context, proof authenticator 234 determines whether resource request 446 is valid based on whether each proof indicates that the entity possesses the corresponding attribute. Proof authenticator 234 obtains encrypted versions of secret A2 and secret C from attribute mapping 238. If proof authenticator 234 determines that the proof of secret A2 corresponds to the encrypted version of secret A2 and the proof of secret C corresponds to the encrypted version of secret B, then proof authenticator 234 authenticates resource request 446 and generates indication 456. Policy verifier 232 receives instruction 456 and determines the access criteria for security policy 128 and whether entity-specific security policies are met based on the authentication of the proofs for secrets A2 and C. According to an embodiment, if the access criteria for each policy protecting encrypted resources are met, policy verifier 232 releases access to the decryption key (e.g., only).

[0105] According to an alternative embodiment where the resource is protected by multiple security policies, the resource is encrypted using multiple encryption keys, each corresponding to a corresponding policy (e.g., security policy 128 and an entity-specific security policy). In this context, if the access criteria for the corresponding policy are met, the corresponding decryption key is released. If the entity possesses each decryption key, the entity can (e.g., only) access (e.g., decrypt) the encrypted resource.

[0106] As described above, the authenticator 234 can receive attribute proofs from the entity in various ways. For example, the entity can include attribute proofs in a resource request. Alternatively, the verification system 106 (or resource processor 230, or another component of verification system 106) prompts the entity to provide attribute proofs. Figure 5BA flowchart 520 is shown for a process of receiving attribute proof from an entity according to an embodiment. Flowchart 520 is a further embodiment of step 506 of flowchart 500. Verification 106 can be operated according to flowchart 520 in the embodiments. Not all steps of flowchart 520 need to be performed in all embodiments. Based on Figure 5B The following description, further structural and operational embodiments will be clear to those skilled in the art.

[0107] Flowchart 520 begins with step 522. In step 522, a proof request is sent to the computing device associated with the entity. The proof request prompts the entity to provide proof of the region's attributes. For example, Figure 4 The proof requester 290 sends a proof request 450 to the application 416N. The proof request 450 prompts entity N (or the proof generator 448 on behalf of entity N) to provide proof of an attribute (e.g., proof of secret A2 in the running example). In response to receiving the proof request 450, entity N, application 416N, and / or proof generator 448 generate the attribute proof. For example, and continuing to refer to the above reference... Figures 2 to 5A The described operational example demonstrates that proof generator 448 can generate proof that entity N possesses secret A2 based on any techniques described elsewhere herein. In embodiments where multiple attributes (e.g., including region attributes) are required to access cryptographic resource 126, proof request 450 prompts entity N, application 416N representing entity N, and / or proof generator 448 representing entity N to generate a corresponding proof for each attribute (or corresponding secret). Alternatively, proof requester 290 sends a separate proof request for each corresponding attribute.

[0108] In step 524, a response is received from the computing device associated with the entity. The response includes proof of a region attribute. For example, the proof authenticator 234 receives authentication request 452 from application 416N. Authentication request 452 includes proof of a region attribute (e.g., proof that entity N possesses secret A2). According to an embodiment, authentication request 452 includes an entity identifier of entity N. According to an embodiment, authentication request 452 includes multiple proofs (e.g., in embodiments where multiple attributes are required to access a resource).

[0109] Figure 4 System 400 can operate in various ways to provide entities with access to resources protected by a region-based security policy. For example, according to one or more embodiments, as described above regarding... Figure 4 As described, authentication system 106 is a trusted authentication system (e.g., a trusted LAP server) that is trusted to decrypt resources protected by a zone-based security policy and operates to grant entities access to resources protected by security policy 128. For example, Figure 5CA flowchart 530 is shown, illustrating a process for providing decryption resources to an entity according to an embodiment. Flowchart 530 is a further embodiment of step 514 of flowchart 500. Verification 106 can be operated according to flowchart 530 in the embodiments. Not all steps of flowchart 530 need to be performed in all embodiments. Based on Figure 5C The following description, further structural and operational embodiments will be clear to those skilled in the art.

[0110] Flowchart 530 begins with step 532. In step 532, the encrypted resource is decrypted. For example, as regarding... Figure 4 As described, policy validator 232 (or Figure 4 Another component of the verification system 106 (not shown) (e.g., a decryptor) decrypts the encrypted resource 126. The verification system 106 can decrypt the encrypted resource 126 in various ways. According to an embodiment (e.g., and in response to the access criteria of verification security policy 128 being met), the policy verifier 232 (or another component of the verification system 106) sends a key request 460 to the key manager 284 for the decryption key 286 associated with the encrypted data 126. For example, as mentioned above regarding... Figures 2 to 5B In the context of the described operational example, key request 460 specifies a policy ID that uniquely identifies security policy 128 (e.g., the policy under which entity A's encrypted resources (e.g., encrypted resource 126) are protected). In this context, key manager 284 returns a decryption key 286 to verification system 106 via key response 462. According to an embodiment, key request 460 includes a secret (e.g., a LAP server secret) (or an encrypted version of the secret) that key manager 284 analyzes to verify the validity of key response 462. According to an embodiment, key manager 284 uses a proof authenticator (or proof authenticator 234) that operates in a similar manner to proof authenticator 234. Figure 4 (Not shown in the image) is used for authentication. Policy validator 232 (or another component of verification system 106) sends a resource request for encrypted resources for entity A to data source 112. Figure 4 (Not shown in the image). The resource request specifies a resource identifier that uniquely identifies the encrypted resource of entity A. Data source 112 returns the encrypted resource of entity A to verification system 106, which decrypts the encrypted resource using decryption key 286.

[0111] In step 534, the decryption resources are provided to the entity. For example, in the context of running the example, policy validator 232 (or Figure 4 Another component of the verification system 106 (not shown) (e.g., a decryptor) is transmitted via Figure 4The response, not shown, provides entity N with a decrypted version of entity A's encrypted resource (e.g., encrypted resource 126). According to an embodiment, verification system 106 utilizes a public key (e.g., entity N's public key, such as that stored in identity mapping 236), application 416N's public key, and a document management and storage system (e.g., by...). The company released Microsoft SharePoint TM This refers to decrypting resources, etc. The decrypted version of the data encrypted by entity A is used. Verification system 106 obtains the public key from identity mapping 236, as described elsewhere herein. According to such an embodiment, verification system 106 sends the resource encrypted with the public key to resource processor 230, and resource processor 230 sends the encrypted resource to application 416N. By doing so, the decrypted version of encrypted resource 126 is protected from malicious users who may compromise resource processor 230. According to an alternative embodiment, verification system 106 (e.g., directly) sends the resource encrypted with the public key to application 416N. By doing so, the decrypted version of encrypted resource 126 is protected from malicious users who may intercept communication between verification system 106 and entity N.

[0112] As mentioned above, Figure 4 System 400 can operate in various ways to provide entities with access to resources protected by a region-based security policy. For example, according to one or more embodiments, as described above regarding... Figure 4 As described, authentication system 106 is not trusted to decrypt resources protected by a region-based security policy (e.g., an untrusted authentication system or a partially trusted authentication system (e.g., an authentication system whose access criteria for the authorized authentication security policy are met but is not authorized to decrypt resources)), and operates to authorize another component of system 400 (e.g., resource processor 230) or another component outside system 400 to grant entities access to resources protected by security policy 128. For example, Figure 5D A flowchart 540 is shown, illustrating a process for an authorized resource processor to provide decryption resources to an entity according to an embodiment. Flowchart 540 is a further embodiment of step 514 of flowchart 500. System 400 can operate according to flowchart 540 in the embodiments. Flowchart 540 does not need to be executed in all embodiments. Based on Figure 5D The following description, further structural and operational embodiments will be clear to those skilled in the art.

[0113] Flowchart 540 includes step 542. In step 542, the resource processor is authorized to decrypt the resource and provide the decrypted resource to the entity. For example, as Figure 4As shown, policy verifier 232 provides instruction 458 to resource processor 230, authorizing resource processor 230 to decrypt encrypted resource 126 protected by security policy 128, and providing the decrypted resource to the entity. For example, according to the above regarding... Figures 2 to 5B The described running example, Policy Verifier 232, is similar to the one described above. Figure 5C The described example involves sending a key request 460 to the key manager 284 and receiving a key response 284. This is as described above regarding... Figure 5C As an alternative to the described example, key manager 284 encrypts decryption key 286 in a manner that prevents policy validator 232 (or another component of verification system 106) from accessing the decrypted version of decryption key 286. For example, according to the embodiment, key manager 284 uses resource processor 230 ( Figure 4 The public key of the key pair (not shown) is used to encrypt the decryption key 286. In this context, the policy validator 232 receives the encrypted version of the decryption key 286 and sends the decryption key 286 to the resource processor 230 (e.g., via instruction 458). The resource processor 230 decrypts the encrypted version of the decryption key 286 and uses it to decrypt the encrypted data of entity A. For example, also as Figure 4 As shown, resource processor 230 also sends a resource request 464 for encrypted data for entity A to data source 112. Resource request 464 specifies a resource identifier that uniquely identifies the encrypted resource for entity A. Data source 112 returns the encrypted data for entity A via resource response 466. Resource processor 230 decrypts the encrypted resource for entity A using decryption key 286 and sends it via response 468 to entity N, the user representing entity N, and / or the application representing entity N (e.g., in...). Figure 4 The diagram shows a decrypted version of the encrypted resources provided for the physical computing device 134N (application 416N).

[0114] According to an embodiment, resource processor 230 utilizes a public key (e.g., the public key of entity N (such as stored in identity mapping 236), the public key of application 416N, and a document management and storage system (e.g., by...). The company released Microsoft SharePoint TM This refers to decrypting resources, etc. The decrypted version of the data in encrypted resource 126 is then encrypted. Resource processor 230 obtains a public key from an identity mapping (e.g., identity mapping 236), as described elsewhere herein. According to such an embodiment, data processor 230 sends the resource encrypted with the public key to the corresponding application of entity N (e.g., application 416N). By doing so, the decrypted version of encrypted resource 126 is protected from malicious users who might intercept communication between resource processor 230 and entity N.

[0115] According to an embodiment, resource processor 230 is a trusted resource processor. In this context, resource processor 230 is trusted to decrypt encrypted resource 126.

[0116] According to another embodiment, resource processor 230 is not a trusted resource processor. In this context, key request 460 includes a decryptor (e.g., a security enclave, a security server, or another suitable application and / or device for securely decrypting resources protected by security policy 128) associated with entity N or authorized to decrypt resources protected by a region-based security policy. Figure 4 (Not shown in the image) Corresponding identity. For example, regarding the above reference Figure 5D In the described operational example, in response to receiving a key request 460, key manager 284 obtains a public key from identity map 236 based at least on the identity included in key request 460 (e.g., the identity of entity N). Key manager 284 encrypts decryption key 286 using the public key obtained from identity map 236 and provides an encrypted version of decryption key 286 to policy validator 232 via key response 462. Policy validator 232 provides an encrypted version of decryption key 286 to resource processor 230 (e.g., via instruction 458). As described above, resource processor 230 obtains encrypted resources of entity A (e.g., encrypted resource 126) and (e.g., via...) Figure 4 In response 468, the encrypted version of decryption key 128 and the encrypted resources of entity A are provided to entity N, the user representing entity N, and / or the application (e.g., application 416N or a decryptor external to application 416N) that uses entity A's decryption key to decrypt entity A's encrypted resources. By doing so, the decrypted version of entity A's encrypted data and the decrypted version of decryption key 128 are protected from malicious users who could potentially penetrate authentication system 106 and / or resource processor 230, while still preventing entity N from independently accessing the decrypted version of encrypted resource 126 without meeting the access criteria of security policy 128.

[0117] According to another embodiment, verification system 106 is not a trusted verification system (or, alternatively, a partially trusted verification system where the access criteria of the authorized verification security policy are met but the decryption of the resource is not authorized), resource processor 230 is not a trusted resource processor, and key manager 284 is not a trusted key manager. For example, regarding the above references Figure 5D The described operational example, on the other hand, involves providing the decryption key 286 to the key manager 284 (e.g., by entity A (or an application representing entity A) as... Figure 3ASteps 312 through 324, or steps prior to them, or steps encrypting / decrypting key 286 when setting security policy 128 by Authorized Party A (or an application representing Authorized Party A). In this context, in response to receiving key request 460, Key Manager 284 provides an encrypted version of decryption key 286 to Policy Verifier 232 via key response 462. Policy Verifier 232 provides an encrypted version of decryption key 286 to Resource Processor 230. Resource Processor 230 (e.g., via...) Figure 4 The response 468) is sent to entity N, the user representing entity N, and / or the application (e.g., application 416N) that decrypts the encrypted version of decryption key 286 on behalf of entity N. In doing so, the decrypted version of entity A's encrypted resources and the decrypted version of decryption key 286 are protected from malicious users who could potentially penetrate authentication system 106, key manager 284, and / or resource processor 230, while still preventing entity N from independently accessing the decrypted version of encrypted resource 126 without meeting the access criteria of security policy 128. For example, as a non-limiting example, suppose authorizing party A uses a secure enclave ( Figure 4 The public key (not shown) is used to encrypt and decrypt the key 286. In this context, after the policy verifier 232 determines that the access criteria of security policy 128 are met and provides an encrypted version of the decryption key 286 to the resource processor 230, the resource processor 230 provides the encrypted version of the decryption key 286 to the security enclave (or provides the security enclave to entity N). The security enclave uses the private key of the security enclave corresponding to the public key authorized party A used to encrypt and decrypt the key 286 to decrypt the decryption key 286. According to another embodiment, the security enclave provides the decrypted version of the decryption key 286 to entity N, enabling entity N to decrypt the encrypted resource 126. Alternatively, the security enclave acquires the encrypted resource 126, decrypts the encrypted resource 126 using the decrypted version of the decryption key 286, and provides the decrypted version of the encrypted resource 126 to entity N (e.g., without providing entity N with access to the decrypted version of the decryption key 286). In this context, the decrypted version of decryption key 286 is protected from malicious users who may infiltrate the computing devices of entity N and / or the communication between entity N and the secure enclave.

[0118] As described above, according to one or more embodiments, resource processor 230 obtains encrypted resource 126 from data source 112, and for example via... Figure 4 The response 468 shown provides entity N, the user representing entity N, and / or the application representing entity N to decrypt encrypted resource 126, a decrypted version of encrypted resource 126, a partially decrypted version of encrypted resource 126, or an encrypted version of encrypted resource 126 and encryption / decryption key 286 to entity N. According to one or more alternative embodiments, resource processor 230 does not access encrypted resource 126. For example, regarding the above reference... Figure 5D In the described operational example, on the other hand, resource processor 230 obtains decryption key 286 (or an encrypted version of decryption key 286) as described above, and (e.g., via...) Figure 4 The response 468 will provide a decryption key to entity N, the user, and / or the application. Entity N, the user, and / or the application accesses the encrypted resources of entity A (e.g., encrypted resource 126) (e.g., from data source 112, from a local data source, or from another data source accessible to the entity, user, and / or application) and uses decryption key 286 to decrypt the encrypted resources of entity A. By doing so, the encrypted resources of entity A are further protected from malicious users who may intercept communication between entity N and resource processor 230. Furthermore, by not including the encrypted resources of entity A in the access response 468, resource processor 230 uses fewer computational resources because resource processor 230 does not need to obtain the encrypted resources of entity A from data source 112.

[0119] As referenced above Figure 5D As discussed, policy validator 232 obtains decryption key 286 (or an encrypted version of decryption key 286) and provides the decryption key to resource processor 230 via instruction 458. According to one or more alternative embodiments, policy validator 232 does not obtain decryption key 286. For example, regarding the above reference... Figure 5D In other words, as described in the various examples, policy validator 232 provides instruction 458 to resource processor 230 in response to determining that the access criteria of security policy 128 are met (e.g., no decryption key 286 is obtained from key manager 284). Upon receiving instruction 458, resource processor 230 sends a key request to key manager 284 in a manner similar to that described regarding policy validator 232 sending a key request 460 to key manager 284. Figure 4 (not shown in the image) (e.g., for decryption key 286 or an encrypted version of decryption key 286). Furthermore, in some embodiments (e.g., where verification system 106 is trusted to verify that access criteria of security policy 128 are met but not to decrypt resources protected by security policy 128), indication 458 includes resource processor 230 provided to key manager 284 (e.g., in a transmitted key request) to indicate that policy verifier 232 has verified that entity N has met the access criteria of security policy 128's secret (e.g., LAP server secret) (or an encrypted version of the secret). Resource processor 230 receives the key response in a manner similar to policy verifier 232 receiving key response 462. Figure 4(Not shown in the diagram). By doing so, the decryption key 286 is further protected from malicious users who may compromise the authentication system 106 and / or the communication between the authentication system 106 and other components of the system 400. Furthermore, by omitting the decryption key 286 in instruction 458, the authentication system 106 uses fewer computational resources because it does not need to obtain the decryption key 286 from the key manager 284.

[0120] As mentioned above, Figure 4 System 400 can operate in various ways to access the decryption key used to decrypt resources protected by a zone-based security policy. For example, several examples are described regarding obtaining the decryption key 286 from key manager 284. This document also anticipates that the verification system 106, resource processor 230, application 416N, and the decryptor of system 400 (…) Figure 4 (Not shown in the image), 134N secure enclave for physical computing devices ( Figure 4 (not shown in the image), System 400 security server ( Figure 4 (Not shown in the diagram) and / or another component or subcomponent of system 400 suitable for decrypting resources protected by security policy 128 may use an encryption algorithm to compute a decryption key instead of obtaining a decryption key from key manager 284. In this context, the cryptographic algorithm receives one or more shared secrets, wherein the one or more shared secrets correspond to attributes that a requesting entity (e.g., entity N) is required to possess as specified in security policy 128. Each of the one or more secret shares provided to the cryptographic algorithm includes a portion of a decryption key (e.g., decryption key 286) for decrypting encrypted resource 126. In an embodiment, entity computing device 134N provides proof that entity N possesses appropriate attributes (including region attributes) after (e.g., in response to policy validator 232 verifying that the access criteria of security policy 128 are met). According to another embodiment, entity computing device 134N provides one or more shared secrets to the cryptographic algorithm before or even simultaneously with providing proof to verification system 106. In an implementation, the shared secrets include unencrypted private keys, each private key corresponding to a public key of an attribute stored in attribute mapping 238. In some implementations, the shared secret is provided to the authentication system 106 (e.g., in resource request 446, in authentication request 452, or in separate communications to the authentication system 106). Figure 4 (Not shown in the diagram), and the verification system 106 provides the shared secret to the cryptographic algorithm when verifying the proof. In other implementations, the physical computing device 134N (e.g., directly) provides the shared secret to the cryptographic algorithm.

[0121] According to an embodiment, the cryptographic algorithm described above generates (or recovers) the decryption key 286 based on a secret share corresponding to the area requirement (e.g., proof that entity N possesses area attributes (e.g., static area attributes (e.g., assigned to entity N by authorizing party A and indicating that entity N is assigned to area A), proof that entity N possesses dynamic area attributes (e.g., indicating that entity N is located in area A) and / or proof that entity N possesses both static and dynamic area attributes)). According to an embodiment, the cryptographic algorithm generates (or recovers) the decryption key 286 based on a secret share corresponding to the area requirement and one or more additional secret shares corresponding to other attributes possessed by entity N required to access the encrypted resource 126. According to an embodiment, the cryptographic algorithm combines shared secrets to generate the decryption key 286. For example, the cryptographic algorithm sums the shared secret corresponding to the area requirement with one or more additional secret shares to generate the decryption key 286. In another example, the cryptographic algorithm performs a polynomial evaluation on these shared secrets to generate the decryption key 286. Note that in the embodiment, any number of portions of the decryption key 286 are released and combined to generate the decryption key 286. For example, a release portion for each verified proof, which receives proof for each attribute.

[0122] As referenced above Figure 4 As described, embodiments of the proof authenticator 234 can operate in various ways to retrieve cryptographic attributes from a ledger database. For example, the proof authenticator 234 according to one or more embodiments retrieves cryptographic attributes (or cryptographic secrets corresponding to the attributes) from the ledger database in a tamper-proof and / or tamper-proof manner. Figure 6 A flowchart 600 is shown, illustrating a process for retrieving encrypted attributes from a ledger database according to an embodiment. Flowchart 600 is as referenced... Figure 5A A further embodiment of step 508 of the described flowchart 500. In the embodiment, Figure 4 The authenticator 234 can operate according to flowchart 600. Not all steps of flowchart 600 need to be executed in all embodiments. Figure 6 The following description, further structural and operational embodiments will be clear to those skilled in the art(s).

[0123] Flowchart 600 begins at step 602. In step 602, a summary representing the state of the ledger database is received from the entity. For example, resource request 446 or authentication request 452 includes a corresponding summary representing the state of ledger database 224. For example, continuing from the above reference... Figure 5AIn the described operational example, the authenticator 234 receives an authentication request 452. In this context, the authentication request 452 includes an attribute certificate and a digest representing the state of the ledger database 224. According to an embodiment, the authentication request 452 includes the identity (or a reference to) of an entity (e.g., entity N of entity computing device 134N). According to another embodiment, the authentication request 452 includes a policy ID representing a security policy (e.g., security policy 128) associated with the corresponding attribute. According to embodiments, the certificate, digest, identity, and / or policy ID are included in a separate request to the authenticator 234. Note that in some embodiments, multiple digests are provided to the authenticator 234, wherein the multiple digests include some or all of the digests previously generated from the ledger of the ledger database 224.

[0124] In step 604, the ledger database is authenticated at least based on a digest. For example, Figure 4 The authenticator 234 provides proof to the DB host 108 of the hosted ledger database 224. Figure 4 (not shown in the image) provides one or more digests (“digests”) received in step 602. According to an embodiment, the authenticator 234 provides the DB host 108 (… Figure 4 (Not shown) provides an attribute request, which includes a summary and the identity of the requested entity (e.g., entity N). The summary is authenticated by DB host 108. If the summary is not authenticated, DB host 108 determines that the ledger has been tampered with and issues a notification indicating that the ledger has been tampered with, certifying the authenticator 234, one or more entity computing devices (e.g., entity computing device 134A, entity computing device 134N, etc.) and / or the authorization system associated with the ledger database (e.g., authorization system 104A).

[0125] In response to the authentication response digest, an encrypted attribute is retrieved. For example, in response to the authentication response digest, the corresponding encrypted attribute (or the encrypted secret corresponding to the attribute) is retrieved from a table (e.g., attribute mapping 238) according to the DB host 108 of the embodiment (e.g., based on the corresponding identity and / or policy ID included in the request). Once the digest has been verified, flowchart 600 continues to step 606.

[0126] In step 606, a response including cryptographic attributes is received from the ledger database. For example, the authenticator 234 receives signal 454 from the ledger database 224. In this context, signal 454 is a response signal that includes cryptographic attributes (or corresponding cryptographic secrets) located by the ledger database 224, as described above and / or as will be understood by those skilled in the art(s) benefiting from this disclosure. For example, regarding references... Figure 4 and 5AIn the described operational example, signal 454 includes an encrypted version of secret A2. According to an embodiment, after DB host 108 obtains the encrypted attributes from attribute mapping 238, authenticator 234 receives signal 454 from DB host 108. According to an embodiment, signal 454 (e.g., received from DB host 108) includes an indication that the digest is valid.

[0127] As mentioned above regarding the process Figure 6 The DB host 108 verifies the ledger database 224 based at least on one or more digests received from entity N. However, this document also envisions that the verification system 106 (or its components, such as the proof authenticator 234) can be configured to... Figure 6 The ledger database 224 is authenticated in a manner similar to that described in flowchart 600. For example, according to an embodiment, verification system 106 receives a first digest from entity N (e.g., via authentication request 452) and a second digest from ledger database 224 (or from DB host 108). Verification system 106 compares the two digests, and if the digests match, it determines that ledger database 224 has not been tampered with. If the digests do not match, verification system 106 determines that the ledger has been tampered with, and one or more entity computing devices (e.g., entity computing device 134A, entity computing device 134N, etc.) and / or an authorization system associated with the ledger database (e.g., authorization system 104A) issue a notification indicating that the ledger has been tampered with.

[0128] V. Example Implementations for Implementing Region-Based Security Policies

[0129] As mentioned above, such as Figure 1 The verification system 106 and / or its components implement a region-based security policy. Therefore, embodiments of the verification system regulate access to resources protected by the region-based security policy by a requesting entity, at least based on the resource and the region to which the requesting entity is assigned. To better illustrate some embodiments of this disclosure, several example systems and corresponding scenarios are described below.

[0130] Figure 7 A block diagram of an example system 700 for implementing a region-based security policy for cloud resources, according to an example embodiment, is shown. Figure 7 As shown, system 700 includes physical computing device 702, authorization system 704, authentication system 706, and data center 708. Physical computing device 702 operates in a manner similar to physical computing device 134A and / or physical computing device 134N, authorization system 704 operates in a manner similar to authorization system 104A, authentication system 706 operates in a manner similar to authentication system 106, and data center 708 operates in a manner similar to data source 712, as referenced above. Figures 1 to 6Each is described separately. For example... Figure 7 As shown, data center 708 stores encrypted resources 710. System 700 may include, for the sake of simplicity... Figure 7 Any additional components not shown (e.g., additional authorization systems, additional entity computing devices, other data sources, policy managers, DB hosts, key managers, resource processors, etc.). According to an embodiment, verification system 706 is a LAP server. According to an embodiment, verification system 706 is a trusted verification system (e.g., a verification system trusted by authorization system 704, used to verify whether the access criteria of the authorizing party's security policy are met, access the decryption key used to decrypt resources protected by such security policy, calculate the decryption key used to decrypt resources protected by such security policy, and / or the decryption key used to decrypt encrypted resources protected by such security policy).

[0131] For example Figure 7 As shown, the authorization system 704 and the physical computing device 702 are located in a first region 730A (“Region 730A” herein), and the data center 708 is located in a second region 730B (“Region 730B” herein). The verification system 706 according to an embodiment is a globally distributed verification system across many regions in a cloud computing platform. According to another embodiment, the verification system 706 is located in region 730A, region 730B, or… Figure 7 For simplicity, this is one of the areas not shown in another area. Each of areas 730A and 730B may include additional licensed systems, physical computing devices, and / or data centers, for simplicity. Figure 7 Not shown. Furthermore, embodiments of system 700 may include any number of regions other than and / or replacing regions 730A and / or 730B. Given the foregoing context, several example scenarios are described below with respect to system 700.

[0132] In a first non-limiting example scenario, the authorization system 704 is associated with a government authorizing entity (“Authorizing Entity 730A”) in region 730A, entity computing device 702 is a computing device belonging to a resident of region 730A (“Resident A”) who possesses the attribute “Resident of Region 730” (“Attribute A”), and encrypted resource 710 is Resident A’s private data protected by Authorizing Entity 730A’s region-based security policy (“Policy A”). In this scenario, the authorization system 704 sends an update request 712 to the verification system 706. The update request 712 includes a request to update Policy A to restrict access to the resident’s private data in region 730A, so that only entities assigned to region 730A (e.g., entities possessing Attribute A or another attribute indicating that an entity is assigned to region 730A) can access the private data. In this context, the verification system 706 verifies the update request 712 (e.g., by referring to…) Figure 3A (as described in step 304) and update the policy mapping corresponding to policy A (e.g., to refer to...) Figure 3A (as described in step 306). By doing so, the access criteria required to access the encrypted resource 710 are updated in the way that the encrypted resource 710 is assigned to region 730A, even though it is stored in data center 708 located in region 730B.

[0133] In this first example, suppose resident A wishes to access their private data (e.g., encrypted resource 710). Resident A sends a resource request 716 to authentication system 706, which is a request to access encrypted resource 710 and includes proof that resident A owns attribute A. Authentication system 706 determines a policy (e.g., policy A) to protect encrypted resource 710 and utilizes authentication and verification techniques described elsewhere in this document (e.g., as referenced). Figure 5A Steps 504 to 512 Figure 5B Steps 522 and 524 and / or Figure 6(As described in steps 602 to 606) to determine whether resource request 716 is valid. For example, authentication system 706 accesses an attribute mapping maintained by licensor A, which maps entities in region 730A to attributes assigned by licensor A. In this example, authentication system 706 accesses the attribute mapping to obtain an encrypted version of attribute A. Authentication system 706 authenticates resource request 716 based at least on the encrypted version of attribute A and the proof included in resource request 716. Authentication system 706 verifies that the access criteria of policy A have been met and sends resource request 718 to data center 708 requesting encrypted resource 710. Authentication system 706 receives a response 720 including encrypted resource 710 and sends a response 722 including encrypted resource 710 to physical computing device 702. Depending on the implementation, authentication system 706 may decrypt encrypted resource 710, provide physical computing device 702 with an encrypted version of the decryption key for decrypting encrypted resource 710, or otherwise enable physical computing device 702 to access the decrypted version of encrypted resource 710.

[0134] In a second, non-limiting example scenario, the authorization system 704 is associated with the authorizing party 730A, and the encrypted resource 710 is the private data of resident A protected by policy A. However, the entity computing device 702 is the computing device of a malicious user (“Hacker B”) not assigned to area A. For example, suppose in this example, Hacker B has already obtained resident A’s identity credentials. In this example, Hacker B sends a resource request 716 including resident A’s identity requesting access to the encrypted resource 710. In this context, the verification system 706 determines that the encrypted resource 710 is protected by policy A and prompts Hacker B to provide proof indicating that Hacker B owns attribute A. Since Hacker B does not own attribute A (or the unencrypted secret corresponding to attribute A), Hacker B generates a forged proof and provides the forged proof to the verification system 706. The verification system 706 receives the forged proof and obtains the encrypted version of attribute A mapped to resident A’s identity (e.g., in the attribute mapping). Verification system 706 determines that resource request 716 is invalid based on the encrypted version of attribute A and the forged proof (e.g., determining that it does not indicate that hacker B possesses proof of attribute A). In this context, verification system 706 may send a notification to resident A and / or authorized party A (or resident A and / or authorized party A's computing device, application, and / or system) instructing them to attempt to access encrypted resource 710. In this example, access to encrypted resource 710 is blocked.

[0135] In a third non-limiting example scenario, authorization system 704 is associated with authorizing party 730A, encrypted resource 710 is private data of resident A protected by policy A, and entity computing device 702 is the computing device of hacker B who has not been assigned to area A. However, suppose hacker B tampers with the attribute mapping maintained by authorizing party 730A to associate hacker B's identity with attribute A. In this example, verification system 706 (or policy A) requires resource requests to include a digest indicating the state of the ledger database maintaining the attribute mapping. Hacker B sends resource request 716 via entity computing device 702, including hacker B's identity and a digest of the ledger database (e.g., the tampered one). Verification system 706 provides the digest to the ledger database. The ledger database determines that the digest provided in resource request 716 is invalid and has been tampered with. In this context, the ledger database notifies the verification system 706 (e.g., by providing a tampering notification to the verification system 706), and the verification system 706 notifies the authorizing party A that the ledger database maintained by the authorizing party A has been tampered with (e.g., by sending a notification to the authorizing party A's computing device, system, and / or application). In this example, resource request 716 is not verified, and access to encrypted resource 710 is blocked.

[0136] Several example scenarios have been described above regarding system 700, which includes an authentication system implementing a zone-based security policy. However, according to one or more embodiments, an entity physically not located in the first zone attempts to access resources protected by a zone-based security policy of the first zone. Furthermore, the entity may be physically located in a data center storing the resources, which is also located in the second zone. For example, Figure 8 A block diagram of an example system 800 for implementing a region-based security policy for cloud resources, according to another example embodiment, is shown. Figure 8 As shown, system 800 includes physical computing device 802, authorization system 804, authentication system 806, and data center 808. Physical computing device 802 operates in a manner similar to physical computing device 134A and / or physical computing device 134N, authorization system 804 operates in a manner similar to authorization system 104A, authentication system 806 operates in a manner similar to authentication system 106, and data center 808 operates in a manner similar to data source 812, as referenced above. Figures 1 to 6 Each is described separately. For example... Figure 8 As shown, data center 808 stores encrypted resources 810. System 800 may include, for the sake of simplicity... Figure 8Any additional components not shown (e.g., additional authorization systems, additional entity computing devices, other data sources, policy managers, DB hosts, resource processors, etc., for key management). According to an embodiment, authentication system 706 is a LAP server. According to an embodiment, authentication system 806 is a trusted authentication system (e.g., an authentication system trusted by authorization system 804, used to verify whether the access criteria of the authorizing party's security policy are met, access the decryption key used to decrypt resources protected by such security policy, calculate the decryption key used to decrypt resources protected by such security policy, and / or the decryption key used to decrypt encrypted resources protected by such security policy).

[0137] For example Figure 8 As shown, the authorization system 804 is located in a first region 830A (“region 830A” herein), and the physical computing device 802 and data center 808 are located in a second region 830B (“region 830B” herein). The verification system 806 according to an embodiment is a globally distributed verification system across many regions in a cloud computing platform. According to another embodiment, the verification system 806 is located in region 830A, region 830B, or… Figure 8 For simplicity, this is one of the areas not shown in the diagram. Each of areas 830A and 830B may include additional licensed systems, physical computing devices, and / or data centers, for simplicity. Figure 8 Not shown. Furthermore, embodiments of system 800 may include any number of regions other than and / or replacing regions 730A and / or 830B, in addition to region 830A and / or region 830B. Given the foregoing context, several example scenarios regarding system 800 are described below.

[0138] In a first non-limiting example scenario, the authorization system 804 is associated with a government authorizing entity (“Authorizer 830A”) in region 830A, entity computing device 802 is a computing device belonging to a resident of region 830A (“Resident A”) who has the attribute “Resident of Region 830” (“Attribute A”) and is vacationing in region 830B, and encrypted resource 810 is Resident A’s private data protected by Authorizer 830A’s region-based security policy (“Policy A”). In this scenario, the authorization system 804 sends an update request 812 to the verification system 806. The update request 812 includes a request to update Policy A to restrict access to the resident’s private data in region 830A, so that only entities assigned to region 830A (e.g., entities that have Attribute A or another attribute indicating that an entity is assigned to region 830A) can access the private data. In this context, the authentication system 806 authenticates the update request 812 (e.g., as described with reference to step 304 of FIG3) and updates the policy mapping corresponding to policy A (e.g., as described with reference to step 306 of FIG3). By doing so, the access criteria required to access the encrypted resource 810 are updated in such a way that the encrypted resource 810 is assigned to region 830A, even though the encrypted resource 810 is stored in data center 808 located in region 830B.

[0139] In this first example, suppose resident A wishes to access their private data (e.g., encrypted resource 810). Resident A sends a resource request 816 to authentication system 806, which is a request to access encrypted resource 810 and includes proof that resident A owns attribute A. Authentication system 806 determines a policy (e.g., policy A) to protect encrypted resource 810 and utilizes authentication and verification techniques described elsewhere in this document (e.g., as referenced). Figure 5A Steps 504 to 512 Figure 5B Steps 522 and 524 and / or Figure 6(As described in steps 602 to 606) to determine whether resource request 816 is valid. For example, authentication system 806 accesses an attribute mapping maintained by licensor A, which maps entities in region 830A to attributes assigned by licensor A. In this example, authentication system 806 accesses the attribute mapping to obtain an encrypted version of attribute A. Authentication system 806 authenticates resource request 816 based at least on the encrypted version of attribute A and the proof included in resource request 816. Authentication system 806 verifies that the access criteria of policy A have been met and sends resource request 818 to data center 808 requesting encrypted resource 810. Authentication system 806 receives a response 820 including encrypted resource 810 and sends a response 822 including encrypted resource 810 to physical computing device 802. Depending on the implementation, authentication system 806 may decrypt encrypted resource 810, provide physical computing device 802 with an encrypted version of the decryption key for decrypting encrypted resource 810, or otherwise enable physical computing device 802 to access the decrypted version of encrypted resource 810. In this context, the authentication system 806 is able to authenticate and verify that both resident A and encrypted resource 810 are assigned to zone 830A (and thus meet the access criteria of policy A), even though they are physically located in zone 830B.

[0140] In the second non-limiting example scenario, authorization system 804 is associated with authorizing party 830A, and encrypted resource 810 is private data of resident A protected by policy A. However, entity computing device 802 is the computing device of a malicious user (“peer C”) who has (e.g., physical) access to the (e.g., physical) storage device storing encrypted resource 810. In this context, peer C is not assigned to region A. Although peer C can access the storage device storing encrypted resource 810, peer C cannot decrypt encrypted resource 810 without authentication by verification system 806. In this context, the peer cannot authenticate with verification system 806 because the access criteria of policy A require peer C to prove that peer C possesses attribute A. Therefore, peer C cannot prove that they possess the required attributes to show that they are a resident of region A, and they cannot access the decrypted version of encrypted resource 810.

[0141] In a third, non-restrictive example scenario, suppose that attacker C tampers with an attribute mapping maintained by authorizing party 830A to include the association between attacker C's identity and attribute A. In this scenario, suppose policy A (or authentication system 806, or the ledger database including the attribute mapping) also requires attacker C to provide a digest to authenticate the ledger database. In this context, attacker C sends a resource request 816 to authentication system 806, which includes a digest of the tampered ledger database. Authentication system 806 provides the digest to the ledger database (e.g., regarding the...). Figure 6The system determines whether the ledger database is valid. In this scenario, the ledger database determines that it has been tampered with and has not provided access to encrypted resource 810 to the attacker C. In this scenario, the verification system 806 can notify the authorized party 830A that the ledger database has been tampered with, as described elsewhere in this document.

[0142] Therefore, the above has already discussed... Figure 7 System 700 and Figure 8 System 800 describes several example embodiments and scenarios for implementing region-based security policies. It should also be understood that similar systems can be used to implement other region-based security policies, as described elsewhere in this document.

[0143] VI. Example Implementations of Mobile Devices and Computer Systems

[0144] As described herein, the described embodiments, together with any circuitry, components and / or sub-components thereof, and the flowcharts / flowcharts (including portions thereof) and / or other embodiments described herein, may be implemented in hardware, or hardware with any combination of software and / or firmware, including computer program code implemented as configured to execute in one or more processors and stored in a computer-readable storage medium, or implemented as hardware logic / circuit, such as being implemented together in a system-on-a-chip (SoC), field-programmable gate array (FPGA), and / or application-specific integrated circuit (ASIC). An SoC may include an integrated circuit chip that includes one or more processors (e.g., microcontrollers, microprocessors, digital signal processors (DSPs), etc.), memory, one or more communication interfaces, and / or additional circuitry and / or embedded firmware for performing its functions.

[0145] The embodiments disclosed herein can be implemented in one or more computing devices, which can be mobile (mobile devices) and / or fixed (fixed devices), and can include any combination of features of such mobile and fixed computing devices. Reference is made below. Figure 9 Examples of computing devices in which embodiments may be implemented are described. Figure 9 A block diagram of an exemplary computing environment 900 including a computing device 902 is shown. The computing device 902 is... Figure 1 Physical computing devices 102A to 102N, licensing systems 104A to 104N, verification system 106, additional physical computing devices 132 and / or physical computing devices 134A to 134N, Figure 7 Physical computing device 702, authorization system 704, verification system 706 and / or data center 708, and / or Figure 8Examples of physical computing device 902, authorization system 804, orchestrator system 806, and / or data center 808, each of which may include one or more components of computing device 902. In some embodiments, computing device 902 is connected to devices outside computing environment 900 via network 904. Figure 9 (Not shown in the image) Communication coupling. Network 904 is... Figure 1 Examples of network 114 include one or more networks, such as a local area network (LAN), a wide area network (WAN), an enterprise network, the Internet, etc., and may include one or more wired and / or wireless components. Network 904 may additionally or alternatively include a cellular network for cellular communications. The computing device 902 is described in detail below.

[0146] Computing device 902 can be any type of computing device. For example, computing device 902 can be a mobile computing device, such as a handheld computer (e.g., a personal digital assistant (PDA)), a laptop computer, or a tablet computer (such as an Apple iPad). TM Hybrid devices, laptops (e.g., Google Chromebooks) TM Provided by Google LLC), netbooks, mobile phones (such as cellular phones, such as those from Apple Inc.) A smart phone that realizes Android TM Operating systems, etc.), wearable computing devices (e.g., including such as...) Glass TM Oculus smart glasses are head-mounted augmented reality and / or virtual reality devices. Facebook Technologies, LLC, etc.) or other types of mobile computing devices. Computing device 902 may alternatively be a fixed computing device, such as a desktop computer, personal computer (PC), fixed server equipment, minicomputer, mainframe, supercomputer, etc.

[0147] like Figure 9As shown, computing device 902 includes various hardware and software components, including a processor 910, storage device 920, one or more input devices 930, one or more output devices 950, one or more wireless modems 960, one or more wired interfaces 980, power supply 982, location information (LI) receiver 984, and accelerometer 986. Storage device 920 includes memory 956 and storage device 990, with memory 956 including non-removable memory 922 and removable memory 924. Storage device 920 also stores operating system 912, applications 914, and application data 916. Wireless modem 960 includes Wi-Fi modem 962, Bluetooth modem 964, and cellular modem 966. Multiple output devices 950 include speakers 952 and a display 954. Multiple input devices 930 include a touchscreen 932, microphone 934, camera 936, physical keyboard 938, and trackball 940. Figure 9 All components of the computing device 902 shown are present in all embodiments, and additional components (not shown) may be present, and any combination of components may be present in a particular embodiment. These components of the computing device 902 are described below.

[0148] A single processor 910 (e.g., a central processing unit (CPU), microcontroller, microprocessor, signal processor, ASIC (Application-Specific Integrated Circuit), and / or other physical hardware processor circuitry) or multiple processors 910 may exist in the computing device 902 for performing tasks such as program execution, signal encoding, data processing, input / output processing, power control, and / or other functions. The processor 910 may be a single-core or multi-core processor, and each processor core may be single-threaded or multi-threaded (to provide multiple execution threads simultaneously). The processor 910 is configured to execute program code stored in a computer-readable medium, such as the program code of an operating system 912 and application programs 914 stored in memory 920. The operating system 912 controls the allocation and use of components of the computing device 902 and provides support for one or more application programs 914 (also referred to as "applications" or "apps"). Application 914 may include general computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications), additional computing applications (e.g., word processing applications, mapping applications, media player applications, productivity suite applications), one or more machine learning (ML) models, and applications related to embodiments disclosed elsewhere herein.

[0149] Any component in computing device 902 can communicate with any other component according to its function, although not all connections are shown for ease of illustration. For example, such as Figure 9As shown, bus 906 is a multi-signal-line communication medium (e.g., conductive traces in silicon, metal traces along the motherboard, wires, etc.) that can exist to communicatively couple processor 910 to computing device 902, although in other embodiments, alternative buses, additional buses, and / or one or more individual signal lines may exist to communicatively couple components. Bus 906 represents one or more bus structures of any number of types, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and any of the various processor or local buses using various bus architectures.

[0150] Storage device 920 is a physical storage device that includes one or both of memory 956 and storage device 990, which stores operating system 912, application program 914, and application data 916 according to any distribution. Non-removable memory 922 includes one or more of RAM (Random Access Memory), ROM (Read Only Memory), flash memory, solid-state drive (SSD), hard disk drive (e.g., a disk drive for reading from and writing to a hard disk), and / or other physical storage device types. Non-removable memory 922 may include main memory and may be separate from processor 910 or incorporated into the same integrated circuit as processor 910. Figure 9 As shown, non-removable memory 922 stores firmware 918, which may be present to provide low-level control over the hardware. Examples of firmware 918 include BIOS (Basic Input / Output System, such as in a personal computer) and boot firmware (e.g., in a smartphone). Removable memory 924 may be inserted into a socket of computing device 902 or otherwise coupled to computing device 902 and may be removed by a user from computing device 902. Removable memory 924 may include any suitable type of removable memory device, including SD (Secure Digital) cards, Subscriber Identity Module (SIM) cards well known in GSM (Global System for Mobile Communications) communication systems, and / or other types of removable physical memory devices. One or more of storage devices 990 may be present inside and / or outside the housing of computing device 902 and may be removable or non-removable. Examples of storage devices 990 include hard disk drives, SSDs, thumb drives (e.g., USB (Universal Serial Bus) flash drives), or other physical storage devices.

[0151] One or more programs may be stored in storage device 920. Such programs include operating system 912, one or more application programs 914, and other program modules and program data. Examples of such applications may include, for example, computer program logic (e.g., computer program code / instructions) for implementing authentication system 106, DB host 108, policy manager 110, data source 112, entity application 116A, authorization application 120A, ledger database 124, resource processor 230, policy validator 232, proof authenticator 234, identity map 236, attribute map 238, policy map 240, proof generator 242, attribute assigner 244, proof generator 248, key manager 284, proof requester 290, proof generator 448, authentication system 706, authentication system 806, and any of their components and / or subcomponents, as well as flowcharts / flowcharts described herein (e.g., flowcharts 300, 310, 500, 520, 530, 540 and / or 600), including portions thereof, and / or one or more of other examples described herein.

[0152] Storage device 920 also stores data used and / or generated by operating system 912 and application 914 as application data 916. Examples of application data 916 include web pages, text, images, tables, sound files, video data, and other data, which may be sent to and / or received from one or more network servers or other devices via one or more wired or wireless networks. Storage device 920 may be used to store other data including user identifiers, such as International Mobile Subscriber Identity (IMSI), and device identifiers, such as International Mobile Equipment Identity (IMEI). Such identifiers may be sent to network servers to identify users and devices.

[0153] Users can input commands and information to computing device 902 through one or more input devices 930, and receive information from computing device 902 through one or more output devices 950. Input devices 930 may include one or more of a touchscreen 932, microphone 934, camera 936, physical keyboard 938, and / or trackball 940, and output devices 950 may include one or more of a speaker 952 and display 954. Each of the input devices 930 and output devices 950 may be integrated into computing device 902 (e.g., built into the housing of computing device 902) or external to computing device 902 (e.g., wired or wirelessly coupled to computing device 902 via wired interface 980 and / or wireless modem 960). Additional input devices 930 (not shown) may include natural user interfaces (NUIs), pointing devices (computer mice), joysticks, video game controllers, scanners, touchpads, styluses, voice recognition systems for receiving voice input, gesture recognition systems for receiving gesture input, etc. Other possible output devices (not shown) may include piezoelectric or other tactile output devices. Some devices may provide more than one input / output function. For example, display 954 may display information and be operated as touchscreen 932 as a user interface by receiving user commands and / or other information (e.g., via touch, finger gestures, virtual keyboard, etc.). Any number of each type of input device 930 and output device 950 may be present, including multiple microphones 934, multiple cameras 936, multiple speakers 952, and / or multiple displays 954.

[0154] One or more wireless modems 960 may be coupled to one or more antennas (not shown) of computing device 902 and may support bidirectional communication between processor 910 and devices external to computing device 902 via network 904, as will be understood by those skilled in the art. Wireless modems 960 are generally shown and may include cellular modems 966 for communicating with one or more cellular networks, such as GSM networks, for data and voice communication within a single cellular network, between cellular networks, or between a mobile device and the Public Switched Telephone Network (PSTN). Wireless modems 960 may also, or alternatively, include other radio-based modem types, such as Bluetooth modem 964 (also referred to as a “Bluetooth device”) and / or Wi-Fi modem 962 (also referred to as a “wireless adapter”). Wi-Fi modem 962 is configured to communicate with an access point or other remotely Wi-Fi-enabled device according to one or more wireless network protocols based on the IEEE (Institute of Electrical and Electronics Engineers) 802.11 family of standards, which are commonly used for local area network and internet access for devices. The Bluetooth Modem 964 is configured to communicate with other Bluetooth-enabled devices in accordance with Bluetooth short-range wireless technology standards such as IEEE 802.15.1 and / or managed by the Bluetooth Special Interest Group (SIG).

[0155] The computing device 902 may also include a power supply 982, an L1 receiver 984, an accelerometer 986, and / or one or more wired interfaces 980. Example wired interfaces 980 include a USB port, an IEEE 1394 (FireWire) port, an RS-232 port, an HDMI (High-Definition Multimedia Interface) port (e.g., for connecting to an external display), a DisplayPort port (e.g., for connecting to an external display), an audio port, an Ethernet port, and / or... The purpose and function of each wired interface of the port(s) are well known to those skilled in the art. The wired interfaces(s) 980 of the computing device 902 provide a wired connection between the computing device 902 and the network 904, or a wired connection between the computing device 902 and one or more devices / peripherals (e.g., a pointing device, a display 954, a speaker 952, a camera 936, a physical keyboard 938, etc.) when the computing device 902 is external to these devices / peripherals. The power supply 982 is configured to supply power to each component of the computing device 902 and may receive power from a battery inside the computing device 902 and / or from a power cord plugged into a power port (e.g., a USB port, an A / C power port) of the computing device 902. The L1 receiver 984 may be used for location determination of the computing device 902 and may include a satellite navigation receiver such as a Global Positioning System (GPS) receiver, or may include other types of location determiners configured to determine the location of the computing device 902 based on received information (e.g., using cellular triangulation, etc.). An accelerometer 986 may be present to determine the orientation of the computing device 902.

[0156] Note that the components shown in computing device 902 are not essential or all-inclusive, and as those skilled in the art will recognize, fewer or more components may be present. For example, computing device 902 may also include one or more of a gyroscope, barometer, proximity sensor, ambient light sensor, digital compass, etc. Processor 910 and memory 956 may coexist in the same semiconductor device package, such as being included together in an integrated circuit chip, FPGA, or system-on-a-chip (SOC), optionally along with other components of computing device 902.

[0157] In this embodiment, computing device 902 is configured to implement any of the features described above in the flowcharts herein. Computer program logic for performing any of the operations, steps, and / or functions described herein may be stored in storage device 920 and executed by processor 910.

[0158] In some embodiments, server infrastructure 970 may reside within computing environment 900 and may be communicatively coupled to computing device 902 via network 904. Server infrastructure 970, when present, may be a set of network-accessible servers (e.g., a cloud computing platform). Figure 9 As shown, server infrastructure 970 includes cluster 972. Each cluster in cluster 972 may include a group of one or more compute nodes and / or a group of one or more storage nodes. For example, as Figure 9As shown, cluster 972 includes nodes 974. Each node in node 974 can be accessed via network 904 (e.g., in a “cloud computing platform” or “cloud-based” embodiment) to build, deploy, and manage applications and services. Any node in node 974 can be a storage node comprising multiple physical storage disks, SSDs, and / or other physical storage devices accessible via network 904 and configured to store data associated with applications and services managed by node 974. For example, as Figure 9 As shown, node 974 can store application data 978.

[0159] Each node in node 974 may serve as a computing node, including one or more server computers, server systems, and / or computing devices. For example, node 974 may include one or more components of the computing device 902 disclosed herein. Each node in node 974 may be configured to execute one or more software applications (or "applications") and / or services and / or manage hardware resources (e.g., processors, memory, etc.) that can be utilized by users (e.g., clients) of a network-accessible set of servers. For example, as... Figure 9 As shown, node 974 can manipulate application data 976. In the implementation, nodes in node 974 can operate on or include one or more virtual machines, where each virtual machine emulates a system architecture (e.g., an operating system) in an isolated manner, on which applications such as application 976 can be executed.

[0160] In embodiments, one or more of clusters 972 may coexist (e.g., housed in one or more nearby buildings with associated components such as backup power, redundant data communications, and environmental controls) to form a data center, or may be otherwise arranged. Therefore, in embodiments, one or more of clusters 972 may be data centers within a distributed collection of data centers. In embodiments, exemplary computing environment 900 includes Amazon Web Services (AWS) from companies such as Amazon Web Services, Inc. ) or Google Cloud Platform, Inc. (Google LLC) TM However, these are just examples and not intended to be restrictive.

[0161] In this embodiment, computing device 902 can access application 976 to execute in any manner, such as via a client application and / or browser at computing device 902. Example browsers include those developed by Microsoft Corporation of Redmond, Washington. Mozilla, developed by the Mozilla Corporation of Mountain View, California Developed by Apple Inc. in Cupertino, California And developed by Google in Mountain View, California Chrome.

[0162] For network (e.g., cloud) backup and data security purposes, computing device 902 may additionally and / or alternatively synchronize copies of application 914 and / or application data 916, which are to be stored as application 976 and / or application data 978 at a network-based server infrastructure 970. For example, operating system 912 and / or application 914 may include a file hosting service client, such as Microsoft's... Amazon Simple Storage Service (Amazon S3) is a product of Amazon Web Services. Dropbox Google Drive TM etc., which are configured to synchronize applications and / or data stored in memory 920 at network-based server infrastructure 970.

[0163] In some embodiments, the local server 992 may reside within the computing environment 900 and may be communicatively coupled to the computing device 902 via a network 904. When the local server 992 is present, it is hosted within the organization's infrastructure and, in many cases, physically located on-site at the organization's facilities. The local server 992 is controlled, managed, and maintained by the organization's IT (information technology) personnel or the organization's IT partners. Application data 998 can be shared by a local server 992 among the organization's computing devices (including computing device 902, when it is part of the organization) via the organization's local network and / or other networks accessible to the organization (including the Internet). Furthermore, the local server 992 can provide applications such as application 996 to the organization's computing devices, including computing device 902. Therefore, the local server 992 can include a storage device 994 (which includes one or more physical storage devices such as storage disks and / or SSDs) for storing application 996 and application data 998, and can include one or more processors for executing application 996. Further, computing device 902 can be configured to synchronize copies of application 914 and / or application data 916 so that they are stored at the local server 992 as backups of application 996 and / or application data 998.

[0164] The embodiments described herein can be implemented in one or more of computing device 902, network-based server infrastructure 970, and local server 992. For example, in some embodiments, computing device 902 can be used to implement the systems, clients, or devices or their components / subcomponents disclosed elsewhere herein. In other embodiments, a combination of computing device 902, network-based server infrastructure 970, and / or local server 992 can be used to implement the systems, clients, or devices or their components / subcomponents disclosed elsewhere herein.

[0165] As used herein, the terms “computer program medium,” “computer-readable medium,” and “computer-readable storage medium,” etc., are used to refer to physical hardware media. Examples of such physical hardware media include any hard disk, optical disk, SSD, other physical hardware media such as RAM, ROM, flash memory, digital video disk, zip disk, MEM (microelectronic machine) memory, nanotechnology-based storage devices, and other types of physical / tangible hardware storage media of storage device 920. Such computer-readable media and / or storage media are distinct from and do not overlap with communication media and propagation signals (excluding communication media and propagation signals). Communication media embody computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves. The term “modulated data signal” refers to a signal whose characteristics are set or altered to encode information in the signal. By way of example and not limitation, communication media include wireless media such as acoustic, RF, infrared, and other wireless media, as well as wired media. Embodiments also relate to such communication media that are separate from and do not overlap with embodiments relating to computer-readable storage media.

[0166] As described above, computer programs and modules (including application program 914) can be stored in storage device 920. Such computer programs can also be received via network 904 through wired interfaces 980 and / or wireless modems 960. When executed or loaded by an application program, such computer programs enable computing device 902 to implement the features of the embodiments discussed herein. Therefore, such computer programs represent the controller of computing device 902.

[0167] The embodiments also relate to computer program products including computer code or instructions stored on any computer-readable medium or computer-readable storage medium. Such computer program products include physical storage devices of storage device 920 and other types of physical storage devices.

[0168] VII. Additional Exemplary Examples

[0169] This document describes a system. The system includes processor circuitry and memory. The memory stores program code that, when executed by the processor circuitry, performs operations. The operations include receiving a resource request from an entity to access an encrypted resource. The operations also include determining that the encrypted resource is allocated to a first zone and protected by a zone-based security policy. The operations further include receiving proof of a zone attribute from the entity. The proof indicates that the entity possesses the zone attribute. The zone attribute indicates that the entity is associated with the first zone. The operations also include retrieving an encrypted attribute from a ledger database. The encrypted attribute is an encrypted version of the zone attribute. The operations also include authenticating the resource request based at least on the proof of the encrypted attribute and the zone attribute. The operations also include verifying that access criteria of the zone-based security policy are met. The operations also include granting the entity access to the encrypted resource.

[0170] In one implementation of the aforementioned system, the encrypted resources are stored in a data center located in a second region separate from the first region.

[0171] In one implementation of the aforementioned system, the first region is the first country, entities are associated with the first country, and the second region is the second country.

[0172] In one implementation of the aforementioned system, an entity is located in a first region, is a resident of the first region, is an organization headquartered in the first region, is a service assigned to the first region, or is a government entity of the first region.

[0173] In one implementation of the aforementioned system, proof of the region attribute is included in the resource request.

[0174] In one implementation of the aforementioned system, receiving proof of the region attribute from the entity includes: sending a proof request to a computing device associated with the entity, the proof request prompting the entity to provide proof of the region attribute; and receiving a response from the computing device associated with the entity, the response including proof of the region attribute.

[0175] In one implementation of the aforementioned system, the system includes a trusted verification system authorized by an licensor in a first region to perform the verification based on the access criteria of the region's security policy being met.

[0176] In one implementation of the aforementioned system, the operation further includes receiving a digest representing the state of the ledger database. The acquisition of the cryptographic attributes includes: authenticating the ledger database at least based on the digest; and receiving a response from the ledger database including the cryptographic attributes.

[0177] In one implementation of the aforementioned system, authentication requests are made without decrypting encrypted attributes.

[0178] In one implementation of the aforementioned system, providing an entity with access to the encrypted resource includes decrypting the encrypted resource and providing the decrypted resource to the entity.

[0179] In one implementation of the aforementioned system, providing an entity with access to encrypted resources includes providing the entity with a decryption key for decrypting the resources.

[0180] In one implementation of the aforementioned system, providing an entity with access to encrypted resources includes authorizing a resource processor to decrypt the resources and providing the decrypted resources to the entity.

[0181] In one implementation of the aforementioned system, the encrypted resource is associated with a user associated with a first region. The operation also includes receiving a storage request from a computing device on behalf of the user, the storage request including the encrypted resource; verifying the user's association with the first region; allocating the encrypted resource to the first region; and storing the encrypted resource.

[0182] In one implementation of the aforementioned system, determining that the encrypted resource is allocated to a first region and protected by a region-based security policy includes determining that the encrypted resource is encrypted with an encryption key based on the region-based security policy.

[0183] This document also discloses a computer-implemented method. The computer-implemented method includes: receiving a resource request from an entity to access an encrypted resource; determining that the encrypted resource is allocated to a first zone and protected by a zone-based security policy; receiving proof of a zone attribute from the entity, the proof indicating that the entity possesses the zone attribute, the zone attribute indicating that the entity is associated with the first zone; retrieving an encrypted attribute from a ledger database, the encrypted attribute being an encrypted version of the zone attribute; authenticating the resource request based at least on the proof of the encrypted attribute and the zone attribute; verifying that the access criteria of the zone-based security policy are met; and granting the entity access to the encrypted resource.

[0184] In one implementation of the aforementioned computer-based method, the encrypted resources are stored in a data center located in a second region separate from the first region.

[0185] In one implementation of the aforementioned computer-based method, the first region is the first country, the entity is associated with the first country, and the second region is the second country.

[0186] In one implementation of the aforementioned computer-based method, the entity is located in a first region, the entity is a resident of the first region, the entity is an organization headquartered in the first region, the entity is a service assigned to the first region, or the entity is a government entity of the first region.

[0187] In one implementation of the aforementioned computer-based method, proof of the region attribute is included in the resource request.

[0188] In one implementation of the aforementioned computer-based method, receiving proof of a region attribute from an entity includes: sending a proof request to a computing device associated with the entity, the proof request prompting the entity to provide proof of the region attribute; and receiving a response from the computing device associated with the entity, the response including proof of the region attribute.

[0189] In one implementation of the aforementioned computer-based method, the verification of the access criteria for a region based on the region's security policy being met includes: the verification access criteria being met by a verification system trusted by the authorizing party of the first region.

[0190] In one implementation of the aforementioned computer-based method, the method further includes receiving a digest representing the state of the ledger database. The acquisition of the cryptographic attributes includes: authenticating the ledger database at least based on the digest; and receiving a response from the ledger database including the cryptographic attributes.

[0191] In one implementation of the aforementioned computer-based method, the authentication request is made without decrypting the encrypted attributes.

[0192] In one implementation of the aforementioned computer-based method, providing access to the encrypted resource to the entity includes: decrypting the encrypted resource and providing the decrypted resource to the entity; providing access to the encrypted resource to the entity includes providing the entity with a decryption key for decrypting the resource; or authorizing a resource processor to decrypt the resource and provide the decrypted resource to the entity.

[0193] In one implementation of the aforementioned computer-based method, the encrypted resource is associated with a user associated with a first region. The method further includes: receiving a storage request from a computing device on behalf of the user, the storage request including the encrypted resource; verifying the association between the user and the first region; allocating the encrypted resource to the first region; and storing the encrypted resource.

[0194] In one implementation of the aforementioned computer-based method, determining that the encrypted resource is allocated to a first region and protected by a region-based security policy includes determining that the encrypted resource is encrypted with an encryption key of the region-based security policy.

[0195] This document also describes a computer-readable storage medium on which program instructions are recorded. When executed by processor circuitry, the program instructions are executed in a method. The method includes: receiving a resource request from an entity to access an encrypted resource; determining that the encrypted resource is allocated to a first region and protected by a region-based security policy; receiving proof of a region attribute from the entity, the proof indicating that the entity possesses the region attribute, the region attribute indicating that the entity is associated with the first region; retrieving an encrypted attribute from a ledger database, the encrypted attribute being an encrypted version of the region attribute; authenticating the resource request based at least on the proof of the encrypted attribute and the region attribute; verifying that the access criteria of the region-based security policy are met; and granting the entity access to the encrypted resource.

[0196] In one implementation of the aforementioned computer-readable storage medium, the encrypted resources are stored in a data center located in a second region separate from the first region.

[0197] In one implementation of the aforementioned computer-readable storage medium, the first region is a first country, the entity is associated with the first country, and the second region is a second country.

[0198] In one implementation of the aforementioned computer-readable storage medium, the entity is located in a first region, the entity is a resident of the first region, the entity is an organization headquartered in the first region, the entity is a service assigned to the first region, or the entity is a government entity of the first region.

[0199] In one implementation of the aforementioned computer-readable storage medium, proof of the region attribute is included in the resource request.

[0200] In one implementation of the aforementioned computer-readable storage medium, receiving proof of a region attribute from an entity includes: sending a proof request to a computing device associated with the entity, the proof request prompting the entity to provide proof of the region attribute; and receiving a response from the computing device associated with the entity, the response including proof of the region attribute.

[0201] In one implementation of the aforementioned computer-readable storage medium, the verification of the access criteria for a region based on the region security policy being met includes: the verification access criteria being met by a verification system trusted by the authorizing party of the first region.

[0202] In one implementation of the aforementioned computer-readable storage medium, the method further includes receiving a digest representing the state of the ledger database. The acquisition of the cryptographic attributes includes: authenticating the ledger database at least based on the digest; and receiving a response from the ledger database including the cryptographic attributes.

[0203] In one implementation of the aforementioned computer-readable storage medium, the request is authenticated without decrypting the encrypted attributes.

[0204] In one implementation of the aforementioned computer-readable storage medium, providing access to the encrypted resource to the entity includes: decrypting the encrypted resource and providing the decrypted resource to the entity; providing the entity with a decryption key for decrypting the resource; or authorizing a resource processor to decrypt the resource and providing the decrypted resource to the entity.

[0205] In one implementation of the aforementioned computer-readable storage medium, the encrypted resource is associated with a user associated with a first region. The method further includes: receiving a storage request from a computing device on behalf of the user, the storage request including the encrypted resource; verifying the association between the user and the first region; allocating the encrypted resource to the first region; and storing the encrypted resource.

[0206] In one implementation of the aforementioned computer-readable storage medium, determining that the encrypted resource is allocated to a first region and protected by a region-based security policy includes determining that the encrypted resource is encrypted with an encryption key of the region-based security policy.

[0207] VIII. Conclusion

[0208] References to "an embodiment," "embodiment," "example embodiment," etc., in the specification indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may not necessarily include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Additionally, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is believed that the influence of such feature, structure, or characteristic on other embodiments is within the knowledge of those skilled in the art, whether explicitly described or not.

[0209] In this discussion, unless otherwise stated, adjectives describing conditions or relational characteristics that modify one or more features of an implementation of this disclosure should be understood to mean that the condition or characteristic is limited to operational tolerances acceptable for the implementation of its intended application. Furthermore, if the execution of an operation is described herein as "in response to" one or more factors, it should be understood that the one or more factors can be considered as the sole contributing factor to causing the operation to occur, or as contributing factors together with one or more additional factors to cause the operation to occur, and the operation can occur at or after the one or more factors are established. Moreover, in the use of "based on" to indicate that an effect is a result of the indicated cause, it should be understood that the effect need not be caused solely by the indicated cause, but any number of possible additional causes may also contribute to the effect. Therefore, as used herein, the term "based on" should be understood as equivalent to the term "at least based on".

[0210] Numerous exemplary embodiments have been described above. Any section / subsection headings provided herein are not intended to be limiting. Embodiments are described throughout this document, and any type of embodiment may be included under any section / subsection. Furthermore, embodiments disclosed in any section / subsection may be combined in any manner with any other embodiments described in the same and / or different sections / subsections.

[0211] Furthermore, example embodiments have been described above with respect to one or more running examples. Such running examples describe one or more specific implementations of the example embodiments; however, the embodiments described herein are not limited to these specific implementations.

[0212] Furthermore, according to the described embodiments and techniques, any component and function of the system, computing device, verification system, ledger database, resource processor, policy validator, proof authenticator, key manager, policy manager, attribute assigner and / or proof generator can be activated for its operation / execution based on other operations, functions, actions, etc., including the initialization, completion and / or execution of operations, functions, actions, etc.

[0213] In some example embodiments, one or more operations of the flowchart described herein may not be performed. Furthermore, operations other than those of the flowchart described herein, or operations that replace the flowchart described herein, may be performed. Additionally, in some example embodiments, one or more operations of the flowchart described herein may be performed out of order, in an alternative order, or partially (or completely) concurrently with each other or with other operations.

[0214] The embodiments described herein and / or any other systems, subsystems, devices and / or components disclosed herein may be implemented in hardware (e.g., hardware logic / circuit) or any combination of hardware and software (computer program code configured to execute in one or more processors or processing devices) and / or firmware.

[0215] While various embodiments have been described above, it should be understood that they have been presented by way of example only and not as limitations. It will be apparent to those skilled in the art that various changes in form and detail can be made therein without departing from the spirit and scope of the embodiments. Therefore, the breadth and scope of the embodiments should not be limited by any of the exemplary embodiments described above, but should be defined only by the appended claims and their equivalents.

Claims

1. A system (100, 200, 400, 706, 806, 900), comprising: Processor circuit (910); as well as Memory (924, 956, 974, 994) stores program code (914, 976, 996), which performs operations when executed by the processor circuit (910), the operations including: Receive resource request (446,716,816) from entity (134N,702,802) to access encrypted resource (126,710,810); It is determined that the encrypted resources (126, 710, 810) are allocated to the first region (130A, 730A, 830A) and protected by the region-based security policy (128); Receive proof of a region attribute from the entity (134N,702,802), the proof indicating that the entity (134N,702,802) possesses the region attribute, the region attribute indicating that the entity (134N,702,802) is associated with the first region (130A,730A,830A); Obtain the encrypted attribute from the ledger database (224), the encrypted attribute being an encrypted version of the region attribute; The resource request (446,716,816) is authenticated based at least on the proof of the encryption attribute and the region attribute; Verify that the access criteria of the region-based security policy (128) are met; and Provide the entity (134N,702,802) with access to the encrypted resource (126,710,810).

2. The system of claim 1, wherein the encrypted resources are stored in a data center located in a second region separate from the first region.

3. The system of claim 2, wherein the first region is a first country, the entity is associated with the first country, and the second region is a second country.

4. The system of claim 1, wherein the region attribute indicates at least one of the following: The entity is located in the first region; The entity is a resident of the first area; The entity is an organization headquartered in the first region; The entity is a service assigned to the first region; or The entity in question is a government entity in the first region.

5. The system of claim 1, wherein providing access to the encrypted resource to the entity comprises: Provide the entity with a decryption key for decrypting the resource.

6. The system of claim 1, wherein the system includes a trusted verification system authorized by an licensor in the first region to perform the verification that the access criteria of the region-based security policy are met.

7. The system according to claim 1, wherein: The encrypted resources are associated with the users associated with the first region; as well as The operation also includes: The user receives a storage request from a computing device, the storage request including the encrypted resources; Verify that the user is associated with the first region; Allocate the encrypted resources to the first region; and Store the encrypted resources.

8. A computer-implemented method (500), comprising: Receive a resource request (502) from the entity to access encrypted resources; Determine that the encrypted resource is allocated to a first region and protected by a region-based security policy (504); Receive a proof of a region attribute from the entity, the proof indicating that the entity possesses the region attribute, the region attribute indicating that the entity is associated with the first region (506); Obtain the encrypted attribute from the ledger database, the encrypted attribute being an encrypted version of the region attribute (508); The resource request is authenticated at least based on the proof of the encryption attribute and the region attribute (510); Verify that the access criteria of the region-based security policy are met (512); as well as Provide the entity with access to the encrypted resource (514).

9. The method of claim 8, wherein the encrypted resources are stored in a data center located in a second region separate from the first region.

10. The computer-implemented method of claim 9, wherein the first region is a first country, the entity is associated with the first country, and the second region is a second country.

11. The computer-implemented method of claim 8, wherein the region attribute indicates at least one of the following: The entity is located in the first region; The entity is a resident of the first area; The entity is an organization headquartered in the first region; The entity is a service assigned to the first region; or The entity in question is a government entity in the first region.

12. The computer-implemented method of claim 8, wherein the proof of the region attribute is included in the resource request.

13. The computer-implemented method of claim 8, wherein receiving the proof of the region attribute from the entity comprises: A proof request is sent to the computing device associated with the entity, the proof request prompting the entity to provide proof of the region attribute; as well as A response is received from the computing device associated with the entity, the response including the proof of the region attribute.

14. The computer-implemented method of claim 8, wherein satisfying the access criteria for the region based on the region-based security policy includes: The access criteria are verified to be met by an authentication system trusted by the authorizing party in the first region.

15. The computer-implemented method of claim 8, wherein the request is verified without decrypting the encryption attribute.

16. The computer-implemented method of claim 8, wherein providing access to the encrypted resource to the entity comprises one of the following: Decrypt the encrypted resource and provide the decrypted resource to the entity; Provide the entity with a decryption key for decrypting the resource; or The authorized resource processor decrypts the resource and provides the decrypted resource to the entity.

17. The computer-implemented method according to claim 8, wherein: The encrypted resources are associated with the users associated with the first region; as well as The method further includes: The user receives a storage request from a computing device, the storage request including the encrypted resources; Verify that the user is associated with the first region; Allocate the encrypted resources to the first region; and Store the encrypted resources.

18. The computer-implemented method of claim 8, wherein determining that the encrypted resource is allocated to a first region and protected by a region-based security policy comprises: It is determined that the encrypted resource is encrypted with the encryption key of the region-based security policy.

19. A computer-readable storage medium (920, 974, 994) having program instructions (914, 976, 996) recorded thereon, which, when executed by a processor circuit (910), performs a method (500), the method (500) comprising: Receive a resource request (502) from the entity to access encrypted resources; Determine that the encrypted resource is allocated to a first region and protected by a region-based security policy (504); Receive a proof of a region attribute from the entity, the proof indicating that the entity possesses the region attribute, the region attribute indicating that the entity is associated with the first region (506); Obtain the encrypted attribute from the ledger database, the encrypted attribute being an encrypted version of the region attribute (508); The resource request is authenticated at least based on the proof of the encryption attribute and the region attribute (510); Verify that the access criteria of the region-based security policy are met (512); as well as Provide the entity with access to the encrypted resource (514).

20. The computer-readable storage medium of claim 19, wherein determining that the encrypted resource is allocated to a first region and protected by a region-based security policy comprises: Determine that the encrypted resource is encrypted with the encryption key of the region-based security policy; as well as Providing the entity with access to the encrypted resource includes one of the following: Decrypt the encrypted resource and provide the decrypted resource to the entity. Provide the entity with a decryption key for decrypting the resource, or The authorized resource processor decrypts the resource and provides the decrypted resource to the entity.

Images