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 par 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 raquette...

En fait, pour répondre à cette question, il faut s'intéresser aux Security Policies qui s'appliquent à la certification de ces produits. On notera alors que leur design est exactement le même et qu'il repose dans chaque cas sur une un architecture 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]...

Mais on s'apercevra également que le périmètre de certification ne concerne que l'implémentation matérielle de ces clés, pas la partie logicielle. 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 Policies, vous constaterez 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 non pas la question de la validité technique de ces certifications, mais plutôt celle 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 ne s'arrête pas à posséder un stockage de masse sécurisé par un micro-contrôleur crypto. Il s'agit aussi de pouvoir lire et/ou écrire des données sur le périphérique en question 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 donc à 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 forcément à se poser la question suivante : à quoi ça sert une certification qui ne répond pas à la question posée ? Ou exactement : à 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 de ce papier est que si la qualité des produits vendus ne peut être évaluée correctement par les acheteurs, alors le marché considéré se verra tiré vers le bas du fait des vendeurs négligeants, les acheteurs adoptant une stratégie d'achat des produits les moins chers parce qu'habitués à obtenir des produits de piètre qualité. Ce qui peut aller 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é informatique, parmi lesquels on retiendra en particulier son fameux "Why Information Security is Hard".

Je rejoins complètement son analyse, et particulièrement en ce qui concerne le marché 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, des contrats de licence qui vous interdisent explicitement l'étude du produit 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 certes plus fumeux les uns que les autres, mais qui n'en restent pas moins impactantes pour les personnes concernées.

Dans un tel monde, on envisage 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éoccupations de l'utilisateur. Or, dans le cas qui nous intéresse, comme dans pas mal d'autres d'ailleurs, elles passent à côté de la plaque. 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. Surtout quand cette dernière est vulnérable à une faille qui expose mes données supposées protégées au premier quidam sachant se servir d'un debugger...

En fait, c'est à un point que d'aucuns parviennent même à argumenter fort sérieusement 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 quand même sur une note d'humour relevée 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, à la prose duquel qui j'ai emprunté quelques liens ;)

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