Delen via

Veilige MOR-implementatie

Samenvatting

  • Gedrag van MorLock, revisie 2

Laatst bijgewerkt

  • Augustus 2020

Van toepassing op:

  • Windows 10

  • OEM's en BIOS-leveranciers die de Credential Guard-functie van Windows 10 willen ondersteunen.

Officiële specificaties

Overzicht

In dit onderwerp wordt het gedrag en het gebruik voor de MemoryOverwriteRequestControlLock UEFI-variabele, revisie 2 beschreven.

Om geavanceerde geheugenaanvallen te voorkomen, wordt het bestaande bios-beveiligingsbeperking memoryOverwriteRequestControl verbeterd ter ondersteuning van vergrendeling om te beschermen tegen nieuwe bedreigingen. Het bedreigingsmodel wordt uitgebreid met de hostbesturingssysteemkernel als aanvaller, waardoor ACPI- en UEFI Runtime Services die worden uitgevoerd op kernelbevoegdhedenniveau, niet worden vertrouwd. Net als bij Secure Boot-implementaties moet MorLock worden geïmplementeerd in een context voor het uitvoeren van bevoegde firmware die niet kan worden gemanipuleerd door de kernel van het host-besturingssysteem (bijvoorbeeld systeembeheermodus, TrustZone, BMC, enzovoort). De interface is gebouwd op UEFI-variabeleservices, die worden beschreven in de UEFI-specificatie versie 2.5, sectie 7.2 met de naam Variabele services.

Deze beperking, MorLock genoemd, moet worden geïmplementeerd op alle nieuwe systemen en niet alleen op systemen met Trusted Platform Modules. Revisie 2 voegt een nieuwe mogelijkheid toe, ontgrendelen, om problemen met opstartprestaties te beperken, met name op grote geheugensystemen.

Met betrekking tot de ACPI-_DSM controlemethode voor het instellen van de MOR-bitstatus (zoals beschreven in sectie 6 van pc Client Work Group Platform Reset Attack Mitigation Specification, versie 1.10 (PDF-download)), raden we u aan deze _DSM methode te verwijderen uit moderne BIOS-implementaties.

Als een BIOS echter deze _DSM methode implementeert, moet deze de status van MorLock respecteren. Als de MorLock is vergrendeld, met of zonder een sleutel, moet deze _DSM methode MOR niet wijzigen en een waarde van 1 retourneren die overeenkomt met 'Algemene fout'. Er is geen ACPI-mechanisme gedefinieerd om MorLock-revisie 2 te ontgrendelen.

Houd er rekening mee dat Windows deze _DSM methode niet rechtstreeks heeft aangeroepen sinds Windows 7 en als afgeschaft beschouwt. Sommige BIOS roept deze _DSM methode indirect aan wanneer Windows ACPI _PTS aanroept als een implementatie van MOR Auto Detection of Clean Shutdown (zoals beschreven in sectie 2.3 van pc Client Work Group Platform Reset Attack Mitigation Specification, versie 1.10 (PDF download)).

De ACPI _PTS-implementatie van MOR Auto Detection heeft een veiligheidstekortkoming en mag NIET worden gebruikt.

Beheerslot voor geheugenoverschrijvingsverzoek

BIOS met de verbeterde mitigatie creëert deze UEFI-variabele tijdens het vroege opstarten:

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

Naam:MemoryOverwriteRequestControlLock

Kenmerken: NV+BS+RT

GetVariable-waarde in gegevensparameter : 0x0 (ontgrendeld); 0x1 (vergrendeld zonder sleutel); 0x2 (vergrendeld met sleutel)

SetVariable-waarde in gegevensparameter : 0x0 (ontgrendeld); 0x1 (vergrendeld)

Vergrendelen met SetVariable

