Masaryk University (Brno, Czech Republic) has discovered a vulnerability in Infineon security chips back at the beginning of the year. Today marks the first public release, which covers the potential impact of the ROCA (Return of Coppersmith’s Attack) vulnerability.
As two of the people involved were also affiliated with Enigma Bridge, we decided to get involved and help with this initial publication. Let me start with a list of primary information sources, which were due to be released on 16th October, at noon UK time:
- A short technical introduction – Centre for Research on Cryptography and Security blog
- An initial Ars Technica article covering the issue – https://arstechnica.com
- Our online test suite – test your public key (paste, upload file, send email, download Python tool) at keychest.net/roca (or https://rocahelp.com)
- An alternative online test provided by CryptoSense at https://keytester.cryptosense.com
What happened up till now
First notifications to the manufacturer, Infineon, was sent out back in February and it has been a long time since, when the team provided an expert support to a number of customer companies using the impacted chips. They dedicated a lot of time and effort into providing an additional support, all free of charge.
The press release, technical descriptions, and tools published today is the first set of public information being released. In other words, Infineon was given nine months to help their customers mitigate the impact of the vulnerability.
I also want to stress that the team has put in place rigorous rules for responsible disclosure and today is the end of the agreed non-disclosure period, which has been extended to an unusually long time of nine months due to the nature and seriousness of the vulnerability.
The purpose of this release is to make end users and companies aware of the issue and help them assess a potential impact of the Return of Coppersmith Attack (ROCA) vulnerability on their systems and applications. It is also an additional early warning that the publication of technical details is imminent and security patches and upgrades should be completed without delay.
What is responsible disclosure
The responsible disclosure framework is a multi-stage process to prevent third parties gaining security, financial, or other advantage over users of products vulnerable to (cyber) attacks. These best practices have been established to protect users by ensuring that security vulnerabilities are corrected in a timely and orderly fashion and they are widely accepted by the IT industry, and government bodies (CERT, CSIRT, OWASP, NIST, etc.). Publishing vulnerabilities helps identify their causes and improves the overall security of technology users.
The ROCA vulnerability allows computation of RSA private key from its public component with low to medium budget and computation times from minutes to days. The vulnerability has been verified for RSA keys of up to 2,048 bits. A successful computation of a private key allows, depending on its use, decrypt sensitive data (from file encryption to HTTPS), forging digital signatures (email security, qualified signatures), impersonation (access control to IT systems or buildings), or personal identity theft (e-ID cards).
As this is a serious problem for a range of products used primarily for ensuring the security on the internet, the rigor of the disclosure process and secrecy surrounding it were exceptional by any comparison. 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 unrelated to computers as such.
What is ROCA
The official disclosure process concludes with the publication of technical details of the ROCA vulnerability at the ACM CCS 2017, a computer security conference, on 2nd November 2017 in Dallas, USA under the title: The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli.
This additional (and unusual) step gives companies and users an extra time to understand their exposure, consider their risk, and decide what steps to take.
While there are now tools available for detecting insecure RSA keys, no further information about the vulnerability will be published before the ACM CCS conference.
What we believe remains secure
Some large deployments of these security chips are NOT impacted. There are two general cases, which limit the vulnerability impact:
- where RSA keys are generated outside the security chips, e.g., EMV (chip & PIN and chip & signature) banking cards, or passports should not be affected;
- where design of products avoided using the vulnerable function of the chips – we believe that, e.g., Gemalto has in many cases replaced the default library with its own.
Let me mention TPM
At first, I didn’t quite appreciate the seriousness of the vulnerability on TPM modules. 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.
These two particular uses may need a particular care. 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 as a single vulnerable laptop may become an unauthorized backdoor.
Why I picked TPMs in particular? The reason is the sheer volume as 25-30% of all TPM chips globally are likely to contain the vulnerability.
If you suspect you or your organization’s security may be at risk, we have implemented an online tool for RSA public keys, which will help you assess your exposure to the vulnerability, It is available on these web addresses:
Please contact manufacturers of products you suspect may be affected, or check their latest bug and press releases, and product updates for more information.
A list of possible mitigation, risk management actions includes:
- replacement of security chips / products with these chips with secure ones;
- change the source of RSA keys to a secure key generator;
- replace RSA algorithm with an elliptic curve encryption (ECC);
- shorten the lifetime of RSA keys;
- limit access to repositories with public keys; or
- separate data-at-rest and data-in-transit encryption.