Microsoft Technology Licensing, LLC

Ronald Aigner

Stefan Thom

Stuart Hillary Schaefer

Robert Karl Spiger

Merzin Kapadia

Paul England

David Rudolph Wooten

Balaji Balasubramanyan

Dennis James Mattoon

Ling Tony Chen

Bryan David Kelly

Jonathan Kent Ross

Alain L Michaud

Peter David Waxman

Lars Reuther

Robert D Young

Giridhar Viswanathan

Md Nazmus Sakib

Navin Narayan Pai

Jork Loeser

Jeremiah J Cox

David Guy Weston

Kevin Patrick Kane

David Kimler Altobelli

Dan Ma

Jonathan Bret Barkelew

Alvin Morales Caro

Jan Simon Rellermeyer

Techniques are described herein that use attestation client code to attest health of a computing device. The computing device receives the attestation client code and a cryptographic key from an attestation service. The cryptographic key is associated with a TPM of the computing device and is usable only by the attestation client code. The computing device executes the attestation client code by executing a dynamic root of trust for measurement (DRTM) sequence. The computing device causes the attestation client code to gather measurements that indicate attributes of an operating system of the computing device. The computing device causes the attestation client code to generate protected measurements by using the cryptographic key to sign and/or encrypt the measurements. The computing device causes the attestation service to establish trust in the measurements by causing the protected measurements to be provided to the attestation service.

Executing attestation client code by executing a dynamic root of trust for measurement (DRTM) sequence to attest health of a computing device

Distributed security key management for protecting roaming data via a trusted platform module is performed by systems that include first and second processors, and first and second respective hardware security modules. The first security module encrypts a security key using a public key from the second security module, and the encrypted security key is provided to the second security module. A virtual machine (VM) executed by the first processor has a first virtual security module instance having state data that includes a storage key encrypting VM virtual disk data and that is encrypted with the security key. When a transfer condition is determined, the VM is transferred and executed by the second processor, using a second virtual security module instance, based on decrypting the security key by the second security module using a private key and decrypting the state data for the second virtual security module using the security key.

Distributed trusted platform module key management protection for roaming data

Methods for protecting software licensing information via a trusted platform module (TPM) are performed by systems and devices. When a licensing server is unreachable, a license is generated for a software application by a licensing manager. The license is generated via a secure register of the TPM using an asymmetric key, specific to the software application and policy-tied to the secure register, to generate a signature of a hashed license file for the software application. The asymmetric key is stored, mapped to the license file, and used for subsequent license validation. A licensing manager validation command is provided to validate the license using the key, as applied to the hash, to verify the signature and checking validity of the time stamp. Time stamp expiration or alteration of the license are determined to provoke invalidation indications for the validating application.

System and method for protecting software licensing information via a trusted platform module

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

A device includes a reset resistant store and a trusted key service. The reset resistant store maintains data across various different device reset or data invalidation operations. The trusted key service maintains, for each of one or more operating systems that run on the device from a boot configuration, an encrypted key associated with the boot configuration. The device also has a master key that is specific to the device. Each of the keys associated with a boot configuration is encrypted using the master key. When booting the device, the boot configuration being run on the device is identified, and the key associated with that boot configuration is obtained (e.g., from the reset resistant store or the encrypted key vault). The master key is used to decrypt the obtained key, and the obtained key is used to decrypt secrets associated with the operating system run from the boot configuration.

Maintaining operating system secrets across resets

Techniques for a trust service for a client device are described. In various implementations, a trust service is implemented remotely from a client device and provides various trust-related functions to the client device. According to various implementations, communication between a client device and a remote trust service is authenticated by a client identifier (ID) that is maintained by both the client device and the remote trust service. In at least some implementations, the client ID is stored on a location of the client device that is protected from access by (e.g., is inaccessible to) device components such as an operating system, applications, and so forth. Thus, the client ID may be utilized to generate signatures to authenticate communications between the client device and the remote trust service.

Trust service for a client device

Techniques for utilizing a trusted platform module of a host device are described. According to various embodiments, a client device that does not include a trusted platform module (TPM) may leverage a TPM of a host device to provide trust services to the client device.

Utilizing a trusted platform module (TPM) of a host device

The use of one or more device health values to indicate the health status of a computing device may enable operating system developers to directly manage the security configuration of the computing device. For instance, a device health value is generated based on a state of the hardware component and/or a state of a software stack that includes the operating system at boot up. The device health value may be compared to a reference health value to determine whether the computing device is in a secured state. Based on the device health value not matching the reference health value, it is determined that the computing device is operating in an unexpected state. Also, a recovery environment may be implemented on the computing device in order to fix any errors with the computing device.

Global platform health management

A portable security device for a computing system includes a housing, an interface at least partially disposed within the housing, a trusted platform module within the housing that is coupled to the interface, and a controller within the housing that is coupled to the trusted platform module and the interface. The interface is configured to engage a plurality of different devices and provide communication between the portable security device and an individual device when engaged with the individual device. In some examples, the trusted platform module can receive power from the individual device via the interface when the portable security device is engaged with the individual device. The controller includes logic to detect when the portable security device is coupled to the individual device via the interface.

Portable security device

A computing device described herein utilizes a secure cryptoprocessor of the computing device to compute a response to a request for authorization received from another local or remote device. The secure cryptoprocessor computes the response based on protected authorization credentials stored by the secure cryptoprocessor for one or more devices. The computing device then provides the computed response to the other device to cause the other device to grant or deny authorization. The computing device may also display information associated with the request for authorization, receive input indicating approval of the request, and utilize the secure cryptoprocessor in response to the received input.

Secure cryptoprocessor for authorizing connected device requests

Techniques for representation of operating system context in a trusted platform module are described. In at least some embodiments, authorization principals that corresponds to representations of operating system context are derived in a trusted platform module. The authorization principals can be used to define authorization policies for access to security assets stored in a trusted platform module.

Growing community of inventors

Redmond, WA, United States of America

Ronald Aigner