Connexion
Abonnez-vous

Chiffrement : BitLocker contourné par un hacker grâce à une ancienne faille

Microsoft « coincée »

Chiffrement : BitLocker contourné par un hacker grâce à une ancienne faille

Crédits : JJ Ying (Unsplash)

Un hacker a prouvé qu’il était possible de contourner la protection BitLocker de Windows en utilisant une ancienne faille insuffisamment corrigée par Microsoft. L’exploitation réclame un accès physique, mais reste valable dans le cadre d’une attaque ciblée.

Le 03 janvier à 15h05

BitLocker est un mécanisme apparu avec Windows Vista proposant un chiffrement intégral du disque. S’il était initialement réservé aux éditions Pro, il est maintenant disponible dans toutes les éditions de Windows 11. Sur les machines les plus récentes, il est même activé par défaut, une décision de Microsoft qui avait communiqué à ce sujet en mai dernier. Cette bascule s’est produite avec les installations neuves de Windows 11 équipées de la dernière mise à jour majeure 24H2.

Le chiffrement est basé sur XTS-AES 128 ou 256 bits. Il permet en théorie de protéger les informations stockées sur le disque en imposant la possession d’une clé pour les déchiffrer. Cette clé est stockée dans la puce TPM (version 1.2 minimum). Elle doit faire l’objet d’un soin particulier dans le cas d’une réinstallation de Windows, pour ne pas perdre ses documents et autres fichiers personnels, comme nous l’indiquions l’année dernière.

Cette protection n’est cependant pas absolue. En février 2024, un youtubeur – Stacksmasher – avait montré comment il avait pu contourner BitLocker avec moins de 10 dollars de matériel. La démonstration était impressionnante, mais tablait sur une configuration spécifique. Il fallait en effet que l’ordinateur dispose d’un connecteur LPC (Low Pin Count) disponible, ce qui était le cas sur d’anciens portables de Lenovo. Le problème était également connu et documenté par Microsoft.

Le hacker Thomas Lambertz a cependant montré il y a quelques jours que l’on pouvait accéder aux informations sans cette technique, même si l’accès physique reste obligatoire.

Une vieille faille remise au goût du jour

Le 28 décembre, Thomas Lambertz a montré sa méthode lors du Chaos Communication Congress qui s'est tenu récemment au Chaos Computer Club (CCC), souvent présenté comme le plus grand club de hackers en Europe.

Sa technique se base sur une ancienne faille, CVE-2023-21563, également surnommée « bitpixie ». Dans la fiche de Microsoft, elle apparait comme corrigée en janvier 2023. Accompagnée d’un score CVSS (3.1) de 6.8, sa dangerosité était réglée sur « importante ». Exploitée, elle aurait permis un contournement de BitLocker et donc un accès aux données, même si elle réclamait un accès physique.

Dans sa démonstration, Lambertz explique que cette faille pouvait toujours être exploitée, la correction n’ayant pas couvert tous les angles. Pour cela, le hacker a réorienté le mécanisme Secure Boot pour lui faire lancer un chargeur d’amorçage (bootloader) obsolète pour Windows. Le chargeur a pour mission d’extraire la clé de chiffrement en mémoire, permettant à un système Linux installé de la récupérer.

La procédure est la suivante :

  • Créer une clé USB bootable, dont l’espace de stockage est supérieur à la quantité de RAM sur l’ordinateur ciblé
  • Redémarrer brutalement l’ordinateur pendant le démarrage de Windows, avant que l’écran de connexion ne s’affiche, afin que la clé de chiffrement soit chargée en mémoire
  • Démarrer depuis la clé USB puis charger un shell UEFI personnalisé, afin de pouvoir exécuter des outils qui réaliseront des dumps (fichier de vidage) de la mémoire
  • Analyser les dumps avec des outils comme xxd et searchMem pour localiser la clé de chiffrement dans des zones spécifiques

L’exploitation de cette faille n’est possible que parce qu’une correction complète exige une modification de l’UEFI. Microsoft aurait été « coincée » par les limitations de l’espace de stockage dans ce composant crucial.

Dangerosité variable

Toute la question est de savoir à quel point la technique utilisée par Thomas Lambertz est dangereuse. Dans l’absolu, elle l’est : BitLocker est contourné et les informations auparavant chiffrées peuvent être lues. Il y a cependant deux conditions importantes. D’une part, un accès physique à la machine, ce qui est loin d’être une garantie, d’autant qu’il faut disposer du temps pour réaliser les manipulations. D’autre part, un accès au réseau, via un adaptateur USB autorisant le démarrage PXE.

