Secure Boot

Secure Boot (з англ. — «безпечне завантаження») — протокол, що є частиною специфікації UEFI[1]. Полягає в перевірці електронного цифрового підпису виконуваних EFI-застосунків, з використанням асиметричної криптографії щодо ключів, які зберігаються в системному сховищі ключів.

Історія

2011 року Microsoft включила у вимоги для сертифікації комп'ютерів під керуванням Windows 8 умову постачання таких систем із увімкненим Secure Boot з використанням ключа Microsoft. Більш того, для ARM-систем (смартфони та деякі ноутбуки) вимагалася неможливість відключення Secure Boot. Це викликало суспільний резонанс і критику в бік Microsoft, оскільки такі вимоги значно ускладнювали, а в разі ARM-систем унеможливлювали встановлення операційних систем, відмінних від Microsoft Windows[2][3][4].

Опис

Автентифіковані змінні

Автентифіковані змінні (Authenticated Variable) — змінні, для змінення яких потрібна автентифікація. Secure Boot передбачає зберігання публічних ключів, підписів та гешів застосунків у автентифікованих змінних, що зберігаються в незалежній пам'яті. Такі змінні можна перезаписати двома способами[5][6][7]:

• нові значення мають бути підписані відомим ключем;
• якщо система перебуває в режимі налаштування або аудиту, то в ці змінні можна записувати непідписані значення.

Використовувані змінні

• Platform Key (PK) — публічний ключ власника платформи. Підписи відповідним приватним ключем необхідні для змінення PK, KEK, db і dbx (описано далі). Сховище PK має бути захищеним від втручання та видалення[8].
• Key Exchange Key (KEK) — публічні ключі операційних систем (ОС). Підписи відповідними приватними ключами необхідні змінення баз даних підписів (db, dbx, описано далі). Сховище KEK має бути захищеним від втручання[8].
• Бази даних підписів (db, dbx) — бази даних підписів та гешів довірених застосунків (db) та недовірених застосунків (dbx).
• Machine Owner Key (MOK) — реалізація ключа Secure Boot специфічна для ОС сімейства Linux. Багато варіантів Linux підтримують Secure Boot, але він створює проблеми при використанні нестандартних ядер ОС і модулів. Для обходу цієї проблеми розроблено концепт МОК. МОК може використовуватися з підписаним завантажувачем Shim для забезпечення керування ключами на рівні користувач/системний адміністратор.

Режими роботи

Setup Mode (режим налаштування)

Перехід у цей режим можливий із режиму користування очищенням PK.

У цьому режимі для запису PK, KEK, db, dbx не потрібно автентифікації.

Запис PK переводить систему в режим користування. Запис одиниці в спеціальну змінну AuditMode (доступна для запису тільки в режимах налаштування та користування) переводить систему в режим аудиту.

Audit Mode (режим аудиту)

Перехід у цей режим можливий з режиму налаштування або режиму користування записом одиниці в змінну AuditMode. При зміненні режиму на режим аудиту очищається PK.

У цьому режимі не потрібно автентифікації для запису PK, KEK, db, dbx. У режимі аудиту можна запускати образи, що не пройшли перевірки, а інформація про всі етапи валідації образів буде записана в спеціальну таблицю, доступну з операційної системи, що дозволяє випробовувати комбінації збережених ключів і підписів, не побоюючись втратити працездатність системи[9].

Запис PK переводить систему в розгорнутий режим.

User Mode (режим користування)

Перехід у цей режим можливий із режиму налаштування записом PK, або з розгорнутого режиму платформозалежним методом (не обумовлено специфікацією).

У цьому режимі для змінення ключових сховищ потрібна автентифікація, а також виконується валідація образів, що запускаються.

Видалення PK переводить систему в режим налаштування. Запис одиниці в змінну AuditMode переводить систему в режим аудиту. Запис одиниці в змінну DeployedMode (доступну для запису тільки в режимі користувача) переводить систему в розгорнутий режим.

Deployed Mode (розгорнутий режим)

Перехід у цей режим можливий із режиму аудиту записом PK, або з режиму користування записом одиниці в змінну DeployedMode.

Найбезпечніший режим[9]. Відрізняється від режиму користування переведенням усіх змінних режимів (AuditMode, DeployedMode, SetupMode) у режим тільки для читання.

Перехід у інші режими (користування або налаштування) можливий тільки через платформозалежні методи або автентифіковане очищення PK[9].

