Abstract: A system that includes an account management module configured to maintain protected accounts. For instance, a particular protected account includes a protected data set that is not readable outside of the system, and perhaps not even readable outside of the account. The particular data set corresponds to a particular entity assigned to the particular account and that includes keys corresponding to the particular entity. A security processor uses at least some of the plurality of keys to perform cryptographic processes in response to one or more trusted execution environment commands received from the particular entity.

Abstract: A “Firmware-Based TPM” or “fTPM” ensures that secure code execution is isolated to prevent a wide variety of potential security breaches. Unlike a conventional hardware based Trusted Platform Module (TPM), isolation is achieved without the use of dedicated security processor hardware or silicon. In general, the fTPM is first instantiated in a pre-OS boot environment by reading the fTPM from system firmware or firmware accessible memory or storage and placed into read-only protected memory of the device. Once instantiated, the fTPM enables execution isolation for ensuring secure code execution. More specifically, the fTPM is placed into protected read-only memory to enable the device to use hardware such as the ARM® architecture's TrustZone™ extensions and security primitives (or similar processor architectures), and thus the devices based on such architectures, to provide secure execution isolation within a “firmware-based TPM” without requiring hardware modifications to existing devices.

Abstract: Computing devices utilizing trusted execution environments as virtual smart cards are designed to support expected credential recovery operations when a user credential, e.g., personal identification number (PIN), password, etc. has been forgotten or is unknown. A computing device generates a cryptographic key that is protected with a PIN unlock key (PUK) provided by an administrative entity. If the user PIN cannot be input to the computing device the PUK can be input to unlock the locked cryptographic key and thereby provide access to protected data. A computing device can also, or alternatively, generate a group of challenges and formulate responses thereto. The formulated responses are each used to secure a computing device cryptographic key. If the user PIN cannot be input to the computing device an entity may request a challenge. The computing device issues a challenge from the set of generated challenges.

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. The generation of a device health value involves initializing hardware components of a computing device and loading the operating system according to configuration settings during boot up of the computing device. The device health value is then 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.

Abstract: Techniques are provided to allow remote initialization of a Trusted Platform Module. The results may be trusted and confidential even if the target device has malicious operating system or other software running.

Abstract: A “Firmware-Based TPM” or “fTPM” ensures that secure code execution is isolated to prevent a wide variety of potential security breaches. Unlike a conventional hardware based Trusted Platform Module (TPM), isolation is achieved without the use of dedicated security processor hardware or silicon. In general, the fTPM is first instantiated in a pre-OS boot environment by reading the fTPM from system firmware or firmware accessible memory or storage and placed into read-only protected memory of the device. Once instantiated, the fTPM enables execution isolation for ensuring secure code execution. More specifically, the fTPM is placed into protected read-only memory to enable the device to use hardware such as the ARM® architecture's TrustZone™ extensions and security primitives (or similar processor architectures), and thus the devices based on such architectures, to provide secure execution isolation within a “firmware-based TPM” without requiring hardware modifications to existing devices.

Abstract: Described herein are techniques for regulating access to a portable storage drive, that stores an operating system securely, using information regarding a host machine. In accordance with some of the techniques described herein, when a portable storage drive that stores an operating system securely is to be accessed by a host machine, information regarding the host machine, such as information regarding the hardware of the host machine, may be retrieved and evaluated to determine whether to grant access to the host machine. When the host machine is granted access, the host machine may access secured data stored on the portable storage drive in any suitable manner. In some cases, accessing the secured data may include decrypting the secured data and transferring decrypted data to another storage of the host machine. The decrypted information may include an operating system that is booted by the host machine.

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. The generation of a device health value involves initializing hardware components of a computing device and loading the operating system according to configuration settings during boot up of the computing device. The device health value is then 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.

