Отключаем Secure Boot на ноутбуках и ПК (UEFI Secure Boot)
Если вы купили ПК или ноутбук с предустановленной операционной системой Windows 8, а потом захотели удалить ее изменить, например, “семеркой” или вообще какой-либо версий ОС Linux, то у вас возникнут с этим проблемы, из-за системы безопасной загрузки “Secure Boot”.
Разработчики компании Microsoft при разработке последней версии ОС Windows 8 полностью отказались от поддержки шестнадцати битных версий BIOS. Вместо этого система стала на 100% совместима с так называемой UEFI BIOS, обладающей системой безопасной загрузки “Secure Boot”.
Система Secure Boot предназначена для того, чтобы не позволить запуск вредоносных программ до загрузки операционной системы и антивирусного ПО соответственно.
Казалось бы, очень даже замечательная система, но, из-за Secure Boot получается попросту невозможным установить на ПК другую операционную систему или программное обеспечение, не имеющее цифровой подписи. Приведем простой пример. Вы купили новый компьютер с предустановленной Windows 8 и решили установить на него дополнительно или вместо “восьмерки” ОС Windows 7 или какую-нибудь Unix подобную систему. Можете забыть про это, функция безопасной загрузки не позволит этого сделать. Если вы не согласны с таким положением дел, то вам потребуется выполнить отключение Secure Boot в UEFI BIOS, то есть зайти в систему ввода-вывода и отключить эту назойливую систему.
Производители современных материнских плат в большинстве своем деактивируют данную функцию еще до комплектации ими устройств или поступления их в продажу. Если разработчики Unix подобных систем уже решили данную проблему в своих ОС добавив в них поддержку безопасной загрузки UEFI BIOS, то вот их коллеги из Microsoft совсем не намерены вносить изменения в Windows Vista и Windows 7. А учитывая то, что данными системами пользуется много миллионов человек, то знать, как отключить Secure Boot просто необходимо, чтобы полноценно пользоваться ПК.
Отключается Secure Boot очень просто, для этого нужно перезагрузить ПК и в самом начале его загрузки несколько раз нажать клавишу “Del” На клавиатуре (возможны другие варианты клавиши, например, F8 или F2), чтобы запустить BIOS (система ввода-вывода).
Мы не станет описывать процесс отключения Secure Boot для всех BIOS (имеется ввиду разработчиков ПО). Так как это просто не реально, да и не имеем мы пока такой возможности, чтобы под рукой были настольные и мобильные ПК всех производителей. Расскажем на примере Pheonix SecureCore Tiano, данная BIOS используется практически на всех ноутбуках, производимых компанией Samsung, а также для UEFI BIOS Utility Asus.
CSM – это модуль поддержки совместимости для операционной системы. Если ваша материнская плата снабжена отличными от описанных выше разработчиками BIOS (UEFI), то дополнительно к описанным действиям пробуйте активировать функцию Legacy BIOS.
Если после проделанных рекомендаций у вас все ровно не получается установить операционную систему отличную от Windows 8, то поэкспериментируйте с переключением SATA контролера в режим AHCI.
CSM означает Compatibility Support Module for Operating System. В других BIOS (UEFI), возможно, нужно будет включить опцию совместимости: Legacy BIOS. Если возникнут проблемы с установкой, то можно попробовать переключить SATA контроллер в режим AHCI. Как это делается написано в статье “Включаем поддержку ACHI у SATA-дисков”
Немного про UEFI и Secure Boot
UEFI (Unified Extensible Firmware Interface) — замена устаревшему BIOS. Эта спецификация была придумана Intel для Itanium, тогда она еще называлась EFI (Extensible Firmware Interface), а потом была портирована на x86, x64 и ARM. Она разительно отличается от BIOS как самой процедурой загрузки, так и способами взаимодействия с ОС. Если вы купили компьютер в 2010 году и позже, то, вероятнее всего, у вас UEFI.
Основные отличия UEFI от BIOS:
Как происходит загрузка в UEFI?
С GPT-раздела с идентификатором EF00 и файловой системой FAT32, по умолчанию грузится и запускается файл \efi\boot\boot[название архитектуры].efi, например \efi\boot\bootx64.efi
Т.е. чтобы, например, создать загрузочную флешку с Windows, достаточно просто разметить флешку в GPT, создать на ней FAT32-раздел и просто-напросто скопировать все файлы с ISO-образа. Boot-секторов больше нет, забудьте про них.
Загрузка в UEFI происходит гораздо быстрее, например, загрузка моего лаптопа с ArchLinux с нажатия кнопки питания до полностью работоспособного состояния составляет всего 30 секунд. Насколько я знаю, у Windows 8 тоже очень хорошие оптимизации скорости загрузки в UEFI-режиме.
Secure Boot
«Я слышал, что Microsoft реализовывает Secure Boot в Windows 8. Эта технология не позволяет неавторизированному коду выполняться, например, бутлоадерам, чтобы защитить пользователя от malware. И есть кампания от Free Software Foundation против Secure Boot, и многие люди были против него. Если я куплю компьютер с Windows 8, смогу ли я установить Linux или другую ОС? Или эта технология позволяет запускать только Windows?»
Начнем с того, что эту технологию придумали не в Microsoft, а она входит в спецификацию UEFI 2.2. Включенный Secure Boot не означает, что вы не сможете запустить ОС, отличную от Windows. На самом деле, сертифицированные для запуска Windows 8 компьютеры и лаптопы обязаны иметь возможность отключения Secure Boot и возможность управления ключами, так что беспокоится тут не о чем. Неотключаемый Secure Boot есть только на планшетах на ARM с предустановленной Windows!
Что дает Secure Boot? Он защищает от выполнения неподписанного кода не только на этапе загрузки, но и на этапе выполнения ОС, например, как в Windows, так и в Linux проверяются подписи драйверов/модулей ядра, таким образом, вредоносный код в режиме ядра выполнить будет нельзя. Но это справедливо только, если нет физического доступа к компьютеру, т.к., в большинстве случаев, при физическом доступе ключи можно заменить на свои.
Для Linux есть 2 пре-загрузчика, которые поддерживают Secure Boot: Shim и PRELoader. Они похожи, но есть небольшие нюансы.
В Shim есть 3 типа ключей: Secure Boot keys (те, которые в UEFI), Shim keys (которые можно сгенерировать самому и указать при компиляции), и MOKи (Machine Owner Key, хранятся в NVRAM). Shim не использует механизм загрузки через UEFI, поэтому загрузчик, который не поддерживает Shim и ничего не знает про MOK, не сможет выполнить код (таким образом, загрузчик gummiboot не будет работать). PRELoader, напротив, встраивает свои механизмы аутентификации в UEFI, и никаких проблем нет.
Shim зависит от MOK, т.е. бинарники должны быть изменены (подписаны) перед тем, как их выполнять. PRELoader же «запоминает» правильные бинарники, вы ему сообщаете, доверяете вы им, или нет.
Оба пре-загрузчика есть в скомпилированном виде с валидной подписью от Microsoft, поэтому менять UEFI-ключи не обязательно.
Secure Boot призван защитить от буткитов, от атак типа Evil Maid, и, по моему мнению, делает это эффективно.
Спасибо за внимание!
Содержание:
↑ Как отключить Secure Boot
↑ Как отключить Secure Boot на ноутбуке Toshiba. Утилита InsydeH20 setup utility
Заходим в БИОС и идём в раздел Security, видим нужную нам опцию «Secure Boot», передвигаемся к ней с помощью стрелок на клавиатуре и нажимаем Enter,
опять же с помощью стрелок выбираем Disabled (отключено)
и жмём Enter. Такими нехитрыми действиями мы смогли отключить Secure Boot в БИОСе UEFI.
Но это ещё не всё, теперь нам нужно включить режим «режим совместимости с другими операционными системами. Идём в раздел „Advanced» находим опцию «System configuration»
и заходим в неё, здесь выбираем опцию «Boot Mode» или «OS Mode Selection», и ставим её вместо положения UEFI OS (может быть UEFI BOOT) в положение «CSM Boot» или «UEFI and Legacy OS», «CMS OS»
Чтобы наши изменения вступили в силу сохраняем наши изменения в БИОС, нажимаем F10,
затем соглашаемся Yes и жмём Enter
происходит перезагрузка. Вот теперь мы сможем загрузить наш ноутбук с установочного диска с любой операционной системой.
Далее можете войти в меню загрузки ноутбука (обычно нужно жать при включении клавишу ESC или F10) и выбрать вашу (уже подсоединённую) загрузочную флешку с операционной системой или установочный диск, если не знаете как это сделать читайте нашу статью Как загрузить любой ноутбук или компьютер с флешки или диска.
↑ Как отключить опцию Secure Boot на ноутбуке HP
Входим в БИОС UEFI и выбираем опцию «System Configuration», входим в неё и выбираем Boot Options, также заходим в неё.
Видим наш параметр безопасной загрузки Secure Boot, выставляем его в положение Disabled (отключено), а опцию «режима совместимости с другими операционными системами» «Legacy support» переводим в положение «Enabled»,
на предупреждение отвечаем Yes.
Сохраняем настройки, жмём F-10, выбираем Yes и Enter, ноутбук перезагружаемся, после перезагрузки выходит вот такое окно с предупреждением «A change to the operating system secure boot mode is peding…» По «англицки» на предлагают ввести на клавиатуре ноутбука код 8721 (в вашем случае код конечно будет другой) и нажать Enter, после этого изменения в настройках БИОСа UEFI будут сохранены и ноутбук перезагрузится.
↑ Как отключить опцию Secure Boot на ноутбуке Samsung. Aptio Setup Utility
Данная утилита в основном установлена на ноутбуках Samsung. Нажимаем при загрузке ноутбука клавишу F2 и входим в BIOS. Идём в раздел Boot, отключаем опцию «Secure Boot»,
с помощью стрелок на клавиатуре выделяем её и ставим в «Disabled», нажимаем «Enter»
на предупреждение о том, что компьютер может загрузиться с ошибкой жмём Enter.
В этом же разделе ниже появляется параметр «OS Mode Selection», выделяем его и жмём «Enter»
выставляем в положение «CMS OS» или «UEFI and Legacy OS» и нажимаем «Enter».
↑ Как отключить Secure Boot на ноутбуке Acer Aspire
Как отключить опцию Secure Boot на ноутбуке Packard Bell
Жмём при загрузке клавишу F2, реже F6 и попадаем в БИОС UEFI ноутбука,
здесь идём во вкладку Boot.
Если до включения ноутбука Вы подключили к нему флешку, то она может не определиться сразу в этом меню.
Выставляем опцию Boot Mode в положение Legacy BIOS.
А опцию Secure Boot выставляем в положение Disabled.
Далее жмём клавишу F10, этим мы сохраняем настройки внесённые нами в БИОС ноутбука Packard Bell, затем перезагружаемся, жмём при загрузке клавишу F2 и входим опять в БИОС.
↑ Как отключить Secure Boot на стационарном компьютере
На многих стационарных компьютерах установлены современные материнские платы с БИОСом UEFI и протоколом безопасной загрузки Secure Boot. Возьмём для примера материнскую плату ASUS, Asrock, Gigabyte. Нужно сказать, что на материнских платах для стационарных компьютеров функциональные возможности БИОСа UEFI намного расширены, здесь вам и русский язык и возможность пользоваться мышью и производить всевозможные регулировки рабочих параметров комплектующих.
Нажимаем при загрузке Delete или F2 и входим в UEFI BIOS. Нажимаем Дополнительно (F7).
Идём во вкладку Boot (Загрузка), далее выбираем опцию Secure Boot (Безопасная загрузка),
жмём Enter и входим в неё, опять жмём Enter и выбираем Other OS (другая операционная система),
теперь выходим отсюда и выбираем CSM (Compatibility Support Module),
ставим опцию Запуск CSM в Enabled.
В открывшихся дополнительных опциях выбираем Параметры загрузочных устройств и выставляем Только Legacy OpROM или UEFI и Legacy OpROM.
Далее опцию Параметры устройств хранения, выставляем в положение Сначала Legacy OpROM или Both, Legacy OpROM first.
Материнская плата MSI. Подраздел «Boot mode select».
Примечание: На многих ноутбуках невозможно отключить опцию Secure Boot, так как она неактивна, в этом случае может помочь прошивка БИОСа ноутбука последним обновлением.
UEFI с «Secure Boot»: безопасная загрузка ПК
На новых компьютерах Microsoft требует использования UEFI с функцией «Secure Boot». Это усложняет установку других операционных систем.
На новых компьютерах Microsoft требует использования UEFI с функцией «Secure Boot». Это усложняет установку других операционных систем. 
Плата с блоком памяти NVRAm Популярность ОС Windows привела к тому, что к многочисленным проблемам добавилась еще одна: «черви», вирусное ПО и трояны заставляют нас испытывать недюжинный страх за безопасность операционной системы. По утверждению Microsoft, интерфейс UEFI с функцией «Secure Boot» — это попытка вернуть пользователям уверенность в безопасности. Если загрузка ПК осуществляется UEFI в данном режиме, то такие вредоносные программы, как руткиты, оказываются не в состоянии до старта системы проникнуть в оперативную память. Все дело в том, что в режиме «Secure Boot» менеджер загрузки UEFI выполняет только подписанный цифровым ключом код, который он сверяет с зашифрованной базой данных.
Столь решительную систему защиты Microsoft предписывает использовать на всех компьютерах, которые реализуются под логотипом «Certified for Windows 8». Иными словами, все новые ПК, начиная с десктопов и ноутбуков и заканчивая Windows-планшетами, поставляются с активированным режимом «Secure Boot».
Но помимо защиты от руткитов есть одно неприятное обстоятельство — невозможность выполнения кода, не имеющего цифровой подписи. Это противоречит принципу свободной компьютерной платформы и с особым негодованием было воспринято сообществом Linux. Если режим «Secure Boot» активирован, вы не сможете ни установить, ни тем более запустить старые системы, включая Windows XP и 7. Более подробное знакомство с технологией позволит ответить на вопрос «почему?».
Удобство и быстрый запуск благодаря UEFI
Unified Extensible Firmware Interface (унифицированный расширяемый интерфейс прошивки), или кратко UEFI, призван заменить на всех компьютерах уходящий в прошлое интерфейс BIOS, который связывает аппаратные средства с операционной системой и отвечает за запуск ПК. Разработчики UEFI прежде всего преследовали цель устранить некоторые ограничения, присущие традиционной BIOS, которая появилась более 30 лет назад и перестала отвечать современным требованиям.
Отдельные этапы инициализации компонентов платформы в некоторой степени соответствуют BIOS, однако они выполняются намного быстрее. После этапа инициализации запускается менеджер загрузки UEFI. После проверки всех аппаратных компонентов он активирует встроенные в UEFI приложения и драйверы — например, оболочку для ввода команд или функцию поддержки сети. Приложения хранятся либо в NVRAM — запоминающем устройстве UEFI-совместимой материнской платы, либо на жестком диске. На последнем этапе менеджер загрузки UEFI запускает загрузчик ОС, который отвечает за старт операционных систем.
«Secure Boot» проверяет системные компоненты
Именно на этом этапе активируется «Secure Boot» и принимается решение о разрешении или запрете на загрузку операционной системы. Для защиты информации в «Secure Boot» используются три ключа шифрования: в самом верху находится ключ платформы (Platform Key), который создается производителем аппаратного обеспечения. Он требуется для обновления UEFI и загрузки новых ключей KEK (Key Enrollment Key). Согласно стандарту UEFI, ключи KEK должны предоставлять разработчики различных операционных систем, но все это чистая теория. На практике в каждом компьютере содержится лишь KEK от Microsoft для Windows 8, так как сегодня все машины с «Secure Boot» поставляются с данной операционной системой — исключением является только «хромобук» от Google. Ключ KEK занимает центральную позицию в «Secure Boot», так как он открывает доступ к базе данных с разрешенными подписями (Allow DB) и базе данных с запрещенными подписями (Disallow DB). В первой из них содержатся цифровые подписи приложений UEFI, а также подписи и/или хеши компонентов операционной системы — например, менеджера загрузки, ядра и драйверов. Только при их наличии загрузчик ОС запускает систему.
«Secure Boot» в сочетании с поставляемой Windows 8 работает безупречно, но для предыдущих версий операционных систем Microsoft не предоставляет подписей. В данном случае пользователю придется отключать «Secure Boot». Для операционных систем Linux доступны подписанный ключом загрузчик Shim и загрузчик от некоммерческой организации The Linux Foundation.
Справедливости ради стоит отметить, что разработчики Linux не отвергают идею «Secure Boot». Однако они усматривают в ней монополистские притязания Microsoft на аппаратное обеспечение, которые не проявлялись до появления «Secure Boot». С одной стороны, в стандартах по сертификации для Windows 8 компания Microsoft четко указывает, что пользователь имеет возможность отключения «Secure Boot». С другой — может произойти так, что в документации к следующей операционной системе данного примечания просто не окажется.
Последовательность загрузки ПК на основе UEFI Пришедший на смену BIOS интерфейс UEFI активирует аппаратное обеспечение, включая драйверы, и выполняет собственные приложения. Если задействуется режим «Secure Boot», UEFI проверяет наличие у драйверов и программ действительных цифровых подписей. В случае их отсутствия процесс запуска будет прерван. Ту же самую проверку проходят менеджер загрузки и ядра установленных операционных систем.
Активация аппаратных средств
На начальном этапе загрузки UEFI мало чем отличается от традиционной BIOS. После проверки того, подается ли на все аппаратные компоненты напряжение, выполняется запуск компонентов материнской платы, процессора и памяти, а затем загружается код UEFI.
Выполнение кода UEFI
Менеджер загрузки UEFI загружает носитель данных и дополнительный код UEFI из памяти NVRAM, а также из раздела UEFI на жестком диске. При этом драйверы и приложения выполняются только в том случае, если их цифровые подписи соответствуют данным, внесенным в базу Allow DB. В завершение выполняется запуск загрузчика ОС.
Загрузка операционной системы
Загрузчик ОС загружает операционные системы либо напрямую, либо с помощью их менеджеров загрузки. Код загрузки ОС и менеджер загрузки должны обладать действующим сертификатом безопасности, в противном случае процесс будет прерван. То же самое относится и ко всем компонентам ядра, которые в дальнейшем загружаются менеджером загрузки.
Проверка «Secure Boot»
В «Secure Boot» все основные файлы операционной системы (ядро, драйверы) должны обладать цифровой подписью. В таблице сертификатов файла указан подходящий сертификат для «Secure Boot», созданный в соответствии со стандартом X.509, а также снабженные цифровой подписью хеш-значения свойств основных файлов. Они должны соответствовать данным, содержащимся в базе Allow DB.
Windows руководство по созданию и управлению ключами безопасной загрузки
PK – 1. Необходимо использовать RSA 2048 или более надежный.
Microsoft Corporation KEK CA 2011
Разрешает обновления баз данных и dbx:
Microsoft Windows рабочий центр сертификации 2011
Запрещенная база данных сигнатур
Список известных недопустимых ключей, центров сертификации и образов от корпорации Майкрософт
Ключ защищенного обновления встроенного по
Рекомендуется, чтобы этот ключ отличался от PK
Таблица 1. ключи и БД, необходимые для безопасной загрузки
2. решения для управления ключами
Ниже даны некоторые метрики, которые мы использовали для сравнения.
2,1. использованные метрики
Следующие метрики помогут вам выбрать компьютер HSM в соответствии с требованиями Спецификации UEFI 2.3.1 errata C и вашими потребностями.
Связанная инфраструктура открытых ключей (PKI)
Производственная среда
Стандарты и соответствие требованиям
Надежность и аварийное восстановление
Разрешено ли резервное копирование ключей?
Резервные копии можно хранить как в безопасном месте, так и в надежном расположении, отличном от компьютера ЦС, а также HSM и или VSPS в автономном расположении.
Обеспечивает ли он высокий уровень доступности для аварийного восстановления?
2,2. параметры управления ключами
2.2.1 аппаратный модуль безопасности (HSM)
На основе указанных выше критериев это наиболее подходящее и безопасное решение. Большинство HSM имеют соответствие стандарту FIPS 140-2 уровня 3. Соответствие требованиям FIPS 140-2 уровня 3 является требованием к проверке подлинности и требует, чтобы ключи не экспортировались и не импортировались из HSM.
Они поддерживают несколько способов хранения ключей. Они могут храниться локально на самом HSM или на сервере, подключенном к HSM. На сервере ключи шифруются и хранятся и являются предпочтительными для решений, требующих хранения большого количества ключей.
Политика безопасности модуля криптографии должна указывать физическую политику безопасности, включая физические механизмы обеспечения безопасности, реализованные в криптографических модулях, такие как, очевидно, запечатывает, блокировки, ответ на фальсификацию и параметры обнуления, а также сигнализации. Он также позволяет указать действия, требуемые операторами, чтобы обеспечить физическую безопасность, такую как периодическая проверка, очевидно, запечатывает или тестирование реагирования на подделки и параметров обнуления.
2.2.1.1 сетевой HSM
Это решение лучше в своем классе с точки зрения безопасности, соблюдения стандартов, создания ключей, хранения и извлечения. Большинство этих компьютеров поддерживают высокий уровень доступности и возможность резервного копирования ключей.
Стоимость этих продуктов может составлять десятки тысяч долларов в зависимости от дополнительных служб, которые они предлагают.
автономный HSM 2.2.1.2
Они отлично работают с автономными серверами. Можно использовать Microsoft CAPI и CNG или любой другой безопасный API, поддерживаемый HSM. Эти HSM бывают разнообразными конструктивными факторами, поддерживающими шины USB, PCIe и PCMCIA.
При необходимости они поддерживают резервное копирование ключей и высокий уровень доступности.
поставщики пользовательских решений 2.2.2
Шифрование с открытым ключом может быть сложной задачей и требует понимания концепций шифрования, которые могут быть новыми. Существуют пользовательские поставщики решений, которые могут помочь в обеспечении безопасной загрузки для работы в производственной среде.
Существуют разнообразные пользовательские решения, предоставляемые поставщиками BIOS, HSM компаниями и консалтинговые компании PKI для получения безопасной загрузки PKI в производственной среде.
Ниже перечислены некоторые поставщики.
поставщики BIOS 2.2.2.1
Некоторые поставщики BIOS могут предоставлять пользовательские решения.
поставщики HSM 2.2.2.2
Некоторые поставщики HSM могут предоставлять собственные консультации. Дополнительные сведения см. в разделе Создание ключа безопасной загрузки и подписывание с помощью HSM (пример).
доверенный платформенный модуль (TPM) 2.2.3 (TPM)
Доверенный платформенный модуль (TPM) (TPM) — микросхема на материнской плате, в которой хранятся криптографические ключи, используемые для шифрования. Многие компьютеры включают в себя доверенный платформенный модуль, но если компьютер не включает его, его нельзя добавить. После включения доверенный платформенный модуль (TPM) может помочь в обеспечении безопасности полных средств шифрования диска, таких как возможности Microsoft BitLocker. Он сохраняет жесткие диски как заблокированные или запечатанные, пока компьютер не завершит процесс проверки или проверки подлинности.
TPM может создавать, хранить и защищать ключи, используемые в процессе шифрования и расшифровки.
Недостатком доверенных платформенных методов является то, что у него могут не быть быстрые процессоры шифрования для ускорения обработки в производственной среде. Они также не подходят для хранения большого количества ключей. Резервное копирование и высокая доступность и соответствие стандартам требованиям FIPS 140-2 уровня 3 могут быть недоступны.
смарт-карты 2.2.4
Смарт-карта может создавать и хранить ключи. Они совместно используют некоторые функции, которые поддерживают HSM, такие как проверка подлинности и защита от несанкционированного доступа, но не включают много хранилища ключей или резервной копии. Они нуждаются в ручном вмешательстве и могут не подойти для автоматизации и использования в рабочей среде, так как производительность может быть низкой.
Недостатки смарт-карт похожи на доверенные платформенные модули. Они могут не иметь быстрых процессоров шифрования для ускорения обработки в производственной среде. Они также не подходят для хранения большого количества ключей. Резервное копирование и высокая доступность и соответствие стандартам требованиям FIPS 140-2 уровня 3 могут быть недоступны.
Сертификат расширенной проверки 2.2.5
Сертификаты EV — это сертификаты высокой надежности, закрытые ключи которых хранятся в аппаратных маркерах. Это помогает установить более надежные методы управления ключами. Сертификаты EV имеют те же недостатки, что и смарт-карты.
2.2.6 программно-ориентированные подходы (не рекомендуется)
Использование интерфейсов API шифрования для управления ключами. Это может привести к хранению ключа в контейнере ключей на зашифрованном жестком диске и возможности использовать виртуальную машину для дополнительной песочницы и безопасности.
Эти решения не так безопасны, как использование HSM и предоставляют более высокий вектор атак.
2.2.6.1 MakeCert (не рекомендуется)
MakeCert — это средство корпорации Майкрософт, которое можно использовать для создания ключей следующим образом. Чтобы обеспечить минимальную площадь уязвимой зоны, может потребоваться «зазор воздуха» на ПК. ПК с Пкприв не должен быть подключен к сети. Он должен находиться в безопасном месте, и в идеале следует по крайней мере использовать устройство чтения смарт-карт, если это не реальный модуль HSM.
Это решение не рекомендуется.
2,3. Создание и хранение ключ HSM для защищенных загрузочных ключей
2.3.1 хранение закрытых ключей
Требование к пространству для каждого ключа RSA-2048 составляет 2048 бит. Фактическое расположение хранилища ключей зависит от выбранного решения. HSM — это хороший способ хранения ключей.
Физическое расположение компьютеров в фабричном зале должно быть защищенной областью с ограниченным доступом пользователей, как и защищенный корпус.
В зависимости от требований эти ключи также могут храниться в различных географических расположениях или архивироваться в другом расположении.
Требования к переключу для этих ключей могут различаться в зависимости от клиента (см. приложение а для федерального моста рекомендации по использованию ключей для государственных центров сертификации).
Это можно сделать один раз в год. Может потребоваться доступ к этим ключам в течение 30 лет (в зависимости от требований к переключности и т. д.).
2.3.2 получение закрытых ключей
Может потребоваться получить ключи по многим причинам.
Проверка подлинности 2.3.3
В соответствии с проверкой подлинности FIPS 140-2 зависит от уровня доступа.
Уровень 2
Уровень безопасности 2 требует, по крайней мере, проверку подлинности на основе ролей, при которой криптографический модуль проверяет подлинность оператора, чтобы принять конкретную роль и выполнить соответствующий набор служб.
Уровень 3
Уровень безопасности 3 требует использования механизмов проверки подлинности на основе удостоверений, что повышает безопасность, обеспечиваемую механизмами проверки подлинности на основе ролей, указанными для уровня безопасности 2. Модуль шифрования проверяет подлинность удостоверения оператора и проверяет, имеет ли идентифицированный оператор разрешение на получение определенной роли и выполнение соответствующего набора служб.
Компьютеры, например поддержка HSM уровня безопасности 3, для которых требуется удостоверение с проверкой подлинности «k из m». Это означает, что k сущностями предоставляется доступ к HSM с токеном, но в данной точке по крайней мере из токенов m необходимо обеспечить проверку подлинности для получения доступа к закрытым ключам из HSM.
Например, для доступа к HSM необходимо пройти проверку подлинности 3 из 5 токенов. Этими участниками могут быть руководители безопасности, авторизация транзакций и (или) члены из руководства руководителя.
Токены HSM
В HSM может быть политика, требующая наличия маркера:
Настроено для автоматической настройки
Рекомендуется использовать сочетание маркера и пароля для каждого маркера.
2,4 Безопасная загрузка и подписание третьей стороны
Подписывание драйвера UEFI 2.4.1
Драйверы UEFI должны быть подписаны центром сертификации или ключом в базе данных, как описано в любом расположении в документе, или иметь хэш образа драйвера, который входит в базу данных. Майкрософт будет предоставлять службу подписи драйвера UEFI, аналогичную службе подписывания драйвера WHQL, с помощью Microsoft Corporation UEFI CA 2011. Все драйверы, подписанные с помощью этой учетной области, будут работать без проблем на компьютерах, содержащих ЦС Microsoft UEFI. Изготовители оборудования также могут подписывать надежные драйверы и включать ЦС OEM в базу данных или включать хэши драйверов в базу данных. Во всех случаях драйвер UEFI (вариантный ПЗУ) не должен выполняться, если он не является доверенным в базе данных.
Все драйверы, входящие в образ системного встроенного по, не требуют повторной проверки. В состав общего образа системы входит достаточно гарантии того, что драйвер является доверенным для компьютера.
Корпорация Майкрософт стала доступной всем, кто хочет подписать драйверы UEFI. этот сертификат является частью Windows хкк безопасных тестов загрузки. Следуйте указаниям [этот блог] (( https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/ ), чтобы узнать больше о политике подписывания ЦС UEFI и обновлениях.
2.4.2 Boot Loader
Сертификат подписи драйвера UEFI (Майкрософт) можно использовать для подписи других OSs. Например, загрузочный загрузчик Linux Fedora будет подписан.
Для этого решения больше не требуется добавлять сертификаты в базу данных ключей. Кроме экономичности ее можно использовать для любого дистрибутива Linux. это решение работает для любого оборудования, которое поддерживает Windows, поэтому оно полезно для широкого спектра оборудования.
3. Сводка и ресурсы
В этом разделе приводится сводка по приведенным выше разделам и показан пошаговый подход.
Установите безопасный ЦС или определите партнера для безопасного создания и хранения ключей.
Если вы не используете стороннее решение, выполните следующие действия.
Установите и настройте программное обеспечение HSM на HSM Server. Инструкции по установке см. в справочном руководстве по HSM. Сервер будет подключен к изолированному или сетевому HSM-модулю.
Сведения о конфигурации HSM см. в разделе 2.2.1, 2,3 и приложении в.
Большинство HSM предлагают соответствие требованиям FIPS 140-2 уровня 2 и 3. Настройте HSM для соответствия уровня 2 или уровня 3. Соответствие уровня 3 имеет более четкие требования к проверке подлинности и доступу к ключам, поэтому он более безопасен. Рекомендуется уровень 3.
Настройте HSM для обеспечения высокой доступности, резервного копирования и проверки подлинности. Ознакомьтесь со справочным руководством по HSM.
Следуйте рекомендациям поставщика HSM по настройке HSM для обеспечения высокой доступности и резервного копирования.
Кроме того, сетевой HSM обычно имеет несколько сетевых портов для разделения трафика. разрешение серверу обмениваться данными с сетью HSM в сети, отдельной от обычной рабочей сети.
После определения участников команды, которые входят в группу безопасности, и назначенных им токенов. Необходимо настроить аппаратный модуль HSM для проверки подлинности k-of-m.
Защищенные ключи загрузки и предварительное создание сертификатов. См. разделы 1,3 – 1,5.
Используйте API-интерфейсы HSM для предварительного создания (создания перед) ключа и сертификатов обновления микропрограммы и ключей.
Required-PK (рекомендовать 1 для каждой модели), ключ обновления встроенного по (рекомендовать 1 для каждой модели), Microsoft KEK, DB, Дбксноте: Microsoft KEK, DB и dbx не должны создаваться OEM и упомянуты для полноты. Необязательно. OEM/сторонней KEK DB, dbx и другие ключи, которые могли бы попасть в базу данных OEM.
примените к компьютеру образ Windows.
Установите Microsoft DB и dbx. См. раздел 1.3.6 и приложение б — API-интерфейсы безопасной загрузки.
установите Microsoft Windows Production PCA 2011 в базу данных.
Установите пустой dbx, если корпорация Майкрософт не предоставляет его. Windows будет автоматически обновлять dbx до последней версии dbx с помощью Центр обновления Windows при первой перезагрузке.
используйте командлеты PowerShell, которые являются частью Windows хкк тестов или используйте методы, предоставленные поставщиком BIOS.
Установите Microsoft KEK. См. раздел 1.3.3.
Установка Microsoft KEK в базу данных UEFI KEK
используйте командлеты PowerShell, которые являются частью Windows хкк тестов или используйте методы, предоставленные поставщиком BIOS.
Необязательный шаг — компоненты безопасной загрузки OEM/третьей стороны. См. раздел 1.3.4 и 1,4.
Выясните, требуется ли создание OEM-или стороннего производителя KEK, DB и dbx.
Подпишите OEM/сторонней базы данных и dbx с OEM/сторонней KEK (создан ранее) с помощью API HSM.
Установите OEM/стороннего производителя KEK, DB и dbx.
Подписывание драйвера UEFI — см. раздел 2,4.
Если поддерживаются карты расширения или другие драйверы или приложения UEFI и загрузчики, установите Microsoft Corporation UEFI цс 2011 в базу данных UEFI.
Ключ обновления встроенного по безопасной загрузки — см. раздел 1.3.5.
только для компьютеров, отличных от Windows RT: установите открытый ключ обновления безопасного по или его хэш-код, чтобы сэкономить место.
Только в SoC, возможно, потребуется сделать что-то другое, например записать ключ безопасного обновления встроенного по: общедоступный или его хэш.
Установите OEM/ОДМ Пкпуб (предпочтительный сертификат, но ключ — нормально) в UEFI-PK.
Регистрация ПЕРВИЧного ключа с помощью API безопасной загрузки. Теперь компьютер должен быть включен для безопасной загрузки.
Если установить ПЕРВИЧный ПК в конце, то MS KEK, DB, dbx не нужно подписывать — SignerInfo не должно присутствовать. Это ярлык.
тестирование безопасной загрузки: выполнение любых собственных тестов и Windows хкк тесты в соответствии с инструкциями. См. приложение б — API-интерфейсы безопасной загрузки.
Поставка платформы. пкприв, скорее всего, никогда не будет использоваться, обеспечьте безопасность.
Обслуживание: будущие обновления встроенного по надежно подписываются с помощью закрытого ключа «закрытый» обновления встроенного по, использующего службу подписывания.
ресурсы 3,1
Приложение A – контрольный список PKI безопасной загрузки для производства
ниже приведен высокоуровневый контрольный список действий, необходимых для включения безопасной загрузки на компьютерах, не являющихся Windows RT.
Настройка безопасной загрузки
Определите стратегию безопасности (выявление угроз, определение упреждающего и реактивной стратегии) в соответствии с документом в разделе 4.
Выявление группы безопасности согласно техническом документу в разделе 4.
Установите безопасный ЦС или определите партнера (рекомендуемое решение) для безопасного создания и хранения ключей.
Определение политики для того, как часто будут использоваться ключи смены ключей. Это может зависеть от специальных требований клиента, таких как государственные учреждения или другие учреждения.
Наличие плана на непредвиденные случаи в случае компрометации защищенного ключа загрузки.
Определение количества ПЕРВИЧного ключа и других ключей, которые будут создаваться в разделе 1.3.3 и 1,5.
Это будет основано на клиентской базе, решении для хранения ключей и безопасности ПК.
Вы можете пропустить шаги 7-8, если вы используете рекомендованное решение для управления ключами с помощью сторонней компании.
Приобретение сервера и оборудования для управления ключами. — сетевой или автономный HSM в разделе 2.2.1. Определите, потребуется ли вам один или несколько HSM для обеспечения высокой доступности и стратегии резервного копирования ключа.
Выявление по крайней мере 3-4 членов команды, которые будут иметь маркер проверки подлинности для аутентификации в HSM.
Используйте HSM или сторонние компании, чтобы предварительно создать ключи и сертификаты, связанные с безопасной загрузкой. ключи будут зависеть от типа пк: SoC, Windows RT или не Windows RT. Дополнительные сведения см. в разделах с 1,3 по 1,5.
Заполните встроенное по с помощью соответствующих ключей.
Зарегистрируйте ключ платформы безопасной загрузки, чтобы включить безопасную загрузку. Дополнительные сведения см. в приложении б.
Выполните все собственные тесты и ХКК безопасные тесты загрузки в соответствии с инструкциями. Дополнительные сведения см. в приложении б.
Поставляют ПК. Пкприв, скорее всего, никогда не будет использоваться, обеспечьте безопасность.
Обслуживание (обновление встроенного по)
Может потребоваться обновить встроенное по по нескольким причинам, например по обновлению компонента UEFI или исправлению защищенного ключа безопасной загрузки или периодической смены загрузочных ключей.
Дополнительные сведения см. в разделе 1.3.5 и разделе 1.3.6.
Приложение б. API-интерфейсы безопасной загрузки
API безопасной загрузки
Следующие API-интерфейсы связаны с UEFI и безопасной загрузкой:
Жетфирмваринвиронментвариабликс: получает значение указанной переменной среды встроенного по.
Сетфирмваринвиронментвариабликс: задает значение указанной переменной среды встроенного по.
Жетфирмваретипе: получает тип встроенного по.
Настройка PK
Чтобы включить безопасную загрузку, используйте командлет Set-SecureBootUEFI. После того как код установит значение PK, система безопасной загрузки не вступит в силу до следующей перезагрузки. Перед перезагрузкой ваш код мог вызвать Жетфирмваринвиронментвариабликс () или командлет PowerShell: Get-SecureBootUEFI, чтобы подтвердить содержимое баз данных безопасной загрузки.
Проверка
Для проверки состояния переменной безопасной загрузки можно использовать Msinfo32.exe или командлеты PowerShell. Интерфейс WMI отсутствует. вы также можете протестировать, получив неправильно подписанный USB-порт (например, из Windows хкк безопасной загрузки вручную) и убедившись, что он не загружается.
Командлеты PowerShell для безопасной загрузки
Confirm-секуребутуефи: является безопасной загрузкой UEFI «on», true или false?
Сетупмоде = = 0 && безопасной загрузки = = 1
Set-секуребутуефи: Установка или Добавление прошедших проверку подлинности переменных UEFI безопасной загрузки
Get-секуребутуефи: получение значений переменных UEFI безопасной загрузки, прошедших проверку подлинности
Format-секуребутуефи: создает сериализацию EFI_VARIABLE_AUTHENTICATION_2 EFI_SIGNATURE_LISTs
Windows хкк и инструкции по безопасной загрузке
Следующие шаги применимы к системным тестам и тестам ПК, не относящимся к классу драйверов.
Отключите защиту от защищенной загрузки.
Введите конфигурацию BIOS и отключите безопасную загрузку.
Установите клиентское программное обеспечение ХКК.
выполните все Windows тесты хкк, за исключением следующих:
Введите конфигурацию BIOS, включите безопасную загрузку и восстановите безопасную загрузку в конфигурации по умолчанию.
Запустите следующие тесты шифрования BitLocker и безопасной загрузки:
Введите конфигурацию BIOS и очистите конфигурацию безопасной загрузки. КОМПЬЮТЕР восстанавливается в режиме установки путем удаления ключа PK и других ключей.
Для компьютеров x86 и x64 требуется поддержка очистки.
Запустите проверку логотипа безопасной загрузки вручную.
для безопасной загрузки требуются Windows хкк, подписанные или VeriSign-драйверы на компьютерах, не применяющих Windows RT
хкк проверка логотипа безопасной загрузки (автоматизированная) Windows
Этот тест будет проверять правильность устаревшей конфигурации безопасной загрузки. В том числе:
Windows структура папки ручного теста безопасной загрузки хкк
ниже описаны макет папки Windows хкк безопасной загрузки с логотипом.
«\Test» папка имеет следующее:
«\Generate» папка содержит скрипты, которые показывают следующее:
Как создаются тестовые сертификаты
Тестовые сертификаты и закрытые ключи включены
Как были созданы все тесты
Включение сертификатов и хэшей в подписанные пакеты
Вы можете выполнить это самостоятельно, подставив собственные сертификаты.
«\certs» папка содержит все сертификаты, необходимые для загрузки Windows:
«ManualTests\example\OutOfBox» папка содержит сценарии, которые можно использовать для установки безопасной загрузки на рабочих компьютерах.
В этом примере «ManualTests\generate\tests\subcreate_outofbox_example.ps1» показано, как были созданы эти примеры и содержат разделы «TODO», когда партнер может заменить свои ПК и другие метаданные.
подписывание и отправка Windows UEFI хкк
Дополнительные сведения см. по следующим ссылкам:
Приложение C — Федеральный мост сертификата центра сертификации. сопоставления безопасности
Элементарные
Этот уровень обеспечивает наименьшую степень гарантии по идентификатору отдельного пользователя. Одной из основных функций этого уровня является обеспечение целостности данных для подписанных сведений. Этот уровень относится к средам, в которых риск возникновения вредоносных действий считается низким. Он не подходит для транзакций, требующих проверки подлинности, и обычно недостаточен для транзакций, требующих конфиденциальности, но может использоваться для второго, когда сертификаты с более высоким уровнем гарантии недоступны.
Основной
Этот уровень обеспечивает базовый уровень гарантии, относящийся к средам, в которых есть риски и последствия компрометации данных, но они не считаются основными значимыми. Это может быть доступ к конфиденциальным сведениям, когда вероятность вредоносного доступа не высока. Этот уровень безопасности предполагает, что пользователи не являются вредоносными.
Средняя
Этот уровень относится к средам, где умеренные риски и последствия компрометации данных. Это могут быть транзакции с существенным денежным значением или риском мошенничества, а также доступ к конфиденциальной информации, когда вероятность вредоносного доступа существенно существенна.
Высокая
Этот уровень подходит для использования в случаях, когда угрозы для данных имеют высокий приоритет, или последствия сбоя служб безопасности очень высоки. Это может быть очень высокое число транзакций или высокий уровень риска мошенничества.
Связанные темы
Этот документ поможет изготовителям оборудования и Одмс в создании и управлении защищенными ключами и сертификатами в производственной среде. в нем рассматриваются вопросы, связанные с созданием, хранением и получением ключей платформы (первичные ключи), ключами безопасного обновления встроенного по, а также ключами Exchange клавишами сторонних производителей (ключи обмена ключами).
Эти действия не относятся к изготовителям ПК. Предприятия и клиенты также могут использовать эти действия для настройки серверов для поддержки безопасной загрузки.
требования к Windows для UEFI и безопасной загрузки можно найти в Windows требованиях к сертификации оборудования. в этом документе не приводится новых требований или представляется официальная программа Windows. Она предназначена как руководство, не превышающее требования к сертификации, для помощи в создании эффективных и безопасных процессов создания защищенных загрузочных ключей и управления ими. Это важно, поскольку безопасная Загрузка UEFI основана на использовании инфраструктуры открытых ключей для проверки подлинности кода перед выполнением этого действия.
Читатель должен знать основы UEFI, базовое понимание безопасной загрузки (глава 27 Спецификации UEFI) и модель безопасности PKI.
требования, тесты и средства проверка безопасной загрузки на Windows доступны на сегодняшний день в Windowsном наборе сертификации оборудования (хкк). однако эти хкк ресурсы не устраняют возможности создания и управления ключами для Windows развертываний. В этом документе Управление ключами рассматривается как ресурс, помогающий партнерам развернуть ключи, используемые встроенным по. Он не предназначен для указания нормативных руководств и не включает новые требования.
Этот документ служит отправной точкой для разработки компьютеров, готовых для клиентов, средств заводского развертывания и ключевых рекомендаций по безопасности.
1. безопасная загрузка, Windows и управление ключами
Спецификация UEFI (Единый интерфейс EFI) определяет процесс проверки подлинности при выполнении встроенного по, называемый безопасной загрузкой. В качестве отраслевых стандартов безопасная загрузка определяет, как встроенное по платформы управляет сертификатами, проверяет подлинность встроенного по и взаимодействие операционной системы с этим процессом.
Безопасная загрузка основана на процессе инфраструктуры открытых ключей (PKI) для проверки подлинности модулей, прежде чем они будут разрешены для выполнения. К этим модулям могут относиться драйверы встроенного по, дополнительные ПЗУ, драйверы UEFI на диске, приложения UEFI или Загрузчики UEFI. Благодаря проверке подлинности на основе образа перед выполнением безопасная загрузка снижает риск атак с использованием вредоносных программ, таких как rootkit-программы. корпорация майкрософт использует безопасную загрузку UEFI в Windows 8 и более поздних версиях в рамках надежной архитектуры безопасности загрузки для повышения безопасности платформы наших клиентов. безопасная загрузка необходима для Windows 8 и более поздних клиентских пк, а также для Windows Server 2016, как определено в Windows требованиях к совместимости оборудования.
Процесс безопасной загрузки работает следующим образом, как показано на рис. 1.
рис. 1. Windowsная надежная архитектура загрузки
Реализация безопасной загрузки UEFI является частью архитектуры надежной загрузки Майкрософт, представленной в Windows 8.1. Растущий тренд эволюции эксплойтов вредоносных программ нацелен на путь загрузки в качестве предпочтительного направления атаки. Этот класс атак был сложно защитить от, так как Антивредоносные программы могут быть отключены от вредоносных программ, что предотвращает их полную загрузку. благодаря Windowsной надежной архитектуре загрузки и установке корня доверия с безопасной загрузкой, клиент защищается от вредоносного кода, выполняемого в загрузочном пути, гарантируя, что только подписанный, сертифицированный «известный хороший» код и загрузчики запуска могут выполняться до того, как будет загружена сама операционная система.
1,1 Public-Key инфраструктура (PKI) и безопасная загрузка
PKI устанавливает подлинность и доверие в системе. Безопасная загрузка использует PKI для двух высокоуровневых целей:
PKI состоит из следующих компонентов:
1,2. шифрование с открытым ключом
Шифрование с открытым ключом использует пару математически связанных криптографических ключей, известных как открытый и закрытый ключи. Если вы знакомы с одним из ключей, вы не сможете легко вычислить то, что имеет другой. Если для шифрования информации используется один ключ, только соответствующий ключ может расшифровать эту информацию. Для безопасной загрузки закрытый ключ используется для цифрового подписывания кода, а открытый ключ используется для проверки подлинности подписи в коде. Если закрытый ключ скомпрометирован, системы с соответствующими открытыми ключами перестают быть безопасными. Это может привести к атакам комплекта загрузки и повредить репутацию сущности, ответственной за обеспечение безопасности закрытого ключа.
В системе с открытым ключом безопасной загрузки необходимо следующее:
1.2.1 RSA 2048 Encryption
RSA-2048 — это асимметричный криптографический алгоритм. Пространство, необходимое для хранения модуля RSA-2048 в необработанном виде, составляет 2048 бит.
1.2.2 самозаверяющий сертификат
Сертификат, подписанный закрытым ключом, совпадающим с открытым ключом сертификата, называется самозаверяющим сертификатом. Сертификаты корневого центра сертификации (ЦС) попадают в эту категорию.
Центр сертификации 1.2.3
Центр сертификации (ЦС) выдает подписанные сертификаты, подтверждающие подлинность субъекта сертификата, и привязывает этот идентификатор к открытому ключу, содержащемуся в сертификате. ЦС подписывает сертификат с помощью его закрытого ключа. Он выдает соответствующий открытый ключ всем заинтересованным сторонам в самозаверяющего сертификата корневого ЦС.
В случае безопасной загрузки центры сертификации (CAs) включают поставщиков вычислительной техники (или их представителей) и Майкрософт. Центры сертификации создают пары ключей, которые формируют корень доверия, а затем используют закрытые ключи для подписывания допустимых операций, таких как разрешенные модули EFI с ранней загрузкой и запросы на обслуживание встроенного по. Соответствующие открытые ключи поставляются в встроенное по UEFI для защищенных компьютеров с поддержкой загрузки и используются для проверки этих операций.
(Дополнительные сведения об использовании центров сертификации и обмена ключами доступны в Интернете, которые относятся к модели безопасной загрузки.)
1.2.4 Открытый ключ
Ключ общедоступной платформы поставляется на компьютере, доступен или является общедоступным. В этом документе мы будем использовать суффикс «Pub» для обозначения открытого ключа. Например, Пкпуб обозначает открытую половину ПЕРВИЧного ключа.
закрытый ключ 1.2.5
Для работы PKI необходимо обеспечить безопасное управление закрытым ключом. Он должен быть доступен для нескольких доверенных лиц в Организации и расположен в физически надежном месте с ограничениями политики доступа на месте. В этом документе мы будем использовать суффикс Priv для обозначения закрытого ключа. Например, Пкприв указывает на частную половину ПЕРВИЧного ключа.
сертификаты 1.2.6
Использование цифровых сертификатов в основном используется для проверки происхождения подписанных данных, например двоичных файлов и т. д. Обычно сертификаты используются для обеспечения безопасности сообщений в Интернете с помощью протокола TLS или SSL (SSL). Проверка подписанных данных с помощью сертификата позволяет получателю узнать источник данных и, если он был изменен во время передачи.
Цифровой сертификат в целом содержит, на высоком уровне, различающееся имя (DN), Открытый ключ и подпись. DN определяет сущность (например, компанию), которая содержит закрытый ключ, соответствующий открытому ключу сертификата. Подписывание сертификата с помощью закрытого ключа и помещение подписи в сертификат привязывает закрытый ключ к открытому ключу.
Сертификаты могут содержать данные других типов. Например, сертификат X.509 включает формат сертификата, серийный номер сертификата, алгоритм сигнатуры сертификата, имя ЦС, которым был издан сертификат, имя и открытый ключ сущности, запрашивающей сертификат, а также сигнатура центра сертификации.
1.2.7 цепочки сертификатов
Рис. 2. цепочка из трех сертификатов
Сертификаты пользователей часто подписываются с помощью другого закрытого ключа, такого как закрытый ключ ЦС. Это образует цепочку из двух сертификатов. Проверка того, что сертификат пользователя является подлинным, подразумевает проверку его подписи, которая требует наличия открытого ключа ЦС из сертификата. Но прежде чем можно будет использовать открытый ключ ЦС, необходимо проверить сертификат, включающий ЦС. Так как сертификат ЦС является самозаверяющим, для проверки сертификата используется открытый ключ ЦС.
Сертификат пользователя не должен быть подписан закрытым ключом корневого ЦС. Он может быть подписан закрытым ключом посредника, сертификат которого подписан закрытым ключом ЦС. Это экземпляр цепочки из трех сертификатов: сертификат пользователя, промежуточный сертификат и сертификат ЦС. Но несколько посредников могут быть частью цепочки, поэтому цепочки сертификатов могут иметь любую длину.
1,3. требования для безопасной загрузки PKI
Корень доверия, определяемый UEFI, состоит из ключа платформы и любых ключей, которые OEM или ОДМ включают в ядро встроенного по. Безопасность до UEFI и корень доверия не решаются процессом безопасной загрузки UEFI, а не с помощью национального института стандартов и технологий (NIST) и организация TCG (TCG) публикаций, упоминаемых в этом документе.
требования к безопасной загрузке 1.3.1
Для реализации безопасной загрузки необходимо учитывать следующие параметры.
Вам потребуется выбрать оборудование для безопасного управления ключами загрузки, таких как аппаратные модули безопасности (HSM), рассмотрите специальные требования на компьютерах для доставки в государственные учреждения и другие учреждения и, наконец, процесс создания, заполнения и управления жизненным циклом различных защищенных загрузочных ключей.
1.3.2 ключи, связанные с безопасной загрузкой
Ниже приведены ключи, используемые для безопасной загрузки.
Рис. 3. ключи, связанные с безопасной загрузкой
На рис. 3 выше представлена подпись и ключи компьютера с безопасной загрузкой. Платформа защищена с помощью ключа платформы, который изготовитель оборудования устанавливает в микропрограмму во время производства. Другие ключи используются безопасной загрузкой для защиты доступа к базам данных, в которых хранятся ключи, разрешающие или запрещающие выполнение встроенного по.
Авторизация базы данных (DB) содержит открытые ключи и сертификаты, представляющие доверенные компоненты встроенного по и загрузчики операционной системы. База данных запрещенных подписей (DBX) содержит хэши вредоносных и уязвимых компонентов, а также скомпрометированные ключи и сертификаты и блокирует выполнение этих вредоносных компонентов. Сила этих политик основана на встроенном по для подписывания с помощью Authenticode и инфраструктуры открытых ключей (PKI). PKI — это хорошо установленный процесс создания, управления и отзыва сертификатов, устанавливающих отношения доверия во время обмена информацией. Инфраструктура PKI является основой модели безопасности для безопасной загрузки.
Ниже приведены дополнительные сведения об этих ключах.
Ключ платформы 1.3.3 (PK)
В соответствии с разделом 27.5.1 для UEFI 2.3.1 об ошибках C, ключ платформы устанавливает отношение доверия между владельцем платформы и встроенным по платформы. Владелец платформы регистрирует открытую половину ключа (Пкпуб) в микропрограмме платформы, как указано в разделе 7.2.1 of the UEFI 2.3.1 errata C. Этот шаг перемещает платформу в пользовательский режим из режима установки. Корпорация Майкрософт рекомендует, чтобы ключ платформы был типа EFI_CERT_X509_GUID с алгоритмом открытого ключа RSA, длиной открытого ключа 2048 бит и алгоритмом подписи sha256RSA. Владелец платформы может использовать тип, EFI_CERT_RSA2048_GUID Если дисковое пространство является важным. Открытые ключи используются для проверки подписей, как описано выше в этом документе. Владелец платформы может позже использовать частную половину ключа (Пкприв):
1.3.3.1 для регистрации или обновления ключа Exchange ключей (KEK) при регистрации ключа платформы
1.3.3.2 Очистка ключа платформы
Владелец платформы очищает общедоступную половину ключа платформы (пкпуб), вызывая интерфейс UEFI Boot SER все, SetVariable () с переменным размером 0 и сбросом платформы. Если платформа находится в режиме установки, то проверка подлинности пустой переменной не требуется. Если платформа находится в пользовательском режиме, то пустая переменная должна быть подписана текущим пкприв; Дополнительные сведения см. в разделе 7.2 (службы переменных) в Спецификации UEFI 2.3.1 errata C. Настоятельно рекомендуется, чтобы Рабочая Пкприв никогда не использовалась для подписывания пакета для сброса платформы, так как это позволяет программно отключить безопасную загрузку. Это, в первую очередь, сценарий подготовительного тестирования.
Ключ платформы также можно очистить с помощью безопасного метода для конкретной платформы. В этом случае необходимо также обновить режим установки глобальных переменных до 1.
Рис. 4. Схема состояния ключа платформы
Создание ПЕРВИЧного ключа 1.3.3.3
По мере получения рекомендаций по UEFI открытый ключ должен храниться в энергонезависимом хранилище, что является несанкционированным и удаляет устойчивость компьютера. закрытые ключи остаются надежными на уровне партнера или в Office безопасности OEM, и на платформу загружается только открытый ключ. Дополнительные сведения см. в разделе 2.2.1 и 2,3.
Число созданных ПЕРВИЧных процессоров определяется по усмотрению владельца платформы (OEM). Эти ключи могут быть следующими:
По одному на ПК. Наличие одного уникального ключа для каждого устройства. Это может потребоваться для государственных учреждений, финансовых учреждений или других клиентов сервера с высокими требованиями к безопасности. Для создания закрытых и открытых ключей для большого количества компьютеров может потребоваться дополнительное хранилище и вычислительная мощность для обработки шифрования. Это усложняет сопоставление устройств с соответствующим ключом ПК при отправке обновлений встроенного по на устройства в будущем. Существует несколько различных решений HSM, доступных для управления большим количеством ключей на основе поставщика HSM. Дополнительные сведения см. в статье Создание безопасного загрузочного ключа с помощью HSM.
По одному на модель. Наличие одного ключа на модель ПК. Компромисс заключается в том, что если ключ скомпрометирован, все компьютеры в одной модели будут уязвимы. Это рекомендовано корпорацией Майкрософт для настольных компьютеров.
По одному на строку продукта. Если ключ скомпрометирован, вся линия продукта будет уязвимой.
Один на OEM. Хотя это и может быть самым простым настройкой, если ключ скомпрометирован, все производимые ПК будут уязвимы. Для ускорения операции в цехе фабрики PK и потенциально другие ключи можно создать заранее и сохранить в безопасном месте. Впоследствии их можно будет извлечь и использовать в строке сборки. В главах 2 и 3 содержатся дополнительные сведения.
1.3.3.4 переключить PK
Это может потребоваться, если ПК скомпрометирован или является требованием клиента, который по соображениям безопасности может принять решение о регистрации собственного ПЕРВИЧного ключа.
Возможность смены ключей может быть выполнена для модели или ПК в зависимости от того, какой метод был выбран для создания ПЕРВИЧного ключа. Все новые компьютеры будут подписаны с использованием только что созданного ПЕРВИЧного ключа.
Для обновления ПЕРВИЧного ПК на рабочем компьютере потребуется либо обновление переменной, подписанное существующим ПЕРВИЧным процессором, заменяющее PK, либо пакет обновления встроенного по. Изготовитель оборудования также может создать пакет SetVariable () и распространить его с помощью простого приложения, такого как PowerShell, которое просто изменяет ПЕРВИЧный ключ. Пакет обновления встроенного по будет подписан с помощью ключа обновления безопасного встроенного по и проверено встроенным по. При обновлении встроенного по для обновления ПЕРВИЧного ключа следует соблюдать осторожность, чтобы убедиться, что KEK, DB и dbx сохранены.
На всех компьютерах рекомендуется не использовать PK в качестве ключа обновления безопасного встроенного по. Если Пкприв скомпрометирован, то это ключ обновления защищенного встроенного по (так как они одинаковы). В этом случае обновление для регистрации нового Пкпуб может оказаться невозможным, так как процесс обновления также был скомпрометирован.
На SoC ПК есть еще одна причина, по которой не следует использовать PK в качестве ключа обновления безопасного встроенного по. это связано с тем, что защищенный ключ обновления встроенного по постоянно бурнт в плавкие предохранители на компьютерах, соответствующих требованиям сертификации оборудования Windows.
ключи обмена ключами ключа Exchange 1.3.4 key (KEK) устанавливают отношения доверия между операционной системой и встроенным по платформы. Каждая операционная система (и потенциально, каждое стороннее приложение, которое должно взаимодействовать с встроенным по платформы) регистрирует открытый ключ (кекпуб) в встроенном по платформы.
1.3.4.1 ключей регистрации ключей Exchange
Ключи обмена ключами хранятся в базе данных сигнатур, как описано в статье базы данных сигнатуры 1,4 (DB и DBX)). База данных сигнатур хранится в виде переменной UEFI, прошедшей проверку подлинности.
Если платформа находится в режиме установки, переменная базы данных сигнатур не должна быть подписана, но параметры вызова SetVariable () по-прежнему должны быть подготовлены согласно указаниям для прошедших проверку подлинности переменных в разделе 7.2.1. Если платформа находится в пользовательском режиме, база данных подписей должна быть подписана с использованием текущего Пкприв
1.3.4.2 очистки KEK
Можно «очистить» (удалить) KEK. Обратите внимание, что если ПК не установлен на платформе, запросы со снятыми флажками не обязательно должны быть подписаны. Если они подписаны, то для очистки KEK требуется пакет, подписанный ПК, а для очистки базы данных или dbx требуется пакет, подписанный любой сущностью, присутствующей в KEK.
1.3.4.3 Microsoft KEK
Microsoft KEK требуется для включения отзыва плохих образов путем обновления dbx и, возможно, для обновления базы данных, чтобы подготовиться к новым Windows подписанным образам.
Включите Microsoft Corporation KEK CA 2011 в базу данных KEK со следующими значениями:
1.3.4.4 кекдефаулт поставщик платформы может предоставить набор ключевых Exchange ключей по умолчанию в переменной кекдефаулт. Дополнительные сведения см. в разделе о Спецификации UEFI 27.3.3.
1.3.4.5 OEM/стороннего производителя KEK — Добавление нескольких KEK
Клиентам и владельцам платформ не обязательно иметь свои собственные KEK. на компьютерах, не являющихся Windows RT, поставщик вычислительной техники может иметь дополнительные ключи обмена ключами, чтобы разрешить дополнительный поставщик вычислительной техники или доверенный сторонний элемент управления для баз данных и dbx.
ключ обновления встроенного по безопасной загрузки 1.3.5 Ключ безопасного обновления встроенного по используется для подписывания встроенного по, когда необходимо его обновить. Этот ключ должен иметь минимальную стойкость ключа RSA-2048. Все обновления встроенного по должны быть надежно подписаны поставщиком вычислительной техники, доверенным представителем, таким как ОДМ или ИБВ (независимый поставщик BIOS) или безопасной службой подписывания.
По мере обновления встроенного по в соответствии с заданной публикацией NIST 800-147 должен поддерживать все элементы руководства.
Любое обновление в флэш-магазине встроенного по должно быть подписано автором.
Встроенное по должно проверять подпись обновления.
1.3.6 создание ключей для безопасного обновления встроенного по
Один и тот же ключ будет использоваться для подписи всех обновлений встроенного по, так как общедоступная половина будет размещена на компьютере. Вы также можете подписать обновление встроенного по с помощью ключа, который цепочка позволяет защитить ключ обновления встроенного по.
На каждый компьютер может быть один ключ, например PK или один для каждой модели, или одна для каждой линейки продуктов. Если имеется один ключ на каждый компьютер, то это означает, что потребуется создать миллионы уникальных пакетов обновления. Подумайте о доступности ресурсов, которые будет использовать метод. Наличие ключа для каждой модели или линейки продуктов — хороший компромисс.
Открытый ключ безопасного обновления встроенного по (или его хэш-код для экономии места) будет храниться в защищенном хранилище на платформе (в общем случае это защищенное устройство флэш-памяти (PC) или одноразовый программируемый предохранитель (SOC)).
Если сохранен только хэш этого ключа (для экономии пространства), то обновление встроенного по будет включать ключ, а первый этап процесса обновления будет проверять, соответствует ли открытый ключ в обновлении хэшу, сохраненному на платформе.
Капсулы — это средство, с помощью которого операционная система может передавать данные в среду UEFI во время перезагрузки. Windows вызывает UEFI упдатекапсуле () для доставки обновлений встроенного по системы и пк. во время загрузки до вызова екситбутсервицес () Windows передает все новые обновления встроенного по, обнаруженные в хранилище драйверов Windows, в упдатекапсуле (). Встроенное по UEFI может использовать этот процесс для обновления встроенного по системы и ПК. используя эту Windows поддержки встроенного по, изготовитель оборудования может использовать один и тот же общий формат и процесс обновления встроенного по для системы и пк. Чтобы обеспечить поддержку UEFI Упдатекапсуле () для Windows, встроенное по должно реализовывать таблицу ACPI ЕСРТ.
дополнительные сведения о реализации поддержки для платформы обновления встроенного по Windows uefi см. в следующей документации: Windows платформа обновления встроенного по uefi.
Обновленные капсулы могут находиться в памяти или на диске. Windows поддерживает обновления памяти.
1.3.6.1 капсула (капсула-в памяти)
Ниже приведена последовательность событий для работы с обновленной капсулой в памяти.
Рабочий процесс 1.3.7 типичного обновления встроенного по
Базы данных сигнатур 1,4 (DB и DBX)
1.4.1 допустимая база данных сигнатур (DB)
Содержимое _IMAGE_SECURITY_DATABASE элемента управления «база данных EFI», какие образы являются доверенными при проверке загруженных образов. База данных может содержать несколько сертификатов, ключей и хэшей для обнаружения разрешенных образов.
на компьютерах, не являющихся Windows RTными, изготовитель оборудования может также иметь дополнительные элементы в базе данных, чтобы разрешить другим операционным системам или драйверам UEFI, утвержденным изготовителем оборудования или приложениям, но эти образы не должны нарушать безопасность компьютера каким-либо образом.
1.4.2 дбдефаулт. поставщик платформы может предоставить набор записей по умолчанию для базы данных сигнатур в переменной дбдефаулт. Дополнительные сведения см. в разделе 27.5.3 в спецификации UEFI.
1.4.3 запрещенная база данных сигнатур (DBX)
1.4.4 дбксдефаулт. поставщик платформы может предоставить набор записей по умолчанию для базы данных сигнатур в переменной дбксдефаулт. Дополнительные сведения см. в разделе 27.5.3 в спецификации UEFI.
