Product SiteDocumentation Site

Fedora 18

Підручник з UEFI Secure Boot

Видання 18.4

Josh Boyer

Проект Fedora

Kevin Fenzi

Проект Fedora

Peter Jones

Команда зі встановлення Red Hat

Josh Bressers

Команда зі встановлення Red Hat

Florian Weimer

Команда зі встановлення Red Hat

За редакції

Eric Christensen

Команда зі встановлення Red Hat

Правова примітка

Copyright © 2012-2013 Fedora Project Contributors.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.
Анотація

Preface
1. Домовленості, що використовуються у документі
1.1. Типографічні стилі
1.2. Умовне позначення цитування
1.3. Примітки та попередження
2. Нам потрібні ваші відгуки!
1. Для чого призначено UEFI Secure Boot?
1.1. UEFI Secure Boot
1.2. Вимоги Microsoft щодо Secure Boot
1.2.1. Подробиці щодо реалізації
1.3. Secure Boot у Fedora
1.4. Від чого Secure Boot може вас захистити?
1.5. Потенційні ризики щодо використання Secure Boot
1.5.1. Примусове обмеження можливостей у режимі Secure Boot
1.5.2. Перенесення системи і Secure Boot
1.5.3. Не передбачено інфраструктури ініціалізації, окрім Microsoft Windows
1.5.4. Не перевірені процедури відкликання сертифікації
2. System Configuration
2.1. Entering the UEFI firmware
2.2. Disabling UEFI Secure Boot
2.3. Enabling Microsoft Secure Boot
2.4. Known issues
3. Реалізація Secure Boot UEFI
3.1. Ключі
3.2. Shim
3.3. GRUB
3.4. Ядро
3.4.1. Обмеження
4. Інструменти
4.1. Shim
4.2. Pesign
4.3. EFIKeyGen
4.4. sign-file
5. Використання ваших власних ключів
5.1. Створення ключів
5.2. Створення ключів для збирання shim
5.3. Пакунки, які потребують перезбирання
5.4. Реєстрація ваших ключів у мікропрограмі
A. Журнал версій
Покажчик

Preface

1. Домовленості, що використовуються у документі

У цьому документі використано певні домовленості щодо позначення певних слів чи фраз та привертання уваги до частин інформації.
У паперовій та PDF версіях цього документа використовуються шрифти гарнітури Liberation Fonts. Набір шрифтів Liberation також використовується у HTML-версії, якщо ці шрифти встановлено у вашій системі. Примітка: шрифти Liberation входять до складу Red Hat Enterprise Linux 5 та новіших версій.

1.1. Типографічні стилі

Для привернення уваги до певних частин тексту використано чотири типографічних стилів. Нижче наведено опис цих стилів та обставин, за яких їх застосовують.
Моноширинний жирний
Використовується для позначення інформації, що вводиться до системи, зокрема команд оболонки, назв файлів та їх адрес. Крім того, використовується для позначення назв клавіш та комбінацій клавіш. Приклад:
Щоб переглянути вміст файла my_next_bestselling_novel у поточному каталозі, введіть у командному рядку команду cat my_next_bestselling_novel та натисніть Enter, щоб наказати системі виконати команду.
У наведеному вище прикладі вказано назву файла, команду оболонки та назву клавіші, які позначено моноширинним жирним шрифтом.
Для відокремлення клавіш у складі комбінацій клавіш використовується знак дефіса. Приклад:
Щоб виконати команду, натисніть Enter.
Для перемикання на перший віртуальний термінал натисніть Ctrl+Alt+F2. Щоб повернутись до вікна сеансу X-Window, натисніть Ctrl+Alt+F1.
У першому прикладі позначено назву окремої клавіші. У другому — дві комбінації клавіш (кожна є сукупністю трьох клавіш, які слід натискати одночасно).
Цим же шрифтом позначаються тексти програми, назви класів, методи, функції, назви змінних та значення, що повертаються. Приклад:
До класів для роботи з файлами належать: filesystem — клас для роботи з файловою системою, file — для роботи з файлами, та dir — для роботи з каталогами. З кожним класом пов'язаний власний набір прав доступу.
Пропорційний жирний
Цим шрифтом позначаються слова та фрази, що зустрічаються у системі, зокрема назви програм, текст з діалогових вікон, назви кнопок, інші елементи графічного інтерфейсу, пункти меню. Приклад:
Щоб запустити програму Параметри миші, виберіть у головному меню Система > Параметри > Миша. Щоб зробити головною кнопкою праву кнопку миші, замість лівої, на вкладці Кнопки, позначте пункт Під ліву руку і натисніть на кнопку Закрити (це зробить мишу зручною для використання лівою рукою).
Щоб вставити спеціальний символ у файлі gedit, у головному меню виберіть Програми > Стандартні > Таблиця символів. Потім, виберіть Пошук > Знайти… у меню Таблиця символів, введіть назву символу у полі Пошук та натисніть Наступний. Символ, який ви шукаєте, буде позначено у полі Таблиця символів. Двічі клацніть на позначеному символі, щоб помістити його у поле Текст для копіювання, а потім натисніть кнопку Копіювати. Тепер поверніться назад до вашого документа і скористайтеся пунктом меню Правка > Вставити gedit.
Наведений вище текст містить назви програм; загальносистемні назви пунктів меню; специфічні для програми пункти меню; назви кнопок та інших елементів графічного інтерфейсу, усі вони позначаються пропорційним жирним шрифтом та розрізняються за контекстом.
Моноширинний жирний курсив або Пропорційний жирний курсив
Обидва стилі означають текст, який треба замінити чи змінний текст. Курсив вказує, що текст не слід вводити дослівно, а змінити його залежно від параметрів. Приклад:
Щоб з'єднатись з віддаленим комп'ютером через ssh, введіть у командному рядку ssh ім'я_користувача@назва.домену. Наприклад, якщо назва віддаленого комп'ютера example.com а назва облікового запису john, введіть ssh john@example.com.
Команда mount -o remount файлова_система повторно монтує файлову систему. Наприклад, для повторного монтування файлової системи /home, слід вказати команду mount -o remount /home.
Щоб побачити версію встановленого пакету, скористайтеся командою rpm -q пакунок. Вона поверне результат у вигляді: пакунок-версія-випуск.
У наведених прикладах жирним курсивом позначаються ім'я_користувача, назва.домену, файлова система, пакет, версія та випуск. Кожне слово замінюється при вводі на фактичну команду, що вводиться або замінюється при виводі справжнім текстом, який покаже система.
Також курсивом позначається перше використання нового та важливого терміну. Приклад:
Publican — це система публікації документів, заснована на DocBook.

1.2. Умовне позначення цитування

Виведені у терміналі дані або початкові коди програми виокремлюються з навколишнього тексту.
Текст, що виводиться на термінал, також позначається моноширинним прямим шрифтом:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Для текстів програм також застосовується моноширинний шрифт, але додається позначення синтаксичних конструкцій:
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

1.3. Примітки та попередження

Зрештою, для привертання уваги до важливої інформації використовуються три візуальні стилі.

Примітка

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

Важливо

На інформацію, що позначена важливою, слід звернути увагу. Вона може містити дані щодо зміни у конфігурації, що стосуються лише поточної версії, або служби, які слід перезапустити перш ніж буде застосовано оновлення. Ознайомлення з важливою інформацією може значно спростити вашу роботу.

Попередження

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

2. Нам потрібні ваші відгуки!

Якщо ви знайдете типографську помилку у цій довідці, або якщо маєте пропозиції щодо її покращення, ми будемо раді вас почути! Надішліть повідомлення у Bugzilla: http://bugzilla.redhat.com/bugzilla/ для продукту Fedora.
При надсиланні повідомлення, не забудьте вказати ідентифікатор документу довідки: UEFI_Secure_Boot_Guide
Якщо ви маєте пропозиції щодо вдосконалення документації, намагайтесь точніше описати їх. Якщо знайшли помилку, будь ласка, включайте номер розділу та уривок тексту поблизу помилки, щоб її можна було швидко знайти.

Розділ 1. Для чого призначено UEFI Secure Boot?

