Спецификация проверки безопасности оборудования

  • Статья

Введение

HSTI защищает от неправильной настройки функций безопасности на устройствах Windows. Для клиентов HSTI обеспечивает лучшую защиту компьютера, приобретенного по умолчанию. Для IHV и IBV HSTI гарантирует, что ваши обещания безопасности хранятся. Для изготовителей оборудования и ODM легко убедитесь, что системы, которые вы отправляете, безопасно настроены из коробки и будут оставаться безопасными, не создавая собственные решения.

Результаты тестов HSTI будут использоваться тестами совместимости Windows и могут использоваться для проверки правильности настройки устройств для включения поддерживаемых функций безопасности. Эти тесты могут использоваться для идентификации незащищенных инженерных устройств в поле, например инженерных устройств, которые могут содержать небезопасные ключи тестирования. Результаты этих тестов могут использоваться ОС Windows для отображения водяного знака (или аналогичного индикатора) на небезопасных устройствах.

Примечание.

  Платформа необходима для реализации аппаратного интерфейса и совместного использования документации и средств, указанных в этом разделе.

Фон

Ожидается, что читатель узнает основы UEFI и имеет представление о технологиях безопасной загрузки, включая раздел 27 "Безопасность" спецификации UEFI и NIST SP 800-147.

Это требование имеет три аспекта:

  • Независимые интерфейсы платформы для запроса состояний безопасности оборудования и встроенного ПО
  • Проектирование и необязательный обзор кода описанных выше реализаций интерфейса
  • Общий доступ к документации и средствам

Реализация высокого уровня

The Bitfield

IHV определяет битовое поле, представляющее тестируемые функции безопасности платформы. Это битовое поле полностью охватывает все определяемые биты, доступные для объектов HSTI, возвращаемых любыми тестами IHV, IBV или OEM HSTI. Разработчик IHV должен разработать определение битового поля и предоставить соответствующую документацию, чтобы IBV правильно возвращал результаты своих тестов HSTI.

SecurityFeaturesRequired

Поле SecurityFeaturesRequired используется только в обработке, если поле в объекте IHV HSTI и является методом, с помощью которого IHV определяет битовое поле необходимых функций безопасности.

SecurityFeaturesImplemented

Это битовое поле функций безопасности, реализованных тестами, возвращающими объект HSTI.

SecurityFeaturesVerified

Это битовое поле функций безопасности, которые были проверены тестами, возвращающими объект HSTI.

Рекомендации по реализации

IHV разрабатывает эталонные проекты безопасности для своих платформ, которые соответствуют требованиям совместимости Windows. Кроме того, IHV и IBV также реализуют программные тесты, которые проверяют правильное включение эталонных реализаций безопасности и сообщают результаты с помощью аппаратного интерфейса тестирования безопасности. Эти тесты доставляются в OEM и ODM как скомпилированные модули (не источник) и должны работать без изменений. Если OEM/ODM отклоняется от эталонных проектов безопасности, эти тестовые модули могут сообщать о сбоях, а OEM/ODM потребуется связаться с корпорацией Майкрософт, чтобы просмотреть изменения и реализовать дополнительный экземпляр HSTI, который сообщает об этих исключениях. Изготовители оборудования должны иметь возможность использовать эти модули безопасности без изменений, необходимых для выполнения эталонной разработки и документации. Изготовители оборудования, которые хотят добавить дополнительные модули безопасности или изменить поведение любого модуля безопасности, должны пройти проверку разработки с корпорацией Майкрософт.

В рамках реализации средств реализации модуля тестов будет содержаться структура. Прототип этой структуры представлен ниже в разделе "Прототип". IHV определяет значение каждого бита в справочнике по безопасности проверка list. IHV будет далее определять смысл каждого бита в битовых полях. Наконец, IHV включает в себя битовое поле "Обязательно" в структуре OEM, и для всех требований, которые они могут тестировать программным способом, они будут устанавливать бит в битовом поле "Реализовано".

IBVs и OEM могут задавать биты в поле "Реализовано", если они представили дизайн для прогаматически проверка для присутствия функций безопасности, представленных этими битами корпорации Майкрософт. Если эти тесты проходят, они могут задать поле "Проверено" в соответствующих структуры.

