Implémentation sécurisée de MOR

Article
06/15/2023

Résumé

Comportement de MorLock, révision 2

Dernière mise à jour

Août 2020

S’applique à

Windows 10
Oem et fournisseurs de BIOS qui souhaitent prendre en charge la fonctionnalité Credential Guard de Windows 10.

Spécifications officielles

Spécifications UEFI
Spécification d’atténuation des attaques de réinitialisation de la plateforme de groupe de travail du client PC, version 1.10 (téléchargement PDF)

Lectures recommandées

Billet de blog : Protection de BitLocker contre les attaques par froid (et d’autres menaces)
Livre blanc : Visite guidée au-delà du BIOS avec la prise en charge de TPM2 UEFI dans EDKII
Protéger les informations d’identification de domaine dérivées avec la protection des informations d’identification

Vue d’ensemble

Cette rubrique décrit le comportement et l’utilisation de la MemoryOverwriteRequestControlLock variable UEFI, révision 2.

Pour empêcher les attaques de mémoire avancées, l’atténuation de sécurité du BIOS système existante MemoryOverwriteRequestControl est améliorée pour prendre en charge le verrouillage afin de se défendre contre les nouvelles menaces. Le modèle de menace est développé pour inclure le noyau du système d’exploitation hôte en tant qu’adversaire, de sorte que les services d’exécution ACPI et UEFI qui s’exécutent au niveau des privilèges du noyau ne sont pas approuvés. À l’instar des implémentations de démarrage sécurisé, MorLock doit être implémenté dans un contexte d’exécution de microprogramme privilégié qui ne peut pas être falsifié par le noyau du système d’exploitation hôte (par exemple, mode de gestion du système, TrustZone, BMC, etc.). L’interface est basée sur les services de variables UEFI, qui sont décrits dans la spécification UEFI version 2.5, section 7.2 nommée « Services variables ».

Cette atténuation, appelée MorLock, doit être implémentée sur tous les nouveaux systèmes et non seulement limitée aux systèmes dotés de modules de plateforme sécurisée. La révision 2 ajoute une nouvelle fonctionnalité, le déverrouillage, pour atténuer les problèmes de performances de démarrage, en particulier sur les systèmes de mémoire volumineux.

En ce qui concerne la méthode de contrôle ACPI _DSM pour définir l’état du bit MOR (comme décrit dans la section 6 de la spécification d’atténuation des attaques de réinitialisation de la plateforme de groupe de travail du client PC, version 1.10 (téléchargement PDF)), nous vous recommandons de supprimer cette méthode _DSM des implémentations modernes du BIOS.

Toutefois, si un BIOS implémente cette méthode _DSM, il doit respecter l’état de MorLock. Si morLock est verrouillé, avec ou sans clé, cette méthode _DSM doit ne pas modifier MOR et retourner une valeur de 1 correspondant à « Échec général ». Aucun mécanisme ACPI n’est défini pour déverrouiller MorLock revision 2.

Notez que Windows n’a pas appelé directement cette méthode _DSM depuis Windows 7 et la considère déconseillée. Certains BIOS appellent indirectement cette méthode _DSM lorsque Windows appelle ACPI _PTS en tant qu’implémentation de la détection automatique mor de l’arrêt de nettoyage (comme décrit dans la section 2.3 de la spécification d’atténuation des attaques de la plateforme de réinitialisation de groupe de travail du client PC, version 1.10 (téléchargement PDF)).

Cette _PTS implémentation de la détection automatique MOR est insuffisante en matière de sécurité et ne doit PAS être utilisée.

MemoryOverwriteRequestControlLock

Le BIOS contenant l’atténuation améliorée crée cette variable UEFI lors du démarrage précoce :

VendorGuid :{BB983CCF-151D-40E1-A07B-4A17BE168292}

Nom :MemoryOverwriteRequestControlLock

Attributs: NV+BS+RT

Valeur GetVariable dans le paramètre Data : 0x0 (déverrouillé) ; 0x1 (verrouillé sans clé) ; 0x2 (verrouillé avec la clé)

Valeur SetVariable dans le paramètre Data : 0x0 (déverrouillé) ; 0x1 (verrouillé)

