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'informations relative au 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 tous les tokens en circulation. Si c'est effectivement le cas, et c'est une hypothèse qui commence à prendre de l'ampleur, et que la fuite impacte effectivement de telles données, RSA sera 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... D'un autre côté, dans un tel contexte, accepter de laisser sa sécurité reposer sur un modèle où ses clés privées sont stockées chez une tierce-partie n'est peut-être pas la meilleure idée du monde...

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. Chaque token arrive avec donc sa la clé sécrète claquée en dur. Et dans la mesure où j'ai déployé des maquettes qui pour autant que je m'en souvienne étaient offlines[4] cela voudrait dire qu'il existe un moyen de la dériver de son numéro de série...

Update (22/03/2011) : Après avoir éplucher des pages et des pages de documentation sur la maintenance des serveurs ACE, j'ai finalement trouvé la réponse que je cherchais ailleurs, sur Oxid[5]. Dans la description du calculateur SecurID de Cain qui, comme son nom l'indique, vous calcule la sortie d'un token SecurID donné, il est écrit noir sur blanc (ouf) que l'enrôlement suppose la fourniture du numéro de série et d'un clé d'activation, comme indiqué par sam280 en commentaire (merci ;)). Les deux étant fournies sous forme de fichier XML. Mon hypothèse de l'algorithme permettant de tout récupérer à partir du numéro de série est donc fausse, et on en revient à l'hypothèse de la base de clés.
Garderait-on précieusement ces fichiers XML chez RSA ? Si c'est le cas, je trouve pour le moins dérangeant de savoir que les informations nécessaires à la génération des OTP utilisés par les utilisateurs du systèmes traînent quelque part ailleurs que sur le serveur d'authentification auxquels ils sont associés. En l'occurrence, la perte de ces informations réduit la sécurité d'un token à la connaissance de son PIN qui, pour le coup, est heureusement choisi par l'utilisateur...

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, ou pire avec une base de données associant clés et numéros de série, alors ils auront fait une belle partie du chemin. Et comme en outre ils connaissent très probablement 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[6]. 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 les hypothèses émises ci-dessus font complètement sens[7], voire même si elle sont valides. En tout cas, si les système de type SecurID sont séduisants, le fait que leur sécurité repose sur des algorithmes secrets m'a toujours dérangé. Mais sûrement moins que le fait que mes clés privées traînent ailleurs que chez moi. Justement parce que dans les deux cas, ça prête franchement le flanc à 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] Donc sans possibilité d'aller récupérer des données en ligne

[5] Elle est également dans le code que je pointais sur Bugtraq.

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

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