Тестовые модули для IHV, IBV и OEM должны выполняться при наличии. Значение true, заданное битом в поле SecurityFeaturesEnabled, указывает на результат прохождения теста. Если тест не выполняется или не проходит, значение 0 должно быть задано для репрезентативного бита.

Пример логики обработки результатов

Этот пример представляет логику, которая будет использоваться обработкой результатов. Реализованные битовые поля должны соответствовать формату, который означает, что реализовано 1, а 0 — не реализовано. Если что-то реализовано, это необходимо. Результаты битовых полей должны соответствовать формату, который 0 означает, что не удалось или тест не присутствует, а 1 означает только утвердительно переданный только.

После вычисления всех результатов битовое поле IHV Results будет NXORd с их обязательным битом. Все битовые поля, отличные от IHV, являются ANDed с соответствующими реализованными битами. Полученные битовые поля являются все ORd вместе, чтобы получить общие результаты. Результат передачи этой операции будет битовое поле, состоящее из полностью 1s.

Доставить и ответственность

Независимые поставщики оборудования (IHV) и независимые поставщики BIOS (IBV)

Поставщики и поставщики силиконовой платформы, поддерживающие Подключение резервные системы, должны реализовать независимые интерфейсы платформы для запроса соответствующих состояний безопасности оборудования и встроенного ПО на своих эталонных платформах. Эти реализации должны быть доставлены в виде скомпилированных модулей. Рекомендуется подписать эти модули, и при запуске проверка подписи выполняется сигнатура. Цель состоит в том, чтобы запрашивать аппаратные и встроенное ПО и состояния, чтобы сообщить о надлежащей подготовке безопасности платформы.

ИЗГОТОВИТЕЛИ и ODM

Изготовители оборудования и ODM не должны изменять или изменять тесты HSTI, предоставляемые им поставщиками. Изготовители оборудования и ODM должны гарантировать, что их системы будут передавать тесты HSTI в качестве компонента требований к сертификации Windows:

Требование к сертификации оборудования Windows — Windows 8.1 WHCR

  • System.Fundamentals.Firmware.UEFISecureBoot
  • System.Fundamentals.Firmware.CS.UEFISecureBoot. Подключение edStandby

Вместо изменения, если изготовителю оборудования требуется метод для предоставления альтернативного метода для обеспечения той же или более эффективной безопасности, то изготовитель оборудования может предоставить дополнительные проверка безопасности. Проверка безопасности OEM должны полностью охватывать один тест безопасности IHV или IBV. Прежде чем использовать, изготовители оборудования должны отправляться в проверку проектирования корпорацией Майкрософт и подчиняются тем же требованиям к документации и раскрытию средств, что и другие поставщики тестов HSTI. После утверждения от Корпорации Майкрософт изготовитель оборудования может включать тесты безопасности, которые расширяются на тестах IHV и IBV.

Обратите внимание, что аттестация OEM не требуется в рамках проектирования HSTI. HSTI не является списком требований для OEM, это интерфейс для обеспечения эффективного программного тестирования безопасности встроенного ПО, аппаратных и параметров конфигурации.

Интерфейсы состояния безопасности

Интерфейсы основаны на протоколе сведений об адаптере EFI, определенном в UEFI версии 2.4.

Интерфейс состояния безопасности платформы

Резюме

Сведения о безопасности платформы. Возвращает сведения о соответствии платформы требованиям к системе сертификации оборудования Windows.Fundamentals.Firmware.CS.UEFISecureBoot, System.Fundamentals.FIRMWARE.CS.UEFISecureBoot.ПодключениеedStandby и System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning.

Прототип

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

Соответствующий InformationBlock:

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;
Срок Description

Версия

Возврат PLATFORM_SECURITY_VERSION_VNEXTCS

Роль

Роль издателя этого интерфейса. Предполагается, что конструкторы эталонной платформы, такие как IHVs и IBV, возвращают PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE и PLATFORM_SECURITY_ROLE_PLATFORM_IBV соответственно. Если тестовые модули из конструкторов не могут полностью проверить все функции безопасности, то разработчикам платформы, изготовителям оборудования и ODM потребуется опубликовать этот интерфейс с ролью реализации.

ImplementationID

Доступный для чтения поставщик, модель и версия этой реализации. Например, "SiliconVendorX Chip1234 v1" и "BIOSvendorY BIOSz v2".

SecurityFeaturesSize

