Partager via

System Guard : Comment une racine de confiance basée sur le matériel permet de protéger Windows

Pour protéger des ressources critiques telles que la pile d’authentification Windows, les jetons d’authentification unique, la pile biométrique Windows Hello et le module de plateforme sécurisée virtuelle, le microprogramme et le matériel d’un système doivent être fiables.

System Guard réorganise les fonctionnalités d’intégrité du système Windows existantes sous un même toit et configure l’ensemble suivant d’investissements dans la sécurité Windows. Il est conçu pour offrir ces garanties de sécurité :

  • Protéger et maintenir l’intégrité du système au démarrage
  • Vérifier que l’intégrité du système a été réellement conservée via l’attestation locale et distante

Maintien de l’intégrité du système au démarrage

Racine statique de confiance pour la mesure (SRTM)

Avec Windows 7, l’un des moyens utilisés par les attaquants pour persister et échapper à la détection était d’installer ce qui est souvent appelé bootkit ou rootkit sur le système. Ce logiciel malveillant démarre avant le démarrage de Windows ou pendant le processus de démarrage lui-même, ce qui lui permet de démarrer avec le niveau de privilège le plus élevé.

Avec Windows 10 s’exécutant sur du matériel moderne, une racine de confiance basée sur le matériel permet de s’assurer qu’aucun microprogramme ou logiciel non autorisé (tel qu’un bootkit) ne peut démarrer avant le chargeur de démarrage Windows. Cette racine de confiance basée sur le matériel provient de la fonctionnalité de démarrage sécurisé de l’appareil, qui fait partie de l’interface UEFI (Unified Extensible Firmware Interface). Cette technique de mesure des composants UEFI de démarrage précoce statique est appelée racine statique de confiance pour la mesure (SRTM).

Comme il existe des milliers de fournisseurs de PC qui produisent de nombreux modèles avec différentes versions DU BIOS UEFI, il devient un nombre incroyablement élevé de mesures SRTM lors du démarrage. Il existe deux techniques pour établir l’approbation ici : tenir à jour une liste de mesures SRTM « incorrectes » connues (également appelées listes de blocage) ou une liste de mesures SRTM « bonnes » connues (également appelées liste d’autorisation).

Chaque option présente un inconvénient :

  • Une liste de mesures SRTM « incorrectes » connues permet à un pirate informatique de modifier seulement 1 bit dans un composant pour créer un hachage SRTM entièrement nouveau qui doit être répertorié. Cela signifie que le flux SRTM est intrinsèquement fragile : une modification mineure peut invalider l’ensemble de la chaîne de confiance.
  • Une liste de « bonnes » mesures SRTM connues nécessite que chaque nouvelle mesure de combinaison BIOS/PC soit soigneusement ajoutée, ce qui est lent. En outre, un correctif de bogue pour le code UEFI peut prendre beaucoup de temps pour concevoir, générer, tester à nouveau, valider et redéployer.

Lancement sécurisé : la racine dynamique de confiance pour la mesure (DRTM)

System Guard Secure Launch, introduit pour la première fois dans Windows 10 version 1809, vise à atténuer ces problèmes à l’aide d’une technologie connue sous le nom de Dynamic Root of Trust for Measurement (DRTM). DRTM permet au système de démarrer librement dans du code non approuvé au départ, mais peu de temps après le lance dans un état approuvé en prenant le contrôle de tous les processeurs et en les forçant à descendre un chemin de code bien connu et mesuré. Cela présente l’avantage de permettre au code UEFI précoce non approuvé de démarrer le système, mais de pouvoir ensuite passer en toute sécurité à un état approuvé et mesuré.

Lancement sécurisé de System Guard.

Le lancement sécurisé simplifie la gestion des mesures SRTM, car le code de lancement n’est désormais pas lié à une configuration matérielle spécifique. Cela signifie que le nombre de mesures de code valides est faible et que les futures mises à jour peuvent être déployées plus largement et plus rapidement.

Protection du mode de gestion du système (SMM)

