Partager via

Spécification de testabilité de sécurité matérielle

  • Article

Introduction

HSTI protège contre une configuration incorrecte des fonctionnalités de sécurité sur les appareils Windows. Pour les clients, HSTI offre la meilleure garantie de l’effort que la machine qu’ils ont achetée est sécurisée par défaut. Pour les IVS et les IRV, HSTI s’assure que vos promesses de sécurité sont tenues. Pour les OEM et les ODM, assurez-vous facilement que les systèmes que vous expédiez sont configurés de manière sécurisée et qu’ils restent sécurisés, sans avoir à développer des solutions propriétaires.

Les résultats des tests HSTI seront consommés par les tests de compatibilité Windows et peuvent être utilisés pour vérifier que les appareils ont été correctement configurés pour activer les fonctionnalités de sécurité prises en charge. Ces tests peuvent être utilisés pour identifier les appareils d’ingénierie non sécurisés sur le terrain, par exemple, les appareils d’ingénierie qui peuvent contenir des clés de test non sécurisées. Les résultats de ces tests peuvent être utilisés par le système d’exploitation Windows pour afficher un filigrane (ou un indicateur similaire) sur des appareils non sécurisés.

Notes

  La plateforme est nécessaire pour implémenter une interface matérielle et partager la documentation et les outils comme spécifié dans cette rubrique.

Fond

Le lecteur est censé connaître les principes de base de l’UEFI et avoir une compréhension des technologies de démarrage sécurisé, notamment la section 27 « Sécurité » de la spécification UEFI et le NIST SP 800-147.

Cette exigence comporte trois aspects :

  • Interfaces indépendantes de la plateforme pour interroger les états de sécurité du matériel et du microprogramme
  • Conception et révision facultative du code des implémentations d’interface ci-dessus
  • Partage de documentation et d’outils

Implémentation de haut niveau

Champ de bits

L’IHV définit un champ de bits représentant les fonctionnalités de sécurité testables de la plateforme. Ce champ de bits couvre entièrement tous les bits définissables disponibles pour les objets HSTI retournés par les tests HSTI IHV, IBV ou OEM. L’implémenteur IHV doit concevoir la définition du champ de bits et fournir la documentation appropriée pour que les IRV retournent correctement les résultats de leurs tests HSTI.

SecurityFeaturesRequiredred

Le champ SecurityFeaturesRequired est utilisé uniquement dans le traitement lorsqu’un champ dans un objet HSTI IHV est la méthode par laquelle l’IHV définit le champ binaire des fonctionnalités de sécurité requises.

SecurityFeaturesImplemented

Il s’agit d’un champ binaire des fonctionnalités de sécurité implémentées par les tests qui retournent l’objet HSTI.

SecurityFeaturesVerified

Il s’agit d’un champ binaire des fonctionnalités de sécurité qui ont été vérifiées par les tests qui retournent l’objet HSTI.

Instructions d’implémentation

L’IHV développera des conceptions de sécurité de référence pour ses plateformes qui sont conformes aux exigences de compatibilité Windows. En outre, les IHV et les IBV implémentent également des tests programmatiques qui vérifient l’activation correcte des implémentations de sécurité de référence et rapportent les résultats via l’interface de test de sécurité matérielle. Ces tests sont fournis aux ODMs & OEM en tant que modules compilés (et non source) et doivent fonctionner sans modification. Si un OEM/ODM s’écarte des conceptions de sécurité de référence, ces modules de test peuvent signaler des échecs, et l’OEM/ODM devra contacter Microsoft pour passer en revue les modifications et implémenter un instance HSTI supplémentaire qui signale ces exceptions. Les oem doivent être en mesure de tirer parti de ces modules de sécurité sans aucune modification requise en suivant la conception et la documentation de référence. Les oem qui souhaitent ajouter des modules de sécurité supplémentaires ou modifier le comportement d’un module de sécurité doivent faire l’objet d’une révision de conception avec Microsoft.

