System Guard: как аппаратный корень доверия помогает защитить Windows

  • Статья
  • Применяется к:
    ✅ Windows 11, ✅ Windows 10

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

System Guard реорганизует существующие функции целостности системы Windows под одной крышей и создает следующий набор инвестиций в безопасность Windows. Он предназначен для обеспечения следующих гарантий безопасности:

  • Защита и поддержание целостности системы при запуске
  • Убедитесь, что целостность системы действительно поддерживается с помощью локальной и удаленной аттестации

Поддержание целостности системы при запуске

Статический корень доверия для измерения (SRTM)

В Windows 7 одним из средств, которые злоумышленники будут использовать для сохранения и уклонения от обнаружения, было установить в системе то, что часто называют bootkit или rootkit. Эта вредоносная программа запускается до запуска Windows или во время самого процесса загрузки, что позволяет ему запускаться с наивысшим уровнем привилегий.

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

Поскольку существуют тысячи поставщиков КОМПЬЮТЕРов, которые производят множество моделей с различными версиями UEFI BIOS, при загрузке становится невероятно большое количество измерений SRTM. Для установления доверия здесь существуют два метода: ведение списка известных "плохих" измерений SRTM (также известного как список блокировок) или список известных "хороших" измерений SRTM (также известный как список разрешений).

У каждого варианта есть недостаток:

  • Список известных "плохих" измерений SRTM позволяет хакеру изменить только 1 бит в компоненте, чтобы создать совершенно новый хэш SRTM, который должен быть указан в списке. Это означает, что поток SRTM по своей сути является хрупким — незначительное изменение может привести к аннулированию всей цепочки доверия.
  • Список известных "хороших" измерений SRTM требует тщательного добавления каждого нового комбинированного измерения BIOS/PC, что происходит медленно. Кроме того, исправление ошибок для кода UEFI может занять много времени для разработки, сборки, повторного тестирования, проверки и повторного развертывания.

Безопасный запуск — динамический корень доверия для измерения (DRTM)

System Guard Secure Launch, впервые появившиеся в Windows 10 версии 1809, призваны устранить эти проблемы, используя технологию, известную как динамический корень доверия для измерения (DRTM). DRTM позволяет системе свободно загружаться в ненадежный код, но вскоре после запуска системы в доверенное состояние, принимая под контроль все ЦП и заставляя их сбой хорошо известного и измеряемого пути кода. Это позволяет ненадежный ранний код UEFI загружать систему, но затем безопасно переходить в доверенное и измеряемое состояние.

System Guard безопасный запуск.

Безопасный запуск упрощает управление измерениями SRTM, так как код запуска теперь не связан с определенной конфигурацией оборудования. Это означает, что количество допустимых измерений кода невелико, и будущие обновления могут развертываться более широко и быстро.

Защита в режиме управления системой (СММ)

Режим управления системой (СММ) — это специальный режим ЦП в микроконтроллерах x86, который обрабатывает управление питанием, конфигурацию оборудования, тепловой мониторинг и все остальное, что производитель считает полезным. При запросе одной из этих системных операций во время выполнения вызывается немаскируемое прерывание (SMI), которое выполняет код SMM, установленный BIOS. Код СММ выполняется на самом высоком уровне привилегий и невидим для ОС, что делает его привлекательным объектом для вредоносных действий. Даже если System Guard Secure Launch используется для позднего запуска, код СММ может потенциально получить доступ к памяти гипервизора и изменить гипервизор.

Для защиты от этого используются два метода:

  • Защита от разбиения на разбиение для предотвращения неуместного доступа к коду и данным
  • Контроль и аттестация оборудования СММ

Защита от разбиения по страницам может быть реализована для блокировки определенных таблиц кода, которые должны быть доступны только для чтения, чтобы предотвратить незаконное изменение. Это предотвращает доступ к памяти, которая не была назначена.

Функция аппаратного процессора, известная как обработчик SMI руководителя, может отслеживать СММ и убедиться, что она не обращается к какой-либо части адресного пространства, в которую он не должен.

Защита СММ основана на технологии Secure Launch и требует, чтобы она функционировала. В будущем Windows 10 также будет измерять поведение обработчика SMI и удостоверять, что память, принадлежащей ОС, не была изменена.

Проверка целостности платформы после запуска Windows (время выполнения)

Хотя System Guard обеспечивает расширенную защиту, которая поможет защитить и сохранить целостность платформы во время загрузки и во время выполнения, реальность такова, что мы должны применить менталитет "предполагать нарушение" даже к нашим самым сложным технологиям безопасности. Мы можем верить, что технологии успешно выполняют свою работу, но нам также нужна способность убедиться, что они были успешными в достижении своих целей. Для обеспечения целостности платформы мы не можем просто доверять платформе, которая потенциально может быть скомпрометирована, чтобы подтвердить состояние ее безопасности. Таким образом, System Guard включает ряд технологий, позволяющих удаленно анализировать целостность устройства.

