Existe-t-il un exemple réel de récupération de données SSD?
La suppression sécurisée des données est connue pour être plus compliquée et insaisissable sur un disque SSD que sur un disque dur standard. Par exemple, le mappage de bloc logique sur le SSD couche de traduction flash rend impossible l'écrasement fiable de secteurs de mémoire spécifiques comme vous le feriez pour effacer un disque dur.
Je cherche un exemple concret (pas une preuve de concept) pour illustrer le problème. Y a-t-il un cas notable où quelqu'un, de préférence des forces de l'ordre, a profité des propriétés d'un SSD pour récupérer des données effacées qui auraient probablement été irrécupérables sur un disque dur?
Ma toute première pensée:
Personne ne peut être absolument sûr que quelque chose ne s'est pas produit, donc la seule réponse acceptable à votre question serait un exemple. J'essaie d'expliquer mes réflexions sur les raisons pour lesquelles il est très peu probable que vous obteniez un tel exemple. Mon argument est inspiré par équation de Drake .
Permettez-moi de commencer par certains faits sur lesquels je pense que nous sommes tous d'accord (plus ou moins, espérons-le):
- La récupération des données d'un SSD effacé peut être effectuée (théoriquement et pratiquement).
- Le faire est loin d'être facile, cela demande des connaissances, des ressources, peut-être du temps.
Comme pour toute attaque, nous avons trois paramètres à considérer:
- compétence requise
- ressources nécessaires
- motivation
Quelles sont les chances que les forces de l'ordre disposent de compétences et de ressources disponibles? NSA, Mossad, KGB - bien sûr. Un service de police "ordinaire"? Ils peuvent probablement le faire s'ils sont en mesure de convaincre quelqu'un que c'est assez important et qu'il n'y a pas d'autre moyen. Ce n'est certainement pas de la "routine".
C'est là que nous parlons de motivation. Pour être motivé (assez), les choses suivantes doivent être vraies:
- Certains "suspects" doivent avoir stocké des données sur un SSD. (Pas un disque dur, pas une disquette ...)
- Quelqu'un - pour une raison quelconque - a décidé d'essuyer ce SSD. (Cela prend un peu de temps et d'efforts et devrait donc être fait avant la police sonne à votre porte.)
- Le SSD ne doit pas avoir été protégé par d'autres moyens tels qu'un cryptage fort. (Notez que, à ce stade, nous avons une personne qui non seulement connaît l'essuyage d'un SSD, mais l'a fait parce qu'il savait que ses secrets pourraient être compromis autrement. Il est certainement possible, bien que très peu probable, qu'une telle personne n'ait pas utilisé cryptage en premier lieu.)
- Les forces de l'ordre doivent savoir ou au moins supposer qu'il y a "quelque chose" à trouver sur ce SSD particulier. (Sinon, ils ne regarderaient pas.)
- Le crime dont nous parlons doit avoir été considéré comme "suffisamment important".
- Il n'y avait pas d'autre moyen d'obtenir les données ou il n'y avait pas suffisamment d'autres preuves contre le suspect.
Donc, finalement, nous sommes suffisamment motivés. Il y a encore plus à considérer:
- Toute l'opération doit avoir été effectuée avec succès.
- L'opération doit avoir été documentée et rendue publique.
Je pense que si nous multiplions toutes ces chances, nous obtenons une chance très, très proche de zéro, qu'il y aura la preuve que quelque chose comme ça a jamais été fait avec succès.
La récupération n'est possible que sous certaines conditions:
- avoir un SSD plus ancien sans prise en charge TRIM ou
- avoir Windows XP (car il ne prend pas en charge TRIM) ou un autre ancien système d'exploitation sans prise en charge TRIM ou
- vous connectez le SSD en tant que disque dur externe via le port USB. ou
- Les interfaces AHCI/SATA ne sont pas détectées dans votre ancien MB - vous utilisez le mode hérité/mode IDE ou
- vous avez une configuration RAID 0
Ce sont des cas heureux. Tout logiciel décent pourra récupérer vos fichiers.
Le cas le plus rencontré aujourd'hui est celui où vous avez un nouveau SSD avec TRIM activé. Dans ce cas, la récupération de données est un no-go, car lorsque TRIM est activé, l'action d'effacement est effectuée immédiatement. TRIM va purger à la fois les données et le lien vers celles-ci, donc pratiquement, elles ont disparu; il est simplement décontaminé et vide, signalé comme prêt à l'emploi.
Dans certaines situations, le lecteur à chiffrement automatique (SED) et l'effacement sécurisé ATA se sont avérés ne pas fonctionner, tout comme le chiffrement Bitlocker. Dans une telle situation, les données sont également récupérables. Mais dans le cas d'un lecteur entièrement crypté avec un outil fiable tiers, rien ne sera récupérable.
Les disques SSD modernes utilisent SED (Self-Encrypting Drive) pour un effacement sécurisé, en particulier via la fonctionnalité ATA Enhanced Security Erase présente sur de nombreux disques. Les lecteurs stockent une clé de cryptage dans une zone spéciale du lecteur et l'utilisent pour crypter de manière transparente tout ce qui y est écrit. Lors de l'envoi de la commande d'effacement de sécurité, plutôt que d'écrire individuellement sur chaque cellule flash, le lecteur efface en toute sécurité la clé SED, rendant ainsi toutes les données du lecteur inutiles. La spécification Opal requiert que ces disques utilisent un générateur de nombres aléatoires matériel pour la génération de la clé. Cela rend l'analyse de la difficulté du problème beaucoup plus simple, car vous n'avez pas à vous soucier autant de phénomènes physiques complexes pour du matériel hautement propriétaire. Au lieu de cela, vous devez analyser la qualité du RNG qui peut ou non donner des résultats positifs.
L'avantage, pour les défenseurs, est qu'une clé est générée par un générateur de nombres aléatoires matériel non déterministe testable et de haute qualité, le lecteur étant crypté avec un algorithme puissant et bien étudié. L'avantage pour les attaquants est que la récupération des données nécessite de trouver une clé. C'est mieux pour eux s'il faut, disons, 6 mois pour casser la clé d'un HWRNG mal conçu que s'il faut 6 mois pour récupérer un kilo-octet de données du stockage.