Процес авторизації

Перед запуском невідомого UEFI-образу він має пройти процес авторизації.

1. Скидання. На цьому етапі відбувається ініціалізація платформи під час завантаження.
2. Ініціалізація сховища ключів.
3. Валідація UEFI-образу. Для успішної авторизації підпис або геш образу повинні міститися в db, і не повинні міститися в dbx.
4. Якщо UEFI-образ не пройшов валідації, прошивка може використовувати інші методи валідації (наприклад, запитати у авторизованого користувача приватний ключ, який відповідає публічному ключу в KEK). Результатом на цьому етапі може бути дозвіл (крок 8), відмова (крок 6) або відтермінування.
5. У разі відтермінування інформація про підпис додається до спеціальної таблиці, доступної з операційної системи.
6. У разі відмови або відтермінування робиться спроба виконання наступного варіанта завантаження (крок 3).
7. У разі дозволу підпис образу зберігається до бази даних підписів.
8. Запуск образу.

Оновлення бази даних довірених програм також доступне з операційної системи[10].

Ключі користувача

Користувач може самостійно згенерувати та встановити власні ключі. «Повний цикл» генерування ключів реалізовано як для ОС Linux, так і для Windows.

Як правило, в процесі генерування ключів застосовується такий ланцюжок перетворень:

PEM => DER => ESL => AUTH

Для Windows є спеціальні інструменти від Microsoft, а на Linux використовують OpenSSL і набір утиліт EfiTools. Існує проблема, пов'язана з відсутністю інтерфейсу для встановлення ключів користувача в BIOS деяких виробників. Для цього може знадобитись окрема утиліта.

Додаткову складність створює необхідність сумісності з обладнанням від Майкрософт у низці випадків. Перевірка працює в обидва боки і без ключів Майкрософт їхнє ПЗ та апаратура (наприклад, GOP-драйвери зовнішніх відеокарт та PXE-драйвери зовнішніх мережевих карт, а значить і самі карти) не працюватимуть. Тобто на певному рівні довіритися Майкрософт доведеться в будь-якому разі.

Користувачеві доведеться додати ключ від Майкрософт до db або КЕК, що створює додаткові ризики для безпеки.

На одному комп'ютері може бути кілька КЕК та db. Таким чином, може утворитися кілька гілок довіри. Або навпаки, одна db може бути підписана кількома КЕК (хоча це й не потрібно)

Розвиток механізму

HP Sure Start — рішення від компанії Hewlett-Packard, фактично є вбудованим апаратно-програмним засобом довіреного завантаження. Здійснює функцію захисту ключів Secure Boot. Secure Boot у його поточному вигляді Майкрософт пропонує як мінімальний стандарт безпеки при захисті від руткітів. Деякі виробники при цьому розробляють свої рішення, що забезпечують довірене завантаження у зв'язці з рішенням від Microsoft, прикладом такого рішення є HP Sure Start[11].

Переваги та недоліки

Переваги

• Захист від шкідливого ПЗ

При втручанні руткітів у критичні компоненти операційної системи підписи відповідних компонентів втрачають валідність. Таку операційну систему просто не буде завантажено[12].

• Локальні безпекові політики

За необхідності обмежити список можливих для запуску операційних систем це можна зробити, внісши відповідні підписи до баз даних підписів[12].

Недоліки

• Вибір обладнання

Драйвери пристроїв, підтримка яких необхідна на стадії завантаження системи, повинні мати підпис, який коректно проходив би перевірку на всіх платформах, де такі пристрої можуть використовуватися. Для цього всім виробникам такого обладнання доведеться узгоджуватися з усіма виробниками платформ для додавання їхніх ключів до сховищ систем. Або такі драйвери доведеться підписувати ключем, який вже міститься в більшості платформ, але тоді виробникам доведеться повністю покладатися на власника такого ключа (наприклад, Майкрософт підписує завантажувач shim[13][14]). Також можна створювати підписи ланцюжком, що закінчується ключем, який міститься в більшості платформ, але навіть цей підхід має недолік — при видаленні відповідного ключа зі сховища ключів (наприклад, щоб заборонити завантаження певної операційної системи) драйвери також втрачають валідність[12].

• Вибір операційної системи

Постачальники систем не повинні реалізовувати можливості відключення Secure Boot. Процедура додавання сторонніх ключів до сховища має бути недоступною для шкідливого програмного забезпечення, наслідком чого є ускладнення цієї процедури для користувачів. Два цих фактори разом значно ускладнюють використання непідписаних операційних систем, а також підписаних невідомим ключем для платформи[12].

