Connexion
Abonnez-vous

BitLocker contourné rapidement pour moins de 10 dollars ? Pas de panique

Ancien Lenovo ? Aïe

BitLocker contourné rapidement pour moins de 10 dollars ? Pas de panique

Un youtubeur a présenté une vidéo pour casser en moins d’une minute la protection BitLocker. Celle-ci assure le chiffrement complet du disque sous Windows. Si la démonstration est impressionnante, le danger est faible. Explications.

Le 09 février à 08h00

BitLocker est une solution de chiffrement de Microsoft. Elle est présente dans les éditions Pro et Enterprise de Windows depuis de nombreuses années. Il s’agit d’une technologie de chiffrement intégral du disque.

En théorie, si le périphérique de stockage est volé, les informations ne peuvent pas être lues sans posséder la clé de chiffrement. Un long code de récupération est donné à l’utilisateur à la première configuration. Il faut le préserver soigneusement sous peine de ne pas pouvoir déchiffrer les informations en cas de récupération.

BitLocker fonctionne de concert avec la puce TPM, chargée de stocker la clé de chiffrement ainsi que les registres de configuration. C’est là que le bât blesse : un youtubeur est parvenu à récupérer ces informations à l’aide d’un Raspberry Pi Pico, le tout en moins de 45 secondes.

Très peu de matériel nécessaire

Stacksmasher explique dans sa vidéo comment il a réussi à déchiffrer le disque d’un portable Lenovo. La puce TPM, externe, était reliée au processeur par un bus LPC (Low Pin Count). En se penchant sur cette configuration, le youtubeur s’est rendu compte que la communication entre la puce TPM et le processeur se faisant de manière non chiffrée. Était-il possible de récupérer la clé de chiffrement du volume de cette manière ?

Sur la machine Lenovo, l’un des connecteurs LPC était inutilisé, juste à côté de l’emplacement M.2 pour le SSD. Il a donc utilisé un Raspberry PI Pico à moins de 10 dollars pour l’y connecter. Il a ensuite récupéré la suite de 0 et de 1 émise par la puce au démarrage de la machine pour reconstituer la clé. Cette dernière en poche, il a pu déchiffrer l’intégralité du contenu du disque et accéder aux données.

Tant qu’à faire, Stacksmasher a mis à disposition le code source (sous licence GPL3) de la petite application développée pour récupérer la clé de volume.

Faut-il s’en inquiéter ?

A priori, la situation est sérieuse. Faut-il paniquer ? Pas forcément.

D’abord, Stacksmasher explique que cette technique vise avant tout les portables Lenovo, qui ont eu pendant longtemps la fâcheuse habitude de laisser un connecteur LPC libre pour le débogage. À cela, il faut ajouter que les ordinateurs vendus depuis ces dernières années n’utilisent plus de puce matérielle externe et physique. Dans la grande majorité, elle est logicielle et gérée directement par le processeur. La fonction s’active ou se désactive dans le BIOS. Auquel cas l’attaque ne peut plus fonctionner.

Ensuite, bien que la méthode requière peu d’investissement et ne prenne que peu de temps dans l’absolu, il faut avoir un accès exclusif à la machine, sans que la victime s’en doute. Il faut également les connaissances techniques et le temps nécessaires, surtout si c’est la première fois.

Si vous avez une machine raisonnablement récente, d’une autre marque que Lenovo et que vous ne la laissez pas longtemps sans surveillance, vous êtes à l'abri.

Précisons aussi que la méthode n’est pas nouvelle, comme Stacksmasher l’indique lui-même sous sa vidéo. Le problème du bus LPC est connu depuis longtemps, comme le montre ce billet datant de 2019, qui prouvait que le mécanisme fonctionnait aussi avec les puces TPM 2.0.