Dans le cadre de leur implémentation de modules de test, les implémenteurs incluent un struct. Un prototype de ce struct est inclus ci-dessous dans la « section Prototype ». L’IHV définit la signification de chaque bit dans la liste de contrôle des références de sécurité. L’IHV définit davantage la signification de chaque bit dans les champs de bits. Enfin, l’IHV inclut un champ de bits « Obligatoire » dans le struct OEM, et pour toutes les exigences, ils sont en mesure de tester par programmation, ils définissent un bit dans le champ de bits « Implémenté ».

Les IBV et les oem peuvent définir des bits dans le champ « Implémenté » s’ils ont présenté une conception pour case activée de manière progamatique pour la présence des fonctionnalités de sécurité représentées par ces bits à Microsoft. Si ces tests réussissent, ils peuvent définir le champ « Vérifié » dans leurs structs respectifs.

Les modules de test pour IHV, IBV et OEM doivent être exécutés s’ils sont présents. Une valeur true définie sur un bit dans le champ SecurityFeaturesEnabled indique un résultat de test réussi. Si un test n’est pas exécuté ou n’est pas réussi, la valeur 0 doit être définie pour le bit représentatif.

Exemple de logique de traitement des résultats

Cet exemple est représentatif de la logique qui sera utilisée par le traitement des résultats. Les champs de bits implémentés doivent suivre le format 1 signifie implémenté et 0 signifie non implémenté. Si un élément est implémenté, il est nécessaire. Les champs de données de résultats doivent suivre le format 0 signifie échec ou test non présent et 1 signifie affirmativement passé uniquement.

Une fois tous les résultats calculés, le champ de bits résultats IHV est NXORd avec son champ de bits obligatoire. Tous les champs de bits de résultats non IHV sont and avec leurs champs de bits implémentés respectifs. Les champs de bits résultants sont tous ORd ensemble pour obtenir les résultats globaux. Le résultat de cette opération sera un champ de bits composé entièrement de 1s.

Livrables et propriété

Fournisseurs de matériel indépendant (IHV) et fournisseurs de BIOS indépendants (IBV)

Les fournisseurs de silicium et les IBV qui prennent en charge les systèmes de secours connectés doivent implémenter les interfaces indépendantes de la plateforme pour interroger les états de sécurité du matériel et du microprogramme respectifs de leurs plateformes de référence. Ces implémentations doivent être fournies sous forme de modules compilés. Il est préférable que ces modules soient signés et qu’une signature case activée soit effectuée lorsqu’ils sont exécutés. L’objectif est d’interroger les états de conception & du matériel et du microprogramme pour signaler l’approvisionnement de sécurité approprié de la plateforme.

OEM et ODM

Les oem et les ODM ne doivent pas modifier ou falsifier les tests HSTI qui leur ont été fournis par les fournisseurs. Les oem et les ODM sont requis pour garantir que leurs systèmes réussissent les tests HSTI en tant que composant des exigences de certification Windows :

Exigence de certification matérielle Windows - Windows 8.1 WHCR

  • System.Fundamentals.Firmware.UEFISecureBoot
  • System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby

Au lieu d’une modification, si un OEM a besoin d’une méthode pour fournir une autre méthode afin d’assurer la même sécurité ou une meilleure sécurité, cet OEM peut fournir des contrôles de sécurité supplémentaires. Les vérifications de sécurité OEM doivent au moins couvrir entièrement un test de sécurité IHV ou IBV. Avant d’utiliser, les oem doivent se soumettre à un examen de conception par Microsoft et sont soumis aux mêmes exigences de divulgation de documentation et d’outil que les autres fournisseurs de tests HSTI. Après approbation de Microsoft, l’OEM peut inclure des tests de sécurité qui s’étendent aux tests IHV et IBV.

Notez que l’attestation OEM n’est pas requise dans le cadre de la conception HSTI. HSTI n’est pas une liste de conditions requises pour les oem, mais une interface permettant de garantir un test de sécurité par programme efficace des microprogrammes, du matériel et des paramètres de configuration.

Interfaces d’état de sécurité

Les interfaces sont basées sur le protocole EFI Adapter Information Protocol défini dans UEFI version 2.4.