• Вразливості у реалізації

Конкретні реалізації прошивок пристроїв різних виробників можуть містити вразливості, експлуатація яких може призвести до обходу механізму Secure boot або його нівелювання[15][16].

• Робота із засобами довіреного завантаження

Механізм Secure Boot може перешкоджати роботі засобів довіреного завантаження (ЗДЗ). Оскільки ЗДЗ підміняють завантажувач ОС власним завантажувачем, що у загальному випадку не має підпису, Secure Boot може заблокувати завантажувач ЗДЗ і, отже, перешкодити роботі ЗДЗ в цілому.

Є два способи вирішення цієї проблеми:

1. Вимкнення Secure Boot на комп'ютерах зі встановленим ЗДЗ. Прикладом такого підходу є ЗДЗ SafeNode System Loader[17].
2. Постачання разом із ЗДЗ комплекту автентифікованих змінних, що засвідчують валідність підпису завантажувача. Після встановлення змінних робота ЗДЗ проводитиметься без обмежень з боку Secure Boot. Прикладом такого підходу є ЗДЗ Dallas Lock. Разом із ключами в такому разі постачається й утиліта keytool.efi[18].

• UEFI BIOS деяких виробників мають слабко розвинений інтерфейс для керування Secure Boot

Див. також

• Тивоїзація
• Embrace, Extend, and Extinguish (з англ. —  «підтримати, надбудувати та знищити») — політика Microsoft для усунення конкурентів та монополізації ринку
• Довірене завантаження (апаратні засоби)

Примітки

1. Специфікація UEFI.
2. Will your computer’s «Secure Boot» turn out to be «Restricted Boot»? (англ.). Free Software Foundation. Архів оригіналу за 28 листопада 2013. Процитовано 23 грудня 2016.
3. Windows 8 Secure Boot: The Controversy Continues (англ.). PC World. Архів оригіналу за 31 березня 2017. Процитовано 23 грудня 2016.
4. Is Microsoft Blocking Linux Booting on ARM Hardware? (англ.). Computerworld UK. Архів оригіналу за 5 квітня 2016. Процитовано 23 грудня 2016.
5. Специфікація UEFI, с. 1817.
6. Специфікація UEFI, с. 1818.
7. Специфікація UEFI, с. 1828.
8. Специфікація UEFI, с. 1819.
9. Специфікація UEFI, с. 1816.
10. Специфікація UEFI, с. 1803—1834.
11. Technical white paper HP Sure Start (англ.). Архів оригіналу за 19 листопада 2020. Процитовано 6 квітня 2022.
12. Jeremy Kerr, Matthew Garrett, James Bottomley. UEFI Secure Boot Impact on Linux (PDF) (англ.). Архів (PDF) оригіналу за 19 липня 2017. Процитовано 23 грудня 2016.
13. mjg59 | Secure Boot bootloader for distributions available now. Архів оригіналу за 25 жовтня 2019. Процитовано 25 жовтня 2019.
14. Secure the Windows 10 boot process — Microsoft 365 Security | Microsoft Docs. Архів оригіналу за 25 жовтня 2019. Процитовано 25 жовтня 2019. {{cite web}}: символ нерозривного пробілу в |title= на позиції 35 (довідка)
15. Corey Kallenberg, Sam Cornwell, Xeno Kovah, John Butterworth. Setup For Failure: Defeating Secure Boot (PDF) (англ.). The MITRE Corporation. Архів (PDF) оригіналу за 23 грудня 2016. Процитовано 23 грудня 2016.
16. Lucian Constantin. Researchers demo exploits that bypass Windows 8 Secure Boot (англ.). ITworld. Архів оригіналу за 24 грудня 2016. Процитовано 23 грудня 2016. [Архівовано 2016-12-24 у Wayback Machine.]
17. Руководство администратора к СДЗ SafeNode System Loader (рос.). Архів оригіналу за 14 серпня 2020. Процитовано 6 квітня 2022.
18. Руководство по эксплуатации СДЗ Dallas Lock (PDF) (рос.). Архів (PDF) оригіналу за 2 квітня 2022. Процитовано 6 квітня 2022.

Література

• Unified Extensible Firmware Interface Specification. Version 2.6 (PDF) (англ.). 2016-01. Процитовано 22 грудня 2016.