Tout commence en avril 2026, comme le raconte notamment TechSpot. Ben Kilpatrick, qui se décrit lui-même comme un utilisateur Linux avancé et soucieux de sa vie privée, aime vérifier que toutes les protections fournies avec un matériel donné sont actives. Il remarque alors un comportement étrange : avec une récente mise à jour du BIOS, l’outil HSI (Host Security ID) renvoyait le résultat : « Encrypted RAM: not supported », alors que la fonction correspondante, TSME, était activée dans le BIOS.

De quoi parle-t-on ?

Si TSME peut être vu comme une évolution de SME, il faut pourtant savoir de quoi on parle précisément.

SME, pour Secure Memory Encryption, est une fonction de chiffrement des données gérée par le système d’exploitation. Elle utilise une clé unique servant à chiffrer sélectivement certaines pages mémoire. TSME (Transparent Secure Memory Encryption) est gérée directement par le firmware (AGESA) et se sert d’un moteur AES (Advanced Encryption Standard) embarqué dans le processeur. Elle correspond ainsi à une réalité matérielle, gravée dans le silicium de la puce.

Quand TSME fonctionne, les applications et le système d’exploitation exécutent leurs tâches, sans nécessiter de modification. Les opérations de chiffrement sont appliquées par le processeur à l’ensemble des données présentes en mémoire vive, sans intervention d’un autre code que celui fourni par le firmware. C’est cet aspect transparent qui a donné son nom à la fonction. Bien que les noms SME et TSME soient très proches, ils ne sont liés que par la finalité, car les processus impliqués sont complètement différents.

TSME est utile pour bloquer certains scénarios d’attaque parmi les plus évolués, dont ceux par « cold boot ». Elles consistent à refroidir physiquement les modules DRAM pour ralentir la perte de données, puis à éteindre la machine. À ce moment, la mémoire retient sa charge suffisamment longtemps pour que les clés de chiffrement, jetons d’authentification et autres identifiants soient récupérés.

Aller et retour d’un hobbyste

Que s’est-il alors passé ? Ben Killpatrick a fini par ouvrir un rapport de bug sur le dépôt GitHub public d’AMD. Deux ingénieurs de l’entreprise, Tom Lendacky et Mario Limonciello, ont fini par répondre. D’abord, le premier a répondu ne pas comprendre d’où venait le problème et a conseillé de modifier le paramètre dans le BIOS. Le second, qui se trouve être aussi le mainteneur de l’implémentation HSI de fwupd (un utilitaire de mise à jour des firmwares presque omniprésent sur Linux), aboutit à une conclusion similaire. Si la manipulation ne donne rien, il conseille de contacter le fabricant de la carte mère.

Il reste 62% de l'article à découvrir.

Déjà abonné ou lecteur  ? Se connecter

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Abonnez-vous