Abstract: Technologies to enable, disable and control hardware subscription features. Computing devices communicate over a network to a subscription server to provide hardware platform information for each of the computing devices. As the subscription server receives hardware platform information, the subscription server determines the hardware features that are enabled, and further determines what hardware subscription options are available for each of the computing devices. When a hardware subscription option is selected/purchased by a computing device, subscription server provides a pre-boot update mechanism, such as a Unified Extensible Firmware Interface (UEFI) capsule, to act as a boot level program that enables hardware features on the computing device. Hardware subscription features are also securely protected using cryptographic engine modules.

Abstract: Technologies to enable, disable and control hardware subscription features. Computing devices communicate over a network to a subscription server to provide hardware platform information for each of the computing devices. As the subscription server receives hardware platform information, the subscription server determines the hardware features that are enabled, and further determines what hardware subscription options are available for each of the computing devices. When a hardware subscription option is selected/purchased by a computing device, subscription server provides a pre-boot update mechanism, such as a Unified Extensible Firmware Interface (UEFI) capsule, to act as a boot level program that enables hardware features on the computing device. Hardware subscription features are also securely protected using cryptographic engine modules.

Abstract: A Trusted Activation License (TAL) can be comprised of a key unique to a Trusted Platform Module (TPM) and identifying information of the software applications bundled with the computing device having that TPM. To activate the software applications, the identifying information in the TAL can be compared against that of the software applications being activated, and the unique TPM key in the TAL can be compared against that of the TPM on the computing device on which the activation is taking place. Subsequent validations can be based on a protected association between the TAL and an Attestation Identity Key (AIK) that can be generated by the TPM as part of the activation step. Optionally, Platform Configuration Registers (PCRs) of the TPM can be periodically changed during validation to protect against useage of one TPM for validations on multiple computing devices.

Abstract: A Trusted Platform Module (TPM) can be utilized to implement One Time Password (OTP) mechanisms. One or more delegation blobs can be created by the TPM and the delegation authentication values of the delegation blobs can be based on the version number of the delegation blobs. A data blob with a protected secret can comprise a pointer to the delegation table of the TPM. The version number can be provided to an authority from which an OTP (a delegation authentication value) can be received. The OTP can be utilized to gain access to the secret and an authentication value of the key blob, which can be utilized to increase the version number of all associated delegation blobs. Policy limitations can be associated with the delegation blobs and can be enforced by policy enforcement mechanisms that can reference the TPM tick counter to enforce temporal policy restrictions.

Abstract: In situations, such as disasters, where the physical protection of data may be compromised, algorithmic protection of such data can be increased in anticipation of the disaster. An off-site mechanism can send a disaster preparation script to computing devices expected to be affected, resulting in the deletion of decryption keys from those computing devices. Once the disaster passes, the off-site mechanism, upon receiving confirmation of the physical integrity of the computing devices, can return one or more decryption keys to the computing devices, enabling access algorithmically protected data. The off-site mechanism can also optionally provide access information that can be used to obtain access to the algorithmically protected data via at least one returned decryption key.

Abstract: A transparent trust validation of an unknown platform can be performed by communicationally coupling it to a trusted device, such as a portable peripheral device carried by a user, or one or more remote computing devices. Information from the unknown platform can be obtained by boot code copied to it from the trusted device and such information can be validated by the trusted device. The trusted device can then provide an encrypted version of decryption key to the boot code which can request the Trusted Platform Module (TPM) of the unknown platform to decrypt and return the decryption key. If the information originally obtained from the unknown platform and validated by the trusted device was authentic, the TPM will be able to provide the decryption key to the boot code, enabling it to decrypt an encrypted volume comprising applications, operating systems or other components.

Abstract: A Trusted Activation License (TAL) can be comprised of a key unique to a Trusted Platform Module (TPM) and identifying information of the software applications bundled with the computing device having that TPM. To activate the software applications, the identifying information in the TAL can be compared against that of the software applications being activated, and the unique TPM key in the TAL can be compared against that of the TPM on the computing device on which the activation is taking place. Subsequent validations can be based on a protected association between the TAL and an Attestation Identity Key (AIK) that can be generated by the TPM as part of the activation step. Optionally, Platform Configuration Registers (PCRs) of the TPM can be periodically changed during validation to protect against useage of one TPM for validations on multiple computing devices.