Il est probable que les utilisateurs classiques ne soient pas en danger. En revanche, les entreprises, les administrations et les gouvernements – particulièrement les membres haut placés – devraient y voir un risque. Si l’opération ne peut pas être réalisée discrètement, le vol de l’appareil reste envisageable. Dérober l’ordinateur portable d’une personnalité peut amener à des informations sensibles, voire classifiées.

La correction complète n’est pas simple

Pour corriger le problème, il faut attendre une solution plus durable que le correctif proposé par Microsoft il y a maintenant deux ans. Malheureusement, cette correction complète requiert un remplacement des certificats de sécurité, dont la révocation n’est pas possible de manière simple.

Selon Thomas Lambertz, l’éditeur est conscient du problème, mais est dans une position délicate, puisque « chaque mise à jour de micrologiciel qu'il ne prévoit pas correctement pourrait casser BitLocker. C'est pourquoi ils ne le font pas ».

Que faire pour se protéger ? Il y a peu de méthodes réellement fiables. Si les PC Windows exploitant BitLocker sont gérés par un administrateur, l’activation de la règle ajoutant un code PIN pour déverrouiller BitLocker est une étape importante. Mais pour le hacker, il n’existe qu’une seule façon de bloquer le problème à la racine : « La seule chose que vous puissiez faire pour empêcher cette attaque est de désactiver la pile réseau complète dans le BIOS. De cette manière, le démarrage PXE n'est pas possible, quel que soit l'appareil branché ».

En attendant, la technique du hacker est efficace sur toute machine Windows 11 à jour. Microsoft n'a pas réagi pour l'instant à ces découvertes, mais a été tenue au courant des avancées par Thomas Lambertz.

Commentaires (45)

votre avatar
J'ai un mot de passe pour déverrouiller mon Windows à chaque redémarrage, ça devrait être bon non?
Et le démarrage PXE n'est de toute façon pas possible.

J'ai aussi un mot de passe à mon UEFI, il faut clear pour y avoir accès, et donc effacer la clef du TPM.
Je devrais être safe, je pense.
votre avatar
Le mot de passe Windows n'a pas de rapport avec le chiffrement du disque :)

Si on branche ton disque dans une autre machine, même avec ton mdp on accède aux fichiers (si pas chiffré bien sûr).

Après, je pense que le particulier est plutôt tranquille avec cette faille ^^
votre avatar
Je ne parles pas du mot de passe Windows.
J'ai fais en sorte que Bitlocker me réclame un mot de passe avant de déchiffrer l'OS.
Comme avec le PIN, mais en mot de passe.
votre avatar
Ah oui ok, j'avais mal compris :)
votre avatar
Le système de fichier NTFS ne permet pas de garder les droits de lecture écriture ? L'ouverture sur Linux d'un système de fichier NTFS fait sauter les droits ?
votre avatar
Tu peux changer le propriétaire des données, si tu es admin de l'OS où se trouve le disque dur, et donc récupérer les droits.
votre avatar
Linux doit en général ignorer les droits, sous Windows, tu peux les faire sauter, te débrouiller pour avoir un accès SYSTEM, utiliser un compte avec des droits "backup", ou encore d'autres trucs (les méthodes d'accès aux fichiers en Kernel ne vérifient pas les permissions par exemple)
votre avatar
Sur les systèmes unix-like, root ("dieu") peut attribuer/modifier les permissions comme bon lui semble.
Le compte root dispose de privilèges bien supérieurs à ceux d'un compte "administrateur" sous Windows.

Certaines techniques permettent, dans une certaine mesure, de limiter ce qu'il est possible de faire avec les privilèges root/wheel (notamment pour lutter contre les 0-day), et la bonne pratique est de désactiver le compte root et de contrôler les élévations de privilèges des comptes administratifs.

TL;DR : avec les bons privilèges, tu fais ce que tu veux avec un Linux, y compris saborder le système lui-même. C'est une des raisons pour lesquelles c'est fun.
votre avatar
Le compte root dispose de privilèges bien supérieurs à ceux d'un compte "administrateur" sous Windows.
Tout à fait. La raison est simple : un compte administrateur Windows, c'est l'équivalent d'un compte utilisateur avec droits d'administration (groupe sudo/wheel sous Linux).

