Slashdot Mirror
DUHK Crypto Attack Recovers Encryption Keys, Exposes VPN Connections (bleepingcomputer.com)
An anonymous reader writes from a report via Bleeping Computer: After last week we had the KRACK and ROCA cryptographic attacks, this week has gotten off to a similarly "great" start with the publication of a new crypto attack known as DUHK (Don't Use Hard-coded Keys). The issue at the heart of the DUHK attack is a combination of two main factors. The first is the usage of the ANSI X9.31 Random Number Generator (RNG). This is an algorithm that takes random data and generates encryption keys used to secure VPN connections, browsing sessions, and other encrypted traffic/data. The second factor needed for a DUHK attack is when hardware vendors use a hardcoded "seed key" for the ANSI X9.31 RNG algorithm. When these two conditions take place, an attacker can brute-force encrypted data to discover the rest of the encryption parameters and deduce the master encryption key used to encrypt web sessions or VPN connections. In a research paper published today, researchers said they found 12 vendors that sold hardware/software products with hardcoded X9.31 seed keys. This issue is widespread because ANSI X9.31 is very widespread. Up until January 2016, the algorithm was on the list of U.S. government (FIPS) approved RNG algorithms. ANSI X9.31 remained on the list until 2016, even if US NIST deprecated the algorithm in 2011, and scientists warned that the algorithm could be broken if the seed key ever leaked way back in 1998.
"Do not attribute to malice that which is adequately explained by incompetence."
"We need crypto in this thing"
"Ok, there is a library for that"
"Done"
"Ship it"
Sure, they had to init the RNG with something, so they initialized it with "something" - a random number choosen by fair die roll or some such. Of course, it will be the same on every power-up.
Your average 80's-90's programmer didn't know why that was stupid. And if it was hard for them to write, it is impossible for mere users to hack anyway.
Management didn't bother hiring a crypto expert, not even for a few days of consulting. You find this kind of flaws everywhere.
Duh! Duh! Duh! =)
Why did the chicken cross the road? Because Elon Musk put an AI chip in its head.
This is what you're doing if you hardcode PRNG seeds:
int getRandomNumber() // chosen by fair dice roll, guaranteed to be random
{
return 4;
}
221
A vulnerability like this was speculated to be the mysterious method the NSA used to supposedly be able to break SSL connections, as revealed in the Snowden documents. It's probably not this exact vuln, though, as this seems to mostly be a problem in hardware used to route to VPNs.
Corruption is convincing someone that the selfless ideal is the same as their selfish ideal.
Yet we will have "AI" becoming sentient and taking over the world real soon now, right? Meanwhile we can't even get normal software to work properly. The tech industry is so full of hype.
I learned very early on to use a random number to initialize the RNG.
The AI's are getting so advanced that they're uncovering multiple cryptographic weaknesses in human code per week! Who do you think came up with KRACK, ROCA, and DUHK? A mere human?
Am I the only one, who nowadays feels like FIPS is more a sign of insecurity than of security?
I’ve read about so many insecurities that only affect FIPS-“certified” software
I don’t even care if it is deliberate. I actually have all things FIPS patched out of my OS.
(Guys! We found that one feature that compiling all your packages yourself is good for! Call somebody! ;)
@Anonymous Coward: "Who thinks this is an accident, show of hands?"
..
Going on the down vote, there's at least one
I also think a similar thing is possible for known S-Boxes in AES. I'd prefer they be generated rather than hardcoded myself. Waiting for that article.....
If you compromise PRNG seed, you can predict its output. This is why seeding with full entropy for crypto applications is so important. This is why if you are running headless Linux box, you should consider XORing CPU entropy with /dev/[u]random.
Fixed entropy [passwd] is clearly an oxymoron -- it is at most an obscurant. At the very least other sources of pseudo-entropy should be sought and mixed in. Something like low-order time bits or low order MAC bits from the network.
I think it is an accident to call it "Don't Use Hard-coded Keys".
How about using Seeds instead of Keys. Since the actual problem is using a hard coded random number generator seed. Not a hard coded crypto key. Although I suppose a hardcoded PRNG seed results in effectively a hard coded key as well.
While the mis-naming may be an accident, the actual problem may not be an accident. TLAs are always looking for ways to compromise systems while leaving us with a false sense of security.
I'll see your senator, and I'll raise you two judges.
Yeah, the first thing I always do is "srandom(random())".
If you can't do any better, such as collect entropy from something, then at least use the least significant bits of the date / time stamp. Most systems have a clock with milliseconds resolution. Even if you only have a clock with seconds resolution, that is better than a hard coded number. Even if the clock hasn't been set by the user. It accumulates time from that blinking 12:00:00 AM that it initially started at.
But there are plenty of things you could use. Timestamps of all incoming events, such as keystrokes, moose movements, memory usage, cpu usage and / or temp, etc that have a few bits you could mix into your PRNG seed. And even one bit matters.
I'll see your senator, and I'll raise you two judges.
But then what seeds the seeder?
moose movements
Moose are a pretty slow source of entropy. Better to use a cat chasing its tail.
I was just thinking that yesterday & yes, I am inclined to agree with you on those very grounds. What you said isn't 'funny': It's fact that is NOT funny @ all...
* Wait till the shift is to "quantum computing" & see all the bugs (OR WORSE in horrible decision making AI might end up making since we can't create anything 100% perfect apparently) that'll pop up then to compound it even moreso, let alone AI alone on Von Neumann based (iirc, feel free to correct me here if needed) architectures we use now.
See subject: It was due to all the "media hype" on AI - which is MOSTLY just mgt. wanting to say "I headed this 'AI' project" (but did no real production work myself on it) on their 'leadership based' resumes (short-sighted fools with no REAL skills in the work they lead (not as true today but it definitely was in my day)).
APK
P.S.=> Good point (but I don't think it's too funny personally, you probably don't either on a guess) & again - "great minds think alike"... apk
Wooosh...
moose movements
Moose are a pretty slow source of entropy. Better to use a cat chasing its tail.
He said moose, he meant squirrel.
It's mostly because a moose once bit his sister.
Am I the only one who read that as "Duh-uck"?
It it looks like a Duck, and it quacks like a DUHK, does anyone hear the tree fall in the forest?
Your average 80's-90's programmer didn't know why that was stupid. And if it was hard for them to write, it is impossible for mere users to hack anyway.
I simply don't believe this as a valid excuse, though.
Programmers of that era were generally less retarded than programmers of today.
I was TEN when I understood that seeding from fixed data would be insecure. Admittedly the hardware I was writing on was very limited and ran BASIC, but I still made an encryptable, printable database. It just required you to enter an initial seed by bashing the keyboard. :)
This coming from a person that can barely manage the multiplication tables in-head and generally has problems with mental calculation. (still passed the FUCK out of Math class though, thank you Calculator-Jesus)
I can understand that there were limited sources of entropy in hardware during those days. Computers were vastly simpler and more predictable.
These days the entire CPUs state from one cycle to the next is more random than probably every single computer that existed in the entire decade of the 80s.