Abstract: This disclosure describes systems and methods for protecting commercial off-the-shelf software program code from piracy. A software program may include an executable file having code and data. A platform may modify the executable file such that the data may be placed at a location in memory that is an arbitrary distance from the code. The platform may modify the executable file to include a separation header. The separation header may indicate that the data can be placed at an arbitrary distance in the memory from the code. The separation header may indicate that the code should be loaded into a hardware enclave and that the data should be loaded outside of the hardware enclave. The platform may encrypt the code and provide it to a computing device. The computing device may load the encrypted code into the hardware enclave but load the data into memory outside the hardware enclave.

Abstract: A TPM with programmable fuses in an SOC includes an on-die RAM storing a blown-fuse count and a TPM state read from off-die NV memory. During initialization, if the blown-fuse count is greater than a TPM state fuse count, a TPM state PIN-attempt-failure count is incremented, thereby thwarting a replay attack. If a PIN satisfies a PIN failure policy, and if a TPM state previously-passed-PIN indicator is set to true, a fuse is blown and the blown-fuse count incremented depending on the PIN being incorrect, but if the TPM state previously-passed-PIN indicator is set to false, a fuse is blown and the blown-fuse count incremented independent of whether the PIN is correct or incorrect. The TPM state fuse count is set equal to the blown-fuse count. If a counter cleared before processing the PIN remains cleared during the next initialization, a fuse voltage cut is detected and a penalty imposed.

Abstract: Embodiments described herein are directed to transferring the ownership of a computing device from one entity to another entity. For example, a security processor is utilized to boot the computing device. During a boot session, the security processor loads and executes boot code, which determines whether specialized firmware authorized by the current owner indicates whether a transfer of ownership is to occur. In response to determining that the specialized firmware indicates that a transfer of ownership is to occur, the secure processor loads and executes the specialized firmware. The specialized firmware, when executed, causes the security processor to program a set of fuses with the public key of the new owner. Execution of the specialized firmware also causes the security processor to invalidate the public key of the original owner, which is stored in another set of fuses.

Abstract: A TPM with programmable fuses in an SOC includes an on-die RAM storing a blown-fuse count and a TPM state including a PIN-attempt-failure count and a fuse count, read from off-die NV memory. During initialization, if the blown-fuse count is greater than TPM state fuse count, TPM state PIN-attempt-failure count is incremented, thereby thwarting a replay attack. A PIN is received for access, and if the TPM state PIN-attempt-failure count satisfies a policy, a fuse is blown and the blown-fuse count incremented. If the fuse blow fails, TPM activity is halted. If the fuse blow succeeds and the PIN is correct, the TPM state PIN-attempt-failure count is cleared, but if the PIN is incorrect the TPM state PIN-attempt-failure count is incremented. TPM state fuse count is set equal to the blown-fuse count, and the TPM state is saved to off-die NV memory.

Abstract: Embodiments described herein are directed to firmware policy enforcement of a computing device. For example, a security processor of the computing device is utilized to boot the computing device. During a boot session, the security processor loads and executes specialized firmware. The specialized firmware, when executed, causes the security processor to determine whether other types of firmware to be executed on the computing device is in compliance with a policy specified by the specialized firmware. Based at least on a determination that the other firmware is in compliance with the policy, the security processor executes the other firmware. Based at least on a determination that the other firmware is not in compliance with the policy, the security processor performs a mitigation with respect to the other firmware.

Abstract: A TPM with programmable fuses in an SOC includes an on-die RAM storing a blown-fuse count and a TPM state read from off-die NV memory. During initialization, if the blown-fuse count is greater than a TPM state fuse count, a TPM state PIN-attempt-failure count is incremented, thereby thwarting a replay attack. If a PIN satisfies a PIN failure policy, and if a TPM state previously-passed-PIN indicator is set to true, a fuse is blown and the blown-fuse count incremented depending on the PIN being incorrect, but if the TPM state previously-passed-PIN indicator is set to false, a fuse is blown and the blown-fuse count incremented independent of whether the PIN is correct or incorrect. The TPM state fuse count is set equal to the blown-fuse count. If a counter cleared before processing the PIN remains cleared during the next initialization, a fuse voltage cut is detected and a penalty imposed.

