ROCA: Vulnerable RSA Key Generation

Last updated at Fri, 15 Dec 2023 00:41:17 GMT

In the KRACK-related and BadRabbit-related chaos of the past week and a half, some people missed a less flashy vulnerability that nevertheless dug up key long-term questions on IoT supply chains and embedded technology. The Czech-based Center for Research on Cryptography and Security published research last weekon a vulnerability (CVE-2017-15361) in the RSA key generation process in a widely-used cryptographic software library found in Infineon secure chips. Specifically:

“The algorithmic vulnerability is characterized by a specific structure of the generated RSA primes, which makes factorization of commonly used key lengths including 1024 and 2048 bits practically possible. Only the knowledge of a public key is necessary and no physical access to the vulnerable device is required. The vulnerability does NOT depend on a weak or a faulty random number generator - all RSA keys generated by a vulnerable chip are impacted.”

A security flaw in the RSA key generation process used within embedded technology is a critical issue—and one that’s likely to keep haunting us. Often when hardware attempts to ensure only authorized code runs or is updated on that platform, the manufacturer deploys what is known as a Trusted Platform Module (TPM), which keeps the encryption keys necessary to validate signed code locked down in “hardware” to prevent others from accessing those keys. However, for all intents and purposes, hardware is just software repackaged: when a software library used to program a piece of hardware has a flaw, you still have to fix that that “hardware” vulnerability the same way you would a software vulnerability. In cases like this, the fact that the TPM is locked down means it’s very hard to remotely push an update by design. In many hardware cases, bugs like this one will be unfixable without a recall.

It’s difficult to know the full extent of the ROCA vulnerability’s impact, since key generation happens at the hardware level. As with any vulnerability leveraging embedded technology, there aren’t currently any good ways of definitively identifying and tracking who’s using the affected chips—much less a method for universal patching. Simply having the library compiled into the product does not mean key signing is vulnerable; many TPM systems only verify signatures and are not themselves the source of the key pair generation. Vulnerability would depend in large part on development teams and how they decided to roll out their products.

Mitigation

The researchers who disclosed the vuln last week also released a number of detection tools to help users determine whether a product they use is vulnerable. If you suspect a product you use is affected, it would be wise to run these tools against the public key signature, (provided you have access to that key signature). One best methods for reducing risk prior to patch availability is to use largest key possible. A key length of 2048, for instance, requires expenditure of up to $40K in processing power for an attacker. Unless you’re a particularly high-value target, attackers are unlikely to spend that level resources on you. Using a 2048- or 4096-length key is significantly prohibitive as far as attacks go.

The Rapid7 Labs team did a check using Project Sonar and found that of all the SSL certificates used on HTTPS services exposed on the public IPv4 internet, the CRoCs detection tools only identify 15 as being affected by this issue. All 15 are SCADA-related. Our findings here almost exactly match the original researchers’ findings.

Asking the right questions

This RSA key generation vulnerability is a useful opportunity to point the industry toward the right question: How do we manage and track chip component supply chain? How do we track open source library usage within embedded technology? How do we build effective and secure over-the-air patching solutions?

Builders of embedded products often use a number of sub-components manufactured by other companies, which may then use any number of various chip sets (including chip sets that contain this vulnerable code library). In the cases where we can track their usage, how do we patch them? Whether hardware manufactures want to believe it or not, they are now software companies: they’re responsible for the firmware installed on their products. The software industry has done a good job at building out patching processes for software products, but the embedded product industry hasn’t yet achieved this level of maturity.

As the hardware industry matures, it’s critical that consumers be provided with a bill of materials (BOM) that each product includes. This BOM should list any significant Integrated Circuits (ICs), such as Microcontrollers and their version numbers. They should also list libraries and versions used in the firmware. As we move forward into a world with more over-the-air (OTA) update capabilities, it will be important to have a standard way to query each devices to get version numbers of both the firmware and libraries used.