DUHK (Don't Use Hard-coded Keys) is a vulnerability that affects devices using the ANSI X9.31 Random Number Generator (RNG) in conjunction with a hard-coded seed key. The ANSI X9.31 RNG is an algorithm that until recently was commonly used to generate cryptographic keys that secure VPN connections and web browsing sessions, preventing third parties from reading intercepted communications.
DUHK allows attackers to recover secret encryption keys from vulnerable implementations and decrypt and read communications passing over VPN connections or encrypted web sessions. The encrypted data could include sensitive business data, login credentials, credit card data and other confidential content.
The affected implementations were all historically compliant with FIPS, the Federal Information Processing Standards.
Traffic from any VPN using FortiOS 4.3.0 to FortiOS 4.3.18 can be decrypted by a passive network adversary who can observe the encrypted handshake traffic. Other key recovery attacks on different protocols may also be possible.
We also found eleven other historically FIPS-certified implementations that document hard-coded X9.31 RNG seed keys in their products. We give the full list in our paper.
Users of affected products should apply the latest software updates.
A device is vulnerable to DUHK if:
It uses the X9.31 random number generator
and
The seed key used by the generator is hard-coded into the implementation
and
The output from the random number generator is directly used to generate cryptographic keys
and
At least some of the random numbers before or after those used to make the keys are transmitted unencrypted. This is typically the case for SSL/TLS and IPsec.
Practical state recovery attacks against legacy RNG implementations [PDF]
By Shaanan Cohney, Nadia Heninger, and Matthew D. Green
The team can be contacted at mail@DUHKattack.com.
Developers of cryptographic software should stop using the X9.31 generator. It was removed from the list of FIPS-approved random number generation algorithms in January 2016. If you must use a block cipher-based RNG, don't use a hard-coded key, and regenerate the key frequently.
Regularly apply software updates. It's good practice and will protect you against flaws that are of greater risk to you than this one.
Update your products to comply with the latest standards. We don't know of any backdoors in the current list of recommended algorithms.
Weakening, sabotaging, backdooring, or frontdooring encryption standards may harm both the overall security of your country as well as your reputation!
Is the vulnerability currently being exploited by attackers?
Does DUHK allow an attacker to steal the server’s private key?
My device is certified FIPS compliant. Am I still vulnerable?
Why should I care about an attack that targets only legacy devices?
Are you planning to release the code for your implementation of the attack?
DUHK stands for Don't Use Hard-coded Keys
Full details are available in our technical paper. With a summary below:
The ANSI X9.31 PRNG is a pseudorandom number generator algorithm design that was included in various forms on cryptographic standards and listed as an approved RNG for FIPS certification for decades. This PRNG has a vulnerability that was described by Kelsey, Schneier and Hall as early as 1998. The RNG uses block cipher encryption with a "seed key" to update a state value from a timestamp. When this "seed key" is known to an attacker, she can recover all previous and future outputs of the generator from 16 bytes of output and a guess for the timestamp.
The general DUHK attack is a state recovery attack against implementations of the X9.31 RNG. It allows an attacker who knows the AES or DES key used by the implementation to recover the secret internal state of the random number generator after observing some output.
The specific attack against the IKEv2 handshake as implemented in FortiOS v4 works as follows:
The attacker reverse-engineers a firmware image and extracts the hard-coded AES encryption key.
The attacker passively observes both sides of an IKEv2 handshake.
The SPI and nonce fields in the IKEv2 handshake are raw RNG output. The attacker brute forces a range of timestamps at the microsecond granularity to recover the internal state of the RNG from these outputs, and confirms against the raw outputs. This step required 224guesses in our experiments.
The secret exponent in the IKEv2 Diffie-Hellman key exchange is generated immediately after these values. The attacker brute forces another timestamp to recover the Diffie-Hellman secret which it confirms against the public key. This step required 25 guesses in our experiments.
The attacker can then compute the shared secret and derived sesion keys, and begin to decrypt traffic.
DUHK was developed by researchers at the University of Pennsylvania and Johns Hopkins University: Shaanan Cohney, Nadia Heninger, and Matthew D. Green.
The team can be contacted at mail@DUHKattack.com.
Yes. The DUHK attack for Fortinet FortiGate devices was assigned CVE-2016-8492.
Yes. Our attack against Fortigate device can be carried out on a modern computer in about four minutes. In the more general case, the practicality depends on the specific implementation details of the RNG.
We have no evidence to suggest that this is the case. You should apply the latest software update anyway.
We prefer to think of it as a front door secured by a hotel minibar key. More seriously, there is no way of knowing whether this type of implementation flaw or the standards that failed to account for it is intentional or has been exploited.
No. DUHK allows an attacker to decrypt one connection at a time by compromising the key exchange.
No. This is an entirely passive attack.
Please visit Emojipedia and set your font size appropriately.
This random person we don't know is selling duck emoji tshirts.
Yes. Also a techno remix.
Potentially. The X9.31 RNG was deprecated by NIST in 2011 and removed from the list of FIPS-approved RNGs in 2016. If your product was certified after January 2016, then it is not vulnerable. If it was certified for the X9.31 RNG at any time, FIPS certification does not prevent this implementation vulnerability.
Internet scanning research shows large number of legacy devices are used many years after they reach end of support from manufacturers. Our scans found at least 23,000 devices with a publicly visible IPv4 address running a vulnerable version of FortiOS.
More generally, this attack underscores the need to design cryptographic standards to preclude known implementation vulnerabilities.
No.
The DUHK attack is a historical failure of the federal standardization process for cryptography. The general vulnerability has been known for at least two decades, yet none of the descriptions of the algorithm we could find mentioned that the seed key should be unpredictable to the attacker.
This vulnerability should be viewed in the context of a multi-year line of research showing how subverted standards, parameter choices, subtle vulnerabilities, and implementation flaws might allow state-level actors to passively decrypt encrypted network traffic.