Есть ли альтернатива безопасной загрузке UEFI с открытым исходным кодом? [закрыто]

0
09.06.2017, 18:37
3 ответа

Ближайшей альтернативой UEFI является coreboot .

1
28.01.2020, 02:33

На самом деле это не прямая альтернатива и может быть не совсем то, что вы ищете, но похожее решение, для которого требуется TPM (Trusted Platform Module ), называется «Trusted Boot» или tboot. Он отличается некоторыми ключевыми моментами, но его конечная цель одна и та же -— установить уровень доверия к цепочке загрузки и состоянию вашей системы.

Tboot на самом деле является реализацией с открытым исходным кодом концепции, называемой MLE или измеряемой средой запуска. В двух словах, это блок двоичного кода, который выполняет и использует Intel TXT для перевода машины в привилегированное и доверенное состояние, где она затем может выполнять измерения хэшей (SHA -1 в TPM 1.2 )ОС и связанные компоненты, а также отправить их в доверенный платформенный модуль для безопасного хранения. Например, в Linux tboot можно настроить на выполнение непосредственно перед загрузкой ядра, и он будет генерировать хэши двоичного файла ядра, параметров ядра и образа initramfs и отправлять их в TPM.

Кроме того, модуль TPM и совместимая материнская плата/BIOS позволяют проводить измерения различных компонентов вашей системы намного раньше в процессе загрузки, таких как сам образ BIOS, пользовательские настройки BIOS, прошивка карты PCI. (Графический процессор, NIC и др. ), загрузчик (grub, например )и др. Вам может быть интересно, что хорошего в этих измерениях? Ну, не так уж и сами по себе. Вместо этого доверенный платформенный модуль можно использовать для выполнения ряда действий тогда и только тогда, когда эти измерения представляют собой определенное значение, например чтение/запись в NVRAM доверенного платформенного модуля или расшифровку ключа, который может расшифровать только доверенный платформенный модуль. Эти измерения также могут быть переданы безопасно (и анонимно, при желании )другой стороне, так что эта сторона может установить доверие удаленно. Следовательно, система может быть спроектирована таким образом, чтобы загружать или выполнять некоторое программное обеспечение только в том случае, если TPM имеет некоторые определенные измерения в своих PCR, что означает загрузку определенного набора программного обеспечения -, т. е. обеспечивает целостность.

По сути, сочетание TPM и tboot обеспечивает широкий спектр охвата системы, и, по крайней мере, на бумаге, насколько я понимаю, может быть расширено для измерения/хэширования практически всего, что вы хотите, с помощью API для отправки хэшей в TPM для хранения. Важно отметить, что хэши не просто загружаются в TPM. Вместо этого, когда хэш должен быть сохранен во внутреннем регистре в TPM (PCR или регистре конфигурации платформы ), он объединяется с предыдущим значением регистра, а большой двоичный объект хешируется, а результат сохраняется в реестр. В результате каждый регистр накапливает состояние, и любая разница в пути приводит к изменению конечного значения. Это называется расширением tpm.

По сути, я думаю, что TPM и tboot предлагают гораздо больше возможностей, чем безопасная загрузка. TPM — это своего рода криптографический сопроцессор общего назначения, который можно использовать для безопасного хранения, RNG, отчетов о состоянии системы для других хостов (, аттестации )и многого другого.

В отличие от безопасной загрузки, которая использует подписи и останавливает процесс загрузки, если подпись не проверена, TPM/tboot не использует подписи и не останавливает последовательность загрузки напрямую. Скорее, система должна быть спроектирована таким образом, чтобы не загружаться при сбое, требуя от TPM выполнения некоторых действий, которые он будет выполнять только в том случае, если система находится в определенном состоянии, если это необходимо.

Что касается вашего беспокойства по поводу открытого -исходного кода и прозрачности всего этого, то даже tboot/TPM проникает в слой неявного доверия, и на самом деле, на мой взгляд, это неизбежный прыжок веры, если только буквально каждый фрагмент Программное обеспечение было с открытым исходным кодом, а аппаратное обеспечение и аппаратные схемы были понятны. В случае tboot и TPM это неявное доверие распространяется на набор микросхем и сам процессор. Предположительно контрольная сумма открытого ключа встроена в чипсет, который используется микрокодом процессора для запуска цепочки доверия.Эта контрольная сумма не объясняется полностью в текстах, которыми я владею, но объясняется, что подпись проверяется микрокодом процессора в блоке кода, находящемся в образе BIOS, который называется BIOS ACM для SRTM или SINIT ACM для DRTM. Конечно, для проверки подписи необходимо использовать открытый ключ, и я предполагаю, что открытый ключ встроен в ACM из соображений экономии места и проверяется по упомянутой ранее аппаратной резидентной контрольной сумме.

0
28.01.2020, 02:33

На самом деле часть, которая проверяет подписи безопасной загрузки , открыта. Это часть Intel TianoCore. Проблема в том, что когда вы покупаете -полочное оборудование -, нет возможности проверить, что на самом деле поставил производитель оборудования. Но это общая проблема с прошивкой ПК, а не с безопасной загрузкой как таковой.

Системная -сторона безопасной загрузки в самих операционных системах с открытым исходным кодом -, например Linux или FreeBSD -, также является полностью открытым исходным кодом.

У Secure Boot есть свои проблемы -схема подписи просто ужасна -но "недостаточная открытость" не является одной из них.

1
28.01.2020, 02:33

Теги

Похожие вопросы