Opinion : Flame ravive la question des certificats
À sa manière Stuxnet avait déjà posé la question : est-il bien raisonnable de laisser reposer l’ensemble de la chaîne de confiance sur les certificats ? Le hack du registrar néerlandais DigiNotar l’avait une nouvelle fois posée de manière criante. Et Flame remet ça. Combien de temps et d’attaques faudra-t-il encore avant qu’une alternative ne soit adoptée ?
Les certificats sont une composante essentielle de la sécurisation des transactions en ligne, et de bien plus encore. Jusqu’ici, on pouvait considérer qu’ils remplissaient plutôt bien leur rôle. Mais Stuxnet a utilisé deux certificats volés à Realtek et à JMicron, deux constructeurs de matériel informatique, pour s’installer en toute discrétion : le système d’exploitation des machines visées faisait confiance à ces certificats pour attester de la légitimité du logiciel à installer. Même chose aujourd’hui pour Flame. Mike Reavey, directeur de l’activité Trustworthy Computing de Microsoft l’explique
dans un billet de blog : certains éléments de code de Flame sont signés par des certificats «qui permettent au logiciel d’apparaître comme étant produit par Microsoft». L’éditeur vient de publier un correctif. Mais il y a eu plus grave : le piratage de DigiNotar à l’été 2011. Cette autorité de certification, filiale du Suisse Vasco, a été
victime d’une intrusion. Celle-ci a permis l’émission frauduleuse de certificats illégitimes pour plusieurs domaines, dont Google.com. De quoi permettre des attaques par interposition sur des internautes tentant par exemple de se connecter à leur compte Gmail. À l’époque, Roel Shuwenberg, de Kaspersky,
s’était interrogé, sur son blog : «avec quelque 500 autorités de certification dans le monde, on imagine mal que seul DigiNotar soit compromis.» Une interrogation d’autant plus légitime que le néerlandais n’était pas le premier à être victime d’une telle intrusion : quelques mois plus tôt, Comodo s’était fait
voler neuf certificats SSL destinés à Hotmail, Gmail, Skype et Yahoo Mail. Deux incidents qui soulèvent la lourde question de la responsabilité des autorités de certification et de leur capacité à l’assumer.
Mais certains n’avaient pas manqué de soulever qu’au-delà de l’incident DigiNotar, c’était surtout sur le fait de faire reposer tout l’édifice de la sécurité en ligne sur ces certificats qu’il fallait s’interroger. Certes, les éditeurs de navigateurs Web, de systèmes d’exploitation, avaient (plus ou moins) rapidement réagi à la révocation des certificats compromis. Mais encore faut-il que le parc installé ait été mis à jour, pour que le risque disparaisse. Et les smartphones et les tablettes n’ont pas été mis à jour avec la même rapidité. Ne serait-ce que parce que leurs constructeurs doivent aussi composer avec les intérêts des opérateurs télécoms, et s’assurer que la révocation des certificats compromis n’aura pas de conséquences désastreuses sur, par exemple, l’accessibilité aux systèmes de self-care. Mais alors, que dire et que penser des entreprises ou des organismes publics qui oublient de renouveler les certificats ou qui utilisent des certificats sans signature valide ? En début d’année, l’accès à certaines rubriques du service client en ligne d’Orange était
bloqué par les navigateurs Web en raison d’un certificat expiré. L’information a semble-t-il été remontée depuis un forum d’utilisateurs; le certificat fautif a été renouvelé trois jour après son expiration... Mais le service de pré-remplissage en ligne du formulaire de demande de carte grise de l’Etat n’est pas dans une situation plus honorable (voir capture ci-contre). Autant pour l’établissement de la confiance et tant pis pour la vigilance des internautes... Voilà qui montre que le système de sécurité basé sur les certificats est aussi menacé par les comportements de ceux qui y ont recours. Un troisième point qui appelle à minima à un changement des processus entourant la gestion des certificats.
