Безопасная реализация MOR

Сводка

  • Поведение MorLock, редакция 2

Последнее обновление

  • Август 2020 г.

Применимо к

  • Windows 10

  • Изготовители оборудования и поставщики BIOS, которые хотят поддерживать функцию Credential Guard Windows 10.

Официальные спецификации

Обзор

В этом разделе описывается поведение и использование переменной MemoryOverwriteRequestControlLock UEFI версии 2.

Чтобы предотвратить расширенные атаки на память, в существующей системной BIOS улучшен механизм MemoryOverwriteRequestControl для поддержки блокировки и защиты от новых угроз. Модель угроз расширяется, чтобы включить ядро ОС узла в качестве злоумышленника, поэтому службы среды выполнения ACPI и UEFI, выполняемые на уровне привилегий ядра, не являются доверенными. Подобно реализации безопасной загрузки, MorLock следует реализовать в привилегированном контексте выполнения встроенного ПО, который не может быть изменен ядром операционной системы узла (например, в режиме управления системой, TrustZone, BMC и т. д.). Интерфейс основан на службах переменных UEFI, которые описаны в спецификации UEFI версии 2.5, разделе 7.2 с именем "Службы переменных".

Это решение, называемое MorLock, должно быть реализовано во всех новых системах, а не только в системах с доверенными платформенными модулями. Версия 2 добавляет новую возможность, разблокировку, чтобы устранить проблемы с производительностью загрузки, особенно в крупных системах памяти.

Что касается метода управления ACPI _DSM для настройки битового состояния MOR (как описано в разделе 6 спецификации сброса рисков атак для клиентских рабочих групп ПК, версия 1.10 (скачивание PDF)), мы рекомендуем удалить этот метод _DSM из современных реализаций BIOS.

Однако если BIOS реализует этот метод _DSM, он должен уважать состояние MorLock. Если MorLock заблокирован любым способом, с ключом или без него, этот метод _DSM не должен изменять MOR и должен вернуть значение 1, соответствующее "General Failure". Для разблокировки MorLock версии 2 не определен механизм ACPI.

Обратите внимание, что Windows не напрямую вызвал этот метод _DSM с Windows 7 и считает его устаревшим. Некоторые BIOS косвенно вызывают этот метод _DSM, когда Windows вызывает ACPI _PTS для реализации автоматического обнаружения чистого завершения работы MOR (как описано в разделе 2.3 спецификации по смягчению атак сброса платформы клиентских ПК, версия 1.10 (скачивание PDF)).

Эта реализация ACPI _PTS для автоматического обнаружения MOR небезопасна и не должна использоваться.

Контроль блокировки запроса перезаписи памяти (MemoryOverwriteRequestControlLock)

BIOS, содержащая улучшенную защиту, создает эту переменную UEFI во время ранней загрузки:

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

Имя: MemoryOverwriteRequestControlLock

Атрибуты: NV+BS+RT

Значение GetVariable в параметре Data : 0x0 (разблокировано); 0x1 (заблокирован без ключа); 0x2 (заблокировано ключом)

Значение SetVariable в параметре Data : 0x0 (разблокировано); 0x1 (заблокировано)

Блокировка с помощью SetVariable

При каждой загрузке BIOS должен инициализировать MemoryOverwriteRequestControlLock в однобайтовое значение 0x00 (указывающие на разблокированное состояние) перед этапом выбора загрузочного устройства (DRIVER####, SYSPREP####, BOOT####, *RECOVERY*, ...). Для MemoryOverwriteRequestControlLock (и MemoryOverwriteRequestControl) BIOS должен предотвращать удаление переменной, и атрибуты должны быть закреплены на NV+BS+RT.

При первом вызове SetVariable путем передачи допустимого ненулевого значения в Data, режим доступа для обоих MemoryOverwriteRequestControlLock и MemoryOverwriteRequestControl изменяется на «только чтение», указывая, что они заблокированы.

Реализация версии 1 принимает только один байт 0x00 или 0x01 для MemoryOverwriteRequestControlLock.

Версия 2 также принимает 8-байтовое значение, представляющее общий секретный ключ. Если любое другое значение указано в SetVariable, вызов завершается сбоем с состоянием EFI_INVALID_PARAMETER. Чтобы создать этот ключ, используйте высококачественный источник энтропии, например доверенный модуль платформы или генератор случайных чисел оборудования.

После установки ключа вызывающий объект и встроенное ПО должны сохранять копии этого ключа в защищенном конфиденциальном расположении, например SMRAM в IA32/X64 или обработчике служб с защищенным хранилищем.

Получение состояния системы

Во втором пересмотре, когда переменные MemoryOverwriteRequestControlLock и MemoryOverwriteRequestControl заблокированы, вызовы SetVariable (для этих переменных) сначала проверяются на соответствие зарегистрированному ключу с помощью алгоритма постоянного времени. Если оба ключа присутствуют и соответствуют, переменные возвращаются в разблокированное состояние. После первой попытки или если ключ не зарегистрирован, последующие попытки установить эту переменную заканчиваются с ошибкой EFI_ACCESS_DENIED, чтобы предотвратить атаки методом подбора. В этом случае перезагрузка системы должна быть единственным способом разблокировки переменных.

Операционная система обнаруживает наличие MemoryOverwriteRequestControlLock и его состояние путем вызова GetVariable. Затем система может заблокировать текущее значение MemoryOverwriteRequestControl , задав MemoryOverwriteRequestControlLock значение 0x1. Кроме того, он может указать ключ для включения разблокировки в будущем после безопасной очистки секретных данных из памяти.

Вызов GetVariable для MemoryOverwriteRequestControlLock возвращает 0x0, 0x1 или 0x2 для указания состояний: разблокировано, заблокировано без ключа или заблокировано с ключом.

Параметр MemoryOverwriteRequestControlLock не записывается в флеш-память (просто изменяет состояние внутренней блокировки). Получение переменной возвращает внутреннее состояние и никогда не предоставляет ключ.

Пример использования ОС:

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

Эти блок-схемы показывают ожидаемое поведение реализации:

Инициализация

инициализация Morlock.

Поток SetVariable

поток программирования Morlock.

Разблокированный поток состояния для SetVariable

морлок разблокировал поток.

Заблокированный поток состояния для SetVariable

морлок заблокировал поток.

Поток для GetVariable

morlock getvariable.

См. также

требования UEFI, применимые ко всем выпускам Windows на платформах SoC

Спецификация по смягчению атак перезапуска платформы рабочей группы ПК, версия 1.10 (скачать PDF)

Защита BitLocker от холодных атак (и других угроз)

Обзор возможностей за пределами BIOS с поддержкой TPM2 в UEFI EDKII

Защита производных учетных данных домена с помощью Credential Guard

Спецификации UEFI

  • Last updated on