SGX et TrustZone pour isoler du code sensible

SGX et TrustZone pour isoler du code sensible

Les enclaves matérielles déplacent une partie du périmètre de confiance sous le système d’exploitation, là où une machine virtuelle reste administrée par un hyperviseur. Elles répondent à un problème précis : exécuter un calcul ou manipuler une clé alors que le noyau, l’administrateur système ou le plan de contrôle de l’hébergement ne méritent pas une confiance totale.

Explication de la marmotte

Une enclave ressemble à une salle fermée dans un immeuble où le gardien possède pourtant toutes les autres clés. On y place ce qui ne doit pas être lu ou modifié par les personnes qui entretiennent le bâtiment, même lorsqu’elles ont accès aux couloirs et aux caméras.

→ Lire l’explication complète de la marmotte

SGX et TrustZone : le compromis à accepter

Intel SGX (Software Guard Extensions) et Arm TrustZone créent un environnement d’exécution de confiance, ou TEE (Trusted Execution Environment), protégé par des mécanismes du processeur. Le code sensible et ses données sont isolés du système d’exploitation, de l’hyperviseur et, selon le modèle, d’autres applications. Cette isolation n’est pas une virtualisation classique : le noyau peut planifier, interrompre ou affamer l’exécution, mais il ne doit pas pouvoir lire la mémoire privée de l’enclave.

Le compromis central est brutal : réduire le TCB (Trusted Computing Base), la quantité de code digne de confiance, au prix d’une complexité opérationnelle et applicative élevée. Le gain est réel pour une clé de signature, un traitement de données confidentielles ou une politique d’accès critique. Le prix inclut une chaîne d’attestation, des dépendances matérielles, des interfaces étroites et une défense explicite contre les canaux auxiliaires. Une enclave n’est pas un bunker magique livré avec une slide de vendeur.

SGX vise surtout le code applicatif sur processeurs Intel compatibles. Chaque enclave dispose de pages mémoire chiffrées hors du processeur, gérées dans l’EPC (Enclave Page Cache). TrustZone partitionne plutôt la plateforme Arm en mondes sécurisé et normal. Le monde sécurisé héberge un système minimal et des services sensibles, tandis que le monde normal exécute souvent Linux ou Android. TrustZone convient aux équipements embarqués, aux terminaux et aux passerelles ; SGX convient davantage à des calculs confidentiels ciblés sur serveur.

La recommandation est de ne pas généraliser les enclaves à toute application. Réserver SGX à un composant dont le secret reste exploitable même si le système hôte tombe, par exemple la dérivation d’une clé, la signature d’un jeton ou le traitement d’un identifiant sensible. Réserver TrustZone aux secrets matériels durables et aux fonctions de démarrage, d’identité d’équipement ou de paiement. Si le besoin est seulement d’isoler des services ordinaires, la segmentation réseau, les identités de charge et une architecture cyber défensive coûtent moins cher à opérer.

Prérequis matériels et chaîne de confiance

SGX exige un processeur Intel qui expose effectivement cette capacité, un microcode maintenu, un firmware UEFI (Unified Extensible Firmware Interface) correctement configuré et un noyau avec pilotes compatibles. Vérifier aussi que le fournisseur d’infrastructure ne masque pas la fonctionnalité : une instance virtuelle peut afficher un processeur récent tout en interdisant les instructions nécessaires. L’émulation ne remplace pas l’isolation matérielle. Elle remplace surtout le problème par une déception bien emballée.

TrustZone dépend du processeur Arm et du micrologiciel de démarrage. La séparation doit être configurée avant le démarrage du monde normal : contrôleur mémoire, interruptions, périphériques à accès direct et stockage sécurisé font partie du périmètre. Un périphérique de type Direct Memory Access, accès direct à la mémoire, autorisé à lire la mémoire sécurisée contourne l’objectif entier. Le code sécurisé doit donc programmer les pare-feux matériels du bus et restreindre les périphériques accessibles depuis le monde normal.

La racine de confiance doit commencer au démarrage. Le chargeur vérifie le firmware suivant, qui vérifie le système sécurisé, qui charge ensuite le système normal. Une signature de démarrage vérifie l’origine du code, pas sa qualité ni l’absence de faille. Une image authentique qui contient une vulnérabilité reste une image authentique, ce qui est d’une honnêteté assez peu commercialisable.

Prévoir un TPM (Trusted Platform Module) ou un élément sécurisé équivalent pour mesurer l’état de démarrage et protéger les clés propres à la machine. Pour les clés à forte valeur, déléguer leur cycle de vie à un HSM (Hardware Security Module) ou à un service de gestion de clés doté d’une séparation d’administration. Une enclave peut utiliser une clé ; elle ne remplace ni gouvernance de clés, ni sauvegarde, ni révocation. Les principes de cryptographie appliquée restent valables, y compris quand le processeur porte un costume de super-héros.

Attestation distante et libération des secrets

