Researchers recently discovered a dangerous vulnerability – called ROCA – in cryptographic smartcards, security tokens, and other secure hardware chips manufactured by Infineon Technologies. These articles on Ars Technica and The Register give a good background.
Is this a serious problem?
Yes. It’s serious in practice and in principle. Infineon used a flawed key generation routine, which means those keys are easier to crack, and the routine is used in chips embedded in a wide variety of devices. It’s reckoned that the flawed routine has been in use since 2012 and has probably been used to generate tens of millions of keys. Naturally, many of those keys will have been generated precisely because someone had data or resources that they particularly wanted to secure.
It’s serious because a flawed implementation managed to get through all the development and standardisation processes without being spotted, and has been widely deployed on mass-market devices.
What’s the flaw, and why does it cause a problem?
The flaw affects keys generated for the RSA and OpenPGP algorithms, both of which are public key crypto systems. Public key cryptography is based on pairs of keys, one of which is made public and the other kept private:
- to send someone an encrypted message, you fetch their public key and encrypt the message with it. They decrypt the message with *their* corresponding private key.
- to sign a document, you use your own private key: the recipient can verify the signature using *your* corresponding public key.
The security of both functions (encryption and signing) relies on one important principle: that you cannot guess a private key from its corresponding public key. The flawed key generation routine fails this principle: researchers discovered a way to find private keys from some public keys, and a way to tell, very quickly, if a given public key is a vulnerable one or not. This means attackers don’t have to try and crack *every* key: they can save their effort for weak keys, and ignore the others.
What does the flaw affect?
The flaw’s main effect is on security chips used in laptops and authentication tokens (smart cards and USB tokens).
In laptops, the Infineon key generation routine is used by Trusted Platform Modules (TPMs) for functions like full disk encryption. Ten manufacturers’ PCs tested were found to be vulnerable. Microsoft, Google, Lenovo, HP and Fujitsu are all reported to have issued patches to devices of theirs that use the flawed routine.
In smart cards, such as the Estonian eID card, the routine generates keys used for both authentication and document signing. 750,000 cards are believed to be affected, and the Estonian government is working on a replacement process.
In Yubikey USB tokens, the flawed routine can be used to generate RSA and OpenPGP keys – though key generation on the tokens is only one of the functions they can perform. The others (such as two factor authentication) are unaffected. PIV-related key generation on a Yubikey may affect some US federal users.
Weak keys have been found in a number of other instances: some used to sign Github submissions, and others used to establish TLS sessions. Those keys are assumed to have been generated using the flawed routine.
What’s the fix?
In the short term, the fix will partly depend on which kind of deployment is at risk. For “embedded crypto” devices such as USB tokens and smart cards, the most practical fix may be replacement of the device. More complex and capable platforms, such as PCs, can probably be securely updated remotely.
In the longer term, there’s a fundamental design question to be addressed: when developing a product, which of the two categories above is the product intended to fall into? If a fundamental flaw is discovered, is it to be managed by remote update or device replacement?
If a device is designed to have no remote management interface, or no user interface to device update functions, then device replacement is probably the only option. Remote management – if it is to be an option – has to be designed in from the outset.
The Internet of Things (IoT) dramatically increases the number of constrained devices attached to the Internet, but if those devices aren’t secure, it also dramatically increases the potential for them to be abused (used to eavesdrop on users, recruited into botnets, exploited to intercept Wi-Fi passwords, hacked to give control over vehicles, etc.).
In some cases (such as smart light bulbs) device replacement is probably the sensible design goal. However, in other cases (such as a device embedded in a vehicle) it may be unrealistic. We can and should learn from existing large-scale deployments of PKI technology, such as cable modems, set-top boxes and smart meters. In those instances, manufacturers have taken one of two approaches:
- Design for device replacement. If your cable modem breaks (including security failures), the ISP will probably just send out a replacement box.
- Design for replacement of security elements. Your set-top box or smart meter may well get its keys/credentials off an inserted smart card; if new keys/credentials are needed, it’s cheaper to send out a replacement smart card than to replace the whole box. This approach can also be used to deliver a new/different algorithm to the affected device.
What’s the bigger picture?
Best practice for responsible vulnerability disclosure appears to have been followed in this case. Laptop vendors were warned of the bug, and so have had time to produce and distribute patches that mitigate the risk… but whether users have applied them is another matter.
In other instances, where remote patching isn’t a practical option (smart cards, USB tokens), the issuers of those devices will probably have to issue replacements. Where that is also a national e-ID issue (as in Estonia), governments need to pay particular attention to the long-term implications for G2C authentication, particularly for e-voting, and the use of digitally signed documents as part of the national trust infrastructure.
In terms of device design: for platforms where it is realistic to offer multiple encryption algorithms, manufacturers should seriously consider doing so, in the interest of “algorithm agility”. (For instance, anyone whose RSA keys are affected by this flaw, but who can switch to Elliptic Curve encryption, can mitigate the risk by doing so). But manufacturers will need to think extremely carefully about the user experience for any such switch.
Where “algorithm agility” on the device is not a practical option (for instance, in some smart objects), manufacturers need to cater for the whole lifecycle of the device, including the possibility of device replacement and decommissioning.
What should I do?
For most individuals, the immediate action is to check that your laptop is fully up to date with manufacturer’s patches. If you use full-disk encryption on a laptop with an Infineon TPM, your manufacturer may have already issued a patch, having been alerted to the problem several months ago.
Assess your keys now with the researchers’ offline and online detection tools and contact your vendor if you are affected.