Secgroup Ca' Foscari DSI > Blog > Vulnerabilites > Attacking and Fixing PKCS#11 Security Tokens

Attacking and Fixing PKCS#11 Security Tokens

Tookan is an automated tool for security analysis of PKCS#11 compliant authentication tokens. In a paper presented today at CCS’10, we show how we used Tookan to reveal secret keys in devices made by Aladdin, Bull, Gemalto, RSA, snd Siemens amongst others. Tookan can also be used to validate patches to the standard, as we demonstrate in our CryptokiX project. Slides from the conference presentation are available, or you can go to the Tookan project website for full details.

This is the result of joint work between Graham Steel (LSV & INRIA) and the Security Group of the Universita’ Ca’ Foscari.

 

Comments: 4

Leave a reply »

 

RSA also registered the advisory at buqtraq. They are one of the few (two for the moment) that answered to our reports. You can see here the full answer from RSA.

Did you get a response from RSA about the PKCS#11 standard itself with regard to attack a1 and a2 ?

I’ve read the standard again carefully, and am of the opinion that the redactors simply considered it out of scope to try to protect an extractable, sensitive key against attacks by the token owner to actively try to recover the clear text of the key. However they never explicitly state this in the document, whilst there should be a warning that if a key is marked as CKA_EXTRACTABLE, then it *will* be possible to find a way of accessing it’s clear text value outside the token.

I think now this could only be solved with a new attribute, CKA_SECURE_EXTRACTABLE, which would also wrapping only by a key :
- that was generated inside the token
- that has CKA_DECRYPT set to false
- whose level of protection with regard to known attacks is stronger, or at least as strong, as the key extracted
But I’m not really 100% sure this definitively leaves no channel available to break the encryption.

Most pkcs#11 HSM provide administrative tools (working outside of the pkcs#11 interface) to save and restore keys, allowing to do that without marking the key as extractable, so keeping them secure.

I believe your attacks a1 and a2 are not really attacks. They are the intended, permitted meaning and purpose of marking a secret as extractable with appropriate authentication and a wrapping key chosen at the time of extraction. Typically, this will be the import key of a new token that didn’t (physically) exist at the time when the extractable key was stored on the original token.

It is also worth noting that PKCS#11 libraries rarely expose the full capabilities of the cards, thus there may be command sequences at the actual hardware security boundary which can do things that may or may not violate the apparent security at the API level. For instance, some cards don’t have a key wrap for export feature at all, making “extractable” keys actually readable except for a soft policy that the official PKCS#11 library will wrap the unencrypted key before returning it to the application.

The lesson is that the authentication pins for key extraction should be different from the day to day key usage pins, and should be protected as well as the keys themselves, perhaps by storing them as sensitive keys in another token.

In attacks a1 and a2 the key is wrapped and then decrypted as if it were encrypted data. This leaks the key value in the clear which is certainly not the intended behaviour of a security token. In fact, to share a key with a new token you can generate a key pair on the new token and wrap the sensitive key from the old token under the public key of the new one. Now you can safely unwrap the wrapped key inside the new token without exposing it in the clear. The PKCS#11 standard states precisely that sensitive keys should not be revealed in plaintext off the token. Notice that in a1 and a2 you *wrap* and then *decrypt*. When exporting and importing keys you should instead call *wrap* and then *unwrap*.

It is true that you could think of a different authentication (e.g. a different PIN) that allows for key management. Then, key management is only done in a safe, isolated environment where you could in principle make keys go around in the clear. This separate key management is done with some HSMs. However if you do not disable key wrapping when using the production PIN, attacks a1 and a2 will potentially leak any sensitive keys.

Does this make better sense to you now?

Leave a Reply

 
(will not be published)
 
 
Comment