Microsoft Technology Licensing, LLC

Amazon Technologies, Inc.

Jamie Hunter

Kenneth D Ray

Paul England

Russell Humphries

Stefan Thom

Jonathan D Schwartz

James Anthony Schwartz, Jr

Marc John Brooker

Eden Grail Adogla

Mukul Vijay Karnik

Antoun Joubran Kanawati

Robert James Hanson

Paul William Berg

John Clark Coonley Duksta

Gary Paul Raden, Ii

Roshith Rajagopal

Eric Jason Brandwine

Gregory Branchek Roth

Bryan M Willman

Carl Melvin Ellison

David Benson Cross

Niels Thomas Ferguson

James George Cavalaris

Thekkthalackal Varugis Kurien

Philip J Lafornara

Santosh Sharad Jodh

Lonny Dean McMichael

Jason T Cobb

Pierre Jacomet

Mark E Paley

Derek Norman LaSalle

Lonnie Dean McMichael

James Anthony Schwartz Jr

A distributed execution environment can provide access to field-programmable device resources. The field-programmable device resources can be provided in association with one or more instances that are instantiated within the distributed execution environment upon request from a computing system. The computing system can be associated with a customer of the distributed execution environment. The customer can program the field-programmable device resources using designs created by or for the customer.

Providing field-programmable devices in a distributed execution environment

Techniques for providing cryptographic keys for encrypted system volumes on machine instances in virtualized and/or distributed systems are described herein. At a time after detecting the requirement for a cryptographic key by a virtual machine instance, one or more computer system entities within a computer system invoke one or more computer system capabilities at least to create one or more virtual hardware devices capable of representing or providing appropriate cryptographic keys. The virtual hardware devices are connected to the machine instance under the control of the computer system so that the encrypted system volumes may be used. After the cryptographic key is no longer needed, it is detached from the machine instance.

Volume cryptographic key management

Systems and methods aggregate data and use caching techniques. In one implementation, a computer-implemented method aggregates data. A server receives a request for data that includes one or more identifiers. Based on at least one of the one or more identifiers, at least one template defining a view of the data is retrieved. One or more modules are identified based on the at least one template and one or more services are invoked to obtain the one or more modules. The one or more modules are received and processing by applying one or more business logic rules. At least a portion of the one or more processed modules are stored in a data store. The view of the data is generated based on the processed one or more modules and a response is transmitted to a client that includes the view of the data.

Data aggregation and caching

Technology is described for performing cache data invalidations. The method may include identifying cache update information at a first cache. The cache update information may identify a cache entry (e.g., a trending cache entry). A second cache may be selected to receive the cache update information from the first cache. The cache update information identifying the cache entry may be sent from the first cache to the second cache. For example, the second cache may be populated by adding the trending cache entry into the second cache.

Cache updating

Access to a storage device, such as a disk, is controlled by performing a disk operation using a single cryptographic engine. Keys associated with each layer of a layered structure associated with controlling access to the storage device are combined. The resultant of this combination is used as the key to the cryptographic engine. Data to be retrieved from and written to the storage device are operated on by the cryptographic engine utilizing the combined key. Keys are combined by combining functions associated with layers of the layered structure. A combining function can include an exclusive or function, a cryptographic hash function, or a combination thereof.

Storage device controlled access

Systems and methods are provided for maintaining and updating a secure boot process on a computer with a trusted platform module (TPM). A boot process may be maintained by inspecting a log of TPM activity, determining data that prevented a secret to unseal, and returning the data to an original state. In situations where this type of recovery is not workable, techniques for authenticating a user may be used, allowing the authenticated user to bypass the security features of the boot process and reseal the boot secrets to platform configuration register (PCR) values that may have changed. Finally, a secure boot process may be upgraded by migrating TPM sealed secrets to a temporary storage location, updating one or more aspects of a secure boot process, and resealing the secrets to the resulting new platform configuration. Other advantages and features of the invention are described below.

Systems and methods for updating a secure boot process on a computer with a hardware security module

In a computer with a trusted platform module (TPM), an expected hash value of a boot component may be placed into a platform configuration register (PCR), which allows a TPM to unseal a secret. The secret may then be used to decrypt the boot component. The hash of the decrypted boot component may then be calculated and the result can be placed in a PCR. The PCRs may then be compared. If they do not, access to the an important secret for system operation can be revoked. Also, a first secret may be accessible only when a first plurality of PCR values are extant, while a second secret is accessible only after one or more of the first plurality of PCR values has been replaced with a new value, thereby necessarily revoking further access to the first secret in order to grant access to the second secret.

Systems and methods for securely booting a computer with a trusted processing module

A mechanism for protected operating system boot that prevents rogue components from being loaded with the operating system, and thus prevents divulgence of the system key under inappropriate circumstances. After a portion of the machine startup procedure has occurred, the operating system loader is run, the loader is validated, and a correct machine state is either verified to exist and/or created. Once the loader has been verified to be a legitimate loader, and the machine state under which it is running is verified to be correct, the loader's future behavior is known to protect against the loading of rogue components that could cause divulgence of the system key. With the loader's behavior being known to be safe for the system key, the validator may unseal the system key and provides it to the loader.

System and method for protected operating system boot using state validation

Systems and methods for controlling access to data on a computer with a secure boot process can provide a highly efficient mechanism for preventing future access to encrypted digital resources. This may be advantageous in a range of scenarios, for example where a computer is sold and assurance is desired that no stray private data remains on the hard disk. Data resources, for example all data associated with one or more particular hard disk partitions, may be encrypted. The decryption key may be available through a secure boot process. By erasing, altering, or otherwise disabling a secret, such as a decryption key or a process that obtains a decryption key, the data formerly accessible using such secret becomes inaccessible.

Systems and methods for controlling access to data on a computer with a secure boot process

Systems and methods for boot recovery in a secure boot process on a computer with a hardware security module

A method and system for avoiding the overwriting of drivers by subsequent versions or other commonly named drivers includes generating a unique identity for every eligible driver package. Driver files from the driver package, or the entire driver package itself, are then installed in a subdirectory location in a common storage based on the unique identity. The driver files may be loaded to a memory from the subdirectory location. Thus, multiple driver packages and driver files having the same name may be installed and loaded side-by-side.

Side-by-side drivers

Growing community of inventors

Bothell, WA, United States of America

Jamie Hunter