Abstract: Embodiments described herein enable at least one of a plurality of entities to access data protected by a security policy in response to validating respective digital access requests from the entities. The respective digital access requests are received, each comprising a proof. For each request, an encrypted secret share is obtained from a respective ledger database. Each request is validated based at least on the respective encrypted secret share and the proof, without decrypting the respective encrypted secret share. In response to validating all of the requests, a verification that an access criteria of a security policy is met is made. If so, at least one of the entities is provided with access to data protected by the security policy. In an aspect, embodiments enable a blind subpoena to be performed. In another aspect, embodiments enable the at least one entity to access the data for an isolated purpose.

Abstract: An access control system is disclosed for controlling access to a resource. A request is received by a location attribute policy (LAP) server to access an encrypted resource. The LAP server accesses a resource policy that identifies requirements for granting access to the encrypted resource, such as a list of attributes of the requestor that are required and a dynamic attribute requirement of the requestor. The LAP server receives a cryptographic proof from the computing device that the requestor possesses the attributes and validates the proof based at least on information obtained from a trusted ledger. Once the proof is validated, the LAP server provides a shared secret associated with the dynamic attribute requirement to a decryption algorithm. The decryption algorithm uses the dynamic attribute shared secret in combination with one or more attribute shared secrets from the requestor to generate a decryption key for the encrypted resource.

Abstract: A decryption key is recovered that is utilized to decrypt an encrypted resource. For example, a determination is made as to whether a user and/or the user's computing device attempting to access an encrypted resource has the necessary attributes to access the resource and/or is in a valid location in which the user is required to be to access the resource. The attributes and/or location are defined by a policy assigned to the resource. To verify that the user has the required attributes, a proof is requested from the user that proves that the user has the required attributes. Upon validating the proof, the decryption key is generated and/or retrieved.

Abstract: Verifiable attribute maps that maintain references to identities and attribute information associated with the identities are disclosed. A verifiable attribute map is maintained by a ledger database that provides tamper-resistant/evident capabilities for tables (comprising the map) thereof. For instance, when a materialized view of the database is generated, the database provides a digest representative of a state thereof to computing devices that access the map for the attribute information. When the database receives a request from a device to access the map, the digest is received along therewith. The database is validated based on the digest to determine whether the database has been tampered with since the provision of the digest. Responsive to a successful validation, the database provides access in accordance with the request. When attribute information in the map is updated, the database subsequently generates a new digest, which is provided to the computing device.

Abstract: A decryption key is recovered that is utilized to decrypt an encrypted resource. One or more location attribute policy (LAP) servers determine whether a user attempting to access a resource has the necessary attributes to access the resource and is in a valid location in which the user is required to be to access the resource. The attributes and location are defined by a policy assigned to the resource. To verify that the user has the required attributes, the LAP server(s) request a cryptographic proof from the user that proves that the user has the required attributes. Upon validating the proof, a first portion of the decryption key is released. The LAP server(s) release a second portion of the decryption key after verifying that the user is in the required location. The LAP server(s) generate the decryption key based on the released portions.

Abstract: Embodiments described herein are directed to a verifiable identity map that maintains identities and public keys associated with the identities. The map is maintained by a ledger database that provides tamper-resistant/evident capabilities for tables (comprising the map) thereof. For instance, when a materialized view of the database is generated, the database provides a digest representative of a state thereof to computing devices that access the map for the keys. When the database receives a request from a device to access the map, the digest is received along therewith. The database is validated based on the digest to determine whether the database has been tampered with since the provision of the digest. Responsive to a successful validation, the database provides access in accordance with the request. When a key in the map is updated, the database subsequently generates a new digest, which is provided to the computing device.

Abstract: Heartbeat consensus forming for the state of a digital ledger built upon a blockchain to provide users with the ability to securely, accurately, and verifiably share state information between distrustful parties is provided herein. The digital ledger is hosted in a networked environment, accessible by multiple parties. Heartbeat transactions allow clients, who are not in direct communication with one another and may distrust one another, to verify the integrity of the digital ledger via consensus. The consensus is readily verifiable by each client on its own machine and allows the ledger to be recovered to an agreed-to state in the event of a fault initiated by a client or the host of the ledger, whether malicious or otherwise. The digital ledger is freely movable to different hosts in the event of a fault.

Abstract: A digital ledger built upon a blockchain to provide users with the ability to securely, accurately, and verifiably share state information between distrustful parties is provided herein. The Verifiable Outsourced Ledger is hosted in a networked environment, accessible by multiple parties, and maintains an immutable view of the transactions submitted by authorized parties and a continuous view of the states shared between the parties that the parties can replicate independently locally to verify the integrity of the ledger.

Abstract: Heartbeat consensus forming for the state of a digital ledger built upon a blockchain to provide users with the ability to securely, accurately, and verifiably share state information between distrustful parties is provided herein. The digital ledger is hosted in a networked environment, accessible by multiple parties. Heartbeat transactions allow clients, who are not in direct communication with one another and may distrust one another, to verify the integrity of the digital ledger via consensus. The consensus is readily verifiable by each client on its own machine and allows the ledger to be recovered to an agreed-to state in the event of a fault initiated by a client or the host of the ledger, whether malicious or otherwise. The digital ledger is freely movable to different hosts in the event of a fault.

