On an x86 system the BIOS is the first part of the system to become active along with the basic CPU core(s) functionality, or so things used to be until Intel introduced its Management Engine (IME) and AMD its AMD Secure Processor (AMD-SP). These are low-level, trusted execution environments, which in the case of AMD-SP involves a Cortex-A5 ARM processor that together with the Cryptographic Co-Processor (CCP) block in the CPU perform basic initialization functions that would previously have been associated with the (UEFI) BIOS like DRAM initialization, but also loading of encrypted (AGESA) firmware from external SPI Flash ROM. Only once the AMD-SP environment has run through all the initialization steps will the x86 cores be allowed to start up.
In a detailed teardown by [Specter] over at the Dayzerosec blog the AMD-SP’s elements, the used memory map and integration into the rest of the CPU die are detailed, with a follow-up article covering the workings of the CCP. The latter is used both by the AMD-SP as well as being part of the cryptography hardware acceleration ISA offered to the OS. Where security researchers are interested in the AMD-SP (and IME) is due to the fascinating attack vectors, with the IME having been the most targeted, but AMD-SP having its own vulnerabilities, including in related modules, such as an injection attack against AMD’s Secure Encrypted Virtualization (SEV).
Although both AMD and Intel are rather proud of how these bootstrapping systems enable TPM, secure virtualization and so on, their added complexity and presence invisible to the operating system clearly come with some serious trade-offs. With neither company willing to allow a security audit, it seems it’s up to security researchers to do so forcefully.
“the workings of the CCP” ……. how apt , is IP theft in that bundle ?
How many IP companies do you have, being you more concerned about poor little corporations than about victims of WASP Big Brother?
In Soviet Russia, the Central Crytopgrahic Co-Processor (CCCP) decrypts YOU!
The european CRA legislation will require exactly that third party audit that amd/intel are now unwilling to do.
I find this kind of stuff really interesting, although it gets over my head pretty quickly. Things I wonder:
(1) if the implementation was bug-free, could they publish complete specs and have it be secure? I hope so.
(2) If so, does that mean there is a handful of people at AMD (or Intel) with access to some private keys that could effectively neuter security on vast swaths of the Internet? How valuable are those keys?
Read the book on the TPM. Security is a hard problem.
“Every software has bugs.”
– The Tao of Programming
If you find a bug in your program, then the probability of finding more bugs has become even greater. :)
…and if you don’t find a bug in your program then you’ve not looked hard enough yet ;)
I could be wrong but I recall from discussions on previous articles about this here and elsewhere, that people were saying AMD and Intel’s hands are tied where they can’t just document their secure coprocessors because of agreements with the 3rd party (ARM?) silicon IP being used… not sure how valid that excuse is though