Interface d’état de sécurité de la plateforme

Résumé

Informations sur la sécurité de la plateforme : retourne des informations sur la conformité de la plateforme avec les exigences de certification matérielle Windows System.Fundamentals.Firmware.CS.UEFISecureBoot, System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby et System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning.

Prototype

InformationType

#define ADAPTER_INFO_PLATFORM_SECURITY_GUID \
     {0x6be272c7, 0x1320, 0x4ccd, { 0x90, 0x17, 0xd4, 0x61, 0x2c, 0x01, 0x2b, 0x25 }}

#define PLATFORM_SECURITY_VERSION_VNEXTCS   0x00000003

#define PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE   0x00000001  // IHV
#define PLATFORM_SECURITY_ROLE_PLATFORM_IBV 0x00000002
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_OEM 0x00000003 
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_ODM  0x00000004

Informations correspondantesBlock :

typedef struct { 
    UINT32  Version,
    UINT32  Role,
    CHAR16  ImplementationID[256],
    UINT32  SecurityFeaturesSize,
    UINT8   SecurityFeaturesRequired[],     //Ignored for non-IHV
    UINT8   SecurityFeaturesImplemented[],
    UINT8   SecurityFeaturesVerified[],
    // CHAR16   ErrorString[];
} ADAPTER_INFO_PLATFORM_SECURITY;
Terme Description

Version

Retourner PLATFORM_SECURITY_VERSION_VNEXTCS

Rôle

Rôle de l’éditeur de cette interface. Les concepteurs de plateforme de référence, tels que les IHV et les IRV, sont censés retourner PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE et PLATFORM_SECURITY_ROLE_PLATFORM_IBV respectivement. Si les modules de test des concepteurs ne parviennent pas à vérifier entièrement toutes les fonctionnalités de sécurité, les implémenteurs de plateforme, les oem et les ODM, devront publier cette interface avec un rôle d’Implémenteur.

ImplementationID

Fournisseur, modèle, & version de cette implémentation lisible par l’utilisateur. Par exemple, « SiliconVendorX Chip1234 v1 » et « BIOSvendorY BIOSz v2 ».

SecurityFeaturesSize

Taille en octets des tableaux SecurityFeaturesRequired et SecurityFeaturesEnabled. Les tableaux doivent avoir la même taille.

SecurityFeaturesRequiredred

Champ de bits défini par IHV correspondant à toutes les fonctionnalités de sécurité qui doivent être implémentées pour répondre aux exigences de sécurité définies par PLATFORM_SECURITY_VERSION Version. Par exemple, il peut être nécessaire d’implémenter 7 fonctionnalités pour satisfaire à la version, et une valeur de 0b0111111111 peut être signalée.

SecurityFeaturesImplemented

Champ de bits défini par l’éditeur correspondant à toutes les fonctionnalités de sécurité qui ont implémenté des tests programmatiques dans ce module.

SecurityFeaturesVerified

Champ de bits défini par l’éditeur correspondant à toutes les fonctionnalités de sécurité qui ont été vérifiées implémentées par cette implémentation.

ErrorString

Chaîne terminée par null, un échec par ligne (CR/LF terminé), avec un identificateur unique que l’OEM/ODM peut utiliser pour localiser la documentation qui décrit les étapes de correction de l’échec. Une URL vers la documentation est recommandée. Par exemple,

0x4827 JTAG not disabled http://somewhere.net/docs/remediate4827.html \r\n0x2744 Platform Secure Boot key not provisioned http://somewhere.net/docs/remediate2744.html

Considérations relatives à la gestion de la mémoire

À des fins de compatibilité entre les modules HSTI, les implémenteurs doivent utiliser AllocatePool() et non AllocatePages().

Examen de la conception de l’implémentation de HSTI

Microsoft effectuera des examens préliminaires de la conception de toutes les implémentations d’interface de test. Des exemples de questions qui peuvent être posées lors d’une révision de la conception sont fournis dans la section Considérations relatives à la conception HSTI.

Révisions de code facultatives