Le mode de gestion du système (SMM) est un mode processeur à usage spécial dans les microcontrôleurs x86 qui gère la gestion de l’alimentation, la configuration matérielle, la surveillance thermique et tout ce que le fabricant juge utile. Chaque fois que l’une de ces opérations système est demandée, une interruption non masquable (SMI) est appelée lors de l’exécution, ce qui exécute le code SMM installé par le BIOS. Le code SMM s’exécute au niveau de privilège le plus élevé et est invisible pour le système d’exploitation, ce qui en fait une cible attrayante pour les activités malveillantes. Même si System Guard Secure Launch est utilisé pour un lancement tardif, le code SMM peut potentiellement accéder à la mémoire de l’hyperviseur et modifier l’hyperviseur.

Pour vous défendre contre cela, deux techniques sont utilisées :

  • Protection de la pagination pour empêcher tout accès inapproprié au code et aux données
  • Supervision et attestation du matériel SMM

La protection de la pagination peut être implémentée pour verrouiller certaines tables de code en lecture seule afin d’empêcher toute falsification. Cela empêche l’accès à toute mémoire qui n’a pas été affectée.

Une fonctionnalité de processeur appliquée au matériel appelée gestionnaire SMI de superviseur peut surveiller le SMM et s’assurer qu’il n’accède à aucune partie de l’espace d’adressage qu’elle n’est pas censée.

La protection SMM repose sur la technologie de lancement sécurisé et nécessite son fonctionnement. À l’avenir, Windows 10 mesurera également le comportement de ce gestionnaire SMI et attestera qu’aucune mémoire appartenant au système d’exploitation n’a été falsifiée.

Validation de l’intégrité de la plateforme après l’exécution de Windows (au moment de l’exécution)

Bien que System Guard offre une protection avancée qui permet de protéger et de maintenir l’intégrité de la plateforme pendant le démarrage et au moment de l’exécution, la réalité est que nous devons appliquer une mentalité de « violation supposée » à nos technologies de sécurité les plus sophistiquées. Nous pouvons être confiants que les technologies font leur travail avec succès, mais nous avons également besoin de la capacité de vérifier qu’elles ont réussi à atteindre leurs objectifs. Pour l’intégrité de la plateforme, nous ne pouvons pas simplement faire confiance à la plateforme, qui pourrait potentiellement être compromise, pour attester de son état de sécurité. System Guard inclut donc une série de technologies qui permettent l’analyse à distance de l’intégrité de l’appareil.

Au démarrage de Windows, System Guard effectue une série de mesures d’intégrité à l’aide du module de plateforme sécurisée 2.0 (TPM 2.0) de l’appareil. System Guard Secure Launch ne prend pas en charge les versions de TPM antérieures, telles que TPM 1.2. Ce processus et ces données sont isolés du matériel de Windows pour garantir que les données de mesure ne sont pas soumises au type de falsification qui pourrait se produire si la plateforme était compromise. À partir de là, les mesures peuvent être utilisées pour déterminer l’intégrité du microprogramme de l’appareil, l’état de configuration matérielle et les composants liés au démarrage de Windows, pour n’en nommer que quelques-uns.

Intégrité de l’heure de démarrage.

Une fois le système démarré, System Guard signe et scelle ces mesures à l’aide du TPM. Sur demande, un système de gestion comme Intune ou Microsoft Configuration Manager peut les acquérir à des fins d’analyse à distance. Si System Guard indique que l’appareil n’est pas intègre, le système de gestion peut effectuer une série d’actions, telles que le refus de l’appareil d’accéder aux ressources.

Conditions d'octroi de licence d'édition Windows

Le tableau suivant répertorie les éditions de Windows qui prennent en charge System Guard :

Windows Pro Windows Entreprise Windows Pro Education/SE Windows Éducation
Oui Oui Oui Oui

Les droits de licence System Guard sont accordés par les licences suivantes :

Windows Pro/Professionnel Éducation/SE Windows Entreprise E3 Windows Entreprise E5 Windows Éducation A3 Windows Éducation A5
Oui Oui Oui Oui Oui

Pour plus d’informations à propos des licences Windows, consultez Vue d’ensemble des licences Windows.

Configuration système requise pour System Guard