Secure Boot — технологія, відповідно до якої мікрокод системи перевіряє, чи підписано системний завантажувач за допомогою криптографічного ключа, уповноваженого на це базою даних, що міститься у мікрокоді. У разі використання адекватної системи перевірки підписів у завантажувачах наступних рівнів, ядрі і, потенційно, програмах для користувачів можна запобігти виконанню комп’ютером непідписаного коду.
Secure Boot — різновид Verified Booting (перевірене завантаження) Перевірка шляхів завантаження системи є також частиною інших технологій, зокрема Trusted Boot. Перевірка шляхів завантаження системи є незалежним від безпечного зберігання криптографічних ключів та віддаленої атестації захистом системи.

1.1. UEFI Secure Boot

UEFI Secure Boot — компонент перевірки шляхів завантаження у специфікації UEFI (Unified Extensible Firmware Interface або універсальний розширюваний інтерфейс мікрокоду) з версії 2.3. Якщо коротко, цей компонент визначає такі елементи захисту:
  • програмний інтерфейс для криптографічно захищених змінних UEFI у незалежному від живлення сховищі даних,
  • спосіб зберігання довірених кореневих сертифікатів X.509 у змінних UEFI,
  • перевірка програм UEFI (завантажувачів і драйверів) за допомогою підписів AuthentiCode, вбудованих до цих програм, і
  • процедури відкликання скомпрометованих сертифікатів та хешів програм.
Для реалізації UEFI Secure Boot не потрібно ніякого спеціалізованого обладнання, окрім незалежного від живлення (флеш) сховища даних, яке можна перемикати з режиму читання з записом у режим лише читання під час завантаження системи. У цьому сховищі мають зберігатися сама реалізація UEFI та декілька захищених змінних UEFI (зокрема сховище довірених кореневих сертифікатів).
З точки зору користування, система, у якій увімкнено UEFI Secure Boot і виявлено втручання до завантаження, просто не завантажиться, доки UEFI Secure Boot не буде вимкнено або на носії даних не буде виявлено підписаного завантажувача наступного рівня. (На ілюстрації Рисунок 1.1, “Типове повідомлення про помилку від UEFI Secure Boot” показано типове повідомлення про помилку.) Так само, засоби встановлення операційної системи без криптографічно коректного підпису не можна буде запустити, у відповідь на запуск таких засобів буде лише показано повідомлення про помилку. Користувачі не зможуть скасувати рішення завантажувача щодо відмови у визнанні підпису, на відміну від ситуації з сертифікатами серверів у інтернеті. Крім того, користувачі не матимуть доступу до даних щодо видавця сертифіката.
┌────────── Secure Boot Violation ──────────┐
│                                           │
├───────────────────────────────────────────┤
│ Invalid signature detected. Check Secure  │
│          Boot Policy in Setup             │
│                                           │
│                                           │
│                   [OK]                    │
└───────────────────────────────────────────┘
Рисунок 1.1. Типове повідомлення про помилку від UEFI Secure Boot

UEFI Secure Boot не запобігає встановленню або вилученню завантажувачів другого рівня і не вимагає явного підтвердження внесення таких змін. Перевірка підписів виконується під час завантаження, а не під час встановлення або оновлення завантажувача. Тому UEFI Secure Boot не запобігає маніпуляціям з шляхом завантаження. Він лише запобігає виконанню зміненого шляху завантаження у системі після внесення таких змін та спрощує виявлення таких змін.

Клієнтська технологія

У поточній версії UEFI Secure Boot загалом увімкнено лише на клієнтських пристроях, його не рекомендується використовувати на серверних комп’ютерах. Вважається, що Secure Boot стане частиною серверних технологій майбутнього.

1.2. Вимоги Microsoft щодо Secure Boot

Microsoft оприлюднено доволі обмежені дані щодо реалізованої компанією версії Secure Boot, заснованої на UEFI Secure Boot.
Microsoft передбачено підтримку UEFI Secure Boot лише у Windows 8, але для встановлення і запуску Windows 8 ця підтримка не обов’язкова. Системи у середовищі UEFI Secure Boot продовжуватимуть завантажуватися, якщо прибрати підтримку Secure Boot з середовища UEFI. Споживачі, яким потрібна підтримка попередніх версій Windows, мають вимкнути Secure Boot, оскільки для них Microsoft не випускає підписаних завантажувачів.
Судячи з відкритих джерел, у версії Secure Boot від Microsoft реалізовано такі можливості захисту:
  • захист цілісності образу для встановлення, який зберігається на придатному для запису носієві даних (зокрема розділах для відновлення жорстких дисків),
  • захист шляху завантаження до того, як зможуть завантажитися евристичні контрзаходи (зокрема антивірусне програмне забезпечення на рівні ядра), на ранній стадії завантаження і
  • автоматичне відновлення початкового шляху завантаження після ймовірного пошкодження системи зловмисним програмним забезпеченням без потреби у повному перевстановленні операційної системи.
Залишається таємницею, чи є плани щодо обмеження доступу до певних даних (у мережі) для систем, у яких увімкнено UEFI і для яких шлях завантаження є криптографічно коректним. Таке обмеження, очевидно, має бути пов’язано з якоюсь сторонньою атестацією, яка не є частиною специфікації UEFI Secure Boot і яку не можна реалізувати безпечно без додаткової підтримки з боку обладнання. Також подібні обмеження має бути пов’язано з обов’язковістю використання UEFI Secure Boot.
Немає ніяких ознак того, що Microsoft має якісь наміри забороняти доступ до реалізації Secure Boot, розробленої компанією. Втім, автоматичне відновлення початкового шляху завантаження стає набагато складнішим завданням, якщо у системі використано декілька завантажувачів.

1.2.1. Подробиці щодо реалізації

Вимогами Microsoft передбачено, що всі клієнтські персональні комп’ютери, на яких розміщено логотип Windows 8, має бути увімкнено UEFI Secure Boot і встановлено надані Microsoft ключі. Потрібний для роботи сертифікат X.509 наведено у розділі Рисунок 1.2, “Довірений сертифікат X.509 Microsoft для реалізації Secure Boot від цієї компанії”. Постачальники обладнання заохочуються до включення інших кореневих сертифікатів, якщо це потрібно, втім, ця вимога не є обов’язковою до виконання.
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            61:07:76:56:00:00:00:00:00:08
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
	        CN=Microsoft Root Certificate Authority 2010
        Validity
            Not Before: Oct 19 18:41:42 2011 GMT
            Not After : Oct 19 18:51:42 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
                 CN=Microsoft Windows Production PCA 2011
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:dd:0c:bb:a2:e4:2e:09:e3:e7:c5:f7:96:69:bc:
		    […]
                    87:65:b4:43:18:a8:b2:e0:6d:19:77:ec:5a:24:fa:
                    48:03
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            1.3.6.1.4.1.311.21.1:
                02:01:00
            X509v3 Subject Key Identifier: 
                A9:29:02:39:8E:16:C4:97:78:CD:90:F9:9E:4F:9A:E1:7C:55:AF:53
            1.3.6.1.4.1.311.20.2:
                1E:0A:00:53:00:75:00:62:00:43:00:41
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Authority Key Identifier: 
                keyid:D5:F6:56:CB:8F:E8:A2:5C:62:68:D1:3D:94:90:5B:D7:CE:9A:18:C4

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.microsoft.com/pki/crl/products/MicRooCerAut_2010-06-23.crl

            Authority Information Access: 
                CA Issuers - URI:http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt

    Signature Algorithm: sha256WithRSAEncryption
         14:fc:7c:71:51:a5:79:c2:6e:b2:ef:39:3e:bc:3c:52:0f:6e:
	 […]
         04:cf:77:a4:62:1c:59:7e

