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.

Comments

I love it.

[Anonymous Coward]

Who thinks this is an accident, show of hands?

Re:I love it.

[Anonymous Coward]

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

Re:I love it.

[olsmeister]

I learned very early on to use a random number to initialize the RNG.

Re:I love it.

[najajomo]

@Anonymous Coward: "Who thinks this is an accident, show of hands?"

Going on the down vote, there's at least one ..

Re:I love it.

[DickBreath]

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.

Re:I love it.

[Anonymous Coward]

Yeah, the first thing I always do is "srandom(random())".

Re:I love it.

[DickBreath]

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.

Re:I love it.

[barbariccow]

But then what seeds the seeder?

Re:I love it.

[barbariccow]

moose movements

Moose are a pretty slow source of entropy. Better to use a cat chasing its tail.

Re:I love it.

[Anonymous Coward]

Wooosh...

Re:I love it.

[fuzznutz]

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:I love it.

[Anonymous Coward]

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.

Duh! Of Course A DUH Attack Recovers Duh Keys

[dryriver]

Duh! Duh! Duh! =)

Re:Duh! Of Course A DUH Attack Recovers Duh Keys

[BlueStrat]

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

[Anonymous Coward]

This is what you're doing if you hardcode PRNG seeds:

int getRandomNumber()
{
    return 4; // chosen by fair dice roll, guaranteed to be random
}

221

Re: RNG

[Anonymous Coward]

âoethe Illusion of safetyâ
- Tyler Derden

Re: RNG

[Anonymous Coward]

This casts the mind back to the original ps3 jailbreak.
Thereâ(TM)s accidentally sloppy, and then there is intent.

Re:RNG

[Anonymous Coward]

AAAAnnnnddddd.... Three code monkeys just cut and pasted that function. Thanks.

capcha: exorcism

Re:RNG

[rgbatduke]

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, there are always hardware sources (including many modern CPUs as well as over the counter ones). Attacks like this have been known and exploited for a long time, and it is honestly a bit difficult to imagine anybody who knows enough to write a VPN in the first place not knowing enough to avoid the problem, but hey, never attribute to malice and corruption that which can easily be explained by human stupidity.

Elon Musk has it all wrong. World War III won't be started by artificial intelligences run amok -- that's irresponsible science-fiction-fantasy-land talk designed to feed his personal narcissism with still more headlines. World War III will be started by purely human stupidity with a soupcon of narcissism on the side. FSM knows that there is plenty of both running rampant in the world today.

Re:RNG

[93 Escort Wagon]

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:RNG

[arglebargle_xiv]

Could someone explain to me why implementing the PRNG in Rust would have prevented this vulnerability?

Re:RNG

[Anonymous Coward]

Yes.

Sounds Familiar

[mentil]

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:Sounds Familiar

[Anonymous Coward]

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.

The secret squirrels are about to loose easy WiFi access, except for phone traffic that has built in binary blob for the phones model. You can see their panic as VPN's polish their acts and eliminate the easies..

Re:Sounds Familiar

[DaMattster]

OpenBSD is not vulnerable to this attack because it does not use ANSI X9.31. Therefore it is still "relatively" safe to use for hard-coded keys. That much said, the manual pages take pains to discourage people from using hard-coded keys at all. Since OpenBSD does not suffer many of the vulnerabilities, I just throw it on two (or more) systems when I need to spin up a VPN.

Re:Sounds Familiar

[AHuxley]

XKeyscore, Turmoil, Keycard, Hammerstein, Turbine, Apex, Coral Reef... Fashioncleft.
Collect it all gets that Encapsulating Security Payload :)

Re:Sounds Familiar

[Anonymous Coward]

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:Sounds Familiar

[arglebargle_xiv]

The problem isn't the use of the X9.17/X9.31 PRNG, it's the use of a hardcoded key with the PRNG and misuse of the PRNG's output. So OpenBSD could be quite vulnerable to all sorts of things that don't involve this particular PRNG. Conversely, something using this PRNG isn't automatically vulnerable.

AI

[110010001000]

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.

Re:AI

[DaMattster]

The tech industry is long on grandiose ideas and VERY short on delivery. What does get delivered is usually a crappy, half-baked app written in India that crashes when you hit the menu button.

Re:AI

[Anonymous Coward]

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 currently can’t stand. A cat^W^WHilllary is fine too. Not trying to be political. *All* of politics is moronic.)

Re:AI

[110010001000]

What AI "actually works"? And don't say "playing Go" or "playing Chess".

Re:AI

[Anonymous Coward]

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:AI

[barbariccow]

Karl the robot can find his way out of a maze if he makes every right turn.

Re:AI

[Anonymous Coward]

The AI is good for figuring out patterns in large sets of data, that's all.
For example, the AI would be good at calculating the seeder seed. ;-)

You don't understand...

[Anonymous Coward]

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?

Re:You don't understand...

