iPhone (dé)verrouillé : résumé et épilogue de l’imbroglio San Bernardino

iPhone (dé)verrouillé : résumé et épilogue de l’imbroglio San Bernardino

900 000 dollars pour… rien

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

20/04/2021 17 minutes
34

iPhone (dé)verrouillé : résumé et épilogue de l’imbroglio San Bernardino

En décembre 2015, une fusillade déclenchait un affrontement brûlant entre Apple et le FBI. Au cœur du conflit, un iPhone retrouvé sur le terroriste. Le Bureau souhaitait que l’entreprise perce ses propres défenses, ce qu’elle refusait. Une faille fut finalement trouvée, au grand dam d’Apple. On connait désormais ce qui serait le fin mot de l'histoire.

La fusillade de San Bernardino, en Californie, est restée dans les mémoires. Elle est déclenchée par un couple, Sayed Rizwan Farook et Tashfeen Malik, et menée au nom de Daech. Elle fait 14 morts et 21 blessés non loin de Los Angeles à l’Inland Regional Center, organisme à but non lucratif dédié aux personnes en situation de handicap, physique ou mental.

Après la mort des deux terroristes, le FBI récupère sur le corps de Farook un iPhone 5c et l’enquête commence. À leur domicile, des preuves sont retrouvées sur leur appartenance à Daech et le smartphone devient un enjeu crucial : les données qu’ils renferment pourraient mener à d’autres membres du groupe.

L'iPhone étant verrouillé, le FBI demande l’aide d’Apple. À cette époque, iOS est en effet doté depuis peu d’une option permettant d’effacer le contenu intégral du téléphone si on enchaine dix codes erronés de verrouillage. La société se met au travail, mais le ton va très vite monter.

Le problème technique posé par le verrouillage

Le FBI, ne voulant pas risquer de perdre les données, profite donc dans un premier temps de l’expertise technique d’Apple, qui dispose – à l’instar de nombreuses grandes entreprises – d’un service dédié.

L’agence avait déjà demandé l’obtention des données sauvegardées dans iCloud, et pour lesquelles Apple possède la clé. Sur le téléphone en revanche, la situation est toute autre. Le code de déverrouillage à six chiffres utilisé par Farook posait un double problème. D’abord, il pouvait déclencher l’effacement de l’appareil en cas de dixième tentative erronée. Sans cette option, l’iPhone se serait « simplement » verrouillé, mais Apple aurait été en mesure de remédier au souci.

Ensuite, et surtout, ce code est utilisé dans la création de la clé privée servant au chiffrement local des données. Apple n’ayant pas le code, la clé de déchiffrement ne pouvait pas être reconstituée, ce qui fut signifié au FBI. La position du Bureau dans ce domaine était connue, puisqu’un an plus tôt, James Comey – alors directeur – avait exprimé ses craintes sur l’utilisation croissante du chiffrement au sein d’Android et iOS. La question était déjà pleinement posée : comment les forces de l’ordre peuvent-elles faire leur travail si les polices sont incapables d’accéder aux données ? Il se disait « ennuyé » par les entreprises faisant « expressément la promotion de quelque chose qui permettra aux gens de se placer hors de portée de la loi »

Il fallait donc qu’Apple perce dans ses propres défenses. Le FBI passe une première fois par la case justice, avec succès : un juge ordonne à Apple d’aider l’agence à contourner les mesures de sécurité de l’iPhone pour en extraire les précieuses informations.

Une porte dérobée dans iOS

Apple refuse d’altérer son produit. Peu de temps après le début des passes d’armes, Tim Cook se fend d’un communiqué. « Toutes ces informations ont besoin d’être protégées des pirates et criminels qui veulent y accéder, les voler et les utiliser sans notre connaissance ou notre permission. Les clients attendent d’Apple et des autres sociétés technologiques qu’elles fassent tout ce qui est en leur pouvoir pour protéger ces données personnelles […]. Compromettre la sécurité de nos informations personnelles pourrait à terme mettre notre sécurité personnelle en danger. Voilà pourquoi le chiffrement est devenu si important pour nous tous. »

L’entreprise est déjà coincée par sa communication, qui vantait déjà la sécurité et le respect de la vie privée. Accepter de contourner les protections aurait non seulement montré qu’elle en était capable, mais qu’elle pouvait « retourner sa veste ».

Apple avait d’ailleurs deux raisons de monter sur ses grands chevaux, car le FBI ne souhaitait pas seulement accéder aux données de cet iPhone en particulier : il demandait qu’une porte dérobée soit créée dans iOS pour que les enquêteurs bénéficient d’un nombre illimité de tentatives sur les codes de déverrouillage. Cette porte devait en outre permettre l’enchainement des tentatives sans délai, car iOS impose d’attendre pour recommencer après trois premiers essais infructueux. Et ce temps augmente de manière exponentielle à chaque nouvel échec.