-----BEGIN CERTIFICATE-----
MIIF1zCCA7+gAwIBAgIKYQd2VgAAAAAACDANBgkqhkiG9w0BAQsFADCBiDELMAkG
A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx
HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEyMDAGA1UEAxMpTWljcm9z
b2Z0IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIwMTAwHhcNMTExMDE5MTg0
MTQyWhcNMjYxMDE5MTg1MTQyWjCBhDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldh
c2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBD
b3Jwb3JhdGlvbjEuMCwGA1UEAxMlTWljcm9zb2Z0IFdpbmRvd3MgUHJvZHVjdGlv
biBQQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN0Mu6Lk
Lgnj58X3lmm8ACG9aTMz760Ey1SA7gaDu8UghNn30ovzOLCrpK0tfGJ5Bf/jSj8E
NSBw48Tna+CcwDZ16Yox3Y1w5dw3tXRGlihbh2AjLL/cR6Vn91EnnnLrB6bJuR47
UzV85dPsJ7mHHP65ySMJb6hGkcFuljxB08ujP10Cak3saR8lKFw2//1DFQqU4Bm0
z9/CEuLCWyfuJ3gwi1sqCWsiiVNgFizAaB1TuuxJ851hjIVoCXNEXX2iVCvdefcV
zzVdbBwrXM68nCOLb261Jtk2E8NP1ieuuTI7QZIs4cfNd+iqVE73XAsEh2W0Qxio
suBtGXfsWiT6SAMCAwEAAaOCAUMwggE/MBAGCSsGAQQBgjcVAQQDAgEAMB0GA1Ud
DgQWBBSpKQI5jhbEl3jNkPmeT5rhfFWvUzAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi
AEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTV
9lbLj+iiXGJo0T2UkFvXzpoYxDBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3Js
Lm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNSb29DZXJBdXRfMjAx
MC0wNi0yMy5jcmwwWgYIKwYBBQUHAQEETjBMMEoGCCsGAQUFBzAChj5odHRwOi8v
d3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY1Jvb0NlckF1dF8yMDEwLTA2
LTIzLmNydDANBgkqhkiG9w0BAQsFAAOCAgEAFPx8cVGlecJusu85Prw8Ug9uKz8Q
E3P+qGjQSKY0TYqWBSbuMUaQYXnW/zguRWv0wOUouNodj4rbCdcax0wKNmZqjOwb
1wSQqBgXpJu54kAyNnbEwVrGv+QEwOoW06zDaO9irN1UbFAwWKbrfP6Up06O9Ox8
hnNXwlIhczRa86OKVsgE2gcJ7fiL4870fo6u8PYLigj7P8kdcn9TuOu+Y+DjPTFl
sIHl8qzNFqSfPaixm8JC0JCEX1Qd/4nquh1HkG+wc05Bn0CfX+WhKrIRkXOKISjw
zt5zOV8+q1xg7N8DEKjTCen09paFtn9RiGZHGY2isBI9gSpoBXe7kUxie7bBB8e6
eoc0Aw5LYnqZ6cr8zko3yS2kV3wc/j3cuA9a+tbEswKFAjrqs9lu5GkhN96B0fZ1
GQVn05NXXikbOcjuLeHN5EVzW9DSznqrFhmCRljQXp2Bs2evbDXyvOU/JOI1ogp1
BvYYVpnUeCzRBRvr0IgBnaoQ8QXfun4sY7cGmyMhxPl4bOJYFwY2K5ESA8yk2fIt
uvmUnUDtGEXxzopcaz6rA9NwGCoKauBfR9HVYwoy8q/XNh8qcFrlQlkIcUtXun6D
gfAhPPQcwcW5kJMOiEWThumxIJm+mMvFlaRdYtagYwggvXUQd30980W5n5efy1eA
bzOpBM93pGIcWX4=
-----END CERTIFICATE-----
Рисунок 1.2. Довірений сертифікат X.509 Microsoft для реалізації Secure Boot від цієї компанії

Очікується, що Microsoft постачатиме підписані запити щодо відкликання сертифікатів на Windows Update. Ці запити встановлюватимуться до змінних налаштування UEFI Secure Boot під час наступного завантаження системи, після перевірки запитів за допомогою ключа Microsoft. На час написання цього підручника відповідного «чорного» списку сертифікатів ще не існувало.
Розробникам сторонніх завантажувачів на час написання цього підручника доступ до сертифіката Microsoft Windows Production PCA 2011, яким компанія Microsoft користується для підписування власних продуктів, було закрито. Замість цього, Microsoft надає послуги служби сертифікації, початковим призначенням якої було підписування драйверів UEFI. Можливості цієї служби було розширено, тепер вона надає послуги з підписування сторонніх завантажувачів. Співробітники Microsoft розглядають надані програми UEFI, надають підпис AuthentiCode на основі власного ключа компанії і надсилають результат авторові подання. За таким підписом не можна ідентифікувати автора програми (псевдоанонімність) і, що важливіше, його пов’язано за допомогою проміжного сертифіката Microsoft Corporation UEFI CA 2011 (див. Рисунок 1.3, “Сертифікат X.509 Microsoft для сторонніх програм UEFI”) з кореневим сертифікатом Microsoft Corporation Third Party Marketplace Root.

Застереження

Сторонні завантажувачі UEFI можуть не працювати у системах з Microsoft Secure Boot, оскільки потрібні для їхньої роботи сертифікати не є частиною специфікації Microsoft Secure Boot.
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            61:08:d3:c4:00:00:00:00:00:04
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
                CN=Microsoft Corporation Third Party Marketplace Root
        Validity
            Not Before: Jun 27 21:22:45 2011 GMT
            Not After : Jun 27 21:32:45 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
                 CN=Microsoft Corporation UEFI CA 2011
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a5:08:6c:4c:c7:45:09:6a:4b:0c:a4:c0:87:7f:
                    06:75:0c:43:01:54:64:e0:16:7f:07:ed:92:7d:0b:
                    b2:73:bf:0c:0a:c6:4a:45:61:a0:c5:16:2d:96:d3:
                    f5:2b:a0:fb:4d:49:9b:41:80:90:3c:b9:54:fd:e6:
                    bc:d1:9d:c4:a4:18:8a:7f:41:8a:5c:59:83:68:32:
                    bb:8c:47:c9:ee:71:bc:21:4f:9a:8a:7c:ff:44:3f:
                    8d:8f:32:b2:26:48:ae:75:b5:ee:c9:4c:1e:4a:19:
                    7e:e4:82:9a:1d:78:77:4d:0c:b0:bd:f6:0f:d3:16:
                    d3:bc:fa:2b:a5:51:38:5d:f5:fb:ba:db:78:02:db:
                    ff:ec:0a:1b:96:d5:83:b8:19:13:e9:b6:c0:7b:40:
                    7b:e1:1f:28:27:c9:fa:ef:56:5e:1c:e6:7e:94:7e:
                    c0:f0:44:b2:79:39:e5:da:b2:62:8b:4d:bf:38:70:
                    e2:68:24:14:c9:33:a4:08:37:d5:58:69:5e:d3:7c:
                    ed:c1:04:53:08:e7:4e:b0:2a:87:63:08:61:6f:63:
                    15:59:ea:b2:2b:79:d7:0c:61:67:8a:5b:fd:5e:ad:
                    87:7f:ba:86:67:4f:71:58:12:22:04:22:22:ce:8b:
                    ef:54:71:00:ce:50:35:58:76:95:08:ee:6a:b1:a2:
                    01:d5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            1.3.6.1.4.1.311.21.1:
                02:03:01:00:01
            1.3.6.1.4.1.311.21.2:
                04:14:F8:C1:6B:B7:7F:77:53:4A:F3:25:37:1D:4E:A1:26:7B:0F:20:70:80
            X509v3 Subject Key Identifier: 
                13:AD:BF:43:09:BD:82:70:9C:8C:D5:4F:31:6E:D5:22:98:8A:1B:D4
            1.3.6.1.4.1.311.20.2:
	        1E:0A:00:53:00:75:00:62:00:43:00:41
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Authority Key Identifier: 
                keyid:45:66:52:43:E1:7E:58:11:BF:D6:4E:9E:23:55:08:3B:3A:22:6A:A8

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.crl

            Authority Information Access: 
                CA Issuers - URI:http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt

    Signature Algorithm: sha256WithRSAEncryption
         35:08:42:ff:30:cc:ce:f7:76:0c:ad:10:68:58:35:29:46:32:
         […]
         92:9b:f5:a6:bc:59:83:58

