Intel bios guard support что это
Предлагаю окунуться в дебри микроархитектуры компьютера и разобраться с тем, как работает одна из наиболее распространенных технологий обеспечения аппаратной целостности загрузки BIOS — Intel Boot Guard. В статье освещены предпосылки появления технологии, перечислены все режимы работы, а так же описан алгоритм каждого из них. Обо всем по порядку.
История и предпосылки создания
Процесс загрузки компьютера представляет собой цепочку событий, в которой управление исполнительной аппаратурой передается от звена к звену, начиная с нажатия пользователем кнопки включения и заканчивая работой приложения. Проблема заключается в том, что каждое из этих звеньев может быть взломано злоумышленником. Причем чем более раний компонент подвергается атаке, тем большую свободу действий получает правонарушитель. Известны случаи атак, при которых злоумышленник заменял BIOS или Boot loader на собственные, уязвимые и по сути превращал компьютер в «кирпич» (именно поэтому такой тип атак называется Bricking). В попытках защитить процесс загрузки компьютера были созданы многие программные средства проверки целостностности. Однако любая программа может быть успешно заменена правонарушителем, поэтому на нее невозможно полагаться на сто процентов. Отсюда и возникла необходимость создания более надежной, аппаратной технологии обеспечения целостности загрузки.
В качестве своего варианта обеспечения аппаратной защиты загрузки компьютера Intel в 2013 году встроила в новую микроархитектуру Haswell технологию Boot Guard. В процесс загрузки был добавлен аппаратный модуль аутентифицированного кода (ACM, Authenticated code module), а производителям оборудования пришлось расширить BIOS, добавив в него начальный блок загрузки (IBB, Initial boot block). С тех пор цепочка загрузки компьютера включает в себя ACM, с помощью которого проверяется IBB, после чего управление передается BIOS и так далее.
Схема процесса загрузки компьютера с Intel Boot Guard
Режимы работы
Важной составляющей технологии Boot Guard является настройка ее работы. Производитель оборудования должен выбрать, какой режим работы активирован и какие действия стоит предпринимать в случае ошибки в ACM или IBB. Вся этак информация содержится в политиках загрузки, которые «зашиты» в аппаратуре.
Режимы работы Boot Guard можно классифицировать по корню доверия:
Измеренная загрузка (Measured boot) полагается на дополнительное устройство, встраиваемое производителем оборудования. Одним из возможных вариантов устройства является TPM (Trusted platform module) — криптопроцессор, в который предустановлены генератор случайных чисел, генератор ключей RSA, устройство хеширования и устройство RSA.
Проверенная загрузка (Verified boot) полагается на программируемые предохранители, которые являются частью аппаратуры компьютера. По своей сути, программируемый предохранитель — это ячейка, которая может находиться в двух состояниях: сожжена или не сожжена. Будучи сожженной, ячейка не может вернуться в исходное состояние. Таким образом можно кодировать информацию.
Измеренная загрузка
В памяти криптопроцессора TPM хранится эталон хеша начального блока загрузки (IBB), с помощью которого и производится проверка подлинности IBB. Алгоритм работы Boot Guard в режиме измеренной загрузки следующий:
Начальный блок загрузки записывается в память криптопроцессора TPM
Устройство хеширования криптопроцессора загружает записанный в памяти IBB
Устройство хеширования вычисляет хеш IBB
Хеш IBB записывается в память криптопроцессора
Производится сравнение между текущим хешем IBB и его эталоном
В случае совпадения состема помечается как надежная, иначе — как ненадежная
Проверенная загрузка
Схема работы Boot Guard в режиме измеренной загрузки выглядит несколько сложнее, поскольку помимо начального блока загрузки (IBB) и программируемых предохранителей в нее входят две дополнительные структуры: манифест IBB (IBBM) и манифест ключа. Манифест IBB включает в себя номер версии безопасности, хеш IBB, открытый ключ RSA, подпись RSA номера версии и хеша IBB. Манифест ключа включает в себя номер версии безопасности, хеш открытого ключа RSA манифеста IBB, открытый ключ RSA производителя оборудования, подпись RSA номера версии и хеша открытого ключа RSA манифеста IBB. В программируемых предохранителях записаны хеш открытого ключа RSA производителя и номера версий безопасности манифестов. Все вычисления и сравнения выполняются с помощью модуля аутентифицированного кода (ACM). Алгоритм работы Boot Guard в режиме проверенной загрузки следующий:
В ACM загружаются хеш открытого ключа RSA производителя и номера версий безопасности манифестов из программируемых предохранителей.
Проверяются номера версий безопасности манифестов. Если хотя бы один из номеров оказался меньше, то проверка завершается в соответствии с политиками загрузки. Если хотя бы один из номеров оказался больше, то соответствующее значение будет обновлено в программируемых предохранителях в конце проверки.
Вычисляется хеш открытого ключа RSA производителя и производится сравнение с соответствующим значением из программируемых предохранителей. В случае несовпадения проверка завершается в соответствии с политиками загрузки.
Проверяется подпись RSA в манифесте ключа. В случае несоответствия проверка завершается в соответствии с политиками загрузки.
Вычисляется хеш открытого ключа RSA манифеста IBB и производится сравнение с соответствующим значением из манифеста ключа. В случае несовпадения проверка завершается в соответствии с политиками загрузки.
Проверяется подпись RSA в манифесте IBB. В случае несоответствия проверка завершается в соответствии с политиками загрузки.
Вычисляется хеш IBB и производится сравнение с соответствующим значением из IBBM. В случае несовпадения проверка завершается в соответствии с политиками загрузки.
В случае необходимости номера версий безопасности манифестов обновляются в программируемых предохранителях путем сжигания дополнительного числа предохранителей.
Начальный блок загрузки успешно проверен и ему передается управление.
Заключение
В заключение хотелось бы добавить, что не смотря на всю прелесть и надежность Boot Guard, важно понимать, что настройка этой технологии доверена производителю оборудования. В 2017 году были обнаружены шесть моделей материнских плат, в которых Boot Guard была настроена некорректно и позволяла обойти проверку целостности BIOS. Берегите свои компьютеры и выбирайте надежного производителя оборудования!
При написании статьи была использована литература:
Предлагаю окунуться в дебри микроархитектуры компьютера и разобраться с тем, как работает одна из наиболее распространенных технологий обеспечения аппаратной целостности загрузки BIOS — Intel Boot Guard. В статье освещены предпосылки появления технологии, перечислены все режимы работы, а так же описан алгоритм каждого из них. Обо всем по порядку.
История и предпосылки создания
Процесс загрузки компьютера представляет собой цепочку событий, в которой управление исполнительной аппаратурой передается от звена к звену, начиная с нажатия пользователем кнопки включения и заканчивая работой приложения. Проблема заключается в том, что каждое из этих звеньев может быть взломано злоумышленником. Причем чем более ранний компонент подвергается атаке, тем большую свободу действий получает правонарушитель. Известны случаи атак, при которых злоумышленник заменял BIOS или Boot loader на собственные, уязвимые и, по сути, превращал компьютер в "кирпич" (именно поэтому такой тип атак называется Bricking). В попытках защитить процесс загрузки компьютера были созданы многие программные средства проверки целостностности. Однако любая программа может быть успешно заменена правонарушителем, поэтому на нее невозможно полагаться на сто процентов. Отсюда и возникла необходимость создания более надежной, аппаратной технологии обеспечения целостности загрузки.
В качестве своего варианта обеспечения аппаратной защиты загрузки компьютера Intel в 2013 году встроила в новую микроархитектуру Haswell технологию Boot Guard. В процесс загрузки был добавлен аппаратный модуль аутентифицированного кода (ACM, Authenticated code module), а производителям оборудования пришлось расширить BIOS, добавив в него начальный блок загрузки (IBB, Initial boot block). С тех пор цепочка загрузки компьютера включает в себя ACM, с помощью которого проверяется IBB, после чего управление передается BIOS и так далее.
Схема процесса загрузки компьютера с Intel Boot Guard
Режимы работы
Важной составляющей технологии Boot Guard является настройка ее работы. Производитель оборудования должен выбрать, какой режим работы активирован и какие действия стоит предпринимать в случае ошибки в ACM или IBB. Вся эта информация содержится в политиках загрузки, которые "зашиты" в аппаратуре.
Режимы работы Boot Guard можно классифицировать по корню доверия:
Измеренная загрузка (Measured boot) полагается на дополнительное устройство, встраиваемое производителем оборудования. Одним из возможных вариантов устройства является TPM (Trusted platform module) — криптопроцессор, в который предустановлены генератор случайных чисел, генератор ключей RSA, устройство хеширования и устройство RSA.
Проверенная загрузка (Verified boot) полагается на программируемые предохранители, которые являются частью аппаратуры компьютера. По своей сущности программируемый предохранитель — это ячейка, которая может находиться в двух состояниях: сожжена или не сожжена. Будучи сожженной, ячейка не может вернуться в исходное состояние. Таким образом можно кодировать информацию.
Измеренная загрузка
В памяти криптопроцессора TPM хранится эталон хеша начального блока загрузки (IBB), с помощью которого и производится проверка подлинности IBB. Алгоритм работы Boot Guard в режиме измеренной загрузки следующий:
Начальный блок загрузки записывается в память криптопроцессора TPM
Устройство хеширования криптопроцессора загружает записанный в памяти IBB
Устройство хеширования вычисляет хеш IBB
Хеш IBB записывается в память криптопроцессора
Производится сравнение между текущим хешем IBB и его эталоном
В случае совпадения состема помечается как надежная, иначе — как ненадежная
Проверенная загрузка
Схема работы Boot Guard в режиме измеренной загрузки выглядит несколько сложнее, поскольку помимо начального блока загрузки (IBB) и программируемых предохранителей в нее входят две дополнительные структуры: манифест IBB (IBBM) и манифест ключа. Манифест IBB включает в себя номер версии безопасности, хеш IBB, открытый ключ RSA, подпись RSA номера версии и хеша IBB. Манифест ключа включает в себя номер версии безопасности, хеш открытого ключа RSA манифеста IBB, открытый ключ RSA производителя оборудования, подпись RSA номера версии и хеша открытого ключа RSA манифеста IBB. В программируемых предохранителях записаны хеш открытого ключа RSA производителя и номера версий безопасности манифестов. Все вычисления и сравнения выполняются с помощью модуля аутентифицированного кода (ACM). Алгоритм работы Boot Guard в режиме проверенной загрузки следующий:
В ACM загружаются хеш открытого ключа RSA производителя и номера версий безопасности манифестов из программируемых предохранителей.
Проверяются номера версий безопасности манифестов. Если хотя бы один из номеров оказался меньше, то проверка завершается в соответствии с политиками загрузки. Если хотя бы один из номеров оказался больше, то соответствующее значение будет обновлено в программируемых предохранителях в конце проверки.
Вычисляется хеш открытого ключа RSA производителя и производится сравнение с соответствующим значением из программируемых предохранителей. В случае несовпадения проверка завершается в соответствии с политиками загрузки.
Проверяется подпись RSA в манифесте ключа. В случае несоответствия проверка завершается в соответствии с политиками загрузки.
Вычисляется хеш открытого ключа RSA манифеста IBB и производится сравнение с соответствующим значением из манифеста ключа. В случае несовпадения проверка завершается в соответствии с политиками загрузки.
Проверяется подпись RSA в манифесте IBB. В случае несоответствия проверка завершается в соответствии с политиками загрузки.
Вычисляется хеш IBB и производится сравнение с соответствующим значением из IBBM. В случае несовпадения проверка завершается в соответствии с политиками загрузки.
В случае необходимости номера версий безопасности манифестов обновляются в программируемых предохранителях путем сжигания дополнительного числа предохранителей.
Начальный блок загрузки успешно проверен и ему передается управление.
Заключение
В заключение хотелось бы добавить, что несмотря на всю прелесть и надежность Boot Guard, важно понимать, что настройка этой технологии доверена производителю оборудования. В 2017 году были обнаружены шесть моделей материнских плат, в которых Boot Guard была настроена некорректно и позволяла обойти проверку целостности BIOS. Берегите свои компьютеры и выбирайте надежного производителя оборудования!
При написании статьи была использована литература:
Одной из функциональных новинок, появившихся в процессорах Intel Core шестого поколения (Skylake), стала технология Intel Software Guard Extensions (Intel SGX). Легко убедиться гуглением, что информации о ней в интернете не так много. Мы решили восполнить этот пробел, тем более что под рукой у нас оказалась статья одного из разработчиков этой технологии, Мэтью Хойкстра (Matthew Hoekstra); в ней он описывает цели, которые преследует Intel SGX. Приводим ее перевод.
Если говорить о сути, то Intel SGX – это набор новых инструкций процессора, которые могут использоваться приложениями для выделения приватных областей кода и данных. Создавая эту технологию, мы преследовали следующие цели.
Цель 1. Позволить разработчикам приложений защитить чувствительные данные от несанкционированного доступа или изменения со стороны зловредного ПО, запущенного с более высокими привилегиями.
Хотел бы выделить в этом пункте несколько принципиальных моментов. Первое, защита чувствительных данных подразумевает обеспечение и их конфиденциальности (предотвращение утечек), и целостности (защита от подделок). Второе, защищать необходимо не только данные, но и код (например, атакующий может легко получить доступ к данным, изменив или отключив авторизацию). Третье, данные должны быть защищены не только когда они хранятся в зашифрованном виде, но и во время рантайма, когда они не зашифрованы и активно используются для вычислений. Наконец, критически важно обеспечить защиту рантайма против вредоносного ПО, обошедшего систему контроля привилегий с целью получить более высокий уровень прав.
Цель 2. Позволить приложениям обеспечивать конфиденциальность и целостность чувствительных данных и кода, не вмешиваясь в работу системы контроля привилегий, не мешая ей планировать и контролировать ресурсы платформы.
Чувствительные данные и код должны быть защищены от вредоносного ПО запущенного с высоким уровнем прав, однако в то же время система контроля привилегий должна постоянно делать свою работу, мешать ей нельзя. Недопустимо, чтобы защищаемые приложения брали на себя или нарушали базовую функциональность системы, такую как планирование задач, управление устройствами и т.д. Операционные системы развивались много лет, чтобы хорошо выполнять эти задачи, и создавать параллельную им сущность было бы непрактично.
Цель 3. Позволить пользователям компьютерных устройств держать над ними контроль, в то же время предоставляя свободу устанавливать и удалять приложения и сервисы.
Работа доверенного приложения не должна требовать каких-то специфических конфигураций и не должна ограничивать контроль пользователя над его компьютером. Обычной практикой обеспечения защиты сегодня является жесткое ограничение набора приложений, которое может быть загружено на платформу. В игровые приставки, смартфоны и т.д. сейчас обычно встроена специализированная операционная система, которая накладывает различного рода ограничения на доступность и поведение приложений, дабы не допустить проблем с безопасностью.
Корпоративное использование устройств может налагать еще более строгие дополнительные ограничения (например, на подключения USB-накопителей). В принципе, в этих мерах нет ничего плохого, но они не должны быть обязательными для обеспечения конфиденциальности и целостности данных. Это условие становится еще более очевидным, если мы будем говорить о персональном ПК, где необходимость в доверенном окружении так же велика, как и потребность в персонализации.
Цель 4. Позволить платформе измерять доверенный код приложения и производить с помощью процессора подписанный аттестат, который включает в себя это измерение и прочие сертификаты, удостоверяющие, что код был корректно инициализирован в доверенной среде.
Разрешая пользователю контролировать ПО на платформе, мы порождаем проблему доверенной доставки приложений. Как кто-либо может быть уверен, что платформа обладает всеми необходимыми примитивами для поддержки доверенных вычислений, которые требуются приложению, или что установленное приложение не было подделано? Или, говоря другими словами, как приложение может доказать, что оно доверенное?
Чтобы определить, было ли приложение корректно загружено и инициализировано, можно сравнить подпись приложения (криптографический хэш его отпечатка памяти в заранее заданной точке исполнения) с ожидаемым значением, полученным из считающейся доверенной системы – это называется измерением приложения. Чтобы подтвердить свое происхождение, измерение подписано приватным ключом, известным только доверенной системе, которая производит измерение.
Отметим, что разработчики не могут полагаться на вычисления, делаемые программно системой; как говорилось ранее, ПО всегда можно виртуализировать или обмануть с помощью вредоносной программы, имеющей достаточный уровень привилегий. Таким образом, вычисление должно быть аппаратным и исполняться тем же компонентом, которое создает доверенную среду, загружает/инициализирует доверенное приложение и осуществляет вычисление чувствительных данных.
Цель 5. Позволить разработчикам создавать доверенные приложения с использованием известных им средств и процессов.
Первые 4 цели обеспечивают преимущества более закрытой среды путем уменьшения набора сущностей, которые должны быть доверенными, при этом платформы остаются открытыми а выбор пользователя – свободным. Однако из этого не следует, что процесс разработки ПО останется неизменным. Например, если выяснится, что разработчикам придется кардинально менять свои процессы или они будут вынуждены писать софт под проприетарный контроллер безопасности, продуктивность процесса значительно уменьшится.
Цель 6. Позволить производительности доверенных приложений увеличиваться с ростом производительности процессоров.
Эта цель вырастает из идеи минимализации влияния на существующий процесс разработки ПО. Одной из движущих сил этого процесса состоит в том, что разработчики пытаются получить максимум преимуществ от увеличивающейся производительности процессора. Было бы здорово, если бы доверенные приложения не имели проблем с производительностью по сравнению с прочими.
Цель 7. Позволить производителям ПО распространять и обновлять приложения, используя наиболее удобные для них способы.
Если предлагаемое решение требует, чтобы независимые создатели ПО тесно работали с производителями платформ с целью предустановить их приложения в момент производства платформы или же обновления ПО могут быть установлены только вместе с обновлением системы, это также будет помехой созданию инновационных продуктов.
Цель 8. Позволить приложениям определять защищенные области кода и данных, которые содержат конфиденциальность, даже в том случае, если атакующий физически контролирует платформу и может производить прямые атаки на ее память.
Эффективное решение должно обеспечивать защиту от различных типов аппаратных атак, включая и те случаи, когда платформа физически находится в распоряжении врага. Исследователи Принстонского университета демонстрируют одну из таких атак. Возможны и другие варианты с использованием анализаторов шины памяти или подобных техник.
В прошлом году мы в блоге Intel уже публиковали пост о технологии Intel Software Guard Extensions (Intel SGX), поддержку которой внедрили в процессорах Intel Core шестого поколения. Тогда речь шла в основном об идеологических моментах; думается, настало время рассказать, как это работает. В этом посте будет много иллюстраций из подробной (более 200 слайдов) презентации Intel, посвященной этой технологии. В ней, конечно, сказано гораздо больше, чем здесь, так что вы теперь знаете, где можно продолжить изучение вопроса.
Кольца защищенного режима разделяют привилегированный код ядра и код приложений, а также отделяют приложения друг от друга. Однако при этом приложения не защищены от атак со стороны привилегированного кода. Зловредное приложение может проникнуть в него с помощью эксплойта и затем внедриться в беззащитную жертву. При этом участок для атаки очень широк: нападать можно и на компоненты ОС, и на само приложение, и даже на аппаратную подсистему.
Смысл SGX состоит в том, чтобы сузить периметр защиты, разместив все критически важные данные в отдельных областях-анклавах, недоступные даже из кода ядра. При этом, однако, не должен коренным образом изменяться процесс разработки и среда, где исполняется приложение.
Приложение состоит из двух частей: доверенного и общего. При запуске оно создает анклав в защищенной части памяти, состоящий из страниц размером 4 Кб. При вызове доверенной функции она видит данные анклава, любой другой внешний доступ (в том числе и со стороны ОС) запрещен. После окончания работы функции анклав остается в защищенной области.
Среда защищенного исполнения встроена в пользовательский процесс, у нее собственные код и данные. Она обеспечивает безопасность, целостность данных, контроль входных точек, поддерживает многопоточность.
При попытке доступа к анклаву проверяется, находятся ли по данному адресу данные вызывающего процесса (EPC, Enclave Page Cache). Далее подвергаются контролю полномочия функции (EPCM, Enclave Page Cache Metadata), и только потом предоставляется требуемый доступ.
Аттестация происходит следующим образом. Анклав запрашивает аппаратно подписанный отчет, содержащий, в том числе информацию о целостности анклава. Этот отчет отсылается на аттестующий сервер, где происходит его верификация. Анклаву высылается ключ приложения (открытая часть ключа), где генерируется подписывающий (приватный) ключ, зависящий от анклава и платформы. Ключ приложения шифруется подписывающим ключом и сохраняется для дальнейшего использования.
Функционал Intel Software Guard Extensions реализуется с помощью комбинации SGX инструкций, поддерживающих локальную аттестацию и предоставляемого Intel аттестационного анклава для поддержки удаленной аттестации.
Разработчики SGX предусмотрели защиту от различного рода атак на данные и код: угрозы со стороны пользовательского и системного ПО, а также загрузчика. Заметим, что средствами SGX невозможно защититься от side-channel уязвимостей, когда злоумышленники собирают статистику использования ЦПУ для определения характеристик исполняемого на нем кода. Для решения подобного рода задач предназначены средства динамического анализа программ, такие, например, как Pin.
Для предотвращения перехвата данных при обмене между процессором и памятью используется Memory Encryption Engine (MEE), работающий как расширение контроллера памяти и поддерживающий технологию SGX. Для определенных областей памяти осуществляется шифрование данных, передающихся по шине. MEE использует специальные комбинации криптографических примитивов для эффективного шифрования при очень жестких требованиях по задержкам.
Как выглядит разработка приложений, поддерживающих SGX? Чувствительные фрагменты кода и данных размещаются в отдельном shared object (.so). Далее определяются интерфейса анклава и генерируются заглушки. Библиотеки SGX взаимодействуют с кодом через API, для разработки используются обычные, привычные для разработчика тулчейны. Для облегчения процесса обработки уже имеется Intel SGX SDK.
Что обещает нам технология Intel SGX? Прежде всего то, что требования к техническим навыкам пользователя, работающего с конфиденциальной информацией, могут быть сильно сокращены. Ей больше не страшны вирусы, трояны и странные программы, которые могут иметься на его компьютере. Далее, повысится доверие к облачным платформам – им можно будет доверять свои приложения, поскольку они будут защищены от любого кода хоста. Конечно, все это дело довольно далекого будущего, ведь процессоры Skylake еще только появились. Но использовать SGX можно уже сейчас. Мы готовы углубляться в эту тему и отвечать на любые вопросы, с ней связанные.
Рекомендуем почитать:
В августе 2017 года, на конференции Black Hat USA 2017, специалист компании Cylance Алекс Матросов (Alex Matrosov) представил доклад, посвященный уязвимостям, которые он обнаружил в имплементациях Intel UEFI BIOS ряда производителей материнских плат. Тогда исследователь рассказал, что найденные им баги позволяют обойти защитные механизмы BIOS, в том числе Intel Boot Guard и Intel BIOS Guard, а также изменить или подменить сам UEFI BIOS, к примеру, внедрив в него руткит.
Протестированные исследователем устройства базировались на популярной среди OEM-производителей AMI Aptio UEFI BIOS (используют Gigabyte, MSI, Asus, Acer, Dell, HP, ASRock и другие). Тогда Матросов рассказал о шести уязвимостях в четырех материнских платах:
- ASUS Vivo Mini: CVE-2017-11315;
- Lenovo ThinkCentre systems: CVE-2017-3753;
- MSI Cubi2: CVE-2017-11312 и CVE-2017-11316;
- Gigabyte серия BRIX: CVE-2017-11313 и CVE-2017-11314.
Исследователь сетовал, что производители материнских плат не используют аппаратные защитные механизмы, в том числе представленные Intel много лет назад, такие как защитные биты для SMM и SPI (BLE, BWE, PRx). А так как активной защиты памяти на аппаратном уровне нет, устройства этих производителей в теории становятся легкими мишенями для атакующих.
Теперь исследование Матросова продолжил специалист компании Embedi Александр Ермолов. Эксперт обошел защиту Intel Boot Guard на материнский плате Gigabyte GA-H170-D3H, и в процессе выяснил, что проблема, скорее всего, распространяется даже дальше, чем предполагалось изначально.
Ермолов связался с представителями AMI, чтобы уведомить их о проблеме, но ему сообщили, что уязвимости уже были устранены и последняя версия AMI BIOS, доступная для производителей, уже лишена таких недостатков. Когда исследователь решил проверить работу патча, оказалось, что исправление, по сути, лишь ухудшило и без того скверную ситуацию. С полным описанием проблемы можно ознакомиться в блоге Embedi.
Читайте также: