Аппаратный корень доверия

Последовательность загрузки машины обычно начинается с запуска BMC (Baseboard Management Controller) или PCH (Platform Controller Hub). Например, ещё до запуска процессора Intel ядро управления работает с PCH. После настройки аппаратного обеспечения PCH позволяет процессору «включиться», а уже процессор загружает BIOS/UEFI по последовательному переферийному интерфейсу (SPI-шине, Serial Peripheral Interface). Прошивка обращается к загрузочному сектору в постоянном хранилище компьютера и подгружает загрузчик (например, GRUB). Тот загружает из хранилища образ операционной системы в системную память и передает управление операционной системе. Похоже на эстафету, когда члены команды по очереди передают друг другу эстафетную палочку, чтобы все вместе выиграли гонку.

В соревнованиях мы уверены в своей команде и доверяем каждому из членов команды часть общей работы, чтобы добраться до финиша. С машинами эта цепочка доверия немного сложнее. Как мы можем проверить, что на каждом шаге загрузки запускается безопасное программное обеспечение? Если оборудование или программа были скомпрометированы в любой точке загрузки, злоумышленник может получить привилегии и сможет делать абсолютно все.

Цель аппаратного корня доверия – убедиться, что программное обеспечение, установленное в каждом компоненте аппаратного обеспечения, является «именно тем» ПО и проверить, было ли что-то взломано или перезаписано.

Модуль доверенной платформы (TPM)

Модуль доверенной платформы (англ. Trusted Platform Module, TPM) – это микросхема, предназначенная для защиты аппаратного обеспечения с помощью встроенных криптографических ключей. Модуль обычно устанавливается на материнской плате и взаимодействует с системой по аппаратной шине.

Модуль имеет следующие функции:

• генератор случайных чисел;
• генерация криптографических ключей;
  
• проверка целостности;
  
• аттестация ключей доверенного платформенного модуля;
• работа с ключами.
  

Проверка целостности

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

Аттестация

Аттестация фиксирует состояние аппаратного и программного обеспечения. Цель аттестации – доказать, что операционная система и программное обеспечение не повреждены и заслуживают доверия. Верификатор доверяет точности данных аттестации, поскольку они подписаны TPM, ключ которого проверен центром сертификации. TPM изготавливаются с парой уникальных public/private ключей, встроенных в аппаратное обеспечение.

Упаковка и привязка ключа

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

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

Собственные чипы

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

Google Titan

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

Целостность первой инструкции

Проверка целостности первой инструкции (англ. first-instruction integrity) заключается в тестировании кода, выполняемого первым в цикле запуска каждой машины. Titan наблюдает за каждым байтом прошивки, вклиниваясь через шину SPI между загрузочной прошивкой BMC (или PCH) и главным процессором. Последовательность загрузки в данном случае с чипом Titan будет отличаться от обычной последовательности:

• Titan удерживает машину в ресете.
• Программа Titan выполняет код из встроенной памяти (ПЗУ).
  
• Titan запускает встроенный самотест памяти, чтобы убедиться, что вся память (включая ПЗУ) не была подделана.
  
• Titan проверяет собственную прошивку с помощью public-ключа и сравнивает принадлежность кода к иерархии ключа Titan.
  
• Загружается проверенная прошивка.
  
• На хосте проверяется BIOS/UEFI.
  
• Из ресета выводится остальная часть машины.
  
• Центральный процессор загружает BIOS/UEFI из загрузочной прошивки, которая выполняет дальнейшую аппаратную/программную настройку.
  
• Далее следует стандартная последовательность загрузки.
  

Удерживая машину в ресете и проверяя загрузочную прошивку, Titan включает проверку первой инструкции. Он знает, какие загрузочные прошивки и ОС загружаются на машине, и даже какие патчи могли быть получены до первой инструкции загрузочной прошивки.

Исправление ошибок

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

Cerberus от Майкрософт

Как и Titan, криптографический чип Cerberus от Microsoft также помещается на шину SPI и непрерывно контролирует доступ для обеспечения целостности встроенного ПО и защиты от несанкционированного вмешательства и вредоносных обновлений.

Apple T2

Чип Apple T2 поддерживает безопасную загрузку машин Apple. В отличие от Titan и Cerberus, которые взаимодействуют через SPI, T2 предоставляет прошивку и загружает CPU по шине eSPI (Enhanced Serial Peripheral Interface).

Последовательность загрузки машины на T2:

• Загружается и выполняется T2 ROM.
  
• Т2 ROM передает управление iBoot-загрузчику.
  
• Загрузчик выполняет ядро bridgeOS (ядро T2-чипа).
  
• bridgeOS переходит к UEFI чипа T2.
  
• Микросхема T2 выводит процессор из ресета.
  
• Процессор подгружает загрузчик macOS.
  
• Выполняется ядро macOS.
  