Le compte root de Windows, c'est l'utilisateur SYSTEM. Et il est "désactivé" (dans le sens, impossible de s'authentifier directement sous cet utilisateur.)
la bonne pratique est de désactiver le compte root et de contrôler les élévations de privilèges des comptes administratifs.
Je vais en faire crier plus d'un, mais Windows le fait de base ^^ :mdr:
votre avatar
un compte administrateur Windows, c'est l'équivalent d'un compte utilisateur avec droits d'administration (groupe sudo/wheel sous Linux).
Windows 10/11 me fait régulièrement suer en me disant que je n'ai pas le droit de faire ci ou ça, quand je me connecte en administrateur.
Avec sudo ou su sous linux, je fait tout ce que je veux et j'en assume pleinement les conséquences potentielles.

Un compte administrateur n'est pas l'égal d'un compte avec les droits sudo, et de loin.

Les deux concepts sont donc proches mais pas équivalents.
Je vais en faire crier plus d'un, mais Windows le fait de base ^^
Cette pratique est généralisée depuis bien longtemps sur tous les OS desktop et même serveur. Même raspbian le fait depuis ses débuts. A part te dire « c'est cool », je ne vois pas matière à régir.
votre avatar
Un droit sudo ne veut rien dire en soit, car les droits accordés vont dépendre de la configuration. Tu peux autoriser toutes les commandes, comme en limiter les usages. C'est un outil très puissant.

Au contraire de su, qui lui te donne véritable le droit root en ouvrant un shell.

Pour les os dektop et serveur qui font ça de base, ce n'est pas ce que je constate de mon côté. C'est une bonne pratique, je suis entierement d'accord, mais elle n'est pas généralisée.
votre avatar
Microsoft « coincée »
Ils ont failli de corriger correctement la faille

pour empêcher cette attaque est de désactiver la pile réseau complète dans le BIOS. De cette manière, le démarrage PXE n'est pas possible, quel que soit l'appareil branché
Et mettre un mot de passe pour empêcher l’accès à l'UEFI sinon la pile réseau peut être réactivité en accédant à l'UEFI ?
votre avatar
On peut désactiver le réseau sur la partie PXE dans tous les bios moderne (sans couper le réseau tout court :)), avec un mdp UEFI, tu es tranquille je pense :p
votre avatar
Dommage que le PXE soit surtout utile en entreprise, et que c'est plutôt une entreprise/un haut placé qui va subir ce type d'attaque.
Mais effectivement pour un poste de particulier, je ne vois pas l'intérêt d'avoir un boot PXE/Réseau activé par défaut.
votre avatar
La personne qui prépare le PC est "censée" virer le PXE dès qu'il n'y a plus l'utilité.
Du moins c'est ainsi qu'on fonctionnait dans mon administration tant qu'on s'en servait.
votre avatar
Oui, d'ailleurs certains constructeurs permettent de modifier le Bios en postinstall via des scripts pour justement paramétrer tout cela de manière automatique :) (HP par exemple)
votre avatar
Je me demande si on pourrait implementer un effacement des données au démarrage selon des critères prédéfinis : certificat, usb id, mdp, date.
Soyons fous, un court-circuitage du PC comme les bipers. Un kill switch avec de la thermite. :devil:
votre avatar
Ça m'a toujours semblé louche de voir que les boutons "reset" et raccourci clavier du genre ne s'attachent jamais à wiper la mémoire. Même si ici, c'est un peu différent. Ça reste le même principe.

Ça traine depuis les AtariST et les Amigas. C'est un peu beaucoup la non*.
votre avatar
Au niveau physique, la RAM il lui faut du temps pour se réinitialiser. Un clic-clac ne suffit pas.
Encore plus si elle est refroidie. Rechercher "cold boot attack" pour de plus amples renseignements :D
votre avatar
Ça je le sais.

Simplement ce genre de chose à part sur une coupure de courant pourrait être faite.

* Soit par l'OS lors de la séquence d'extinction. Kill du process et formatage de la plage mémoire concernée. Si le gestionnaire de tâche peut compter les octets, c'est qu'il sait où ils sont.
* Soit par l'UEFI au boot (ou même POST). Tu boot avec un slip propre en résumé.