La problématique des portes dérobées est connue, et Cook s’était d’ailleurs fait une joie de la rappeler : « Le FBI veut que nous créions une nouvelle version du système d’exploitation de l’iPhone pour contourner plusieurs fonctionnalités importantes de sécurité et l’installer sur un iPhone obtenu pendant l’enquête. Entre de mauvaises mains, ce logiciel – qui n’existe pas actuellement – aurait le potentiel de déverrouiller n’importe quel iPhone. Le FBI peut utiliser différents mots pour désigner cet outil, mais ne soyez pas dupes : bâtir une version d’iOS qui contourne la sécurité de cette manière créerait immanquablement une porte dérobée. Et bien que le gouvernement puisse assurer que son utilisation serait limitée à cette affaire, il n’existe aucune garantie d’un tel contrôle. »

Guerre de communication et enjeux opposés

L’un des aspects surprenants de l’affaire tenait dans la loi brandie par le FBI pour obtenir satisfaction : l’All Writs Act. Elle permet aux forces de l’ordre d’exiger d’une personne – physique ou morale – qu’elle fasse tout ce qui est nécessaire pour répondre aux demandes lors d’une enquête approuvée par un juge. Une loi qui date de 1789, « writs » pouvant se traduire par « ordres royaux ».

Chez Apple, on crie au scandale et on passe à la deuxième personne : « Les implications des demandes du gouvernement sont effrayantes. S’il peut utiliser l’All Writs Act pour faciliter le déverrouillage de votre iPhone, il obtiendrait le pouvoir d’atteindre n’importe quel appareil pour en récupérer les données. Le gouvernement pourrait élargir cette brèche dans la vie privée et demander à Apple de bâtir un logiciel de surveillance pour intercepter vos messages, accéder à vos données de santé ou financières, suivre votre position géographique ou même accéder à votre micro ou votre caméra sans que vous le sachiez. »

Apple fait donc appel de la décision et dénonce une utilisation abusive de l’All Writs Act. Le combat de l’entreprise est vite repéré et largement soutenu, notamment par l’ACLU (American Civil Liberties Union) et l’EFF (Electronic Frontière Foundation). Avocat à l’ACLU, Alexander Abdo résume alors le point de vue de l’association : « Si le FBI réalise une enquête, il ne peut pas forcer le serrurier du coin à l’aider à forcer une propriété ».

En l’espace d’une semaine, la communication devient nettement plus tranchée, montrant une grande entreprise faire face à une agence gouvernementale, avec en conséquence des intérêts très différents. Chez Apple, on tente de jouer cartes sur table pour expliquer, dans une FAQ, que les demandes du FBI vont trop loin. Elle va jusqu’à expliquer qu’elle serait en mesure de réaliser ce qui est demandé. Mais elle se refuse à créer un dangereux précédent, travaillant son jeu d’équilibriste : Apple ne doit pas apparaitre comme protégeant les terroristes, mais comme désamorçant des demandes jugées extrêmes. Google, Facebook ou encore Twitter apportent – évidemment – leur soutien à Apple.

Au FBI, les enjeux sont tout autres. C’est non seulement la plus grosse fusillade en Californie depuis 1984, mais elle est en plus marquée du sceau de Daech. La pression est forte : l’enquête doit aboutir. James Comey se montre direct : « L’affaire de San Bernardino n’a rien à voir avec la création d’un précédent ou l’envoi d’un quelconque message. Il s’agit ici de victimes et de justice. Quatorze personnes ont été assassinées et bien d’autres ont eu leurs vies et leurs corps détruits. Nous leur devons de par la loi une enquête complète et professionnelle. C’est comme ça. Les Américains ne devraient rien attendre de moins du FBI. »

Une guerre de communication et d’opinion s’engage. Quelques années auparavant, elle aurait peut-être été silencieuse. Mais 2013 et l’affaire Snowden sont passées par là, et les grandes entreprises américaines sont prises dans les répercussions sans fin des révélations, dont leur image est ressortie largement ternie.

Apple « aide les kidnappeurs, les voleurs et les meurtriers »

Deux semaines après le début des évènements, Apple remporte une importante victoire dans un tribunal de New York. On découvre alors que des iPhone sont au centre d’une douzaine d’affaires et qu’une victoire du FBI aurait une importance capitale pour la tenue de ces enquêtes. Or, le juge James Orenstein douche les espoirs de l’agence.

Il critique l’interprétation trop large faite de la loi par le FBI et rappelle qu’il existe des limites claires à l’application de cette loi, notamment que l’aide fournie par une personne morale ne doit pas mettre en danger son activité commerciale. Dans son jugement, il indique que l’Acte « ne peut être un moyen pour l’Éxécutif d’atteindre un objectif législatif que le Congrès a déjà examiné et rejeté ».