При загрузке Windows System Guard с помощью доверенного платформенного модуля 2.0 устройства (TPM 2.0) выполняется ряд измерений целостности. System Guard Secure Launch не поддерживает более ранние версии доверенного платформенного модуля, например TPM 1.2. Этот процесс и данные изолированы аппаратно от Windows, чтобы гарантировать, что данные измерений не подвержены типу незаконного изменения, которое может произойти в случае компрометации платформы. Здесь измерения можно использовать для определения целостности встроенного ПО устройства, состояния конфигурации оборудования и компонентов, связанных с загрузкой Windows.

Целостность времени загрузки.

После загрузки системы System Guard подписывает и запечатывает эти измерения с помощью доверенного платформенного модуля. По запросу система управления, например Intune или Microsoft Configuration Manager, может получить их для удаленного анализа. Если System Guard указывает на отсутствие целостности устройства, система управления может выполнить ряд действий, например запретить устройству доступ к ресурсам.

Требования к выпуску и лицензированию Windows

В следующей таблице перечислены выпуски Windows, поддерживающие System Guard:

Windows Pro Windows Корпоративная Windows Pro для образовательных учреждений/SE Windows для образовательных учреждений
Да Да Да Да

System Guard лицензии предоставляются следующими лицензиями:

Windows Pro/Pro для образовательных учреждений/SE Windows Корпоративная E3 Windows Корпоративная E5 Windows для образовательных учреждений A3 Windows для образовательных учреждений A5
Да Да Да Да Да

Дополнительные сведения о лицензировании Windows см. в статье Обзор лицензирования Windows.

Требования к системе для System Guard

Эта функция доступна для следующих процессоров:

  • Процессоры Intel® vPro™, начиная с Intel® Coffeelake, Whiskeylake или более поздней версии
  • Процессоры AMD®, начиная с кремния Zen2 или более поздней версии
  • Процессоры Qualcomm с набором® микросхем SD850 или более поздней версии

Требования к процессорам Intel® vPro™, начиная с Intel® Coffeelake, Whiskeylake или более поздней версии

Имя Описание
64-разрядный ЦП 64-разрядный компьютер с не менее чем четырьмя ядрами (логическими процессорами) требуется для гипервизора и безопасности на основе виртуализации (VBS). Дополнительные сведения о Hyper-V см. в статьях Hyper-V на Windows Server 2016 или Общие сведения о Hyper-V на Windows 10. Дополнительные сведения о низкоуровневой оболочке см. в разделе Спецификации гипервизора.
Доверенный платформенный модуль (TPM) 2.0 Платформы должны поддерживать дискретный TPM 2.0. Интегрированные и встроенные TPM не поддерживаются, за исключением микросхем Intel, поддерживающих технологию Platform Trust Technology (PTT), которая является типом интегрированного аппаратного доверенного платформенного модуля, соответствующего спецификации TPM 2.0.
Защита Windows DMA Платформы должны соответствовать спецификации защиты DMA Windows (все внешние порты DMA должны быть отключены по умолчанию до тех пор, пока ОС явно не заключит их).
Буферы связи СММ Все буферы связи SMM должны быть реализованы в типах памяти EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS или EfiReservedMemoryType.
Таблицы страниц СММ Не должен содержать никаких сопоставлений с EfiConventionalMemory (например, отсутствие памяти, принадлежащей ОС или VMM).
Не должен содержать сопоставлений с разделами кода в EfiRuntimeServicesCode.
НЕ должны иметь разрешения на выполнение и запись для одной и той же страницы
Должен разрешать только то, что страницы TSEG могут быть помечены исполняемыми, а карта памяти должна сообщать О TSEG EfiReservedMemoryType.
Обработчик SMI BIOS должен быть реализован таким образом, чтобы таблицы страниц SMM блокировались в каждой записи SMM.
Современный и подключенный резервный режим Платформы должны поддерживать современный и подключенный резервный режим.
Индекс AUX доверенного платформенного модуля Платформа должна настроить индекс AUX с индексом, атрибутами и политикой, которые точно соответствуют индексу AUX, указанному в группе DG TXT с размером данных, равным ровно 104 байтам (для данных AUX SHA256). (NameAlg = SHA256)
Платформы должны настроить индекс PS (поставщик платформы) с помощью:
  • Именно стиль "TXT PS2" Атрибуты при создании следующим образом:
    • AuthWrite
    • PolicyDelete
    • Запись заблокирована
    • WriteDefine
    • AuthRead
    • WriteDefine
    • Нода
    • Написано
    • ПлатформаСоздать
  • Политика exactly PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg and Policy)
  • Размер ровно 70 байт
  • NameAlg = SHA256
  • Кроме того, она должна быть инициализирована и заблокирована (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1) во время запуска ОС.
