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

900 000 dollars pour… rien

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

Le 20 avril 2021 à 12h14

Commentaires (34)

votre avatar

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.

votre avatar

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.

votre avatar

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.

votre avatar

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.

votre avatar

(reply:1868718:Naruto`kun)


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

votre avatar

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

votre avatar

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?

votre avatar

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

votre avatar

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) ?

votre avatar

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 ;)

votre avatar

(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…

votre avatar

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.

votre avatar

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.

votre avatar

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
support.apple.com Apple



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

votre avatar

(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:

votre avatar

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

votre avatar

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…

votre avatar

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.

votre avatar

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

votre avatar

(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…


votre avatar

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.

votre avatar

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.

votre avatar

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:

votre avatar

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.

votre avatar

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…

votre avatar

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.

votre avatar

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 :) )

votre avatar

:oops: :smack:

votre avatar

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.

votre avatar

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.

votre avatar

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.

votre avatar

(reply:1869536:benjarobin) my bad :)


votre avatar

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.

votre avatar

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…

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

  • 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

Fermer