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

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: 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: 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: A personal computing device, server or other type of processing device authenticates a user attempting to access a protected resource by verifying user knowledge of one or more extracted characteristics of stored information indicative of an internal operating state of that resource. The one or more extracted characteristics are characteristics that would likely be known to the user if that user had made one or more previous authenticated accesses to the protected resource. For example, the extracted characteristics may be indicative of a manner in which the user had utilized the protected resource during the one or more previous authenticated accesses to the protected resource. The processing device receives input from the user regarding the one or more extracted characteristics, and grants or denies access to the protected resource based at least in part on the input received from the user.

Abstract: A system for bootstrap provisioning of a device is provided. A vouching device is provisioned to access a bootstrap account of a bootstrap account provider and a secondary account of a secondary account provider. The bootstrap account provider stores an indication of the secondary account, and the secondary account provider stores verification data to verify a certification of the vouching device. A target device is provisioned to access the bootstrap account of the bootstrap account provider. The target device receives from the bootstrap account provider an indication that the target device is provisioned with the secondary account provider. The target device directs generation of a certification by the vouching device of target authentication data of the target device. The target device then sends the certification to the secondary account provider to effect the provisioning of the target device to access the secondary account.

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: A system for bootstrap provisioning of a device is provided. A vouching device is provisioned to access a bootstrap account of a bootstrap account provider and a secondary account of a secondary account provider. The bootstrap account provider stores an indication of the secondary account, and the secondary account provider stores verification data to verify a certification of the vouching device. A target device is provisioned to access the bootstrap account of the bootstrap account provider. The target device receives from the bootstrap account provider an indication that the target device is provisioned with the secondary account provider. The target device directs generation of a certification by the vouching device of target authentication data of the target device. The target device then sends the certification to the secondary account provider to effect the provisioning of the target device to access the secondary account.

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: Aspects of the subject matter described herein relate to clusters. In aspects, an image is created to install software onto nodes of the cluster. A root secret of the cluster is injected into the image. After installing the software of the image onto a node of the cluster, the node may boot into a secure mode, detect that individualization is needed for the node to join a cluster, create an identity for authenticating with other nodes of the cluster, chain the identity via the root secret, and then securely erase the root secret from the node prior to assuming node duties. Among other things, this allows a single image to be used for installing software on all nodes of a cluster without the compromise of a single node compromising the entire cluster.

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: A mobile telephone or other type of mobile communication device is configured to store a cryptographic credential within a secure hardware environment of the device. A script is provisioned for execution in the mobile communication device, the script comprising program code that executes at least in part within the secure hardware environment and is configured to utilize the cryptographic credential stored within the secure hardware environment. Prior to permitting the script to access the cryptographic credential, the secure hardware environment verifies an endorsement of the script. The endorsement may be provided by an issuer of the cryptographic credential. The cryptographic credential stored in the secure hardware environment may comprise a long-term credential and the script may be configured to generate a plurality of short-lived credentials based on the long-term credential.

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: Techniques are disclosed for performing operations in an authentication token or other cryptographic device in a system comprising an authentication server. In one aspect, a code generated by the authentication server is received in the cryptographic device. The code may have associated therewith information specifying at least one operation to be performed by the cryptographic device. The cryptographic device authenticates the code, and responsive to authentication of the code, performs the specified operation. If the code is not authenticated, the operation is not performed. The code may be determined as a function of a one-time password generated by the authentication server. The function may also take as an input an identifier of the operation to be performed.

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: Aspects of the subject matter described herein relate to clusters. In aspects, an image is created to install software onto nodes of the cluster. A root secret of the cluster is injected into the image. After installing the software of the image onto a node of the cluster, the node may boot into a secure mode, detect that individualization is needed for the node to join a cluster, create an identity for authenticating with other nodes of the cluster, chain the identity via the root secret, and then securely erase the root secret from the node prior to assuming node duties. Among other things, this allows a single image to be used for installing software on all nodes of a cluster without the compromise of a single node compromising the entire cluster.

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.