Предлагаем заглянуть под капот программного модуля доверенной загрузки ViPNet SafeBoot. Сегодня мы расскажем о его архитектуре, технических возможностях, процессе установки.
Общая информация
Важной задачей при построении любой доверенной системы является необходимость передать управление на доверенную ОС, являющуюся ядром данной системы, убедившись в ее целостности — т.е. только на то верифицированное исполняемое окружение, в рамках которого будет выполняться целевое ПО доверенной системы. Не выполнив данной задачи нельзя с полной ответственностью говорить о том, что в процессе загрузки ОС не могут быть подменены компоненты ОС, а исполняемое окружение останется доверенным.
ViPNet SafeBoot предназначен для решения следующих основных задач:
доверенная загрузка ОС с контролем целостности программной и аппаратной исполняемой среды;
ранняя аутентификация пользователей (для ограничения доступа к конфигурации доверенной загрузки, в частности).
ViPNet SafeBoot — исключительно программное средство, которое функционирует в окружении UEFI, имеет модульную структуру и встраивается в UEFI BIOS платформ, закрепляясь для старта на достаточно ранней стадии загрузки системного кода платформы.
ViPNet SafeBoot — наложенное средство защиты, это означает, что для его работы не нужно иметь специализированное исполняемое окружение (свой UEFI BIOS), а достаточно оригинального UEFI BIOS платформы (в специализированных исполнениях может требоваться доверенный UEFI BIOS платформы, но это не касается напрямую самого ViPNet SafeBoot). Отметим, что установка ViPNet SafeBoot возможна не только на этапе производства платформы, но и на различных фазах работы с целевой платформой (например, администратором в удобном для него окружении) — это интересное и важное преимущество программного МДЗ опишем подробнее ниже.
Исполняемое окружение
Изначально ViPNet SafeBoot разрабатывался для архитектуры процессоров x64 (Intel, AMD), в дальнейшем мы поддержали архитектуру процессоров aarch64/arm64 (например, Байкал-М, которые мы поддержали на нескольких типах материнских плат). Отметим, что по нашему опыту, для платформ с firmware на базе UEFI, поддержка новых процессорных архитектур в ViPNet SafeBoot (сборка, подготовка инсталлятора и прочее) не является такой уж серьезной проблемой и занимает обозримое время.
ViPNet SafeBoot может функционировать в различных средах — на реальном оборудовании, в виртуальных средах (VMware, VirtualBox, QEMU), в эмуляторах (Nt32 из состава edk2).
В качестве реального оборудования могут выступать рабочие станции, сервера, тонкие клиенты, ноутбуки, планшеты, встраиваемое оборудование. Со списком официально поддерживаемых (и неподдерживаемых тоже) платформ можно ознакомиться по ссылке. На самом деле, в реальности, список поддерживаемых платформ с firmware на базе UEFI существенно шире, так как мы добавляем в список поддерживаемых платформ только то, что проверено нами.
Кроме систем на базе нативного UEFI-окружения нами исследуется возможность работы в системах на базе coreboot (в рамках UEFI payload) и U-Boot (в рамках его UEFI-окружения).
Механизм действия
Модули ViPNet SafeBoot встраиваются в UEFI BIOS, а именно в один из исполняемых Firmware Volume (BIOS region), что обеспечивает достаточно ранний старт первой фазы исполнения на стадии DXE dispatch (вызываемой средствами системного DXE-диспетчера). Часть модулей может располагаться на диске в рабочей директории ViPNet SafeBoot на системном разделе ESP в директории EFI\Infotecs — таким образом поддерживается сценарий установки в условиях недостаточного свободного места в UEFI BIOS, когда в UEFI BIOS встраивается только базовый набор модулей, загружающий в доверенном режиме основной набор модулей с диска. Доверенная загрузка модулей с диска происходит с верификацией подписи каждого модуля и проверкой на вхождение модуля в замкнутое исполняемое окружение.
ViPNet SafeBoot функционирует на следующих фазах работы системы:
DXE dispatch — точка старта базового набора модулей, регистрация обработчиков основных фаз исполнения;
EndOfDxe — выполнение раннего функционала защиты (выставление защиты UEFI BIOS после S3, блокировка PCI Option ROM и т.д.);
ReadyToBoot — основная фаза исполнения;
ExitBootServices — завершающая фаза исполнения: включение защиты UEFI BIOS, включение эмуляции NVRAM, очистка памяти (модулей и динамической) и т.д.;
Runtime — эмуляция NVRAM;
SMM — функции самозащиты: фильтрация Software SMI, контроль целостности runtime-модулей.
ViPNet SafeBoot использует в своей основной работе стандартные программные интерфейсы, предоставляемые окружением UEFI: сервисы системных таблиц (EFI_BOOT_SERVICES, EFI_RUNTIME_SERVICES и EFI_MM_SYSTEM_TABLE) и стандартные UEFI/SMM-протоколы. Для выполнения специальных задач, например, по блокировке функционала встроенных средств обновления BIOS, используются вендор-специфичные UEFI-протоколы (в данном случае — их перехват/блокировка).
Установка ViPNet SafeBoot
Основными задачами при установке ViPNet SafeBoot на целевую платформу являются:
встраивание модулей в UEFI BIOS;
разворачивание рабочей директории на диске;
задание стартовой конфигурации.
Предполагаются следующие сценарии установки ViPNet SafeBoot (встраивания модулей в UEFI BIOS) на целевые платформы:
программная установка (инсталлятором) — своими средствами или при взаимодействии с производителем платформы;
установка на производстве (программатором) — своими средствами или при взаимодействии с производителем платформы.
Программная установка
Как основной сценарий, мы рассматриваем именно программную установку своими средствами: таким образом обеспечивается автономность от производителя платформы (часто данный процесс имеет свойство затягиваться по времени), упрощается инструментарий установки, повышается гибкость в выборе времени установки (при отсутствии специального инструментария установки на нужной фазе установки).
На данный момент программная установка производится из окружения EFI Shell — это не только объединяет сценарии по установке и обновлению, но и исключает влияние ПО уровня ОС на протяжении данного процесса.
Сценарий программной установки довольно прост и удобен:
подключение USB-диска с инсталлятором;
запуск EFI Shell с USB-диска из BIOS Setup;
автоматический запуск инсталлятора;
выполнение инсталлятором всех операций по установке.
Вместе с тем, при программной установке своими средствами могут возникать следующие типовые проблемы:
Включенная защита UEFI BIOS на уровне аппаратных средств типа регистров чипсета BIOS_CNTL и PRx — препятствие в виде блокировки записи UEFI BIOS программными средствами.
Варианты решения:
o Отключение защиты через изменение системных NVRAM-переменных или некоторыми другими способами.
o Использование альтернативных программных средств установки.
o Взаимодействие с производителем платформы (разработчиком UEFI BIOS).
Включенная защита UEFI BIOS на уровне аппаратных средств типа Intel BootGuard (или как вариант — программного средства подобного направления) — препятствие в виде верификации UEFI BIOS при каждом старте системы.
Варианты решения:
o Поиск и встраивание модулей ViPNet SafeBoot в другой исполняемый Firmware Volume, не покрытый контролем Intel BootGuard (и аналогов).
o Взаимодействие с производителем платформы (разработчиком UEFI BIOS).
Безусловно сложнейшей задачей при установке ViPNet SafeBoot является встраивание модулей в UEFI BIOS — она включает в себя (в стандартном сценарии):
считывание образа UEFI BIOS из микросхемы SPI Flash платформы;
встраивание одного из набора модулей (в зависимости от настроек) в считанный образ UEFI BIOS;
запись модифицированного образа UEFI BIOS в микросхему SPI Flash платформы.
Для работы с микросхемами SPI Flash для платформ Intel мы используем стандартные средства, находящиеся в открытом доступе, а для платформ AMD предлагаем средства собственной разработки. Кроме того, доступна возможность использования специальных средств, специфичных для конкретных платформ (AMI AFU, flashrom и т.д.).
Для работы с образами UEFI BIOS мы используем средства собственной разработки — данные инструменты позволяют выполнять множество операций по модификации образов UEFI BIOS: добавление/удаление модулей в определенный Firmware Volume, замена секций существующих модулей, управление NVRAM-переменными и многое другое.
Для снятия риска возникновения необратимых (или трудозатратных) последствий, например, при записи поврежденного образа UEFI BIOS в микросхему SPI Flash, в инсталляторе ViPNet SafeBoot реализован специальный режим съема диагностической информации, анализ результатов которой мы готовы проводить по запросу, подтверждая возможность установки на данной платформе.
Диагностику необходимо запускать перед установкой, затем отправлять диагностическую информацию нам для анализа и ждать подтверждения возможности установки.
В инсталляторе ViPNet SafeBoot реализован механизм расширений (аналог плагинов), которые предполагается использовать при наличии каких-то специфических особенностей платформы — таким образом обеспечивается неизменность основной части инсталлятора, находящейся под контролем целостности, и упрощается (формализуется) процесс настройки инсталлятора под конкретную платформу.
Расширения инсталлятора позволяют выполнять специфические для данной платформы действия на разных фазах установки и решать следующие задачи:
управление средствами защиты UEFI BIOS перед установкой (сценарий снятия защиты UEFI BIOS);
задание образа UEFI BIOS, отличного от текущего (сценарий обновления версии UEFI BIOS);
управление встраиванием модулей в UEFI BIOS (сценарий недостаточного свободного места в UEFI BIOS);
задание сторонних средств работы с микросхемами SPI Flash (сценарий отсутствия поддержки работы с микросхемой SPI Flash стандартными средствами инсталлятора);
многое другое.
Например, при определенной комбинации стандартных расширений инсталлятора можно собрать расширение, которое позволит в автоматическом режиме (запускаемом из настроек ViPNet SafeBoot) обновить версию UEFI BIOS с сохранением установленного ViPNet SafeBoot и его данных.
Установка на производстве
При установке на производстве, конечно, не исключается и программный сценарий установки (описанный выше), но все же основным сценарием является установка либо с помощью аппаратного программатора, либо с помощью специальных программных средств — для обеспечения массового производства платформ со встроенным ViPNet SafeBoot в UEFI BIOS.
Взаимодействие с производителями платформ (разработчиком UEFI BIOS)
На данный момент налажено взаимодействие (включающее в себя встраивание модулей ViPNet SafeBoot и подпись полученного образа UEFI BIOS или установку ViPNet SafeBoot на этапе производства платформ) со следующими производителями платформ:
отечественные производители: Аквариус, Depo, iRU, ICL, РАМЕК-ВС;
зарубежные производители: Lenovo, ASUS
Режим неактивности
В ViPNet SafeBoot поддерживается сценарий установки в неактивном режиме. Это серьезное преимущество, и оно может быть интересно в случае, когда производитель платформ захочет выпускать или устанавливать единый образ UEFI BIOS на большую партию платформ, а включать ViPNet SafeBoot будет администратор на необходимом ему подмножестве платформ этой партии. Таким образом, процесс взаимодействия с производителями платформ может сильно упроститься, а объем их работ и издержки значительно уменьшатся.
Функции ViPNet SafeBoot
Проведем обзор с точечным, более детальным описанием основных функций и возможностей ViPNet SafeBoot.
Хранение журнала и БД
Важнейшей задачей при разработке ViPNet SafeBoot является обеспечение доверенного хранения его данных — в первую очередь, журнала событий и БД (настроек). По историческим причинам они хранятся в независимых и отдельных структурных единицах.
Поддерживаются 2 основных режима хранения:
внутренний – в NVRAM (в UEFI BIOS);
внешний – в файлах (в рабочей директории на диске).
Внутренний режим хранения
Внутреннее хранение данных позволяет уйти от зависимости от внешних хранилищ (дисков) — что обеспечивает, в частности, возможность поддерживать сценарий работы на бездисковых рабочих станциях, и в перспективе реализовать полноценный Zero Client на произвольном оборудовании.
При использовании внутреннего режима хранения данные сохраняются в индексированном списке NVRAM-переменных, оформленном в специальном формате для предотвращения проблем при разрыве списка в случае прерывания по сбросу питания и т.д.
Для предотвращения стороннего доступа к внутренним хранилищам данных используется целый ряд мер, подробнее описанных ниже — от эмуляции NVRAM, до защиты UEFI BIOS (на чтение и запись).
Основным минусом и ограничением внутреннего режима хранения данных является относительно небольшой объем свободного пространства в NVRAM — на современных системах это около 100 Кб, чего, например, явно недостаточно для хранения полных списков контроля целостности компонентов системы. Для закрытия этого ограничения мы ведем исследование по возможности организации автономного от NVRAM внутреннего хранилища и уже есть определенные практические результаты в этом направлении.
Внешний режим хранения
При использовании внешнего режима хранения все данные хранятся в виде файлов в рабочей директории, в формате, предотвращающем сторонний доступ к ним:
в зашифрованном виде (журнал, БД) — для предотвращения чтения данных;
в подписанном виде (журнал, БД, списки эталонов КЦ) — для предотвращения модификации данных (преднамеренной и непреднамеренной);
в привязанном к внутренней БД виде (журнал, БД, списки эталонов КЦ) — для предотвращения атак отката.
Во внутреннем хранилище в данном режиме хранится лишь базовая конфигурация — например, ключи контроля целостности внешних данных.
Доверенная загрузка ОС
Ключевой задачей ViPNet SafeBoot является организация доверенной загрузки ОС.
Поддерживаются следующие типы доверенной загрузки ОС:
legacy ОС;
UEFI ОС;
по сети (UEFI).
Для ViPNet SafeBoot нет явных ограничений по поддержке локально загружаемых ОС — единственным препятствием может служить только использование в ОС разделов с неподдерживаемыми типами ФС (для контроля целостности их содержимого).
Организация доверенной загрузки ОС в ViPNet SafeBoot серьезно отличается от стандарта де-факто Secure Boot и основывается на следующих принципах:
контроль целостности заданных файлов ОС (цепочки загрузки ОС);
явная передача управления на заданный загрузчик ОС (или загрузочное устройство в случае legacy ОС).
Контроль целостности заданных файлов ОС
Перед передачей управления на загрузчик ОС необходимо верифицировать его целостность и целостность цепочки загрузки ОС (т.е. других исполняемых и конфигурационных файлов ОС, следуемых и используемых в процессе загрузки за загрузчиком ОС).
Для этого необходимо поставить на контроль целостности всю цепочку загрузки ОС. Для распространенных дистрибутивов версий ОС Windows и Linux реализован автоматический режим, но есть и возможность ручной конфигурации в настройках контроля целостности ViPNet SafeBoot.
Передача управления на заданный загрузчик ОС
Для передачи управления на заданный загрузчик ОС (или загрузочное устройство в случае legacy ОС) необходимо указать его в настройках загрузки ViPNet SafeBoot, предварительно выбрав тип загрузки.
Передача управления на заданный загрузчик ОС происходит средствами самого ViPNet SafeBoot — с использованием сервисов LoadImage/StartImage системной таблицы EFI_BOOT_SERVICES, т.е. без передачи управления UEFI Boot Manager и манипуляции его параметрами (BootOrder и т.д.). Таким образом упрощается контроль за управлением загрузкой ОС.
Загрузка ОС по сети
Поддерживаются сценарии загрузки UEFI ОС по сети по протоколам PXE и HttpBoot.
При этом на данный момент есть возможность контроля адреса сервера PXE/HttpBoot и контроля целостности загрузчика ОС.
Контроль целостности
Контролируемые компоненты
Для обеспечения контроля исполняемой среды поддерживается контроль целостности следующих программных и аппаратных компонентов системы:
файлов на диске (на разделах с ФС FAT*, NTFS, ext2/3/4);
реестра Windows (на уровне ключей/значений);
CMOS (на уровне регистров);
конфигурационных пространств PCI;
таблиц ACPI;
структур SMBIOS (DMI);
карты распределения памяти;
модулей UEFI BIOS;
загрузочных секторов диска (загрузочного);
переменных NVRAM (с релиза 3.1);
системных таблиц UEFI (с релиза 3.1).
Для каждого компонента ведется свой список элементов (хранимый либо в файле на диске, либо во внутреннем хранилище NVRAM), контролируемых отдельно. Например, элементами компонента «Файлы» будут конкретные файлы (с указанием их путей), а элементами компонента «Модули UEFI BIOS» — как это ни странно :) , модули UEFI BIOS (с указанием их в формате <fv_id>:<guid>).
Схема контроля целостности
Для каждого компонента применяется следующая схема контроля целостности («схема каталогов»):
по каждому контролируемому элементу компонента рассчитывается хэш — так называемый эталонный хэш;
формируется список в текстовом виде, каждая строка которого идентифицирует контролируемый элемент с его эталонными хэшем в виде: <hash> <element_id>;
список сохраняется в файле в рабочей директории или в БД;
при сохранении в файле — список подписывается на ключе защиты данных, подпись сохраняется в открепленном виде рядом с файлом списка;
o ключ защиты данных хранится в БД в защищенном виде и его можно изменить из настроек ViPNet SafeBoot;
при сохранении в файле — в БД фиксируется привязка к сохраняемому на диске файлу (на основе хэша) для предотвращения атак отката.
Данная схема обеспечивает целостность и аутентичность (т.е. невозможность модификации злоумышленником без знания закрытого ключа подписи) контролируемых данных, исключает необходимость в подписи каждого элемента отдельно (т.е. ускоряет процесс контроля целостности) и применяется при контроле целостности программных и аппаратных компонентов системы, запросов удаленного управления, а также пакетов обновлений.
Криптографический базис
В качестве криптографических алгоритмов используются алгоритмы семейства ГОСТ:
ГОСТ 34.10-2018 — для подписи и верификации подписи;
ГОСТ 34.11-2018 — для расчета хэша и HMAC;
ГОСТ 34.12-2018/ГОСТ 34.13-2018 — для шифрования и расчета имитовставки.
В качестве криптографической библиотеки в ViPNet SafeBoot используется криптографическое ядро, разрабатываемое в ИнфоТеКС, и являющееся криптографическим базисом многих других продуктов ИнфоТеКС. Кроме того, для поддержки работы с сертификатами и других подсистем применяется OpenSSL с нашим engine, использующим данное криптографическое ядро.
Аутентификация
Другой важной задачей ViPNet SafeBoot является аутентификация пользователей (разграничение доступа). Аутентификация позволяет заблокировать доступ сторонних пользователей к системе (в частности, к загрузке ОС), а также ограничить возможности по управлению настройками ViPNet SafeBoot со стороны низкопривилегированных пользователей.
В ViPNet SafeBoot используется следующая ролевая модель:
администратор — имеет все права на изменение настроек;
аудитор — имеет права на чтение и экспорт журнала и на изменение своего пароля (пролонгации его срока действия);
пользователь — имеет права только на изменение своего пароля (пролонгации его срока действия).
Одновременно может быть заведено до 32 пользователей всех типов (всего).
Кроме того, может быть задано расписание доступа (графика работы) пользователей — для более гибкого управления аутентификацией пользователей.
Поддерживаются следующие типы аутентификации:
по паролю — с верификацией введенного пароля по хэшу от пароля с солью, сохраненным в БД;
по сертификату на смарт-карте/токене — на основе протокола аутентификации, описанного ниже;
по паролю и по сертификату на смарт-карте/токене — комбинированный режим с последовательным запуском процедуры аутентификации по паролю, а затем по сертификату на смарт-карте/токене;
по паролю на смарт-карте/токене — с верификацией пароля, сохраненного в специальном закрытом файле смарт-карты/токена, по хэшу от пароля с солью, сохраненным в БД;
по LDAP — на основе bind на удаленный LDAP-сервер (Microsoft AD, Astra ALD Pro), с поддержкой ограничения списка разрешенных к аутентификации пользователей через задание белого списка пользователей.
Поддерживаются следующие смарт-карты/токены: Рутокен ЭЦП 2, Рутокен Lite, Рутокен S, JaCarta-2 ГОСТ, JaCarta PKI, JaCarta LT, Guardant ID (и некоторые другие). Драйвера смарт-карт/токенов разрабатываются самостоятельно.
Аутентификация по сертификату на смарт-карте/токене
Аутентификация по сертификату на смарт-карте/токене требует предварительной подготовки смарт-карты/токена со стороны администратора средствами либо ViPNet CSP, либо вендор-специфичного ПО, а именно:
генерации закрытого ключа (неизвлекаемого или в формате программного контейнера закрытого ключа ViPNet CSP) на смарт-карте/токене;
выпуска и сохранения на смарт-карте/токене сертификата пользователя.
Важным требованием при аутентификации по сертификату на смарт-карте/токене является обеспечение невозможности дупликации смарт-карты/токена — полноценно это доступно на смарт-картах/токенах с неизвлекаемыми ключами, на других смарт-картах/токенах это доступно частично (с ограничением знания PIN злоумышленником).
Протокол аутентификации на смарт-карте/токене с неизвлекаемым ключом выглядит следующим образом (см. рис.2):
запрашивается ввод PIN смарт-карты/токена (для доступа к ключу);
производится аутентификация на смарт-карте/токене по введенному PIN;
на ПДСЧ (программном датчике случайных чисел) генерируется вектор определенной длины;
вектор аппаратно подписывается на неизвлекаемом ключе смарт-карты/токена;
подпись вектора программно верифицируется на сертификате пользователя (сохраненном как на смарт-карте/токене, так и в БД);
при успешном результате верификации можно говорить о том, что смарт-карта/токен соответствует сертификату пользователя и является аутентичной/аутентичным;
o при этом за счет программной верификации подписи исключается возможность подмены/эмуляции аппаратной составляющей (смарт-карты/токена), которая могла бы фиктивно верифицировать подпись аппаратным способом;
происходит верификация цепочки сертификатов (от сертификата пользователя до корневого сертификата) — этим самым проверяется существование всей цепочки сертификатов, сроков действия всех сертификатов в цепочке, а также отсутствие сертификата пользователя в списке отзыва (CRL).
Аутентификация в режиме Single Sign-On
Для удобства прохождения множественной аутентификации (в ViPNet SafeBoot, в ОС/СЗИ) реализована поддержка механизма Single Sign-On со сквозной аутентификацией пользователя в ОС/СЗИ. Для аутентификации в режиме Single Sign-On на стороне ОС требуется установка провайдера аутентификации, реализованного на данный момент для ОС Windows и Linux. Кроме того, поддержка аутентификации в режиме Single Sign-On реализована в СЗИ ViPNet SafePoint.
Аутентификационная информация пользователя передается в защищенном виде через эмулятор NVRAM (через память) и имеет минимальное время жизни.
Средства защиты и самозащиты
Средства защиты и самозащиты являются с некоторой точки зрения вспомогательными компонентами, но в то же время без которых о безопасности ViPNet SafeBoot говорить можно было бы лишь условно. Они позволяют противостоять атакам по подмене настроек (конфигурации доверенной загрузки ОС, в частности) и по удалению/отключению ViPNet SafeBoot — в первую очередь с уровня ОС, т.е. со стороны произвольного, даже высокоприоритетного, пользователя ОС.
Далее будут рассмотрены конкретные средства защиты и самозащиты, реализованные в ViPNet SafeBoot.
Защита UEFI BIOS
Для предотвращения возможности перезаписи UEFI BIOS (как в сценарии целенаправленной атаки, так и в сценарии легального обновления UEFI BIOS со стороны ОС, которое просто «удалит» установленный ViPNet SafeBoot) применяется следующий подход:
Intel: на весь BIOS region микросхемы SPI Flash устанавливается защита регионов SPI Flash на уровне регистров чипсета PRx (защита уровня PRx является предпочтительнее защиты уровня BIOS_CNTL, т.к. опирается только на аппаратную составляющую, т.е. имеет большую защищенность — например, в случае совершения атак на SMM);
AMD: блокируются SPI-команды записи и стирания микросхемы SPI Flash (с реализацией части кода на уровне SMM, ввиду специфики AMD);
Байкал-М: на уровне ARM TF (части firmware вне UEFI) реализуется перехват сервисов SMC записи в микросхему SPI Flash.
После включения данная защита обеспечивает невозможность ее отключения до последующей перезагрузки системы (аппаратными средствами для Intel и AMD), которая в свою очередь находится под контролем ViPNet SafeBoot — при последующей загрузке системы защита будет вновь активирована.
Нельзя не обратить внимание на восстановление параметров защиты после выхода из режима сна (S3) — ввиду специфики современных платформ Intel/AMD, на которых после S3 происходит «укороченная» переинициализация конфигурации системы (и регистров чипсета, в частности), ViPNet SafeBoot поддерживает задание параметров защиты в сценариях выхода из S3.
Поскольку со стороны ОС могут быть легальные запросы на чтение-запись NVRAM-переменных, а NVRAM находится в защищаемом регионе UEFI BIOS, при включенной защите UEFI BIOS предполагается дополнительно включать эмуляцию NVRAM (описана ниже).
Эмуляция NVRAM
Эмуляция NVRAM решает сразу несколько задач:
предотвращение доступа к NVRAM-переменным ViPNet SafeBoot;
поддержка легальных запросов на чтение-запись NVRAM-переменных со стороны ОС в случае включенной защиты UEFI BIOS на чтение-запись;
предотвращение атак на реализацию NVRAM со стороны ОС.
При включенной эмуляций NVRAM происходит дупликация содержимого NVRAM в эмулируемый пул памяти и перехватываются сервисы системной таблицы EFI_RUNTIME_SERVICES, отвечающие за работу с NVRAM-переменными, с перенаправлением на эмулятор NVRAM.
Следует отметить, что даже при отключенном режиме эмуляции NVRAM происходит блокировка (фильтрация) доступа к NVRAM-переменным ViPNet SafeBoot для стороннего кода (с уровня ОС).
Контроль (фильтрация) Software SMI
Для предотвращения обновления UEFI BIOS с помощью вендор-специфичных средств (например, AMI AFU), функционирующих по протоколу на уровне SMI (с взаимодействием с SMM-кодом) в отличие от прямой работы с SPI-контроллером, реализован контроль (фильтрация) Software SMI с реализацией своего фильтра на уровне SMM с блокировкой явно опасных SMI, используемых в протоколе взаимодействия. База правил, блокируемых SMI, может дополнительно расширяться/уточняться при установке/обновлении ViPNet SafeBoot.
Блокировка встроенных средств обновления UEFI BIOS
Для предотвращения обновления UEFI BIOS со стороны специальных вендор-специфичных режимов уровня UEFI реализована защита, основанная на перехвате сервисов UEFI-протоколов обновления с последующей блокировкой их выполнения.
Поддерживается блокировка UEFI-протоколов обновления UEFI BIOS от основных производителей платформ (OEM). Реализована формализованная система правил описания перехватываемых UEFI-протоколов для расширения и сопровождения списка.
Контроль runtime-кода
Для контроля неизменности runtime-кода ViPNet SafeBoot (и SMM включительно) реализована защита, функционирующая на уровне SMM, выполняющая периодическую верификацию целостности кода на основе эталонных хэшей модулей и блокирующая доступ к системе в случае нарушения их целостности.
Блокировка входа в специальные режимы настроек
Для предотвращения доступа в специальные режимы настроек, например, в BIOS Setup, реализована блокировка (фильтрация) явно опасных комбинаций клавиш на ранней стадии загрузки системы. База блокируемых комбинаций клавиш может дополнительно расширяться/уточняться администратором (при нашей поддержке) при установке/обновлении ViPNet SafeBoot.
Средства защиты от malware
В последнее время очень активно развиваются инструменты для атаки на системы со встраиванием компонентов malware в firmware на базе UEFI. Причем встраивание malware может проходить как на достаточно длительном цикле цепочки поставок, так и в процессе эксплуатации систем.
Большинство malware уровня UEFI BIOS позволяет автоматически заражать ОС даже после ее переустановки (либо в файловом, либо в бесфайловом режимах). Собственно, для этой цели, а также для обеспечения более раннего старта, malware и встраивается в UEFI BIOS. Основные вектора атак, используемые UEFI malware, указаны на рис.3.
Средства защиты от malware в ViPNet SafeBoot отвечают в первую очередь за блокировку (полную изоляцию) основного функционала уже находящегося в UEFI BIOS вредоносного (или потенциально вредоносного) кода, например, в условиях, когда ViPNet SafeBoot устанавливается в уже зараженный (или потенциально зараженный) UEFI BIOS. В случае установленного ViPNet SafeBoot встраивание malware в UEFI BIOS будет блокироваться средствами защиты UEFI BIOS ViPNet SafeBoot.
Далее будут рассмотрены конкретные средства защиты от malware, реализованные в ViPNet SafeBoot.
Блокировка ACPI WPBT
Для предотвращения записи потенциально вредоносных исполняемых файлов в системные разделы ОС и их запуска со стороны ОС, реализована блокировка механизма специальных ACPI-таблиц WPBT.
Примеры блокируемых malware: Absolute Software Computrace/LoJack.
Защита дисков от записи
Для предотвращения записи потенциально вредоносных исполняемых и конфигурационных файлов в системные разделы ОС, реализован механизм блокировки записи на диск в файловом и блочном/секторном режимах. Механизм основан на перехвате системных UEFI-протоколов SimpleFileSystem, BlockIo, DiskIo с последующим контролем вызывающего кода.
При включении данного механизма возможность доступа к диску на запись будет только у компонентов ViPNet SafeBoot.
Примеры блокируемых malware: Hacking Team’s UEFI Rootkit, Absolute Software Computrace/LoJack, LoJax, MosaicRegressor.
Защита системных таблиц UEFI
Для предотвращения перехвата сервисов системных таблиц UEFI EFI_BOOT_SERVICES и EFI_RUNTIME_SERVICES реализован механизм виртуализации/локализации системных таблиц UEFI для каждого исполняемого модуля, что приводит при перехвате сервисов к модификации только локальной копии системной таблицы вредоносного (или потенциально вредоносного) модуля — при этом системные таблицы, используемые непосредственно в процессе загрузки ОС, остаются неизменными.
Примеры блокируемых malware: EfiGuard, CosmicStrand.
Блокировка загрузки PCI Option ROM
Для предотвращения запуска потенциально вредоносного кода с подключаемых PCI-устройств из исполняемых PCI Option ROM реализован механизм перехвата и блокировки старта исполняемого кода из PCI Option ROM посредством затирания его памяти.
Таким образом, вследствие достаточно раннего старта ViPNet SafeBoot имеется возможность блокировать даже функционал АПМДЗ (примеры приводить не станем J).
Удаленное управление
Для удобной эксплуатации ViPNet SafeBoot, реализован механизм удаленного управления.
В качестве ПО, реализующего функции удаленного управления на стороне ОС, может выступать ViPNet SafeBoot MC или ViPNet EPP. Данное ПО имеет клиент-серверную структуру с возможностью управления агентами (клиентами), функционирующими на ОС Windows и Linux основных версий и дистрибутивов.
Механизм удаленного управления позволяет считывать журналы событий, изменять настройки, а также обновлять версии ViPNet SafeBoot на всем парке управляемых машин.
Механизм удаленного управления функционирует следующим образом (см. рис. 4):
ViPNet SafeBoot передает журнал и БД в канал удаленного управления (на стороне UEFI);
после загрузки ОС ПО удаленного управления получает доступ к журналу и БД из канала удаленного управления (на стороне ОС);
при необходимости изменения настроек ViPNet SafeBoot (на стороне ОС):
o ПО удаленного управления вносит соответствующие изменения настроек в полученную БД;
o ПО удаленного управления формирует так называемый запрос удаленного управления на основе измененной БД и передает его в канал удаленного управления;
после перезагрузки ОС при наличии запроса удаленного управления в канале удаленного управления (на стороне UEFI):
o ViPNet SafeBoot верифицирует запрос удаленного управления;
o ViPNet SafeBoot вносит изменения в настройках в БД;
o при наличии в запросе удаленного управления обновления ViPNet SafeBoot — запускает процесс обновления.
Каналом удаленного управления является файловый механизм хранения данных в рабочей директории. Т.е. все исходные и измененные данные, а также служебные структуры, реализующие, в частности, их контроль целостности, представляются в виде файлов — все это вместе и называется запросом удаленного управления. Для ограничения доступа со стороны сторонних пользователей, журнал и БД в канале удаленного управления передаются в зашифрованном виде.
Для подтверждения (аутентификации) запросов удаленного управления применяется механизм подписи всех данных, входящих в запрос. Подпись производится на ключе, сертификат от которого задается в настройках ViPNet SafeBoot. Таким образом обеспечивается защита от формирования или модификации запросов удаленного управления со стороны злоумышленника. Кроме того, реализован механизм защиты от атак повтора, основанный на наличии привязки (генерируемого при каждой загрузке идентификатора сессии удаленного управления), сохраняемой в БД и в БД в канале удаленного управления, и проверяемой на этапе верификации запроса удаленного управления.
Обновление
В ViPNet SafeBoot поддерживается механизм обновления — из настроек (локально) и по запросу удаленного управления.
Обновление возможно на старшую или текущую версию (последнее бывает нужно в некоторых сценариях, например, при обновлении версии UEFI BIOS с сохранением текущей версии ViPNet SafeBoot и его данных).
Обновление представляет из себя набор файлов и директорий, включающий в себя модули новой версии ViPNet SafeBoot, а также служебные файлы и исполняемые модули, и разворачивается:
на USB-диске — при обновлении из настроек;
на разделе ESP — при обновлении по запросу удаленного управления.
Все файлы пакета обновления находятся под контролем целостности (по стандартной схеме, описанной выше), процесс верификации запускается непосредственно перед обновлением. Таким образом обеспечивается защита от преднамеренной и непреднамеренной модификации модулей обновляемой версии, а также сценариев их встраивания в UEFI BIOS.
Структурно пакет обновления совпадает с инсталлятором, единственным отличием может быть различная конфигурация пакета обновления и инсталлятора, например, при обновлении часто может требоваться сохранение БД и журнала от предыдущей версии, что в свою очередь требует задания специального параметра конфигурации инсталлятора/обновления.
Для обновления (как и для установки) позволяется задавать основную и расширенную конфигурацию:
основной конфигурацией является возможность управления сохранением БД, журнала, списков эталонов контроля целостности, модулей ViPNet SafeBoot;
расширенной конфигурацией является возможность управления более тонкими параметрами, такими как задание разрешения экрана для графического интерфейса, встраивание модулей ViPNet SafeBoot в нестандартный Firmware Volume, задание специального профиля установки и т.д.
Режимы восстановления
Для обеспечения возможности выхода из различных нештатных ситуаций, а также при неаккуратном управлении ViPNet SafeBoot со стороны администраторов, в ViPNet SafeBoot поддерживаются несколько режимов восстановления. Поскольку ViPNet SafeBoot работает на ранней стадии загрузки системы, при этом блокируя возможности по обходу своего функционала, вопрос о механизме штатного восстановления сложно недооценить.
Большая часть режимов восстановления построена на использовании диска восстановления. Диск восстановления представляет из себя USB-диск (с ФС FAT*) с наличием в корне файла со сгенерированным на ДСЧ ключом восстановления достаточно большой длины. Сгенерировать ключ восстановления возможно с помощью специального ПО уровня ОС или из настроек ViPNet SafeBoot.
Для того, чтобы обеспечить связывание конкретной платформы с ViPNet SafeBoot с конкретным диском восстановления (для целей безопасности – чтобы злоумышленник не мог воспользоваться единым диском восстановления на любой машине с ViPNet SafeBoot), проводится операция привязки диска восстановления. Привязка к диску восстановления возможна:
при установке — при этом хэш от ключа восстановления сохраняется в Firmware Volume рядом с модулями ViPNet SafeBoot (ключ восстановления располагается на диске установки);
при вызове из настройки — при этом хэш от ключа восстановления сохраняется в БД ViPNet SafeBoot (ключ восстановления располагается на произвольном USB-диске).
Привязка к диску восстановления на стадии установки является предпочтительной, так как позволяет пережить сброс настроек ViPNet SafeBoot (и NVRAM в целом).
Привязка же при вызове из настроек удобнее логистически, так как позволяет возложить ответственность по подготовке диска восстановления на администратора без необходимости хранения и передачи копий дисков восстановления с фазы производства (если применяется сценарий установки с централизованным производством).
Диск восстановления следует хранить в специальных условиях с ограничением доступа к нему посторонних лиц.
Следует отметить, что использование единого USB-диска для хранения данных установки/обновления и восстановления (диск установки и диск восстановления одновременно) возможно.
При запросе одного из режимов восстановления происходит:
поиск USB-диска с ключом восстановления;
верификация структуры и целостности ключа восстановления;
расчет хэша по ключу восстановления;
сопоставление рассчитанного хэша с привязанным хэшем (сохраненным в Firmware Volume или БД);
при совпадении — передается управление на конкретный режим восстановления.
Режим PassThrough
Режим PassThrough позволяет однократно отключить основной функционал ViPNet SafeBoot при возникновении каких-либо нештатных ситуаций. Активизируется с помощью комбинации клавиш Ctrl+x на ранней стадии загрузки ViPNet SafeBoot.
Режим PassThrough требует подключения диска восстановления.
Режим восстановления профиля администратора по умолчанию
Режим восстановления профиля администратора по умолчанию позволяет восстановить (выставить в значения по умолчанию) настройки профиля администратора по умолчанию при утере его пароля, истечении срока действия его пароля, утрате смарт-карты/токена, истечении срока действия сертификата на смарт-карте/токене и т.д. Активизируется с помощью комбинации клавиш Ctrl+r на ранней стадии загрузки ViPNet SafeBoot.
Режим восстановления профиля администратора по умолчанию требует подключения диска восстановления.
Режим восстановления рабочей директории
Режим восстановления рабочей директории может потребоваться при переустановке ОС с форматированием раздела ESP, ручном удалении содержимого на разделе ESP пользователями ОС и т.д.
Начиная с релиза 2.1.2 реализована возможность автоматического восстановления в двух сценариях:
без требования подключения USB-диска установки — в случае встраивания в UEFI BIOS полного набора модулей ViPNet SafeBoot;
с требованием подключения USB-диска установки — в случае встраивания в UEFI BIOS базового набора модулей ViPNet SafeBoot.
Режим восстановления рабочей директории не требует подключения диска восстановления (с соответствующей привязкой к текущим настройкам ViPNet SafeBoot) — достаточно подключения произвольного USB-диска установки с развернутым на нем инсталлятором текущей версии ViPNet SafeBoot. Это упрощает процесс восстановления, не прибегая к получению диска восстановления из специального хранилища.
Пользовательский интерфейс
Для эффективного и удобного управления настройками в различных сценариях в ViPNet SafeBoot реализовано два независимых типа пользовательских интерфейса — графический и псевдографический.
Графический пользовательский интерфейс
Графический интерфейс является основным и реализован на графической библиотеке собственной разработки — это позволяет более гибко подходить к требованиям окружения UEFI.
В графическом пользовательском интерфейсе кроме клавиатуры дополнительно доступно использование мыши, тачпэда и тачскрина для взаимодействия с ViPNet SafeBoot. Для поддержки сценария работы на бесклавиатурных платформах (планшетах) реализована возможность пользовательского ввода через виртуальную клавиатуру (с использованием тачскрина), являющуюся составной частью графического интерфейса ViPNet SafeBoot.
Псевдографический пользовательский интерфейс
Псевдографический интерфейс является вспомогательным режимом и может использоваться в сценарии, когда на платформе физически нет видеовыхода и предполагается взаимодействие через консоль по последовательному порту (Serial Port Console Redirection).
В псевдографическом пользовательском режиме необходимо подключение внешней клавиатуры для взаимодействия с ViPNet SafeBoot.
Выпуск релизов
Отдельно хотелось бы сказать о циклах выпуска релизов, т.к. именно с выходом очередного релиза добавляются новые возможности, улучшаются сценарии использования, исправляются ошибки и уязвимости продукта.
В основном при выпуске релизов мы стараемся придерживаться режима «один релиз в год» — исходя из специфики и накладных расходов по сертификации релизов по требованиям различных регуляторов (ФСТЭК, ФСБ). Обычно процесс сертификации после выпуска релиза занимает от полугода до года.
На данный момент ситуация по релизам следующая:
Релиз | Актуальность | Сертификация | Архитектура |
1.1 | неактуален | сертифицирован (ФСТЭК) | x64 |
1.3 | неактуален | сертифицирован (ФСТЭК) | x64 |
1.4 | неактуален | сертифицирован (ФСТЭК) | x64 |
2.0 | неактуален | сертифицирован (ФСТЭК) | x64 |
2.1.2 | актуален | сертифицирован (ФСТЭК) | x64 |
3.0.1 | актуален | на сертификации (ФСТЭК, ФСБ) | x64, aarch64 |
3.1 | в разработке (ожидается выпуск в первом квартале 2023 г.) | будет передан на сертификацию (ФСТЭК, ФСБ) | x64, aarch64 |
Сравнение ViPNet SafeBoot с альтернативными решениями
Сравнение с программно-аппаратными средствами доверенной загрузки
На российском рынке использование программно-аппаратных средств доверенной загрузки (АПДМЗ) де-факто является стандартом обеспечения безопасности физических серверов и конечных узлов информационных систем.
Принцип действия АПДМЗ заключается в старте кода уровня системы в виде PCI Option ROM с PCI-совместимой платы, подключаемой к целевой платформе. В целом, возможности подобных средств потенциально могут быть сопоставимы с ViPNet SafeBoot.
Так ли удобны и функционально сравнимы АПМДЗ с чисто программными средствами (а именно — с ViPNet SafeBoot)?
Преимущества ViPNet SafeBoot по сравнению АПМДЗ:
возможность установки в платформы, в которых отсутствуют свободные аппаратные разъемы для подключения АПДМЗ (например, в мобильные платформы);
ранняя точка старта;
простота доверенной доставки/активации;
скорость появления новых версий не зависит от аппаратной составляющей;
возможность работы на отличных от x64 процессорных архитектурах;
стоимость.
Недостатки ViPNet SafeBoot по сравнению АПМДЗ:
отсутствие аппаратного watchdog-таймера, подключаемого в разрыв цепи питания целевой платформы (на самом деле далеко не на каждой платформе можно подключить такой watchdog-таймер, что обычно сводится к тому, что на этот вопрос на практике просто закрывают глаза);
отсутствие возможности реализовать полностью автономное хранилище информации (решается средствами защиты доступа к стандартному хранилищу или реализацией автономного хранилища программными средствами, что описано выше).
Сравнение с Secure Boot (и его расширениями)
Стандартом де-факто (базовым) по доверенной загрузке ОС является технология Secure Boot.
Принцип действия Secure Boot заключается в верификации подписи (или сравнении хэшей) загружаемых с диска модулей (драйверов, утилит, загрузчиков ОС) на сертификатах, установленных в служебных NVRAM-переменных PK, KEK, db, dbx (при верификации подписи). Непосредственная передача управления загрузчику ОС не входит в прямую зону ответственности Secure Boot.
Достаточно ли возможностей Secure Boot, чтобы закрыть вопрос доверенной загрузки ОС в рамках заявленной функциональности?
Преимущества ViPNet SafeBoot по сравнению с Secure Boot:
возможность гибкой настройки контроля целостности загружаемой исполняемой среды - с возможностью постановки на контроль целостности всех необходимых исполняемых файлов ОС, без необходимости переподписи исполняемых файлов при смене ключа и т.д.;
автоматизация процесса постановки на контроль целостности (процесс управления ключами контроля целостности в Secure Boot достаточно сложный);
использование ГОСТ-криптографии для контроля целостности;
наличие собственных средств защиты от обхода разных уровней (по сравнению с простой и потенциально нулевой защитой на базе пароля на вход в BIOS Setup в Secure Boot).
Недостатки ViPNet SafeBoot по сравнению с Secure Boot:
необходимость в дополнительной установке;
требуются новые знания по методам работы с ViPNet SafeBoot.
Заключение
Мы попытались представить наш продукт ViPNet SafeBoot с технической точки зрения. Готовы к обратной связи, у нас много планов по развитию ViPNet SafeBoot! Мы открыты к предложениям и ждем комментариев от тех, кто уже эксплуатирует наш продукт и от тех, кто только узнал о его существовании.
