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: 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 virtual machine on a physical host computer provides controlled access to protected data by creating and storing a “stored system fingerprint” from stable system values (SSVs) as existing when creating the stored system fingerprint. The SSVs include virtual-machine-specific values that change upon cloning the virtual machine (VM) but do not change upon migration of the VM. Upon a request for access to the protected data, a current system fingerprint is calculated from the SSVs as existing when processing the request, the current system fingerprint is compared to the stored system fingerprint to determine whether there is a predetermined degree of matching, and the requested access to the protected data is permitted only if there is the predetermined degree of matching.

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 technique controls access to a file. The technique involves creating a file encryption key based on (i) a user input parameter (e.g., a user password) from a user of the client device and (ii) an automatically generated salt parameter (e.g., a random number). The technique further involves encrypting the file using the file encryption key to form an encrypted copy of the file, and providing the salt parameter to an external storage system to externally store the salt parameter. Access to data within the encrypted copy of the file requires the salt parameter provided to the external storage system.

Abstract: Computing devices utilizing trusted execution environments as virtual smart cards are designed to support expected credential recovery operations when a user credential, 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: 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: An event log can comprise, not only entries associated with components instantiated since a most recent power on of a computing device, but also entries of components instantiated prior to that power on, such as components that were instantiated, and represent, a state of the computing device prior to hibernation that has now been resumed. Upon hibernation, the current values of the Platform Configuration Registers (PCRs) of a Trusted Platform Module (trusted execution environment), as well as a quote of those current values, and a current value of a monotonic counter of the trusted execution environment can be logged. The monotonic counter can be incremented at each power on to track successive generations of the computing device and to guard against an intervening, not-logged generation. A subsequent parsing of the event log can verify the prior generational entries with reference to the PCR values in the log that are associated with those generations.

Abstract: In one embodiment, an encryption system may protect user login metadata from hammering attacks. A data storage 140 may store an integrity protected data set 602 for an operating system in a storage location. A processor 120 may register a counter reading from a remote counter 202 in a secure location 204 separate from the storage location. The processor 120 may determine a lockout state of the integrity protected data set 602 based on the counter reading.

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: 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: An authentication-delegating service implemented in an authentication server or other processing device is configured to receive a request from a relying party for delegated authentication information associated with a particular user, to determine a level of trust associated with the relying party, and to provide the delegated authentication information to the relying party if the relying party has a sufficient level of trust, so as to permit the relying party to authenticate the user based on the delegated authentication information. The delegated authentication information has the property that the user can be presently authenticated based on such information. The delegated authentication information may comprise, for example, at least one value derived from a one-time password or other authentication credential of the particular user.

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: 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: One or more techniques and/or systems are provided for provisioning encrypted key blobs and client certificates. That is, a trusted execution environment on a first machine may provide a key service provider with a cryptographic encryption key. The key service provider may encrypt a key blob using the cryptographic encryption key and/or wrap the encrypted key blob with one or more policies, such as a platform policy. The key service provider may provision the encrypted key blob to a client on the first machine. The client may submit the encrypted key blob to the trusted execution environment for validation so that the client may perform key actions, such as sign an email or encrypt data. Because the key blob may be specific to a particular trusted execution environment and/or machine, the key service provider may re-wrap the key blob if the client “roams” to a second machine.

Abstract: An event log can comprise, not only entries associated with components instantiated since a most recent power on of a computing device, but also entries of components instantiated prior to that power on, such as components that were instantiated, and represent, a state of the computing device prior to hibernation that has now been resumed. Upon hibernation, the current values of the Platform Configuration Registers (PCRs) of a Trusted Platform Module (trusted execution environment), as well as a quote of those current values, and a current value of a monotonic counter of the trusted execution environment can be logged. The monotonic counter can be incremented at each power on to track successive generations of the computing device and to guard against an intervening, not-logged generation. A subsequent parsing of the event log can verify the prior generational entries with reference to the PCR values in the log that are associated with those generations.

Abstract: An access component sends an access request to an intermediary component, the access request being a request to access a service or resource without credentials of a current user of the intermediary component being revealed to the access component. The intermediary component obtains user credentials, for the current user, that are associated with the service or resource. The access request and the user credentials are sent to the service or resource, and in response session state information is received from the service or resource. The session state information is returned to the access component, which allows the access component and the service or resource to communicate with one another based on the session state information and independently of the first component.

Abstract: Techniques for secure generation of a seed for use in performing one or more cryptographic operations, utilizing a seed generation protocol carried out by a seed generation client (110c) and a seed generation server (110s). The seed generation server (110s) provides a first string to the seed generation client (110c). The seed generation client (110c) generates a second string, encrypts the second string utilizing a key (216), and sends the encrypted second string to the seed generation server (110s). The seed generation client (110c) generates the seed as a function of at least the first string and the second string. The seed generation server (110s) decrypts the encrypted second string (222) and independently generates the seed as a function of at least the first string and the second string.

Abstract: A method of protecting a password being used to establish interaction between a user and an application includes detecting a request for the password from the application by receiving a notification from the user indicating the request. The method further includes combining the password with information identifying the application, so as to produce a protected password, and authenticating to the application using the protected password. The method may also include a mutual authentication capability between user and the application.