Microsoft en parle d'ailleurs dans une fiche technique. L'éditeur propose d'ailleurs des contre-mesures, comme la création d’un code PIN, qui ne peut malheureusement se faire que par une stratégie de groupe. On peut aussi choisir, à l'activation de BitLocker, de stocker la clé de volume sur une clé USB. Il faudra alors être très vigilant sur le stockage de cette dernière.

Les Mac ne sont pas concernés

On peut se poser légitimement la question : les Mac sont-ils concernés ? Après tout, les ordinateurs d’Apple proposent, eux aussi, une solution de chiffrement intégral du disque, FileVault.

La comparaison s’arrête là cependant. Les Mac n’utilisent pas de puce TPM. Il y a une autre différence de taille : sur un Mac, le mot de passe de la session est obligatoire pour lancer le déverrouillage des données. Sur PC, la clé est transmise automatiquement au démarrage du système.

Commentaires (50)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Petite précision: pour mettre un pin code, il faut effectivement une stratégie de groupe, mais ça peut se faire sur un ordinateur autonome sans active directory avec gpedit


Ensuite, rajouter un code pin c'est juste
manage-bde -protectors -add c: -TPMAndPIN
votre avatar
À noter tout de même que les stratégies de groupe ne sont pas dispo sous les versions « Home » de Windows. Il faut être sous une version Pro ou Entreprise. Bon après il me semble qu’il existe des outils pour ajouter la fonctionnalité aux éditions Home de Windows pour ceux qui veulent bidouiller.
votre avatar
Bitlocker n'est pas présent dans les editions Home donc je ne pense pas que l'absence de la solution soit gênante comme le problème n'est pas présent
votre avatar
Bien vu... je m'en vais me recoucher :mdr:
votre avatar
Il me semble que cela a changé avec Windows 11 (je confirme que sous les versions antérieures, il n'y a pas de Bitlocker sur les versions famille).
votre avatar
On peut aussi configurer pour avoir un mot de passe à la place du PIN. Par contre petite subtilité, le clavier de saisie du mot de passe au démarrage est en qwerty donc quand on saisit le mot de passe a la configuration en azerty il y a un petit souci.
votre avatar
Edifiant... Maintenant, la clef ne doit être délivrée qu'assez tardivement dans le démarrage de l'UEFI. Je dirais peu avant l'étape BDS (Boot Device Selection).

A voir si, selon les BIOS, mettre un mot de passe de boot et accès aux settings passe plus tôt dans le démarrage et qu'un clear généralement accessible ou en retirant la pile RTC invalide des mesures faites plus tôt sur les reboot ultérieurs... et aucune solution de récupération de la clef.

Le TPM qui communique en clair, c'est quand même ballot. Il n'était quand même pas compliqué d'implémenter un lien qui, à la 1ere mise sous tension si un TPM est présent, permette d'initialiser une clef de chiffrement entre processeur et TPM.

C'était bien la peine d'imposer un TPM 2.0 pour win11 avec un tel trou béant pour tout processeur l'intégrant pas directement le TPM.

Ils n'ont plus qu'a les imposer en BGA, avec une conception du PCB ne rendant aucun signal accessible...
votre avatar
Quand j'enlève la pile de mon BIOS, ou que je le reset, le mot de passe admin saute, et Windows se lance quand-même. :/

Je ne sais pas si je dois activer une option dans le bios Asus de ma X670E.
votre avatar
Si j'enlève la pile de mon BIOS, à part la date et le paramétrage, rien ne saute. Pour faire sauter le mot de passe admin, à part les pinces et le flashage du BIOS à froid, ce n'est pas possible.
Pire: ce n'est pas gagné, car maintenant une partie du BIOS est stockée chiffrée par le fTPM du CPU avec une clé Lenovo qui s'active quand on met le CPU... Donc on ne peut plus flasher le BIOS si le fTPM n'a pas été désactivé AVANT. Changer de CPU peut donc nécessiter un reflashage du BIOS avec un BIOS générique de démarrage avant de retagger l'ordi. DE même, le CPU, une fois mis dans la machine, ne peux plus être utilisé que dans des machines lenovo.
votre avatar
Quand je reset mon BIOS avec le bouton prévue, le mot de passe admin saute, mais pas le démarrage de Windows, et ça pose problème.
votre avatar
Le problème que tu soulèves est en réalité très complexe. Si tu protèges la protection 1 avec une protection 2, comment tu protèges cette protection 2?

Chiffrer entre le CPU et le TPM, avec quelle(s) clé(s) de chiffrement? symétrique? asymétrique? comment tu la(les) génères? comment tu la(les) révoques? comment tu la(les) changes? on fait une PKI? est-ce un certificat avec une date? comment tu vérifies la date dans cette section de early boot d'un ordinateur? ces clés de chiffrement, comment et ou tu les stocke?

A ma connaissance, dans le monde grand public, seul Apple le fait sur les iPhone par exemple en établissant une liaison chiffré unique et certifié entre le SOC et le bouton TouchId.

En dehors de la solution actuel, qui a été de rendre physiquement, extremement compliqué d'accéder au TPM en le gravant dans le CPU, c'est vraiment très très compliquer de faire une solution bullet proof sans avoir un controle physique de la machine.
votre avatar
Il n'y a guère de noeuds à se faire au cerveau et procéder comme je le disais: Tu as un TPM au chiffrement non initialisé qui est découvert à la 1ère mise sous tension d'une mobo à peine assemblée en usine et on se passe une clef de chiffrement symétrique. C'est tout ce qu'il y a de plus facile.
Ensuite, toute la vie de la machine, cela fonctionne. Sur une machine avec un TPM sur connecteur ca marche aussi si on le change.
Note que sur un mode similaire, les firmwares intel initialement non signés le sont au 1er démarrage avec une clef dérivée de l'ID unique processeur. C'est pour cela que récupérer une image de boot flash sur une mobo en espérant la remettre sur une autre identique transformée en presse papier après un pb de MAJ BIOS ne fonctionne pas.
votre avatar
Ok, d'un côté une clé symétrique stocké dans le TPM. Et de l'autre côté, tu la stockes où cette clé?
votre avatar

C'est évidemment une chose qu'il faut prévoir des 2 côtés avant d'être confronté à ce genre de problème. Mais en tout cas, on saurait tout à fait dériver une clef de chiffrement symétrique unique à un processeur pour la donner à un TPM à la première mise en route de l'ensemble en fabrication.

C'est ce qui est déjà fait pour les firmwares et ne dépends nullement de la présence d'un TPM (c'est effectifs sur des cartes qui n'en intègrent pas!): En résumé, c'est LE moyen d'Intel de préserver le business des vendeurs de BIOS car s'il fournit un blob binaire (version compilée aux aux API restreintes de ses Reference Code nécessaires au démarrage de la plateforme, incluant la complexe init DDR) utilisé par des projets type coreboot/EDKII (ce dernier étant en fait son bébé), il ne fournit les firmwares non signés (tout comme la version source des ref codes) qu'aux vendeurs de BIOS: Sans cela, impossible de construire des boot flash communes pour la fabrication ou des capsules d'upgrade durant la vie du produit (sauf à ne jamais MAJ les FW).
votre avatar
"il faut prévoir", "on pourrait", "on saurait", ... sauf qu'en pratique, concrètement, c'est pas fait. "Y a qu'à, faut qu'on" comme on dit.

On revient donc à ce que je dis, c'est très complexe.

Merci du smiley foutage de gueule btw.
votre avatar
Ca n'a rien de complexe et il est toujours préférable de réfléchir avant d'agir. Ne pas l'avoir fait ici sur le "maître des clef" d'une mobo, ca renvoie à la référence GhostBusters quand même!

“Tout problème a une solution, ou bien vous faites partie du problème.” – Albert Einstein.
votre avatar
Tu penses vraiment que les gens qui ont fait ça, l'ont fait sans réfléchir?

Peut-être que dans la balance, il y a le coût de la R&D? Le fait que peut de temps ensuite, les CPU allaient intégrer le TPM directement?

Pour rappel, on parle de module de sécurité externe, branché au bus LPC. Donc c'est pas forcement le fabriquant de la mobo qui fabrique aussi le module TPM, donc il faut aussi mettre en place un système de génération et partage de clé sécurisé (affaire de la Master Key des BR qui a fuité), et est-ce vraiment la solution?

Car au final, t'as toujours pas résolu le problème. Comment tu protèges le secret coté client?
votre avatar
Dans les ordis, les clés du TPM sont effaçables depuis le BIOS, une fois fait elles sont renégociées au boot suivant.
Donc ce serait possible...

Par ailleurs, il me semble que sans bitlocker, les SSD compatibles OPAL (souvent en option chez lenovo) font le job en hard.
votre avatar
Tous ces stockages sont chiffrés de base en fait (on ne récupère jamais les données sur les plateaux ou dans les flash). C'est la mise en place d'un mot de passe sur le stockage qui va permettre de bloquer les commandes d'accès read/write tant qu'il n'est pas donné au démarrage (ensuite tant que le stockage reste alimenté, le stockage reste débloqué, ce qui est une vulnérabilité mais l'avantage est que c'est transparent niveau perf et indépendant d'un support OS).
Normalement, les commandes permettant de changer ce mdp sont désactivées par le BIOS avant de passer la main à l'OS car cela faisait aussi un excellent moyen de rendre instantanément inaccessible les précieuses données de l'utilisateur par des virus avec derrière une demande de rançon pour les récupérer!
votre avatar
"Il y a une autre différence de taille : sur un Mac, le mot de passe de la session est obligatoire pour lancer le déverrouillage des données. Sur PC, la clé est transmise automatiquement au démarrage du système."