Одной из важных особенностей чипа T2 является проверка версии MacOS, работающей на компьютере. T2 проверяет хэш MacOS на соответствие списку одобренных хэшей для запуска. Именно на этом уровне Apple контролирует запуск других (не яблочных) ОС на своих устройствах.

Отказоустойчивость платформы (PFR)

Обеспечение целостности микропрограммного обеспечения, обнаружение повреждений и восстановление частей микропрограммного обеспечения обратно в состояние целостности, построено на основе рекомендаций Национального института стандартов и технологий (США).

PFR устраняет уязвимость в энтерпрайз-серверах с модулями мультиобработки, каждый из которых имеет свою собственную прошивку. Эта прошивка может быть атакована хакерами, которые могут тайно установить вредоносный код во флэш-память модуля и оставить систему навсегда скомпрометированной.

Спецификация PFR основана на таких принципах:

• Защита: гарантируется, что код микропрограммы и критические данные остаются в состоянии целостности и защищены от повреждения.
• Обнаружение: фиксирование момента, когда код прошивки или критические данные были повреждены.
  
• Восстановление: возвращение кода прошивки и критических данных до состояния целостности или принудительное восстановление с помощью авторизованного механизма.
  

UEFI Secure Boot

UEFI Secure Boot предназначен для проверки бинарников EFI, исполняемых во время загрузки, с помощью контрольной суммы или валидной сигнатуры, подкрепленной доверенным сертификатом. Пользователь может настроить список доверенных сертификатов и контрольных сумм с помощью EFI переменных, которые хранятся в энергонезависимой памяти UEFI.

Ядро UEFI чрезвычайно сложное и содержит миллионы строк кода. Оно состоит из служб загрузки и служб рантайма. UEFI является дырой для многих уязвимостей, так как имеет один и тот же проприетарный код, используемый на различных платформах. Поскольку UEFI живет в прошивке CPU, обычно хранимой во флэш-памяти SPI, пробравшиеся туда эксплойты могут «натворить дел». Даже если юзер переустановит ОС или заменит жесткий диск, уязвимость останется.

Intel's Boot Guard

Boot Guard – это решение Intel для проверки сигнатур прошивки процессора. Boot Guard работает путем внедрения public-ключа BIOS в программируемой памяти внутри Intel Management Engine. У машины есть открытый ключ BIOS, и она может проверять правильность подписи во время каждой последующей загрузки. Как только производитель включил данную функцию, отключить ее больше не получится.

Проблема Boot Guard заключается в том, что только Intel или производитель имеют ключи для подписи прошивки. Это делает невозможным использование coreboot, LinuxBoot или любых других эквивалентов в качестве прошивки на этих процессорах. Если все-таки попытаться загрузить такую альтернативу, то прошивка не подпишется правильным ключом, что приведет к «окирпичиванию» девайса.

Прозрачность системы

Прозрачность системы – это процесс, направленный на улучшение доверия к компонентам системы путем предоставления каждому серверу cледующих компонентов:

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

Все это достигается с помощью следущих принципов:

1. Привязка идентификатора. Ключевая задача каждого сервера – связать уникальную “личность” сервера с трудноповторимым элементом, своего рода капчей.
2. Физическая защита прошивки от записи. Доступные для записи разделы кода имеют изменяемое состояние. Код, доступный только для чтения, служит источником доверия для других механизмов безопасности.
3. Обнаружение подделки. Злоумышленников невозможно остановить путем физической замены чипа, т. е. необходимо выявить нарушения физической целостности серверного оборудования и принять соответствующие меры.
4. Измеряемая загрузка. Этот инструмент в сочетании с удаленной проверкой позволяет третьим лицам получить криптографический журнал загрузки всех компонентов в системе.
5. Воспроизводимая сборка. Гарантирует, что если бинарник собран один раз, он может быть собран снова и снова для производства того же бинарника.
6. Неизменная инфраструктура. Прозрачность системы работает только тогда, когда на изменения стоит ограничение. Если разрешить кому-либо войти в систему и внести произвольные изменения – это аннулирует все гарантии загрузки.
7. Бинарный журнал прозрачности. Все микропрограммы и образы ОС, которые могут быть загружены в систему, подписываются владельцем системы, а записи об этом вставляются в общедоступный журнал.

Подводя итог

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

Прошивка разбросана по всем компонентам машины. Она находится в: CPU, сетевушке, SSD/HDD, графическом процессоре, и даже в контроллере вентиляторов. Чтобы обеспечить целостность машины, все эти компоненты должны быть проверены. В будущем описанные выше чипы будут устанавливаться не только на SPI flash, но и на другие устройства, связывающиеся с BMC.

Если вам интересна тема безопасности программных систем, у нас также имеются следующие материалы:

• Qwerty уже не тот. Как хакеры взломали аккаунты 270 млн пользователей
• «Я тебя по IP вычислю»: как хакеры рассекречивают звенья цепи Tor
  
• Шифруйся: лучшее бесплатное ПО для защиты данных