Microsoft Technology Licensing, LLC

Other

Kahren Tevosyan

Mark Eugene Russinovich

Brian Scott Lounsberry

Chandan Rama Reddy

Ashok Chandrasekaran

Jeffrey F Spelman

Chetan S Shankar

Donald E Schmidt

Ryan D Johnson

Vyom P Munshi

Chuang Wang

Hervey O Wilson

Sylvan Wesley Clebsch

Manuel Silverio Da Silva Costa

Sandeep Kalarickal

Cédric Alain Marie Christophe Fournet

Vijayavani Nori

Antoine Jean Denis Delignat-lavaud

Matthew Hur

Abhishek Pratap Singh Chauhan

Pavel Zakharov

George M Moore

David R Mowers

Janani Vasudevan

Corey M Sanders

Pavan Gopal Bandla

Thomas Charles Knudson

Ian C Jirka

Cristian Stefan Salvan

Abhinav Bose

Aravind N Thoram

Mohit Srivastava

Krishnanand K Shenoy

Kamran Riaz Khan

Harini Raghavan

David A Matson

Pawel Tomasz Lipiec

Corbin C Rogerson

Harsha Vardhan Sanagaram

Bhuvaneshwari Krishnamurthi

Hieu Trung Nguyen

Mayank Mahajan

Sudhakara Reddy Evuri

Srinivas S Nidadavolu

The disclosed technology is generally directed to code transparency. In one example of the technology, a claim associated with an application is received. The claim is a document that is signed with a claim signature and that includes evidence associated with a policy, and further includes an expected set of at least one binary measurement associated with the application. The evidence is cryptographically verifiable evidence associated with the application. A trusted execution environment (TEE) is used to provide a distributed ledger. The claim is verified. Verifying the claim includes verifying the expected set of at least one binary measurement associated with the application, verifying the claim signature, and, based at least on the evidence, verifying that the application meets the policy. Upon successful verification of the claim, the claim is appended to the distributed ledger. A ledger countersignature associated with the claim is generated.

Code transparency system operation

The disclosed technology is generally directed to code transparency. In one example of the technology, evidence associated with a policy is obtained. The evidence includes data that includes cryptographically verifiable evidence associated with initial source code in accordance with the policy. The initial source code is source code for a CTS. The initial binary is based on the initial source code is executed in a TEE such that a CTS instance begins operation. The CTS instance is configured to register guarantee(s) associated with code approved by the CTS instance. The TEE is used to provide a ledger. The evidence is stored on the ledger. Measurement(s) associated with the binary are provided. A service key associated with CTS instance is generated. TEE attestation of the measurement(s), the evidence, and the service key is provided.

Bootstrapping a code transparency system

Various methods and systems are provided for autonomous orchestration of secrets renewal and distribution. A secrets management service ('SMS') can be utilized to store, renew and distribute secrets in a distributed computing environment. The secrets are initially deployed, after which, SMS can automatically renew the secrets according to a specified rollover policy, and polling agents can fetch updates from SMS. In various embodiments, SMS can autonomously rollover client certificates for authentication of users who access a security critical service, autonomously rollover storage account keys, track delivery of updated secrets to secrets recipients, deliver secrets using a secure blob, and/or facilitate autonomous rollover using secrets staging. In some embodiments, a service is pinned to the path where the service's secrets are stored. In this manner, secrets can be automatically renewed without any manual orchestration and/or the need to redeploy services.

Autonomous secrets renewal and distribution

Methods, systems, and computer storage media for providing access to computing environments based on a multi-environment policy are provided. The a multi-environment policy is configurable to define rules that have provider-controlled and customer-controlled computing environment parameters for approving access to provider-controlled computing environments and customer-controlled computing environments. In operation, a request associated a computing environment are received. The computing environment is associated with a multi-environment policy. The multi-environment policy is configurable to define the rules based on access vectors having grouped computing environment aspects for control and visibility associated with accessing computing environments. Based on the request, a determination whether the request is for a provider-controlled or a customer-controlled computing environment is made. Based on the multi-environment policy, approval-request parameters of an approval-request are communicated to receive approval-request response values. And, based on receiving the approval-request response values, a request response indicating approval or denial of the request is communicated.

Access management system with a multi-environment policy

Various methods and systems are provided for autonomous signing management for a key distribution service ('KDS'). In operation, a key request from a KDS client device is received at a KDS server. The key request is associated with a security token of a signing entity caller or verifying entity caller, and a signature descriptor. The signature descriptor supports signing data with an encryption key and verifying a signature with a decryption key. The signing entity caller or the verifying entity caller is authenticated based on the corresponding security token and signature descriptor. The encryption key or the decryption key associated with the key request is generated. The encryption key or the decryption key is generated based on authenticating using the security token and the signature descriptor. The encryption key or the decryption key is communicated to a KDS client device the KDS client to sign data or decrypt a signature.

Autonomous signing management operations for a key distribution service

Various methods and systems are provided for autonomous orchestration of secrets renewal and distribution across scope boundaries. A cross-scope secrets management service ('SMS') can be utilized to store, renew and distribute secrets across boundaries in a distributed computing environment such as regional boundaries. In some embodiments, locally scoped secrets management services subscribe to receive updates from the cross-scope secrets management service. As secrets are renewed, they are automatically propagated to a subscribing local scope and distributed by the local secrets management service. In various embodiments, SMS can autonomously rollover storage account keys, track delivery of updated secrets to secrets recipients, deliver secrets using a secure blob, and/or facilitate autonomous rollover using secrets staging. In some embodiments, a service is pinned to the path where the service's secrets are stored. In this manner, secrets can be automatically renewed without any manual orchestration and/or the need to redeploy services.

