L'affaire Apple vs FBI a attirĂ© l'attention sur la question de la vie privĂ©e, en particulier dans le contexte des appareils mobiles. AprĂšs l'attaque terroriste de San Bernardino en 2015, le FBI a saisi un tĂ©lĂ©phone portable appartenant au tireur, Syed Farook, dans le but de rechercher des preuves supplĂ©mentaires ou des indices relatifs Ă l'enquĂȘte en cours. Cependant, bien qu'il soit en possession de l'appareil, le FBI n'a pas pu dĂ©verrouiller le tĂ©lĂ©phone et accĂ©der Ă son contenu.
Cela peut sembler déconcertant au premier abord.
« Sûrement, si le FBI avait accÚs au téléphone, il ne pourrait pas extraire les données utilisateur qui y sont stockées à l'aide d'outils médico-légaux ? »
Eh bien, la réponse n'est pas si simple. Vous voyez, l'appareil en question est un iPhone 5c avec iOS 9.
Comme vous le savez, à partir d'iOS 8, Apple a automatiquement activé le Chiffrement complet du disque (FDE) à l'aide d'une clé de cryptage dérivée du mot de passe de l'utilisateur. Pour accéder aux données sur l'appareil, le FBI devrait briser ce cryptage. à moins d'erreurs dans la conception du cryptage, cela aurait probablement été obtenu en craquant le mot de passe de l'utilisateur.
« Alors pourquoi ne pas utiliser le forçage brutal ? »
Cela semble ĂȘtre une trĂšs bonne approche - d'autant plus que la plupart des utilisateurs sont notoirement maladroits dans le choix de mots de passe forts, en particulier lorsqu'il s'agit d'appareils mobiles.
Cependant, les ingénieurs d'Apple n'ignoraient pas cette préoccupation lorsqu'ils ont conçu leur schéma FDE. Afin d'essayer d'atténuer ce type d'attaque, ils ont conçu le schéma de cryptage de sorte que la clé cryptographique générée soit liée au matériel de l'appareil.
En bref, chaque appareil possĂšde une clĂ© unique et immuable de 256 bits appelĂ©e UID, qui est gĂ©nĂ©rĂ© de maniĂšre alĂ©atoire et fusionnĂ© dans le matĂ©riel de l'appareil lorsqu'il est produit. La clĂ© est stockĂ©e de maniĂšre Ă empĂȘcher complĂštement l'accĂšs Ă l'aide d'un logiciel ou d'un micrologiciel (elle ne peut ĂȘtre dĂ©finie que comme clĂ© pour le moteur AES), ce qui signifie que mĂȘme Apple ne peut pas le retirer de l'appareil une fois qu'il a Ă©tĂ© configurĂ©.
Cette clĂ© spĂ©cifique Ă l'appareil est ensuite utilisĂ©e avec le mot de passe fourni par l'utilisateur pour gĂ©nĂ©rer la clĂ© de chiffrement rĂ©sultante utilisĂ©e pour protĂ©ger les donnĂ©es de l'appareil. Cela "emmĂȘle" efficacement le mot de passe et la clĂ© UID.
Lier la clé de cryptage au matériel de l'appareil permet à Apple de rendre le travail beaucoup plus difficile pour les attaquants potentiels. Essentiellement, cela oblige les attaquants à utiliser l'appareil pour chaque tentative de violation. Ceci, à son tour, permet à Apple d'introduire toute une série de défenses qui rendraient les tentatives de piratage peu pratiques.
Pour commencer, la fonction de dérivation de clé est conçue de telle maniÚre qu'il faudrait beaucoup de temps pour la calculer sur l'appareil. Plus précisément, Apple a choisi des paramÚtres de fonction de sorte qu'une seule clé de dérivation ait un délai d'environ 80 millisecondes. Ce délai ralentirait le piratage de mots de passe alphanumériques courts (environ 2 semaines pour un mot de passe alphanumérique à 4 caractÚres) et le piratage de mots de passe plus longs serait totalement impraticable.
Afin d'attĂ©nuer davantage les attaques par force brute sur l'appareil lui-mĂȘme, Apple a Ă©galement introduit un dĂ©lai incrĂ©mentiel entre les tentatives successives de devinette de mot de passe. Sur l'iPhone 5c, ce dĂ©lai a Ă©tĂ© complĂštement attĂ©nuĂ© via un logiciel. Enfin, Apple a autorisĂ© la possibilitĂ© d'effacer complĂštement toutes les donnĂ©es stockĂ©es sur l'appareil aprĂšs 10 tentatives infructueuses pour rĂ©cupĂ©rer le mot de passe. Cette configuration, associĂ©e Ă des retards induits par le logiciel, a rendu le piratage du mot de passe sur l'appareil lui-mĂȘme plutĂŽt peu pratique.
RETARD ENTRE TENTATIVES
- [1-4]> Aucun
- [5]> 1 minute
- [6]> 5 minutes
- [7-8]> 15 minutes
- [9]> 1 heure
Sachant cela, il est beaucoup plus raisonnable de supposer que le FBI n'a pas été en mesure de déchiffrer le cryptage de l'appareil.
S'ils avaient pu extraire la clĂ© UID, ils auraient pu utiliser le matĂ©riel (spĂ©cialisĂ©) nĂ©cessaire, afin de trouver rapidement de nombreux mots de passe, ce qui leur aurait probablement permis de trouver le bon mot de passe. Cependant, Ă©tant donnĂ© que la clĂ© UID ne peut pas ĂȘtre extraite via un logiciel ou un micrologiciel, cette option est exclue.
En ce qui concerne le piratage du mot de passe sur l'appareil, les délais induits par le logiciel entre les tentatives de saisie du mot de passe et la possibilité de supprimer toutes les données sur l'appareil ont rendu l'option peu pratique. Cela exclut la possibilité de contourner les protections logicielles.
Revenons à la question à l'étude - nous pouvons voir qu'Apple a intelligemment conçu son schéma FDE d'une maniÚre qui le rend trÚs difficile à déchiffrer.
via