Compromission de RSA : Kerckhoffs #FAIL ?

N

ous avons appris cette semaine que l'APT avait encore frappé. Et pas n'importe qui, puisque c'est sournoisement qu'on s'en est pris à RSA. Et son patron de se fendre d'une lettre ouverte à destination de ses clients et des ses actionnaires. Communiqué dont le contenu va être largement commenté.

Car que dit ce communiqué ? Que cette compromission a permis aux attaquants de mettre la main sur des informations relatives au système SecurID qui, sans pour autant permettre une attaque directe, seraient susceptibles de, et on admirera la tournure ampoulée traduite ici par mes soins, "réduire l'efficacité de l'implémentation d'une authentification bi-facteur dans le cadre d'une attaque de plus grande ampleur".

Si tout le monde y va de son commentaire, de son analyse ou de ses conseils avisés, je n'ai jusqu'alors vu personne s'émouvoir du fait que la compromission du système d'information d'un éditeur de solutions cryptographiques puissent mettre à mal la sécurité de ses clients... Je m'explique...

On m'a toujours expliqué que la cryptographie, pour être efficace, devait satisfaire le principe de fameux Principe de Kerckhoffs, énoncé en 1883 par le cryptologue néerlandais qui lui a donné son nom. Ce principe veut que la sécurité d'un système cryptographique ne doit reposer que sur le secret de la clé, et, de fait, pas sur le secret de son implémentation. Surtout pas pourrait-on ajouter, puisque les exemples illustrant la pertinence de cet enseignement sont légion. Ce qui en fait en quelque sorte un des principes de base de la cryptographie moderne.

Je ne suis pas un expert du produit RSA SecurID, aussi j'invite ceux qui en savent plus long que moi à corriger mes approximations, raccourcis et autres erreurs factuelles éventuelles. Voici toujours ce que j'en ai compris et retenu. Grosso modo, le système repose sur deux horloges synchronisées. La première, de référence, se situant au niveau du serveur d'authentification. La seconde se trouvant dans le token, c'est à dire le dispositif matériel qui affiche à l'utilisateur ses codes d'authentification. Ces codes sont dérivés de l'heure, au moyen d'un système cryptographique propriétaire mettant en œuvre une clé sécrète partagée entre le serveur et le token. De fait, ils changent régulièrement au fil du temps^[1], fournissant une solution de One Time Password. À la saisie, le code est complété d'un PIN constituant le deuxième facteur d'authentification^[2].

Jusque là, tout va bien. Sans la connaissance du code PIN et de la clé secrète, il devrait donc être impossible à un attaquant d'impersonnifier un utilisateur, quand bien même il connaîtrait la fameuse fonction cryptographique qui sert à changer l'heure en code d'authentification. Aussi, il paraît pour le moins étonnant de constater que la capture d'information sur la conception du système SecurID puisse mettre à mal la sécurité du système...

Si personne ne la soulève explicitement, on sent tout de même la question poindre à demi-mot. Et certains commencent à avancer des explications. Ainsi, Jérôme Saiz nous fait part sur SecurityVibes d'une indiscrétion : selon une source, RSA hébergerait les fameuses clés sécrètes pour le compte de ses clients. Ayant joué avec le système dans une autre vie, j'aurais tendance à penser qu'il s'agirait là d'un service optionnel, dont j'ai du mal à saisir l'utilité. En effet, SecurID a vocation à être mis en œuvre complètement offline, et rien de tel n'apparaît dans les documentations que j'ai pu voir. Toujours est-il que si c'était effectivement le cas, et que la fuite impacte effectivement de telles données, RSA serait clairement à clouer au pilori. Car ne pas se montrer capable de protéger correctement les clés secrètes de leurs clients, en les chiffrant typiquement, ce serait carrément la honte...

Personnellement, c'est une autre explication qui me vient à l'esprit, aiguillé par quelques pistes évoquées çà et là. Pour autant que je me souvienne, on n'interagit pas avec un token RSA^[3]. On n'en change même pas la pile. Il arrive allumé, vous affiche un nouveau code toutes les minutes, et c'est tout. Du coup, quand on enrôle un token, il n'y a pas de génération de clé entre le serveur et le token, puisqu'il n'y a pas de moyen d'initier une telle séquence sur le token. On entre simplement le numéro de série du token dans le serveur, on choisit un PIN, et c'est parti. Ce qui veut dire qu'en pratique, chaque token arrive avec sa la clé sécrète claquée en dur. Et qu'il existe un moyen de la dériver de son numéro de série^[4]...

Et c'est peut-être là qu'est le soucis. Car si les attaquants sont repartis avec le mécanisme qui permet de dériver la clé sécrète du numéro de série, alors ils auront fait une belle partie du chemin. Si en outre ils connaissent la fonction qui dérive le code de l'heure, cela voudra dire qu'ils sont capables de reconstituer les codes fournis par un token donné juste en connaissant son numéro de série. Ce qui reste bien plus pratique et fournira un accès bien plus pérenne que le vol de l'équipement^[5]. Reste cependant le problème du PIN, ce qui peut expliquer qu'on s'en tienne à arguer que la fuite ne fait qu'affaiblir le système, sans le compromettre pour autant.

Je ne sais pas si l'hypothèse émise ci-dessus fait complètement sens^[6], voire même si elle est valide. En tout cas, si les système de type SecurID sont séduisant, le fait que leur sécurité repose sur des algorithmes secrets m'a toujours dérangé. Justement parce que ça prête le flan à des problèmes comme celui-ci. Lesquels laissent les utilisateurs dans l'attente d'explications leur permettant d'évaluer leur exposition. Chose qui à l'heure actuelle, au regard des informations disponibles, reste impossible...

Notes

[1] Toutes les 60 secondes.

[2] Le token étant ce qu'on possède, le PIN ce qu'on sait.

[3] Certains sont équipés d'un clavier, mais le modèle de base est vierge de tout bouton.

[4] Et c'est ce qui rend inutile le stockage des clés secrètes, puisqu'on sait les recalculer...

[5] Ce qui conduira immanquablement à sa révocation.

[6] Je pourrais m'être trompé sur le fonctionnement du système.