-----BEGIN CERTIFICATE-----
MIIGEDCCA/igAwIBAgIKYQjTxAAAAAAABDANBgkqhkiG9w0BAQsFADCBkTELMAkG
A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx
HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE7MDkGA1UEAxMyTWljcm9z
b2Z0IENvcnBvcmF0aW9uIFRoaXJkIFBhcnR5IE1hcmtldHBsYWNlIFJvb3QwHhcN
MTEwNjI3MjEyMjQ1WhcNMjYwNjI3MjEzMjQ1WjCBgTELMAkGA1UEBhMCVVMxEzAR
BgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1p
Y3Jvc29mdCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0
aW9uIFVFRkkgQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKUIbEzHRQlqSwykwId/BnUMQwFUZOAWfwftkn0LsnO/DArGSkVhoMUWLZbT9Sug
+01Jm0GAkDy5VP3mvNGdxKQYin9BilxZg2gyu4xHye5xvCFPmop8/0Q/jY8ysiZI
rnW17slMHkoZfuSCmh14d00MsL32D9MW07z6K6VROF31+7rbeALb/+wKG5bVg7gZ
E+m2wHtAe+EfKCfJ+u9WXhzmfpR+wPBEsnk55dqyYotNvzhw4mgkFMkzpAg31Vhp
XtN87cEEUwjnTrAqh2MIYW9jFVnqsit51wxhZ4pb/V6th3+6hmdPcVgSIgQiIs6L
71RxAM5QNVh2lQjuarGiAdUCAwEAAaOCAXYwggFyMBIGCSsGAQQBgjcVAQQFAgMB
AAEwIwYJKwYBBAGCNxUCBBYEFPjBa7d/d1NK8yU3HU6hJnsPIHCAMB0GA1UdDgQW
BBQTrb9DCb2CcJyM1U8xbtUimIob1DAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMA
QTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRFZlJD
4X5YEb/WTp4jVQg7OiJqqDBcBgNVHR8EVTBTMFGgT6BNhktodHRwOi8vY3JsLm1p
Y3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNDb3JUaGlQYXJNYXJSb29f
MjAxMC0xMC0wNS5jcmwwYAYIKwYBBQUHAQEEVDBSMFAGCCsGAQUFBzAChkRodHRw
Oi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY0NvclRoaVBhck1hclJv
b18yMDEwLTEwLTA1LmNydDANBgkqhkiG9w0BAQsFAAOCAgEANQhC/zDMzvd2DK0Q
aFg1KUYydid87xJBJ0IbSqptgThIWRNV8+lYNKYWC4KqXa2C2oCDQQaPtB3yA7nz
Gl0b8VCQ+bNVhEIoHCC9sq5RFMXArJeVIRyQ2w/8d56Vc5GIyr29UrkFUA3fV56g
Ye0N5W0l2UAPF0DIzqNKwk2vmhIdCFSPvce8uSs9SSsfMvxqIWlPm8h+QjT8NgYX
i48gQMCzmiV1J83JA6P2XdHnNlR6uVC10xLRB7+7dN/cHo+A1e0Y9C8UFmsv3maM
sCPlx4TY7erBM4KtVksYLfFolQfNz/By8K673YaFmCwhTDMr8A9K8GiHtZJVMnWh
aoJqPKMlEaTtrdcErsvYQFmghNGVTGKRIhp0HYw9Rw5EpuSwmzQ1sfq2U6gsgeyk
BXHInbi66BtEZuRHVA6OVn+znxaYsobQaD6QI7UvXo9QhY3GjYJfQaH0Lg3gmdJs
deS2abUhhvoH0fbiTdHarSx3Ux4lMjfHbFJylYaw8TVhahn1sjuBUFamMi3+oon5
QoYnGFWhgspam/gwmFQUpkeWJS/IJuRBlBpcAj/lluOFWzw+P7tHFnJV4iUisdl7
5wMGKqP3HpBGwwAN1hmJ4w41J2IDcRWm79AnoKBZN2D4OJS44Hhw+LpMhoeU9uCu
AkXuZcK2o35pFnUHkpv1prxZg1g=
-----END CERTIFICATE-----
Рисунок 1.3. Сертифікат X.509 Microsoft для сторонніх програм UEFI

Звичайного сертифіката для підписування недостатньо для гарантування завантаження у системі з Microsoft Secure Boot. Microsoft вимагає сертифікат для підписування коду під час роботи з авторами програм для UEFI, але ця процедура стосується лише розробників, сертифікація залишається непомітною для кінцевого споживача.
Після завантаження операційної системи у Microsoft Windows 8 передбачено підтримку перевірки і завантаження за допомогою AuthentiCode підписаних сторонніх модулів ядра системи. У Windows передбачено інфраструктуру для розширення криптографічної перевірки на програми користувача, знову ж таки на основі AuthentiCode.

1.3. Secure Boot у Fedora

Реалізація Secure Boot у Fedora має єдину мету: запобігання виконанню непідписаного коду у режимі ядра.
У Fedora передбачено можливість завантаження систем з увімкненим Microsoft Secure Boot, якщо встановлено сертифікат Microsoft для сторонніх програм UEFI. Цей режим роботи має найбільше значення для встановлення Fedora на комп’ютери, які було приготовано спеціально до Windows 8. На іншому ж обладнанні, ймовірно, середовище Microsoft Secure Boot просто не реалізовано.

Застереження

Немає ніяких гарантій працездатності сторонніх завантажувачів UEFI (зокрема завантажувач Fedora) у системах з Microsoft Secure Boot, оскільки потрібні для роботи сертифікати не є частиною вимог щодо сертифікації обладнання Windows 8. Якщо ваше обладнання належить саме до такої категорії, вам слід вимкнути UEFI Secure Boot, зареєструвати сертифікат Microsoft, якого не вистачає, або зареєструвати сертифікат Fedora.
Fedora завантажується у системах UEFI без підтримки або з вимкненим Secure Boot. Завантаження у таких системах працюватиме для будь-яких завантажувачів UEFI. Такими завантажувачами також може бути передбачено підтримку запуску у середовищі, яке виконує перевірку шляху завантаження у інші способи, не пов’язані з UEFI. У такому режимі ніяких обмежень щодо виконання коду у режимі ядра не накладатиметься.
Подробиці реалізації Secure Boot у Fedora викладено у розділі Розділ 3, Реалізація Secure Boot UEFI. Обмеження на виконання коду у режимі ядра призводять до потреби у вимиканні деяких можливостей, див розділ Розділ 3.4.1, “Обмеження”.

1.4. Від чого Secure Boot може вас захистити?

На базовому рівні UEFI Secure Boot запобігає запуску непідписаних завантажувачів. Результати запуску завантажувача, звичайно ж, залежать від самого завантажувача. Наведені нижче дані стосуються реалізації Secure Boot у Fedora. Реалізація Microsoft відрізняється від цієї реалізації, див. розділ Розділ 1.2, “Вимоги Microsoft щодо Secure Boot”.
У Fedora ланцюжок довіри продовжено з середовища UEFI до ядра. Перевірка виконується до завантаження модулів ядра, але не поширюється на програми користувача системи. Забезпечується запобігання виконанню непідписаного коду до завантаження початкового образу системи (initrd) до оперативної пам’яті. Оскільки дані initrd не підписано криптографічно і у них міститься виконуваний код, завантаження підписано завантажувача Fedora може призвести до будь-яких результатів.
Реалізація Secure Boot у Fedora спрощує перевірку шляху завантаження у цифровій криміналістиці. Під час завантаження застарілого BIOS потенційно небезпечний код, завантажений з диска, виконувався на дуже ранній стадії, що значно ускладнювало визначення того, чи було систему скомпрометовано на дуже низькому рівні. (Частково переваги нового способу завантаження пов’язано з більш декларативною природою налаштувань завантаження UEFI на диску.)

1.5. Потенційні ризики щодо використання Secure Boot

