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

Abstract: In a cloud computing environment, a production server virtualization stack is minimized to present fewer security vulnerabilities to malicious software running within a guest virtual machine. The minimal virtualization stack includes support for those virtual devices necessary for the operation of a guest operating system, with the code base of those virtual devices further reduced. Further, a dedicated, isolated boot server provides functionality to securely boot a guest operating system. The boot server is isolated through use of an attestation protocol, by which the boot server presents a secret to a network switch to attest that the boot server is operating in a clean mode. The attestation protocol may further employ a secure co-processor to seal the secret, so that it is only accessible when the boot server is operating in the clean mode.

Abstract: Computing devices that perform hardware rooted attestation are described, as are methods for use therewith, wherein such devices include a system integrated TPM (e.g., a firmware-based TPM), with m boot chain components loaded and executed prior to the system integrated TPM. Between powering-up of a device and the system integrated TPM being loaded and executed, seed morphing is performed for n=0 to m. This involves an nth encryption seed (ESn) being morphed into an n+1th encryption seed (ESn+1), under control of an nth boot chain component, by extending the nth encryption seed (ESn) with a measurement of the n+1th boot chain component to thereby generate the n+1th encryption seed (ESn+1). In a similar manner, an nth identity seed (ISn) is morphed into an n+1th identity seed (ISn+1). Such techniques establish trust in the system integrated TPM despite it not being the first component loaded and executed after powering-up.

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: 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 provide multiple partitions hosted on an isolation technology such as a hypervisor where at least one of the partitions, a local secure service partition (LSSP), provides security services to other partitions. The service partitions (LSSPs) host those high assurance services that require strict security isolation, where the service can be shared across partitions and accessed even when the user is not connected to a network. The LSSP also can certify the results of any computation using a key signed by a TPM attestation identity key (AIK), or other key held securely by the hypervisor or a service partition. The LSSPs may be configured to provide trusted audit logs, trusted security scans, trusted cryptographic services, trusted compilation and testing, trusted logon services, and the like.

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

Abstract: In accordance with certain aspects, data is received from a calling program. Ciphertext that includes the data is generated, using public key encryption, in a manner that allows the data to be obtained from the ciphertext only if one or more conditions are satisfied. In accordance with another aspect, a bit string is received from a calling program. Data in the bit string is decrypted using public key decryption and returned to the calling program only if one or more conditions included in the bit string are satisfied.

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

Abstract: Computing devices that perform hardware rooted attestation are described, as are methods for use therewith, wherein such devices include a system integrated TPM (e.g., a firmware-based TPM), with m boot chain components loaded and executed prior to the system integrated TPM. Between powering-up of a device and the system integrated TPM being loaded and executed, seed morphing is performed for n=0 to m. This involves an nth encryption seed (ESn) being morphed into an n+1th encryption seed (ESn+1), under control of an nth boot chain component, by extending the nth encryption seed (ESn) with a measurement of the n+1th boot chain component to thereby generate the n+1th encryption seed (ESn+1). In a similar manner, an nth identity seed (ISn) is morphed into an n+1th identity seed (ISn+1). Such techniques establish trust in the system integrated TPM despite it not being the first component loaded and executed after powering-up.

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

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: A security processing unit is configured to manage cryptographic keys. In some instances, the security processing unit may comprise a co-processing unit that includes memory, one or more processors, and other components to perform operations in a secure environment. A component that is external to the security processing unit may communicate with the security processing unit to generate a cryptographic key, manage access to a cryptographic key, encrypt/decrypt data with a cryptographic key, or otherwise utilize a cryptographic key. The external component may comprise a central processing unit, an application, and/or any other hardware or software component that is located outside the security processing unit.

Abstract: In a cloud computing environment, a production server virtualization stack is minimized to present fewer security vulnerabilities to malicious software running within a guest virtual machine. The minimal virtualization stack includes support for those virtual devices necessary for the operation of a guest operating system, with the code base of those virtual devices further reduced. Further, a dedicated, isolated boot server provides functionality to securely boot a guest operating system. The boot server is isolated through use of an attestation protocol, by which the boot server presents a secret to a network switch to attest that the boot server is operating in a clean mode. The attestation protocol may further employ a secure co-processor to seal the secret, so that it is only accessible when the boot server is operating in the clean mode.

Abstract: Technology is described for protection of virtual machines executing on a host device having host processors and host memory. The system can include a hypervisor configured to enable the virtual machines to execute concurrently on the host device. An emancipated partition can be provided with a communication channel to the hypervisor. A primary partition can be configured to interface with the emancipated partition through the communication channel via the hypervisor. In addition, an emancipated memory space and virtual register state for the emancipated partition can be protected from direct access by the primary partition.

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