Abstract: A Trusted Platform Module (TPM) can be utilized to implement One Time Password (OTP) mechanisms. One or more delegation blobs can be created by the TPM and the delegation authentication values of the delegation blobs can be based on the version number of the delegation blobs. A data blob with a protected secret can comprise a pointer to the delegation table of the TPM. The version number can be provided to an authority from which an OTP (a delegation authentication value) can be received. The OTP can be utilized to gain access to the secret and an authentication value of the key blob, which can be utilized to increase the version number of all associated delegation blobs. Policy limitations can be associated with the delegation blobs and can be enforced by policy enforcement mechanisms that can reference the TPM tick counter to enforce temporal policy restrictions.

Abstract: A cryptographic device protocol provides a generic interface allowing pre-OS applications to employ any of a variety of cryptographic devices within the pre-OS environment. The generic interface can be used independent of the specific cryptographic devices and is independent of the cryptographic or hashing algorithms used by each device. Cryptographic functions may be performed in the pre-OS environment by pre-OS applications communicating with cryptographic device drivers using the cryptographic device protocol that is independent of the cryptographic devices. Each cryptographic device may be identified by a unique device identifier and may have a number of keys available to it, with each key being identified by a unique key identifier.

Abstract: A transparent trust validation of an unknown platform can be performed by communicationally coupling it to a trusted device, such as a portable peripheral device carried by a user, or one or more remote computing devices. Information from the unknown platform can be obtained by boot code copied to it from the trusted device and such information can be validated by the trusted device. The trusted device can then provide an encrypted version of decryption key to the boot code which can request the Trusted Platform Module (TPM) of the unknown platform to decrypt and return the decryption key. If the information originally obtained from the unknown platform and validated by the trusted device was authentic, the TPM will be able to provide the decryption key to the boot code, enabling it to decrypt an encrypted volume comprising applications, operating systems or other components.

Abstract: A cryptographic device protocol provides a generic interface allowing pre-OS applications to employ any of a variety of cryptographic devices within the pre-OS environment. The generic interface can be used independent of the specific cryptographic devices and is independent of the cryptographic or hashing algorithms used by each device. Cryptographic functions may be performed in the pre-OS environment by pre-OS applications communicating with cryptographic device drivers using the cryptographic device protocol that is independent of the cryptographic devices. Each cryptographic device may be identified by a unique device identifier and may have a number of keys available to it, with each key being identified by a unique key identifier.

Abstract: Firmware of a system is configured to allow secondary devices, such as a smart card, to be used for authentication. In an example embodiment, the secondary device is a CCID smart card in compliance with the ISO 7816 specification. The smart card is inserted into a card reader coupled to the system prior to booting the system. The firmware comprises an emulator and driver configured to allow authentication information from the smart card to be utilized to allow execution of the boot process. In an example embodiment, the smart card comprises external keys for use with BITLOCKER™. The secondary device is compatible with systems implementing a BIOS and with systems implementing EFI. Authentication also can be accomplished via devices that do not provide data storage, such as a biometric device or the like.

Abstract: In situations, such as disasters, where the physical protection of data may be compromised, algorithmic protection of such data can be increased in anticipation of the disaster. An off-site mechanism can send a disaster preparation script to computing devices expected to be affected, resulting in the deletion of decryption keys from those computing devices. Once the disaster passes, the off-site mechanism, upon receiving confirmation of the physical integrity of the computing devices, can return one or more decryption keys to the computing devices, enabling access algorithmically protected data. The off-site mechanism can also optionally provide access information that can be used to obtain access to the algorithmically protected data via at least one returned decryption key.

Abstract: Image based login procedures for computer systems include: (a) displaying a first image on a computer screen; (b) receiving user input indicating a portion of the first image; (c) determining if the user input corresponds to a first acceptable user input for user authentication; and (d) proceeding with the authentication procedure when this user input corresponds to the first acceptable user input for user authentication. Additionally or optionally, when proceeding with this authentication procedure, the systems and methods further may include: displaying a second image on the screen; receiving new user input indicating a portion of the second image; and determining if this new input corresponds to a second acceptable user input for user authentication.