Secure Boot не захистить ваш комп’ютер від більшості зловмисного програмного забезпечення або зловмисників. Secure Boot захищає лише фазу завантаження системи, але не може захистити від нападів на вже запущену систему або викрадення даних. У Fedora використання Secure Boot лише обмежує перелік модулів ядра, які можна завантажувати, але не надає додаткового захисту від зловмисного програмного забезпечення, запущеного від імені користувача системи. Початковий образ системи у пам’яті (initrd), що використовується під час завантаження, не захищено цією можливістю, отже у цьому образі може міститися зловмисний код.

1.5.1. Примусове обмеження можливостей у режимі Secure Boot

У поточній версії нами використано підхід з «чорним» списком для блокування можливостей ядра, користуватися якими небезпечно. У певних випадках вимкнено деякі функціональні можливості. Здебільшого ці можливості є доволі прихованими, використовуються вони доволі нечасто. Ось список обмежених можливостей у поточній версії:
  • внесення змін до карт адрес у пам’яті пристроїв за допомогою «setpci» і запис до пам’яті з простору користувача за допомогою sysfs
  • присипляння (також називається присипляння на диск)
  • kexec і kdump (робота над уможливленням цих компонентів триває)
  • запис до комп’ютеро-специфічних регістрів, запис за допомогою модуля ядра «msr».
  • параметр командного рядка acpi_rspd, який використовується для визначення нетипових даних ACPI
  • дії з введення або виведення до /dev/kmem
Крім того, можливості використання systemtap обмежено лише тими модулями, які було підписано з використанням відповідного сертифіката. Рекомендуємо вам створити такий сертифікат на місці, забезпечити належні умови захисту системи та використовувати лише підписані сертифікати. У разі використання локального сертифіката його можна зареєструвати у локальній базі даних комп’ютера за допомогою програми mokutil. Для набуття внесеними змінами чинності після використання цієї програми систему слід перезавантажити. Під час перезавантаження shim запустить MokManager з метою надання вам інтерфейсу для реєстрації сертифіката.

Застереження

Використання локальних сертифікатів вимагає використання належних заходів безпеки. Ці сертифікати мають бути недоступними для зловмисників, які можуть скористатися ними для компрометації захисту модулів. З такими сертифікатами слід поводитися як з будь-якими конфіденційними даними. Варто дотримуватися загальноприйнятих стандартів щодо ключів шифрування та сертифікатів.

1.5.2. Перенесення системи і Secure Boot

Оновлення BIOS або заміна материнської плати може призвести до вимикання Secure Boot у системах, де його було раніше увімкнено. Встановлення додаткового обладнання на комп’ютері може призвести до несумісності апаратної частини з Secure Boot (безпосередній доступ до пам’яті з режиму користувача, підтримка SystemTap, модулі ядра, зібрані не Red Hat). Це означає, що Secure Boot не може бути обов’язковим компонентом, потрібним для працездатності системи. Було б дуже нерозважливим вчинком, робити цей компонент захисту обов’язковим.

1.5.3. Не передбачено інфраструктури ініціалізації, окрім Microsoft Windows

Деякими виробниками апаратного забезпечення Secure Boot реалізовано так, що задіяти його можна лише у разі встановлення Windows 8. Користувачам, яким хочеться увімкнути Secure Boot, можливо доведеться отримати клієнтську ліцензію на Windows 8, надану виробником апаратного забезпечення. Про цей сценарій можна було б забути, якби у Red Hat Був би доступ до власного довіреного кореневого сертифіката, створеного у співробітництві з виробниками обладнання.

1.5.4. Не перевірені процедури відкликання сертифікації

Нам нічого не відомо про те, чи насправді працюють бізнес-процеси, пов’язані з відкликання сертифікатів. Відкликання — складна процедура, оскільки кожне відкликання має бути виконано синхронно усіма виробниками операційних систем для забезпечення підтримки можливості завантаження декількох систем на одному обладнанні. Без такої координації підпис може бути відкликано до того, як розробник операційної системи зможе його оновити. Це може призвести до неможливості завантаження системи.
Правила видання Microsoft даних щодо відкликання сертифікатів залишаються незрозумілими. Потенційними причинами відкликання можуть бути неможливість досягнення потрібного рівня захисту (тобто доведення можливості виконання непідписаного коду у лабораторних умовах) або використання вразливості у системі для компрометації шляху завантаження систем Windows 8 поза межами лабораторій. Останній варіант також може стосуватися можливості обійти захист Secure Boot і завантажити непідписаний код після певних дій користувача.

Розділ 2. System Configuration

This chapter describes how to configure systems for use with UEFI Secure Boot. The required steps vary from system to system because they depend on how the firmware implements the UEFI specification, but the descriptions should give you an idea where to look.

System can become unbootable

If the operating systems installed on your machine do not provide UEFI boot loaders, or if those boot loaders are not accepted by the new Secure Boot configuration because the signatures are not recognized, your system will no longer boot after switching on Secure Boot.

2.1. Entering the UEFI firmware

When the system is booting, try pressing the Enter, Del, F1 or Esc keys. Usually, instructions will appear telling you how to enter the firmware, similar to Рисунок 2.1, “Firmware activation instructions” (which still refers to the UEFI firmware as BIOS Setup Utility, so you are expected to press F1).
┌───────────────────────────────────────────────────────────┐
│                Startup Interrupt Menu                     │
│───────────────────────────────────────────────────────────│
│ Press one of the following keys to continue:              │
│                                                           │
│     ESC to resume normal startup                          │
│     F1 to enter the BIOS Setup Utility                    │
│     F12 to choose a temporary startup device              │
│                                                           │
│ Press ENTER to continue                                   │
│                                                           │
└─────────────────────────────9─────────────────────────────┘
Рисунок 2.1. Firmware activation instructions

You may want to insert a USB stick to prevent a full operating system from booting, so that you can reboot more quickly and try out different keys faster.
If the firmware is protected by a password and you do not know this password, you need to check your system or mainboard manual for password reset instructions.
Once you have entered the firmware, a screen similar to Рисунок 2.2, “UEFI firmware start screen” will be shown.
                                     Lenovo BIOS Setup Utility
    Main  Devices  Advanced  Power  Security  Startup  Exit
┌────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                        │
│► System Summary                                                                        │
│► System Time & Date                                                                    │
│                                                                                        │
│  Machine Type and Model               0896A9G                                          │
│  System Brand ID                      Lenovo Product                                   │
│  System Serial Number                 RUYWEQZ                                          │
│  Asset Tag                            INVALID                                          │
│  System UUID                          1846F489-64F1-4714-83D8-A02FD2C79AD1             │
│  Ethernet MAC address                 D5-3D-7E-60-29-2C                                │
│  BIOS Revision Level                  F1KT44AUS                                        │
│  Boot Block Revision Level            F144A                                            │
│  BIOS Date (MM/DD/YY)                 12/21/2012                                       │
│  License Status                                                                        │
│  Language                             [English]                                        │
│                                                                                        │
│                                                                                        │
│                                                                                        │
│                                                                                        │
│                                                                                        │
│                                                                                        │
│                                                                                        │
│                                                                                        │
└────────────────────────────────────────────────────────────────────────────────────────┘
 F1     Help     ↑↓     Select Item     +/-     Change Values       F9     Setup Defaults
 ESC    Exit     ←→     Select Menu     Enter   Select►Sub-Menu     F10    Save and Exit
Рисунок 2.2. UEFI firmware start screen

2.2. Disabling UEFI Secure Boot

Systems which come with Microsoft Windows 8 pre-installed typically have enabled UEFI Secure Boot, and ship the Microsoft keys in the firmware.
The Lenovo desktop system we use as an example makes disabling Secure Boot fairly straightforward. First, enter the firmware as described in Розділ 2.1, “Entering the UEFI firmware”. Press the key until you reach the Security tab, as shown in Рисунок 2.3, “UEFI firmware Security tab”.
                                     Lenovo BIOS Setup Utility
    Main  Devices  Advanced  Power  Security  Startup  Exit