Une victoire importante mais pas définitive, car les deux affaires ont de larges différences. La principale tient au terrorisme, quand l’affaire jugée par Orenstein concernait le trafic de drogue. Le juge new-yorkais relevait cependant que le FBI semblait prêt à tout pour passer en force, ce qui ne manquait pas de l’inquiéter sur les retombées d’une telle utilisation de l’All Writs Act.

Ce verdict avait dans tous les cas donné une base puissante de défense pour Apple, car au vu de la communication de l’entreprise, il n’était pas difficile de prouver qu’obéir au FBI entrainerait immanquablement une baisse du chiffre d’affaires.

Peu de temps après, les propos s’échauffent nettement. On se souvient de John Miller, responsable de l’unité antiterroriste à New York, qui accusait Apple « d’aider les kidnappeurs, les voleurs et les meurtriers ». Et pour appuyer sa démonstration, il citait les propos d’un détenu de la prison de Riker’s Island avec un tiers : « Tu dois mettre iOS 8. C’est un don de Dieu, parce que les flics ne peuvent pas le pirater ».

Le FBI était d’autant plus agacé qu’il avait fini par reconnaître une erreur. Le terroriste avait bien une sauvegarde iCloud de ses données, mais les enquêteurs n’avaient réclamé les données qu’après avoir tenté de prendre le contrôle du compte Apple correspondant, passant par une réinitialisation du mot de passe.

Sans que l’on sache exactement comment, le FBI s’est retrouvé avec un compte verrouillé. Apple a bel et bien répondu aux demandes et récupéré la sauvegarde la plus récente. Mais elle datait du 19 octobre, soit un mois et demi avant les évènements tragiques du 2 décembre. Las, le FBI avait fini par indiquer que ces informations ne contenaient rien de significatif, mettant d’autant plus la pression sur les données toujours coincées dans l’iPhone.

La vulnérabilité entre en piste

Les passes d’armes vont continuer pendant encore une semaine, jusqu’à ce que le FBI surprenne tout le monde : l’aide d’Apple n’était plus requise, l’agence pouvant se débrouiller toute seule désormais. Ou presque.

Si au début le FBI n’évoque qu’une « méthode tierce » d’accès aux données, le Bureau finit par confirmer qu’il s’agit d’une faille 0-day. Une vulnérabilité pour laquelle il n’existe donc pas de correctif et qui permettrait aux enquêteurs d’entrer dans iOS, avec l’aide d’un tiers dont l’identité a longtemps été cachée.

L’annonce marque un grand tournant dans l’affaire et les rôles s’inversent. Apple, qui n’est soudainement plus sollicitée, va bien sûr se tourner vers le FBI pour lui demander des détails sur la fameuse « méthode ». La situation n’est guère plus plaisante pour la firme, qui se retrouve avec une faille dans la nature manifestement capable de passer les défenses de son système. Mais le Bureau reste coi.

Quelques détails filtrent peu après, par James Comey en personne. Dans une interview, pressé d’en dire davantage sur la faille, il finit par préciser que son prix a dépassé le salaire cumulé du temps qu’il lui restait à passer à ce poste. À l’époque, cette durée était de sept ans et quatre mois, pour un salaire annuel de 183 000 dollars. Le FBI aurait donc payé au moins 1,34 million de dollars. Il ajoute que la même méthode a pu être employée sur un iPhone doté d’iOS 9.

Cellebrite pourrait-elle être à l’origine de la fameuse méthode ? L’entreprise israélienne, dont c’est justement l’une des spécialités, ne répond pas. Trois médias vont cependant attaquer le FBI – The Associated Press, USA Today et Vice Media – en se basant sur la FOIA (Freedom of Information Act) : le Bureau étant financé par des fonds publics, les détails financiers et contractuels avec le tiers devraient être connus. Une transparence d’autant plus nécessaire que le FBI tentait de forcer le passage auprès d’Apple.

Après un échec, la procédure finit par faire mouche, et les trois médias obtiennent un document d’une centaine de pages révélant quelques précisions intéressantes. Par exemple, le FBI avait lancé un appel d’offres dès les premières tensions avec Apple pour une autre méthode, qui pouvait être une faille de sécurité. Trois entreprises avaient répondu, une avait été sélectionnée, mais le nom en avait été caviardé. Les informations les plus importantes avaient toutes subi le même traitement, la liberté d’information ne faisant pas le poids face au secret d’une faille.

Une faille dans un code de Mozilla payée 900 000 dollars

Il y a quelques jours, le Washington Post a présenté ce qui serait la conclusion de l’énigme. Selon le journal américain, la société ayant remporté l’appel d’offres se nommerait Azimuth Security, basée en Australie.

