Microsoft Technology Licensing, LLC

Paul England

Marcus Peinado

Butler W Lampson

Bryan M Willman

Kenneth D Ray

John D DeTreville

Stefan Thom

Daniel Ron Simon

Josh D Benaloh

Thekkthalackal Varugis Kurien

Dennis James Mattoon

David Rudolph Wooten

Glenn Frederick Evans

Mukund Sankaranarayan

Cormac E Herley

Yacov Yacobi

Robert Karl Spiger

Jonathan D Schwartz

Jamie Hunter

Gideon Andreas Yuval

Russell Humphries

Niels Thomas Ferguson

Himanshu Raj

Ravindra Pandya

James Anthony Schwartz, Jr

Henrique Sarmento Malvar

Arnold Neil Blinn

Alastair Wolman

Scott Field

Michael Todd Kramer

Mariusz Hieronim Jakubowski

Nicholas P Wilt

Mark Fishel Novak

Stefan Saroiu

Thomas C Jones

John L Manferdelli

Rajasekhar Abburi

Brian Clifford Telfer

Jeffrey R C Bell

Andrey Marochko

Michael David Marr

Keith Stuart Kaplan

Blair Brewster Dillaway

Stuart Hillary Schaefer

John Charles Dunn

Andrew John Thornton

Ronald Aigner

Frank Dominic Yerrace

Glen T Slick

Luis Irun-Briz

Merzin Kapadia

Shravan Rayanchu

Andrew D Rosen

Dave M McPherson

Jork Loeser

Sangho Lee

Ramaranthnam Venkatesan

Magnus Bo Gustaf Nystrom

Hai Ying (Vincent) Yu

Anh M Nguyen

Eric J Horvitz

Alexander Frank

Brian LaMacchia

David Benson Cross

Alan Geller

Nathan T Lewis

Yuqun Chen

Jason Garms

Krishnamurthy Ganesan

Charles F Rose

Muthukrishnan Paramasivam

Quintin Swayne Burns

John Carl Simmons

Ning Lin

Matthew Charles Setzer

Mohamed Rouatbi

John E Paff

Varugis Kurien

Julian Federico Gonzalez

Samuel John Wenker

Pierre Jacomet

Michael Alfred Aday

Andrew Lee Jenks

Derek Norman LaSalle

Peter Nicholas Biddle

Mark E Paley

Svetlana Gaivoronski

Kevin M Kane

Lonnie Dean McMichael

Nuno Santos

Anshul Dhir

Benjamin Armstrong

Selena Wilson

Lightweight mechanisms provide a way to assert provenance when live streaming media content and establish provenance upon playback. For example, a provenance claim generator generates a key pair including a live-stream private key and live-stream public key. The claim generator signs, with a long-term private key reliably associated with a sender, manifest metadata including the live-stream public key, thereby producing a manifest signature. During live streaming, the claim generator signs respective portions of media content with the live-stream private key, producing portion signatures for the respective portions. A provenance claim validator receives the manifest signature and manifest metadata. The claim validator verifies the manifest metadata using a long-term public key (reliably associated with the sender) and the manifest signature. During live streaming, the claim validator verifies the respective portions of the media content using the live-stream public key and the portion signatures for the respective portions.

Asserting and establishing provenance of media content during live streaming

Systems and methods to determine when a media is a high-fidelity reproduction of an original media from a trusted entity are disclosed. In certain aspects, systems and method for generating a fragile watermark are disclosed. The fragile watermark may be inserted into digital media in a manner such that the watermark cannot be identified if the media content is significantly altered. Media content may be subsequently analyzed to determine the presence of a fragile watermark. When the fragile watermark is present, provenance of the media content can be verified and an indication of provenance is provided to the user.

Media provenance certification via fragile watermarking

A storage device for booting a host computing device includes a first storage memory region having a first storage memory controller, a second storage memory region having a second storage memory controller, and a resilient boot controller. The resilient boot controller is configured to store boot code in the first storage memory region, prevent write access by the host computing device through the first storage memory controller to the first storage memory region, detect a reset of the host computing device through the input/output interface, copy at least a portion of the boot code from the first storage memory region to the second storage memory region, responsive to detection of the reset of the host computing device, and enable read access of the copied boot code by the host computing device through the second storage memory controller of the second storage memory region, responsive to the copy operation.

