From b855069e82cafeec770e7bd1d470a14302aadcb1 Mon Sep 17 00:00:00 2001 From: Tommy Date: Mon, 10 Jun 2024 20:57:12 -0700 Subject: [PATCH 01/20] Misinformation on x86 Hardware Signed-off-by: Tommy --- .../Misinformation on x86 Hardware/index.md | 67 +++++++++++++++++++ content/posts/hardware/_index.md | 7 ++ 2 files changed, 74 insertions(+) create mode 100644 content/posts/hardware/Misinformation on x86 Hardware/index.md create mode 100644 content/posts/hardware/_index.md diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md new file mode 100644 index 0000000..5de6be3 --- /dev/null +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -0,0 +1,67 @@ + +--- +title: "Misinformation on x86 Hardware" +date: 2024-06-10 +tags: ['Hardware', 'Security'] +author: Tommy +--- + +While browsing privacy forums, I often see a lot discussions regarding x86 hardware security features. Unfortunately, most of the threads are riped with misinformation. In this post, I will bad advices I have seen. + +### Intel CSME and AMD PSP + +A very common misinformation among privacy communities is that the Intel Management Engine (ME), its sucessor - [Intel Converged Security and Management Engine (CSME)](https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf), and the AMD Platform Security Processor (PSP) are some sort of evil backdoor. Some may go so far as to tell other users to "disable the ME" or to "buy hardware with the ME disabled". + +The problem with these recommendations are as follows: + +Intel CSME provides critical security features, including: +- [Boot Guard](https://networkbuilders.intel.com/docs/networkbuilders/secure-the-network-infrastructure-secure-boot-methodologies.pdf) - The basis of Static Root of Trust Measurement. It verifies that a significant portion of your EEPROM is signed by your OEM, and provides fuses to prevent downgrade attacks to old, vulnerable versions. +- [Platform Trust Technology](https://www.intel.com/content/www/us/en/support/articles/000094205/processors/intel-core-processors.html) - An firmware TPM implementation. Generally, fTPMs have better security properties when compared to dTPMs, as they stay on the same die as the CPU and are immune to bus sniffing attacks. + +AMD PSP provides its own set of secrity features: +- Firmware TPM - serving the same role as Intel's Platform Trust Technology. +- Secure Encryption Virtualization (on Ryzen Pro and EPYC CPUs). SEV protects both the hypervisor from cold boot attacks and making VM break outs much more difficult. + +By buying hardware with Intel CSME disabled, you are **increasing the attack surface** by not having Boot Guard to protect your firmware. Additionally, if you buy hardware so old that you can run `me_cleaner` to disable the ME yourself, it means that these hardware do not have Boot Guard to begin with. In both cases, you will end up with a piece of hardware with no root of trust, and any attempt to implement firmware security will be futile. + +I am not aware of any way to disable AMD PSP, but even if this was possible, all that it does is to deprive you of useful security features. + +This excercise also achieves absolutely nothing to protect against a hypothetical scenario where Intel and AMD are malicious. Intel and AMD do not need the co-processor to implement a backdoor - they can simply introduce CPU vulnerabilities like Spectre and Meltdown if they want to. If you do not trust a CPU vendor, the only mitigation is to not use said vendor. + +### Intel AMT and AMD DASH + +Another misinformation regarding CSME is that it is provides some kind of [shady "remote management" system](https://www.fsf.org/blogs/community/active-management-technology) for your computer. In reality, this is the AMT component which only exists on Intel vPro CPUs. It is meant for IT teams to manage systems with technologies like Serial over LAN, Solarwind, etc. + +Here are some facts about it: +- You can disable it firmware settings. +- Certain firmware allows you to permanently disable it by blowing an eFuse. +- It is detectable. An easy way is to just go visit port 16992/tcp on your device. +- To be extra sure, you can also run `nmap` to scan the port from a different device. + +This is not something hidden, people have accidentally [run into AMT](https://mastodon.lilysthings.org/@i_lost_my_bagel/112228352384742242) on social media. + +For attack surface reduction, you should absolutely disable it. If you do not have a vPro laptop and are curious what this looks like, have a look at the [BIOS Simulator for the Thinkpad T14 Gen 5](https://download.lenovo.com/bsco/#/graphicalsimulator/ThinkPad%20T14%20Gen%205%20(21ML,21MM)). + +With that said, don't let the scary claims about "remote management" by the spook you - if some sort of hypothetical backdoor is actually implemented this way, it will not be hard to detect it. There are better ways to implement a backdoor as discussed above, and if you don't trust the CPU vendor you should avoid them as a whole, not just the vPro model. + +Some people recommend buying AMD instead of Intel to avoid the possibility of having Intel AMT. However, they also miss a very simple fact that AMD has an equivalent technology for their Ryzen Pro CPU - [AMD DASH](https://www.amd.com/system/files/documents/out-of-band-client-management-overview.pdf). + +### Intel vPro + +On the topic of AMT, a lot of people seem to think that vPro is all about AMT and that regular users do not need it. This is far from the truth. Intel vPro Enterprise provides other features that are absolutely relevant outside of corporate usecases: + +- Total Memory Encryption - Multi Key. This is AMD SEV's Intel counterpart - it provides memory encryption to protect the host from cold boot attacks and make VM break outs harder. This is a mandatory requirement to meet HSI level 4 on Linux. +- Intel Key Locker - This feature makes it possible to encrypt and decrypt data with an AES key using a key handle instead of the actual encryption key. A key handle can be revoked when the system state changes, such as with a reboot. This feature is not widely used on Linux, although it is already available on Chromebooks with vPro Enterprise. +- Intel Trusted Execution Technology (TXT). This feature implements Dynamic Root of Trust Measurement (DRTM) and is necessary for [System Guard](https://learn.microsoft.com/en-us/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows) on Windows. It is a pre-requisite for the Secure-cored certification. On Linux, DRTM is not widely used, but Trenchboot is being developed to address that. + +It is always best to buy a vPro Enterprise CPU to enjoy all of the security features that Intel has to offer. AMT comes with vPro and is attack surface, but it can easily be disabled as I discussed above. + +### Restricted Boot + +Another false claim regarding Secure Boot is that UEFI Secure Boot is somehow Microsoft's evil attempt to lock users out of their computer by only allowing it to run Microsoft approved software. + +In reality, most if not all laptops with UEFI Secure Boot allows you to disable it - you can run whichever operating system you want. While it is true that certain lines of laptops like Razer do not allow custom key enrollment, proper business laptops like Dell Latitude/Precision and Lenovo Thinkpad do. You can enroll your own Secure Boot key and tell your laptop to boot only the system you trust. + +Another benefit of laptops with Microsoft's Secure-cored certification is that you can have the **Freedom** to disable the Microsoft Secure Boot Third-Party Certificate Authority and still have the laptop function normally. This is especially handy if you plan to run Windows as your operating system. + +UEFI Secure Boot is not [Restricted Boot](https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web). It is a building block of SRTM and how you can build a secure boot environment. \ No newline at end of file diff --git a/content/posts/hardware/_index.md b/content/posts/hardware/_index.md new file mode 100644 index 0000000..a97cbca --- /dev/null +++ b/content/posts/hardware/_index.md @@ -0,0 +1,7 @@ +--- +title: Hardware +ShowReadingTime: false +ShowWordCount: false +--- + +A collection of posts about general hardware security. From f53704d2e01f3fcee3c7b93a59a3855c7aecde1e Mon Sep 17 00:00:00 2001 From: Tommy Date: Mon, 10 Jun 2024 21:19:15 -0700 Subject: [PATCH 02/20] Update Signed-off-by: Tommy --- .../hardware/Misinformation on x86 Hardware/index.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 5de6be3..13e16b5 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -20,7 +20,7 @@ Intel CSME provides critical security features, including: AMD PSP provides its own set of secrity features: - Firmware TPM - serving the same role as Intel's Platform Trust Technology. -- Secure Encryption Virtualization (on Ryzen Pro and EPYC CPUs). SEV protects both the hypervisor from cold boot attacks and making VM break outs much more difficult. +- [Secure Encryption Virtualization](https://www.amd.com/en/developer/sev.html) (on Ryzen Pro and EPYC CPUs). SEV protects both the hypervisor from cold boot attacks and making VM break outs much more difficult. By buying hardware with Intel CSME disabled, you are **increasing the attack surface** by not having Boot Guard to protect your firmware. Additionally, if you buy hardware so old that you can run `me_cleaner` to disable the ME yourself, it means that these hardware do not have Boot Guard to begin with. In both cases, you will end up with a piece of hardware with no root of trust, and any attempt to implement firmware security will be futile. @@ -30,7 +30,7 @@ This excercise also achieves absolutely nothing to protect against a hypothetica ### Intel AMT and AMD DASH -Another misinformation regarding CSME is that it is provides some kind of [shady "remote management" system](https://www.fsf.org/blogs/community/active-management-technology) for your computer. In reality, this is the AMT component which only exists on Intel vPro CPUs. It is meant for IT teams to manage systems with technologies like Serial over LAN, Solarwind, etc. +Another piece of misinformation regarding CSME is that it is provides some kind of [shady "remote management" system](https://www.fsf.org/blogs/community/active-management-technology) for your computer. In reality, this is the AMT component which only exists on Intel vPro CPUs. It is meant for IT teams to manage systems with technologies like Serial over LAN, Solarwind, etc. Here are some facts about it: - You can disable it firmware settings. @@ -54,14 +54,14 @@ On the topic of AMT, a lot of people seem to think that vPro is all about AMT an - Intel Key Locker - This feature makes it possible to encrypt and decrypt data with an AES key using a key handle instead of the actual encryption key. A key handle can be revoked when the system state changes, such as with a reboot. This feature is not widely used on Linux, although it is already available on Chromebooks with vPro Enterprise. - Intel Trusted Execution Technology (TXT). This feature implements Dynamic Root of Trust Measurement (DRTM) and is necessary for [System Guard](https://learn.microsoft.com/en-us/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows) on Windows. It is a pre-requisite for the Secure-cored certification. On Linux, DRTM is not widely used, but Trenchboot is being developed to address that. -It is always best to buy a vPro Enterprise CPU to enjoy all of the security features that Intel has to offer. AMT comes with vPro and is attack surface, but it can easily be disabled as I discussed above. +It is always best to buy a vPro Enterprise CPU to enjoy all of the security features that Intel has to offer. AMT comes with vPro and is attack surface, but it can easily be disabled as discussed above. ### Restricted Boot -Another false claim regarding Secure Boot is that UEFI Secure Boot is somehow Microsoft's evil attempt to lock users out of their computer by only allowing it to run Microsoft approved software. +A false claim popularized by the Free Software Foundation is that Secure Boot is somehow [Microsoft's evil attempt to lock users out of their computer by only allowing it to run Microsoft approved software](https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web). In reality, most if not all laptops with UEFI Secure Boot allows you to disable it - you can run whichever operating system you want. While it is true that certain lines of laptops like Razer do not allow custom key enrollment, proper business laptops like Dell Latitude/Precision and Lenovo Thinkpad do. You can enroll your own Secure Boot key and tell your laptop to boot only the system you trust. -Another benefit of laptops with Microsoft's Secure-cored certification is that you can have the **Freedom** to disable the Microsoft Secure Boot Third-Party Certificate Authority and still have the laptop function normally. This is especially handy if you plan to run Windows as your operating system. +Microsoft even went further to make sure that Secure Boot better for end users. Computers with their Secure-Cored certification provides users with the **Freedom** to disable the Microsoft Secure Boot Third Party Certificate Authority and still have the computers function normally. They protect the users from having to sign and trust random proprietary OptionRoms. It is great for both users who want to use Windows as their primary system and users who plan to set up a proper Secure Boot system with Linux. -UEFI Secure Boot is not [Restricted Boot](https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web). It is a building block of SRTM and how you can build a secure boot environment. \ No newline at end of file +UEFI Secure Boot is not Restricted Boot. It is a building block of Static Root of Trust Measurememnt and step towards building a secure boot environment. \ No newline at end of file From aa08041a4a416f98b0c235cf966067d7464fc831 Mon Sep 17 00:00:00 2001 From: Tommy Date: Mon, 10 Jun 2024 21:23:38 -0700 Subject: [PATCH 03/20] Fun Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 13e16b5..1da3ce5 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -62,6 +62,6 @@ A false claim popularized by the Free Software Foundation is that Secure Boot is In reality, most if not all laptops with UEFI Secure Boot allows you to disable it - you can run whichever operating system you want. While it is true that certain lines of laptops like Razer do not allow custom key enrollment, proper business laptops like Dell Latitude/Precision and Lenovo Thinkpad do. You can enroll your own Secure Boot key and tell your laptop to boot only the system you trust. -Microsoft even went further to make sure that Secure Boot better for end users. Computers with their Secure-Cored certification provides users with the **Freedom** to disable the Microsoft Secure Boot Third Party Certificate Authority and still have the computers function normally. They protect the users from having to sign and trust random proprietary OptionRoms. It is great for both users who want to use Windows as their primary system and users who plan to set up a proper Secure Boot system with Linux. +Microsoft even went further to make Secure Boot better for end users. Computers with their Secured-core certification provides users with the **Freedom** to disable the Microsoft Secure Boot Third Party Certificate Authority and still have the computers function normally. They protect the users from having to sign and trust random **proprietary Option ROMS**. It is great for both users who want to use Windows as their primary system and users who plan to set up a proper Secure Boot system with Linux. UEFI Secure Boot is not Restricted Boot. It is a building block of Static Root of Trust Measurememnt and step towards building a secure boot environment. \ No newline at end of file From a40ee7a4fab200d6fb975f7d37a5b5bc5e76c8bf Mon Sep 17 00:00:00 2001 From: Tommy Date: Mon, 10 Jun 2024 21:24:14 -0700 Subject: [PATCH 04/20] Better Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 1da3ce5..909845b 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -62,6 +62,6 @@ A false claim popularized by the Free Software Foundation is that Secure Boot is In reality, most if not all laptops with UEFI Secure Boot allows you to disable it - you can run whichever operating system you want. While it is true that certain lines of laptops like Razer do not allow custom key enrollment, proper business laptops like Dell Latitude/Precision and Lenovo Thinkpad do. You can enroll your own Secure Boot key and tell your laptop to boot only the system you trust. -Microsoft even went further to make Secure Boot better for end users. Computers with their Secured-core certification provides users with the **Freedom** to disable the Microsoft Secure Boot Third Party Certificate Authority and still have the computers function normally. They protect the users from having to sign and trust random **proprietary Option ROMS**. It is great for both users who want to use Windows as their primary system and users who plan to set up a proper Secure Boot system with Linux. +Microsoft even went further to make Secure Boot better for end users. Computers with their Secured-core certification provides users with the **Freedom** to disable the Microsoft Secure Boot Third Party Certificate Authority and still have the computers function normally. They **protect** the users from having to sign and trust random **proprietary Option ROMS**. It is great for both users who want to use Windows as their primary system and users who plan to set up a proper Secure Boot system with Linux. UEFI Secure Boot is not Restricted Boot. It is a building block of Static Root of Trust Measurememnt and step towards building a secure boot environment. \ No newline at end of file From 8b7f18708dfb5e3e611232e1d40935134285ef5b Mon Sep 17 00:00:00 2001 From: Tommy Date: Mon, 10 Jun 2024 21:30:47 -0700 Subject: [PATCH 05/20] typo fix Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 909845b..975e22f 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -52,7 +52,7 @@ On the topic of AMT, a lot of people seem to think that vPro is all about AMT an - Total Memory Encryption - Multi Key. This is AMD SEV's Intel counterpart - it provides memory encryption to protect the host from cold boot attacks and make VM break outs harder. This is a mandatory requirement to meet HSI level 4 on Linux. - Intel Key Locker - This feature makes it possible to encrypt and decrypt data with an AES key using a key handle instead of the actual encryption key. A key handle can be revoked when the system state changes, such as with a reboot. This feature is not widely used on Linux, although it is already available on Chromebooks with vPro Enterprise. -- Intel Trusted Execution Technology (TXT). This feature implements Dynamic Root of Trust Measurement (DRTM) and is necessary for [System Guard](https://learn.microsoft.com/en-us/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows) on Windows. It is a pre-requisite for the Secure-cored certification. On Linux, DRTM is not widely used, but Trenchboot is being developed to address that. +- Intel Trusted Execution Technology (TXT). This feature implements Dynamic Root of Trust Measurement (DRTM) and is necessary for [System Guard](https://learn.microsoft.com/en-us/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows) on Windows. It is a pre-requisite for the Secured-core certification. On Linux, DRTM is not widely used, but Trenchboot is being developed to address that. It is always best to buy a vPro Enterprise CPU to enjoy all of the security features that Intel has to offer. AMT comes with vPro and is attack surface, but it can easily be disabled as discussed above. From 51518f8a8e039c76e1c00be86a40eeacdbcb7a6b Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 14:12:01 -0700 Subject: [PATCH 06/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 975e22f..9eb3b9d 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -10,7 +10,7 @@ While browsing privacy forums, I often see a lot discussions regarding x86 hardw ### Intel CSME and AMD PSP -A very common misinformation among privacy communities is that the Intel Management Engine (ME), its sucessor - [Intel Converged Security and Management Engine (CSME)](https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf), and the AMD Platform Security Processor (PSP) are some sort of evil backdoor. Some may go so far as to tell other users to "disable the ME" or to "buy hardware with the ME disabled". +A very common piece of misinformation among privacy communities is that the Intel Management Engine (ME), its sucessor - [Intel Converged Security and Management Engine (CSME)](https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf), and the AMD Platform Security Processor (PSP) are some sort of evil backdoor. Some may go so far as to tell other users to "disable the ME" or to "buy hardware with the ME disabled". The problem with these recommendations are as follows: From 1c24b87e7a5adb62d58d92e42bfaafa36b9c7684 Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 14:12:19 -0700 Subject: [PATCH 07/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 9eb3b9d..393e328 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -12,7 +12,7 @@ While browsing privacy forums, I often see a lot discussions regarding x86 hardw A very common piece of misinformation among privacy communities is that the Intel Management Engine (ME), its sucessor - [Intel Converged Security and Management Engine (CSME)](https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf), and the AMD Platform Security Processor (PSP) are some sort of evil backdoor. Some may go so far as to tell other users to "disable the ME" or to "buy hardware with the ME disabled". -The problem with these recommendations are as follows: +The problems with these recommendations are as follows: Intel CSME provides critical security features, including: - [Boot Guard](https://networkbuilders.intel.com/docs/networkbuilders/secure-the-network-infrastructure-secure-boot-methodologies.pdf) - The basis of Static Root of Trust Measurement. It verifies that a significant portion of your EEPROM is signed by your OEM, and provides fuses to prevent downgrade attacks to old, vulnerable versions. From 20d6fbaa878d60695a171a6f5391585a4cc7981f Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 14:13:22 -0700 Subject: [PATCH 08/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 393e328..59c48cc 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -42,7 +42,7 @@ This is not something hidden, people have accidentally [run into AMT](https://ma For attack surface reduction, you should absolutely disable it. If you do not have a vPro laptop and are curious what this looks like, have a look at the [BIOS Simulator for the Thinkpad T14 Gen 5](https://download.lenovo.com/bsco/#/graphicalsimulator/ThinkPad%20T14%20Gen%205%20(21ML,21MM)). -With that said, don't let the scary claims about "remote management" by the spook you - if some sort of hypothetical backdoor is actually implemented this way, it will not be hard to detect it. There are better ways to implement a backdoor as discussed above, and if you don't trust the CPU vendor you should avoid them as a whole, not just the vPro model. +With that said, don't let the scary claims about "remote management" spook you --- if some sort of hypothetical backdoor is actually implemented this way, it will not be hard to detect. There are better ways to implement a backdoor as discussed above, and if you don't trust the CPU vendor you should avoid them as a whole, not just the vPro models. Some people recommend buying AMD instead of Intel to avoid the possibility of having Intel AMT. However, they also miss a very simple fact that AMD has an equivalent technology for their Ryzen Pro CPU - [AMD DASH](https://www.amd.com/system/files/documents/out-of-band-client-management-overview.pdf). From 363796aa8ae30c599d02c65cd18defa287ebfaa8 Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 20:41:04 -0700 Subject: [PATCH 09/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 59c48cc..aa2403e 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -18,7 +18,7 @@ Intel CSME provides critical security features, including: - [Boot Guard](https://networkbuilders.intel.com/docs/networkbuilders/secure-the-network-infrastructure-secure-boot-methodologies.pdf) - The basis of Static Root of Trust Measurement. It verifies that a significant portion of your EEPROM is signed by your OEM, and provides fuses to prevent downgrade attacks to old, vulnerable versions. - [Platform Trust Technology](https://www.intel.com/content/www/us/en/support/articles/000094205/processors/intel-core-processors.html) - An firmware TPM implementation. Generally, fTPMs have better security properties when compared to dTPMs, as they stay on the same die as the CPU and are immune to bus sniffing attacks. -AMD PSP provides its own set of secrity features: +AMD PSP provides its own set of security features: - Firmware TPM - serving the same role as Intel's Platform Trust Technology. - [Secure Encryption Virtualization](https://www.amd.com/en/developer/sev.html) (on Ryzen Pro and EPYC CPUs). SEV protects both the hypervisor from cold boot attacks and making VM break outs much more difficult. From 7c38c5f5c0808a94d508dc758df71fb2530d56d8 Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 20:41:21 -0700 Subject: [PATCH 10/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index aa2403e..5bb45e2 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -20,7 +20,7 @@ Intel CSME provides critical security features, including: AMD PSP provides its own set of security features: - Firmware TPM - serving the same role as Intel's Platform Trust Technology. -- [Secure Encryption Virtualization](https://www.amd.com/en/developer/sev.html) (on Ryzen Pro and EPYC CPUs). SEV protects both the hypervisor from cold boot attacks and making VM break outs much more difficult. +- [Secure Encryption Virtualization](https://www.amd.com/en/developer/sev.html) (on Ryzen Pro and EPYC CPUs). SEV both protects the hypervisor from cold boot attacks and makes VM break outs much more difficult. By buying hardware with Intel CSME disabled, you are **increasing the attack surface** by not having Boot Guard to protect your firmware. Additionally, if you buy hardware so old that you can run `me_cleaner` to disable the ME yourself, it means that these hardware do not have Boot Guard to begin with. In both cases, you will end up with a piece of hardware with no root of trust, and any attempt to implement firmware security will be futile. From e7ca0f066c945ac302e565a5ba7d9c87a4ad1f43 Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 20:41:31 -0700 Subject: [PATCH 11/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 5bb45e2..b8d3b6d 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -44,7 +44,7 @@ For attack surface reduction, you should absolutely disable it. If you do not ha With that said, don't let the scary claims about "remote management" spook you --- if some sort of hypothetical backdoor is actually implemented this way, it will not be hard to detect. There are better ways to implement a backdoor as discussed above, and if you don't trust the CPU vendor you should avoid them as a whole, not just the vPro models. -Some people recommend buying AMD instead of Intel to avoid the possibility of having Intel AMT. However, they also miss a very simple fact that AMD has an equivalent technology for their Ryzen Pro CPU - [AMD DASH](https://www.amd.com/system/files/documents/out-of-band-client-management-overview.pdf). +Some people recommend buying AMD instead of Intel to avoid the possibility of having Intel AMT. However, they also overlook the very simple fact that AMD has an equivalent technology for their Ryzen Pro CPU: [AMD DASH](https://www.amd.com/system/files/documents/out-of-band-client-management-overview.pdf). ### Intel vPro From 54381adda4a1e54c8c05f23320935e1dcfe49588 Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 20:41:42 -0700 Subject: [PATCH 12/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index b8d3b6d..3627e8c 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -64,4 +64,4 @@ In reality, most if not all laptops with UEFI Secure Boot allows you to disable Microsoft even went further to make Secure Boot better for end users. Computers with their Secured-core certification provides users with the **Freedom** to disable the Microsoft Secure Boot Third Party Certificate Authority and still have the computers function normally. They **protect** the users from having to sign and trust random **proprietary Option ROMS**. It is great for both users who want to use Windows as their primary system and users who plan to set up a proper Secure Boot system with Linux. -UEFI Secure Boot is not Restricted Boot. It is a building block of Static Root of Trust Measurememnt and step towards building a secure boot environment. \ No newline at end of file +UEFI Secure Boot is not Restricted Boot. It is a building block of Static Root of Trust Measurement and a step towards building a secure boot environment. \ No newline at end of file From bee6f704c71c0e2edffb32542cb38aed3b294f5d Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 20:42:14 -0700 Subject: [PATCH 13/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 3627e8c..e9ebdff 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -50,7 +50,7 @@ Some people recommend buying AMD instead of Intel to avoid the possibility of ha On the topic of AMT, a lot of people seem to think that vPro is all about AMT and that regular users do not need it. This is far from the truth. Intel vPro Enterprise provides other features that are absolutely relevant outside of corporate usecases: -- Total Memory Encryption - Multi Key. This is AMD SEV's Intel counterpart - it provides memory encryption to protect the host from cold boot attacks and make VM break outs harder. This is a mandatory requirement to meet HSI level 4 on Linux. +- Total Memory Encryption - Multi Key. This is AMD SEV's Intel counterpart: it provides memory encryption to protect the host from cold boot attacks and make VM break outs harder. This is a mandatory requirement to meet HSI level 4 on Linux. - Intel Key Locker - This feature makes it possible to encrypt and decrypt data with an AES key using a key handle instead of the actual encryption key. A key handle can be revoked when the system state changes, such as with a reboot. This feature is not widely used on Linux, although it is already available on Chromebooks with vPro Enterprise. - Intel Trusted Execution Technology (TXT). This feature implements Dynamic Root of Trust Measurement (DRTM) and is necessary for [System Guard](https://learn.microsoft.com/en-us/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows) on Windows. It is a pre-requisite for the Secured-core certification. On Linux, DRTM is not widely used, but Trenchboot is being developed to address that. From 44c6226a38739301ab302444e634f2f11befa10c Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 20:55:16 -0700 Subject: [PATCH 14/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index e9ebdff..f69a1ad 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -24,7 +24,7 @@ AMD PSP provides its own set of security features: By buying hardware with Intel CSME disabled, you are **increasing the attack surface** by not having Boot Guard to protect your firmware. Additionally, if you buy hardware so old that you can run `me_cleaner` to disable the ME yourself, it means that these hardware do not have Boot Guard to begin with. In both cases, you will end up with a piece of hardware with no root of trust, and any attempt to implement firmware security will be futile. -I am not aware of any way to disable AMD PSP, but even if this was possible, all that it does is to deprive you of useful security features. +I am not aware of any way to disable AMD PSP, but even if this was possible, all that it does is deprive you of useful security features. This excercise also achieves absolutely nothing to protect against a hypothetical scenario where Intel and AMD are malicious. Intel and AMD do not need the co-processor to implement a backdoor - they can simply introduce CPU vulnerabilities like Spectre and Meltdown if they want to. If you do not trust a CPU vendor, the only mitigation is to not use said vendor. From f5aaf2bab00fbec30ed343dbe75a25ee7a78b109 Mon Sep 17 00:00:00 2001 From: Tommy Date: Tue, 11 Jun 2024 20:55:31 -0700 Subject: [PATCH 15/20] Update content/posts/hardware/Misinformation on x86 Hardware/index.md Co-authored-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com> Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index f69a1ad..0253ed6 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -26,7 +26,7 @@ By buying hardware with Intel CSME disabled, you are **increasing the attack sur I am not aware of any way to disable AMD PSP, but even if this was possible, all that it does is deprive you of useful security features. -This excercise also achieves absolutely nothing to protect against a hypothetical scenario where Intel and AMD are malicious. Intel and AMD do not need the co-processor to implement a backdoor - they can simply introduce CPU vulnerabilities like Spectre and Meltdown if they want to. If you do not trust a CPU vendor, the only mitigation is to not use said vendor. +This exercise also achieves absolutely nothing to protect against a hypothetical scenario where Intel and AMD are malicious. Intel and AMD do not need the co-processor to implement a backdoor --- they can simply introduce CPU vulnerabilities like Spectre and Meltdown if they want to. If you do not trust a CPU vendor, the only mitigation is to not use said vendor. ### Intel AMT and AMD DASH From 9ffdd7425159ce173ba40cd73a8ab5453014837d Mon Sep 17 00:00:00 2001 From: Tommy Date: Thu, 13 Jun 2024 04:47:23 -0700 Subject: [PATCH 16/20] Add modern standby Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 0253ed6..e4dfe92 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -17,6 +17,7 @@ The problems with these recommendations are as follows: Intel CSME provides critical security features, including: - [Boot Guard](https://networkbuilders.intel.com/docs/networkbuilders/secure-the-network-infrastructure-secure-boot-methodologies.pdf) - The basis of Static Root of Trust Measurement. It verifies that a significant portion of your EEPROM is signed by your OEM, and provides fuses to prevent downgrade attacks to old, vulnerable versions. - [Platform Trust Technology](https://www.intel.com/content/www/us/en/support/articles/000094205/processors/intel-core-processors.html) - An firmware TPM implementation. Generally, fTPMs have better security properties when compared to dTPMs, as they stay on the same die as the CPU and are immune to bus sniffing attacks. +- [Modern Standby](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby) - This is not necessarily a security feature, but Windows does use modern standby to download critical updates even when the computer is in sleep mode. AMD PSP provides its own set of security features: - Firmware TPM - serving the same role as Intel's Platform Trust Technology. From 12ddd5e97b50ac9bdc1153777fd51f32dd2300f3 Mon Sep 17 00:00:00 2001 From: Tommy Date: Thu, 13 Jun 2024 05:24:21 -0700 Subject: [PATCH 17/20] Blah Signed-off-by: Tommy --- .../Misinformation on x86 Hardware/index.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index e4dfe92..6be1422 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -14,9 +14,9 @@ A very common piece of misinformation among privacy communities is that the Inte The problems with these recommendations are as follows: -Intel CSME provides critical security features, including: -- [Boot Guard](https://networkbuilders.intel.com/docs/networkbuilders/secure-the-network-infrastructure-secure-boot-methodologies.pdf) - The basis of Static Root of Trust Measurement. It verifies that a significant portion of your EEPROM is signed by your OEM, and provides fuses to prevent downgrade attacks to old, vulnerable versions. -- [Platform Trust Technology](https://www.intel.com/content/www/us/en/support/articles/000094205/processors/intel-core-processors.html) - An firmware TPM implementation. Generally, fTPMs have better security properties when compared to dTPMs, as they stay on the same die as the CPU and are immune to bus sniffing attacks. +Intel CSME provides security features, including: +- [Boot Guard](https://networkbuilders.intel.com/docs/networkbuilders/secure-the-network-infrastructure-secure-boot-methodologies.pdf) - The basis of Static Root of Trust Measurement (SRTM). It verifies that a significant portion of your EEPROM is signed by your OEM, and provides fuses to prevent downgrade attacks to old, vulnerable versions. +- [Platform Trust Technology](https://www.intel.com/content/www/us/en/support/articles/000094205/processors/intel-core-processors.html) - A firmware TPM implementation. Generally, fTPMs have better security properties when compared to dTPMs, as they stay on the same die as the CPU and are immune to bus sniffing attacks. - [Modern Standby](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby) - This is not necessarily a security feature, but Windows does use modern standby to download critical updates even when the computer is in sleep mode. AMD PSP provides its own set of security features: @@ -65,4 +65,12 @@ In reality, most if not all laptops with UEFI Secure Boot allows you to disable Microsoft even went further to make Secure Boot better for end users. Computers with their Secured-core certification provides users with the **Freedom** to disable the Microsoft Secure Boot Third Party Certificate Authority and still have the computers function normally. They **protect** the users from having to sign and trust random **proprietary Option ROMS**. It is great for both users who want to use Windows as their primary system and users who plan to set up a proper Secure Boot system with Linux. -UEFI Secure Boot is not Restricted Boot. It is a building block of Static Root of Trust Measurement and a step towards building a secure boot environment. \ No newline at end of file +UEFI Secure Boot is not Restricted Boot. It is a building block of Static Root of Trust Measurement and a step towards building a secure boot environment. + +### Trusted Platform Module + +The Trusted Platform Module (TPM) is very often misunderstood, and there have been plenty of inaccurate claims regarding its capabilities. The reality is this: + +- It is a passive chip. It does not have the capability to measure what is going on on a system - it only receive measurements given to it by the firmware, Trusted Execution Technology, bootloader, and so on. It cannot serve as a root of trust, and it cannot verify the integrity of the firmware, firmware settings, operating system status, etc on its own. + +- It does not weaken disk encryption when used properly. The TPM provides 2 important properties: it enforces rate limiting, and it pinning a secret against certain PCRs. Rate limiting is useful if the user does not have a sufficiently strong encryption password, however it is not strictly necessary when a diceware encryption passphrase is used. Pinning secrets against PCRs on the other hand are critical, as SRTM and DRTM technologies rely on it to be useful. The general idea is that \ No newline at end of file From 47678a8672d57b0ee6513c46aabedf12beaccd3e Mon Sep 17 00:00:00 2001 From: Tommy Date: Thu, 13 Jun 2024 05:27:10 -0700 Subject: [PATCH 18/20] Clean up bit Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 6be1422..6ea8d97 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -73,4 +73,4 @@ The Trusted Platform Module (TPM) is very often misunderstood, and there have be - It is a passive chip. It does not have the capability to measure what is going on on a system - it only receive measurements given to it by the firmware, Trusted Execution Technology, bootloader, and so on. It cannot serve as a root of trust, and it cannot verify the integrity of the firmware, firmware settings, operating system status, etc on its own. -- It does not weaken disk encryption when used properly. The TPM provides 2 important properties: it enforces rate limiting, and it pinning a secret against certain PCRs. Rate limiting is useful if the user does not have a sufficiently strong encryption password, however it is not strictly necessary when a diceware encryption passphrase is used. Pinning secrets against PCRs on the other hand are critical, as SRTM and DRTM technologies rely on it to be useful. The general idea is that \ No newline at end of file +- It does not weaken disk encryption when used properly. The TPM provides 2 important properties: it enforces rate limiting, and it pinning a secret against certain PCRs. Rate limiting is useful if the user does not have a strong encryption password, but is not strictly necessary when a diceware encryption passphrase is used. Pinning secrets against PCRs on the other hand are critical, as SRTM and DRTM technologies rely on it to be useful. The general idea is that \ No newline at end of file From 114bcf2ca7d77777bb09d6cade4ba37a2424fe38 Mon Sep 17 00:00:00 2001 From: Tommy Date: Thu, 13 Jun 2024 05:27:32 -0700 Subject: [PATCH 19/20] Grammar fix Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index 6ea8d97..dce9c59 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -73,4 +73,4 @@ The Trusted Platform Module (TPM) is very often misunderstood, and there have be - It is a passive chip. It does not have the capability to measure what is going on on a system - it only receive measurements given to it by the firmware, Trusted Execution Technology, bootloader, and so on. It cannot serve as a root of trust, and it cannot verify the integrity of the firmware, firmware settings, operating system status, etc on its own. -- It does not weaken disk encryption when used properly. The TPM provides 2 important properties: it enforces rate limiting, and it pinning a secret against certain PCRs. Rate limiting is useful if the user does not have a strong encryption password, but is not strictly necessary when a diceware encryption passphrase is used. Pinning secrets against PCRs on the other hand are critical, as SRTM and DRTM technologies rely on it to be useful. The general idea is that \ No newline at end of file +- It does not weaken disk encryption when used properly. The TPM provides 2 important properties: it enforces rate limiting, and it pins secrets against certain PCRs. Rate limiting is useful if the user does not have a strong encryption password, but is not strictly necessary when a diceware encryption passphrase is used. Pinning secrets against PCRs on the other hand are critical, as SRTM and DRTM technologies rely on it to be useful. The general idea is that \ No newline at end of file From 9a039ef94935098a29dcd8a5d3380852009ecec2 Mon Sep 17 00:00:00 2001 From: Tommy Date: Thu, 13 Jun 2024 05:27:54 -0700 Subject: [PATCH 20/20] Blah Signed-off-by: Tommy --- content/posts/hardware/Misinformation on x86 Hardware/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/hardware/Misinformation on x86 Hardware/index.md b/content/posts/hardware/Misinformation on x86 Hardware/index.md index dce9c59..cce0290 100644 --- a/content/posts/hardware/Misinformation on x86 Hardware/index.md +++ b/content/posts/hardware/Misinformation on x86 Hardware/index.md @@ -73,4 +73,4 @@ The Trusted Platform Module (TPM) is very often misunderstood, and there have be - It is a passive chip. It does not have the capability to measure what is going on on a system - it only receive measurements given to it by the firmware, Trusted Execution Technology, bootloader, and so on. It cannot serve as a root of trust, and it cannot verify the integrity of the firmware, firmware settings, operating system status, etc on its own. -- It does not weaken disk encryption when used properly. The TPM provides 2 important properties: it enforces rate limiting, and it pins secrets against certain PCRs. Rate limiting is useful if the user does not have a strong encryption password, but is not strictly necessary when a diceware encryption passphrase is used. Pinning secrets against PCRs on the other hand are critical, as SRTM and DRTM technologies rely on it to be useful. The general idea is that \ No newline at end of file +- It does not weaken disk encryption when used properly. The TPM provides 2 important properties: it enforces rate limiting, and it pins secrets against certain PCRs. Rate limiting is useful if the user does not have a strong encryption password, but is not strictly necessary when a diceware passphrase is used. Pinning secrets against PCRs on the other hand are critical, as SRTM and DRTM technologies rely on it to be useful. The general idea is that \ No newline at end of file