Elle aurait trouvé un lot de trois failles, dont la principale résiderait dans un code écrit par Mozilla et dont Apple se sert pour permettre aux iPhone et iPad d’utiliser des accessoires via le port Lightning. Les deux autres seraient là pour créer une chaine d’exploitation, probablement pour échapper à la sandbox et obtenir des droits supplémentaires. Résultat, l’équipe aurait été capable d’enchainer les tentatives de déverrouillage sans augmenter le temps entre chaque essai et sans risquer de déclencher l’effacement des données.

La méthode présentée par Azimuth Security serait nommée Condor. Elle a été facturée 900 000 dollars à l'agence, selon la sénatrice Diane Feinstein en 2017. Durant l’affaire San Bernardino, elle avait remis en cause l’attitude du FBI et interrogé le bien-fondé de ses demandes devant les tribunaux, craignant pour le chiffrement. Ce chiffre contredisait celui donné par James Comey et n’a jamais été confirmé.

L’histoire autour de cet iPhone n’a d’ailleurs pas manqué de nouveaux rebondissements. Apple aurait appris qui était à l’origine de cette méthode, principalement le chercheur David Wang. La firme aurait tenté de le débaucher d’Azimuth Security, offre déclinée par Wang. Le chercheur a fondé en effet peu après la société Corellium, dont le fonds de commerce est de virtualiser des iPhone et à qui l’ont doit récemment le portage de Linux vers les Mac M1.

Et on connait les relations d’Apple avec Corellium, puisque la Pomme a déjà tenté – sans succès – de faire interdire ce produit à la fin de l’année dernière. Une autre procédure est en cours, dans laquelle elle affirme que Corellium a contourné des mesures de sécurité pour faire fonctionner son logiciel.

La faille corrigée, l’iPhone finalement presque vide

La suite est en tout cas connue. En avril 2016, le FBI annonce publiquement que l’iPhone ne contenait aucun contact terroriste et finalement aucun indice critique sur Daech ou même d’autres groupes.

Tout ça pour ça ? Oui, mais le FBI ne pouvait le savoir sans atteindre les précieuses données. L’affaire de « l’iPhone de San Bernardino », comme on l’appelle depuis, cristallise les interrogations sur plusieurs sujets, dont le plus important est la sécurité.

Le mot fourre-tout recouvre parfois des visions antagonistes. Par exemple, la sécurité chez Apple recouvre une préservation du chiffrement et un refus d’insérer des portes dérobées. Ces dernières pourraient être trouvées par des pirates, qui les exploiteraient à leur seul bénéfice. Pour le FBI, la sécurité recouvre des menaces nettement plus physiques contre la population.

Les deux sont indissociables et pourtant antagonistes. Toute technologie de sécurité peut être détournée pour masquer des comportements illégaux, voire malveillants. Mais tout affaiblissement de la sécurité peut être exploité de la même manière, et il n’existe aucune méthode garantissant qu'une faiblesse ne serait utilisée que pour des raisons « légitimes ».

Cette thématique, déjà complexe, l’est encore davantage aux États-Unis. La NSA y gère en effet à la fois l’attaque et la défense, alors que l’ANSSI ne gère en France que la défense par exemple. Pour illustrer cette ambivalence, rappelons que l’agence avait d’elle-même publié une infographie où elle clamait fièrement, un mois avant les évènements de San Bernardino, que 91 % des failles collectées étaient communiquées aux sociétés concernées. Traduction, 9 % d’entre elles étaient gardées en réserve pour d’éventuelles missions.

L’affaire de San Bernardino a de nouveau illustré cette ambivalence, les forces de l’ordre ayant eu recours à une faille, sans en communiquer les détails à Apple. Cela étant, la firme a quand même colmaté la brèche, Mozilla l’ayant découverte environ deux mois après le déverrouillage de l’iPhone par le FBI.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le problème technique posé par le verrouillage

Une porte dérobée dans iOS

Guerre de communication et enjeux opposés

Apple « aide les kidnappeurs, les voleurs et les meurtriers »

La vulnérabilité entre en piste

Une faille dans un code de Mozilla payée 900 000 dollars

La faille corrigée, l’iPhone finalement presque vide

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (34)


On pourrait accuser Apple de protéger les criminels en brandissant la sécurité de vie privée de son matériel.
Mais on oublie aussi que ces sécurités ne sont pas apparus du jour au lendemain et que les gens ont commencés à s’y intéresser uniquement après les révélations Snowden, révélations dues à l’appétit vorace des services de renseignements, récoltant tout et n’importe quoi “parce que ça pourrait servir”.



Du coup, ces fameux services auraient pris que ce dont-elles auraient eu besoin à l’époque, Snowden travaillerait toujours pour les mêmes agences, les OS auraient pas vu leur sécurité renforcée et l’affaire de San Bernardino dans la presse en n’aurait pas été une.


