Windows Defender System Guard : Comment une racine de confiance basée sur le matériel contribue à protéger Windows 10

Pour protéger les ressources critiques telles que la pile 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.

Windows Defender System Guard réorganise les fonctionnalités d’intégrité système Windows 10 existantes sous un même toit et configure le prochain ensemble 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 maintenue par le biais d’une attestation locale et à distance

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

Racine statique de l’approbation pour la mesure (SRTM)

Avec Windows 7, l’un des moyens utilisés par les attaquants pour conserver et échapper à la détection était d’installer ce qu’on appelle souvent un kit de démarrage ou un 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 (c’est-à-dire Windows 8 certifié ou supérieur), une racine de confiance basée sur le matériel permet de s’assurer qu’aucun microprogramme ou logiciel non autorisé (tel qu’un kit de démarrage) ne peut démarrer avant le chargeur de démarrage Windows. Cette racine d’approbation matérielle 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 statiques 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 au démarrage. Il existe deux techniques pour établir la confiance ici : conserver une liste de mesures SRTM « incorrectes » connues (également appelées listes bloquées) ou une liste de mesures SRTM « correctes » connues (également appelées liste verte).

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 toute la chaîne d’approbation.
  • Une liste de « bonnes » mesures SRTM connues nécessite que chaque nouvelle mesure combinée 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, retester, valider et redéployer.

Lancement sécurisé : racine dynamique de l’approbation pour la mesure (DRTM)

Windows Defender lancement sécurisé de System Guard, introduit dans Windows 10 version 1809, vise à atténuer ces problèmes en tirant parti d’une technologie appelée « racine dynamique de confiance pour la mesure » (DRTM). DRTM permet au système de démarrer librement dans du code non approuvé initialement, mais peu de temps après le lancement du système dans un état approuvé en prenant le contrôle de toutes les processeurs et en les forçant à descendre un chemin de code bien connu et mesuré. Cela a l’avantage de permettre au code UEFI précoce non approuvé de démarrer le système, mais de 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 plus lié à une configuration matérielle spécifique. Cela signifie que le nombre de mesures de code valides est faible et que les mises à jour futures peuvent être déployées plus largement et plus rapidement.

Protection du mode de gestion système (SMM)

Le mode de gestion système (SMM) est un mode UC à 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 qu’une de ces opérations système est demandée, une interruption non masquable (SMI) est appelée au moment de l’exécution, 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 le lancement sécurisé de System Guard est utilisé pour le lancement en retard, 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 pagination pour empêcher l’accès inapproprié au code et aux données
  • Supervision et attestation matérielleSMM

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

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

La protection SMM s’appuie 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 (durée d’exécution)

Bien que Windows Defender System Guard offre une protection avancée qui aidera à protéger et à 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 » à même nos technologies de sécurité les plus sophistiquées. Nous pouvons faire confiance au fait 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 être compromise, pour attester elle-même de son état de sécurité. Ainsi, Windows Defender System Guard inclut une série de technologies qui permettent l’analyse à distance de l’intégrité de l’appareil.

À mesure que Windows 10 démarre, une série de mesures d’intégrité sont prises par Windows Defender System Guard à 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 antérieures du module de plateforme sécurisée, telles que TPM 1.2. Ce processus et ces données sont isolés du matériel de Windows pour vous assurer 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 Windows, pour n’en nommer que quelques-uns.

Intégrité du temps de démarrage.

Après le démarrage du système, Windows Defender System Guard signe et scelle ces mesures à l’aide du module TPM. Sur demande, un système de gestion comme Intune ou Microsoft Endpoint Configuration Manager peut les acquérir pour une analyse à distance. Si Windows Defender 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’accès de l’appareil aux ressources.

Configuration système requise pour System Guard

Pour les processeurs Intel® vPro™ commençant par Intel® Coffeelake, Whiskylake ou un silicium ultérieur Description
Processeur 64bits Un ordinateur 64 bits avec un minimum de quatre cœurs (processeurs logiques) est requis pour l’hyperviseur et la sécurité basée sur 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 prises en charge un module TPM 2.0 discret. Les modules TPM intégrés/microprogrammes ne sont pas pris en charge, à l’exception des puces Intel qui prennent en charge platform trust technology (PTT), qui est un type de module 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 d’autorisations d’exécution et d’écriture pour la même page
Doit autoriser uniquement que les pages TSEG puissent être marquées exécutables et que la carte mémoire doit signaler TSEG EfiReservedMemoryType.
Le gestionnaire SMI BIOS doit être implémenté de telle 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 le 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 les attributs de style « TXT PS2 » lors de la création, comme suit :
    • AuthWrite
    • PolicyDelete
    • WriteLocked
    • WriteDefine
    • AuthRead
    • WriteDefine
    • Noda
    • Écrit
    • PlatformCreate
  • Une stratégie de 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} OU {{A} ET {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 qu’il soit utilisé 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} OU {{A} ET {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 nécessaire 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.
Pour les processeurs AMD® commençant par le silicium Zen2 ou ultérieur Description
Processeur 64bits Un ordinateur 64 bits avec un minimum de quatre cœurs (processeurs logiques) est requis pour l’hyperviseur et la sécurité basée sur 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 prises en charge un module TPM 2.0 OU TPM Microsoft Pluton discret.
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 d’autorisations d’exécution et d’écriture pour la même page
Le gestionnaire SMI BIOS doit être implémenté de telle 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 qu’il soit utilisé 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} OU {{A} ET {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 de lancement sécurisé AMD® doivent être livrées avec le devnode du pilote AMD® DRTM exposé et le pilote AMD® DRTM installé

La protection anti-restauration du microprogramme du processeur sécurisé AMD® doit être activée sur la plateforme
AmD® Memory Guard doit être activé sur la plateforme.
Mise à jour du microprogramme de la plateforme Il est recommandé de mettre à jour le microprogramme système via UpdateCapsule dans Windows Update.
Pour les processeurs Qualcomm® avec des chipsets SD850 ou ultérieurs Description
Surveiller la communication en mode Toutes les mémoires tampons de communication en mode Moniteur doivent être implémentées dans EfiRuntimeServicesData (recommandé), les sections de données de EfiRuntimeServicesCode comme décrit par la table des attributs de mémoire, EfiACPIMemoryNVS ou les types de mémoire EfiReservedMemoryType
Tableaux de page du mode Surveiller Toutes les tables de page mode Moniteur doivent :
  • NE contient aucun mappage à EfiConventionalMemory (par exemple, aucune mémoire appartenant au système d’exploitation/VMM)
  • Ils ne doivent PAS avoir d’autorisations d’exécution et d’écriture pour la même page
  • Les plateformes doivent autoriser uniquement les pages en mode Moniteur marquées comme exécutables
  • La carte mémoire doit signaler le mode Moniteur en tant qu’EfiReservedMemoryType
  • Les plateformes doivent fournir un mécanisme pour protéger les tables de page 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 nécessaire au lancement.
Mise à jour du microprogramme de la plateforme Il est recommandé de mettre à jour le microprogramme système via UpdateCapsule dans Windows Update.