┌────────────────────────────────────────────────────────┬───────────────────────────────┐
│                                                        │          Help Message         │
│  Hardware Password Manager            [Enabled]        │───────────────────────────────│
│  Secure Boot Status                   [Enabled]        │Select whether to enable or    │
│                                                        │disable Secure Boot            │
│  Adminstrator Password                Not Installed    │[Enabled] Enable Secure        │
│  Power-On Password                    Not Installed    │Boot,BIOS will prevent         │
│                                                        │un-authorised OS be loaded.    │
│  Set Administrator Password           Enter            │[Disable] Disables Secure      │
│  Set Power-On Password                Enter            │Boot.                          │
│                                                        │                               │
│  Allow Flashing BIOS to a Previous    [Yes]            │                               │
│  Version                                               │                               │
│                                                        │                               │
│  Require Admin. Pass. when Flashing   [No]             │                               │
│  Require POP on Restart               [No]             │                               │
│                                                        │                               │
│► Fingerprint Setup                                     │                               │
│► Hard Disk Password                                    │                               │
│► System Event Log                                      │                               │
│► Secure Boot                                           │                               │
│                                                        │                               │
│  Configuration Change Detection       [Disabled]       │                               │
│                                                        │                               │
└────────────────────────────────────────────────────────┴───────────────────────────────┘
 F1     Help     ↑↓     Select Item     +/-     Change Values       F9     Setup Defaults
 ESC    Exit     ←→     Select Menu     Enter   Select►Sub-Menu     F10    Save and Exit
Рисунок 2.3. UEFI firmware Security tab

Press until you reach the Secure Boot item and hit Enter. The Image Execution Policy screen appears (Рисунок 2.4, “UEFI firmware Secure Boot settings”).
                                     Lenovo BIOS Setup Utility
    Main  Devices  Advanced  Power  Security  Startup  Exit
┌────────────────────────────────────────────────────────┬───────────────────────────────┐
│                     Image Execution Policy             │          Help Message         │
│────────────────────────────────────────────────────────│───────────────────────────────│
│  Secure Boot Status                   User Mode        │Select whether to enable or    │
│  Secure Boot                          [Enabled]        │disable Secure Boot            │
│                                                        │[Enabled] Enable Secure        │
│  Reset to Setup Mode                                   │Boot,BIOS will prevent         │
│                                                        │un-authorised OS be loaded.    │
│                                                        │[Disable] Disables Secure      │
│                                                        │Boot.                          │
│                                                        │                               │
│                                                        │                  .            │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
└────────────────────────────────────────────────────────┴───────────────────────────────┘
 F1     Help     ↑↓     Select Item     +/-     Change Values       F9     Setup Defaults
 ESC    Exit     ←→     Select Menu     Enter   Select►Sub-Menu     F10    Save and Exit
Рисунок 2.4. UEFI firmware Secure Boot settings

Make sure that Secure Boot is selected, and press Enter, hit to choose Disabled, and press Enter again.
The previous step only disables verification of cryptographic signatures, it does not remove some restrictions Microsoft imposes on firmware settings. If you want to boot non-UEFI operating systems, it is necessary to disable the OS Optimized Defaults.

2.3. Enabling Microsoft Secure Boot

Systems which do not ship with Microsoft Windows 8 typically do not enable UEFI Secure Boot (or its Microsoft variant). However, many of these systems still contain the Microsoft keys in the firmware, and enabling Microsoft Secure Boot is relatively straightforward.
For example, on a Lenovo desktop system, you need to enter the firmware as described in Розділ 2.1, “Entering the UEFI firmware”. Then press the key until you reach the Exit tab, as shown in Рисунок 2.5, “UEFI firmware Exit tab”.
                                     Lenovo BIOS Setup Utility
    Main  Devices  Advanced  Power  Security  Startup  Exit
┌────────────────────────────────────────────────────────┬───────────────────────────────┐
│                                                        │          Help Message         │
│  Save Changes and Exit                                 │───────────────────────────────│
│  Discard Changes and Exit                              │Some settings below are        │
│                                                        │changed accordingly. Select    │
│  Load Optimal Defaults                                 │"Enabled" to meet Microsoft(R) │
│  OS Optimized Defaults                [Disabled]       │Windows 8 (R) Certification    │
│                                                        │Requirement.                   │
│                                                        │Affected settings are CSM      │
│                                                        │Support, Boot mode, Boot       │
│                                                        │Priority, Secure Boot, Secure  │
│                                                        │RollBack Prevention.           │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
└────────────────────────────────────────────────────────┴───────────────────────────────┘
 F1     Help     ↑↓     Select Item     +/-     Change Values       F9     Setup Defaults
 ESC    Exit     ←→     Select Menu     Enter   Select►Sub-Menu     F10    Save and Exit
Рисунок 2.5. UEFI firmware Exit tab

Press to select the OS Optimized Defaults entry. Press Enter to change the settings. A confirmation dialog will appear, and need to choose Yes. (See Рисунок 2.6, “UEFI firmware confirmation for OS Optimized Defaults”).
                                     Lenovo BIOS Setup Utility
    Main  Devices  Advanced  Power  Security  Startup  Exit
┌────────────────────────────────────────────────────────┬───────────────────────────────┐
│                                                        │          Help Message         │
│  Save Changes and Exit                                 │───────────────────────────────│
│  Discard Changes and Exit                              │Some settings below are        │
│                                                        │changed accordingly. Select    │
│  Load Optimal Defaults                                 │"Enabled" to meet Microsoft(R) │
│  OS Optimized Defaults   ┌───────────────────────────────────────────┐Certification    │
│                          │                 Attention!                │                 │
│                          ├───────────────────────────────────────────┤ngs are CSM      │
│                          │  If OS Optimized Defaults is changed to   │mode, Boot       │
│                          │  Enable, some settings including Secure   │re Boot, Secure  │
│                          │  Boot,CSM,IPV4 and IPV6 will be changed.  │ntion.           │
│                          │      Do you really want to continue?      │                 │
│                          │  Select Yes to continue to Enable the OS  │                 │
│                          │            Optimized Defaults.            │                 │
│                          │ Select No  to discontinue the operation.  │                 │
│                          │                                           │                 │
│                          │                                           │                 │
│                          │            [Yes]          [No]            │                 │
│                          └───────────────────────────────────────────┘                 │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
│                                                        │                               │
└────────────────────────────────────────────────────────┴───────────────────────────────┘
 F1     Help     ↑↓     Select Item     +/-     Change Values       F9     Setup Defaults
 ESC    Exit     ←→     Select Menu     Enter   Select►Sub-Menu     F10    Save and Exit
Рисунок 2.6. UEFI firmware confirmation for OS Optimized Defaults

Afterwards, check that OS Optimized Defaults has changed to Enabled. Press several times until you reach the Security tab (Рисунок 2.3, “UEFI firmware Security tab”), press to select Secure Boot, hit Enter, and check that Secure Boot is enabled, as in Рисунок 2.4, “UEFI firmware Secure Boot settings”.
Return to the Exit tab, choose Save Changes and Exit, and press Enter. Confirm saving the settings, and reboot. Microsoft Secure Boot is now enabled.

2.4. Known issues

When Fedora is installed on an UEFI system, existing boot loaders (for example, the code found in the Master Boot Record) are not overwritten. Therefore, Fedora has considerably less control over the boot process. In some cases, systems cannot dual-boot between Fedora and other operating systems. Even if Fedora is selected manually in the firmware boot loader selection dialog (choose a temporary startup device in Рисунок 2.1, “Firmware activation instructions”), the other operating system is started. This is not a problem with UEFI Secure Boot; on the affected systems, it also happens with Secure Boot disabled.
UEFI Secure Boot (and its Microsoft variant) require secure firmware updates. Typically, this is implemented by writing a signed update to a staging area, where the firmware picks it up during the next boot, verifies it, and then proceeds to overwrite the actual firmware. However, this process is still far from foolproof and firmware updates still can make devices unusable, requiring a firmware replacement.

Розділ 3. Реалізація Secure Boot UEFI

Реалізацією механізмів Secure Boot у Fedora передбачено два способи завантаження. У межах першого способу використано службу підписування, супровід якої здійснює корпорація Microsoft, з метою надання копії завантажувача shim, підписаного ключами Microsoft. Другий спосіб є узагальненою формою першого, у якого межах користувачем або групою користувачів може бути створено власні ключі, які може бути додано до мікрокоду системи і використано для підписування власних двійкових файлів.

