Вопрос или проблема
Я только что закончил настраивать безопасную загрузку на установке Arch. В отличие от других дистрибутивов, это не работает из коробки. Тем не менее, процесс создания собственных ключей и автоматической подписи каждого обновления ядра с их помощью с помощью sbctl и хука pacman относительно прост.
У меня, однако, есть проблема с этим подходом: если я должен хранить свои ключи на своем компьютере и могу использовать их для подписи всего с учетными данными, доступными инструмента, который я могу вызвать в пользовательском пространстве… Как это защищает мою систему?
Мне было бы гораздо удобнее и безопаснее, если бы эти вещи уже были подписаны поддерживающими Arch. Я мог бы просто добавить их ключ в свою базу данных безопасной загрузки, разрешив его в настройках BIOS единожды. Но я не нахожу способа сделать это. Почему все методы настройки, которые я вижу в интернете, так запутаны, когда это решение кажется таким очевидным и простым? Существует ли какая-то техническая, идеологическая или процедурная причина, которую я упускаю?
Почему поддерживающие Arch не подписывают свои ядра/загрузчики?
Основная причина в том, что в настоящее время у них нет подходящей инфраструктуры для хранения и доступа к signing ключу.
В отличие от других дистрибутивов, пакеты Arch в настоящее время не собираются на центральной “ферме сборки” – сборка осуществляется вручную, либо на собственных компьютерах разработчиков, либо передается на обычный сервер сборки через SSH. Пакеты затем подписываются с помощью собственного ключа PGP разработчика (и поставляются с этой подписью, а не пересSigned).
(Образы .iso собираются аналогичным образом – обратите внимание, что они подписаны PGP-ключом человека, а не общим ключом “Debian buildd”, и когда этот человек недоступен, весь процесс иногда задерживается.)
До сих пор это удовлетворяло потребности в подписи пакетов, потому что pacman имеет процедуру для отзыва ключей (ключи разработчиков могут быть удалены, сохраняя те же CA), а также модель доверия “M из N”, характерную для PGP. Однако отображение этой модели 1:1 на подпись Secure Boot (предполагая, что вы хотите только внутреннюю подпись “Arch CA”) больше не позволит автоматически отзывать сертификаты, так как единственные ‘dbx’ обновления, которые могут быть установлены автоматически, подписаны Microsoft (потому что только Microsoft находится в вашем списке ‘KEK’, и нет никаких гарантий, что прошивка вашего устройства позволит вам зарегистрировать собственный KEK без полного выполнения вашей собственной подписи Secure Boot с самого PK).
Это также не соответствует требованиям для “полной” безопасной загрузки (как это делают другие дистрибутивы), так как ядро должно быть подписано единственным ключом, который должен быть встроен в сборку ‘Shim’ загрузчика, подписанную Microsoft. Чтобы избежать риска утечки ключей (и отзыва/пересборки/повторной подписи Shim), необходима какая-то централизованная инфраструктура сборки, которая все еще находится в процессе формирования, и, в идеале, какой-то безопасный способ хранения ключей (TPM или смарт-карта или Nitrokey или аналогичный HSM), который не позволит вытащить ключ, что требует договоренностей с хостинг-компанией (Arch не имеет собственных дата-центров).
Если я должен хранить свои ключи на своем компьютере и могу использовать их для подписи всего с учётными данными, доступными инструменту, который я могу вызвать в пользовательском пространстве…
Это такая же ситуация, как, например, в Ubuntu, который тоже заставляет вас хранить ключ на вашем компьютере – MOK (ключ владельца машины) – который можно использовать для подписи любого модуля ядра, как легитимного (пакеты DKMS), так и нет.
(Насколько я помню, он также поставляется с программой EFI, которая позволяет кому-то с физическим доступом зарегистрировать любой MOK, который они хотят, хотя большинство прошивок все равно это позволяет для безопасной загрузки.)
Как это защищает мою систему?
Безопасная загрузка сама по себе не сильно защищает вашу систему (если вообще защищает), в первую очередь – особенно учитывая, что она даже не проверяет изображение initrd (действительно, если не используется процесс локальной подписи ‘UKI’). 90% ее полезности исходит от использования в сочетании с шифрованием системного диска (что также означает, что ваши ключи подписи тоже будут зашифрованы).
Действительно, в большинстве дистрибутивов Linux защищенная цепочка останавливается на ядре и его модулях и ничего не делает, чтобы предотвратить внешние подделки даже самых критически важных файлов пользовательского пространства – только тот факт, что диск зашифрован, в основном предотвращает это.
Чтобы быть наиболее полезной, безопасная загрузка должна сочетаться с измеренной загрузкой – например, когда ключи шифрования диска запечатываются с использованием TPM и привязываются к конкретному состоянию системы. Вот что делает BitLocker; его автоматическая разблокировка не хочет “пароль безопасной загрузки”, она хочет “безопасная загрузка говорит, что ядро Windows было подписано именно этим сертификатом Microsoft”, т.е. это становится одним из ингредиентов в общей аттестации состояния системы.
(Системы DRM и античит также используют SB TPM измерения без шифрования диска.)
Есть некоторые параллели с тем, как работают TLS и SSH: сначала ключи шифрования обмениваются неаутентифицированным образом (DH), и только потом используется закрытый ключ сервера для привязки сертификата и транскрипта предыдущего процесса; это означает, что DH является критической частью протокола, но будет почти бесполезным само по себе.
Ответ или решение
Почему разработчики Arch не подписывают свои ядра/загрузчики?
Основная причина заключается в том, что в настоящее время у них нет подходящей инфраструктуры для хранения и доступа к ключу подписи. В отличие от других дистрибутивов, пакеты Arch не создаются на централизованной «ферме сборок» — сборка выполняется вручную, либо на собственных машин разработчиков, либо на обычном сервере сборки через SSH. Пакеты затем подписываются с использованием собственного PGP-ключа разработчика, и эта подпись доставляется вместе с пакетом, а не повторно подписывается.
Процесс создания образов .iso выполняется аналогичным образом. Обратите внимание, что они подписываются ключом конкретного человека, а не ключом «сборщика Debian», и когда этот человек недоступен, весь процесс иногда задерживается. На данный момент это полностью удовлетворяет требованиям подписки пакетов, поскольку Pacman имеет процедуру отзыва ключей (ключи разработчиков могут быть удалены, при этом сохраняя те же корневые центры сертификации), а также модель доверия «M из N», которая является родной для PGP. Однако применение этой модели для полноценной подписи Secure Boot (предполагая, что вы хотите только внутреннюю подпись «CA Arch») больше не позволит выполнять автоматическое отзыва сертификатов, поскольку единственные обновления ‘dbx’, которые могут быть установлены автоматически, подписаны Microsoft (потому что только Microsoft находится в вашем списке ‘KEK’, и нет гарантии, что прошивка вашего устройства позволит вам зарегистрировать собственный KEK без полной настройки подписи Secure Boot).
Кроме того, это не соответствует требованиям для полноценного Secure Boot (так, как это делают другие дистрибутивы), поскольку ядро должно быть подписано единым ключом, который необходимо встроить в сборку загрузчика ‘Shim’, подписанную Microsoft. Для снижения риска утечки ключей (и аннулирования/переподписывания Shim) требуется какая-то центральная инфраструктура сборки, которая всё еще находится в процессе создания, а также, ideally, какое-то безопасное хранилище ключей (TPM, смарт-карта или Nitrokey или аналогичный HSM), что требует договоренностей с хостинговой компанией (Arch не имеет собственных дата-центров).
Что касается хранения ваших ключей на вашем устройстве, это аналогично тому, как это реализовано в Ubuntu, где вам также нужно хранить ключ на своем устройстве — MOK (Machine Owner Key), который может быть использован для подписывания любого модуля ядра, как легитимного (пакеты DKMS), так и нет.
Таким образом, это не гарантирует значительной защиты системы. Secure Boot сам по себе сильно не защищает вашу систему, особенно учитывая, что он не проверяет образ initrd (действительно, если только не используется процесс локальной подписи ‘UKI’). 90% его полезности приходит от его использования в сочетании с шифрованием системного диска (что также означает, что ваши ключи подписи будут также зашифрованы).
Наиболее полезным Secure Boot становится, когда он комбинируется с «измеренной» загрузкой, например, когда ключи шифрования диска защищены с помощью TPM и связаны с конкретным состоянием системы. Таким образом, Secure Boot становится важным ингредиентом в актуальной аттестации состояния системы, где упоминаемые вами процессы, как TLS и SSH, требуют взаимодействия, где вначале обмен ключами происходит неаутентифицированным образом, а затем использует частный ключ сервера для связывания сертификата и сформированной ранее транскрипции.
В свете вышеизложенного, понимание о том, почему Arch не предоставляет автоматическую подпись для систем, может помочь в формировании адекватных ожиданий и шагов по обеспечению безопасности вашей установки.