Réduction de la surface d'attaque des microprogrammes (FASR)
En octobre 2019, Microsoft a travaillé en étroite collaboration avec nos partenaires OEM et Silicon pour lancer les PC à cœur sécurisé. Ces appareils sont dotés de fonctionnalités profondément intégrées au niveau du matériel, du microprogramme et des logiciels pour contribuer à garantir une sécurité renforcée des appareils, de l'identité et des données. L'un des piliers de la sécurité des PC à cœur sécurisé est la protection des microprogrammes des appareils. Une fonctionnalité matérielle fondamentale requise pour satisfaire ce pilier est la racine de confiance dynamique pour les mesures (D-RTM). Cependant, peu d'appareils offrent D-RTM aujourd'hui en raison de la dépendance à l'égard du jeu de puces sous-jacent pour la prise en charge de cette fonctionnalité, ce qui entrave notre engagement à contribuer à élever et à maintenir un niveau de sécurité élevé pour tous les appareils Windows.
Il est possible de faire davantage pour améliorer la sécurité de tous les appareils Windows, y compris ceux qui ne sont pas dotés de la technologie D-RTM. Microsoft travaille avec ses partenaires pour surmonter les problèmes de compatibilité qui empêchaient l'application des protections de la mémoire dans les microprogrammes UEFI, en développant un ensemble d'améliorations de la sécurité SMM en open source, afin d'offrir une plus grande flexibilité aux OEM.
Pour refléter cet engagement en faveur de la sécurité des microprogrammes, nous avons défini une nouvelle approche afin de garantir que les appareils puissent répondre aux exigences de protection des microprogrammes des PC à noyau sécurisé.
Vue d’ensemble d’un processus FASR
Pour les PC à noyau sécurisé qui ne disposent pas de capacités D-RTM matérielles, nous devons définir un petit ensemble de composants de microprogrammes qui présentent une surface d'attaque réduite et qui peuvent être attestés dans le système d'exploitation. Cette approche est appelée réduction de la surface d'attaque des microprogrammes (FASR). Pour que les microprogrammes basés sur FASR puissent s'adapter aux PC de différents fournisseurs, une nouvelle approche du processus de démarrage des microprogrammes a dû être définie.
FASR prend en charge deux chemins d'amorçage :
Parcours d'entraînement certifié :
Seul le code approuvé, signé et intégré par Microsoft est autorisé à s'exécuter.
Toute altération du chemin d'amorçage est détectable par le système d'exploitation.
La figure ci-dessous montre le flux de démarrage de FASR S-RTM sur le chemin d'amorçage certifié. Ce chemin d'amorçage permet d'éviter l'exécution d'un code de microprogramme de plate-forme inattendu. Cependant, il utilise certaines données spécifiques à la plate-forme fournies par le chemin d'amorçage personnalisé. Le diagramme suivant illustre le flux d'amorçage FASR sur le chemin d'amorçage certifié.
Chemin d'amorçage personnalisé : Tous les microprogrammes de la plate-forme peuvent être exécutés. Les informations critiques de démarrage spécifiques à un OEM/une plate-forme particulière sont converties en données sur le chemin d'amorçage personnalisé et utilisées par le chemin d'amorçage certifié pour configurer correctement le système sur ce chemin d'amorçage. Le diagramme suivant illustre le flux d'amorçage FASR sur le chemin d'amorçage personnalisé.
Un appareil FASR activé pour la conformité au PC à noyau sécurisé utilise par défaut le chemin d'amorçage certifié, à moins qu'un événement n'entraîne le passage au chemin d'amorçage personnalisé au début du processus d'amorçage du microprogramme. Il peut s'agir, par exemple, d'une mise à jour du microprogramme, d'une requête de l'utilisateur pour une interface utilisateur du microprogramme ou d'un choix de l'utilisateur de désactiver Secured-core PC, ce qui signifie qu'il démarrera toujours sur le chemin d'amorçage personnalisé jusqu'à ce qu'il soit réactivé.
Le démarrage personnalisé peut être utilisé pour démarrer n'importe quel système d'exploitation ou logiciel tiers pris en charge par le microprogramme de la plateforme sur un appareil compatible avec FASR, mais Windows ne reconnaîtra pas le démarrage sur le chemin de démarrage personnalisé comme étant conforme à Secured-core PC.
Pour mieux comprendre les technologies de sécurité qui sous-tendent FASR, nous aimerions vous donner un bref aperçu du processus de démarrage de Windows.
Processus de démarrage de Windows
La racine de la confiance
L'exécution initiale du microprogramme dans un PC moderne suit un processus de démarrage dans lequel un premier ensemble de code charge d'autres codes, et le niveau de fonctionnalité s'étend au fur et à mesure que le démarrage progresse. Chaque ensemble de code vérifie l'ensemble de code suivant, formant ainsi une chaîne de confiance. Lorsque le microprogramme UEFI prend le contrôle, il suit la norme Secure Boot qui consiste à vérifier les signatures des logiciels afin de poursuivre la chaîne de confiance jusqu'au système d'exploitation. Ensuite, le chargeur de démarrage de Windows poursuit la chaîne de confiance avec Trusted Boot, qui vérifie tous les autres composants du système d'exploitation dans le processus de démarrage avant qu'ils ne soient chargés.
En général, les attaquants cherchent à prendre le contrôle le plus tôt possible dans le processus de démarrage, avant que les fonctionnalités de sécurité et les verrous qui aident à protéger le système ne soient activés. Lorsque le système est réinitialisé, le premier ensemble de code exécuté doit être ancré dans la confiance. La technologie de vérification matérielle qui joue le rôle de vérification précoce du code est appelée racine de confiance. Bien que les détails exacts varient d'un fournisseur de matériel à l'autre, toutes les racines de confiance sont généralement ancrées dans du matériel ou des ROM immuables dans le SOC.
Démarrage mesuré
Le démarrage sécurisé ancré dans une racine de confiance permet de s'assurer que la signature numérique de tous les microprogrammes est vérifiée ; toutefois, il est également souhaitable de disposer d'un enregistrement des microprogrammes exécutés. Le programme de compatibilité matérielle de Windows exige que tous les PC Windows 10 et Windows 11 intègrent une puce appelée module de plateforme de confiance (TPM). Le TPM contient des emplacements de mémoire appelés registres de configuration de la plateforme (PCR). Chaque PCR contient le hachage d'un type de code et/ou de données chargé lors du démarrage, comme le code du microprogramme sur l'appareil de stockage non volatile (par exemple, la flash SPI), les ROM d'option des périphériques PCI ou le chargeur de démarrage du système d'exploitation. La taille d'une valeur pouvant être stockée dans une PCR est déterminée par la taille du condensé de l'algorithme de hachage pris en charge. Par exemple, une PCR SHA-1 peut stocker 20 octets, tandis qu'une PCR SHA-2 peut stocker 32 octets. Plusieurs PCR associées au même algorithme de hachage sont appelées une banque. La spécification du profil TPM du TCG PC Client définit l'inclusion d'au moins une banque PCR avec 24 registres.
En présence d'un TPM, chaque composant du microprogramme peut également mettre à jour ou étendre la PCR appropriée au fur et à mesure que du nouveau code et des données sont chargés dans le processus de démarrage. Le processus d'extension met à jour la valeur de la PCR pour qu'elle corresponde à la sortie de l'algorithme de hachage en utilisant la valeur actuelle de la PCR concaténée avec le nouveau code ou les nouvelles données en tant qu'argument d'entrée. Il en résulte que les PCR peuvent être inspectées après le processus de démarrage pour déterminer ce qui a été exécuté. Cela permet au logiciel du système d'exploitation de comprendre si le processus de démarrage a été différent des précédents. Dans un environnement sensible à la sécurité, le système d'exploitation peut être informé de l'ensemble exact des mesures de code attendues dans certaines PCR afin de détecter l'exécution d'un code microprogramme inattendu. Étant donné que les 16 premiers PCR d'une banque ne peuvent être réinitialisés qu'en réinitialisant l'ensemble du TPM, ils sont dignes de confiance et constituent l'emplacement privilégié pour le stockage des mesures importantes dans le TPM.
La base de confiance pour les mesures
Maintenant que nous avons examiné le rôle d'une racine de confiance et la manière dont Measured Boot est utilisé, nous allons nous pencher sur deux approches courantes pour établir une racine de confiance pour le signalement d'une chaîne de mesure au TPM : statique et dynamique.
Une racine de confiance statique pour les mesures (S-RTM) établit la confiance lors de la réinitialisation du système et exige qu'elle soit maintenue tout au long du processus de démarrage. Si la confiance est compromise à un moment quelconque du processus de démarrage, elle est irrécupérable jusqu'à la réinitialisation du système. Le diagramme suivant illustre l'utilisation de S-RTM sur le chemin d'amorçage certifié.
En revanche, la racine de confiance dynamique pour la mesure (D-RTM) ne fait confiance qu'à une petite partie du code du microprogramme d'initialisation du chipset, ainsi qu'à un agent matériel qui est utilisé pour rétablir la confiance de manière dynamique pendant le démarrage. Le système peut initialement démarrer avec un microprogramme non fiable mais, peu de temps après le lancement, il revient à un état de confiance en prenant le contrôle de tous les processeurs et en les forçant à suivre un chemin bien connu et mesuré. Le diagramme suivant donne un aperçu d'un flux D-RTM traditionnel.
Il y a un compromis entre S-RTM et D-RTM. Le S-RTM ne nécessite pas de capacités matérielles particulières, mais requiert un logiciel pour mieux prendre en compte le code exécuté pendant toute la durée du démarrage. Le D-RTM nécessite des capacités matérielles spéciales mais permet aux logiciels de passer à un état de confiance de manière dynamique pendant la durée de vie du système.
Les PC à noyau sécurisé Windows ont utilisé un D-RTM dans le cadre du lancement sécurisé afin de permettre à un large éventail de fabricants de systèmes de mettre en œuvre des fonctionnalités et des expériences uniques dans le microprogramme, tout en veillant à ce que le système puisse atteindre un état fiable et mesuré, acceptable pour héberger un environnement de système d'exploitation sécurisé. Un événement de lancement D-RTM est utilisé pour rétablir la confiance à partir d'un environnement inconnu avant de charger un noyau sécurisé. Le diagramme suivant montre l'événement de lancement D-RTM pour rétablir un environnement système connu.
Dans le passé, S-RTM pouvait être mis en œuvre dans un plus grand nombre d'appareils en raison de son absence de dépendance à l'égard de capacités matérielles spéciales pour vérifier l'état de sécurité du système, mais le système d'exploitation ne disposait pas d'une méthode fiable pour confirmer qu'il pouvait se fier aux mesures rapportées sur un appareil Windows donné utilisant S-RTM.
Améliorations de la sécurité des microprogrammes
Réduire au minimum les composants du microprogramme dans le chemin d'accès au système d'exploitation
L'un des moyens de se fier aux mesures S-RTM consiste à réduire les composants du microprogramme autorisés à s'exécuter à un ensemble minimal. Si tous les appareils utilisant le S-RTM utilisaient le même ensemble de microprogrammes, le système d'exploitation n'aurait à se fier qu'à un seul ensemble de valeurs PCR attendues pour ces composants connus et fiables. Avec cette approche basée sur le SRTM, on peut considérer qu'un appareil répond à l'exigence de protection des microprogrammes des PC à noyau sécurisé lorsque l'ensemble des microprogrammes de démarrage est vérifié pour ne contenir que des logiciels signés par Microsoft et pouvant être attestés par Windows. Pour mieux comprendre en quoi ces microprogrammes diffèrent de ceux d'un PC normal, examinons le processus de démarrage avant et après.
En raison de la flexibilité et de la richesse des fonctionnalités offertes par les microprogrammes modernes des PC, le code qui s'exécute avant le système d'exploitation présente une surface d'attaque accrue. Le diagramme suivant montre un exemple de processus de démarrage S-RTM traditionnel.
Les principales responsabilités du microprogramme pendant le démarrage peuvent être grandement simplifiées :
Spécifique à la plate-forme : Fonctionnalité qui s'applique uniquement à la conception matérielle de la plateforme spécifique.
Non spécifique à une plate-forme : Fonctionnalité qui est standard dans l'industrie et commune à d'autres matériels.
Un sous-ensemble relativement restreint de microprogrammes modernes est généralement spécifique à une plate-forme. Une grande partie du code de l'infrastructure du microprogramme qui exécute des tâches communes telles que l'allocation de mémoire, l'envoi de pilotes de microprogrammes, la gestion d'événements, etc. est identique pour tous les systèmes (ou la plupart des systèmes) basés sur l'UEFI. Les pilotes binaires de microprogrammes pour ces tâches peuvent être réutilisés d'un PC à l'autre. En outre, les spécifications et interfaces matérielles standard de l'industrie permettent aux pilotes de microprogrammes communs d'initialiser les disques durs, les contrôleurs USB et d'autres périphériques. Les pilotes de microprogrammes pour ce matériel peuvent également être réutilisés d'un PC à l'autre. En résumé, les PC peuvent être démarrés avec un ensemble minimal de pilotes de microprogrammes communs.
La réduction de l'ensemble des pilotes de microprogrammes chargés lors du démarrage peut présenter d'autres avantages :
Amélioration du temps de démarrage
Moins de coordination entre les fournisseurs pour les mises à jour
Réduction de l'exposition aux bogues
Réduction de la surface d'attaque
Vérification du chemin d'amorçage FASR et conformité au noyau sécurisé
Pour qu'un système FASR réponde aux exigences de protection du microprogramme des PC Secured-core, il doit avoir démarré sur le chemin d'amorçage certifié. Le microprogramme FASR facilite cette tâche en fournissant au système d'exploitation un manifeste signé par Microsoft appelé manifeste FASR (mesuré dans le TPM) qui contient les valeurs PCR attendues pour la séquence de démarrage du module sur le chemin certifié. Ce manifeste peut être comparé à la séquence de démarrage réelle qui s'est produite sur le chemin certifié. Si ces mesures correspondent, le système est considéré comme ayant satisfait à l'exigence de protection du microprogramme du programme PC à noyau sécurisé. Tout écart par rapport à la séquence de démarrage certifiée attendue entraîne des mesures inattendues dans les registres de configuration de la plate-forme (PCR) du TPM que le système d'exploitation détecte.
En outre, Windows ne libérera les secrets protégés par l'hyperviseur qu'après avoir validé le manifeste FASR signé par rapport aux mesures enregistrées pendant le démarrage en cours. Si, lors d'un démarrage certifié ou d'une mise à jour de capsule, le manifeste FASR n'est pas présent, la vérification de la signature échoue ou une erreur de PCR se produit, et les secrets du VSM ne seront pas descellés ou migrés.
Comment le microprogramme FASR aborde les protections de la mémoire et le SMM
Maintenant qu'un binaire unique signé par Microsoft et doté d'un ensemble minimal de fonctionnalités a été défini, il peut inclure les protections de sécurité fondamentales mais manquantes du microprogramme que Microsoft travaille avec ses partenaires à mettre sur le marché. Le chemin d'amorçage certifié doit au minimum répondre aux exigences suivantes :
Le code ne lit pas/écrit sur NULL/Page 0
Les sections de code et de données de l'image sont séparées.
Les sections d'image sont alignées sur une limite de page (4 Ko).
Les données sont uniquement allouées dans les types de mémoire de données et le code dans les types de mémoire de code.
Les images de code ne sont pas chargées à partir du code distribué sous forme de binaires UEFI (uniquement les répartiteurs désignés).
Le code reste dans les limites des tampons de mémoire alloués avec des pages de garde autour des allocations de pages.
Les débordements de pile peuvent être détectés
Le code ne s'exécute pas à partir de la pile
La caractéristique /NXCOMPAT DLL est définie pour activer les protections NX.
Les ROM d'option tierces, les applications UEFI et les pilotes UEFI n'ont souvent pas été construits ou validés par rapport à cet ensemble d'exigences. Par conséquent, ils ne s'exécuteront pas sur le chemin d'amorçage certifié. Le chemin d'amorçage personnalisé peut éventuellement choisir d'abaisser le niveau de protection requis, mais ce chemin d'amorçage n'est pas considéré comme conforme à Secured-core PC par le système d'exploitation.
Mode de gestion du système (SMM)
Le SMM est un mode de fonctionnement spécial du processeur dans l'architecture x86. Il présente un défi unique pour la sécurité du système car le code exécuté dans l'environnement SMM est opaque pour le système d'exploitation et s'exécute généralement au niveau de privilège le plus élevé (parfois appelé « Ring -2 ») de tout logiciel sur le processeur hôte. Dès son entrée, le SMM configure son propre environnement en établissant la table des pages, la table de répartition des interruptions (IDT) et d'autres structures du système. Le SMM représente une surface d'attaque importante qui pourrait être utilisée par un code malveillant pour compromettre ou contourner les protections du système d'exploitation activées par la sécurité basée sur la virtualisation (VBS). Afin d'atténuer le danger que représente le SMM, la fonctionnalité du SMM peut être conceptuellement divisée en deux parties : l'infrastructure centrale du SMM et les pilotes du SMM, comme suit :
Le cœur du SMM : Code commun à toutes les implémentations de SMM, assurant des responsabilités en matière d'architecture et d'infrastructure.
Pilotes SMM : Code écrit pour accomplir une tâche spécifique à une plateforme dans SMM
Les moments clés du cycle de vie de SMM sont les suivants :
Lorsque la fondation (ou le cœur) du SMM est établie - le chargement initial du programme (IPL) du SMM.
Lorsque les pilotes de SMM sont chargés - ce que l'on appelle la répartition des pilotes de SMM.
Lorsque l'entrée dans le SMM se produit - par le biais d'une interruption de la gestion du système (SMI).
Le chargement initial du programme SMM (IPL)
Le processeur possède des fonctionnalités spéciales qui confèrent au code SMM ses privilèges élevés et contribuent à le protéger. Par exemple, un mécanisme est défini pour entrer dans le SMM via des événements logiciels ou matériels, une instruction du processeur est utilisée pour revenir du SMM, et plusieurs registres sont définis pour contrôler l'accès et verrouiller la configuration du SMM. Nombre de ces registres de contrôle sont configurés par le code IPL du SMM pour restreindre l'accès à la zone de mémoire où sont stockés le code et les données du SMM (appelée System Management RAM ou SMRAM).
Comme la zone SMRAM se trouve dans la mémoire principale (DRAM), elle ne peut pas être établie tant que la DRAM n'est pas activée pendant le démarrage. Les procédures d'activation de la DRAM varient selon les fournisseurs de silicium, mais plusieurs mégaoctets de code peuvent être exécutés directement à partir du cache LLC du processeur (y compris le code qui initialise la DRAM) avant que la mémoire principale ne soit disponible.
Le microprogramme FASR introduit le point IPL SMM plus tôt dans le démarrage que la plupart des autres systèmes. Cela réduit la possibilité pour un attaquant de saper ce processus et de prendre le contrôle du système avant que le SMM ne soit configuré. Pour mieux comprendre ce point et les autres améliorations apportées au SMM dans le microprogramme FASR, nous devons en savoir plus sur le processus d'amorçage du microprogramme.
Initialisation de la plate-forme (PI) dans le microprogramme UEFI
Les microprogrammes modernes pour PC sont construits autour de nombreuses spécifications. La spécification UEFI définit l'interface entre un système d'exploitation compatible UEFI comme Windows et le microprogramme de l'appareil. Une autre spécification, appelée spécification PI (Platform Initialization), définit la manière dont les pilotes de microprogrammes sont construits et détaille le processus de démarrage lui-même. À un niveau élevé, la spécification UEFI peut être considérée comme l'une des normalisations permettant à une seule image Windows de fonctionner avec un grand nombre d'appareils différents, et la spécification PI peut être considérée comme l'une des normalisations permettant à un grand nombre d'images de microprogrammes provenant de différents fournisseurs de matériel de fonctionner ensemble. Les deux spécifications sont maintenues par le Forum UEFI.
La spécification PI définit les phases de démarrage et les pilotes qui sont écrits dans les phases de démarrage. Pendant le démarrage du microprogramme, chaque phase passe le relais à la suivante et, dans la plupart des cas, les pilotes de la phase qui passe le relais ne sont plus utilisés et seules les données importantes sont transmises à la phase suivante afin qu'elle puisse poursuivre le processus de démarrage. Les phases de démarrage peuvent être résumées comme suit :
SEC - Prise de contrôle au niveau du vecteur de réinitialisation du processeur et passage du code assembleur au code C pour charger le PEI.
PEI - Initialisation de l'état du système pour charger DXE et initialiser la DRAM
DXE - Effectuer le reste de l'initialisation du système, ce qui inclut la fourniture du support dont le BDS a besoin pour charger un système d'exploitation.
BDS - Découvrir l'option d'amorçage pour l'amorçage actuel (par exemple, le chargeur d'amorçage du système d'exploitation) et tenter d'amorcer cette option.
OS - Le noyau du système d'exploitation
Protection du chargement de programme initial (IPL) du SMM
Les microprogrammes traditionnels conformes aux spécifications PI de l'UEFI chargent l'IPL du SMM lors de la phase de démarrage DXE. Les microprogrammes FASR chargent l'IPL du SMM dans la phase d'amorçage PEI. La Trusted Computing Base (TCB) d'un système est l'ensemble des mécanismes de protection qui le protègent, y compris le matériel, les microprogrammes et les logiciels. En déplaçant l'IPL SMM de DXE à PEI, toute la phase DXE (qui est un environnement plus vaste et plus riche que PEI) est supprimée de la TCB. Le diagramme suivant montre que l'IPL SMM est déplacé plus tôt dans le processus de démarrage de l'UEFI.
Les codes PEI et DXE s'exécutent au niveau de l'anneau 0 et ne persistent pas (à quelques exceptions près) dans le système d'exploitation. Le code SMM s'exécute avec un privilège plus élevé que l'anneau 0 (et l'hyperviseur) et persiste dans le système d'exploitation, de sorte que le fait de ne pas permettre à une vulnérabilité DXE d'avoir un impact sur l'établissement du SMM réduit la surface d'attaque du système dans son ensemble. En outre, comme SMM est lancé plus tôt dans le processus de démarrage, les bits de verrouillage définis pour aider à protéger SMM peuvent être activés plus tôt dans le démarrage, ce qui minimise encore la fenêtre d'un attaquant pour compromettre SMM.
Protection du processus de distribution du pilote SMM
La spécification PI définit deux modes SMM : MM traditionnel et MM autonome. Le mode MM traditionnel est équivalent au modèle logiciel SMM historiquement utilisé dans les microprogrammes conformes à la spécification PI, qui constituent la plupart des microprogrammes UEFI de l'industrie. Standalone MM est un mode relativement nouveau qui révise le modèle historique afin d'améliorer la sécurité de l'environnement SMM et d'éviter les erreurs courantes commises dans les implémentations Traditional MM qui ont conduit à de nombreux problèmes de portabilité et de sécurité au fil des ans.
Le microprogramme FASR fonctionne exclusivement en mode MM autonome. Cela permet au microprogramme FASR de suivre une approche disciplinée de l'exécution logicielle dans l'environnement SMM. De nos jours, de nombreuses vulnérabilités basées sur le SMM sont dues à de mauvaises pratiques autorisées dans le code SMM en mode MM traditionnel, qui peuvent être simplement supprimées en mode MM autonome. À un niveau élevé, cela se produit parce que dans le modèle MM traditionnel, un pilote SMM est distribué deux fois, une fois par le distributeur DXE dans l'anneau 0, et une autre fois par le distributeur SMM dans le SMM. Le code du pilote exécuté dans l'environnement DXE a donc tout le loisir de mettre en cache des pointeurs vers des ressources situées en dehors de la SMRAM auxquelles il ne devrait pas accéder après le retour du point d'entrée. Les attaques qui dépendent du code SMM pour appeler du code en dehors de SMM sont souvent appelées « attaques par appel SMM ».
Protection de l'entrée dans le SMM
Les données sont transmises à un gestionnaire SMI par l'intermédiaire d'une structure appelée « tampon de communication ». Le gestionnaire SMI est chargé de valider si les données répondent à certaines exigences dans son point d'entrée. La table d'atténuation de la sécurité Windows SMM (WSMT) est un mécanisme utilisé pour atténuer la menace que les gestionnaires SMI non contrôlés font peser sur la sécurité basée sur la virtualisation dans le système d'exploitation. Microsoft a contribué au code du projet TianoCore afin d'améliorer la validation du tampon de communication. Outre l'application de ces deux techniques, le code FASR met également en œuvre des protections strictes de l'accès à la mémoire, permettant au code SMM de n'accéder qu'aux plages de mémoire explicitement autorisées.
Superviseur du mode de gestion (MM Supervisor)
Le code de base du SMM est commun et partagé avec un minimum de changements, voire aucun, entre les systèmes. La surface d'attaque imposée par le SMM peut être considérablement réduite en introduisant la séparation des privilèges dans l'environnement SMM. C'est pourquoi le microprogramme FASR comprend un superviseur SMM qui s'exécute en mode MM autonome. Il en résulte un environnement SMM bien défini avec un TCB minimal dont les niveaux de privilèges sont appliqués dès la création. Le superviseur MM impose des restrictions sur les accès aux ports d'E/S, aux registres spécifiques au modèle (MSR), aux MMIO, à l'état de sauvegarde du processeur et aux instructions autorisées dans l'environnement SMM. Une stratégie du superviseur SMM est utilisée pour configurer les détails exacts des ressources matérielles à restreindre, et ces détails exacts sont susceptibles d'être modifiés par génération de silicium.
La stratégie a récemment évolué vers une approche de refus par défaut qui réduit considérablement les ressources matérielles disponibles pour le code en dehors du superviseur SMM. Ce superviseur fonctionne sans dépendance matérielle à l'égard de capacités matérielles que l'on ne trouve pas couramment dans les PC modernes.
Le MM Supervisor utilisé dans FASR est open source et disponible dans le référentiel MM Supervisor du projet Mu.
Conformité du système FASR avec les exigences des PC à noyau sécurisé
Le tableau suivant indique les principaux piliers ou objectifs de sécurité des PC à noyau sécurisé, et la manière dont les systèmes FASR démarrant par le chemin certifié peuvent répondre aux exigences des PC à noyau sécurisé :
| Avantages de sécurité | Fonctionnalités de sécurité des PC à noyau sécurisé |
|---|---|
| Création d'une racine de confiance soutenue par le matériel | Démarrage sécurisé |
| Module de plateforme sécurisée 2.0 | |
| Protection DMA (Direct Memory Access) | |
| Protection contre les attaques au niveau du microprogramme (voir note ci-dessous) | Lancement sécurisé de System Guard (D-RTM) ou S-RTM (FASR FW) |
| Isolation du mode de gestion du système (SMM) ou MM autonome avec MM Supervisor (FASR FW) | |
| Protéger le système d’exploitation contre l’exécution de code non vérifié | Intégrité de la mémoire (également connue sous le nom de HVCI) |
| Fournir une vérification et une protection d’identité avancées | Windows Hello |
| Protégez les données critiques en cas de perte ou de vol d'appareils. | Chiffrement BitLocker |
Si le système ne dispose pas de capacités de sécurité avancées pour prendre en charge D-RTM, les exigences de protection du microprogramme peuvent être satisfaites en utilisant une combinaison de S-RTM et de Standalone MM avec MM Supervisor, tous deux offerts par le microprogramme FASR.
Résumé
Il s'agit là de quelques-uns des investissements réalisés par Microsoft pour faire face au nombre croissant d'attaques de microprogrammes qui sévissent aujourd'hui dans l'industrie. En utilisant un code open source pour ces changements, nous donnons à nos partenaires les moyens d'utiliser certains de ces avantages en matière de sécurité, ce qui profitera à l'ensemble de l'écosystème et de l'industrie en général.
L'objectif principal de l'initiative Secured-core PC est de s'assurer que les clients ont accès à certaines des capacités de sécurité les plus avancées disponibles pour les PC Windows. Avec certains de ces changements de microprogrammes, nous nous rapprochons de cet objectif, et nous avons mis à jour les exigences de protection des microprogrammes des PC à noyau sécurisé pour refléter cette inclusion. Pour en savoir plus sur les PC à cœur sécurisé, cliquez ici.