Abstract: A TPM with programmable fuses in an SOC includes an on-die RAM storing a blown-fuse count and a TPM state read from off-die NV memory. During initialization, if the blown-fuse count is greater than a TPM state fuse count, a TPM state PIN-attempt-failure count is incremented, thereby thwarting a replay attack. If a PIN satisfies a PIN failure policy, and if a TPM state previously-passed-PIN indicator is set to true, a fuse is blown and the blown-fuse count incremented depending on the PIN being incorrect, but if the TPM state previously-passed-PIN indicator is set to false, a fuse is blown and the blown-fuse count incremented independent of whether the PIN is correct or incorrect. The TPM state fuse count is set equal to the blown-fuse count. If a counter cleared before processing the PIN remains cleared during the next initialization, a fuse voltage cut is detected and a penalty imposed.

Abstract: A TPM is implemented in an SOC for thwarting PIN state replay attacks. Programmable fuses are used as a counter and an on-die RAM stores a blown-fuse count and a TPM state that includes a PIN-failure count and a fuse count. TPM initialization includes incrementing the TPM state PIN-failure count if the blown-fuse count is greater than the TPM state fuse count. Once a PIN is received, if the TPM state PIN-failure count satisfies a PIN failure policy and the PIN is correct, the TPM state PIN-failure count is cleared, and if the PIN is incorrect, a fuse is blown and the blown-fuse count is incremented. If the fuse blow fails, TPM activity is halted. If the fuse blow succeeds, the TPM state PIN-failure count is incremented and the TPM state fuse count is set equal to the blown-fuse count. The TPM state is saved to off-die non-volatile memory.

Abstract: A method for secure key exchange. The method comprises receiving a request to certify a key from a communication partner at an interface between an access and tamper resistant circuit block and exposed circuitry. Within the access and tamper resistant circuit block, a first random private key is generated. A corresponding public key of the first random private key is derived, and a cryptographic digest of the public key and attributes associated with the first random private key is generated. The generated cryptographic digest is signed using a second random private key that has been designated for signing by one or more associated attributes. The public key and the signature are then sent to the communication partner via the interface.

Abstract: A TPM is implemented in an SOC for thwarting PIN state replay attacks. Programmable fuses are used as a counter and an on-die RAM stores a blown-fuse count and a TPM state that includes a PIN-failure count and a fuse count. TPM initialization includes incrementing the TPM state PIN-failure count if the blown-fuse count is greater than the TPM state fuse count. Once a PIN is received, if the TPM state PIN-failure count satisfies a PIN failure policy and the PIN is correct, the TPM state PIN-failure count is cleared, and if the PIN is incorrect, a fuse is blown and the blown-fuse count is incremented. If the fuse blow fails, TPM activity is halted. If the fuse blow succeeds, the TPM state PIN-failure count is incremented and the TPM state fuse count is set equal to the blown-fuse count. The TPM state is saved to off-die non-volatile memory.

Abstract: A method for secure key exchange. The method comprises receiving a request to certify a key from a communication partner at an interface between an access and tamper resistant circuit block and exposed circuitry. Within the access and tamper resistant circuit block, a first random private key is generated. A corresponding public key of the first random private key is derived, and a cryptographic digest of the public key and attributes associated with the first random private key is generated. The generated cryptographic digest is signed using a second random private key that has been designated for signing by one or more associated attributes. The public key and the signature are then sent to the communication partner via the interface.

Abstract: Methods, systems, apparatuses, and computer-readable storage mediums described herein enable executable code of a hardware security platform (HSP) circuit to communicate with a hypervisor in a separate processor. The hypervisor generates and manages virtual machines. The HSP code comprises trusted platform module (TPM) logic, that processes TPM commands received via the hypervisor, and in response to the processing, communicates security information (e.g., measurements, keys, authorization data) with the virtual machines via the hypervisor. The TPM logic receives security information related to a virtual machine from the hypervisor and stores the security information in non-volatile memory of the HSP circuit, where security information from a particular VM is distinguishable from security information from another VM in the HSP memory.

Abstract: This disclosure describes systems and methods for protecting commercial off-the-shelf software program code from piracy. A software program may include an executable file having code and data. A platform may modify the executable file such that the data may be placed at a location in memory that is an arbitrary distance from the code. The platform may modify the executable file to include a separation header. The separation header may indicate that the data can be placed at an arbitrary distance in the memory from the code. The separation header may indicate that the code should be loaded into a hardware enclave and that the data should be loaded outside of the hardware enclave. The platform may encrypt the code and provide it to a computing device. The computing device may load the encrypted code into the hardware enclave but load the data into memory outside the hardware enclave.

