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.
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)
#1
Ensuite, rajouter un code pin c'est juste
manage-bde -protectors -add c: -TPMAndPIN
#1.1
#1.3
#1.4
#1.5
#1.2
#2
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...
#2.1
Je ne sais pas si je dois activer une option dans le bios Asus de ma X670E.
#2.6
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.
#2.7
#2.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.
#2.3
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.
#2.4
#2.8
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).
#2.10
On revient donc à ce que je dis, c'est très complexe.
Merci du smiley foutage de gueule btw.
#2.11
“Tout problème a une solution, ou bien vous faites partie du problème.” – Albert Einstein.
#2.12
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?
#2.5
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.
#2.9
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!
#3
Alors ça, c'est vraiment bête.
Aucun moyen pour reproduire ce comportement des Mac sur PC?
#3.1
Parce que moi j'ai un PC, et mon Linux demande mon mot de passe pour déverrouiller les données.
#3.3
#3.5
#3.6
#3.7
#3.2
Ou alors garder le TPM et bidouiller la stratégie de groupe comme indiqué dans les premiers commentaires, mais j'ai pas testé.
#3.4
Faudrait que ce soit le code du compte utilisateur qui déverrouille les données, sinon c'est pas sécurisé du tout......
#3.9
#3.10
#3.13
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.
#3.14
#3.15
#3.16
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?
#3.17
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.
#3.8
Mais c'est un mot de passe "en plus".
#3.11
#3.12
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.
#3.18
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).
#4
#5
(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).
#6
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é.
#6.1
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!
#6.2
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 ;)
#7
#8
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.
Historique des modifications :
Posté le 11/02/2024 à 16h40
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.
Posté le 11/02/2024 à 16h47
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.
Posté le 11/02/2024 à 16h47
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.
Posté le 11/02/2024 à 16h50
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 sont plus élevés de plusieurs ordres de grandeurs.
#8.1
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.
#8.2
#9
#9.1
#9.2