Tookan (TOOl for cryptoKi ANalysis) is an automated tool which reverse-engineers a real PKCS#11 token to deduce its functionality, constructs a model of its API for the SATMC model checker, and then executes any attack trace found by the model checker directly on the token.
PKCS#11 specifies an API for performing cryptographic operations such as encryption and signature using cryptographic tokens. Sensitive cryptographic keys are stored inside the token and any cryptographic operation is performed by the token without revealing the key to the outside, insecure, world. In fact, compromising a key allows an attacker to clone the token and, more generally, to perform the same security-critical operations as the legitimate token user.
Tookan is able to extract sensitive cryptographic keys from a variety of commercially available tamper resistant cryptographic security tokens, exploiting vulnerabilities in their RSA PKCS#11 based APIs.
Curious to see Tookan at work? Watch our demo! (high-resolution AVI file)
We report here our ongoing results on real devices. All the vulnerabilities has been reported to manufacturers at least 5 months before publication. The following table summarizes the results.
IMPORTANT NOTE: Responses from manufacturers, when given, are linked from the device model.
|Device||Supported Functionality||Attacks found|
|Eutron||Crypto Id. ITSEC||X||X|
|Gemalto||Smart Enterprise Guardian||X||X|
|MXI Security||Stealth MXP Bio||X||X||X|
|Gemalto||SafeSite Classic TPC IS V1||X||X|
|Gemalto||SafeSite Classic TPC IS V2||X||X||X||X||X||X||X||X||X||X||a3|
|Siemens||CardOS V4.3 B||X||X||X||X||X||a4|
Below, we give more details on the supported functionalities:
- Columns ‘sym’ and ‘asym’ respectively indicate whether or not symmetric and asymmetric key cryptography are supported. (Gemalto SafeSite Classic TPC IS V1 should implement both symmetric and asymmetric cryptography according to its specification, but the one we tested could not generate and use symmetric keys. This may be a hardware issue with the specific token we possess.)
- Column ‘cobj’ refers to the possibility of inserting external, unencrypted, keys on the device via C_CreateObject PKCS#11 function. This is allowed by almost all of the analysed tokens. Although this command does not directly violate a security property, allowing known keys onto a device is generally a dangerous thing: an attacker might import an untrusted wrapping key from outside and ask the device to wrap a sensitive internal key with it.
- The next column, ‘chan’, refers to the possibility of changing key attributes through C_SetAttributeValue. This functionality can easily be abused if not limited in some way. For example, it is clear (and stated in the standard) that it should never be possible to make a sensitive key nonsensitive.
- The following two columns, ‘w’ and ‘ws’, respectively indicate whether the token permits wrapping of nonsensitive and sensitive keys. It is discouraging to observe that every device providing ‘ws’, i.e., the wrapping of sensitive keys, is also vulnerable to attack. All the other devices avoid attacks at the price of removing such functionality.
The reported attacks are as follows:
- Attack a1 is a wrap/decrypt attack. The attacker exploits a key k2 with attributes wrap and decrypt and uses it to attack a sensitive key k1 . More precisely (& is used to note an handle to a key):
Wrap(&k1,&k2) → senc(k1,k2) SDecrypt(senc(k1,k2), &k2) → k1
As we have discussed above, the possibility of inserting new keys in the token (column ‘cobj’) might simplify further the attack. It is sufficient to add a known wrapping key k2 and use it to wrap the sensitive key k1. The attacker can then decrypt the wrapped k1, since he knows the wrapping key k2 . SATMC discovered this variant of the attack on vulnerable tokens. We note that despite its apparent simplicity, this attack has not appeared before in the PKCS#11 security literature.
- Attack a2 is a variant of the previous ones in which the wrapping key is a public key and the decryption key is the corresponding private key;
- Attack a3 is a clear flaw in the PKCS#11 implementation. It is explicitly required that the value of sensitive keys should never be communicated outside the token. In practice, when the token is asked for the value of a sensitive key, it should return some “value is sensitive” error code. Instead, we found that some of the analysed devices just return the plain key value, ignoring this basic policy;
- Attack a4 is similar to a3: PKCS#11 requires that keys declared to be unextractable should not be readable, even if they are nonsensitive. If they are in fact readable, this is another violation of PKCS#11 security policy;
- Attack a5 refers to the possibility of changing sensitive and unextractable keys respectively into nonsensitive and extractable ones.
All the acronyms are summarized below:
|cobj||inserting new keys via C_CreateObject|
|chan||changing key attributes|
|ws||wrapping sensitive keys|
|Attacks||a1||wrap/decrypt attack based on symmetric keys|
|a2||wrap/decrypt attack based on asymmetric keys|
|a3||sensitive keys are directly readable|
|a4||unextractable keys are directly readable (forbidden by the standard)|
|a5||sensitive/unextractable keys can be changed into nonsensitive/extractable|
|mc||first attack found by Tookan|
- Matteo Bortolozzo, Matteo Centenaro, Riccardo Focardi and Graham Steel.
Attacking and Fixing PKCS#11 Security Tokens.
Proceedings of the 17th ACM Conference on Computer and Communications Security (ACM CCS 2010), October 2010.
[pdf] [conference site]
We describe the operation of Tookan and give results of testing the tool on 17 commercially available tokens: 9 were vulnerable to attack, while the other 8 had severely restricted functionality.One of the attacks found by the model checker has not previously appeared in the literature. We show how Tookan may be used to verify patches to insecure devices, and give a secure configuration that we have implemented in a patch to our software token simulator CryptokiX. This is the first such configuration to appear in the literature that does not require any new cryptographic mechanisms to be added to the standard.
- Matteo Bortolozzo (Univ. Venice)
- Matteo Centenaro (Univ. Venice)
- Riccardo Focardi (Univ. Venice), coordinator
- Graham Steel (LSV & INRIA), coordinator