3.1. Ключі

Рішення зі службою підписування Microsoft було вибрано через простоту. Використаний Microsoft ключ постачається з усім відомим обладнанням, отже Fedora зможе завантажуватися на цьому обладнанні без жодних проблем. Звичайно ж, існують певні ризики у використанні сторонньої служби. Fedora Project вважає за потрібне ретельно стежити за тенденціями у цьому питанні і надасть адекватну відповідь на будь-яку нову інформацію.
Використання ключів у реалізації для Fedora є доволі складним. Ось, у який спосіб виконується підписування різноманітних компонентів системи.
Shim: цей компонент підписується службою підписування UEFI. Ми не контролюємо цей ключ. shim містить відкритий ключ служби сертифікації Fedora Boot.
GRUB: його підписано ключем «Fedora Boot Signer», який походить від ключа служби сертифікації Fedora Boot. У GRUB не міститься ніяких ключів, для перевірки завантажувача викликається shim.
Ядро: цей компонент також підписано ключем Fedora Boot. У ядрі міститься відкрита частина ключа, що використовується для підписування модулів ядра.
Модулі ядра: ці компоненти підписуються закритим ключем, який створюється під час їхнього збирання. Цей ключ ніде не зберігається. Під час кожного збирання ядра система створює новий ключ.
Ключ служби сертифікації Secure Boot Fedora використовується для перевірки цілісності GRUB і ядра. Відкритий ключ можна знайти у пакунку з кодом shim. Параметри ключа є такими:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2574709492 (0x9976f2f4)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Fedora Secure Boot CA
        Validity
            Not Before: Dec  7 16:25:54 2012 GMT
            Not After : Dec  5 16:25:54 2022 GMT
        Subject: CN=Fedora Secure Boot CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ae:f5:f7:52:81:a9:5c:3e:2b:f7:1d:55:f4:5a:
                    68:84:2d:bc:8b:76:96:85:0d:27:b8:18:a5:cd:c1:
                    83:b2:8c:27:5d:23:0a:d1:12:0a:75:98:a2:e6:5d:
                    01:8a:f4:d9:9f:fc:70:bc:c3:c4:17:7b:02:b5:13:
                    c4:51:92:e0:c0:05:74:b9:2e:3d:24:78:a0:79:73:
                    94:c0:c2:2b:b2:82:a7:f4:ab:67:4a:22:f3:64:cd:
                    c3:f9:0c:26:01:bf:1b:d5:3d:39:bf:c9:fa:fb:5e:
                    52:b9:a4:48:fb:13:bf:87:29:0a:64:ef:21:7b:bc:
                    1e:16:7b:88:4f:f1:40:2b:d9:22:15:47:4e:84:f6:
                    24:1c:4d:53:16:5a:b1:29:bb:5e:7d:7f:c0:d4:e2:
                    d5:79:af:59:73:02:dc:b7:48:bf:ae:2b:70:c1:fa:
                    74:7f:79:f5:ee:23:d0:03:05:b1:79:18:4f:fd:4f:
                    2f:e2:63:19:4d:77:ba:c1:2c:8b:b3:d9:05:2e:d9:
                    d8:b6:51:13:bf:ce:36:67:97:e4:ad:58:56:07:ab:
                    d0:8c:66:12:49:dc:91:68:b4:c8:ea:dd:9c:c0:81:
                    c6:91:5b:db:12:78:db:ff:c1:af:08:16:fc:70:13:
                    97:5b:57:ad:6b:44:98:7e:1f:ec:ed:46:66:95:0f:
                    05:55
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Authority Information Access:
                CA Issuers -
URI:https://fedoraproject.org/wiki/Features/SecureBoot

            X509v3 Authority Key Identifier:
                keyid:FD:E3:25:99:C2:D6:1D:B1:BF:58:07:33:5D:7B:20:E4:CD:96:3B:42

            X509v3 Extended Key Usage:
                Code Signing
            X509v3 Subject Key Identifier:
                FD:E3:25:99:C2:D6:1D:B1:BF:58:07:33:5D:7B:20:E4:CD:96:3B:42
    Signature Algorithm: sha256WithRSAEncryption
         37:77:f0:3a:41:a2:1c:9f:71:3b:d6:9b:95:b5:15:df:4a:b6:
         f4:d1:51:ba:0d:04:da:9c:b2:23:f0:f3:34:59:8d:b8:d4:9a:
         75:74:65:80:17:61:3a:c1:96:7f:a7:c1:2b:d3:1a:d6:60:3c:
         71:3a:a4:c4:e3:39:03:02:15:12:08:1f:4e:cd:97:50:f8:ff:
         50:cc:b6:3e:03:7d:7a:e7:82:7a:c2:67:be:c9:0e:11:0f:16:
         2e:1e:a9:f2:6e:fe:04:bd:ea:9e:f4:a9:b3:d9:d4:61:57:08:
         87:c4:98:d8:a2:99:64:de:15:54:8d:57:79:14:1f:fa:0d:4d:
         6b:cd:98:35:f5:0c:06:bd:f3:31:d6:fe:05:1f:60:90:b6:1e:
         10:f7:24:e0:3c:f6:33:50:cd:44:c2:71:18:51:bd:18:31:81:
         1e:32:e1:e6:9f:f9:9c:02:53:b4:e5:6a:41:d6:65:b4:2e:f1:
         cf:b3:b8:82:b0:a3:96:e2:24:d8:83:ae:06:5b:b3:24:74:4d:
         d1:a4:0a:1d:0a:32:1b:75:a2:96:d1:0e:3e:e1:30:c3:18:e8:
         cb:53:c4:0b:00:ad:7e:ad:c8:49:41:ef:97:69:bd:13:5f:ef:
         ef:3c:da:60:05:d8:92:fc:da:6a:ea:48:3f:0e:3e:73:77:fd:
         a6:89:e9:3f
Рисунок 3.1. Сертифікат X.509 Fedora для підписування ядра і GRUB

3.2. Shim

У Fedora використано завантажувач першого етапу, який називається shim і містить самопідписаний сертифікат CA. Цей сертифікат використовується для перевірки завантажувача GRUB 2 (версія UEFI, програма PE/COFF, підписана за допомогою AuthentiCode). До завантаження ядра GRUB 2 звертається до shim для перевірки підпису AuthentiCode ядра.
Окрім ключа Microsoft, у shim також передбачено підтримку додаткових довірених сертифікатів, наданих власником, і механізм вимикання перевірки підписів. Дані зберігаються у змінних UEFI, які не можна перезаписати після завантаження операційної системи. Shim містить засоби перевірки фізичної наявності і проситиме підтвердження до оновлення параметрів, що зберігаються у цих змінних UEFI.
У Fedora shim складається з двох пакунків. Пакунок з назвою «shim» є результатом збирання коду, з якого складається shim. Цей пакунок не завантажуватиме систему, оскільки його ще не підписано. Результати збирання пакунка shim підписуються, а потім включаються до пакунка shim-signed. У пакунку shim-signed міститься підписаний виконуваний файл, який може завантажувати систему.
У пакунку shim також міститься «чорний список відомих скомпрометованих ключів та виконуваних файлів, які не можна завантажувати. «Чорний» список зберігається у файлі з назвою dbx.esl, цей файл є частиною пакунка shim. У поточній реалізації «чорний» список вбудовується до виконуваного файла shim під час його збирання. Цей список призначено для запобігання завантаженню версії GRUB з відомими вразливостями. У майбутніх версіях цей список може бути пересунуто до пам’яті UEFI. У поточній реалізації оновлення «чорного» списку не надаватиме вам ніякого додаткового захисту, оскільки можна повернутися до попередньої версії shim і уникнути оновлення «чорного» списку. Якщо «чорний» список зберігатиметься у BIOS, його не можна буде змінити поверненням до попередньої версії shim.
Крім того, існує «чорний» список, супровід якого здійснює Microsoft. Цей список зберігається у BIOS для перевірки. Microsoft надаватиме цей список Fedora Project для включення до дистрибутива. Це може призвести до періодичних оновлень пакунка shim-signed, під час яких виконуваний файл shim не змінюватиметься. У поточній версії немає цього файла, оскільки жодних ключів ще не скомпрометовано. Ймовірно, цей «чорний» список буде включено до окремого пакунка, щоб уникнути оновлень пакунка shim-signed.
Дані «чорного списку» мають надходити від Microsoft. Fedora Project не оновлюватимемо «чорний список» самостійно. Дані підписано ключем Microsoft, що запобігає оновленню цього списку сторонніми особами. Microsoft заявляла, що цей «чорний список» використовується лише для запобігання завантаженню за допомогою скомпрометованих ключів та відомих вразливостей системи.
У разі використання обох методів завантаження shim, GRUB і ядро виявлятимуть, що їх запущено у режимі, який у UEFI називається «режим користувача», з увімкненим Secure Boot Після виявлення запуску у відповідному режимі програми виконуватимуть перевірку можливості виконання подальших дій за допомогою особливого відкритого ключа шифрування Fedora. Перевірка для GRUB здійснюватиметься за допомогою shim, потім GRUB викликатиме shim для перевірки ядра. Щойно ядро буде завантажено, його код також виявить, що запуск здійснюється у режимі Secure Boot, а отже слід забезпечити виконання таких умов:
командний рядок завантаження містить лише певний обмежений набір параметрів ядра;
під час завантаження модулів ядра перевірятимуться підписи, модулі не завантажуватимуться, якщо їх не підписано або підписано ключем, якого немає у змінних сховища ключів UEFI (див. зауваження);
забороняються всі дії з простору користувача, якщо спричинятимуть визначені для простору користувача DMA.
Додаткові дані щодо shim можна знайти у сховищі коду shim.