Autonomous cross-scope secrets management

Various methods and systems are provided for autonomous secrets management for a key distribution service ('KDS'). A KDS server performs centralized management and distribution of keys for client devices in a distributed computing system, which obviates key management and distribution at the client devices. In operation, a key request is received at a KDS server from a KDS client device. The key request is generated using a data protector and a KDS client component of the KDS client device. The key request is associated with a caller and a security token of the caller. The caller is authenticated at a security token service (STS) based on a security token. An encryption key or decryption key associated with the key request is generated. The encryption key or the decryption key is generated based on an interval-based key derivation scheme. The encryption key or the decryption key is communicated to KDS client.

Autonomous secrets management for a key distribution service

A compute resource provider system is shown having an encryption agent that obtains a cryptographic key for a virtual machine and sends the cryptographic key to a host agent. The host agent receives the cryptographic key from the encryption agent and stores the received cryptographic key to a user key vault. The host agent generates a key vault secret reference (KVSR) locator pointing to the cryptographic key stored in the user key vault, associates the KVSR with the virtual diskset, and sends a success message to the encryption agent. The encryption agent receives the success message from the host and, responsive thereto, encrypts the virtual diskset using the cryptographic key. Subsequently, another host agent uses the KVSR to obtain the cryptographic key from the key vault and boot the virtual machine with the encrypted virtual diskset.

Encryption at rest for cloud-resourced virtual machines

Aspects of the technology described herein enable a client device to access a web service in a claims-based identity environment thorough an Internet Protocol (IP) address, rather than the web service's domain name service (DNS). In a claims-based identity environment, a client device will authenticate a relying party's server SSL certificate before providing the token to the relying party by following an authentication process. Current authentication processes include a name-chaining operation, which compares a subject field of a token provided with the Uniform Resource Identifier (URI) used to request the resource (e.g., RP application). When the IP address is used as the URI, then the URI in the certificate will not match the URI in the request and the authentication will fail. Accordingly, aspects of the technology use an alternative authentication method that allows access to a web service through an IP address, when the default client-side token validation is DNS-name based.

Relying party certificate validation when client uses relying party's IP address

Various methods and systems are provided for autonomous management for a managed service identity. A first token request, for a secret, is generated at a managed service. The secret supports authenticating the managed service for performing operations in a distributed computing environment. The first token request includes an identity identifier of the managed service. The first token request is communicated to a credentials manager which is associated with a secrets management service ('SMS') that can be utilized to store, renew and distribute secrets in the distributed computing environment. Based on communicating the first token request to credentials manager, the token is received, via the credentials manager, from the secret token service. The token is received based in part on the credentials manager generating a second token request for the token and communicating the second token request and a secret associated with the managed service to the secret token service.

Autonomous secrets management for a managed service identity

Various methods and systems are provided for autonomous secrets management for a temporary shared access signature ('SAS') service. Input for a temporary access request for an account resource, is received from a client. The temporary access request is validated, based on communicating a validation request to the secrets management service ('SMS') that can be utilized to store, renew and distribute secrets in a distributed computing environment. Validating the temporary access request is based on determining a storage account location path for SAS keys that provide temporary access to account resources. An access policy associated with the temporary access request is accessed. An SAS key request, associated with temporary access request, is communicated to the SMS. The SAS key request includes at least a portion of the access policy. An SAS key is received from the SMS. The SAS key, for access to the account resource, is communicated to the client.

Autonomous secrets management for a temporary shared access signature service

Embodiments are directed to establishing separate security identities for a shared service and shared service instances, and to managing shared and service instance credentials. In one scenario, a computer system establishes a shared credential for a shared service that includes multiple shared service instances, where the shared credential uniquely identifies the shared service. The computer system establishes a service instance credential for each shared service instance that uniquely identifies each shared service instance and maintains a relationship between the service instance and the shared service. The relationship provides service instance access to the shared credentials as the shared credentials are updated over time. Then, upon determining that the shared credentials have been updated and are no longer valid, the shared service instance accesses the updated shared credentials using the established relationship.

Managing security credentials for scaled-out services

An invention is described for securely deploying a provable identity for virtual machines (VMs) in a dynamic environment. In an embodiment, a fabric controller instructs a VM host to create a VM and sends that VM a secret. The fabric controller sends that same secret (or a second secret, such as the private key of a public/private key pair) to the security token service along with an instruction to make an account for the VM. The VM presents proof that it possesses the secret to the security token service and in return receives a full token. When a client connects to the deployment, it receives the public key from the security token service, which it trusts, and the full token from the VM. It validates the full token with the public key to determine that the VM has the identity that it purports to have.

Secure deployment of provable identity for dynamic application environments

Systems and methods directed at enhancing the capability of a federated authentication system by configuring the system with extensibility points for adding new account stores and customizing claim transformations. The federated authentication system includes accounts stores, a security token service (STS), and custom claim transformation modules. The account stores are configured to maintain data associated with accounts and to provide security claims in an intermediate format. The STS is configured to retrieve the security claims provided by the account stores and includes built-in transformations for transforming each security claim from the intermediate format to formats associated with resource providers. The STS is further configured to provide extensibility points for custom claim transformations that are not available from the built-in transformations. The custom claim transformation modules are configured to perform at least one custom claim transformation. Each custom claim transformation module is further configured to interact with the STS through at least one of the extensibility points. The STS may be configured to provide extensibility points for interacting with account stores that the STS does not explicitly recognize.

Extensible account authentication system

Growing community of inventors

Kirkland, WA, United States of America

Kahren Tevosyan