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