Данные индекса PS DataRevocationCounters, SINITMinVersion и PolicyControl должны быть 0x00
Политика AUX Требуемая политика AUX должна быть следующей:
  • A = TPM2_PolicyLocality (Locality 3 & Locality 4)
  • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
  • authPolicy = {A} OR {{A} AND {B}}
  • дайджест authPolicy = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24
Индекс NV доверенного платформенного модуля Встроенное ПО платформы должно настроить индекс NV доверенного платформенного модуля для использования операционной системой с:
  • Дескриптор: 0x01C101C0
  • Атрибуты:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Политика:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Дайджест-значение 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Встроенное ПО платформы Встроенное ПО платформы должно содержать весь код, необходимый для безопасного запуска технологии intel® Trusted Execution Technology:
  • Intel® SINIT ACM должна быть перенесена в BIOS OEM
  • Платформы должны поставляться с рабочим ACM, подписанным правильным рабочим подписывателем Intel® ACM для платформы.
Обновление встроенного ПО платформы Встроенное ПО системы рекомендуется обновлять через UpdateCapsule в клиентский компонент Центра обновления Windows.

Требования к процессорам AMD®, начиная с Zen2 или более поздней версии

Имя Описание
64-разрядный ЦП 64-разрядный компьютер с не менее чем четырьмя ядрами (логическими процессорами) требуется для гипервизора и безопасности на основе виртуализации (VBS). Дополнительные сведения о Hyper-V см. в статьях Hyper-V на Windows Server 2016 или Общие сведения о Hyper-V на Windows 10. Дополнительные сведения о низкоуровневой оболочке см. в разделе Спецификации гипервизора.
Доверенный платформенный модуль (TPM) 2.0 Платформы должны поддерживать дискретный TPM 2.0 или TPM Microsoft Pluton.
Защита Windows DMA Платформы должны соответствовать спецификации защиты DMA Windows (все внешние порты DMA должны быть отключены по умолчанию до тех пор, пока ОС явно не заключит их).
Буферы связи СММ Все буферы связи SMM должны быть реализованы в типах памяти EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS или EfiReservedMemoryType.
Таблицы страниц СММ Не должен содержать никаких сопоставлений с EfiConventionalMemory (например, отсутствие памяти, принадлежащей ОС или VMM).
Не должен содержать сопоставлений с разделами кода в EfiRuntimeServicesCode.
НЕ должны иметь разрешения на выполнение и запись для одной и той же страницы
Обработчик SMI BIOS должен быть реализован таким образом, чтобы таблицы страниц SMM блокировались в каждой записи SMM.
Современный и подключенный резервный режим Платформы должны поддерживать современный и подключенный резервный режим.
Индекс NV доверенного платформенного модуля Встроенное ПО платформы должно настроить индекс NV доверенного платформенного модуля для использования операционной системой с:
  • Дескриптор: 0x01C101C0
  • Атрибуты:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Политика:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Дайджест-значение 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Встроенное ПО платформы Встроенное ПО платформы должно содержать весь код, необходимый для выполнения безопасного запуска:
  • Платформы AMD® Secure Launch должны поставляться с предоставленным devnode драйвера AMD® DRTM и установленным драйвером AMD® DRTM.

На платформе должна быть включена защита от отката встроенного ПО безопасного процессора AMD®
На платформе должна быть включена функция AMD® Memory Guard.
Обновление встроенного ПО платформы Встроенное ПО системы рекомендуется обновлять через UpdateCapsule в клиентский компонент Центра обновления Windows.

Требования к процессорам Qualcomm с наборами® микросхем SD850 или более поздней версии

Имя Описание
Мониторинг обмена данными в режиме Все буферы связи в режиме монитора должны быть реализованы в EfiRuntimeServicesData (рекомендуется), разделах данных EfiRuntimeServicesCode, как описано в таблице атрибутов памяти, EfiACPIMemoryNVS или EfiReservedMemoryType.
Таблицы страниц режима мониторинга Все таблицы страниц в режиме монитора должны:
  • НЕ содержат никаких сопоставлений с EfiConventionalMemory (например, нет памяти, принадлежащей ОС или VMM).
  • Они не должны иметь разрешения на выполнение и запись для одной и той же страницы.
  • Платформы должны разрешать только страницы в режиме мониторинга, помеченные как исполняемые файлы
  • Карта памяти должна сообщать о режиме монитора как EfiReservedMemoryType.
  • Платформы должны обеспечить механизм защиты таблиц страниц режима монитора от изменения
Современный и подключенный резервный режим Платформы должны поддерживать современный и подключенный резервный режим.
Встроенное ПО платформы Встроенное ПО платформы должно содержать весь код, необходимый для запуска.
Обновление встроенного ПО платформы Встроенное ПО системы рекомендуется обновлять через UpdateCapsule в клиентский компонент Центра обновления Windows.