SSTIC 2011 - Attacking and Fixing PKCS#11 Security Tokens with Tookan
Attacking and Fixing PKCS#11 Security Tokens with Tookan
La couleur est annoncée, méthodes formelles et Tokens PKCS#11 … (vous savez, les token rsa que vous pouvez voir pendouiller autour du cou des vendeurs de téléphone mobile par exemple…)
Le standard PKCS11 c’est 400 pages, avec quelques pages sur la sécurité… les mesures de protection sont les suivantes :
– il faut taper le pin pour interagir avec le token
– certaines clefs peuvent être marquées comme « non-extractible » (pour éviter leur récupération via les commandes appropriés)
– une fois qu’une clef est stockée et marquée comme sensible, elle ne peut plus être rendue non-sensible par la suite (et donc n’est plus extractible)
L’analyse formelle
se fait sur ces propriétés de sécurité, et sur les fonctions de chiffrement/déchiffrement qu’on peut demander au token etc… (n’hésitez pas à me reprendre si je dit des bétises :p ) et à partir de là, ils sont allés voir les fabriquant de tokens, et ils leur ont répondu qu’ils avaient des experts qui travaillaient là dessus… (lol)
Ils ont donc décidé de créer un outil pour attaquer les tokens PKCS#11 nommé tookan ! et démontrer l’efficacité de leur attaques théoriques (slides ici, des vidéos de démo et les détails sur la page du projet).
Pour l’analyse il faut 9min en utilisant l’analyse des clefs en mémoire non volatile, 
et bien moins en utilisant les clefs de session volatiles… il en résulte une analyse de la configuration du token, qui sert à alimenter le model checker qui après analyse indique s’il est possible d’attaquer le token ou non (dans la démo, c’est le cas ! et c’est madame qui a fait le logo de l’outil).
Les test ont été effectué sur un ensemble de token commerciaux… et sur certains token, on peut récupérer une clef censée être marqué sensible ! (cf: tableau de résultat)
Les réactions des constructeurs à leur responsible disclosure… RSA à renseigné un CVE, d’autres ont promis que leur prochaine version serait meilleure, et certains ont demandé qui d’autre est vulnérable… (ce qui à bien fait rire l’assemblée).
Pour éviter les erreurs dans la programmation des tokens PKCS#11, l’auteur et son équipe on mis à disposition une librairie pour aider les développeurs et éviter les erreurs… Bravo !