Alors ça, c'est vraiment bête.
Aucun moyen pour reproduire ce comportement des Mac sur PC?
votre avatar
Sous Windows.

Parce que moi j'ai un PC, et mon Linux demande mon mot de passe pour déverrouiller les données.
votre avatar
Parce que tu ne chiffre pas avec Bitlocker. :p
votre avatar
Sur Mac non plus ce n'est pas Bitlocker.
votre avatar
Un mac est un PC ...
votre avatar
Plus depuis leur abandon des cpu x86 😁
votre avatar
Désactiver TPM dans le BIOS, ainsi sous Windows tu pourras chiffrer avec un mot de passe qui sera demandé au tout début du démarrage de Windows. Sans le désactiver, l'option n'apparaît pas, c'est stocké dans le TPM et il n'y a pas d'autre protection proposée. Si tu as déjà chiffré, il faut déchiffrer, désactiver TPM, et rechiffrer.

Ou alors garder le TPM et bidouiller la stratégie de groupe comme indiqué dans les premiers commentaires, mais j'ai pas testé.
votre avatar
Un peu pénible de désactiver le TPM.
Faudrait que ce soit le code du compte utilisateur qui déverrouille les données, sinon c'est pas sécurisé du tout......
votre avatar
sauf que pour arrivé jusqu'au choix du compte utilisateur windows à besoin de se charger et donc d'acceder au donnée du disque non?
votre avatar
Apple y arrive bien, Windows peut le faire aussi j'imagine.
votre avatar
C'est parfaitement sécurisé, si tu n'as pas le mot de passe l'OS ne boote même pas, et rien n'est déchiffré. C'est même plus sécurisé que de le faire au mot de passe utilisateur puisque tout l'OS est chiffré.

