NSA Starts Contributing Low-Level Code to UEFI BIOS Alternative
The NSA has started assigning developers to the Coreboot project, which is an open source alternative to Windows BIOS/UEFI firmware. The NSA's Eugene Myers has begun contributing SMI Transfer Monitor (STM) implementation code for the x86 processor. Myers works for NSA’s Trusted Systems Research Group, which according to the agency’s website, is meant to “conduct and sponsor research in the technologies and techniques which will secure America's information systems of tomorrow.”
Can The NSA Be Trusted With Such Low-Level Code?
NSA has worked on security projects embraced by the public before, including Security-Enhanced Linux, a security module for Linux. More recently, the NSA released the Ghidra reverse engineering tool as open source, which has also been adopted by Coreboot developers so that they can more easily reverse-engineer hardware firmware.
Myers published a paper about STM last year on how NSA’s STM implementation could work. All Coreboot code, including all the STM contributions from the NSA, are open source, so anyone could verify that there is no backdoor in there -- in theory.
In practice, the NSA could have also written the code in a less-than-secure way with vulnerabilities that are hard to detect without more experienced security researchers. Alternatively, the NSA could also update this implementation years later, when there are less eyes on the STM implementation and the update would no longer make headlines.
This wouldn’t be completely out of the question for an agency like the NSA. After all, the NSA succeeded in pushing a backdoor through the NIST standardization process years ago. The agency was also accused by EFF co-founder John Gilmore of sabotaging the IPsec protocol by making it too complex to ever be secure (something that would benefit an espionage agency).
More recently, it also tried to push two encryption algorithms through the ISO standardization process, but the reviewers overwhelmingly rejected the algorithms based on trust concerns and NSA’s failure to answer some technical questions.
NSA Low-Level Code In Coreboot
Intel released the STM specification and documentation of the SMT firmware security feature in 2015, six years after the discovery of bypasses against the company’s Trusted Execution Technology, which can be used to ensure that an operating system starts in a trusted environment.
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
The STM is a hypervisor that launches inside the System Management Mode, which is a “ring -2” isolated environment that offers protected execution against tampering of low-level services, such as power management, security functions, calls to the Trusted Platform Module and so on. STM was initially supposed to work with an Intel TXT launch, but the latest specification allows the STM to work with Intel Virtualization Technology (VT) only. The TXT was not enough to protect these services against attacks, and STM is meant to do that.
USB-C cable CT scan reveals sinister active electronics — O.MG pen testing cable contains a hidden antenna and another die embedded in the microcontroller
Hackers breach Wi-Fi network of U.S. firm from Russia — daisy chain attack jumps from network to network to gain access from thousands of miles away
-
daglesj I guess to some this will perfectly okay "cos it's our guys doin' it!"Reply
Then it all goes to China to be made and they add their special sauce too maybe...
What a mess those that tried to save a buck all those years ago have made. -
traxxmy
Blame your own governmet for thatdaglesj said:I guess to some this will perfectly okay "cos it's our guys doin' it!"
Then it all goes to China to be made and they add their special sauce too maybe...
What a mess those that tried to save a buck all those years ago have made. -
bit_user
Part of the NSA's mission is to protect government systems from cyber-terrorism. So, they have a legitimate reason for wanting to improve security - not just break it.daglesj said:I guess to some this will perfectly okay "cos it's our guys doin' it!"
Second, the problem with back doors is that other people inevitably find & use them - both other governments and cyber criminals. This is the strongest argument against backdoors, really. So, they're bad no matter matter who is adding them. And it would be especially dumb to try and add them in an open source codebase that everyone (security researchers and hackers, alike) can analyze.
I'm somewhat disappointed in Lucian. His articles are usually better than this.