Зауваження

Іншими дистрибутивами було вибрано спосіб реалізації Secure Boot, який не передбачає підписування модулів ядра. Розробники Fedora вважають, щоб без повної підтримки можливостей Secure Boot, його реалізація позбавлена сенсу. Розробники Fedora працюють на тим, щоб зменшити негативні наслідки такого рішення, водночас забезпечивши неможливість виконання коду потенційно небезпечних непідписаних модулів.

3.3. GRUB

Дані GRUB містяться у пакунку grub2. Ці дані підписано ключем служби сертифікації Fedora. Після проходження криптографічної перевірки виконуваний файл GRUB буде виконано shim. У пакунку GRUB не міститься даних ключів. У разі потреби у перевірці цілісності ядра GRUB звертатиметься до shim, shim і виконуватиме саму перевірку.

3.4. Ядро

Ядро підписано ключем служби сертифікації Fedora, shim виконуватиме його перевірку до того, як GRUB дозволить його виконання. Модулі ядра підписано ключем, який створюється під час збирання ядра, а потім знищується.
Ядро імпортуватиме базу даних ключів UEFI і використовуватиме її для виконання перевірки модулів ядра. Це означає, що сторонні модулі, підписані ключем, який вважається надійним UEFI (Microsoft), завантажуватимуться ядром, якщо увімкнено Secure Boot.

Важливе

Варто зауважити, що після завантаження ядром початкового образу (initrd) у пам’ять виконання програм вже не можна вважати довіреним. Хоча initrd може містити підписані модулі ядра, там також може міститися непідписаний код користувача. Цілісність цього коду не можна гарантувати.

3.4.1. Обмеження

Ці обмеження введено з метою повної сумісності зі стандартами Secure Boot. Ці стандарти вимагають заборону виконання будь-якого неперевіреного коду на рівні супервізора системи. Більшість користувачів не помітить ніяких змін, оскільки пакунки, якими користується ця більшість і які потребують доступу до заборонених ресурсів системи, було виправлено, — вони працюють з новими механізмами захисту. Втім, у поточній реалізації є декілька служб або можливостей, які не працюватимуть на комп’ютері з увімкненим Secure Boot. Серед них такі:
kexec/kdump
присипляння (сон зі збереженням на диск)
робота сторонніх модулів, які не підписано або підписано невідомим ключем
зондування ядра systemtap (та kprobes)

Зауваження

У майбутніх версіях підтримки Secure Boot може бути реалізовано підтримку вказаних вище можливостей, але реалізувати ці можливості протягом приготування до випуску Fedora 18 все ж не вдалося. Якщо вам потрібна підтримка якоїсь з цих можливостей, вам слід вимкнути Secure Boot.

Важливе

У поточній версії shim у Fedora підписано ключем, який діятиме до жовтня 2013 року, тобто строк підтримки Fedora 18 ще не буде вичерпано до настання завершення строку дії ключа. Нам не відоме обладнання, на якому перевіряється строк дії ключів, але появу такого обладнання не можна виключати. Використаний строк дії було визначено Microsoft під час надання підпису. Fedora не може його змінювати. Ми знаємо про цю ваду і сподіваємося усунути її у майбутньому.

Розділ 4. Інструменти

Для того, щоб Fedora могла працювати з мікрокодом UEFI Secure Boot, розроблено декілька інструментів.

4.1. Shim

Shim — підписане у криптографічний спосіб програмне забезпечення, яке забезпечує роботу проміжного шару захисту між мікрокодом UEFI та GRUB і програмним забезпеченням ядра. Shim має криптографічний підпис від Verisign (Microsoft), отже мікрокод UEFI розпізнає систему Fedora і надасть змогу програмному забезпеченню виконати процедуру її завантаження. Shim перевіряє GRUB і ядро за допомогою криптографічних методів, заснованих на ключі Fedora, використаному для підписування всіх трьох компонентів.

4.2. Pesign

Pesign надає змогу користувачам створювати власні версії shim і використовувати власні криптографічні ключі. За допомогою цього інструмента ви можете створити власні моделі захисту без потреби у використанні моделі захисту Microsoft. Щойно користувачем буде створено власні ключі і підписано shim і, якщо потрібно, підписаний і зібраний GRUB та kernel, він зможе скористатися режимом налаштування у мікрокоді для встановлення Fedora і використатися інструмент sbsetup, який є частиною pesign, для реєстрації ключів у мікрокоді.

4.3. EFIKeyGen

4.4. sign-file

Розділ 5. Використання ваших власних ключів

5.1. Створення ключів

5.2. Створення ключів для збирання shim

5.3. Пакунки, які потребують перезбирання

5.4. Реєстрація ваших ключів у мікропрограмі

Журнал версій

Опис змін
Версія 18.4Tue 11 March 2013Eric Christensen
Додано пояснення щодо деяких дій.
Версія 18.3Tue 19 February 2013Eric Christensen
Включено дані зі сховища даних Флоріана.
Додано ілюстрації.
Версія 18.2Wed 06 February 2013Eric Christensen
До всіх розділів додано дані щодо відкритих ключів.
Версія 18.1Fri 04 January 2013Eric Christensen
Оновлено главу «Для чого призначено Secure Boot». (Повідомлення про ваду 891758)
Оновлено главу «Реалізація». (Повідомлення про ваду 891924)
Оновлено адресу електронної пошти Josh Boyer. (Повідомлення про ваду 891932)
Версія 0Thu Jul 12 2012Eric Christensen
Початкове створення книги за допомогою Publican

Покажчик

Символи

зворотний зв'язок
контактна інформація стосовно цього посібника, Нам потрібні ваші відгуки!
ключі
Fedora Secure Boot CA
відкритий ключ, Ключі
GRUB, Ключі
shim, Ключі
строк дії
Fedora 18, Обмеження
ядро, Ключі
ядро
ключ, Ключі
цілісність, Ключі

E

EFIKeyGen
визначення, EFIKeyGen

F

Fedora Secure Boot CA, Ключі

G

GRUB
ключ, Ключі
цілісність, Ключі

P

pesign
definition, Pesign
sbsetup, Pesign

S

Secure Boot
«чорний» список, Shim
ключі, Ключі
(див. також ключі)
обмеження, Обмеження
реалізація, Реалізація Secure Boot UEFI
shim
визначення, Shim
ключ, Ключі
пояснення, Shim
sign-file
визначення, sign-file