Je ne suis pas un expert en la matière, c'est juste une analyse du dossier selon mes connaissances limitées.
L'ENCRYPTION d'Android
Android prend en charge deux modes de cryptage ; FDE y FBE . FDE crypte le dispositif de bloc entier, c'est-à-dire userdata partition en utilisant le noyau de Linux dm-crypt tandis que la FBE est basée sur fscrypt disponible depuis Android 7. Du point de vue de la récupération des données, l'approche est similaire pour les deux. Les deux offrent un cryptage fort et ce qui a été attaqué par les pirates n'est pas le cryptage lui-même, mais le mécanisme d'Android pour créer et stocker les clés nécessaires au décryptage.
parfois il y a un problème lors de l'activation du cryptage laissant une partie du stockage non crypté
Vous avez raison, c'est intéressant. FDE, AFAIK, crypte l'ensemble du dispositif de blocs, à l'exception du crypto footer à la fin de la partition qui inclut les clés de décryptage. Initialement, tous les secteurs peuvent ne pas être cryptés comme c'est le cas avec le cryptage en place :
vold vérifie si un secteur est utilisé avant de le lire et de l'écrire, ce qui rend le cryptage beaucoup plus rapide sur un nouveau périphérique qui contient peu ou pas de données.
Mais les secteurs ignorés sont ceux qui ne contiennent aucune donnée dans le système de fichiers. Cependant, au fur et à mesure que les données sont écrites dans les secteurs (ou si le cryptage a été initialisé avec des données aléatoires, ce qui ne semble pas être le cas avec Android), elles sont cryptées et très vite, le bloc entier devient un bloc géant de données à haute entropie sans structure visible. Il est impossible de distinguer les données cryptées du bruit aléatoire. TRIM Toutefois, si supporté par par le matériel, le noyau, le système de fichiers et le système d'exploitation, peut révéler l'espace vide dans le système de fichiers. Mais la lecture de cet espace ne renvoie que des zéros.
LES MÉTHODES POSSIBLES DE RÉCUPÉRATION DES DONNÉES
La récupération des données fonctionne généralement de deux manières :
- Lire uniquement le contenu du fichier par la méthode de découpage / recherche par signature
- Ou lire les fichiers complets avec les métadonnées (noms de fichiers, horodatages, permissions) à partir du système de fichiers.
Les méthodes possibles sont les suivantes :
- Lecture de la mémoire flash à travers le contrôleur de firmware (Flash Translation Layer) de l'eMMC en utilisant des APIs communément disponibles, par exemple du noyau Liux. C'est la FTL qui stocke les mappages entre LBA et PBA, ainsi que les informations relatives aux partitions, aux secteurs défectueux, aux données supprimées, etc. Cela peut être fait en exposant les partitions à un PC dans un mode bootloader si disponible, ou en utilisant un protocole de communication de niveau inférieur, par exemple JTAG ou par la méthode chip-off.
- Ou accéder directement aux cellules de silicium, ce qui n'est possible qu'avec un équipement sophistiqué que l'on trouve dans les laboratoires de police scientifique, et non sans la fiche technique du fabricant. Dans ce cas, seule la méthode de gravure est possible. Les données lues dans les cellules sont des octets aléatoires provenant de l'espace non partitionné et des 50+ partitions, y compris celles qui n'ont pas de système de fichiers. La probabilité de récupérer des données utiles est donc presque négligeable, en particulier pour les fichiers de taille raisonnable. Si les données sauvegardées sont cryptées (en utilisant FDE, FBE ou toute autre méthode), les chances avec cette méthode sont nulles à coup sûr.
Le choix de la méthode dépend de plusieurs facteurs, comme le but recherché :
- Pour récupérer des données supprimées
- Pour récupérer les données d'un téléphone mort
- Pour casser le mécanisme de cryptage, par exemple en cas d'expertise judiciaire, de vol de téléphone, etc.
La récupération des données peut se faire de deux manières :
- Sur l'appareil, par exemple en mode de récupération si l'appareil est déverrouillé et qu'un environnement de récupération personnalisé est disponible.
- Ou de l'appareil. C'est la seule option dans la plupart des cas car les appareils ont des chargeurs de démarrage verrouillés. Mais si votre appareil a été livré avec Android 5+, il y a de fortes chances pour qu'il ait supporté par le matériel Le cryptage est activé, ce qui rend presque impossible la récupération des données - même celles qui n'ont pas été supprimées - hors de l'appareil, sauf si l'on essaie de mettre en place un système de cryptage. hacks parce que vous ne pouvez pas force brute des clés RSA .
DÉVERROUILLAGE DU BOOTLOADER
En tenant compte de tous les faits ci-dessus et de votre situation, seule une approche sur l'appareil ou semi-hors ligne peut être tentée pour récupérer les données. Mais alors vient la partie de déverrouillage du bootloader.
Google exige des fournisseurs de SoC/OEM d'effacer complètement les données sur déverrouillage du bootloader :
En tant que meilleure pratique, les appareils Android déverrouillables doivent effacer de manière sécurisée toutes les données de l'utilisateur avant d'être déverrouillés.
...
Le défaut de mise en œuvre de ces protections est considéré comme une vulnérabilité de sécurité de niveau modéré .
Citation tirée de aquí :
Lorsque le fastboot flashing unlock La commande est envoyée...
...
une réinitialisation des données d'usine doit être effectuée pour empêcher tout accès non autorisé aux données.
En fonction de l'appareil, un BLKSECDISCARD , BLKDISCARD ou un écrasement complet avec des zéros est recommandé. Elle est ensuite suivie par la création du système de fichiers qui peut à nouveau poser des problèmes de TRIM . La même chose se produit lors d'une réinitialisation d'usine. userdata y cache les partitions sont complètement effacées (bien que la conformité dans le passé ait été mauvais ). Voir cette réponse pour plus de détails.
BLKDISCARD y FITRIM sont des IOCTL du noyau Linux qui émettent des commandes spéciales aux périphériques eMMC sous-jacents en fonction de leurs capacités. TRIM est émis par le système de fichiers vers le FTL, demandant l'effacement physique réel des blocs de données (LBA) qui ont été supprimés du système de fichiers. DISCARD est en quelque sorte TRIM pour le dispositif de bloc entier. TRIM ne touche évidemment pas les fichiers non supprimés, la structure du système de fichiers et la table de partition du disque. BLKDISCARD ne sauvegarde rien du tout sur le dispositif de blocage, y compris le pied de page cryptographique. Ces deux commandes appartiennent à Assainissement logique niveau de suppression sécurisée des données. Il en va de même pour ERASE émis par BLKSECDISCARD IOCTL, tandis que d'autres délivrés par le même - notamment SECURE TRIM , SECURE ERASE y SANITIZE - sont considérés comme des Assainissement numérique c'est-à-dire qu'ils provoquent un effacement encore plus sûr. Même un écrasement complet avec des zéros rendra les données irrécupérables - du moins sans faire fondre la eMMC - en raison de l'Overprovisioning et du Garbage Collection.
POSSIBILITÉ DE RÉCUPÉRATION DES DONNÉES
En résumé, ces commandes (si elles sont prises en charge par le matériel sous-jacent et, le cas échéant, par les pilotes fournis par les fournisseurs) ne laissent pas beaucoup de place à la récupération des données supprimées. Le cryptage ajoute au problème. Comme expliqué plus haut, le type de cryptage avec FDE est en quelque sorte un tout ou rien. Si même une petite partie du crypto footer est effacée pendant le déverrouillage du bootloader, oubliez le décryptage. Citation d'un ingénieur principal pour la sécurité d'Android ( réf. ) :
Si vous prévoyez de revendre ou de mettre au rebut votre appareil et que vous ne l'avez pas encore fait, cryptez-le, puis effectuez une réinitialisation d'usine.
Tout comme la suppression de l'en-tête LUKS sur Linux. Citation de la section des avertissements sur page officielle :
De loin, la plupart des questions posées sur la liste de diffusion cryptsetup proviennent de personnes qui ont réussi à endommager le début de leurs partitions LUKS, c'est-à-dire l'en-tête LUKS. Dans la plupart des cas, il n'y a rien qui puisse être fait pour aider ces pauvres âmes à récupérer leurs données.
Ainsi, sans le pied de page cryptographique qui contient la clé maîtresse cryptée, la clé RSA (liée au matériel) et d'autres informations relatives au cryptage, tout n'est que données aléatoires. Mais même si nous supposons que le crypto footer n'a pas été effacé dans votre cas et que le cryptage lié au matériel n'a pas été un obstacle non plus, les problèmes ne sont pas terminés. Avec dm-crypt FDE : une clé principale est utilisée pour crypter/décrypter les secteurs (512B chacun) individuellement lorsqu'ils sont écrits/lus respectivement (chaque secteur a son propre IV). Après le décryptage userdata partiton un nouveau périphérique de bloc virtuel est créé à /dev/block/dm-0 qui contient un système de fichiers, principalement ext4 .
Afin de monter le système de fichiers, les secteurs contenant la structure de base du système de fichiers doivent être intacts, par exemple le(s) superbloc(s), les entrées de répertoire, les tables d'inodes, les bitmaps d'inodes/blocs, le journal, etc. Il est pratiquement impossible que tout cela n'ait pas été écrasé lors du déverrouillage du bootloader et de la création du nouveau système de fichiers. L'ancien système de fichiers a donc disparu et il ne vous reste que la méthode de découpage qui a un taux de réussite très faible, notamment à cause de la fragmentation des gros fichiers. La plupart du temps, ce que vous obtenez, ce sont de petites vignettes sans nom ou des fichiers texte, et ce, après tant de suppositions.
CONCLUSION
Si le chargeur de démarrage est déverrouillé sur un appareil crypté, la probabilité de récupération des données semble très proche de zéro.
RELATED
