Yubico To Replace Vulnerable YubiKey FIPS Security Keys

Yubico said today it plans to replace certain hardware security keys because of a firmware flaw that reduces the randomness of cryptographic keys generated by its devices. From a report: Affected products include models part of the YubiKey FIPS Series, a line of YubiKey authentication keys certified for use on US government networks (and others) according to the US government's Federal Information Processing Standards (FIPS). According to a Yubico security advisory published today, YubiKey FIPS Series devices that run firmware version 4.4.2 and 4.4.4 contain a bug that keeps "some predictable content" inside the device's data buffer after the power-up operation.

This "predictable content" will influence the randomness of cryptographic keys generated on the device for a short period after the boot-up, until the "predictable content" is all used up, and true random data is present in the buffer. This means that for a short period after booting up YubiKey FIPS Series devices with the affected 4.4.2 and 4.4.4 versions will generate keys that can be either recovered partially, or in full, depending on the cryptographic algorithm the key is working with for a particular authentication operation.

The lab dropped the ball on this one

[sinij]

As part of FIPS 140-3 certification, the certifying lab suppose to examine entropy generation. Here is YubiKey CMVP certificate [nist.gov]. Apparently, someone at UL VERIFICATION SERVICES INC dropped the ball on checking entropy generation.

Re:

[hsmith]

The CAVP tests are to blame and the entropy evaluator. The lab runs automated tests and validates it against tools that NIST and the NSA provide. So, I don't think it is just the blame no the lab itself.

Re:

[sinij]

As part of CMVP, the lab also suppose to verify NIST SP 800-90B [nist.gov] is followed and run statistical tests on a large sample of collected entropy data. If this was correctly tested, predictable part of initial entropy pool would have caused statistical test to fail.

Re:The lab dropped the ball on this one

[gweihir]

Certification is mostly useless for security. It is more of a CYA mechanism, where the incompetent or the clueless can excuse their screw-ups by "But we had _certification_!". Sure, there is some overlap between security certification and and actual security, but it is pretty small.

Re:

[arglebargle_xiv]

Yup. FIPS 140 certification is a measure of how desperate a company is to sell to the USG, the higher the level, the more desperate they are. You could get the same effect by making vendors set fire to a pile of US dollars, the more you burn, the higher your FIPS 140 level, however some people might possibly get a bit suspicious about what's really going on then, so instead it's dressed up in security theatre to make it look like value is being added.

Apart from the uselessness of FIPS 140, the vuln is also

Re:

[mysidia]

And yet they were certified to FIPS anyways, just fine. This basically proves by counterexample of how worthless the FIPS certification process is/how much value FIPS140-3 certification label on hardware clearly does NOT have.

How many other "FIPS Certified" devices have security flaws so severe that they Ought to not have been certifiable, but got to have the certification seal, nonetheless?

Re:

[guruevi]

You can pay most production companies in China to get UL, FCC, FIPS and a host of other certifications. It costs nothing if you use their production facilities.

Re:

[TechyImmigrant]

As part of FIPS 140-3 certification, the certifying lab suppose to examine entropy generation. Here is YubiKey CMVP certificate [nist.gov]. Apparently, someone at UL VERIFICATION SERVICES INC dropped the ball on checking entropy generation.

The restart tests that would catch this have been in draft form forever, but only recently got standardized and don't come into force until Sept 22nd. That said, whitebox design review should have found it.

That does not inspire confidence

[gweihir]

This is basically a beginner's mistake or the mistake a coder that has no clue about coding cryptographic mechanisms. The bug itself is one thing, but for such a bug to be happening, the development process is pretty badly faulty and something like this or other problems related to incompetence are likely to happen or already be present. This is a sign of "cheaper than possible" coding and coders.

Re:

[DigitAl56K]

What is also concerning are that multiple vendors are doing recalls recently:
https://www.engadget.com/2019/... [engadget.com]

It is very good that they are doing the responsible thing (disclose, replace), but worrying nonetheless.

Re:

[gweihir]

As I said, "cheaper than possible" coding and engineering. The "no-understanding" MBA scourge at work. Will take some time, but in the end these morons will finally find out that technology has to be solid, even if that means expensive people doing it. Because the alternatives are much more expensive.

Re: obi7ch

[Anonymous Coward]

I just do it manually. Check the buffer to see if the checksum matches the previous day (no need to tediously look at every byte) then hit reset then add new key, usually based on date and time and often current state of the chip. I've done this every day since the device flaw was uncovered. No big deal.

Huh?

[Ol Olsoc]

Yubico Yubikey FIPS Keys?

Sounds like something from an episode of Rick and Morty. Something Floopy Noopers might have said.

Someone Tell Intel About This

[Marlin Schwanke]

Actually replacing defective hardware. What a concept. Now if we could get Intel to replace all those Spectre & Meltdown ridden processors they’ve sold us.