Bij elke opstart initialiseert BIOS MemoryOverwriteRequestControlLock als single-bytewaarde 0x00 (wat aangeeft dat het ontgrendeld is) vóór de Boot Device Selection (BDS)-fase (DRIVER###, SYSPREP###, BOOT###, *RECOVERY*, ...). Voor MemoryOverwriteRequestControlLock (en MemoryOverwriteRequestControl) moet het BIOS voorkomen dat de variabele wordt verwijderd en moeten de attributen worden vastgezet op NV+BS+RT.

Wanneer SetVariable voor MemoryOverwriteRequestControlLock het eerst wordt aangeroepen door een geldige niet-nulwaarde door te geven in Gegevens, wordt de toegangsmodus voor beide MemoryOverwriteRequestControlLock gewijzigd in MemoryOverwriteRequestControl alleen-lezen, wat aangeeft dat ze zijn vergrendeld.

Implementaties van revisie 1 accepteren slechts één byte van 0x00 of 0x01 voor MemoryOverwriteRequestControlLock.

Revisie 2 accepteert bovendien een waarde van 8 bytes die een gedeelde geheime sleutel vertegenwoordigt. Als er een andere waarde is opgegeven in SetVariable, mislukt de aanroep met status EFI_INVALID_PARAMETER. Als u die sleutel wilt genereren, gebruikt u een hoogwaardige entropiebron, zoals de Trusted Platform Module of hardware random number generator.

Na het instellen van een sleutel moeten zowel de beller als de firmware kopieën van deze sleutel opslaan op een locatie met vertrouwelijkheidsbeveiliging, zoals SMRAM op IA32/X64 of een serviceprocessor met beveiligde opslag.

De systeemstatus verkrijgen

In revisie 2, wanneer de variabelen MemoryOverwriteRequestControlLock en MemoryOverwriteRequestControl zijn vergrendeld, worden aanroepen van SetVariable eerst gecontroleerd op de geregistreerde sleutel met behulp van een algoritme dat in constante tijd werkt. Als beide sleutels aanwezig zijn en overeenkomen, worden de variabelen teruggezet naar een ontgrendelde status. Na deze eerste poging of als er geen sleutel is geregistreerd, mislukken volgende pogingen om deze variabele in te stellen met EFI_ACCESS_DENIED om beveiligingsaanvallen te voorkomen. In dat geval is het opnieuw opstarten van het systeem de enige manier om de variabelen te ontgrendelen.

Het besturingssysteem detecteert de aanwezigheid van MemoryOverwriteRequestControlLock en de status door GetVariable aan te roepen. Het systeem kan vervolgens de huidige waarde MemoryOverwriteRequestControl vergrendelen door de MemoryOverwriteRequestControlLock waarde in te stellen op 0x1. U kunt ook een sleutel opgeven om ontgrendeling in de toekomst mogelijk te maken nadat geheime gegevens veilig uit het geheugen zijn verwijderd.

GetVariable aanroepen voor MemoryOverwriteRequestControlLock retourneert 0x0, 0x1 of 0x2 om aan te geven dat ontgrendeld, vergrendeld zonder sleutel of vergrendeld is met sleutelstatussen.

Instelling MemoryOverwriteRequestControlLock wordt niet opgeslagen in het flashgeheugen (wijzigt alleen de interne vergrendelingsstatus). Als u de variabele ophaalt, wordt de interne status geretourneerd en wordt de sleutel nooit weergegeven.

Voorbeeld van gebruik door het besturingssysteem:

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);

MorLock-implementatiestroom

Deze stroomdiagrammen tonen het verwachte gedrag van uw implementatie:

Initialisatie

morlock-initialisatie.

SetVariable-stroom

morlock programmering flow.

Ontgrendelde statusstroom voor SetVariable

morlock ontgrendelde gegevensstroom.

Vergrendelde statusstroom voor SetVariable

morlock vergrendelde stroom.

Proces voor GetVariable

morlock getvariable.

Zie ook

UEFI-vereisten die van toepassing zijn op alle Windows-edities op SoC-platforms

Pc Client Work Group Platform Reset Attack Mitigation Specification, versie 1.10 (PDF download)

BitLocker beveiligen tegen koude aanvallen (en andere bedreigingen)

Een rondleiding voorbij BIOS met de UEFI TPM2-ondersteuning in EDKII

Afgeleide domeinreferenties beveiligen met Credential Guard-

UEFI-specificaties

  • Last updated on