NSA Starts Contributing Low-Level Code to UEFI BIOS Alternative

(Image credit: Intel)

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.

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.

(Image credit: Intel)
Lucian Armasu
Lucian Armasu is a Contributing Writer for Tom's Hardware US. He covers software news and the issues surrounding privacy and security.
  • daglesj
    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.
    Reply
  • traxxmy
    daglesj 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.
    Blame your own governmet for that
    Reply
  • bit_user
    daglesj said:
    I guess to some this will perfectly okay "cos it's our guys doin' it!"
    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.

    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.
    Reply