Microsoft Technology Licensing, LLC

Kinshumann

Christopher Warner McCarron

Mark Fishel Novak

Nir Ben-Zvi

Yevgeniy Anatolievich Samsonov

John Anthony Messec

David Matthew Kruse

Anders Bertil Vinberg

Niels Thomas Ferguson

David John Linsley

Samartha Chandrashekar

Qiang Wang

Amitabh Prakash Tamhane

JianMing M Zhou

Hari R Pulapaka

Benjamin M Schultz

Scott Randall Shell

Frederick Justus Smith

Scott Daniel Anderson

David Bradley Probert, Jr

Giridhar Viswanathan

Charles Glenn Jeffries

Margarit Simeonov Chenchev

Md Nazmus Sakib

Daryn Elliot Robbins

Dale R Rolf

Ian James McCarty

A virtual secure mode is enabled for a virtual machine operating in a computing environment that is associated with a plurality of different trust levels. First, a virtual secure mode image is loaded into one or more memory pages of a virtual memory space of the virtual machine. Then, the one or more memory pages of the virtual memory space are made inaccessible to one or more trust levels having a relatively lower trust level than a launching trust level that is used by a virtual secure mode loader to load the virtual secure mode image. A target virtual trust level is also enabled on a launching virtual processor for the virtual machine that is higher than the launching trust level.

Secure management of operations on protected virtual machines

Embodiments are directed to managing software components loaded on a device by identifying a platform manifest having a valid certificate, confirming that the platform manifest is bound to the device, identifying components listed on the platform manifest, confirming that the listed components have a valid certificate, and loading listed components with valid certificates on the device. The components may be binaries and packages for an operating system. The components may be signed in an embedded manner or with detached signatures. The platform manifest may be bound to the device in a manner that allows for identification of unauthorized platform manifests.

Securely defining operating system composition without multiple authoring

Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.

Securing virtual execution environments

Booting a machine in a secure fashion in a potentially unsecure environment. The method includes a target machine beginning a boot process. The method further includes the target machine determining that it needs provisioning data to continue booting. The target machine contacts a secure infrastructure to obtain the provisioning data. The target machine provides an identity claim that can be verified by the secure infrastructure. As a result of the secure infrastructure verifying the identity claim, the target machine receives a request from the secure infrastructure to establish a key sealed to the target machine. The target machine provides the established key to the secure infrastructure. The target machine receives the provisioning data from the secure infrastructure. The provisioning data is encrypted to the established key. The target machine decrypts the encrypted provisioning data, and uses the provisioning data to finish booting.

Secure creation of encrypted virtual machines from encrypted templates

Obtaining a sealed secret. The method includes decrypting one or more BLOBs at a computing system from among a plurality of different BLOBs. Each of the BLOBs in the plurality of BLOBs contains the secret. Each of the BLOBs in the plurality of BLOBs is sealed to a different condition from among a plurality of conditions. A given condition is a reflection of a system state where the system state is indicative of whether or not the system can be trusted to receive the secret. The method further includes evaluating one or more of the conditions to determine if at least one of the one or more conditions is met. The method further includes, if at least one of the one or more conditions is met, then providing the secret to an external entity.

Preserving protected secrets across a secure boot update

Growing community of inventors

Redmond, WA, United States of America

Kinshumann