The DUHK Attack: FIPS Certification Has Gaps In It

duhk attack
The DUHK attack is not a new vulnerability. But it is still destructive

The latest DUHK attack indeed has a clever name.

And an obligatory logo.

That is, of a duck.

Hackers have assaulted crypto this week again.

The DUHK attack stands for Don’t Use Hardcoded Keys.

Industry experts say that the latest DUHK attack may represent just a part of many other threat models.

Hackers can use the attack to decrypt Virtual Private Network traffic and encrypted browser traffic passively.

What does the DUHK attack rely on?

To start off, a host of errors in implementation techniques.

Hackers launch the DUHK attack while looking out for ancient security products and/or appliances.

Admittedly, this allows hackers to take advantage of an old vulnerability.

Some say these appliances have had this vulnerability for over two decades.

This vulnerability usually exists in an old pseudorandom number generator.

It is true that the issue is present in ANSI X 9.17 / x 9.31 PRNG.

And developers should have patched it a long time ago.

The issue is problematic especially on old versions of specific VPN gateways and firewall appliances.

Researchers now believe there is another much larger issue at hand.

You see, developers built PRNG design right into several crypto standards.

PRNG first came on to the scene in 1985.

Moreover, PRNG managed to stay on FIPS 140-2 and FIPS 140-1 approved algorithm lists till January 2016.

The even more problematic part is that government systems had approved the use of PRNG till January 2016 as well.

Researchers revealed these insights recently in a paper.

They titled the paper Practical State Recovery Attacks Against Legacy RNG Implementations.

Researchers also revealed that they had found more than a dozen products that had a vulnerability to the DUHK attack.

And all of these products that FIPS 140-2 certification.

According to researchers, such products contained a static hardcoded key in their source doe.

This rendered these products vulnerable to the DUHK attack.

Researchers also developed a DUHK attack of their own.

They used it against Fortinet Fortigate VPN gateways.

These VPN gateways ran FortiOS version 4.

Researchers also faced no major hurdles in recovering private encryption keys.

And all it took them were a couple of seconds in terms of computation time.

Researcher Findings

All vulnerabilities are dangerous. It doesn’t matter if they are old

Researchers wrote in their paper that they measured the supposed prevalence of the DUHK attack vulnerability on the current visible internet.

They used active sans and managed to find out that they could recover the existing random number generator state for many HTTPS hosts.

About 21 percent of them.

These HTTPS hosts served a default product certificate from Fortinet.

Moreover, researchers could use the DUHK attack on 97 percent of hosts that contained metadata which could identify FortiOS v4.

Researchers also revealed that they successfully demonstrated the recovery of the full private key out in the wild.

They did so against an actual subset of hosts that accepted IPsec connections.

In an interview with Threatpost, Heninger said that nation states would keep the DUHK attack on their radar from now on.

She also said that the DUHK attack represented a passive decryption ability.

It affects ancient versions of Fortinet/Fortigate products.

So what should worried sysadmins do?

Should they patch everything if they find that their company is using products vulnerable to the DUHK attack?

What if they have a Fortigate version that is vulnerable to the DUHK attack?

Well, according to Heninger, they should apply the required patches as soon as possible.

However, if the company doesn’t use a DUHK attack vulnerable version of Fortigate that they don’t need to worry about too much.


Because the DUHK attack isn’t a vulnerability that too many script kiddies could exploit.

The Problem With ANSI X9.17/x9.31 PRNG

NIST deprecated ANSI X9.17/X9.31 back in 2011.

Moreover, it banned ANSI X9.17/X9.31 back in January 2016.

Researchers had known about its core weakness since a 1998 paper though.

John Kelsey, Chris Hall, David Wagner and Bruce Schneier wrote that paper 1998 and hence the community considers these researchers as crypto pioneers.

If you read the paper, it clearly points out that if a hacker learned a system’s static key and/or other basic raw output, then ANSI PRNG would become useless in offering any security to the system.

In a blog post that Green wrote to accompany the paper’s release back in 1998, he said that he considered it very unlikely that a hacker could learn about a system’s static key.

On a side note, of those researchers, Kelsey still works with NIST.

Commentators are questioning as to why approving bodies didn’t do something about the flaw earlier.

Green’s DUHK Attack Post Comments

Green wrote that if a hacker ever obtained K somehow and then went ahead to learn about only a single 16 byte, Ri, raw output block via a working PRG, then the hacker could accomplish a lot of menacing things.

Some of which included,

  • Guess the system’s timestamp T
  • Decrypting by using K and working backwards to recover the system’s corresponding state value V
  • Then run the generator backwards or forwards by guessing values for T in order to obtain subsequent and every previous output of the generator.

Green also said that thus if a given application used the ANSI generator in order to produce something similar to a random nonce and also could use the generator in order to produce secret keys then this could allow a hacker to potentially recover the generated secret keys.

And then move forward to completely break the related protocol.

Readers should also know that nonce is something that is usually sent in clear text format in a protocol.

Heninger also questioned as to why the FIPS certification process didn’t manage to protect against the DUHK attack.

Because according to her the vulnerability existed two decades ago as well.

Moreover, she also questioned how and why more than a dozen DUHK attack vulnerable products that researchers identified in the paper managed to pass the same FIPS certification process.

She said that her team had interest in the more broader questions of how they could make the FIPS certification process a bit more effective in order to keep such type of things from happening in the future.

Furthermore, she said, why did people still use all these ancient algorithms which actually worked a lot worse than most modern random number generator designs.

She says that these ancient algorithms should have gone out of business and retired decades ago.

Heninger also pointed out that she hoped that officials who had the responsibility to set the policy for crypto standard usage at the top government level could pay more attention to the latest research.

Moreover, they should also take steps in order to retire old DUHK attack vulnerable algorithms.

The government should also encourage researchers to work some more and examine all the old standard that may or may not have similar DUHK attack vulnerabilities and gaps in their security.

Heninger also mentioned that to protect systems against DUHK attack vulnerability and other types of attacks, researchers needed to vet implementations a bit more carefully.

Researchers should also take a fine-toothed comb for all of the modern and old random number generators algorithms that are still in use today.

Ending her comment, Heninger said that speaking from a policy perspective, she didn’t have a clear idea on how they could push the whole community away from all the DUHK attack vulnerable implementations.


Zohair A. Zohair is currently a content crafter at Security Gladiators and has been involved in the technology industry for more than a decade. He is an engineer by training and, naturally, likes to help people solve their tech related problems. When he is not writing, he can usually be found practicing his free-kicks in the ground beside his house.
Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.