SoylentNews is people
SoylentNews
from the deep-seated-insecurities-and-paranoia dept.
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.”
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.
Better to avoid coreboot and feel secure that the hardware could never subvert my expectations of security and privacy. /s
(Score: 2) by pipedwho on Tuesday June 25 2019, @12:27AM (6 children)
This is true.
And on top of that, the NSA, like any paranoid agency is extremely unlikely to intentionally introduce a flaw that can be discovered by a third party outside their control. It is of no benefit to the NSA, either due to bad publicity on how they botched a supposedly secure implementation, or because then they won't be the only ones that can use their back door.
The sort of backdoor that I'd expect from the NSA would include some sort of magic number with a trap door that can't be 'discovered' with anything less than a brute force approach measured to take a time frame with a resolution of 'ages of the universe'. And after the Dual Curve EC PRNG debacle, I doubt they'd be able to pull off a stunt like that again.
(Score: 2, Interesting) by fustakrakich on Tuesday June 25 2019, @12:38AM (1 child)
some sort of magic number:
20380119031408
La politica e i criminali sono la stessa cosa..
(Score: 2) by pipedwho on Tuesday June 25 2019, @12:55AM
It's fitting the 2038 unix signed 32 bit overflow just after "pi o'clock AM".
But, I'm thinking of a number that has been constructed and included as part of the design, not so much a time bomb.
(Score: 2) by JoeMerchant on Tuesday June 25 2019, @03:24AM (3 children)
Mostly this, I think:
would be some sort of cryptography that only they can break with the massive quantum computer they have implemented under Cheyenne Mountain (wonder why NORAD moved out? Hmmm.....)
They might be ordered to try, and as an agency they might want to look dumber than they are. But, there's also value for them in helping to build truly secured systems for the private sector. Having a rogue state take down the banking system for a week isn't much of a "best case scenario" for any security agency.
🌻🌻 [google.com]
(Score: 4, Interesting) by pipedwho on Tuesday June 25 2019, @04:14AM (2 children)
I doubt that. Anything the NSA can build in their secret dungeon is potentially on a few years away being built by someone else. If the NSA is aware of a cryptoanalytic technique that allows something to be broken easily by their own systems, they'll most likely be looking to secure it in a way where someone else with a similar system at some point in the future can't break it.
The best way for that is to make sure the 'trapdoor' technique in place is not breakable by themselves or anyone else that doesn't possess a secret key. If they design it correctly, that generator coefficient can be made so not even the NSA itself could 'crack' it without prior knowledge of the key value.
However, that approach becomes obvious when 'magic numbers' are included in a design that may not have the security properties they purport to have, but are instead chosen to include mathematically derivable 'trap doors' that weaken the algorithm to something crackable to anyone possessing this secret 'trap door' key.
(Score: 2) by JoeMerchant on Tuesday June 25 2019, @12:51PM (1 child)
All of cryptography is about the secret's lifetime as a secret. There's a vague function of 1 / ( exposure x effort ) -> time to break, and with globally deployed systems like UEFI that exposure x effort quantity approaches infinity. No matter what the protocols are protecting the deployed key, unless they've also built in a key rotation mechanism to keep the active key fresh (and such a thing would be too obvious in open source, and difficult in a system like BIOS), that key is going to be required for a large number of operations, raising its exposure level to a point where it is virtually certain to be leaked eventually - particularly with the effort that will be being expended to obtain it.
🌻🌻 [google.com]
(Score: 2) by pipedwho on Wednesday June 26 2019, @01:07AM
True. The way 'magic number' trap doors happen is to choose a 'random' number, but select (or generate) it to have a property that makes it either easier to brute force knowing the generation partials. When the number is supposed to be 'random', it should be taken from a public authenticated source or other standardised deterministic method.
For example, let's say an algorithm requires a large 4096 bit prime modulus. The defined standard modulus could be a huge randomly generated base with prime properties appropriate to the security of the algorithm. However, if the NSA generates that 'prime' where it is actually a composite made up of two 2048 bit primes, it could choose one of primes to be 'weakened' by having properties that significantly improve the ability to brute force a message/key exchange encrypted with said algorithm. A non-NSA attacker would have to first factor the 4096 'prime', which requires substantial effort and is not currently possible with today's technological state. And the NSA never needs to expose these keys outside their own systems.
This is why 'magic numbers' are frowned upon in the crypto world. The NIST standardised prime curves for ECDSA/ECDH are examples of this contention. The curves are 'random' prime curves that are used in all standard implementations. These curves are 'believed' to be secure, but there is no way to guarantee that the NSA hasn't carefully chosen them to allow them to be more easily brute force attack an encrypted message or key exchange. The numbers are huge (eg. 256bit, 512bit) making them very difficult to dissect in anything less than polynomial time (unless you already know the roots/weaknesses).