On s'amusait déjà à l'époque à "détourner" le bouton reset des AtariST et Amiga pour le faire. C'est une "routine" par très compliquée à faire.
votre avatar
Je ne suis pas sûr de comprendre ce que tu veux faire réellement comme nettoyage de mémoire mais la première faille exploitée est que le bootloader Windows dans un cas d'erreur de supprimait pas la clé en mémoire. Microsoft supprimait donc (à par ce bug) la clé afin qu'elle ne soit pas récupérable.

À partir de là, ce qui est décrit ici est l'utilisation du chargement par PXE d'un bootloader toujours buggé alors que la "correction" de Microsoft a seulement consisté à faire un nouveau bootloader qui lui effaçait bien la clé mais sans que tout le processus du "secure" boot ne puisse empêcher de charger l'ancien bootloader.
Ensuite, il finit par charger un Linux lui-même avec une faille permettant de lire toute la mémoire physique et donc de retrouver la clé. Celle-ci étant précédée d'une chaîne de caractères précise et donc facile à trouver.
votre avatar
Je vais essayer de re-phraser.

Pour moi (mon opinion), un ordinateur qui démarre doit le faire avec une mémoire propre.
Donc pour éviter toutes éventualités de quoi que ce soit. Au moment où le dispositif sait accéder à la RAM, il devrait écrire du zéro partout (hors zones protégées bien sur!). Pour ainsi dire.

Idem pour un ordinateur qui arrive en fin de la séquence d'extinction. L'OS devrait faire le ménage.

Il fut un temps où le BIOS testait la mémoire. Un bon vieux "write/read" des familles. Tout le monde désactivait la fonction parce que c'était un peu lent. Aujourd'hui, nous n'avons plus ce problème. C'est très rapide quand bien même les volumes de RAM ont explosé. Techniquement parlant, je ne vois pas ce qui empêcherait une mise à blanc de la RAM.

J'ajouterai que les programmeurs et les développeurs devraient faire un peu mieux le ménage aussi. Et sans oublier les langages informatiques eux-mêmes. Ce n'est pas comme si c'était automatique. On saluera quand même le "Garbage Collector" qu'on trouve en POO.

Rien que "faire le ménage" simplement, permet d'éviter une sacrée tonne de problème du genre "left over exploits".

Il faut le visualiser comme la réalité. Si le chat a lâché une poire sur le tapis, cela se voit. La RAM c'est pareil à une maison... Bon là, ce sera une vision d'horreur. Disons que le chat a le volume d'un mammouth. Mais au moins, on en prend conscience.
votre avatar
Voilà pourquoi je n'ai confiance qu'en des technologies de chiffrement open source !
votre avatar
Soupir..... Déjà des failles, il y en a partout. Y compris dans l'open source.
Ensuite pour la faille en question, déjà il faut un accès physique au pc,et il faut certaines connaissances.
Et si tu ne travailles pas pour une agence de contre espionnage ou dans le nucléaire, tu peux dormir tranquille.
C'est pas cette news qui me fera remplacer bitlocker par autre chose.
votre avatar
Au delà de la faille, on ne peut pas faire confiance à BitLocker ! Non pas parce que c'est du Microsoft mais simplement parce qu'il existe un principe fondamental en cryptographique que l'on nomme le principe de Kerckhoffs, principe qui consiste à dire que la sécurité d'un système crytographique doit reposer uniquement sur sa clé. Et par corollaire, offuscation de l’algorithme eet de son implémentation n'ajoute pas une sécurité supplémentaire. Pis, et a été déjà démontré à mainte reprises que ça finit toujours pas être cracké.