C’est juste.



Le plus cynique étant que le FBI a sauté sur l’occasion pour jouer la carte “antiterrorisme” pour essayer de forcer apple à reculer sur la légitime sécurité qu’elle promet à ses utilisateurs. Le pire étant qu’ils sont prêts à risquer la sécurité de tous pour leur petit délire panoptique.


On ne peut que saluer la position d’Apple dans cette affaire.



En imaginant qu’Apple accepte d’ajouter des portes dérobées dans son système, les utilisateurs mal-intentionnés utiliseraient un autre système (du android custom ou autre) …
Donc en définitive : on aurait le même problème pour le FBI, à l’exception près que le reste de la population pourrait elle se faire étroitement surveiller par nos amis des services de renseignements.



C’est sans même mentionner qu’une porte dérobée quand elle existe peut effectivement être utilisée par des pirates une fois découverte. Encore pire.



gjdass a dit:


En imaginant qu’Apple accepte d’ajouter des portes dérobées dans son système, les utilisateurs mal-intentionnés utiliseraient un autre système (du android custom ou autre) …




Après on pourrais imaginer faire une version de l’OS sans ses sécurités, dont seul Apple aurais accès en interne, qu’il fasse la mise a jour, fasse le brute-force, et reflashe le firmware d’origine après. Le plus dur dans cette histoire est de s’arranger pour que cette version de l’OS ne sorte pas du coffre fort d’Apple.



(reply:1868718:Naruto`kun)




Il est pas impossible qu’elle existe cette version d’iOS.


C’est (en mon humble opinion) peu probable, le risque de fuite étant plus importants que tous les bénéfices potentiels. Au final on en revient toujours à la confiance que l’on accorde au propriétaire constructeur du device (cela vaut pour toute puce ayant au moins un blob propriétaire dans son firmware).



xdbob a dit:


le risque de fuite étant plus importants que tous les bénéfices potentiels




C’est ce que je me suis dis au début, mais si on y réfléchit, ils arrivent bien a sécuriser la clé privée qui permet de signer leur OS, en quoi ils pourraient pas faire pareil avec l’OS directement?



(reply:1868718:Naruto`kun)




Parce que ça sous-entend qu’ils y a deux versions à maintenir, donc à tester.
En sachant que malgré les tests, certains retours se font d’après les utilisateurs, tu as donc toutes les chances que quelqu’un fuite l’existence de cette version (et pas nécessairement le code source hein, juste son existence).



Pour Apple et son iPhone, gardien de la vie privée, ça donnerait une mauvaise image.


Je ne connais pas très bien les iPhones et ce qu’on peut faire dessus, mais pour éviter de perdre les données et tenter quand même une attaque en force brute (6 digits c’est pas compliqué), c’était pas possible de dumper la flash et d’essayer de déverrouiller le téléphone dans une VM (qu’on peut recréer toutes les 10 tentatives échouées à partir du dump original, voire lancer en parallèle sur pls milliers de machines qui tenteront chacune des combinaisons différentes des 6 chiffres de déverrouillage) ?


Il me semble que depuis pas mal de temps, Apple utilise un Secure Element, un peu similaire à du TPM. Du coup la clé de déchiffrement y est stockée, ainsi que le code PIN associé.
Le contenu du Secure Element n’est pas “copiable”, du coup impossible de le monter dans un VM
Je laisse les experts commenter sur les détails ;)



