Chiffrement : Le député Yann Galut (PS) va prochainement déposer une proposition d’amendement visant à imposer de très lourdes sanctions financières aux sociétés comme Apple ou Google, qui refusent actuellement de donner accès aux données des téléphones de leurs propres clients.
C’est à se demander ce qui passe, parfois, dans la tête de certains députés. Yann Galut, député PS, proposera prochainement, dans le cadre de la prochaine grosse loi crime organisé, énième loi depuis quelques années, d’imposer des sanctions financières de l’ordre du million d’euro.
Le principe
J’imagine aisément les motivations dudit député : lutter contre le crime. Quoi de plus louable me direz-vous. Il est vrai que les forces de l’ordre rencontrent, de façon anecdotique cependant, des problèmes avec des téléphones chiffrés. Cette impossibilité d’accéder aux données présentes dans le téléphone complique le travail des forces de l’ordre dans le cadre de certaines enquêtes.
C’est donc « logiquement » que le député Galut cherche une solution au problème posé. En soi, c’est une intention louable que de vouloir arranger les choses
Mais pas n’importe comment
Le problème n’est donc pas l’intention du député, mais la solution qu’il propose : imposer aux sociétés qui chiffrent les données de leurs utilisateurs de donner accès à ces données.
Le député se veut rassurant : « Le procureur ou le juge d’instruction ne pourront avoir accès à la clé de chiffrement des constructeurs de smartphones qu’avec l’autorisation du juge des libertés et de la détention. Par ailleurs, cette clé ne servira que pour le ou les portables concernés par la procédure judiciaire » (source)
Cependant, et l’histoire me donnera malheureusement raison, ce n’est pas ainsi que cela se passe. Dès lors qu’on donne accès à de tels moyens, on ouvre une boite de pandore. D’autres services, pour d’autres raisons tout autant justifiées, viendront se greffer à ce dispositif d’accès et au final, cet accès se banalisera à l’ensemble des services et l’outil sera encore et toujours détourné de ce pour qui et quoi il était fait à la base.
Chiffrement : un problème de compréhension
Le député, sollicité par mes soins, n’a pas encore donné suite, mais j’espère que cela arrivera, pour lui expliquer que quelque chose lui échappe manifestement.
Premièrement, je doute que demander à Apple et Google de fournir des solutions pour casser les protections installées soit légal. Soit on demande à l’ensemble des fournisseurs de solutions de chiffrement de donner des moyens pour casser des protections, soit on ne demande à personne.
Ensuite, le député Galut n’a pas compris quelque chose, il n’est pas technicien, mais député. Je vais donc expliquer ce qu’il ne comprend pas : Apple et Google proposent des solutions de chiffrement qui font que même eux ne sont pas en capacité de connaître la clef que l’utilisateur à choisi.
Donc, le seul moyen d’accéder aux données du téléphone, c’est d’obtenir la clef, donc que l’utilisateur accepte de la donner.
A défaut, puisque Apple et Google sont dans la totale incapacité d’accéder aux données, ils seront dans l’obligation d’installer une des deux solutions suivantes :
- une clef générique, qui ne tardera pas à fuiter et à représenter une menace plus que sévère pour la protection des données du téléphone.
- une porte dérobée, qui ne tardera pas à être découverte et qui sera utilisée par de très nombreuses personnes.
Dans les deux cas, cela revient à affaiblir la sécurité des appareils et à exposer nos données personnelles à de trop nombreux risques.
Je ne vous jette pas la pierre, monsieur le député Galut. Votre travail n’est pas de comprendre « comment ça marche », le mien si. A une époque où le chiffrement devient de plus en plus la norme, vos propositions ne devraient pas exister.
Monsieur le député, si vous prenez le temps de lire mon billet, prenez aussi celui de me contacter afin que nous puissions échanger sur le sujet. Vos intentions sont louables mais les solutions que vous proposez sont tout bonnement irréalistes et dangereuses.
Le cas est relativement complexe,
la moindre simplification,
le moindre oubli entraîne une compréhension erronée.
La quasi totalité des articles de presse font ces erreurs là, et c’est bien dommage.
J’espère que je ne ferai pas de même ci-après.
– Apple ne refuse pas d’aider le FBI, ils ont collaboré, pleinement, dans les limites légales qui s’imposent à eux.
– Apple à proposé au FBI de ramener l’IPhone à proximité d’un réseau wifi sur lequel il avait probablement déjà été connecté, pour éventuellement pouvoir obtenir une sauvegarde ICloud récente (celles en possession d’Apple datent de 6 semaines avant l’attaque de mémoire).
Ça n’a pas fonctionné, car quelqu’un a ré initialisé le mot de passe ICloud, l’Iphone ne peut donc pas s’y connecter.
– Apple ne refuse pas de donner accès aux données qu’ils ont, ils ont livré les sauvegardes ICloud qu’ils avaient en leur possession.
– Apple ne refuse pas de donner accès aux données chiffrées présentes dans l’Iphone, ils ne peuvent techniquement pas !
Ils n’ont pas connaissance de la clef de chiffrement, elle est propre à chaque équipement et dépend en plus du pin de l’utilisateur (cf :https://reflets.info/apple-versus-fbi-le-choc-des-pipeaux/)
– Apple conteste le jugement rendu (https://assets.documentcloud.org/documents/2714001/SB-Shooter-Order-Compelling-Apple-Asst-iPhone.txt)
l’obligeant sous couvert d’une loi de 1789 (!!) (https://en.wikipedia.org/wiki/All_Writs_Act) à fournir une « assistance technique raisonnable » consistant à développer du code qu’ils disent ne pas avoir et qui permettrait de (points 2.1 à 2.3) :
* désactiver si elle est active la fonctionnalité d’auto effacement des donnés après saisi de 10 codes pin erronés
* entrer le pin code via le port physique, wifi, bluetooth ou tout autre protocole disponible sur l’appareil
* désactiver tout délais d’attente introduit logiciellement entre deux saisie de pin.
En d’autres mots, amoindrir considérablement les mesures de sécurité de l’appareil et permettant d’essayer tout les code pin possibles (attaque en force brute) le plus vite possible.
Enfin le logiciel en question doit être signé numériquement pour ne pouvoir s’exécuter que sur l’IPhone en question (point 3), sur un autre appareil il ne doit donc PAS fonctionner.
Ça semble rassurant, c’est probablement fait pour. Mais du coup, impossible donc de le tester et d’en valider le bon fonctionnement sur d’autres appareils.
Ce qui est problématique en soi concernant la validité juridique des données extraites.
Ou alors, le code n’est pas restreint sur un seul appareil, et il fuitera nécessairement et dans un délais très court.
Un outil forensic DOIT être audité par de multiples parties pour être reconnu fiable.
(J’ai lu un long article en anglais d’un expert judiciaire qui critiquait vertement cet aspect, mais je ne le retrouve pas).
Le point 4 est sympa et laisse un peu de latitude à Apple.
=> Apple conteste le caractère « raisonnable » de l’aide technique exigée (ne souhaite pas créer un précédent fâcheux, la justice US ayant d’autres cas en attente, et bien d’autres juridictions également, y compris des « démocraties relatives »).
=> Apple prétend qu’un tel logiciel, s’il fuitait et Apple y voit une certitude, mettrait en danger la vie privée de tout ses clients, nuirait à la confiance qu’ils lui accordent, nuirait à son image de marque et donc nuirait à son business.
Et aux USA le business c’est quelque chose !
Enfin le contexte, les méchants ont pris grand soin de détruire physiquement leurs téléphones personnels faisant du coup disparaître toutes preuves qu’ils pouvaient contenir et entravant d’autant le travail du FBI …
Pourquoi personne n’exige des téléphones indestructibles ?
Ça je suis quasi certain qu’on serait nombreux à être pour et ça ne mettrait en danger la vie privée de personne.
Celui retrouvé chiffré est le tel pro du terroriste, pour lequel les données sont manquantes pour la seule période de 6 semaines précédent l’attaque, avant le FBI a les sauvegardes ICloud.
Sur cette période de 6 semaines, le FBI a très probablement toute les autres données possibles, localisation, n° appelés, appelants, duré d’appel, etc, etc.
Fallait pas flinguer le mec qui connaissait le code pin ‘stout.
Là ils peuvent toujours essayer de waterboarder l’IPhone à défaut du mec ou de sa nana ou de leurs parents/gosses/amis/vagues connaissances/etc.
Pour terminer, je n’aime pas Apple, son écosystème fermé, sa morale pudibonde, son « optimisation fiscale » etc, etc, mais je comprends parfaitement leur position actuelle et au regard des éléments connus, suis plutôt enclin à la partager.
Bonjour,
Merci pour cet article. Il me semble pourtant que la faisabilité technique, il existe un moyen éprouvé de chiffrer un container avec deux paires de clefs distinctes.
Je m’explique, les étapes sont les suivantes:
1. Le fabricant de téléphone génère une paire de clef (publique/privée) pour chaque device qu’il fabrique. On a donc, chez le vendeur dans une de ses bases de données, une association DeviceID (numéro de série) paire de clef
2. Le fabricant installe la clef publique sur l’OS avant la livraison du device
3. Lorsque le client achète son device tout beau tout neuf, il le déballe et doit choisir lors du premier démarrage un mot de passe donc sera dérivée une autre paire de clef publique/privée qui lui sera propre.
4. Ensuite, une clef symétrique (AES256 par exemple) est générée et l’ensemble du téléphone est chiffré avec cette clef symétrique. Puis, stocké dans un espace dédié (un header, un stub quelconque), cette clef symétrique est elle même chiffrée deux fois:
– une fois avec la clef publique du fabricant pour ce device précis
– une fois avec la clef publique du possesseur du téléphone
Résultat:
Si nécessaire, le fabricant peut fournir une clef privée de déchiffrement du téléphone aux autorités. Cette clef n’est pas « générique » mais propre à chaque device.
Voilà en gros comment ça marcherait, et c’est un principe qui est utilisé pour des traces sécurisées sur certains équipements que j’utilise, afin de permettre un accès à différente équipes, avec des clefs différentes.
Évidemment, si la BDD du fabricant est compromise, c’est la merde 🙂