Abstract: Computing devices utilizing trusted execution environments as virtual smart cards are designed to support expected credential recovery operations when a user credential, e.g., personal identification number (PIN), password, etc. has been forgotten or is unknown. A computing device generates a cryptographic key that is protected with a PIN unlock key (PUK) provided by an administrative entity. If the user PIN cannot be input to the computing device the PUK can be input to unlock the locked cryptographic key and thereby provide access to protected data. A computing device can also, or alternatively, generate a group of challenges and formulate responses thereto. The formulated responses are each used to secure a computing device cryptographic key. If the user PIN cannot be input to the computing device an entity may request a challenge. The computing device issues a challenge from the set of generated challenges.

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: Systems, methods, and technologies for configuring a conventional smart card and client machine, and for performing a smart card authorization using the configured smart card and client. Further, the combination of methods provides for mutual authentication—authentication of the client to the user, and authentication of the user to the client. The authentication methods include presenting a specified token to the user sufficient to authenticate the client to the user and thus protect the user-provided PIN. Security is strengthened by using an integrity key based on approved client system configurations. Security is further strengthened by calculating a PIN? value based on a user-specified PIN and a modifier and using the PIN? value for unlocking the smart card.

Abstract: Briefly, aspects of the subject matter described herein relate to virtual machines. In aspects, when a host is reset or powered on, a measured boot is performed. If the measured boot indicates that the host is in a state that satisfies a policy for gaining access to a cryptographic key, the cryptographic key may be obtained. The cryptographic key may be used, directly or indirectly, to decrypt data of a virtual storage device. This decrypted data may then be used to instantiate a virtual machine.

Abstract: Systems, methods, and technologies for configuring a conventional smart card and client machine, and for performing a smart card authorization using the configured smart card and client. Further, the combination of methods provides for mutual authentication—authentication of the client to the user, and authentication of the user to the client. The authentication methods include presenting a specified token to the user sufficient to authenticate the client to the user and thus protect the user-provided PIN. Security is strengthened by using an integrity key based on approved client system configurations. Security is further strengthened by calculating a PIN? value based on a user-specified PIN and a modifier and using the PIN? value for unlocking the smart card.

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: Computing devices utilizing trusted execution environments as virtual smart cards are designed to support expected credential recovery operations when a user credential, e.g., personal identification number (PIN), password, etc. has been forgotten or is unknown. A computing device generates a cryptographic key that is protected with a PIN unlock key (PUK) provided by an administrative entity. If the user PIN cannot be input to the computing device the PUK can be input to unlock the locked cryptographic key and thereby provide access to protected data. A computing device can also, or alternatively, generate a group of challenges and formulate responses thereto. The formulated responses are each used to secure a computing device cryptographic key. If the user PIN cannot be input to the computing device an entity may request a challenge. The computing device issues a challenge from the set of generated challenges.

Abstract: Systems, methods, and technologies for configuring a conventional smart card and client machine, and for performing a smart card authorization using the configured smart card and client. Further, the combination of methods provides for mutual authentication—authentication of the client to the user, and authentication of the user to the client. The authentication methods include presenting a specified token to the user sufficient to authenticate the client to the user and thus protect the user-provided PIN. Security is strengthened by using an integrity key based on approved client system configurations. Security is further strengthened by calculating a PIN? value based on a user-specified PIN and a modifier and using the PIN? value for unlocking the smart card.

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. The generation of a device health value involves initializing hardware components of a computing device and loading the operating system according to configuration settings during boot up of the computing device. The device health value is then 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.

Abstract: Cloning of a virtual machine having a trusted executed environment such as a software-based trusted platform module. In order to clone the virtual machine, the virtual machine state of the source virtual machine is copied to formulate a target virtual machine state that is to be associated with a target virtual machine. The target virtual machine is a clone of the source virtual machine state, and thus the storage hierarchy of the trusted execution environment may be the same for the trusted execution environment in the source and target virtual machine states. However, because the identity of the target virtual machine is different than that of the source virtual machine, the endorsement hierarchy of the target virtual machine state is altered such that it is based on the identity of the target virtual machine, rather than the source virtual machine.

Abstract: Booting a computing device includes executing one or more firmware components followed by a boot loader component. A protection component for the computing device, such as an anti-malware program, is identified and executed as an initial component after executing the boot loader component. One or more boot components are also executed, these one or more boot components including only boot components that have been approved by the protection component. A list of boot components that have been previously approved by the protection component can also be maintained in a tamper-proof manner.

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