Failure In Practical Security...

M

ême si les faits datent d'il y a deux mois et s'ils ont déjà généré leur lot de buzzz et de polémique, cette histoire de clés USB chiffrées cassées me titille à plus d'un titre. D'abord parce que la faille en question, initialement publiée par deux chercheurs allemands de SySS, touche un produit utilisant du chiffrement AES implémenté matériellement sur un composant dédié. Ensuite parce que si on va retrouver cette même faille sur d'autres produits de la même marque, elle va également toucher deux autres constructeurs...

Enfin et surtout, parce que tous ces produits ont reçu leur certification FIPS 140-2 niveau 2. Et que considérant le caractère presque trivial, voire amusant, de la vulnérabilité, il y a vraiment de quoi se poser des questions sur la valeur d'une telle certification...

La lecture de l'article décrivant la faille est assez impressionnant. Pas de technicité, mais plutôt parce qu'on se demande ce sur quoi la certification a bien pu porter pour passer à côté d'un trou béant de ce genre. Il y est en effet démontré que la bonne vérification du mot de passe fourni l'utilisateur ne dépend au final que du logiciel client. Ça semble assez violent conceptuellement, mais c'est bien le cas. Et c'est passé à travers la certification...

Si on s'intéresse aux Security Policies qui s'appliquent à la certification de ces produits, on notera que leur design est exactement le même et qu'il reposent tous sur une un architecture apparemment identique articulée autour d'un même composant cryptographique, un micro-contrôleur appelé S2. Du coup, ça semble déjà un peu moins surprenant que les trois produits soient touchés par le même problème. Et ça le devient encore moins quand on s'aperçoit que le logiciel client porte le même nom, ExmpSrv.exe. Il y a donc de fortes chances qu'on ait affaire à la même techno^[1]...

On s'aperçoit également que la certification ne concerne que l'implémentation matérielle de ces clés. Et il se trouve que c'est exactement l'argument avancé par le NIST sur le sujet. Du beau "Ah ben non mon bon môssieur, c'est hors périmètre votre truc". Comme pour tous les autres accidents du même genre dont on a pu avoir vent par le passé d'ailleurs... Parce que dans ces certifications, vous verrez que les critères environnementaux de la certification ne sont pas considérés parce que, je cite^[2], "le module a un environnement opérationnel limité". Period. CR-LF. Next paragraph...

Ce qui pose la question non pas de la validité technique de ces certifications, mais de leur pertinence quant à la satisfaction du besoin auquel prétendent répondre ces produits. Car, mais corrigez-moi si je me trompe, le besoin en question n'est pas de posséder un stockage de masse sécurisé par un micro-contrôleur crypto, mais bel et bien de pouvoir lire et/ou écrire de données sur un stockage de masse sécurisé depuis un ordinateur. Ce qui veut dire que le canal de communication entre le-dit ordinateur et le stockage de masse sécurisé fait totalement partie de la solution et qu'on s'attend à ce qu'il fasse partie du périmètre de certification. Or ce n'est pas le cas. Et évidemment, c'est précisément là que le bactéries attaquent...

Alors on en vient à se poser la question : à quoi ça sert une certification qui ne répond pas à la question posée ? Ou plutôt, à quoi ça sert de certifier des produits sur des cibles de sécurité qui ne couvrent pas l'usage qu'on en fait ? La réponse, simple, est contenue dans le question elle-même : à rien. Car de mon point de vue, une certification devrait servir à fournir à un public relativement large et donc pas forcément averti^[3] un indicateur de la qualité d'une solution au regard de certains critères. Ici la sécurité fournie par la solution considérée.

Comme j'ai pu l'indiquer auparavant, je me range à l'idée que le marché de la sécurité informatique est un marché fortement asymétriquement, concept décrit par George Akerlof dans son désormais célèbre "The Market for Lemons: Quality Uncertainty and the Market Mechanism". L'idée principale est que si la qualité des produits proposés ne peut être évaluée correctement par les acheteurs, alors le marché considéré se verra tiré vers le bas par les vendeurs négligeants, les acheteurs adoptant une stratégie d'achat des produits les moins chers parce qu'habitués à obtenir des produits de mauvaise qualité, jusqu'à un point qui pourrait tout simplement tuer le marché. Ross Anderson a publié nombres d'articles passionnants sur l'application de cette idée à la sécurité, parmi lesquels on retiendra en particulier son essai sur la difficulté d'obtenir de la sécurité.

C'est particulièrement le cas à mon avis pour le marché particulier des produits de sécurité. Si l'asymétrie informationnelle y est déjà forte par la nature même des technologies manipulées^[4], elle se trouve en outre renforcée par des pratiques courantes telles que l'obfuscation ou des cadres législatifs contraignants, comme l'interdiction de la rétro-ingénierie à des fins de sécurité ou de l'étude de moyens de protection^[5] et la menace de poursuites pour des motifs plus fumeux les uns que les autres, mais néanmoins impactantes.

Dans un tel monde, on comprend parfaitement le rôle crucial que les certifications ont à jouer : celui de fournir à l'acheteur de vrais critères de sélection. Seulement pour que cela marche, il faut certes que les certifications soient techniquement pertinentes, mais il faut surtout qu'elles répondent aux préoccupation de l'utilisateur. Or, dans le cas qui nous intéresse, comme dans pas mal d'autres d'ailleurs, elles passent à côté. Car en tant qu'utilisateur, je n'ai que faire de savoir que mon système d'exploitation est certifié EAL4 s'il ne doit pas être mis en réseau pour m'offrir ce niveau de sécurité, pas plus que de savoir que la puce crypto d'une clé USB est FIPS 140-2 si ce niveau ne prend pas en compte la partie logicielle qui en déverrouille le contenu.

D'aucuns arguent même que les certifications demandent un niveau de compétences certain pour être comprises comme elle le doivent. Comprendre pour faire la différence entre une bonne et une mauvaise certification... Marché, citrons, casseroles, tout ça...

Je finirai sur une note d'humour relevé par mes confrères mais néanmoins amis de CNIS Mag qui remarquent qu'un certain article de SecurityFocus cité plus haut se retrouve encore flanqué d'un énorme bandeau de pub pour... IronKey... Ça ne s'invente pas...

Notes

[1] Découvrir laquelle est laissée en exercice aux investigateurs en herbe, ou aux lecteurs de DC ;)

[2] En traduisant librement.

[3] soit par manque de compétence, soit par manque de temps et/ou de moyen.

[4] Comprendre par là que la plupart des gens n'ont pas les compétences, les moyens et/ou le temps de s'investir pour juger factuellement de la qualité d'un produit.

[5] Cf. DMCA par exemple.