Pénible en quoi de désactiver le TPM ? A moins que tu ne t'en serves pour quelque chose d'autre, ce qui n'est pas le cas sur Mac puisqu'il n'y en a pas. Et c'est Microsoft, pas moi, qui a décidé de cette restriction. Essaie la stratégie de groupe sinon.
votre avatar
J'ai plusieurs disques.
votre avatar
Et donc ?
votre avatar
ils ont tous bitlocker, je ne connais pas le fonctionnement du truc sans TPM.
Est-ce-que Windows stock les clefs et déchiffre à la volée une fois que la session est ouverte?

Ou bien est-ce-que je dois rentrer les clefs à chaque fois pour mes 4 supports de stockage?
votre avatar
Rentrer 4 fois les mots de passe, je sais pas, j'ai pas essayé sur un disque non système, je sais pas quand il va demander les mots de passe, ni s'il va demander plusieurs fois si tu as mis le même sur chaque disque, il faut essayer.

Après si tu veux utiliser TPM tu as testé la modification de stratégie de groupe décrite plus haut dans les commentaires ? J'avais l'impression que ça allait verrouiller le TPM par un pin ou un mot de passe, et donc que tu n'aurais à le rentrer qu'une seule fois.
votre avatar
Dans le BIOS. Sécurisation du démarrage par mot de passe.
Mais c'est un mot de passe "en plus".
votre avatar
c'est un truc qui saute si tu reset le bios, non?
votre avatar
Ca dépend de l'ordi. Pour plein de portables, c'est assez chaud.
Et ça dépend de l'étendue du mot de passe. S'il est utilisé pour chiffrer le disque dur... Tu peux reformater le disque si tu a effacer le mot de passe.
votre avatar
Dans le BIOS Asus, j'ai mis le mot de passe "user".
Il me le réclame au démarrage du PC.

