Microsoft Technology Licensing, LLC

Bell Communications Research, Inc.

Telcordia Technologies, Inc.

Microsoft Corporation

Ramarathnam R Venkatesan

Mariusz Hieronim Jakubowski

M Kivanc Mihcak

Saurabh Sinha

Peter L Montgomery

Yacov Yacobi

Matthew C Cary

Srinath Setty

William A Aiello

Mustafa Kesal

Marcus Peinado

Yuqun Chen

Mehmet Kivanc Mihcak

Nishanth Chandran

Victor V Boyko

Kenneth Hiroshi Eguro

Soumya Basu

Ruoming Pang

Jonathan Alexander Lee

Sumit Gulwani

Ganesh Ananthanarayanan

Ravishankar Ramamurthy

David Jao

Vijay Vazirani

Michael T Malkin

Kristin E Lauter

Kamal Jain

Michael James Zwilling

Gideon Andreas Yuval

Zheng Wang

Roy Peter D'Souza

Donald Kossmann

Panagiotis Antonopoulos

Dan Boneh

Arvind Arasu

Sriram Kottarakurichi Rajamani

Prateek Jain

Baskar Sridharan

Mehmet Kucukgoz

Shriraghav Kaushik

Mitica Manu

Raghunath Ramakrishnan

Sean Blagsvedt

Srivatsan Laxman

Ken B Pierce

Srinath T V Setty

Satyanarayana V Lokam

Pushkar Vijay Chitnis

Manas Rajendra Joglekar

Scott Arthur McFarling

Spyridon Blanas

Saurabh Srivastava

Shastry M C Shankara

Prasang Upadhyaya

Kartik Gupta

Thathachar S Jayram

Ahmed El-Shimi

Yoganand Rajasekaran

Ulrich Homann

Say-Ming William Koon

Mark C Johnson

Sivaramakrishnan Rajagopalan

Bertrand Anckaert

Jin Li

Eric Cohen

Sudipta Sengupta

Ran Kalach

Chad B Rothschiller

Lidong Zhou

Benjamin Zorn

Paul Adrian Oltean

Gary Keith Starkweather

Daniel C Battagin

Perraju Bendapudi

Malcolm Hollis Davis

Rishabh Singh

Omkant Pandey

Rajesh Jalan

Yuanchao Shu

Srinath Tumkur Venkatacha Setty

Dany Rouhana

Ilya Mironov

Harish Mohanan

Kiran Muthabatulla

Victor K Wei

Michael Lowell Roberts

Daniel John Carroll, Jr

Chit Wei Saw

Vipul Goyal

Abishek Kumarasubramanian

Adi Akavia

S Serdar Kozat

Viktor Boyko

S Ramesh Raju

Matt Cary

Christopher Benedict

Rodrigo Moreira-Silveira

Dmitri O Danilov

Sivaramakrishnam Rajagopalan

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.

Verifiable identity map maintaining identities and associated public keys

An entity is enabled to access encrypted resources in response to verifying access criteria of a region-based security policy is met. For example, a resource request to access an encrypted resource is received from an entity. A determination that the encrypted resource is assigned to a first region and is protected by a region-based security policy is made. A proof of a region attribute indicating that the entity possesses the region attribute is received from the entity, the region attribute indicates 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 encrypted attribute and the proof of the region attribute. A verification is made that an access criteria of the region-based security policy is met. The entity is provided access to the encrypted resource.

Region-based security policies for cloud resources

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.

Zero-trust distributed data sharing

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.

Blind subpoena protection

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.

Decryption key generation and recovery

The techniques described herein use an edge device to manage the security for a data stream being ingested by a tenant and a cloud platform. The creation of the data stream for ingestion occurs in an environment that is trusted by a tenant (e.g., an on-premises enterprise network). The cloud platform that is part of the data stream ingestion process is outside this trusted environment, and thus, the tenant loses an element of security when ingesting data streams for cloud storage and/or cloud processing. Accordingly, the edge device is configured on a trust boundary so that the data stream ingestion process associated with a cloud platform is secured, or trusted by the tenant. The edge device is configured to encrypt the data stream using a data encryption key and/or manage the protection of the data encryption key.

Secure data ingestion with edge computing

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.

Heartbeats and consensus in verifiable outsourced ledgers

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.

Verifiable outsourced ledgers

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.

Secure data processing on sensitive data using trusted hardware

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.

Blockchain system for leveraging member nodes to achieve consensus

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.

Data operations using a proxy encryption key

Growing community of inventors

Bellevue, WA, United States of America

Ramarathnam R Venkatesan