Microsoft Technology Licensing, LLC

Md Nazmus Sakib

Scott Randall Shell

Jeffrey A Sutherland

Deskin M Miller

Ling Tony Chen

Bryan David Kelly

Peter David Waxman

Scott Daniel Anderson

Kinshumann Kinshumann

Jeffrey Richard McKune

Thomas W Caldwell

Adrian Mihail Marinescu

David John Linsley

Ronald Aigner

Vishal Agarwal

Yogesh A Mehta

Narendra Shripati Acharya

Daryn Elliot Robbins

Giridharan Sridharan

Kinshumann

JianMing M Zhou

Ian James McCarty

Deepak Jagannathan Manohar

Dale R Rolf

David Guy Weston

Arnold Paul Pereira

Jessica M Krynitsky

Thomas Walter Caldwell, Iii

Deven Robert Desai

Jaskaran Singh Khurana

Embodiments described herein are directed to transferring the ownership of a computing device from one entity to another entity. For example, a security processor is utilized to boot the computing device. During a boot session, the security processor loads and executes boot code, which determines whether specialized firmware authorized by the current owner indicates whether a transfer of ownership is to occur. In response to determining that the specialized firmware indicates that a transfer of ownership is to occur, the secure processor loads and executes the specialized firmware. The specialized firmware, when executed, causes the security processor to program a set of fuses with the public key of the new owner. Execution of the specialized firmware also causes the security processor to invalidate the public key of the original owner, which is stored in another set of fuses.

Transfer of ownership of a computing device via a security processor

Methods, systems, apparatuses, and computer-readable storage mediums described herein enable executable code of a hardware security platform (HSP) circuit to communicate with a hypervisor in a separate processor. The hypervisor generates and manages virtual machines. The HSP code comprises trusted platform module (TPM) logic, that processes TPM commands received via the hypervisor, and in response to the processing, communicates security information (e.g., measurements, keys, authorization data) with the virtual machines via the hypervisor. The TPM logic receives security information related to a virtual machine from the hypervisor and stores the security information in non-volatile memory of the HSP circuit, where security information from a particular VM is distinguishable from security information from another VM in the HSP memory. The hypervisor (and VMs) communicate via a network fabric with the HSP circuit within an SOC, or the HSP may reside on a discrete chip and communicate via a secure encrypted channel.

Hardware virtualized TPM into virtual machines

An application is installed on a computing device from an application package. An origin of the application (e.g., a managed installer for an enterprise, a reputation checking service) is propagated to files written to a storage device of the computing device as part of the installation, such as by writing origin information to the storage device as metadata associated with the file. The origin information for a file, in conjunction with a policy on the computing device specifying one or more trusted origins for applications on the computing device, is used to identify whether a particular action can be taken with and/or by the file. These actions can include, for example, execution of an application from an executable file. If the origin information for a file indicates an origin that is a trusted origin specified by the policy, then the action can be performed.

Propagating origin information for applications during application installation

Embodiments described herein are directed to firmware policy enforcement of a computing device. For example, a security processor of the computing device is utilized to boot the computing device. During a boot session, the security processor loads and executes specialized firmware. The specialized firmware, when executed, causes the security processor to determine whether other types of firmware to be executed on the computing device is in compliance with a policy specified by the specialized firmware. Based at least on a determination that the other firmware is in compliance with the policy, the security processor executes the other firmware. Based at least on a determination that the other firmware is not in compliance with the policy, the security processor performs a mitigation with respect to the other firmware.

Firmware policy enforcement via a security processor

Integrity verification of a containerized application using a block device signature is described. For example, a container deployed to a host system is signed with a single block device signature. The operating system of the host system implements an integrity policy to verify the integrity of the container when the container is loaded into memory and when its program code executes. During such events, the operating system verifies whether the block device signature is valid. If the block device signature is determined to be valid, the operating system enables the program code to successfully execute. Otherwise, the program code is prevented from being executed. By doing so, certain program code or processes that are not properly signed are prevented from executing, thereby protecting the host system from such processes. Moreover, by using a single block device signature for a container, the enforcement of the integrity policy is greatly simplified.

Block device signature-based integrity protection for containerized applications

Examples described herein generally relate to a computer device including a memory, and at least one processor configured to determine whether to allow execution of an application file on the computer device. The processor receives a command to execute a file. The processor determines whether the file is associated with a package reputation of an installation package. The processor determines a file reputation of the file. The processor determines whether to allow execution of the file based on a combination of the file reputation of the file and whether the file is associated with the good package reputation.

Binary authorization based on both file and package attributes

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

A system for changing policy information of a process is provided. When a process is to execute, the system stores policy information for the process in association with the process code. The system also creates a token for the process. The token provides evidence of the policy for the process and includes at least a reference to the stored policy information. The system provides the token to the process for use by the process as evidence of the policy for the process. When the process provides the token to a service provider, the service provider uses the reference to access the policy information for the process. While the process is executing, the system modifies the stored policy information. When the process subsequently provides the token to a service provider, the service provider uses the reference to access the modified policy information for the process.

Dynamic updating of process policies

Growing community of inventors

Seattle, WA, United States of America

Md Nazmus Sakib