Cette fonctionnalité est disponible pour les processeurs suivants :

  • Processeurs Intel® vPro™ commençant par Intel® Coffeelake, Whiskeylake ou silicium ultérieur
  • Processeurs AMD® à partir du silicium Zen2 ou ultérieur
  • Processeurs Qualcomm® avec puces SD850 ou version ultérieure

Configuration requise pour les processeurs Intel® vPro™ à partir d’Intel® Coffeelake, Whiskeylake ou d’un silicium ultérieur

Nom Description
Processeur 64 bits Un ordinateur 64 bits avec un minimum de quatre cœurs (processeurs logiques) est requis pour la sécurité basée sur l’hyperviseur et la virtualisation (VBS). Pour plus d’informations sur Hyper-V, consultez Hyper-V sur Windows Server 2016 ou Présentation d’Hyper-V sur Windows 10. Pour plus d’informations sur l’hyperviseur, consultez Spécifications de l’hyperviseur.
Module de plateforme sécurisée (TPM) 2.0 Les plateformes doivent prendre en charge un TPM discret 2.0. Les TPM intégrés/microprogrammes ne sont pas pris en charge, à l’exception des puces Intel qui prennent en charge la technologie PTT (Platform Trust Technology), qui est un type de TPM matériel intégré qui répond aux spécifications TPM 2.0.
Windows DMA Protection Les plateformes doivent respecter la spécification de protection DMA Windows (tous les ports DMA externes doivent être désactivés par défaut jusqu’à ce que le système d’exploitation les alimente explicitement).
Mémoires tampons de communication SMM Toutes les mémoires tampons de communication SMM doivent être implémentées dans les types de mémoire EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS ou EfiReservedMemoryType.
Tables de pages SMM Ne doit PAS contenir de mappages vers EfiConventionalMemory (par exemple, aucune mémoire appartenant au système d’exploitation/VMM).
Ne doit PAS contenir de mappages aux sections de code dans EfiRuntimeServicesCode.
Ne doit PAS avoir les autorisations d’exécution et d’écriture pour la même page
Doit autoriser UNIQUEMENT que les pages TSEG puissent être marquées comme exécutables et que la carte mémoire doit signaler TSEG EfiReservedMemoryType.
Le gestionnaire SMI du BIOS doit être implémenté de sorte que les tables de pages SMM soient verrouillées sur chaque entrée SMM.
Veille moderne/connectée Les plateformes doivent prendre en charge la veille moderne/connectée.
TPM AUX Index La plateforme doit configurer un index AUX avec un index, des attributs et une stratégie qui correspond exactement à l’index AUX spécifié dans la DG TXT avec une taille de données d’exactement 104 octets (pour les données AUX SHA256). (NameAlg = SHA256)
Les plateformes doivent configurer un index PS (Fournisseur de plateforme) avec :
  • Exactement le style « TXT PS2 » Attributs lors de la création comme suit :
    • AuthWrite
    • StratégieSupprimer
    • WriteLocked
    • WriteDefine
    • AuthRead
    • WriteDefine
    • NoDa
    • Écrit
    • PlateformeCréer
  • Une stratégie exactement PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg et Policy)
  • Taille exacte de 70 octets
  • NameAlg = SHA256
  • En outre, il doit avoir été initialisé et verrouillé (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1) au moment du lancement du système d’exploitation.
Les données d’index PS DataRevocationCounters, SINITMinVersion et PolicyControl doivent toutes être 0x00
Stratégie AUX La stratégie AUX requise doit être la suivante :
  • A = TPM2_PolicyLocality (localité 3 & localité 4)
  • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
  • authPolicy = {A} OR {{A} AND {B}}
  • authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24
TPM NV Index Le microprogramme de la plateforme doit configurer un index NV TPM pour une utilisation par le système d’exploitation avec :
  • Handle : 0x01C101C0
  • Attributs:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Une stratégie de :
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Valeur digeste de 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Microprogramme de la plateforme Le microprogramme de la plateforme doit contenir tout le code requis pour exécuter un lancement sécurisé de la technologie d’exécution approuvée Intel® :
  • Intel® SINIT ACM doit être transporté dans le BIOS OEM
  • Les plateformes doivent être livrées avec un ACM de production signé par le signataire Intel® ACM de production approprié pour la plateforme