Abstract: Embodiments described herein are directed to firmware policy enforcement of a computing device. For example, a security processor of the computing device is utilized to boot the computing device. During a boot session, the security processor loads and executes specialized firmware. The specialized firmware, when executed, causes the security processor to determine whether other types of firmware to be executed on the computing device is in compliance with a policy specified by the specialized firmware. Based at least on a determination that the other firmware is in compliance with the policy, the security processor executes the other firmware. Based at least on a determination that the other firmware is not in compliance with the policy, the security processor performs a mitigation with respect to the other firmware.

Abstract: Embodiments described herein are directed to transferring the ownership of a computing device from one entity to another entity. For example, a security processor is utilized to boot the computing device. During a boot session, the security processor loads and executes boot code, which determines whether specialized firmware authorized by the current owner indicates whether a transfer of ownership is to occur. In response to determining that the specialized firmware indicates that a transfer of ownership is to occur, the secure processor loads and executes the specialized firmware. The specialized firmware, when executed, causes the security processor to program a set of fuses with the public key of the new owner. Execution of the specialized firmware also causes the security processor to invalidate the public key of the original owner, which is stored in another set of fuses.

Abstract: This disclosure describes systems and methods for protecting commercial off-the-shelf software program code from piracy. A software program may include multiple image files having code and data. A platform may modify the executable file such that the data may be placed at a location in memory that is an arbitrary distance from the code. The platform may encrypt the code and provide it to a computing device comprising a hardware enclave. The computing device may load the encrypted code into the hardware enclave but load the data into memory outside the hardware enclave. The computing device may request a decryption key from an authentication server using a hash of the hardware enclave signed by a processor. The authentication server may provide the decryption key if it verifies the signature and the hash. The computing device may decrypt the code and mark the hardware enclave as non-readable.

Abstract: A TPM with programmable fuses in an SOC includes an on-die RAM storing a blown-fuse count and a TPM state read from off-die NV memory. During initialization, if the blown-fuse count is greater than a TPM state fuse count, a TPM state PIN-attempt-failure count is incremented, thereby thwarting a replay attack. If a PIN satisfies a PIN failure policy, and if a TPM state previously-passed-PIN indicator is set to true, a fuse is blown and the blown-fuse count incremented depending on the PIN being incorrect, but if the TPM state previously-passed-PIN indicator is set to false, a fuse is blown and the blown-fuse count incremented independent of whether the PIN is correct or incorrect. The TPM state fuse count is set equal to the blown-fuse count. If a counter cleared before processing the PIN remains cleared during the next initialization, a fuse voltage cut is detected and a penalty imposed.

Abstract: A TPM is implemented in an SOC for thwarting PIN state replay attacks. Programmable fuses are used as a counter and an on-die RAM stores a blown-fuse count and a TPM state that includes a PIN-failure count and a fuse count. TPM initialization includes incrementing the TPM state PIN-failure count if the blown-fuse count is greater than the TPM state fuse count. Once a PIN is received, if the TPM state PIN-failure count satisfies a PIN failure policy and the PIN is correct, the TPM state PIN-failure count is cleared, and if the PIN is incorrect, a fuse is blown and the blown-fuse count is incremented. If the fuse blow fails, TPM activity is halted. If the fuse blow succeeds, the TPM state PIN-failure count is incremented and the TPM state fuse count is set equal to the blown-fuse count. The TPM state is saved to off-die non-volatile memory.

Abstract: A TPM with programmable fuses in an SOC includes an on-die RAM storing a blown-fuse count and a TPM state including a PIN-attempt-failure count and a fuse count, read from off-die NV memory. During initialization, if the blown-fuse count is greater than TPM state fuse count, TPM state PIN-attempt-failure count is incremented, thereby thwarting a replay attack. A PIN is received for access, and if the TPM state PIN-attempt-failure count satisfies a policy, a fuse is blown and the blown-fuse count incremented. If the fuse blow fails, TPM activity is halted. If the fuse blow succeeds and the PIN is correct, the TPM state PIN-attempt-failure count is cleared, but if the PIN is incorrect the TPM state PIN-attempt-failure count is incremented. TPM state fuse count is set equal to the blown-fuse count, and the TPM state is saved to off-die NV memory.

Abstract: A method for secure key exchange. The method comprises receiving a request to certify a key from a communication partner at an interface between an access and tamper resistant circuit block and exposed circuitry. Within the access and tamper resistant circuit block, a first random private key is generated. A corresponding public key of the first random private key is derived, and a cryptographic digest of the public key and attributes associated with the first random private key is generated. The generated cryptographic digest is signed using a second random private key that has been designated for signing by one or more associated attributes. The public key and the signature are then sent to the communication partner via the interface.