Micro Focus is now part of OpenText. Learn more >

You are here

You are here

ROCA encryption #fail: Worse than we thought (and way worse than KRACK)

public://webform/writeforus/profile-pictures/richi-2016-480.jpg
Richi Jennings Your humble blogwatcher, dba RJA
 

What if you could easily get the private key from a public key? That would be bad.

And what if the key pair was generated by a supposedly-secure hardware enclave, installed in countless PCs, Chromebooks, 2FA dongles and smartcards? And what if the problem silently existed in those trusted devices for 10 years?

Yes, it’s the Return Of Coppersmith’s Attack. In this week’s Security Blogwatch, ROCA makes the sky fall.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention:  The original Blade Runner score

 

Token scurity?

What’s rockin’? Here’s Thomas Fox-Brewster’s cunning angle—Worse Than KRACK:

ROCA [is] another complex but dangerous weakness in widely used … chips made by German company Infineon Technologies AG. [It] is to do with the vendor's implementation of the encryption.

The researchers [will] present their full findings at the ACM Conference on Computer and Communications Security [on November 2]. The researchers (from the Centre for Research on Cryptography and Security, Masaryk University, Enigma Bridge and Ca' Foscari University) crafted a version of an old technique called the Coppersmith's attack.

Infineon didn't check that its [public keys] weren't factorable and so millions of devices are now thought to be vulnerable. … With patches available, [the] first recourse should be vendor updates. Infineon, Google and Microsoft all put out notices last week.

And Dan Goodin says Millions of high-security crypto keys crippled:

A crippling flaw … has fatally undermined the security of millions of encryption keys used in some of the highest-stakes settings, including national identity cards, software- and application-signing, and trusted platform modules protecting government and corporate computers.

The five-year-old flaw is … in code that complies with two internationally recognized security certification standards that are binding on many governments, contractors, and companies. … The flaw is the one Estonia's government obliquely referred to last month when it warned that 750,000 digital IDs … were vulnerable. … Petr Svenda, one of the researchers who discovered the faulty library, also warned [it] had the potential to create problems for elections in countries where vulnerable cards are used.

The flaw resides in [an] Infineon-developed RSA Library [which] allows people to generate keys with … smartcard chips and TPMs. … Factorizing a 2048-bit RSA key generated with the faulty Infineon library … would require [on average 9] days and [$20,150] using … Amazon Web Services and [$38] and [23] minutes to factorize an affected 1024-bit key.

Attackers can first test a public key to see if it's vulnerable. … The test is inexpensive, requir[ing] less than 1 millisecond. … The researchers also scanned the Internet for fingerprinted keys and quickly … found 447 fingerprinted keys—237 of them factorizable—used to sign GitHub submissions … 2,892 PGP keys used for encrypted e-mail, 956 of which were factorizable … 15 factorizable keys used for TLS … almost all of them contain[ing] the string "SCADA" in the common name. … All told, the researchers estimate that Infineon's faulty library may have generated tens of millions of RSA keys.

The vulnerability is especially acute for TPM version 1.2, because the keys it uses to control Microsoft's BitLocker hard-disk encryption are factorizable.

What do these meddling researchers have to say for themselves? Dan Cvrcek is easy for you to say: [You’re fired -Ed.]

Infineon was given nine months to help their customers mitigate the impact of the vulnerability. [This] unusually long time [is] due to the nature and seriousness of the vulnerability.

As this is a serious problem … the rigor of the disclosure process and secrecy surrounding it were exceptional. … The impact of the vulnerability extends far beyond the internet and may touch some e-government schemes, citizen ID cards, EU qualified signatures, and other use cases.

At first, I didn’t quite appreciate the seriousness of the vulnerability on TPM[s]. These are small security chips in computers, which facilitate security. They can also be used to store keys for disk encryption. What I wasn’t quite aware of was that they were also used to secure access to some cloud platforms.

The disk encryption may require not only a generation of new keys, but also re-encryption of whole disks in laptops or PCs. The cloud access security may require well-managed security update of all relevant computers to prevent attacks.

I have personally believed, and I still do, that while the replacement of weak keys generated by TPM modules may be a complex task, replacement of smart cards used by enterprises from VPN access and secure email, to physical access control will be harder still.

We have initially avoided identification of particular types of smart cards … on purpose. … Identification a particular smart card type is non-trivial. [It] can further depend on the manufacturing year. [But] I would … urge companies using smart cards marketed as Gemalto .NET v2 / Gemalto ID Prime .NET [or] Infineon Javacards … to test them … as we have collected several independent reports suggesting these cards produce weak RSA keys. … First indications suggest that weak keys may be present in smart cards manufactured as far back as 2007.

Wait, 2007? That’s even worse than we thought. Lee D is hurting:

Most places will let you turn it off, but sometimes "Secure Boot" is a necessity, especially for odd devices (e.g. Windows tablets, Chromebooks, etc.) and TPM is a part of that. … It's not infeasible that such an attack will hurt BIOS-locking manufacturers … software DRM schemes … Bitlocker (eek!) … activation keys on Windows, etc.

And just about every machine now has [a TPM] to the point that they are incredibly difficult to avoid. Your smartphone probably has one. As does your tablet. And so will your PC.

This is a big ouch.

Of course, if Infineon made this mistake, who else could have made a similar faux pas? Nick Lamb ponders the ACM paper:

The essential fingerprinting trick comes down to this (I had to work all this out while I was discussing it with Let's Encrypt's @cpu yesterday):

Infineon RSA moduli have weird properties, when you divide them by some (but not all) small primes the remainder isn't zero (which would be instantly fatal to security) but is heavily biased. For example when divided by 11 the remainder is always 1 or 10.

[So] if your modulus has an expected remainder for all the 20+ small primes that distinguish Infineon, there's a very high chance it was generated using their hardware. … I have estimated the false positive rate as no more than 1 in 2 million. … There is no "false negative" rate.

I believe the November paper will not announce a new category of RSA weak keys, but instead will describe how to get better than chance rates of guessing RSA private key bits from the public modulus if the key was generated using Infineon's library. Such knowledge can be leveraged into a cost effective attack using existing known techniques.

And Hamid “@hkashfi” Kashfi cashes in:

If you’re managing a big network, you may want to check all your keys before someone else does that for you!

Anyone w/ a DB of keys extracted from embedded devices firmwares tried cross-checking against ROCA? I bet the result will be interesting :)

Meanwhile I'm downloading latest x.509 database of scans.io (212GB of certs) to check it for the lols. … Results actually surprised me. Only 14 SSL (PEM) certificates out of 17.8 million scanned records were vulnerable. … But out of 14, 6 are related to a certain SCADA vendor.

Most YubiKey dongles are vulnerable, too, says @below0day:

Check your #YubiKey for #ROCA vulnerability! Anything shipped after 6/6/17 (version 4.3.5 or higher) is safe!

Meanwhile, Kyle “@essobi” Stone sounds worried:

Uhh.. "The vulnerability is present in NIST FIPS 140-2". Those are audited and have operational checks for RNG. Something is afoot.

I really want to spoof the on-line checker with a "upload your private keys here". lol.


The moral of the story? Get patching (again), and don’t forget your physical tokens. (Google users: Advanced Protection, anyone? Check those YubiKeys!)

And Finally…

Deconstructing Vangelis’ score for Blade Runner

Hat tip: David Pescovitz


You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites… so you don’t have to. Hatemail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.

 

Image source: Flickr

Keep learning

Read more articles about: SecurityApplication Security