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.
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.
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.
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).
Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.
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.
moose movements
Moose are a pretty slow source of entropy. Better to use a cat chasing its tail.
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.
Finally! A year of moderation! Ready for 2019?