L’attestation distante permet à un service de vérifier qu’il dialogue avec une enclave attendue avant de lui remettre un secret. Pour SGX, l’enclave produit une preuve liée à son identité cryptographique, à la version de son code et à une valeur de fraîcheur fournie par le demandeur. Le vérificateur contrôle la chaîne de certificats, le statut de révocation, l’identité attendue et la valeur de fraîcheur. Cette dernière bloque la réutilisation d’une preuve ancienne capturée par un attaquant.

La décision de libération doit porter sur une politique précise : identité du code compilé, identité du signataire, niveau minimal de correctif, configuration matérielle et environnement de déploiement. Accepter toute enclave signée par une même clé réduit les mises à jour pénibles, mais transforme la clé de signature en passe-partout. Accepter uniquement une empreinte exacte verrouille le déploiement et impose une procédure de migration à chaque reconstruction. Le bon choix dépend de la fréquence de livraison et de la capacité à révoquer rapidement une version compromise.

Ne jamais remettre directement une KEK (Key Encryption Key), clé qui chiffre d’autres clés, à une enclave au seul motif qu’elle a produit une attestation valide. Établir d’abord un canal authentifié avec éphémères cryptographiques, associer l’attestation à la négociation de session, puis livrer une clé de travail limitée dans le temps et dans son usage. Une attestation dissociée de la session ouvre la porte à une attaque de relais : l’attestation est bonne, mais le secret termine dans la mauvaise conversation.

L’attestation ne garantit pas que la logique métier est correcte. Elle prouve l’exécution d’un binaire identifié sur une plateforme répondant à certains critères. Une enclave qui signe une transaction frauduleuse selon une règle frauduleuse exécute parfaitement son contrat. La sécurité applicative doit venir des contrôles de métier, des autorisations et de la traçabilité des identités.

Exemple reproductible : vérifier le support SGX Linux

Avant de concevoir une enclave, vérifier les capacités réellement exposées par l’hôte. Le contrôle suivant s’exécute sous Linux avec les outils cpuid et dmesg disponibles. Il ne valide ni l’attestation ni la configuration de production, mais évite de bâtir un château sur une instruction absente.

# Installer l'outil de lecture des capacités processeur sur Debian ou Ubuntu.
sudo apt-get update
sudo apt-get install -y cpuid

# Le bit SGX doit apparaître dans les fonctionnalités exposées au système invité.
cpuid -1 | grep -i -E 'sgx|software guard extensions'

# Vérifier que le noyau a chargé le pilote et détecté une enclave utilisable.
dmesg | grep -i -E 'sgx|enclave'

# Contrôler la présence des périphériques fournis par le pilote SGX.
ls -l /dev/sgx_enclave /dev/sgx_vepc 2>/dev/null

Une sortie vide n’autorise aucune extrapolation optimiste. Elle signifie que la chaîne processeur, firmware, hyperviseur, noyau ou pilote manque à l’appel. Corriger la cause documentée ; ne pas contourner le contrôle en basculant vers un mode logiciel présenté comme équivalent. Il ne l’est pas.

Surface d’attaque des enclaves matérielles

Le système d’exploitation compromis conserve des pouvoirs gênants : interrompre l’enclave, manipuler ses entrées, provoquer des défauts de page, rejouer des requêtes et observer les temps d’exécution. Il ne lit pas directement la mémoire protégée, mais il peut influencer ce qui y entre et quand le code s’exécute. Toute interface d’entrée est donc hostile par défaut : valider tailles, pointeurs, encodages, états et identifiants avant toute copie.

Les canaux auxiliaires restent le problème le plus sous-estimé. Cache processeur, prédiction de branchement, accès mémoire, pagination et durée d’exécution peuvent révéler des informations sur les secrets traités. Les attaques Spectre, Meltdown et leurs variantes ont démontré qu’une frontière architecturale ne dispense jamais de suivre les avis de sécurité processeur. Maintenir microcode, firmware, noyau et bibliothèque d’enclave ; désactiver ou limiter les optimisations incompatibles avec le modèle de menace ; employer des primitives à temps constant pour les opérations cryptographiques.

Les attaques par rollback visent le stockage persistant. Un hôte malveillant peut restaurer une ancienne base chiffrée, un compteur ou un état d’autorisation afin de faire rejouer une décision passée. Lier les versions à un compteur monotone matériel lorsque disponible, ou à un registre distant append-only authentifié. Le chiffrement seul ne détecte pas le retour en arrière. Il garantit la confidentialité du mauvais état, ce qui reste une forme particulièrement raffinée d’échec.

TrustZone ajoute le risque de périphériques mal configurés et de pilotes sécurisés trop larges. Le monde sécurisé ne doit exposer qu’un protocole minimal au monde normal. Un pilote graphique, réseau ou système de fichiers complet dans le monde sécurisé élargit le TCB jusqu’à retrouver un petit système généraliste. C’est faisable, mais alors autant assumer qu’on a reconstruit un noyau miniature avec moins d’outils de diagnostic.

Exploitation : rotation, supervision et reprise

Les secrets d’enclave doivent être éphémères autant que possible. Dériver une clé de session après attestation, limiter sa durée de vie, lier son usage à une identité de service et journaliser les décisions de libération. La clé racine ne doit jamais être exportée vers l’enclave si une opération distante par HSM suffit. Une enclave est un consommateur de secret, pas nécessairement son coffre-fort définitif.