(reply:1868718:Naruto`kun)




C’est précisément la demande du FBI, mais pour pouvoir faire une attaque en force brute sur le pin



Avoir un dump de la flash ne sert en théorie à rien, car cette flash est chiffrée. En général, la clef est dans un secure element (SE), qui te le délivre contre un code pin correct (c’est simplifié, il y a aussi de l’authentification entre les acteurs dans l’histoire). D’ailleurs, je suis surpris que ce SE ne détruise pas de lui même les clef en cas de tentatives infructueuses trop nombreuses, rendant toute tentative d’arnaque par force brute impossible. Mais je ne sais pas ce qu’il en est pour les iPhones.
De plus, ta proposition consiste peut-être à déssouder et ressouder la flash un nombre incalculable de fois pour la réinitialiser, ça me semble difficile…



popi_le_clown a dit:


Avoir un dump de la flash ne sert en théorie à rien, car cette flash est chiffrée. En général, la clef est dans un secure element (SE), qui te le délivre contre un code pin correct (c’est simplifié, il y a aussi de l’authentification entre les acteurs dans l’histoire). D’ailleurs, je suis surpris que ce SE ne détruise pas de lui même les clef en cas de tentatives infructueuses trop nombreuses, rendant toute tentative d’arnaque par force brute impossible. Mais je ne sais pas ce qu’il en est pour les iPhones.




Le secure element complique le problème, voire le rend insoluble, à moins que le constructeur n’ait une méthode pour en extraire le contenu. Si ce n’est pas le cas, ça doit être trop long effectivement de casser le chiffrement de l’iPhone (j’imagine qu’Apple n’a pas chiffré ça avec une clé de 8 bits). Concernant la destruction des clés en cas d’échecs répétés, ce n’est pas ce qui se passe quand les 10 essais ont été ratés ?




De plus, ta proposition consiste peut-être à déssouder et ressouder la flash un nombre incalculable de fois pour la réinitialiser, ça me semble difficile…




Non, une fois pour en extraire le contenu, et on utilise la copie pour tenter les PIN.


Pour Apple accéder aux données est trivial. Je m’explique.




  • Il suffit de mettre à jour l’iPhone avec une version spéciale, que eux seul peuvent réaliser. Car c’est signé, et le bootloader refusera une image “invalide”.

  • En effet, il nous faut le code pin pour pouvoir déchiffrer en utilisant le TPM. Mais la limitation du nombre d’essais est purement logiciel, et non HW. Donc la version spécialement déployée lors de cette mise à jour, n’a pas cette limitation, et va automatiquement brute-forcer toutes les combinaisons.

  • Et voila on a un iPhone qui se déverrouille tout seule.



Mais il n’y a qu’Apple qui peut déployer une telle image. Déjà il faudrait reverse-engineer tellement de chose que cela prendrait une éternité à faire, même pour une grosse institution, et après il faut avoir le “certificat” pour signer le binaire, et cela c’est très bien gardé par Apple



Après la question peut se poser si c’est possible de mettre à jour l’iPhone (juste la partie nécessaire) sans le déverrouiller au préalable… Si ce n’est pas possible tout ce que j’ai expliqué tombe à l’eau.


benjarobin

Pour Apple accéder aux données est trivial. Je m’explique.




  • Il suffit de mettre à jour l’iPhone avec une version spéciale, que eux seul peuvent réaliser. Car c’est signé, et le bootloader refusera une image “invalide”.

  • En effet, il nous faut le code pin pour pouvoir déchiffrer en utilisant le TPM. Mais la limitation du nombre d’essais est purement logiciel, et non HW. Donc la version spécialement déployée lors de cette mise à jour, n’a pas cette limitation, et va automatiquement brute-forcer toutes les combinaisons.

  • Et voila on a un iPhone qui se déverrouille tout seule.



Mais il n’y a qu’Apple qui peut déployer une telle image. Déjà il faudrait reverse-engineer tellement de chose que cela prendrait une éternité à faire, même pour une grosse institution, et après il faut avoir le “certificat” pour signer le binaire, et cela c’est très bien gardé par Apple



Après la question peut se poser si c’est possible de mettre à jour l’iPhone (juste la partie nécessaire) sans le déverrouiller au préalable… Si ce n’est pas possible tout ce que j’ai expliqué tombe à l’eau.


Mouais, faites ce que je vois c’est loin d’être aussi évident : ça semble bien fait en HW, au moins sur les iPhones récents
https://www.numerama.com/tech/146674-comment-fonctionne-le-chiffrement-des-donnees-sur-iphone.html
https://support.apple.com/fr-fr/guide/security/sec59b0b31ff/web



Après, je m’emballe, parce qu’ici c’est quand même un vieil iPhone 5c, qui n’a visiblement rien de ces protections



(reply:1868704:gjdass) et tout le monde.




C’est pas l’Allemagne qui a indiqué dernièrement dans sa constitution le fait que chaque produits / dispositifs devaient avoir un porte dérobée pour les renseignements ?
Je retrouve pas d’article mentionnant cela explicitement.




Mais du coups, si n’importe quel pays vote quelque chose comme cela, cette porte dérobée sera donc disponible pour tout les pays, ce qui pourrait mettre Apple ou les autre dans l’illégalité dans d’autre pays qui auraient une loi disant l’inverse …. :fou:


Ça m’étonnerait très fortement que l’Allemagne ait voté ce genre de loi…



deathscythe0666 a dit:


à moins que le constructeur n’ait une méthode pour en extraire le contenu.




C’est justement le concept d’un SE de ne pas laisser faire ça :/




deathscythe0666 a dit:


Concernant la destruction des clés en cas d’échecs répétés, ce n’est pas ce qui se passe quand les 10 essais ont été ratés ?




Normalement si, de ce que j’avais compris. Mais comme une attaque par force brute est possible, je me demande si quelque chose n’est pas géré par l’os, ici. Comme par exemple le fait de détruire la clef : si c’était géré par le SE sans accès par l’os, il ne serait pas possible de d’inhiber ce comportement, et une attaque par force brute comme le FBI a pu le faire le semble bien plus dur : il faut compromettre l’os (ce qui a été fait) et ce SE (on n’en parle pas ici).




deathscythe0666 a dit:


Non, une fois pour en extraire le contenu, et on utilise la copie pour tenter les PIN.




Je viens de regarder rapidement comment semblait marcher le chiffrement chez Apple. Le code pin ne déchiffre rien du tout, donc ne sert à rien avec un dump. La clef de déchiffrement n’est visiblement jamais accessible…


Je ne connais pas la procédure mais la suggestion de ressoudage factice des boitiers est possible avec des interrupteurs, tout simplement…



Le problème c’est le coût de l’opération et sa validation en tant qu’analyse recevable en justice.


L’iPhone est “inviolable” mais pas l’iCloud… où le backup de l’iPhone est stocké si l’option est activé.



https://www.reuters.com/article/us-apple-fbi-icloud-exclusive-idUSKBN1ZK1CT



(reply:1868821:Idiogène)
Dans tous les cas, comme je l’ai dis plus haut, le pin n’est pas la clef, et cette dernière n’est pas accessible à l’os, d’après ce que j’ai lu. Donc ça ne résout pas le problème : la copie ne sert à rien. Et comme tu l’as dit, extraire une copie directement depuis la flash, ça ne doit pas être évident, même s’ils ont réussi à dépenser une somme colossale pour accéder aux données…




popi_le_clown a dit:


Je viens de regarder rapidement comment semblait marcher le chiffrement chez Apple. Le code pin ne déchiffre rien du tout, donc ne sert à rien avec un dump. La clef de déchiffrement n’est visiblement jamais accessible…




Du coup, avec un dump, l’objectif est d’essayer de casser le chiffrement, mais c’est peut être pas possible dans un temps raisonnable selon les algos utilisés.


Le principe général de ces solutions est toujours semblable, c’est d’avoir un HSM dédié dans l’environnement du système pour sécuriser les clefs nécessaires.
Celui d’Apple s’appelle secure enclave. Sur des machines de bureau c’est le module TPM qui est utilisé de manière équivalente par exemple dans windows hello avec des codes PIN qui protègent la clef utilisée pour le login sur le système. Ceux d’entre vous qui n’ont encore jamais dû dépanner dans leur entourage un PC dont le code PIN est rendu inopérant par un changement de hardware doivent d’abord mesurer leur chance et ensuite savoir que ça va finir par leur tomber dessus.
Le problème du module TPM c’est que des petits malins ont utilisé le fait que le hardware dédié soit en dehors (chip discret ou intégré au southbridge) pour intercepter les signaux entre le CPU et le TPM avec des dispositifs matériels lourds (petits malins identifiant ici généralement une agence gouvernementale en trois lettres).
Le fait d’avoir intégré le HSM directement dans le SoC rend ce genre de gymnastique déjà ardue autrement plus acrobatique, d’où le fait qu’ils aient peu goûté les choix opérés par Apple. Microsoft a un projet similaire pour amener ce niveau de sécurité sur les CPU des PC de bureau (chercher Pluton hardware security).



Enfin notez qu’Apple a quant même fini par se coucher sur l’implémentation d’une clef sous le contrôle exclusif de l’utilisateur pour le chiffrement des sauvegardes iCloud et qu’ils sont restés remarquablement discrets sur ce renoncement pas franchement glorieux.



ehol a dit:


Enfin notez qu’Apple a quant même fini par se coucher sur l’implémentation d’une clef sous le contrôle exclusif de l’utilisateur pour le chiffrement des sauvegardes iCloud et qu’ils sont restés remarquablement discrets sur ce renoncement pas franchement glorieux.




Autant ça ne me plairait absolument pas que mes données soient accessibles, autant c’est logique pour une sauvegarde. Si l’utilisateur perd ou détruit son téléphone, il perd aussi sa clé et donc la sauvegarde serait inutilisable et donc… inutile :transpi:


Avoir la clef sous le contrôle de l’utilisateur ne signifie pas forcément qu’elle reste stockée dans le téléphone. Ça peut être une clef dérivée d’un mot de passe.
Le fait qu’elle soit sous le contrôle exclusif de l’utilisateur signifie évidemment qu’il y a plus de procédure de recovery s’il oublie ou perd toutes les sauvegardes de l’information nécessaires. Ça signifie aussi qu’Apple n’aurait plus la capacité de fournir les sauvegardes déchiffrées sous réquisition judiciaire. Mais également de se les faire piquer par un attaquant malveillant.
Ils avaient à une époque suggéré qu’ils se dirigeaient par là.
Ils n’en parlent plus du tout. Et il y a clairement eu beaucoup de pressions.


ehol

Avoir la clef sous le contrôle de l’utilisateur ne signifie pas forcément qu’elle reste stockée dans le téléphone. Ça peut être une clef dérivée d’un mot de passe.
Le fait qu’elle soit sous le contrôle exclusif de l’utilisateur signifie évidemment qu’il y a plus de procédure de recovery s’il oublie ou perd toutes les sauvegardes de l’information nécessaires. Ça signifie aussi qu’Apple n’aurait plus la capacité de fournir les sauvegardes déchiffrées sous réquisition judiciaire. Mais également de se les faire piquer par un attaquant malveillant.
Ils avaient à une époque suggéré qu’ils se dirigeaient par là.
Ils n’en parlent plus du tout. Et il y a clairement eu beaucoup de pressions.


Fermer la clé à double tours et laisser la fenêtre ouverte…



Le contrôle exclusif parait douteux : le module de chiffrement (le secure enclave) est dans tous les cas de figue une preuve matérielle. Inutile donc de demander le mot de passe il est lisible depuis cet élément. La faille logicielle exploitée c’est juste pour la frime.



Je me demande aussi pourquoi le FBI n’a pas souhaité faire cette expertise en profondeur… Après tout casser littéralement un iphone made in china c’est pas la mer à boire pour eux. Ou alors ils sont devenus des adeptes des bisounours et répudient la technique de l’éléphant dans le magasin de porcelaine mais je ne vois pas bien la différence dans le cas du cassage par force brute… c’est tout aussi bête et méchant que la porte dérobée pour mammouth…



deathscythe0666 a dit:


Le secure element complique le problème, voire le rend insoluble, à moins que le constructeur n’ait une méthode pour en extraire le contenu.




Comme pour toute puce électronique, il y a toujours la solution de fraiser le boîtier de la puce pour mettre le die à nu, regarder au microscope électronique, chercher où se trouve la clé ou le code pin sur le die (par reverse engineering avec l’aide d’autres exemplaires non verrouillés de la puce), et lire les bits à l’oeil. L’avantage est qu’il y a relativement peu de données à lire.



Par contre, ça demande du matériel hyper précis, ça prend beaucoup de temps, et faut pas se louper. Mais est-ce que c’est plus cher qu’un million, je ne sais pas.


Superbe synthèse très plaisante à lire ! Merci @Vincent-Hermann !



Ce genre d’article est précieux, il permet une réelle remise en perspective des faits, et apporte des éléments de réflexion. Pour moi c’est une péptite journalistique.



(Et je suis très heureux de vous payer mon abonnement :) )


:oops: :smack:



Inodemus a dit:


Par contre, ça demande du matériel hyper précis, ça prend beaucoup de temps, et faut pas se louper. Mais est-ce que c’est plus cher qu’un million, je ne sais pas.




Vu l’application qui devait en être faite, cette méthode (et son budget) aurait très probablement pu se justifier pour le FBI.



benjarobin a dit:


Mais la limitation du nombre d’essais est purement logiciel, et non HW. Donc la version spécialement déployée lors de cette mise à jour, n’a pas cette limitation, et va automatiquement brute-forcer toutes les combinaisons.




Qu’en sais-tu ? Ce pourrait etre géré pas le HW.


J’en sais car l’article indique que suite à une faille logiciel il est possible in fine d’enchainer les essais (Voir l’article…). Donc limitation purement logiciel.



(reply:1869536:benjarobin) my bad :)



Je vois pas où tu veux en venir.
Il s’agit ici de deux aspects distincts. D’abord le chiffrement du téléphone, avec son HSM embarqué dans le SOC et qui est bien sous le contrôle de l’utilisateur puisqu’il faut activer la clef qui est dedans. Et que donc Apple ne peut pas déchiffrer.
Ensuite le chiffrement des sauvegardes dans le cloud qui sont forcément pas selon les mêmes modalités puisque l’un des principaux cas d’usage est de restaurer sur un matériel distinct (classiquement changement pour un modèle plus récent ou remplacement pour perte). L’aspect sur lequel je disais donc qu’ils s’étaient couchés c’était le fait de révoquer toute leurs possibilités d’accéder aux clefs protégeant les backups en ligne. Qui ne ne peuvent donc pas être uniquement des clefs matérielles planquées dans le téléphone.



ehol a dit:


Je vois pas où tu veux en venir…Qui ne ne peuvent donc pas être uniquement des clefs matérielles planquées dans le téléphone.




À montrer que Apple ou le FBi sont très potes : l’un dit aux américains qu’il existe une puce pour se protéger du vol physique, l’autre valide son efficacité et dilue le problème dans une solution logicielle.



Sachant qu’on a déjà des méthodes de chiffrement réellement pertinentes et efficaces à tous les niveau ailleurs (chez les pros) il faut en conclure que toute cette affaire est une vaste fumisterie…