Abstract: The cyber owner of the asset can transfer cyber ownership to a second entity based on a transaction and using an escrow entity. An escrow service in association with an escrow entity is utilized to secure transfer of ownership to the second entity in accordance with the conditions of the transaction. The cyber owner initiates an escrow process by transmitting an escrow instruction to the access configuration controller. A new cryptographic key is generated responsive to the escrow instruction and is managed by a generated escrow policy indicating an escrow period. Different components of the cryptographic key are transmitted to the second entity and the escrow service. When the conditions of the transaction are satisfied during the escrow period, the escrow service transmits the component of the cryptographic key to the second entity. The second entity may use the recomposed cryptographic key to assert ownership of the asset.

Abstract: The techniques and systems described herein are directed to providing targeted, secure software deployment in a computing system. An identity of the computing device can be determined and verified using a trusted platform module (TPM) of the computing device, and a software update can be expressly configured to operate solely on the computing device. Further, a configuration of the computing device can be ascertained using platform configuration registers (PCRs) of the TPM to determine that the computing device has not been modified from a trusted configuration. For example, if malware or unauthorized software is operating on the computing device, the software update may be prevented from being installed. Further, the software update can be targeted for a particular computing device, such that when the software update is received at the computing device, the software update may not be duplicated and provided to an additional, unauthorized device.

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

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

Abstract: A device is configured with a trusted platform module (TPM) executing in a trusted execution environment (TEE). Software/firmware updates, user data, applications, etc. are pushed to the device as a payload. The payloads contain a sealed container (e.g., the software/firmware update, user data, applications, etc.), one or more policies, and one or more provisioning code segments corresponding to the one or more policies. The policies are checked by the TPM of the device. If the measurement of the one or more provisioning code segments satisfy the one or more policies, then the sealed container is unsealed by the TPM and released to the device.

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 device is equipped with a public/private key pair. The private key is stored in a secure location on the device and the public key is utilized to track ownership of the device by a manufacturer, vendor, and/or one or more provisioning services. When a user purchases the device, a transaction involving the public key associated with the device and the user is recorded. The one or more provisioning services, which are provided access to user information, prepare a configuration payload for the device specific to the user and the device. The configuration payload is encrypted using the device's public key. When the device is powered on, the configuration payload is sent to the device. The device decrypts the configuration payload using the device's private key and adjusts one or more configuration parameters based on the configuration payload.

Abstract: A key originating device generates a subject key that is managed by a policy. The subject key may be generated and the policy configured at the instruction of a user, an application, or a service, such as a provisioning service. The policy that manages the subject key identifies at least one or more entities that are authorized to receive the subject key. The subject key is provided varying layers of encryption as it is communicated between the originating device, an escrow services, and an authorized entity.

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

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

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

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

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

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

Abstract: Described are examples for authenticating a device including detecting an event related to communications with a trusted platform module (TPM) device, performing, in response to detecting the event, one or more security-related functions with the TPM device, such as generating and/or signing one or more digital certificates, which may be based on one or more keys on the TPM device.

Abstract: Methods and devices for creating a secure log of security events may include receiving a historical digest representing approved historical security events associated with a trusted network of devices. The methods and devices may include receiving one or more new security events. The methods and devices may include calculating, when a period of time has expired, a hash based on at least the historical digest and the one or more new security events and determining if a value of the hash is less than a value threshold. The methods and devices may include storing a new security event digest corresponding to a respective hash having a respective value less than the value threshold, wherein the new security event digest is confirmed by one or more trusted devices in the trusted network of devices.

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

Abstract: The techniques and systems described herein are directed to providing targeted, secure software deployment in a computing system. An identity of the computing device can be determined and verified using a trusted platform module (TPM) of the computing device, and a software update can be expressly configured to operate solely on the computing device. Further, a configuration of the computing device can be ascertained using platform configuration registers (PCRs) of the TPM to determine that the computing device has not been modified from a trusted configuration. For example, if malware or unauthorized software is operating on the computing device, the software update may be prevented from being installed. Further, the software update can be targeted for a particular computing device, such that when the software update is received at the computing device, the software update may not be duplicated and provided to an additional, unauthorized device.

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