Tookan

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)

Tookan demo from secgroup on Vimeo.

Analysis results

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
Company Model sym asym cobj chan w ws a1 a2 a3 a4 a5 mc
USB
 Aladdin eToken PRO X X X X X X X X a1
Athena ASEKey X X X
Bull Trustway RCI X X X X X X X X a1
Eutron Crypto Id. ITSEC X X
Feitian StorePass2000 X X X X X X X X X a3
Feitian ePass2000 X X X X X X X X X a3
Feitian ePass3003Auto X X X X X X X X X a3
Gemalto Smart Enterprise Guardian X X
MXI Security Stealth MXP Bio X X X
RSA SecurID 800 X X X X X X X a3
SafeNet iKey 2032 X X X X
Sata DKey X X X X X X X X X X X a3
Card
 ACS ACOS5 X X X X
Athena ASE Smartcard X X X
Gemalto Cyberflex V2 X X X X X X a2
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
Soft
 Eracom HSM simulator X X X X X X X X a1
IBM opencryptoki 2.3.1 X X X X X X X X X a1

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.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.)Below, we give more details on the supported functionalities:

  • 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:

Acronym Description
Supported functionality
 sym symmetric-key cryptography
asym asymmetric-key cryptography
cobj inserting new keys via C_CreateObject
chan changing key attributes
w wrapping keys
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

Model files

the models of the above token, as extracted by Tookan, are available here. Models are written in the Tookan model metalanguage syntax.

Publications

  1. 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.

Contacts

Tookan is a joint project of INRIA and University Ca’ Foscari, Venice and is developed by the following people. Contact us if you want more information or feel free to post a comment in our Blog.

Attacking and Fixing PKCS#11 Security Tokens
Matteo Bortolozzo, Matteo Centenaro, Riccardo Focardi , Graham Steel

at the 17th ACM Conference on Computer and Communications Security (ACM CCS 2010)

One thought on “Tookan”

  1. Pingback: Secgroup Ca' Foscari DSI » Tookan: Attacking and Fixing PKCS#11 Security Tokens

Comments are closed.