Je verrai si un jour quand je reset le bios, si les clefs Bitlocker sautent (j'espère).
votre avatar
sinon y'a aussi la solution de ne pas utiliser bitlocker hein. y'en a d'autres. ^^
votre avatar
De mémoire (vieilles recherches sur les potentielles solution à ce problème) il est prévu de chiffrer les transmissions sur le bus LPC (de mémoire un bus I2C). Mais ça n'est pas fait.
(Comment ? Je ne sais plus, mais bon, pourquoi pas la même chose que TLS avec le loader qui vérifie le certificat... Tant que cette partie est couverte par Secure boot, pas de problème).

Pour ceux intéressés il y avait de dispo une présentation sur le cassage (assez simple) de la chose, avec un analyseur logique (capture des trames I2C, décodage... Ce que fait ce "YouTubeur" aussi je suppose, à part qu'il utilise un pico pi).
votre avatar
Sinon, une fois la liaison chiffrée, reste aussi à chiffrer la mémoire (et la liaison avec la mémoire). Mes machines ont des fTPMs, je me suis souvent interrogé sur la difficulté de faire un "module RAM de wiretapping". (En principe résolu sur les quelques CPU qui disposent du chiffrage de la RAM activé dans le BIOS au démarrage)

A noter aussi que tout semble se concentrer sur BitLocker, le problème est le même avec LUKS + TPM.

Pour le moment, chiffrer une machine qui puisse booter indépendamment reste un compliqué. Le déverrouillage sans mot de passe était vu comme un moyen de décourager l'attaquant, pas une protection contre un attaquant motivé.
votre avatar
Aller se mettre sur une interface DDR sans la perturber, bon courage. Quand on voit la tétrachiée de calibrations désormais nécessaires pour que cela fonctionne...

Il serait beaucoup plus simple de mettre la machine suspend to ram, ce qui mets la DDR en self refresh (permettant de "tenir" plus longtemps durant une phase de réinit, pendant laquelle le contrôleur mémoire ne fera pas ce refresh, cf la suite), pour l'extraire (si elle n'est pas soudée bien sûr!) et la mettre sur un lecteur spécialisé (si on fait vite, même pas forcément utile de maintenir une alimentation) avec un code d'init DDR qui permets un mode de démarrage conservant le contenu (couramment utilisé dans l'embarqué car on a en général une partie du mapping mémoire réservé à un "flight recorder" permettant les analyses post-mortem si on n'a pas pu logger sur le stockage avant un crash).

Bon, c'est pas neuf et je ne sais pas si cela fonctionnerait encore sur des générations de DDR actuelles... mais dans la première moitié de la décennie 2000 j'avais du code de démarrage qui, en développement (une variable d'environnement du boot-loader autorisait ce hack totalement hors spec constructeur mais qui, expérimentalement, fonctionnait!), tentait vraiment tout pour préserver le contenu de la DDR (dont zone de "flight recorder") y compris sur des démarrages à froid ou ce n'était pas censé être faisable (car les alimentations tombent pendant 1 ou 2 secondes, dont celle de la DDR et même en self-refresh elle en a besoin): Cela permettait de débugger en post-mortem des cas de watchdog ou on n'avait sans cela aucune bille par exemple.

La zone était classiquement constituée d'un header avec un magic number initialisé après sa mise en place pour signifier qu'elle était lisible et des zones checksummées validant les contenus.

Quand ce mode de reboot a froid de développement/labo était actif, si le magic nb était trouvé on faisait une réinit DDR partielle puis vérifiait au boot la validité des zones avec les checksum et s'il y en avait un pas bon on signalait les zones avec des données crouillées (mais avec peut-être encore des trucs exploitables! Une bonne partie étant du texte, un caractère mauvais par ci par là n'est pas si emmerdant).

Un jour, un appel de l'usine pour explication car un opérateur de banc de test consciencieux avait remarqué un message inhabituel même si tous ses tests passaient...

L'occasion de se rendre compte que le truc était activé car un environnement par défaut mal ficelé s'était retrouvé à l'usine... et surtout que ce contenu de la DDR était l'immense majorité du temps conservé pendant des dizaines de secondes sans alimentation!

En effet, l'affaire se déclarait sur un banc de test module succédant à un test carte ou elle était démarré la première fois après flashage: Entre les deux, retrait du lit à clous du banc carte, assemblage du sandwich dans la mécanique puis ensemble pluggé dans le banc module voisin.

De l'ordre de la minute entre le shutdown sur banc carte et le redémarrage sur le banc module... et un contenu DDR encore exploitable!
votre avatar
Dans le genre y'a l'azote liquide ou autre refroidissement. Sauf erreur de ma part la majeure partie de la RAM survit à un reboot, d'où le fait qu'il faille verrouiller la séquence de boots, sinon reboot sous un OS minimaliste qui laisse la RAM autant intacte que possible.
L' attaque est connue sous le nom de "Cold boot attack".

Y'a aussi les attaques par DMA, en principe mitigée avec IOMMU.

Et autant faire du wiretap sur du I2C (en plus souvent sur un module enfichable avec un connecteur IDC) ça me semble simple (d'ailleurs le jour où je me suis intéressé au sujet, j'ai juste cherché ça comme attaque, et j'ai trouvé de suite un beau papier avec les copies d'écran de l'analyseur logique), autant oui... Sur de la DDR.... Disons que je n'ai pas passé 1 minute sur le sujet ;)

Sinon pour ce que tu faisais dans les années 2000, je le fais aujourd'hui sur des petits ARM. Pas forcément complètement dans le même but, ça m'intéresse de préserver des infos, et pareil, y'a du checksum avec pour s' assurer que ça s'est bien passé. Bon ils n'ont pas de DDR ;)
votre avatar
Au final, c'est pas vraiment un problème Windows mais un problème TPM dans son design couplé à un constructeur pas très malin. Comme le dit l'article, le TPM est maintenant dans le processeur donc bon chance pour intercepté le binaire et reconstruire la clé. Microsoft a fait le choix d'implémenter un chiffrement complet du disque via le TPM contrairement à Apple ou autre OS. Du coup si on sort un disque d'un Mac, on peut faire boot l'OS mais ne pas accéder aux données car pas la clé de déchiffrement c'est ça ?
votre avatar
Penser qu'on est protégé de quoique ce soit en chiffrant son disque système, que ce soit bitlocker ou autre système, reste une fantaisie de toute manière.