Abstract: Heartbeat consensus forming for the state of a digital ledger built upon a blockchain to provide users with the ability to securely, accurately, and verifiably share state information between distrustful parties is provided herein. The digital ledger is hosted in a networked environment, accessible by multiple parties. Heartbeat transactions allow clients, who are not in direct communication with one another and may distrust one another, to verify the integrity of the digital ledger via consensus. The consensus is readily verifiable by each client on its own machine and allows the ledger to be recovered to an agreed-to state in the event of a fault initiated by a client or the host of the ledger, whether malicious or otherwise. The digital ledger is freely movable to different hosts in the event of a fault.

Abstract: Methods, systems, and computer-readable media are directed towards receiving, at an untrusted component, a query for a data store. The query includes a plurality of data operations. The data store is accessible by the untrusted component. A first proper subset of data operations is determined from the plurality of data operations that do not access sensitive data within the data store. A second proper subset of data operations is determined from the plurality of data operations that access sensitive data within the data store. The first proper subset of data operations is executed, at the untrusted component, to create first results. The second proper subset of data operations is sent to a trusted component for execution. Second results based on the sending the second proper subset of data operations are received from the trusted component. Results to the query are returned based on the first results and the second results.

Abstract: Systems and methods described herein relate to secure, efficient, confidential, and/or outsourced blockchain networks, which can enable a group of mutually distrusting participants to securely share state and then agree on a linear history of operations on that shared state.

Abstract: Operating upon encrypted data with a particular data scope. A base encryption key is established and associated with the particular data scope, and then stored in a base encryption key store. That base encryption key store might be managed by an application or service that stores base encryption keys for multiple data scopes. A proxy encryption key acts as a kind of proxy for the base encryption key. The proxy encryption key may be used for frequent operations on encrypted data within the particular data scope. Thus, the principles described herein act as a frequency amplifier that allows key-based operations upon the particular data scope to be performed at much higher frequencies than otherwise would be possible by operating directly using the base encryption key.

Abstract: Heartbeat consensus forming for the state of a digital ledger built upon a blockchain to provide users with the ability to securely, accurately, and verifiably share state information between distrustful parties is provided herein. The digital ledger is hosted in a networked environment, accessible by multiple parties. Heartbeat transactions allow clients, who are not in direct communication with one another and may distrust one another, to verify the integrity of the digital ledger via consensus. The consensus is readily verifiable by each client on its own machine and allows the ledger to be recovered to an agreed-to state in the event of a fault initiated by a client or the host of the ledger, whether malicious or otherwise. The digital ledger is freely movable to different hosts in the event of a fault.

Abstract: Methods, systems, and computer-readable media are directed towards receiving, at an untrusted component, a query for a data store. The query includes a plurality of data operations. The data store is accessible by the untrusted component. A first proper subset of data operations is determined from the plurality of data operations that do not access sensitive data within the data store. A second proper subset of data operations is determined from the plurality of data operations that access sensitive data within the data store. The first proper subset of data operations is executed, at the untrusted component, to create first results. The second proper subset of data operations is sent to a trusted component for execution. Second results based on the sending the second proper subset of data operations are received from the trusted component. Results to the query are returned based on the first results and the second results.

Abstract: A digital ledger built upon a blockchain to provide users with the ability to securely, accurately, and verifiably share state information between distrustful parties is provided herein. The Verifiable Outsourced Ledger is hosted in a networked environment, accessible by multiple parties, and maintains an immutable view of the transactions submitted by authorized parties and a continuous view of the states shared between the parties that the parties can replicate independently locally to verify the integrity of the ledger.

Abstract: Heartbeat consensus forming for the state of a digital ledger built upon a blockchain to provide users with the ability to securely, accurately, and verifiably share state information between distrustful parties is provided herein. The digital ledger is hosted in a networked environment, accessible by multiple parties. Heartbeat transactions allow clients, who are not in direct communication with one another and may distrust one another, to verify the integrity of the digital ledger via consensus. The consensus is readily verifiable by each client on its own machine and allows the ledger to be recovered to an agreed-to state in the event of a fault initiated by a client or the host of the ledger, whether malicious or otherwise. The digital ledger is freely movable to different hosts in the event of a fault.

Abstract: Methods, systems, and computer-readable media are directed towards receiving, at an untrusted component, a query for a data store. The query includes a plurality of data operations. The data store is accessible by the untrusted component. A first proper subset of data operations is determined from the plurality of data operations that do not access sensitive data within the data store. A second proper subset of data operations is determined from the plurality of data operations that access sensitive data within the data store. The first proper subset of data operations is executed, at the untrusted component, to create first results. The second proper subset of data operations is sent to a trusted component for execution. Second results based on the sending the second proper subset of data operations are received from the trusted component. Results to the query are returned based on the first results and the second results.

Abstract: A digital ledger built upon a blockchain to provide users with the ability to securely, accurately, and verifiably share state information between distrustful parties is provided herein. The Verifiable Outsourced Ledger is hosted in a networked environment, accessible by multiple parties, and maintains an immutable view of the transactions submitted by authorized parties and a continuous view of the states shared between the parties that the parties can replicate independently locally to verify the integrity of the ledger.

Abstract: Operating upon encrypted data with a particular data scope. A base encryption key is established and associated with the particular data scope, and then stored in a base encryption key store. That base encryption key store might be managed by an application or service that stores base encryption keys for multiple data scopes. A proxy encryption key acts as a kind of proxy for the base encryption key. The proxy encryption key may be used for frequent operations on encrypted data within the particular data scope.