Размер массивов SecurityFeaturesRequired и SecurityFeaturesEnabled в байтах. Массивы должны иметь одинаковый размер.

SecurityFeaturesRequired

Определяемое IHV битовое поле, соответствующее всем функциям безопасности, которые должны быть реализованы в соответствии с требованиями безопасности, определенными в PLATFORM_SECURITY_VERSION версии. Например, для удовлетворения версии могут потребоваться 7 функций, может быть сообщено значение 0b0111111.

SecurityFeaturesImplemented

Определяемое издателем битовое поле, соответствующее всем функциям безопасности, которые реализовали программные тесты в этом модуле.

SecurityFeaturesVerified

Определяемое издателем битовое поле, соответствующее всем функциям безопасности, которые были проверены этой реализацией.

ErrorString

Строка, завершающаяся значением NULL, одна ошибка для каждой строки (CR/LF завершена) с уникальным идентификатором, который OEM/ODM может использовать для поиска документации, которая будет описывать шаги по исправлению сбоя. Рекомендуется url-адрес документации. Пример: 

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

Рекомендации по управлению памятью

В целях совместимости между модулями HSTI разработчики должны использовать AllocatePool() и не AllocatePages().

Обзор разработки реализации HSTI

Корпорация Майкрософт должна проводить предварительные проверки проектирования всех реализаций тестового интерфейса. Примеры вопросов, которые могут быть заданы в обзоре дизайна, приведены в разделе "Рекомендации по проектированию HSTI".

Необязательные проверки кода

Разработчики HSTI могут запрашивать проверки кода, выполненные корпорацией Майкрософт. Проверка кода может быть предоставлена на основе приоритета и доступности ресурсов и не гарантируется. Проверки кода будут проходить в соответствии с соглашением о неразглашении.

Общий доступ к документации и средствам

Поставщики силиконовой и встроенного ПО должны предоставлять корпорации Майкрософт все необходимые справочные документы и средства, связанные с безопасностью, которые они предоставляют изготовителям оборудования. Эта документация и средства должны быть доступны не позднее, чем они предоставляются изготовителям оборудования Windows. Это должно включать в себя, но не ограничивается всеми документами и инструментами, связанными с слиянием, установкой и обновлением встроенного ПО, восстановлением встроенного ПО и загрузкой, аппаратным диагностика, встроенного ПО диагностика и диагностика загрузки. Эта документация и средства должны быть полностью достаточной для выполнения проверка HSTI в лабораторной среде.

Рекомендации по проектированию HSTI

Ниже приведен иллюстрированный список рекомендаций по проектированию, которые должен учитывать разработчик HSTI для реализации HSTI. Это не строгий список требований, а также исчерпывающий список рекомендаций. В качестве разработчика HSTI вы будете писать тесты, чтобы проверить функции безопасности, которые вы работаете в направлении максимально полного охвата. Перед обзором дизайна в Корпорации Майкрософт мы рекомендуем ознакомиться с этим списком вдохновения и учесть, что корпорация Майкрософт, скорее всего, хочет, чтобы при реализации этих функций вы тестировали их как можно более подробно.

