Originally published at: https://boingboing.net/2019/06/14/u-s-government-security-keys.html
…
Lowest bidder?
1 Like
It’s just a default value, until we have quantum computers in our pockets there will always be default values. The keys are recomputed on a regular cycle, so if the startup code has a bug and doesn’t generate a new seed correctly before the first key value is computed then the default value would remain and the first key would be weak.
Should it have passed QC? No
Is it surprising? No
Is it news? Only because of the number of people affected.
YMMV, IANAP, just an educated guess. 
8 Likes
https://makezine.com/projects/really-really-random-number-generator/
You can make a random number generator that is actually random easily with '70s technology.
If you prefer a more modern approach: http://moonbaseotago.com/onerng/
It will cost a bit more than the fixed seed, but yiu have something truly random to use…
4 Likes
According to Yubico, a bug keeps “some predictable content” inside the device’s data buffer…
If someone reading this can school me on why anyone working at Yubico would think that keeping ‘predictable content’ on a device meant to secure highly-sensitive governmental systems and information, I’d appreciate it.
I don’t understand why you seem to think this was intentional. It was a bug. They identified it, created a fix, are recalling all the affected devices to make it good (because the nature of the device doesn’t permit firmware updates). Should it have been caught in FIPS testing? Probably. Lesson learned.
What’s the problem?
12 Likes
I agree, it was not intentional. It’s an unfortunate bug that slipped through. No software is 100% bug free.
Specifics on the impact of bug:
For RSA key generation on the YubiKey FIPS Series, the RSA key may be impacted by up to 80 predictable bits out of a minimum of 2048 bits (length will depend on user configuration). We believe 80 predictable bits does not make it imminently possible for an attacker to obtain the private key material or decrypt data that has been encrypted to a key created in this way. During RSA key generation only a portion of these bits may be used, which could further reduce the impact on the algorithm’s output.
For ECDSA signatures, the nonce K becomes significantly biased with up to 80 of the 256 bits being static, resulting in weakened signatures. This could allow an attacker who gains access to several signatures to reconstruct the private key.
For ECC key generation on the YubiKey FIPS Series, the key may be impacted by up to 80 predictable bits out of the minimum 256 bit key length.
For ECC encryption,16 bits of the private key becomes known. For secp256r1 private keys, the key may be impacted by 16 predictable bits, reducing the number of unknown bits in the key from 256 to 240 bits. Similarly, for impacted secp384r1 private keys, the number of unknown bits in the key is reduced from 384 to 368 bits. 240 bit keys are not known to be defeated at the time of this advisory.
2 Likes
When you said “the stupidest reason imaginable,” I was expecting something a whole lot stupider than that. That kind of bug is really easy to make, and might not even be trivially obvious to QA.
I can imagine much stupider reasons that this could happen.
11 Likes
…or you can use open source schematics and source to make your own keys: https://solokeys.com/
1 Like
Preposterous. Something like that never happened before, especially not with free software.
1 Like
Spook vs Spook.
Sounds like a case of the cannibalistic NSA eating itself with a backdoor so they can engage in “legitimate data collection”?
2 Likes
This topic was automatically closed after 5 days. New replies are no longer allowed.