[Anonymous Coward]

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:You don't understand...

[Anonymous Coward]

Everyone knows that ICE and ICE breakers came from AI, duh.

Re: You don't understand...

[Anonymous Coward]

as if a bot could do that ðY(TM)

FIPS = Fucking Insecure Pseudo-Security?

[Anonymous Coward]

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! ;)

Re:FIPS = Fucking Insecure Pseudo-Security?

[aaarrrgggh]

How do you test on your RNG to make sure it is random without FIPS?

Re: FIPS = Fucking Insecure Pseudo-Security?

[Anonymous Coward]

FIPS protects against a few things, but leaves you open to a host of other problems. It gives a false sense of security, which is the main problem with FIPS apps. People assume that since they got FIPS thier app is secure and they don't need to worry about security anymore.

Re:FIPS = Fucking Insecure Pseudo-Security?

[rgbatduke]

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

Re:FIPS = Fucking Insecure Pseudo-Security?

[ctilsie242]

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:FIPS = Fucking Insecure Pseudo-Security?

[aaarrrgggh]

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:FIPS = Fucking Insecure Pseudo-Security?

[ctilsie242]

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.

Same for known S-Boxes

[Anonymous Coward]

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:Same for known S-Boxes

[fisted]

You cannot be serious

Re:Same for known S-Boxes

[Anonymous Coward]

S-Boxes are chosen to make the math work. They are no different than saying you need to use a prime number at some point in the calculation (eg. RSA). They are not keys.

Re:Same for known S-Boxes

[amorsen]

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

[sinij]

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.

Re:This isn't news

[rgbatduke]

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 accumulates more "random" bits.

Re:This isn't news

[HiThere]

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:This isn't news

[sinij]

If you trying to condition it, instead of compressing, pass it through SHA1.

Re:This isn't news

[rgbatduke]

https://en.wikipedia.org/wiki/...

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 necessary -- a good one should already produce white/unbiased output) you can always xor them with a white PRNG -- it doesn't even have to be a terribly GOOD white PRNG, as long as it passes the bit distribution tests in dieharder (some from FIPS, some I made up myself) that rigorously check that all bit patterns occur according to the multinomial distribution as they should (a bit stronger than just counting 0's and 1's or 00 01 10 11 patterns, in other words).

That's why I'm surprised that supposedly professional companies selling VPNs did something as boneheaded as use a hard coded seed. Seriously? What, did their "security expert" sit at a table with the board and say "Hey, we need to make this encryption really, really random, based on a number nobody can possibly guess. Everybody give me your birthdays and we'll turn them into our secret key..."? You can do better -- you can do decently well, in fact, just reading pages on Wikipedia on the subject, e.g.: https://en.wikipedia.org/wiki/.... Cryptography has a long and colorful history, filled with illuminating examples such as the fact that World War II was to some extent won by the allies because they beat the shit out of the axis encryption schemes, inventing and building some of the earliest electronic computers to do so. Even now, civilization teeters on the brink because if somebody figures out solutions to certain "hard" computational problems (like prime number generation or factorization) SSL, SSH, and RSA-based methods in general are screwed, and with them pretty much all of modern e-commerce. To pull something as boneheaded as this requires real stupidity, almost wilful ignorance.

Unsalted?

[redelm]

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.

Re:Unsalted?

[Anonymous Coward]

There's plenty more sources for pseudo-random data that could be mixed in:
hard drive / solid-state drive R/W speeds
Drive sizes, letters, names.
Working directory size, every Nth letter in every Nth filenames.
network activity, IPs, fileshare information, network name. (again, sections of data from each, not all)
and so on.

Once you feed that in to the system, along with feeding it back through itself with these data sources, a few times, it can become incredibly random very quickly.
Brute-forcing the system then becomes a universe-ending timeline the more iterations you do for this initial base seed.
This then becomes the base seed for the rest of encryption.
Every so often, re-seed it with the above data depending on your requirements for security.
The first time the encryption algo is used will have a slower response than any other because the initial generation stage. The re-seed data fetching segment will always be gathering noise from the above sources that change regularly.

Essentially /dev/urandom and any other similar system of gathering entropy.
A large enough data set from it is more than enough. Unless you expect your mad encryption container of yourself in a gimp suit to get out in the time you are alive because magical quantum computers and the NSAs hate-boner for you. Then just go use /dev/random to calm your paranoia.

Harder issue to deal with in embedded systems though. I could easily understand if it was where the problem existed.
Hardware and static firmware create predictable boots most times unless there are weird temperature spikes or drops the next time it boots. Should always keep a little writeable area for storing the last set of data to ensure integrity, if you actually do need it. You can't generate secure WiFi keys if a person hasn't connected to you yet and everything else is predictable, just ain't happenin'.

"Great minds think alike"... apk

[Anonymous Coward]

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

DUHK?

[Anonymous Coward]

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?