Linux UEFI TPM 2.0 security impacts
203 views
Skip to first unread message
Cube
Dec 17, 2015, 8:43:18 AM12/17/15
to qubes-users
Thoughts?
https://plus.google.com/+GuidoStepken/posts/XZsgDcuairt
https://plus.google.com/+GuidoStepken/posts/XZsgDcuairt
The "security chain" begins with one or more TPM 2.0 "Endorsement Keys" (EK), that are stored on the motherboard and that cannot be overwritten without "allowance" by either the owner (hardware manufacturer) or somebody, that is "higher" in key hierarchy, such as Microsoft or U.S. government authorities.
Key Exchange Keys (KEK) establish a trust relationship between the operating system and the platform firmware. Each operating system (and potentially each 3rd party application, that needs to communicate with platform firmware) enrolls a public key (KEKpub) into the platform firmware.
When your hardware comes "Windows Certified", the "Endorsement Key" already is initialized, is signed by Microsoft and U.S. authorities.
"Windows certified" here automatically means "NSA backdoor" included and activated in all encryption modules.
Tim W
Dec 18, 2015, 2:28:38 AM12/18/15
to qubes-users
Most of what is in that article has been greatly sensationalize and reading the other articles it seems a standard theme. But thats just my personal opinion.
Do not get me wrong there are some serious possible issues with TPM 2.0 but also some improvements that were more issues in 1.2. I will post the changes below.
But I think it will be very self evident where the issues lie. Again it will come down to who or what are your perceived threats. One thing for sure though the biggest one is the allowablity of fundamental changes to the TPM functions to include its RNG and crypto algorithms by anyone other than the consumer owner as oppose to the platform owner (manufacturer)
On the otherside is much better privacy for remote attestation as its local control instead of third party cert authorities which have been broken for years in terms of real security.
I have attached the full paper that the quotes below are from for complete reading. It gives a good overview of the comparison of TPM 1.2 vs 2.0 and UEFI and its impact on security and freedom.
"No Opt-in/Opt-out:
The 1.2 version and earlier versions explicitly demanded the TPM to be disabled when the device was shipped to the customer. The user had to enable the chip in his computer’s BIOS and perform a take ownership of the TPM before it could be used. The 2.0 specification allows it to ship already operating TPMs with a device. Even more the user might not be able to deactivate the TPM since the specification says that “The platform manufacturer decides whether or not the Owner can disable the platform’s use of the TPM.
The 1.2 version and earlier versions explicitly demanded the TPM to be disabled when the device was shipped to the customer. The user had to enable the chip in his computer’s BIOS and perform a take ownership of the TPM before it could be used. The 2.0 specification allows it to ship already operating TPMs with a device. Even more the user might not be able to deactivate the TPM since the specification says that “The platform manufacturer decides whether or not the Owner can disable the platform’s use of the TPM.
Seeds and Keys:
The 1.2 specification defined two keys to be stored inside of the TPM, the SRK and the EK. The 2.0 specification replaces those with seeds, large numbers created by the RNG of the TPM, to allow a greater flexibility in choice of algorithms. The EPS and SPS respectively are used in conjunction with a Key Derivation Function (KDF) to create one or more EKs and SRKs. The 1.2 specification allowed only one EK and one SRK. Also a third persistent seed was added, the Platform Primary Seed (PPS) 3. The EPS, SPS and PPS are under the control domain of the endorsementAuth, ownerAuth and platformAuth respectively. TPM 2.0 further introduces ephemeral keys, keys that are generated inside of the TPM and can be used only once. They are used in Elliptic Curve Cryptography (ECC) based Direct Anonymous Attestation (DAA).
Algorithm Flexibility:
In previous versions of the specifications all algorithms to be used for specific functions of the TPM were fixed. TPM 2.0 allows greater flexibility and even “field upgrades” to the algorithms that the TPM supports.
Remote Attestation (RA):
A TPM compliant with the 1.2 specification had a single, non-erasable EK. This EK was linked to a platform certificate that could be used to prove the validity of the TPM to a remote party. Since the EK was bound to the platform, PCR data was never signed with the EK directly but with an Attestation Identity Key (AIK) – a key provided and signed by a trusted third party that vouched for the authenticity of the TPM. This way the identity of the platform was no longer contained in the quoted data, which is crucial for privacy. The TPM 2.0 specifications now go a different way. EKs are not obligatorily linked to the platform certificate anymore. That means that EKs do not necessarily contain the platform identity. The 2.0 specification, however, strongly promotes ECC-based Direct Anonymous Attestation (ECDAA) as an alternative, a method that allows strong privacy.
Ownership Hierarchies:
Prior to the 2.0 specifications there was but a single owner of the TPM or the platform for that matter. Whoever took ownership of the TPM had full control over the platform. Since TPMs were shipped witout an owner (Opt-in), the purchaser was the exclusive owner of the platform. Now, since the platform firmware has authority to add, update or exchange algorithms (that means executable code) on the TPM, great care must be taken no unauthorized person can take control over this role. Otherwise trust in TPM supplied data would be shattered fundamentally. As a consequence the firmware role will always be outside of the domain of the control of the owner. With the firmware hierarchy having other extensive rights, platform ownership now is somewhat divided between the PM and the owner."
Credit and quotes from:
Fachhochschule Hannover - University of Applied Sciences and ArtsFaculty IV - Business and Computer Science Department of Computer Science"TPM 2.0, UEFI and their Impact on Security and Users' Freedom"A thesis Submitted in partial fulfillment of requirements fro the degree of Master of Science by Thomas Rossow
The 1.2 specification defined two keys to be stored inside of the TPM, the SRK and the EK. The 2.0 specification replaces those with seeds, large numbers created by the RNG of the TPM, to allow a greater flexibility in choice of algorithms. The EPS and SPS respectively are used in conjunction with a Key Derivation Function (KDF) to create one or more EKs and SRKs. The 1.2 specification allowed only one EK and one SRK. Also a third persistent seed was added, the Platform Primary Seed (PPS) 3. The EPS, SPS and PPS are under the control domain of the endorsementAuth, ownerAuth and platformAuth respectively. TPM 2.0 further introduces ephemeral keys, keys that are generated inside of the TPM and can be used only once. They are used in Elliptic Curve Cryptography (ECC) based Direct Anonymous Attestation (DAA).
Algorithm Flexibility:
In previous versions of the specifications all algorithms to be used for specific functions of the TPM were fixed. TPM 2.0 allows greater flexibility and even “field upgrades” to the algorithms that the TPM supports.
Remote Attestation (RA):
A TPM compliant with the 1.2 specification had a single, non-erasable EK. This EK was linked to a platform certificate that could be used to prove the validity of the TPM to a remote party. Since the EK was bound to the platform, PCR data was never signed with the EK directly but with an Attestation Identity Key (AIK) – a key provided and signed by a trusted third party that vouched for the authenticity of the TPM. This way the identity of the platform was no longer contained in the quoted data, which is crucial for privacy. The TPM 2.0 specifications now go a different way. EKs are not obligatorily linked to the platform certificate anymore. That means that EKs do not necessarily contain the platform identity. The 2.0 specification, however, strongly promotes ECC-based Direct Anonymous Attestation (ECDAA) as an alternative, a method that allows strong privacy.
Ownership Hierarchies:
Prior to the 2.0 specifications there was but a single owner of the TPM or the platform for that matter. Whoever took ownership of the TPM had full control over the platform. Since TPMs were shipped witout an owner (Opt-in), the purchaser was the exclusive owner of the platform. Now, since the platform firmware has authority to add, update or exchange algorithms (that means executable code) on the TPM, great care must be taken no unauthorized person can take control over this role. Otherwise trust in TPM supplied data would be shattered fundamentally. As a consequence the firmware role will always be outside of the domain of the control of the owner. With the firmware hierarchy having other extensive rights, platform ownership now is somewhat divided between the PM and the owner."
Credit and quotes from:
Fachhochschule Hannover - University of Applied Sciences and ArtsFaculty IV - Business and Computer Science Department of Computer Science"TPM 2.0, UEFI and their Impact on Security and Users' Freedom"A thesis Submitted in partial fulfillment of requirements fro the degree of Master of Science by Thomas Rossow
Reply all
Reply to author
Forward
0 new messages