Microsoft Technology Licensing, LLC

David Rudolph Wooten

Stefan Thom

Paul England

Robert Karl Spiger

Dennis James Mattoon

Kenneth D Ray

Merzin Kapadia

Andrey Marochko

Mark F Williams

Nathan T Lewis

Stuart Hillary Schaefer

Ronald Aigner

Idan Avraham

Kevin M Litwack

Karan Mehra

Bryan M Willman

Octavian Tony Ureche

John Charles Dunn

Scott A Brender

Magnus Bo Gustaf Nyström

Paul Cador Roberts

Matthew Charles Setzer

John E Paff

Dan Sledz

Tony Ureche

Christine M Chew

Eric Holt

Douglas M Maclver

Constantyn Koeman

Magnus Bo Gustaf NYSTRÖM

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

Systems and methods for facilitating a trusted platform module (TPM) or other protector mechanism that provides a device with a trusted device capability store. To provide the device with a trusted device capability store, a fingerprint of an endorsement key that is associated with the TPM or other protector mechanism can be imprinted into firmware of the device. By imprinting the fingerprint into the firmware, the device can determine whether or not the TPM or other protector mechanism the device is communicating with is the TPM or other protector mechanism associated with the device. The TPM or other protector mechanism can include the endorsement key, the trusted device capability store, and an access policy. The trusted device capability store can include one or more capabilities associated with the device. The access policy can indicate both unauthorized read access and authorized write access associated with the TPM or other protector mechanism.

Tamper proof device capability store

Techniques are provided to ensure isolation of trusted input/output devices using a Secure Crypto-Processor. Secure IO lines may be used to drive devices that have a higher integrity requirement and to do attestation of sensor readings. Enhanced authorization policies may be used to enforce policies on interaction with IO devices. A bus master controller may also be provided in a Secure Crypto-Processor. Individual devices on an isolated Secure Crypto-Processor bus may be mapped to Indices so that read and write operations can be associated with Secure-Crypto-Processor-enforced authorization policies. The Secure Crypto-Processor may further provide means of attestation for complex data read from an input/output device that may be signed with the device identity to show strong origination proof of that data.

Isolation of trusted input/output devices

Systems and methods facilitating a framework that provides a core trusted computing base (TCB) of an electronic device with various security capabilities. The framework can include a low-resource device and at least one distributed resource. The low-resource device can be configured to generate sealing keys, migration keys, and attestation keys that are based on a device secret associated with the low-resource device and one or more software modules. The low-resource device can further be configured to use the migration keys and the sealing keys to both verify a software update and migrate secrets from a previous version of the software to a newer version of the software. Additionally, the low-resource device can be configured to generate an attestation statement using the attestation keys and perform attestation using the attestation statement and the at least one distributed resource.

Trusted platforms using minimal hardware resources

Migrating secrets using hardware roots of trust for devices

Architecture that utilizes logical combinations (e.g., of Boolean logic) of authorizations as a logical authorization expression that is computed through a proofing process to a single proof value which equates to authorizing access to an intended entity. The authorizations are accumulated and processed incrementally according to an evaluation order defined in the authorization expression. The logical combinations can include Boolean operations that evaluate to a proof value associated with a sum of products expression (e.g., combinations of AND, OR, etc.). The incremental evaluations output corresponding hash values as statistically unique identifiers used in a secure hash algorithm that when evaluated in order allow execution of a specific command to access the entity. The architecture, employed in a trust module, uses minimal internal trust module state, and can be employed as part of a device system that handles trust processing to obtain authorization to access the intended entity.

Authorization logic in memory constrained security device

The described implementations relate to trusted platform module (TPM) security. One configuration that is implemented on a computing device includes a TPM configured to generate a key pair utilizing a factor stored on the TPM and an external cofactor that is not stored on the TPM. The computing device also includes a communication device configured to receive the external cofactor and convey the external cofactor to the TPM.

Trusted platform module security

The subject disclosure is directed towards certifying cryptographic data for a crypto-processor outside of a controlled environment. The crypto-processor and a certifying entity maintain shared secret data for the purpose of verifying security of cryptographic key generation by the crypto-processor's firmware. In order to certify new cryptographic keys, the crypto-processor uses the shared secret data to verify the crypto-processor's firmware/hardware to the certifying entity. By protecting the shared secret data from exposure to compromised firmware, the shared secret data may be used to compute another secret conveying to the certifying entity whether the firmware can be trusted or not.

Secure crypto-processor certification

A 'Secure Code Launcher' establishes platform trustworthiness, i.e., a trusted computing base (TCB), and uses hardware or firmware based components to securely launch one or more software components. The Secure Code Launcher measures and loads software components by interfacing with security extension functionality integral to one or more hardware or firmware-based components in the computing device. For example, various embodiments of the Secure Code Launcher include firmware-based components that interface with security extension functionality integral to the computing device to measure and load boot managers, operating system (OS) loaders, or other OS components including OS kernels. Similarly, the Secure Code Launcher is capable of measuring and loading software components responsible for installing an instance of an OS. In addition, various embodiments of the Secure Code Launcher provide a hypervisor loader that measures and loads a hypervisor which in turn measures and loads operating system components including virtual machines.

Dynamically loaded measured environment for secure code launch

In accordance with one or more aspects, a representation of a configuration of a firmware environment of a device is generated. A secret of the device is obtained, and a platform secret is generated based on both the firmware environment configuration representation and the secret of the device. One or more keys can be generated based on the platform secret.

Digital signing authority dependent platform secret

A trusted platform module stores information in a protected object having an associated policy. A program requesting access to the information is allowed to access the information if the policy is satisfied, and is denied access to the information if the policy is not satisfied. The trusted platform module uses one or more monotonic counters associated with the protected object to track attempts to access the information. If a threshold number of unsuccessful requests to access the information are received, then the trusted platform module locks the information to prevent the program from accessing the information for an indefinite amount of time.

Attack protection for trusted platform modules

Computer systems and environments implemented herein permit a local machine increased participation in authorizing access to protected content. An operating system attests to a computing environment at a corresponding computer system. If the computing environment is one permitted to access protected content, the operating system is permitted to regulate further (e.g., application) access to protected content in accordance with a procreation policy. As such, authorization decisions are partially distributed, easing the resource burden on a content protection server. Accordingly, this computing environment can facilitate more robust and efficient authorization decisions when access to protected content is requested.

Attested content protection

Procedures for resumption from a low activity condition are discussed. In implementations, a persistent state file, or a portion thereof, is secured via an encryption algorithm, with the decryption key secured via the operating system (OS) login user credentials. Once a user is authenticated via the OS login, the persistent state file may be decrypted and inserted in the OS boot path with resumption occurring through the persistent state file.

Growing community of inventors

Redmond, WA, United States of America

David Rudolph Wooten