DUHK Crypto Attack Recovers Encryption Keys, Exposes VPN Connections (bleepingcomputer.com) 59
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.
Re: (Score:3, Insightful)
"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.
Managemen
Re: (Score:1)
Re: (Score:1)
Yeah, the first thing I always do is "srandom(random())".
Re: (Score:2)
Re: (Score:3)
But there are plenty of things you could use. Timestamps of all incoming events, such a
Re:I love it. (Score:5, Funny)
moose movements
Moose are a pretty slow source of entropy. Better to use a cat chasing its tail.
Re: (Score:2)
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.
Re: (Score:1)
Going on the down vote, there's at least one
Re: (Score:3)
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.
Duh! Of Course A DUH Attack Recovers Duh Keys (Score:2)
Re: (Score:1)
Duh! Duh! Duh! =)
NSA wants into our shit
Do-DUH Do-DUH
Now it's leaked and hackers pwn it
All the do-DUH day!
Gonna leak all night
Gonna leak all day
NSA leaks and breaks our shit
All the do-DUH day!
Strat
RNG (Score:5, Funny)
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 [xkcd.com]
Re:RNG (Score:4, Funny)
AAAAnnnnddddd.... Three code monkeys just cut and pasted that function. Thanks.
capcha: exorcism
To be fair, the AC found the code on Stack Overflow.
Re: (Score:2)
xkcd mod informative? Not funny? Seriously?
Without going into the impossibility of generating a "random" (as opposed to unpredictable and/or uncorrelated) number, the sad thing is that it is so easy to generate "good" seeds, as all of the primary operating systems have entropy gathering systems that are easy to call. The one in Windows is (sadly) closed source, but it is there, and M$ programmers are rarely overtly incompetent given a specific task. And for mission critical super-duper applications, the
Re: (Score:2)
Sounds Familiar (Score:5, Interesting)
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.
Re: (Score:1)
All hardware with EEPROMS or re writable firmware is a good bet. Special flags upped by say row hammering is another,
What IS interesting is that pace of vuln discovery is picking up - maybe the millions splashed on rewards is training competent goldhats to uncover single basics -combination backdoors are somewhat harder to discover, As baked in management hardware is real, all one can do is insert BSD like handcrafted routers to drop unexpected traffic - now that whole computer usb dongles are cheap cheap.
T
Re: (Score:1)
I see security getting worse. Mainly because there is zero reason to put out a secure product, and a ton of reasons not to. If I made a secure IoT lightbulb, I'd be put ot of business by competitors who have the exact same thing, but 1/10 the price, because they didn't bother with security, since security brings zero returns on investment.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Collect it all gets that Encapsulating Security Payload
AI (Score:3, Funny)
Re: (Score:2)
Re: (Score:1)
The tech industry's greatest trick is moving to new things so quickly that few people can ever really get their head around a given tech before it falls by the wayside. So we all end up building things, from the trivial to the critical, on technologies that we delude ourselves into thinking we understand. Because the advantages of computing and software are so massive that no one wants to wait until the day when we understand software the way we understand, say, building and bridge construction.
Re: (Score:1)
That may sound like a joke, but imagine the DoD training Alpha Go Zero up on recognising vulnerabilities in code then setting it loose on other nation states. Then imagine other nations with similar projects. Welcome to the future.
Re: (Score:1)
Well, the point of actual AI is, that you don’t have to get shit right, because you can just use a very simple algorithm, use a _lot_ of it, and get the thing to solve the problems by itself. Which, surprisingly, actually works.
Of course none of that shit we see being called AI, is actually AI.
Damn! Now I wonder if there is a way to use this to get large masses of dumb humans to perform something smart! Imagine actually getting something good out of a billion Trumps*!
(* Or insert whatever meme you cur
Re: (Score:2)
Re: (Score:3)
"Great minds think alike"... apk (Score:1)
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 no
Re: (Score:2)
How do you test on your RNG to make sure it is random without FIPS?
Re: (Score:2)
Initially seed it by asking the user to wiggle the mouse or bang on the keyboard at random (similar to how TrueCrypt gets random values), then using a high speed timer (python timeit, etc.) to grab microsecond or higher timestamps, SHA-512 the timestamps (SHA is mainly used as a bit blender), and toss those in the pool. It isn't perfect, but combined with a hardware RNG, it should be good enough for most things.
Re: (Score:2)
That gives you personally confidence that your data is random... but can you prove it? Not just for "compliance" purposes, but to know that you have the best possible starting point.
While far from my area of expertise, you always risk that the process you do actually reduces randomness-- using your example, maybe the collection of information will not yield random distribution of the SHA512 hashes.
Re: (Score:2)
I can't prove a human is more random than a good RNG on an Intel chip, but I will assert that taking the sum of both produces a random number pool better than each separately. Using user input is how Linux, BSD, and other operating systems kept their random number pool going for a while, until hardware RNGs became common in CPUs.
Re:FIPS = Fucking Insecure Pseudo-Security? (Score:5, Interesting)
There is nothing wrong with the FIPS tests, as far as they go, although they focus on bitlevel short-range (de)correlation and are relatively unsensitive to long range patterns. Marsaglia's tests are better for the latter. The problem with both is that they can't possibly protect you against this sort of thing. You can use the world's best (algorithmic) encryption-class RNG, one that passes every single test you throw at it with flying colors, and if you seed it with the number "42" every time you boot the system you will get the same random-looking sequence of bits every time you call the generator.
I do my best to educate people about this sort of thing (I'm the primary author of "dieharder", a testing tool that incorporates Marsaglia's diehard battery of tests, some of the FIPS tests, some tests of my own, and some tests contributed by others) but the fundamental difficulty is that many people just don't know what a random number is and don't understand that "random number generator" is an oxymoron. The XKCD joke posted above is actually remarkably apropos.
The problem is exhibited in the fact that many old books of tables had pages of "random numbers" in them. Even Marsaglia, when he first distributed his diehard test on CD, included files full of "high quality/certified random numbers". This sort of thing has led to people understandably having the misconception that it is numbers that are random-ish, not the PROCESS THAT GENERATES THE NUMBERS (sorry for shouting, but it is frustrating). If you have a "good" pseudorandom number generator (one that produces an acceptable spectrum of results when tested by a decent RNG tester and that has "algorithmic strength" on the basis of mathematics and not just empirical tests -- you really need both, especially for cryptography) and you seed it with a bitwise uniformly distributed and unpredictable seed, you are going to end up with a generator that returns a unique (to the seed) bitwise uniformly distributed, uncorrelated, unpredictable WITHOUT the seed bit sequence, that can be xor'd with a data stream to reversibly encrypt it. The problem is that understanding this much is only the tip of the iceberg as far as good encryption is concerned -- you can't reuse the same seed to send many messages, for example, especially messages that have the same bit patterns in predictable places such as a header (note that I'm NOT an expert on encryption per se, but know enough to appreciate the discipline and know a bit more than that in areas that overlap RNGs per se). Nor can you use a "good" algorithm (say AES or threefish) with a 32 bit seed -- too easy to exhaustively search the seed space. I'm sure there are other, more subtle, Don'ts out there.
But all encryption methods have the chicken/egg problem. To be secure and reproducible, you need a maximum entropy SOURCE to generate the seed bits, and there need to be enough seed bits to not be exhaustively searchable. You cannot get the seed from any sort of table. You cannot generate it with any RNG with its OWN -- 32 bit (don't laugh) -- seed. You cannot generate it with a process that has bias or internal correlation that effectively reduces the information content. It truly does need to be unpredictable, uniform, and not detectably correlated. Generating this isn't easy, and it isn't fast. Servers often lack sufficient entropy to keep up with a strong demand for random bits. Personal computers/laptops usually have more entropy sources and can do better. But ultimately, your entire encryption chain is always as weak as your primary seeding PROCESS.
Is the number 01010101 random? Maybe. If it was generated by a random process it is, even though it looks internally correlated. If you rolled an 8-bit perfect die and excluded all of the numbers that don't "look random", like this one and 00000000 and 11111111 etc, you'd end up with a a lot less than 8 bits of randomness. Numbers per se are never "random", but the process that generates them can be effectively unpredictable (and in the case of quantum processes, possibly "truly random" although this is more a metaphysical statement than an empirical one).
Same for known S-Boxes (Score:1)
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.....
Re: (Score:2)
You cannot be serious
Re: (Score:3)
It is highly likely that there exists at least one set of values for S-Boxes for AES that would make the encryption trivially breakable. It is also highly likely that it would be possible to detect a datastream encrypted with that kind of broken AES. Those are not properties you want in an encryption algorithm.
This isn't news (Score:3)
Re: (Score:3)
Or, if your application is really critical (read, it will cost you a mountain of money, human lives, etc if its encryption fails) you might throw in a well-designed commercial entropy source (a number are out there, including some that at least claim to be quantum based and hence "truly random" and not JUST unpredictable) and xor in that as well. Headless boxes also have a hard time keeping up with entropy demand, so adding a fast high entropy source is a good idea to avoid delays while the system accumula
Re: (Score:3)
What you need is an old fashioned triode amplifier with the gain turned up and no signal fed in. Turn up the amplifier enough and you get thermal noise, to make it nice, compress it a bit and use the middle bytes. (I think most compression algorithms would work for this, all you're doing is making sure that half the bits are on and half off. You could probably do as well though by taking two sample and xor-ing them.)
Re: (Score:2)
Re: (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
It is going to be moderately difficult not to reinvent a wheel in /. commentary. This is big business, worth a lot of money, valuable as a research tool, critical to national defenses round the world, basis of modern commerce and banking, key (so to speak) to personal privacy in the internet era, and what the heck, essential to really excellent games.
One can buy hardware RNGs that plug into USB ports for a few tens of dollars. To efficiently whiten their output (if necessa
Unsalted? (Score:3)
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.