Intel x86 Root of Trust: loss of trust
The scenario that Intel system architects, engineers, and security specialists perhaps feared most is now a reality. A vulnerability has been found in the ROM of the Intel Converged Security and Management Engine (CSME). This vulnerability jeopardizes everything Intel has done to build the root of trust and lay a solid security foundation on the company's platforms. The problem is not only that it is impossible to fix firmware errors that are hard-coded in the Mask ROM of microprocessors and chipsets. The larger worry is that, because this vulnerability allows a compromise at the hardware level, it destroys the chain of trust for the platform as a whole.
[...] Intel CSME is the cryptographic basis for hardware security technologies developed by Intel and used everywhere, such as DRM, fTPM, and Intel Identity Protection. In its firmware, Intel CSME implements EPID (Enhanced Privacy ID). EPID is a procedure for remote attestation of trusted systems that allows identifying individual computers unambiguously and anonymously, which has a number of uses: these include protecting digital content, securing financial transactions, and performing IoT attestation. Intel CSME firmware also implements the TPM software module, which allows storing encryption keys without needing an additional TPM chip—and many computers do not have such chips.
Intel tried to make this root of trust as secure as possible. Intel's security is designed so that even arbitrary code execution in any Intel CSME firmware module would not jeopardize the root cryptographic key (Chipset Key), but only the specific functions of that particular module. Plus, as the thinking went, any risks could be easily mitigated by changing encryption keys via the security version number (SVN) mechanism.
[...] Unfortunately, no security system is perfect. Like all security architectures, Intel's had a weakness: the boot ROM, in this case. An early-stage vulnerability in ROM enables control over reading of the Chipset Key and generation of all other encryption keys. One of these keys is for the Integrity Control Value Blob (ICVB). With this key, attackers can forge the code of any Intel CSME firmware module in a way that authenticity checks cannot detect. This is functionally equivalent to a breach of the private key for the Intel CSME firmware digital signature, but limited to a specific platform.
[...] A single key is used for an entire generation of Intel chipsets. And since the ROM vulnerability allows seizing control of code execution before the hardware key generation mechanism in the SKS is locked, and the ROM vulnerability cannot be fixed, we believe that extracting this key is only a matter of time. When this happens, utter chaos will reign. Hardware IDs will be forged, digital content will be extracted, and data from encrypted hard disks will be decrypted.
[...] We will provide more technical details in a full-length white paper to be published soon. We should point out that when our specialists contacted Intel PSIRT to report the vulnerability, Intel said the company was already aware of it (CVE-2019-0090). Intel understands they cannot fix the vulnerability in the ROM of existing hardware. So they are trying to block all possible exploitation vectors.
[...] any platform device capable of performing DMA to Intel CSME static memory and resetting Intel CSME (or simply waiting for Intel CSME to come out of sleep mode) can modify system tables for Intel CSME pages, thereby seizing execution flow.
Also covered at The Verge and The Register.
For an historical perspective, think back to the Intel Pentium FDIV bug and what it cost Intel to deal with it.
At least take comfort in the fact that most governments have No Such Agency that would be interested in something like this.
(Score: -1, Troll) by Anonymous Coward on Saturday March 07 2020, @04:43AM (9 children)
n/t
(Score: 3, Insightful) by takyon on Saturday March 07 2020, @05:19AM (8 children)
From zero to zero?
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 0) by Anonymous Coward on Saturday March 07 2020, @05:42AM (6 children)
If you go from 0 to 0 in 0 time then your velocity is 0/0. That's not possible - therefore nothing is stationary.
(Score: 1, Funny) by Anonymous Coward on Saturday March 07 2020, @07:54AM (4 children)
0/0 is not undefined, it's zero. Zero multiplied by anything is zero (0 * 1/0, in this case)
(Score: 1, Funny) by Anonymous Coward on Saturday March 07 2020, @08:24AM
Cool, so 0/0 = 0 now we know!
(Score: 3, Funny) by maxwell demon on Saturday March 07 2020, @02:22PM (1 child)
Yeah, and 1/0=0, too.
Proof:
0 = 1/0 - 1/0 = 1/0 + 1/(-0) = 1/0 + 1/0 = 2/0 = (2*1)/(2*0) = 1/0
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by shrewdsheep on Saturday March 07 2020, @06:22PM
Bah, ... that's trivial stuff. Here, I show (for the first time) that 1/0 is also 1. 1/0 = 0 ⇒ 1 = 0² ⇒ 1 = 0 = 1/0 q.e.d.
(Score: 2) by DannyB on Monday March 09 2020, @04:17PM
Infinite?
Draw a graph with multiple lines. X axis is from 1 to 10. Y axis is logarithmic to some large value.
Graph: 10/x, 9/x, 8/x, etc.
In all cases, as x approaches zero, y approaches insanity.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 3, Insightful) by aristarchus on Saturday March 07 2020, @12:03PM
https://soylentnews.org/article.pl?sid=20/02/22/1033250 [soylentnews.org]
Told ya!
(Score: 3, Insightful) by driverless on Sunday March 08 2020, @05:58AM
For those who only heard a whooshing sound, what that comment is saying is that you had zero "trust" beforehand and now you've still got zero "trust". With gaping-open barn doors like IPMI present, there's no trust to start with.