Verrouillage avec SetVariable

À chaque démarrage, le BIOS doit s’initialiser MemoryOverwriteRequestControlLock sur une valeur codée sur un octet de 0x00 (indiquant qu’il est déverrouillé) avant la phase de sélection du périphérique de démarrage (BDS) (DRIVER###, SYSPREP####, BOOT###, *RECOVERY*, ...). Pour MemoryOverwriteRequestControlLock (et MemoryOverwriteRequestControl), le BIOS doit empêcher la suppression de la variable et les attributs doivent être épinglés à NV+BS+RT.

Lorsque SetVariable for MemoryOverwriteRequestControlLock est appelé pour la première fois en passant une valeur valide autre que zéro dans Data, le mode d’accès pour les deux MemoryOverwriteRequestControlLock et MemoryOverwriteRequestControl est modifié en lecture seule, indiquant qu’ils sont verrouillés.

Les implémentations de révision 1 n’acceptent qu’un seul octet de 0x00 ou 0x01 pour MemoryOverwriteRequestControlLock.

La révision 2 accepte également une valeur de 8 octets qui représente une clé secrète partagée. Si une autre valeur est spécifiée dans SetVariable, l’appel échoue avec status EFI_INVALID_PARAMETER. Pour générer cette clé, utilisez une source d’entropie de haute qualité, telle que le module de plateforme sécurisée ou le générateur de nombres aléatoires matériels.

Après avoir défini une clé, l’appelant et le microprogramme doivent enregistrer des copies de cette clé dans un emplacement protégé par la confidentialité, tel que SMRAM sur IA32/X64 ou un processeur de services avec stockage protégé.

Obtention de l’état du système

Dans la révision 2, lorsque les MemoryOverwriteRequestControlLock variables et MemoryOverwriteRequestControl sont verrouillées, les appels de SetVariable (pour ces variables) sont d’abord vérifiés par rapport à la clé inscrite à l’aide d’un algorithme à temps constant. Si les deux clés sont présentes et correspondent, les variables reviennent à un état déverrouillé. Après cette première tentative ou si aucune clé n’est inscrite, les tentatives suivantes de définition de cette variable échouent avec EFI_ACCESS_DENIED pour empêcher les attaques par force brute. Dans ce cas, le redémarrage du système est le seul moyen de déverrouiller les variables.

Le système d’exploitation détecte la présence de MemoryOverwriteRequestControlLock et son état en appelant GetVariable. Le système peut ensuite verrouiller la valeur actuelle de MemoryOverwriteRequestControl en définissant la MemoryOverwriteRequestControlLock valeur sur 0x1. Elle peut également spécifier une clé pour activer le déverrouillage à l’avenir après que les données secrètes ont été vidées de la mémoire de manière sécurisée.

L’appel de GetVariable pour MemoryOverwriteRequestControlLock retourne 0x0, 0x1 ou 0x2 pour indiquer déverrouillé, verrouillé sans clé ou verrouillé avec des états de clé.

Le paramètre MemoryOverwriteRequestControlLock ne valide pas sur flash (modifie simplement l’état de verrouillage interne). L’obtention de la variable retourne l’état interne et n’expose jamais la clé.

Exemple d’utilisation par le système d’exploitation :

if (gSecretsInMemory)
{
    char data = 0x11;
    SetVariable(MemoryOverwriteRequestControl, sizeof(data), &data);
}

// check presence
status = GetVariable(MemoryOverwriteRequestControlLock, &value);  

if (SUCCESS(status))
{
    // first attempt to lock and establish a key
    // note both MOR and MorLock are locked if successful

    GetRNG(8, keyPtr);
    status = SetVariable(MemoryOverwriteRequestControlLock, 8, keyPtr);

    if (status != EFI_SUCCESS)
    {
        // fallback to revision 1 behavior
        char data = 0x01;
        status = SetVariable(MemoryOverwriteRequestControlLock, 1, &data);
        if (status != EFI_SUCCESS) { // log error, warn user }
    }
}
else
{
    // warn user about potentially unsafe system
}

// put secrets in memory

// … time passes …

// remove secrets from memory, flush caches

SetVariable(MemoryOverwriteRequestControlLock, 8, keyPtr);