Prévoir une rotation qui tolère plusieurs versions de code. Une nouvelle enclave doit pouvoir attester avec la nouvelle identité tandis que l’ancienne reste autorisée pendant une fenêtre bornée. Révoquer ensuite l’ancienne identité dans la politique du vérificateur et dans le service de clés. La révocation d’un certificat ou d’une identité ne retire pas les clés déjà en mémoire : il faut aussi expirer les sessions et redémarrer les charges concernées.

Superviser les échecs d’attestation, les refus de politique, les changements de version de microcode, les redémarrages d’enclave et les anomalies de latence. Une hausse de défauts de page ou d’interruptions n’établit pas une attaque par canal auxiliaire, mais mérite une corrélation avec l’hôte et le plan de contrôle. Les journaux ne doivent jamais contenir de secret, de preuve d’attestation complète réutilisable ou de donnée métier déchiffrée. Cela arrive encore, parce que le mode débogage a une capacité surnaturelle à survivre aux migrations.

La reprise après incident impose une copie chiffrée des états persistants, une protection anti-rollback et une procédure de réémission des secrets. Sauvegarder une image d’enclave ne suffit pas : les clés liées à une machine ou à une mesure matérielle peuvent devenir indisponibles sur le matériel de secours. Tester la restauration avec une plateforme distincte et une nouvelle attestation, sinon le plan de reprise reste un exercice littéraire.

🐝 Ce qui arrive si on s’en passe

Sans enclave, la clé de signature ou de dérivation réside dans la mémoire ordinaire du processus : tout compte root, tout module noyau et l’hyperviseur la lisent directement, sans avoir à exploiter la moindre faille. Elle se retrouve aussi dans les copies que la plateforme produit d’elle-même : fichier d’échange, vidage mémoire après plantage (core dump), instantané de machine virtuelle ou image de migration à chaud. Ces artefacts sont conservés et sauvegardés hors du périmètre prévu. Côté distribution des secrets, l’absence d’attestation oblige le service de clés à se fier à un identifiant réseau ou à un jeton. Un binaire modifié qui présente le même jeton reçoit alors le même secret, et les journaux ne distinguent pas la version légitime de la version altérée, ce qui prive l’enquête de toute trace exploitable.

🦫 Explication de la marmotte 🍫

Une enclave est une zone protégée par le processeur. Un programme y place une petite partie de son code et des données secrètes, par exemple une clé servant à signer. Le système qui fait tourner la machine continue de lancer le programme, de lui donner du temps de calcul et de lui fournir des données. Mais il ne doit pas pouvoir lire directement ce qui se trouve dans cette zone protégée.

Avant de transmettre un secret, un service distant demande une preuve. Cette preuve indique quel programme protégé est lancé, quelle version il utilise et si le matériel répond aux règles attendues. Le service vérifie cette preuve, puis crée une communication chiffrée liée à cette vérification. Si la preuve est fausse, trop ancienne ou produite par une version refusée, le secret n’est pas transmis.

Cette protection a des limites. Le système compromis peut envoyer des données malformées, arrêter le programme, ralentir son calcul ou observer certains effets indirects, comme le temps nécessaire à une opération. Le programme protégé doit donc contrôler toutes ses entrées, éviter de laisser ses calculs révéler des secrets et rester très petit.

Les clés doivent expirer et être renouvelées. Les données conservées doivent aussi détecter un retour vers une ancienne version. Sans cette précaution, un attaquant peut remettre un ancien état pourtant chiffré.

À lire aussi

• Sécuriser les données en mémoire dans le cloudMettre en œuvre le confidential computing pour protéger les données pendant le traitement des workloads cloud.
• Comment sécuriser firmware UEFI, réseau et BMCLe firmware UEFI, des contrôleurs réseau et des BMC forme une surface d’attaque privilégiée, autonome et souvent invisible depuis le système d’exploitation.
• Comment sécuriser un démarrage réseau PXE en entrepriseLe démarrage réseau PXE expose l'infrastructure de déploiement à des attaques DHCP, TFTP et de substitution d'images souvent absentes des inventaires de sécurité.
• Attaques par canaux auxiliaires et secretsLes attaques par canaux auxiliaires extraient un secret en observant le temps, la consommation électrique ou les émissions électromagnétiques d’un calcul.

Pages voisines

La citent

• Isolation des conteneurs Docker : namespaces, cgroups et évasions
• Isolation multi-locataire face à un locataire hostile
• Ce que le bout en bout laisse voir
• Chiffrement homomorphe dans le cloud : promesses et limites réelles
• Sécuriser les données en mémoire dans le cloud

SGX et TrustZone pour isoler du code sensible

Elle cite

• ⇄Lien dans les deux sens :Rowhammer, Spectre et Meltdown, mécanismes et contre-mesures
• Attestation distante TPM et démarrage mesuré
• Gouverner les comptes de service et agents autonomes

⇄ : les deux pages se citent l’une l’autre.