Проверки HSTI поставщиков и поставщиков (IHV)

  1. Вы используете только RSA 2048 и SHA256 (или аналогичную силу шифрования)
  2. Код встроенного ПО должен присутствовать в защищенном хранилище
    1. Вы защищаете спифлаш?
    2. Реализуйте только чтение до сброса для секций eMMC
    3. Поддерживается ли проверка подписанного встроенного ПО. Встроенное ПО, установленное OEM, либо доступно только для чтения, либо защищено безопасным процессом обновления встроенного ПО.
  3. Процесс обновления безопасного встроенного ПО
    1. По умолчанию выполняется ли процесс безопасного обновления встроенного ПО с помощью ключей тестирования? (РЕКОМЕНДУЕТСЯ)
    2. Вы проверка, если тестовые ключи используются в рабочей среде?
    3. Разрешить откат до небезопасной версии встроенного ПО? Если да, то что такое механизм защиты? Очистить TPM при откате?
  4. У вас есть внутренниеdoors для переопределения SecureBoot
    1. Поддерживает ли ваша система встроенные запросы на обход Secureboot? Если да, то он отключен, пока включено SecureBoot?
    2. У вас есть производственные бэкдоры? Вы проверка, чтобы они были отключены во время включения SecureBoot и всегда отключены в рабочей системе?
  5. [CS] Поддержка целостности загрузки
    1. Поддерживается ли целостность загрузки и включена ли она по умолчанию?
    2. Платформа использует память локального ввода-диска или однократного программирования (OTP) для хранения начального кода загрузки и обеспечивает логику сброса питания для выполнения из локального диска или безопасного встроенного SRAM.
  6. [CS] Защита от внутренней и внешней DMA
    1. Сохраняется ли внутренняя DMA только для компонентов, необходимых во время загрузки? И отключен для всех остальных компонентов.
    2. Вы сохраняете внешнюю DMA только для компонентов, необходимых во время загрузки? И отключен для всех остальных компонентов.
    3. Если встроенное ПО имеет возможность включить и отключить защиту DMA, конфигурация доставки должна иметь защиту от DMA по умолчанию
    4. Какие автобусы и устройства (плавки, подсистемы безопасности, TZ, видео, кэши, IMEM, память ядра) могут получить доступ DMA к разным областям NV и переменным регионам хранения и как они защищены?
    5. Поддерживается ли реализация bit-модуля MOR
  7. Защита от отладчика внешнего оборудования
    1. Поддерживаете ли вы JTAG? Параметр JTAG OFF, если SecureBoot включен
    2. Предоставляется ли серверная часть производства для отключения защиты JTAG? Вы проверка, если этот внутренний вход отсутствует в рабочих системах?
    3. Очистить TPM при включении JTAG?
    4. Поддерживается ли любой другой аппаратный отладчик? И сделайте то же самое проверка для него.
  8. Правильно ли вы подготовили секрет для каждого устройства?
  9. Что такое плавки безопасности у вас (у конкретного поставщика)
    1. SoC SecureBoot fuse
    2. Уникальные секреты для каждого устройства, такие как подтверждение или encypherment fuses
    3. Плавки JTAG
    4. FUSE обработчика приложений SOC SecureBoot
    5. SoC МБ A Processor SecureBoot fuse
    6. SoC Modern Processor SecureBoot fuse
    7. Любые другие специальные плавки SOC для вашей платформы

Проверки IBV HSTI

  1. Вы используете только RSA 2048 и SHA256 (или выше, но не ниже этого)
  2. Модули поддержки совместимости (CSM)
    1. Вы предоставляете возможность включить CSM
    2. Вы проверка блокировку загрузки CSM при включении SecureBoot
    3. [CS] Вы проверка, если CSM не присутствует в системах CS постоянно
  3. Код встроенного ПО должен присутствовать в защищенном хранилище
    1. Вы защищаете спифлаш?
    2. Реализуйте только чтение до сброса для секций eMMC
    3. Поддерживается ли проверка подписанного встроенного ПО. Встроенное ПО, установленное OEM, либо доступно только для чтения, либо защищено безопасным процессом обновления встроенного ПО.
  4. Процесс обновления безопасного встроенного ПО
    1. По умолчанию выполняется ли процесс безопасного обновления встроенного ПО с помощью ключей тестирования?
    2. Вы проверка, если тестовые ключи используются в рабочей среде?
    3. Разрешить откат до небезопасной версии встроенного ПО? Если да, то что такое механизм защиты? Очистить TPM при откате?
    4. Используются ли тестовые ключи?
  5. У вас есть внутренниеdoors для переопределения SecureBoot
    1. Поддерживает ли ваша система встроенные запросы на обход Secureboot? Если да, то он отключен, пока включено SecureBoot?
    2. У вас есть производственные бэкдоры? Вы проверка, чтобы они были отключены во время включения SecureBoot и всегда отключены в рабочей системе?
  6. [CS] Защита от внутренней и внешней DMA
    1. Сохраняется ли внутренняя DMA только для компонентов, необходимых во время загрузки? И отключен для всех остальных компонентов.
    2. Вы сохраняете внешнюю DMA только для компонентов, необходимых во время загрузки? И отключен для всех остальных компонентов.
    3. Если встроенное ПО имеет возможность включить и отключить защиту DMA, конфигурация доставки должна иметь защиту от DMA по умолчанию
    4. Какие автобусы и устройства (плавки, подсистемы безопасности, TZ, видео, кэши, IMEM, память ядра) могут получить доступ DMA к разным областям NV и переменным регионам хранения и как они защищены?
    5. Поддерживается ли реализация bit-модуля MOR