Je continuerai à le faire pour mes clients / mon employeur parce que ça leur permet de passer des audits.

Mais concrètement le risque pris à ne pas chiffrer les disques d'un poste est tellement minime qu'il est virtuel.

Avec de la créativité la protection se bypass, que ce soit mdp ou que ce soit clé physique.
Si la machine est déjà allumée, il n'y a plus de protection, ce qui est une très grosse partie du temps.
Aujourd'hui les données importants sont de moins en moins en local et de plus en plus en ligne, loin de la partition chiffrée.

Pour bitlocker, on a permis aux utilisateurs de ne pas se soucier des clés de chiffrement en utilisant une puce TPM. Ce n'était qu'une question de temps que quelqu'un aille regarder la puce TPM. Donc honnêtement la manip ne m'étonne pas et ne m'effraie pas plus que ça non plus. C'est by design.
Tout accès physique au matériel rend caduque n'importe quelle protection "automatique" qui ne demande pas d'interaction. Toute tentative d'échapper à cette règle ne sont que des exercices de forme et d'obfuscation.

C'est une énigme impossible où on dispose d'une clé (le secret), et on voudrait la laisser sur la machine pour pouvoir l'utiliser quand on veut, ou pouvoir la démarrer automatiquement ou pouvoir la réinitialiser au cas où, mais on voudrait en même temps qu'elle ne soit pas récupérée par la personne qui récupère la machine. C'est impossible.