Les implémenteurs HSTI peuvent demander des révisions de code effectuées par Microsoft. Les révisions de code peuvent être fournies en fonction de la priorité et de la disponibilité des ressources et ne sont pas garanties. Les révisions de code auront lieu sous réserve d’un accord de non-divulgation.

Partage de documentation et d’outils

Les fournisseurs de microprogrammes et de silicium doivent mettre à la disposition de Microsoft toute la documentation et les outils de référence liés à la sécurité qu’ils fournissent aux oem. Cette documentation et ces outils doivent être mis à disposition au plus tard avant qu’ils ne soient fournis aux oem Windows. Cela doit inclure, sans s’y limiter, toute la documentation et les outils liés à la fusion, à l’installation et à la mise à jour du microprogramme, à la récupération de microprogrammes et de démarrage, à la diagnostics matérielle, au microprogramme diagnostics, & au démarrage diagnostics. Cette documentation et ces outils fournis doivent être entièrement suffisants pour effectuer des vérifications HSTI dans un environnement de laboratoire.

Considérations relatives à la conception HSTI

Voici une liste illustrative des considérations de conception qu’un implémenteur HSTI doit prendre en compte pour son implémentation HSTI. Il ne s’agit pas d’une liste stricte d’exigences, ni d’une liste exhaustive de considérations. En tant qu’implémenteur HSTI, vous allez écrire des tests pour valider les fonctionnalités de sécurité que vous travaillez pour une couverture aussi complète que possible. Avant votre révision de conception avec Microsoft, nous vous recommandons de consulter cette liste pour vous inspirer et de considérer que Microsoft est susceptible de souhaiter que si vous implémentez ces fonctionnalités, vous les testiez aussi largement que possible.

Vérifications HSTI des fournisseurs/fournisseurs de silicium (IHV)

  1. Utilisez-vous RSA 2048 et SHA256 uniquement (ou une force de chiffrement similaire)
  2. Le code du microprogramme doit être présent dans le stockage protégé
    1. Protégez-vous spiflash ?
    2. Implémentez-vous la lecture seule jusqu’à la réinitialisation pour les partitions eMMC
    3. Prenez-vous en charge la vérification des microprogrammes signés : le microprogramme installé par OEM est en lecture seule ou protégé par un processus de mise à jour sécurisé du microprogramme.
  3. Processus de mise à jour du microprogramme sécurisé
    1. Le processus de mise à jour sécurisée du microprogramme est-il activé par défaut avec des clés de test ? (RECOMMANDÉ)
    2. Avez-vous case activée si des clés de test sont utilisées en production ?
    3. Autorisez-vous la restauration vers une version de microprogramme non sécurisée ? Si oui, quel est le mécanisme de protection ? Effacez-vous le module de plateforme sécurisée lorsque la restauration se produit ?
  4. Avez-vous des portes dérobées pour remplacer SecureBoot
    1. Votre système prend-il en charge l’invite inline à contourner Secureboot ? Si oui, est-il désactivé alors que SecureBoot est activé ?
    2. Avez-vous des portes dérobées de fabrication? Avez-vous case activée pour qu’ils soient désactivés alors que SecureBoot est activé et toujours désactivé dans le système de production ?
  5. [CS] Prise en charge de l’intégrité du démarrage
    1. Prenez-vous en charge l’intégrité de démarrage et est-elle activée par défaut ?
    2. La plateforme utilise une MÉMOIRE ROM sur site ou One-Time mémoire programmable (OTP) pour stocker le code de démarrage initial et fournit une logique de réinitialisation de mise sous tension pour s’exécuter à partir d’une ROM sur support ou d’une mémoire SRAM sécurisée.
  6. [CS] Protection contre les DMA internes et externes
    1. Maintenez-vous la DMA interne activée uniquement pour les composants requis pendant le démarrage ? Et est désactivé pour tous les autres composants.
    2. Conservez-vous DMA externe activé uniquement pour les composants requis pendant le démarrage ? Et est désactivé pour tous les autres composants.
    3. Si le microprogramme dispose d’une option permettant d’activer et de désactiver la protection DMA, la protection DMA doit être activée par défaut pour la configuration de l’expédition
    4. Quels bus/appareils (fusibles, moteurs de sécurité, TZ, vidéo, caches, IMEM, mémoire du noyau) sont capables d’accéder DMA à différentes régions de stockage NV et volatiles et comment sont-ils protégés ?
    5. Prenez-vous en charge l’implémentation de bits MOR
  7. Protection contre le débogueur matériel externe
    1. Prenez-vous en charge JTAG ? JTAG OFF quand SecureBoot est activé
    2. Fournissez-vous une porte dérobée de fabrication pour désactiver la protection JTAG ? Vous case activée si cette porte dérobée n’est pas présente dans les systèmes de production ?
    3. Effacez-vous le module de plateforme sécurisée lorsque JTAG est activé ?
    4. Prenez-vous en charge un autre débogueur matériel ? Et faites les mêmes vérifications pour elle.
  8. Avez-vous correctement provisionné le secret unique par appareil ?
  9. Quels sont les fusibles de sécurité dont vous disposez (propre au fournisseur)
    1. Fusible SOC SecureBoot
    2. Secrets uniques par appareil, tels que les fusibles d’approbation ou de chiffrement
    3. Fusibles JTAG
    4. Fusible secureBoot du processeur SOC Apps
    5. Fusible du processeur SOC MBA SecureBoot
    6. Fusible secureBoot du processeur moderne SOC
    7. Tout autre fusible spécifique SOC pour votre plateforme