Selective boot sequence controller that cryptographically validating code package for resilient storage memory

Selective boot sequence controller for resilient storage memory

A computing device's trusted platform module (TPM) is configured with a cryptographic watchdog timer which forces a device reset if the TPM fails to solve a cryptographic challenge before the expiration of the timer. The computing device's TPM is configured to generate the cryptographic challenge, to which the computing device does not possess the cryptographic token for resolution. While the watchdog timer counts down, the computing device requests a cryptographic token from a remote service to solve the challenge. The remote service transmits the cryptographic token to the computing device so long as the remote service identifies no reason to withhold the token, such as the computing device being infected with malware. The interoperability of the computing device and remote service enables the remote service to exercise control and reset capabilities over the computing device.

Cryptographic hardware watchdog

A process to detect intrusions with an intrusion detection system is disclosed. The intrusion detection system identifies instance types, and each instance type includes an instance. A know compromised instance is identified from the plurality of instances. A link between the plurality instance types is traversed from the compromised instance to discover an additional compromised instance.

Intrusion detection

Disclosed is a trusted language runtime (TLR) architecture that provides abstractions for developing a runtime for executing trusted applications or portions thereof securely on a mobile device (e.g., a smartphone). TLR offers at least two abstractions to mobile developers: a trustbox and a trustlet. The trustbox is a runtime environment that offers code and data integrity, and confidentiality. Code and data running inside a trustbox cannot be read or modified by any code running outside the trustbox. A trustlet is the code portion of an application that runs inside a trustbox. With TLR, programmers can write applications in .NET and specify which parts of the application handle sensitive data, and thus, run inside the trustbox. With the TLR, the developer places these parts in a trustlet class, and the TLR provides all support needed to run the parts in the trustbox.

Trusted language runtime on a mobile platform

Disclosed are systems that provide for secure and reliable remote management. Cryptographic health tickets provided by a management server are provided to a protected process executing on a computing device. In some examples, the health tickets reset an authenticated watchdog timer that resets the computing device if the timer expires. In some examples, the computing device may contact the management server prior to loading an operating system to receive instructions, but may omit contacting the management server if a valid health ticket is found.

Device health tickets

A smart device, connected device, Internet of Things (IoT) device, etc. is configured with an embedded certificate authority. The embedded certificate authority generates a compound certificate that is signed at least by a manufacturer certificate securely stored on the device. The compound certificate includes a representation of a state of the device, which is based on one or more measurements of code executable on the device. The compound certificate may be used by an external device communicating with the smart device to determine whether the device is in a trusted state. Because the compound certificate is chained to a manufacturer certificate, the external device can communicate with the manufacturer (or an employed party) to determine whether the state of the device should be trusted.

Device with embedded certificate authority

A keying infrastructure may generate and/or manage cryptographic keys. The cryptographic keys may include identity keys, encryption keys, and a variety of other types of keys. The cryptographic keys may be derived or created with a key derivation function (KDF) or other one-way function. The cryptographic keys may include keys that are accessible to a boot loader, keys that are accessible to particular components of a Trusted Execution Environment (TrEE), and so on. In some examples, a key may be derived from a preceding key in a sequence of keys. The preceding key may be deleted when the key is derived.

Keying infrastructure

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

The various embodiments described below are directed to providing authenticated and confidential messaging from software executing on a host (e.g. a secure software application or security kernel) to and from I/O devices operating on a USB bus. The embodiments can protect against attacks that are levied by software executing on a host computer. In some embodiments, a secure functional component or module is provided and can use encryption techniques to provide protection against observation and manipulation of USB data. In other embodiments, USB data can be protected through techniques that do not utilized (or are not required to utilize) encryption techniques. In accordance with these embodiments, USB devices can be designated as 'secure' and, hence, data sent over the USB to and from such designated devices can be provided into protected memory. Memory indirection techniques can be utilized to ensure that data to and from secure devices is protected.

Methods and systems for protecting data in USB systems

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

Growing community of inventors

Bellevue, WA, United States of America

Paul England