Edit : Conclusion modifiée à propos de la pollution par des utilisateurs malintentionnés
Avec ce post on va rentrer un peu dans les coulisses de la sécurité informatique, le monde des R-SSI (Responsables de la Sécurité des Systèmes d’Information), de l’AN-SSI (Agence Nationale…) et d’une façon générale de la SSI tout court.
Et en particulier on va parler d’une vérité qui va à l’encontre de tout ce que l’on répète au grand public. Asseyez-vous si vous n’avez pas deviné ce que je m’apprête à écrire : la sécurité ça n’existe pas ! Et en particulier la sécurité absolue ça n’existe pas.
Un système exposé sur internet assez longtemps sera piraté. C’est une question de temps et seulement une question de temps. C’est sur que si votre ordinateur attire le regard « Sauronesque » de la NSA américaine ou de ses équivalents Chinois, Russes, Israéliens ou même Français (parce qu’on est pas mauvais du tout dans ce domaine figurez vous) ce temps a des chances d’être vraiment très court.
Ce que beaucoup de gens compétents, forts de cette information cruciale, font dans le domaine de la sécurité informatique est alors très logique. Sachant que les systèmes à protéger vont céder tôt ou tard ils faut :
- Mettre en place ce qu’il faut pour que les méchants fassent plus de bruit que prévu en entrant (c’est un peu comme mettre plein de bouteilles de verre vides en équilibre dans votre grenier : si un voleur passe par là il va réveiller tout le quartier et ptet même se blesser un peu au passage).
- Mettre en place ce qu’il faut pour les ralentir et laisser aux gentils le temps de se réveiller et de réagir.
- Et pour les meilleurs mettre en place ce qu’il faut pour récolter de l’information voire faire un peu de misères aux méchants si on arrive à les identifier.
Le corollaire de cette vérité dérangeante est qu’on ne peut pas prévoir tous les cas d’attaques contre la sécurité d’un système.
Il existe bien des méthodes de développement dites « formelles » prévues pour traiter tous les cas possibles mais ça donne des développements qui prennent un temps affreux et coûtent un « pognon de dingue ». On fait ça genre pour les centrales nucléaires, les missiles de croisière ou des commandes de vol d’avions de combat. On devrait le faire pour les pacemakers et autres équipements vitaux. On ne le fait jamais pour les applications qui gèrent vos comptes bancaires, ni pour le développements de vos sites web préférés (Facebook ou Gmail compris), et devinez ? on ne le fera pas non plus pour l’application #StopCovid
Par contre ce qu’on peut faire c’est mettre l’accent sur certains points pour sécuriser une application contre certains types d’ennuis précisément « choisis » à l’avance. Soit parce qu’avec l’habitude on sait d’avance d’où va venir la « gifle ». Soit parce qu’on a réfléchi (seul ou a plusieurs) et qu’on pense que c’est ça le plus probable.
Le résultat de ces cogitations est une liste de types d’attaques de méchants précisant qui ils sont, par où ils arrivent et ce qu’ils vont tenter. On appelle ça un modèle de menace. C’est tout de même un « pari » (qu’en général on essaye de rendre gagnant sauf à jouer contre son camp) sur les différentes formes que la menace peut prendre.
Par exemple pour une banque le modèle de menace inclura forcément le cas de l’employé tenté de piquer dans les coffres ou de détourner des sommes d’argent à son profit. Et il inclura d’autres types de menaces évidemment en allant du braquage brut et bête à la tentative de piratage très élaborée.
Il existe des méthodes comme « EBIOS » proposées par l’ANSSI qui permettent de déterminer un modèle de menace pertinent en fonction de plein de choses. C’est un métier à part entière de faire ça et ceux qui le pratiquent ont tout mon respect. Au passage il y a pas mal d’entreprises qui feraient bien d’y jeter un œil pour leur propre bien.
Et si on parlait du modèle de menace choisi pour #StopCovid ?
On apprend l’essentiel du « pari » effectué dans les spécifications du fameux « protocole ROBERT ». Elles sont publiques (ça aide bien) :
https://github.com/ROBERT-proximity-tracing/documents
Le modèle de menace est décrit dans les spécifications (c’est en anglais désolé pour les francophones) au chapitre 1.4 « Adversarial model ». En voici une traduction française rapide :
Nous supposons le modèle de menace suivant:
• Les utilisateurs peuvent être malveillants. Ils peuvent, par exemple, effectuer des attaques actives et passives, espionner, injecter de faux messages, altérer des messages, polluer les listes de contacts des utilisateurs et développer leurs propres applications.
• L’autorité qui gère le système, pour sa part, est «honnête mais curieuse». Plus précisément, elle ne se déploiera pas de moyens d’espionnage ou ne modifiera pas les protocoles et les messages. Cependant, elle pourra utiliser les informations collectées à des fins spécifiques telles que la ré-identification des utilisateurs ou la déduction de leurs graphes de contact. Nous supposons que le système central est sécurisé et régulièrement audité et contrôlé par des autorités externes de confiance et neutres (comme les autorités de protection des données et les agences nationales de cybersécurité).
«honnête mais curieuse» ça fait une autorité gouvernementale digne du monde des Bisounours et encore même pour les Bisounours ça serait sans doute «too much» en termes de gentillesse.
Soyons sympas : il faut aussi comprendre que les gens qui ont conçu ce protocole sont aussi payés par la dite autorité centrale (prise au sens large)… partir du principe que ceux qui te payent puissent être de dangereux sociopathes autoritaires et hyper compétents en piratage ça aurait fait tout de même mauvais genre…
Et si on complétait un peu le tableau ?
On s’occupera des Bisounours plus tard mais en terme de modèle de menace ça serait peut être bien de s’intéresser aux smartphones : on est d’accord qu’il n’y a pas qu’une seule application… et que parmi ces applications il y a des chances de trouver des apps Google, et bien sûr Whatsapp et Facebook…
Et si ces applications se mettaient à tenter d’accéder aux pseudonymes et aux historiques de contact de l’application #StopCovid ?
En cas de réussite on aurait un tiers disposant des identités réelles, des pseudonymes ET des contacts entre pseudonymes. Et à grande échelle parce que des smartphones avec #StopCovid et SANS #Facebook ou #WhatSapp on peut estimer raisonnablement que ça sera une frange très marginale de la population.
Pour répondre à ça il va falloir chiffrer les données stockées sur les mobiles par #StopCovid ET s’assurer que le déchiffrage ne nécessite pas juste de prendre la clé là où elle est. Ça veut dire en gros que les clés ne seront utilisables qu’avec mot de passe et que ce mot de passe devra être fourni à chaque démarrage de l’application #StopCovid (Ça rendrait le « biniou » nettement moins pratique).
Ça ne relève pas directement du protocole ROBERT lui même mais ça n’en est pas moins critique du point de vue de la sécurité.
Il faut aussi avoir un mot à propos de Bluetooth. Bluetooth c’est un moyen de communication sans fil à courte portée qui sert à connecter votre téléphone au casque sans fil, à l’enceinte audio portable pour mettre l’ambiance partout où l’on va, au bidule qui mesure votre fréquence cardiaque, à votre vélo d’appartement ou que sais-je de communiquant…
En termes de sécurité Bluetooth c’est un peu la honte… des failles sont découvertes tout le temps. Elles sont corrigées mais on en trouve de nouvelles et c’est à nouveau le risque maximum jusqu’à la diffusion d’un correctif.
Quand ton regarde les conseils prodigués par les spécialistes en sécurité (exemple parmi des tas : https://www.securiteinfo.com) le conseil est :
- N’utiliser le protocole Bluetooth que si nécessaire,
- ne pas le laisser activé sans raison.
- Ne pas laisser son équipement en mode visible.
- Rejeter toute sollicitation inattendue.
- Changer le mot de passe par défaut de connexion (en général « 0000 »)
Des types d’attaques sur Bluetooth il y en a des zillions : BlueBorne attack, Bluebugging, Bluesnarfing, Bluejacking, Bluetooth Tracking (tiens donc), Key Negotiation attack, Bluewave Zero-Click (décembre 2019 tout de même), et la dernièreen date qui a le joli nom de BlueFrag leak (CVE 2020-022 pour les experts)…
C’est assez clair : le bluetooth ouvert tout le temps est une des pires bêtises à faire en termes de sécurité…
Résultat : pour faire marcher #StopCovid il faudrait faire de l’open bar permanent avec Bluetooth et exposer la population à un risque de piratage de masse digne du Guiness Book des Records.
Au tour des Bisounours maintenant.
Notre autorité centrale «honnête mais curieuse» est en contact direct avec les applications… elle sait donc associer IP et pseudonymes au début mais aussi à chaque instant vu que les applications lui redemandent des informations régulièrement à propos de l’état d’exposition des pseudonymes qu’elles ont.
Or les bases des fournisseurs d’accès à internet que ça soit mobile ou fixe disposent des informations permettant de refaire le lien entre IP et identité réelle. Elles permettent aussi de faire de la géolocalisation macroscopique puisqu’on sait avec quelles bornes les téléphones « discutent ».
Et ça n’est pas dit qu’une autorité centrale «honnête mais curieuse» soit incapable de récupérer ces informations. En fait la justice et les forces de l’ordre peuvent déjà obtenir ces informations assez facilement dans le cadre de procédures judiciaires ou de lutte contre le terrorisme.
Il faut également se rappeler que notre autorité centrale «honnête mais curieuse» dispose déjà des fameuses boites noires de la loi renseignement… je dis ça je dis rien mais avec des boites noires à disposition ça ne devrait pas être trop compliqué de refaire le lien entre IP et identité réelle sans demander aux fournisseurs d’accès à internet.
Au final sauf si le niveau technique de l’autorité centrale «honnête mais curieuse» est honteusement bas ils doivent être capable de savoir qui est malade et qui a de fortes chances de l’être de façon nominative.
Ou alors il faut changer de métier et trouver une autre voie… élevage de chèvres, sculpture du bois, maître chien, y’a plein de métiers géniaux qui ne nécessitent pas ces compétences là.
Pour répondre à ce risque de croisement de données il faudrait un tiers de confiance fonctionnant comme un proxy anonymisant (ou plusieurs, par exemple un par fournisseur d’accès à internet) pour que l’autorité centrale ne puisse pas relier les IP et les pseudonymes… Et tout cas pas sans pirater les proxy ou corrompre leurs opérateurs. C’est possible aussi mais le risque de scandale d’état est majeur dans un cas pareil.
Et si notre autorité était un tout petit peu moins Bisounours ? Ou la prochaine autorité ? Ou celle d’encore après ?
Eh bien par exemple une fois l’application rendue obligatoire (ça fait partie des choses envisagées dans un 2eme temps) il suffirait de faire voler au dessus d’une manifestation, par exemple attaché à un drone, un téléphone avec dedans une application #StopCovid un peu modifiée qui ferait juste les petits « coucou c’est moi » nécessaires pour récupérer les pseudonymes des manifestants… pratique pour ficher les opposants politiques. Un peu moins drôle du point de vue de la démocratie et des libertés publiques.
Un dernier mot sur la centralisation (Il faut bien une partie un peu plus technique).
Dans le protocole ROBERT c’est l’autorité centrale qui reçoit les notifications d’infection et qui calcule le niveau de risque pour chaque pseudonyme.
On aurait pu imaginer un protocole bien plus décentralisant : l’autorité centrale pourrait se comporter uniquement comme un « passeur » de messages entre téléphones : les messages ainsi chiffrés d’application à application transiteraient par le point central sans que ce dernier puisse rien en faire (les clés ayant été échangées lors des connexions bluetooth directes).
Les usagers seraient informés de leur niveau de risque (ce qui est le but final affiché), l’autorité centrale n’aurait ni besoin d’attribuer des pseudonymes ni même de les connaître (les applications se débrouilleraient entre elles) ni besoin de calculer les risques d’exposition et du coup l’idée de croiser adresse IP et identité réelle avec… hé bien rien du tout deviendrait bien moins séduisante.
Une approche bien plus acceptable et bien plus robuste face à un modèle de menace élargi ce qui ferait au final quelque chose de plus protecteur de l’individu et de ses libertés fondamentales.
Reste qu’il faudrait trouver un mécanisme d’adressage des messages entre téléphones sans que l’autorité centrale ne puisse connaitre les pseudonymes.
Rajout au sujet de la pollution par des gens qui se déclareraient malades alors qu’ils ne le sont pas. L’application #StopCovid traite ce sujet en faisant scanner un QRCode par les malades. Ce QRCode embarque sans doute une signature numérique vérifiable par l’autorité centrale. Ce qui veut dire que les médecins « signent » une déclaration de maladie (Après un test formel en laboratoire ? Ou juste sur constatation des symptômes ?).
Cela veut dire que la remontée d’alerte aux personnes concernées va se faire avec un retard de plusieurs heure ou même plusieurs jours par rapport à une déclaration libre dès les premiers symptômes. Je ne suis pas certain d’adhérer à la logique de l’information fiable qui arrive trop tard par rapport à celle de l’information potentiellement fausse qui arrive au plus tôt. En tout cas dans un contexte de pandémie je me pose la question.
Pour traiter ça il faudrait que le mécanisme d’échange puisse gérer de façon distribuée la notion de pré-alerte et de confirmation :
- Pouvoir déclarer : Je suis peut-être/probablement malade (avec un niveau de confiance ?)
- Pouvoir déclarer : Fausse alerte le test est négatif (avec signature du médecin)
- Pouvoir déclarer : C’est confirmé je suis positif au test (avec signature du médecin)
L »autorité centrale dans ce cas fournirait juste l’infrastructure de clés pour que les les applications puissent vérifier à l’aide d’un « certificat racine » qu’un message avec un QRCode de médecin est bien valide.