Mise à jour du microprogramme de la plateforme Il est recommandé de mettre à jour le microprogramme système via UpdateCapsule dans Windows Update.

Configuration requise pour les processeurs AMD® à partir du silicium Zen2 ou ultérieur

Nom Description
Processeur 64 bits Un ordinateur 64 bits avec un minimum de quatre cœurs (processeurs logiques) est requis pour la sécurité basée sur l’hyperviseur et la virtualisation (VBS). Pour plus d’informations sur Hyper-V, consultez Hyper-V sur Windows Server 2016 ou Présentation d’Hyper-V sur Windows 10. Pour plus d’informations sur l’hyperviseur, consultez Spécifications de l’hyperviseur.
Module de plateforme sécurisée (TPM) 2.0 Les plateformes doivent prendre en charge un module TPM discret 2.0 OU Microsoft Pluton TPM.
Windows DMA Protection Les plateformes doivent respecter la spécification de protection DMA Windows (tous les ports DMA externes doivent être désactivés par défaut jusqu’à ce que le système d’exploitation les alimente explicitement).
Mémoires tampons de communication SMM Toutes les mémoires tampons de communication SMM doivent être implémentées dans les types de mémoire EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS ou EfiReservedMemoryType.
Tables de pages SMM Ne doit PAS contenir de mappages vers EfiConventionalMemory (par exemple, aucune mémoire appartenant au système d’exploitation/VMM).
Ne doit PAS contenir de mappages aux sections de code dans EfiRuntimeServicesCode.
Ne doit PAS avoir les autorisations d’exécution et d’écriture pour la même page
Le gestionnaire SMI du BIOS doit être implémenté de sorte que les tables de pages SMM soient verrouillées sur chaque entrée SMM.
Veille moderne/connectée Les plateformes doivent prendre en charge la veille moderne/connectée.
TPM NV Index Le microprogramme de la plateforme doit configurer un index NV TPM pour une utilisation par le système d’exploitation avec :
  • Handle : 0x01C101C0
  • Attributs:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Une stratégie de :
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Valeur digeste de 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Microprogramme de la plateforme Le microprogramme de la plateforme doit contenir tout le code requis pour exécuter le lancement sécurisé :
  • Les plateformes AMD® Secure Launch doivent être fournies avec le devnode du pilote AMD® DRTM exposé et le pilote AMD® DRTM installé

La protection anti-restauration du microprogramme du processeur AMD® secure doit être activée pour la plateforme
AMD® Memory Guard doit être activé pour la plateforme.
Mise à jour du microprogramme de la plateforme Il est recommandé de mettre à jour le microprogramme système via UpdateCapsule dans Windows Update.

Configuration requise pour les processeurs Qualcomm® avec les circuits microprogrammés SD850 ou ultérieur

Nom Description
Surveiller la communication en mode Toutes les mémoires tampons de communication en mode Moniteur doivent être implémentées dans les sections de données EfiRuntimeServicesData (recommandé), dans les sections de données d’EfiRuntimeServicesCode, comme décrit par les types de mémoire Memory Attributes Table, EfiACPIMemoryNVS ou EfiReservedMemoryType
Tables de pages en mode Moniteur Toutes les tables de pages en mode Moniteur doivent :
  • NE contient pas de mappages vers EfiConventionalMemory (par exemple, aucune mémoire de système d’exploitation/VMM)
  • Ils ne doivent PAS avoir les autorisations d’exécution et d’écriture pour la même page
  • Les plateformes doivent uniquement autoriser les pages en mode Moniteur marquées comme exécutables
  • Le mappage de mémoire doit signaler le mode Moniteur sous la forme EfiReservedMemoryType
  • Les plateformes doivent fournir un mécanisme pour protéger les tables de pages en mode Moniteur contre toute modification
Veille moderne/connectée Les plateformes doivent prendre en charge la veille moderne/connectée.
Microprogramme de la plateforme Le microprogramme de la plateforme doit contenir tout le code requis pour le lancement.
Mise à jour du microprogramme de la plateforme Il est recommandé de mettre à jour le microprogramme système via UpdateCapsule dans Windows Update.