We have reasonable grounds to believe that all Gemalto IDPrime .NET smart cards generate weak RSA keys vulnerable to the recently published ROCA vulnerability (CVE-2017-15361, VU#307015). Gemalto stopped selling these cards in September 2017, but there are large numbers of cards still in use in corporate environments. Their primary use is in enterprise PKI systems for secure email, VPN access, and so on.
The ROCA vulnerability does NOT seem to affect Gemalto IDPrime MD cards. We have also NO reason to suspect the ROCA vulnerability to affect Protiva PIV smart cards, although we couldn’t test any of these.
We have collected a number of reports of weak keys generated by cards manufactured between 2008 and 2017 over this week. All reports so far confirm RSA keys affected by the ROCA vulnerability.
As first indications suggest a better proof of the vulnerability may be required due to the potential impact on their users, we have generated a short RSA key (512 bits). Despite its short length, it verifies the validity of our assumption that the available key testing tools are accurate. While this key length is not acceptable for any practical use, breaking these RSA keys still requires several gigabytes of disk space and days of processing on a desktop computer.
We asked the team from Masaryk University to attempt the factorization of this key. They completed the actual factorization, using a low cost virtual machine in less than 20 minutes, fully in line with the theoretical estimate of less than 2 hours. (Update: another key took 3 minutes on a laptop.)
The checker available online (https://keychest.net/roca) showed the key as vulnerable, and the toolkit used by Masaryk university was identical they used to verify ROCA vulnerability previously.
- Follow updates from Gemalto and any advise it will provide to its customers.
- Initiate your internal security incident plans.
- If your internal assessment concludes that you need to take remediation action, please consider the following notes:
If you use affected smart cards and they generate their RSA keys, you will need to either change the way you generate the keys, the algorithm you use (RSA to Elliptic curve signature), or replace smart cards with secure ones.
There may still be applications using 1,024 bit keys, which can be factored in minutes once the attacker gets respective public keys. (there can be practical reasons for this configuration – e.g., signatures are used for authentication in combination with passwords, generation of longer keys fails and as it times out sessions of web-based applications). The ROCA vulnerability completely changes relevant risk profiles and you’re strongly advised to re-evaluate an impact of this change.
Complete remediation of vulnerable systems where .NET smart cards are used for authentication requires replacement of smart cards, and revocation of all certificates issued for insecure keys. Temporarily, the risk can be managed by increasing the key length (3072 bits) or by shortening the validity of certificates.
If application(s) utilizing .NET smart cards protect documents or messages, where you rely on an ability to verify the content or the origin for a longer period of time, you may also need to implement additional security mechanisms, which can be used to verify the documents haven’t changed since their creation or delivery if there’s a dispute about the content or the origin.
If you already implemented multiple protection mechanisms to increase your resiliency against cyber attacks, you are advised to evaluate the change in your risk exposure and implement appropriate changes to protect your company from any new unacceptable risk.
Try the Professional HTTPS/TLS monitoring service KeyChest.net to keep on top of your certificates with its certificate auto-discovery. The public cloud service is free and allows you monitor thousands of certificates within minutes (YouTube video – 49 seconds).