Vérifications IBV HSTI

  1. Utilisez-vous RSA 2048 et SHA256 uniquement (ou une version ultérieure, mais pas inférieure à celle-ci)
  2. Modules de prise en charge de compatibilité (CSM)
    1. Fournissez-vous une option pour activer CSM
    2. Avez-vous case activée blocage du chargement de CSM lorsque SecureBoot est activé
    3. [CS] Vous case activée si CSM n’est pas présent de façon permanente sur les systèmes CS
  3. Le code du microprogramme doit être présent dans le stockage protégé
    1. Protégez-vous spiflash ?
    2. Implémentez-vous la lecture seule jusqu’à la réinitialisation pour les partitions eMMC
    3. Prenez-vous en charge la vérification des microprogrammes signés : le microprogramme installé par OEM est en lecture seule ou protégé par un processus de mise à jour sécurisé du microprogramme.
  4. Processus de mise à jour du microprogramme sécurisé
    1. Le processus de mise à jour sécurisée du microprogramme est-il activé par défaut avec des clés de test ?
    2. Avez-vous case activée si des clés de test sont utilisées en production ?
    3. Autorisez-vous la restauration vers une version de microprogramme non sécurisée ? Si oui, quel est le mécanisme de protection ? Effacez-vous le module de plateforme sécurisée lorsque la restauration se produit ?
    4. Des clés de test sont-elles utilisées ?
  5. Avez-vous des portes dérobées pour remplacer SecureBoot
    1. Votre système prend-il en charge l’invite inline à contourner Secureboot ? Si oui, est-il désactivé alors que SecureBoot est activé ?
    2. Avez-vous des portes dérobées de fabrication? Avez-vous case activée pour qu’ils soient désactivés alors que SecureBoot est activé et toujours désactivé dans le système de production ?
  6. [CS] Protection contre les DMA internes et externes
    1. Maintenez-vous la DMA interne activée uniquement pour les composants requis pendant le démarrage ? Et est désactivé pour tous les autres composants.
    2. Conservez-vous DMA externe activé uniquement pour les composants requis pendant le démarrage ? Et est désactivé pour tous les autres composants.
    3. Si le microprogramme dispose d’une option permettant d’activer et de désactiver la protection DMA, la protection DMA doit être activée par défaut pour la configuration de l’expédition
    4. Quels bus/appareils (fusibles, moteurs de sécurité, TZ, vidéo, caches, IMEM, mémoire du noyau) sont capables d’accéder DMA à différentes régions de stockage NV et volatiles et comment sont-ils protégés ?
    5. Prenez-vous en charge l’implémentation de bits MOR