Si Microsoft (mais d'autres) veulent un système de chiffrement sécurisée, le code source doit pouvoir être librement accessible et reproductible.
votre avatar
Wikipédia :
Le principe de Kerckhoffs n'implique pas que le système de chiffrement soit public, mais seulement que sa sécurité ne repose pas sur le secret de celui-ci.
Le principe du chiffrement de Bitlocker est connu, que le code ne soit pas publié est accessoire. C'est d'ailleurs pour cela que la démonstration utilise Linux pour une fois la clé trouvée monter le disque sous Linux et que celui-ci est lisible.
votre avatar
Je cite Wikipedia (version anglaise) : "The principle holds that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge."

Ce qui, selon moi, implique que même si je dérobe le code source de BitLocker et le publie ouverte, la sécurité de celui-ci ne sera pas comprise car il repose sur la clé. Par conséquent, pourquoi Microsoft ne le rend-t-il pas publique ? Le chiffrement est connu c'est de l'AES. Le Cipher block, de l'XTS et la taille de la clé est connu (mais si à cette égard j'ignore si la taille de la clé donnée est avant ou après application de l'XTS).

J'ignore la citation original de Kerckhoffs, et de fait quelle page wiki est correct. En revanche, l'évolution des conflits et le role de la cryptographique a évolué depuis Kerckhoffs.
Et je pense que la version "moderne" formulée par Shannon (celui de l'entropie de l'information) : "The ennemy knows the system" est plus approprié (non pas parce qu'elle appuie mon argument, mais parce qu'elle se trouve plus réaliste de nos conflits modernes).
votre avatar
Ms ne le rend pas public parce que ses clients ne le demandent pas en masse. La plupart des clients s'en moquent: ils ne règlent pas les problèmes via une revue de code mais via des pénalités et des avocats.
Et ces clients pourraient voir d'un mauvais oeil que Ms publie le code source.

Les deux mondes opensource/closed source doivent cohabiter.

Par ailleurs, Ms a un avantage: la doc. Ms documente encore plutôt bien (je trouve moins bien qu'avant mais bon, c'est toujours plus facile à trouver que la doc linux utilisable et à jour).

Ms ne publie pas de code, mais ils sont transparents sur énormément de points y compris techniques. C'est une autre conception.
votre avatar
J'aimerais voir ses clients français qui règlent leur problème d'espionnage économique de Microsoft ou alors de défauts de sécurités en envoyant des avocats. Pour les US je suis d'accord. Mais en France j'ai des doutes... Entre le coup des avocats, le gain a obtenir, la durée des procédures, le ping-pong juridiques et voir pis, le politique qui rentre dans la danse je vois pas comment une boîte française peut s'en tirer avec un gain favorable.

De mon trou de serrure, ce genre de clauses contractuelles sont là pour les commerciaux pour rassurer leur client, mais en sachant parfaitement qu'elles ne seront jamais utilisés.

Et encore une fois, si ça ne pose pas de problèmes à Microsoft pourquoi, moi client de Microsoft ayant une licence MS, je me fais rejeter par le service client quand je demande ? Si MS n'a rien à cacher pourquoi il ne montre pas le code en faisant une simple demande ?

Quand aux clients qui n'apprécierait pas, ceci se règle avec du marketing & de la com'. Ce genre de clients n'a pas les notions requises (en interne) pour comprendre ce genre de choses techniques, donc qu'ils se contente de ce qu'ils peuvent comprendre : " la com' ".


Pour la doc MS je ne sais pas vraiment ne l'ayant pas pratiqué énormément. Celle de Linux est plus technique et a un ticket d'entrée plus haut. Mais au moins, on peut prendre une décision éclairé. Quand à l'utilisation de la doc, pas de soucis ni à trouver une version à jour. Mais je n'ai probablement pas les même usages et besoins de que toi.
votre avatar
pourquoi, moi client de Microsoft ayant une licence MS, je me fais rejeter par le service client quand je demande ?
Directed by Quentin Inventino
Si MS n'a rien à cacher pourquoi il ne montre pas le code en faisant une simple demande ?
Dans le monde entier, la pratique courante est bien entendu de livrer son IP à n'importe qui, juste parce qu'un "client" le demande, c'est bien connu...

Sinon, comme tu l'indiques, tu as une licence, et elle ne te permet tout simplement pas l'accès au code. Il existe des programmes qui permettent d'avoir accès au code, dans des cas spécifiques : intégrateurs, états, cross-development ...
votre avatar
On parle pas du kernel, de Recall ou autres. On parle d'un système cryptographique. Si Microsoft refuse cet accès à un client, alors c'est de la sécurité par l'obscurité et dès lors c'est contraire au standard de cryptographie moderne (Schneier a publié à ce sujet à de nombreuses reprises), et par conséquent la sécurité du système peut-être légitimement questionné.

Que la licence m'interdise des choses (code source de Recall, insertion de clé TPM...) oui me parait logique au regard de la stratégie lock-in de Microsoft. Mais pour un système cryptographique qui visent à sécuriser mes données, c'est exactement le contraire que ça fait.

Il n'y a aucune raison valable à rendre opaque un système cryptographique quand on prétend concevoir/utiliser un tel système pour protéger des données, que ce soit pour des civils, des militaires ou des industriels.
votre avatar
Il n'y a aucune raison valable à rendre opaque un système cryptographique quand on prétend concevoir/utiliser un tel système pour protéger des données, que ce soit pour des civils, des militaires ou des industriels.
Vraie question, tu as des noms de fournisseurs de tels systèmes propriétaires qui publient publiquement l'IP associée ?

La raison que je vois : cela ne fait pas parti de la licence que tu as acheté, l'accès au code source se paye dans d'autres niveaux de licences / programmes.
votre avatar
C'est exactement ce que je pense 🙂
votre avatar
De toutes façons tout se pirate.
Après bitlocker existe depuis... 15 ans ?
Et jusqu'ici personne ne s'est fait pirater un pc avec bitocker. Les 2 ou 3 failles que j'ai vu passé depuis 15 ans, il faut un accès physique au pc et avoir les connaissances nécessaires.
votre avatar
Bitlocker est justement fait pour protéger les données d'une machine ou d'un disque auquel on a un accès physique.

Il faillit donc à sa tâche ici.
votre avatar
En effet des failles en a partout, ça reste quand même plus rassurant quand c'est open source.
votre avatar
La faille n'est pas dans la technologie de chiffrement mais dans un bootloader de Windows ancien que l'on peut toujours utiliser en appliquant la technique expliquée au CCC. Elle permet de récupérer la clé de déchiffrement.

Une fois une clé de déchiffrement récupérée, n'importe quel système de chiffrement est vulnérable.

S'il y a une technologie à critiquer ici, c'est le secure boot et sa complexité ainsi que le fait qu'il ne puisse pas invalider le bootloader avec la faille faute d'assez d'espace de stockage. On peut aussi critiquer Linux, logiciel open source s'il en est dont certaines versions signées par MIcrosoft permettent à cause d'une faille de récupérer la clé en lisant toute la mémoire physique, mais l'auteur de la présentation répond à une question en indiquant qu'il est aussi possible d'utiliser des outils Windows pour récupérer la clé.
votre avatar
open source c'est encore pire, la disponibilité du code source va faciliter la recherche de failles
votre avatar
Et elles seront corrigées d'autant plus vite. Mais bon, ici, la faille principale est dans du logiciel propriétaire. On voit que l'ont ait accès au code source ou pas ne change pas grand chose.
votre avatar
Sauf que là, on parle d'une faille corrigée - mais ressucitée...
votre avatar
Elle n'a pas été correctement corrigée puisqu'il est toujours possible d'utiliser le bootloader qui contient la faille. Ils ont juste publié un nouveau bootloader qui efface la clé dans un cas où ils ne l'avait pas fait. Ils n'ont pas rendu impossible le chargement du bootloader qui contient la faille. Moi, je n'appelle pas ça un secure boot si on peut toujours utiliser un logiciel que l'on connaît comme non sûr puisqu'il permet de récupérer la clé de déchiffrement.
C'est toute la conception du secure boot qu'il faut refaire pour blacklister tous les logiciels avec faille de sécurité.
votre avatar
Normalement c'est fait depuis Avril 2024 :)
techcommunity.microsoft.com Microsoft
Mais l'implémentation est un peu fastidieuse et n'est pas forcée pour l'instant.
votre avatar
@fred42 à raison cela permet de corriger les faille très vite, avec la garantie qu'il n'y ait pas de bac d'or.
votre avatar
Pas de backdoor dans l'opensource??? C'est pas parce qu'il y en a quelques unes qui ont été déjouées (mail sur BSD, sudo, openssl, php) qu'aucune autre n'existe.

D'ailleurs dans le dev opensource python, il y a en permanence des alertes de crypto et autres sur des librairies rogues.
votre avatar
Au final, le plus gros danger, ça reste le fait de pouvoir booter sur USB.
Je ne suis pas sûr que ça marche sur mon ordi (j'ai laissé le chiffrement mémoire, et à priori la clé est jetée au boot) - mais quand on boot sur USB, on pourrait vider la RAM quand même.
Qu'on ne le fasse pas sur un boot à chaud sur un disque interne, soit. Qu'on ne la vide pas (alors que ce ne serait pas si difficile puisqu'on peut la vider en parallèle) sur un boot depuis un device externe... C'est douteux.

Chiffrement : BitLocker contourné par un hacker grâce à une ancienne faille

  • Une vieille faille remise au goût du jour

  • Dangerosité variable

  • La correction complète n’est pas simple

Fermer