Et quand on compare le risque de se voir sa machine piratée via une connexion externe quand il est allumé, vs le risque que quelqu'un vous prenne votre pc, qu'il prenne le disque, qu'il a la compétence pour siphoner ce qui s'y trouve. L'effort et le risque pris par le hacker dans le second cas sont plus élevés de plusieurs ordres de grandeurs.
votre avatar
C'est justement pour ça qu'il est possible d'y adjoindre un facteur d'authentification tiers comme un code PIN. Les puces TPM 2.0 ont un système anti-force brute (anti-hammering) qui augmente fortement le temps d'attente entre chaque essai en cas d'erreurs à répétition (configurable). Cela diminue les chances de le trouver dans un laps de temps raisonnable.

Après, c'est toujours une question de modèle de menaces : contre qui on souhaite se protéger ? Contre les gouvernements et leurs moyens colossaux ou simplement un voleur ou un concurrent un peu trop curieux ? Dans ces deux derniers cas, la protection sera bien assez efficace, et c'est ce qu'on lui demande.
votre avatar
Et puis Bitlocker ne sert à rien face à l'ouverture de ChatonMignon.PDF bien rempli de craspouilles :D
votre avatar
J'ai jamais compris l'intérêt du TPM. Généralement le voleur vole le PC complet donc le TPM avec.
votre avatar
Certes, mais le TPM contient justement une mémoire qui n'est pas lisible de l'extérieur. Même s'il doit être possible de l'ouvrir, la mettre à nue pour en lire le contenu, l'opération à surtout toutes les chances de détruire la puce au passage et les clés qu'elle contient :)
votre avatar
Exemple : tu vas chez le réparateur. Il peut copier ton disque, il n'en fera rien. Il peut t'installer un nouveau disque et garder l'ancien, il n'en fera rien non plus. Enfin, quand je dis rien, je veux dire des données. Le disque il peut tout à fait le formater et le réutiliser derrière !

BitLocker contourné rapidement pour moins de 10 dollars ? Pas de panique

  • Très peu de matériel nécessaire

  • Faut-il s’en inquiéter ?

  • Les Mac ne sont pas concernés

Fermer