Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.