Підручник з uefi secure...

Fedora 18

Підручник з UEFISecure Boot

Josh Boyer

Kevin Fenzi

Peter Jones

Josh Bressers

Florian Weimer

Підручник з UEFI Secure Boot Чернетка

Fedora 18 Підручник з UEFI Secure BootВидання 18.4

Автор Josh Boyer [email protected]Автор Kevin Fenzi [email protected]Автор Peter Jones [email protected]Автор Josh Bressers [email protected]Автор Florian Weimer [email protected] Eric Christensen [email protected]

Copyright © 2012-2013 Fedora Project Contributors.

The text of and illustrations in this document are licensed by Red Hat under a Creative CommonsAttribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is availableat 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 withCC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for theoriginal 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 InfinityLogo, 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 Statesand/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and othercountries.

All other trademarks are the property of their respective owners.

mailto:[email protected]






http://creativecommons.org/licenses/by-sa/3.0/

https://fedoraproject.org/wiki/Legal:Trademark_guidelines

https://fedoraproject.org/wiki/Legal:Trademark_guidelines

Чернетка Чернетка

iii

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

1.1. Типографічні стилі ............................................................................................... v1.2. Умовне позначення цитування ........................................................................... vi1.3. Примітки та попередження ................................................................................ vii

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

1. Для чого призначено UEFI Secure Boot? 11.1. UEFI Secure Boot ........................................................................................................ 11.2. Вимоги Microsoft щодо Secure Boot ............................................................................. 2

1.2.1. Подробиці щодо реалізації ............................................................................... 31.3. Secure Boot у Fedora .................................................................................................. 71.4. Від чого Secure Boot може вас захистити? ................................................................. 71.5. Потенційні ризики щодо використання Secure Boot ..................................................... 8

1.5.1. Примусове обмеження можливостей у режимі Secure Boot .............................. 81.5.2. Перенесення системи і Secure Boot ................................................................. 91.5.3. Не передбачено інфраструктури ініціалізації, окрім Microsoft Windows .............. 91.5.4. Не перевірені процедури відкликання сертифікації .......................................... 9

2. System Configuration 112.1. Entering the UEFI firmware ......................................................................................... 112.2. Disabling UEFI Secure Boot ....................................................................................... 122.3. Enabling Microsoft Secure Boot .................................................................................. 142.4. Known issues ............................................................................................................. 16

3. Реалізація Secure Boot UEFI 173.1. Ключі ......................................................................................................................... 173.2. Shim .......................................................................................................................... 193.3. GRUB ........................................................................................................................ 203.4. Ядро ......................................................................................................................... 20

3.4.1. Обмеження ..................................................................................................... 20

4. Інструменти 234.1. Shim .......................................................................................................................... 234.2. Pesign ....................................................................................................................... 234.3. EFIKeyGen ................................................................................................................ 234.4. sign-file ...................................................................................................................... 23

5. Використання ваших власних ключів 255.1. Створення ключів ...................................................................................................... 255.2. Створення ключів для збирання shim ....................................................................... 255.3. Пакунки, які потребують перезбирання ..................................................................... 255.4. Реєстрація ваших ключів у мікропрограмі ................................................................. 25

A. Журнал версій 27

Покажчик 29


v

Preface

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

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

1.1. Типографічні стиліДля привернення уваги до певних частин тексту використано чотири типографічних стилів.Нижче наведено опис цих стилів та обставин, за яких їх застосовують.

Моноширинний жирний

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

Щоб переглянути вміст файла my_next_bestselling_novelу поточному каталозі, введіть у командному рядку команду catmy_next_bestselling_novel та натисніть Enter, щоб наказати системівиконати команду.

У наведеному вище прикладі вказано назву файла, команду оболонки та назву клавіші, якіпозначено моноширинним жирним шрифтом.

Для відокремлення клавіш у складі комбінацій клавіш використовується знак дефіса. Приклад:

Щоб виконати команду, натисніть Enter.

Для перемикання на перший віртуальний термінал натисніть Ctrl+Alt+F2. Щобповернутись до вікна сеансу X-Window, натисніть Ctrl+Alt+F1.

У першому прикладі позначено назву окремої клавіші. У другому — дві комбінації клавіш (кожнає сукупністю трьох клавіш, які слід натискати одночасно).

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

До класів для роботи з файлами належать: filesystem — клас для роботи зфайловою системою, file — для роботи з файлами, та dir — для роботи зкаталогами. З кожним класом пов'язаний власний набір прав доступу.

Пропорційний жирний

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

1 https://fedorahosted.org/liberation-fonts/

https://fedorahosted.org/liberation-fonts/



Preface Чернетка

vi

Щоб запустити програму Параметри миші, виберіть у головному меню Система> Параметри > Миша. Щоб зробити головною кнопкою праву кнопку миші,замість лівої, на вкладці Кнопки, позначте пункт Під ліву руку і натисніть накнопку Закрити (це зробить мишу зручною для використання лівою рукою).

Щоб вставити спеціальний символ у файлі gedit, у головному меню виберітьПрограми > Стандартні > Таблиця символів. Потім, виберіть Пошук >Знайти… у меню Таблиця символів, введіть назву символу у полі Пошук танатисніть Наступний. Символ, який ви шукаєте, буде позначено у полі Таблицясимволів. Двічі клацніть на позначеному символі, щоб помістити його у полеТекст для копіювання, а потім натисніть кнопку Копіювати. Тепер повернітьсяназад до вашого документа і скористайтеся пунктом меню Правка > Вставитиgedit.

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

Моноширинний жирний курсив або Пропорційний жирний курсив

Обидва стилі означають текст, який треба замінити чи змінний текст. Курсив вказує, що текст неслід вводити дослівно, а змінити його залежно від параметрів. Приклад:

Щоб з'єднатись з віддаленим комп'ютером через ssh, введіть у командномурядку ssh ім'я_користувача@назва.домену. Наприклад, якщо назвавіддаленого комп'ютера example.com а назва облікового запису john, введітьssh [email protected].

Команда mount -o remount файлова_система повторно монтує файловусистему. Наприклад, для повторного монтування файлової системи /home, слідвказати команду mount -o remount /home.

Щоб побачити версію встановленого пакету, скористайтеся командою rpm -qпакунок. Вона поверне результат у вигляді: пакунок-версія-випуск.

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

Також курсивом позначається перше використання нового та важливого терміну. Приклад:

Publican — це система публікації документів, заснована на DocBook.

1.2. Умовне позначення цитуванняВиведені у терміналі дані або початкові коди програми виокремлюються з навколишнього тексту.

Текст, що виводиться на термінал, також позначається моноширинним прямим шрифтом:

books Desktop documentation drafts mss photos stuff svnbooks_tests Desktop1 downloads images notes scripts svgs

Для текстів програм також застосовується моноширинний шрифт, але додається позначеннясинтаксичних конструкцій:

package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

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

vii

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

http://bugzilla.redhat.com/bugzilla/

http://bugzilla.redhat.com/bugzilla/

Preface Чернетка

viii

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


1

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

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

1.1. UEFI Secure BootUEFI Secure Boot — компонент перевірки шляхів завантаження у специфікації UEFI (UnifiedExtensible 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” показано типовеповідомлення про помилку.) Так само, засоби встановлення операційної системи безкриптографічно коректного підпису не можна буде запустити, у відповідь на запуск таких засобівбуде лише показано повідомлення про помилку. Користувачі не зможуть скасувати рішеннязавантажувача щодо відмови у визнанні підпису, на відміну від ситуації з сертифікатами серверіву інтернеті. Крім того, користувачі не матимуть доступу до даних щодо видавця сертифіката.

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

2

┌────────── 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 загалом увімкнено лише на клієнтських пристроях, йогоне рекомендується використовувати на серверних комп’ютерах. Вважається, що SecureBoot стане частиною серверних технологій майбутнього.

1.2. Вимоги Microsoft щодо Secure BootMicrosoft оприлюднено доволі обмежені дані щодо реалізованої компанією версії 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 і яку не можна реалізувати безпечно без додаткової підтримки з

Чернетка Подробиці щодо реалізації

3

боку обладнання. Також подібні обмеження має бути пов’язано з обов’язковістю використанняUEFI Secure Boot.

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

1.2.1. Подробиці щодо реалізаціїВимогами Microsoft передбачено, що всі клієнтські персональні комп’ютери, на яких розміщенологотип Windows 8, має бути увімкнено UEFI Secure Boot і встановлено надані Microsoft ключі.Потрібний для роботи сертифікат X.509 наведено у розділі Рисунок 1.2, “Довірений сертифікатX.509 Microsoft для реалізації Secure Boot від цієї компанії”. Постачальники обладнаннязаохочуються до включення інших кореневих сертифікатів, якщо це потрібно, втім, ця вимога неє обов’язковою до виконання.


4

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+gAwIBAgIKYQd2VgAAAAAACDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEyMDAGA1UEAxMpTWljcm9zb2Z0IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIwMTAwHhcNMTExMDE5MTg0MTQyWhcNMjYxMDE5MTg1MTQyWjCBhDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEuMCwGA1UEAxMlTWljcm9zb2Z0IFdpbmRvd3MgUHJvZHVjdGlvbiBQQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN0Mu6LkLgnj58X3lmm8ACG9aTMz760Ey1SA7gaDu8UghNn30ovzOLCrpK0tfGJ5Bf/jSj8ENSBw48Tna+CcwDZ16Yox3Y1w5dw3tXRGlihbh2AjLL/cR6Vn91EnnnLrB6bJuR47UzV85dPsJ7mHHP65ySMJb6hGkcFuljxB08ujP10Cak3saR8lKFw2//1DFQqU4Bm0z9/CEuLCWyfuJ3gwi1sqCWsiiVNgFizAaB1TuuxJ851hjIVoCXNEXX2iVCvdefcVzzVdbBwrXM68nCOLb261Jtk2E8NP1ieuuTI7QZIs4cfNd+iqVE73XAsEh2W0QxiosuBtGXfsWiT6SAMCAwEAAaOCAUMwggE/MBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBSpKQI5jhbEl3jNkPmeT5rhfFWvUzAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTV9lbLj+iiXGJo0T2UkFvXzpoYxDBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNSb29DZXJBdXRfMjAxMC0wNi0yMy5jcmwwWgYIKwYBBQUHAQEETjBMMEoGCCsGAQUFBzAChj5odHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY1Jvb0NlckF1dF8yMDEwLTA2LTIzLmNydDANBgkqhkiG9w0BAQsFAAOCAgEAFPx8cVGlecJusu85Prw8Ug9uKz8QE3P+qGjQSKY0TYqWBSbuMUaQYXnW/zguRWv0wOUouNodj4rbCdcax0wKNmZqjOwb1wSQqBgXpJu54kAyNnbEwVrGv+QEwOoW06zDaO9irN1UbFAwWKbrfP6Up06O9Ox8hnNXwlIhczRa86OKVsgE2gcJ7fiL4870fo6u8PYLigj7P8kdcn9TuOu+Y+DjPTFlsIHl8qzNFqSfPaixm8JC0JCEX1Qd/4nquh1HkG+wc05Bn0CfX+WhKrIRkXOKISjwzt5zOV8+q1xg7N8DEKjTCen09paFtn9RiGZHGY2isBI9gSpoBXe7kUxie7bBB8e6eoc0Aw5LYnqZ6cr8zko3yS2kV3wc/j3cuA9a+tbEswKFAjrqs9lu5GkhN96B0fZ1GQVn05NXXikbOcjuLeHN5EVzW9DSznqrFhmCRljQXp2Bs2evbDXyvOU/JOI1ogp1BvYYVpnUeCzRBRvr0IgBnaoQ8QXfun4sY7cGmyMhxPl4bOJYFwY2K5ESA8yk2fItuvmUnUDtGEXxzopcaz6rA9NwGCoKauBfR9HVYwoy8q/XNh8qcFrlQlkIcUtXun6DgfAhPPQcwcW5kJMOiEWThumxIJm+mMvFlaRdYtagYwggvXUQd30980W5n5efy1eAbzOpBM93pGIcWX4=-----END CERTIFICATE-----

Рисунок 1.2. Довірений сертифікат X.509 Microsoft для реалізації Secure Boot від цієї компанії

Чернетка Подробиці щодо реалізації

5

Очікується, що 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”) з кореневим сертифікатом MicrosoftCorporation Third Party Marketplace Root.

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

Сторонні завантажувачі UEFI можуть не працювати у системах з Microsoft Secure Boot,оскільки потрібні для їхньої роботи сертифікати не є частиною специфікації Microsoft SecureBoot.


6

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/igAwIBAgIKYQjTxAAAAAAABDANBgkqhkiG9w0BAQsFADCBkTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE7MDkGA1UEAxMyTWljcm9zb2Z0IENvcnBvcmF0aW9uIFRoaXJkIFBhcnR5IE1hcmtldHBsYWNlIFJvb3QwHhcNMTEwNjI3MjEyMjQ1WhcNMjYwNjI3MjEzMjQ1WjCBgTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0aW9uIFVFRkkgQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKUIbEzHRQlqSwykwId/BnUMQwFUZOAWfwftkn0LsnO/DArGSkVhoMUWLZbT9Sug+01Jm0GAkDy5VP3mvNGdxKQYin9BilxZg2gyu4xHye5xvCFPmop8/0Q/jY8ysiZIrnW17slMHkoZfuSCmh14d00MsL32D9MW07z6K6VROF31+7rbeALb/+wKG5bVg7gZE+m2wHtAe+EfKCfJ+u9WXhzmfpR+wPBEsnk55dqyYotNvzhw4mgkFMkzpAg31VhpXtN87cEEUwjnTrAqh2MIYW9jFVnqsit51wxhZ4pb/V6th3+6hmdPcVgSIgQiIs6L71RxAM5QNVh2lQjuarGiAdUCAwEAAaOCAXYwggFyMBIGCSsGAQQBgjcVAQQFAgMBAAEwIwYJKwYBBAGCNxUCBBYEFPjBa7d/d1NK8yU3HU6hJnsPIHCAMB0GA1UdDgQWBBQTrb9DCb2CcJyM1U8xbtUimIob1DAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRFZlJD4X5YEb/WTp4jVQg7OiJqqDBcBgNVHR8EVTBTMFGgT6BNhktodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNDb3JUaGlQYXJNYXJSb29fMjAxMC0xMC0wNS5jcmwwYAYIKwYBBQUHAQEEVDBSMFAGCCsGAQUFBzAChkRodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY0NvclRoaVBhck1hclJvb18yMDEwLTEwLTA1LmNydDANBgkqhkiG9w0BAQsFAAOCAgEANQhC/zDMzvd2DK0QaFg1KUYydid87xJBJ0IbSqptgThIWRNV8+lYNKYWC4KqXa2C2oCDQQaPtB3yA7nzGl0b8VCQ+bNVhEIoHCC9sq5RFMXArJeVIRyQ2w/8d56Vc5GIyr29UrkFUA3fV56gYe0N5W0l2UAPF0DIzqNKwk2vmhIdCFSPvce8uSs9SSsfMvxqIWlPm8h+QjT8NgYXi48gQMCzmiV1J83JA6P2XdHnNlR6uVC10xLRB7+7dN/cHo+A1e0Y9C8UFmsv3maMsCPlx4TY7erBM4KtVksYLfFolQfNz/By8K673YaFmCwhTDMr8A9K8GiHtZJVMnWhaoJqPKMlEaTtrdcErsvYQFmghNGVTGKRIhp0HYw9Rw5EpuSwmzQ1sfq2U6gsgeykBXHInbi66BtEZuRHVA6OVn+znxaYsobQaD6QI7UvXo9QhY3GjYJfQaH0Lg3gmdJsdeS2abUhhvoH0fbiTdHarSx3Ux4lMjfHbFJylYaw8TVhahn1sjuBUFamMi3+oon5QoYnGFWhgspam/gwmFQUpkeWJS/IJuRBlBpcAj/lluOFWzw+P7tHFnJV4iUisdl75wMGKqP3HpBGwwAN1hmJ4w41J2IDcRWm79AnoKBZN2D4OJS44Hhw+LpMhoeU9uCuAkXuZcK2o35pFnUHkpv1prxZg1g=-----END CERTIFICATE-----

Рисунок 1.3. Сертифікат X.509 Microsoft для сторонніх програм UEFI

Чернетка Secure Boot у Fedora

7

Звичайного сертифіката для підписування недостатньо для гарантування завантаженняу системі з 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 BootUEFI. Обмеження на виконання коду у режимі ядра призводять до потреби у вимиканні деякихможливостей, див розділ Розділ 3.4.1, “Обмеження”.

1.4. Від чого Secure Boot може вас захистити?На базовому рівні UEFI Secure Boot запобігає запуску непідписаних завантажувачів. Результатизапуску завантажувача, звичайно ж, залежать від самого завантажувача. Наведені нижче даністосуються реалізації Secure Boot у Fedora. Реалізація Microsoft відрізняється від цієї реалізації,див. розділ Розділ 1.2, “Вимоги Microsoft щодо Secure Boot”.

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


8

міститься виконуваний код, завантаження підписано завантажувача Fedora може призвести добудь-яких результатів.

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

1.5. Потенційні ризики щодо використання Secure BootSecure 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 з метою надання вам інтерфейсу для реєстраціїсертифіката.

Чернетка Перенесення системи і Secure Boot

9


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

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

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

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

Правила видання Microsoft даних щодо відкликання сертифікатів залишаються незрозумілими.Потенційними причинами відкликання можуть бути неможливість досягнення потрібного рівнязахисту (тобто доведення можливості виконання непідписаного коду у лабораторних умовах)або використання вразливості у системі для компрометації шляху завантаження систем Windows8 поза межами лабораторій. Останній варіант також може стосуватися можливості обійти захистSecure Boot і завантажити непідписаний код після певних дій користувача.


11

System ConfigurationThis chapter describes how to configure systems for use with UEFI Secure Boot. The requiredsteps vary from system to system because they depend on how the firmware implements the UEFIspecification, 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 thoseboot loaders are not accepted by the new Secure Boot configuration because the signatures arenot recognized, your system will no longer boot after switching on Secure Boot.

2.1. Entering the UEFI firmwareWhen the system is booting, try pressing the Enter, Del, F1 or Esc keys. Usually, instructions willappear 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 canreboot 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 yoursystem or mainboard manual for password reset instructions.

Once you have entered the firmware, a screen similar to Рисунок 2.2, “UEFI firmware start screen” willbe shown.

Розділ 2. System Configuration Чернетка

12

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 BootSystems which come with Microsoft Windows 8 pre-installed typically have enabled UEFI SecureBoot, and ship the Microsoft keys in the firmware.

The Lenovo desktop system we use as an example makes disabling Secure Boot fairlystraightforward. 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 Securitytab”.

Чернетка Disabling UEFI Secure Boot

13

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 screenappears (Рисунок 2.4, “UEFI firmware Secure Boot settings”).


14

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 Enteragain.

The previous step only disables verification of cryptographic signatures, it does not remove somerestrictions Microsoft imposes on firmware settings. If you want to boot non-UEFI operating systems, itis necessary to disable the OS Optimized Defaults.

2.3. Enabling Microsoft Secure BootSystems which do not ship with Microsoft Windows 8 typically do not enable UEFI Secure Boot (or itsMicrosoft 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”.

Чернетка Enabling Microsoft Secure Boot

15

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 confirmationdialog will appear, and need to choose Yes. (See Рисунок 2.6, “UEFI firmware confirmation for OSOptimized Defaults”).


16

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 untilyou 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 Bootsettings”.

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 issuesWhen Fedora is installed on an UEFI system, existing boot loaders (for example, the code found inthe Master Boot Record) are not overwritten. Therefore, Fedora has considerably less control over theboot 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 temporarystartup device in Рисунок 2.1, “Firmware activation instructions”), the other operating system isstarted. This is not a problem with UEFI Secure Boot; on the affected systems, it also happens withSecure Boot disabled.

UEFI Secure Boot (and its Microsoft variant) require secure firmware updates. Typically, this isimplemented by writing a signed update to a staging area, where the firmware picks it up during thenext boot, verifies it, and then proceeds to overwrite the actual firmware. However, this process isstill far from foolproof and firmware updates still can make devices unusable, requiring a firmwarereplacement.


17

Реалізація 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. Параметри ключа є такими:

Розділ 3. Реалізація Secure Boot UEFI Чернетка

18

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

Чернетка Shim

19

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.

Розділ 3. Реалізація Secure Boot UEFI Чернетка

20

Додаткові дані щодо shim можна знайти у сховищі коду shim1.

Зауваження

Іншими дистрибутивами було вибрано спосіб реалізації 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присипляння (сон зі збереженням на диск)робота сторонніх модулів, які не підписано або підписано невідомим ключем

1 https://github.com/mjg59/shim

https://github.com/mjg59/shim

https://github.com/mjg59/shim

Чернетка Обмеження

21

зондування ядра systemtap (та kprobes)

Зауваження

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

Важливе

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


23

ІнструментиДля того, щоб 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


25

Використання ваших власних ключів

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

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

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

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


27

Додаток A. Журнал версійВерсія 18.4 Tue 11 March 2013 Eric Christensen

[email protected]

Додано пояснення щодо деяких дій.

Версія 18.3 Tue 19 February 2013 Eric [email protected]

Включено дані зі сховища даних Флоріана.Додано ілюстрації.

Версія 18.2 Wed 06 February 2013 Eric [email protected]

До всіх розділів додано дані щодо відкритих ключів.

Версія 18.1 Fri 04 January 2013 Eric [email protected]

Оновлено главу «Для чого призначено Secure Boot». (Повідомлення про ваду 891758)Оновлено главу «Реалізація». (Повідомлення про ваду 891924)Оновлено адресу електронної пошти Josh Boyer. (Повідомлення про ваду 891932)

Версія 0 Thu Jul 12 2012 Eric [email protected]

Початкове створення книги за допомогою Publican







29

Покажчик

Символизворотний зв'язок

контактна інформація стосовно цьогопосібника, vii

ключіFedora Secure Boot CA

відкритий ключ, 17GRUB, 17shim, 17строк дії

Fedora 18, 21ядро, 17

ядроключ, 17цілісність, 17

EEFIKeyGen

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

FFedora Secure Boot CA, 17

GGRUB

ключ, 17цілісність, 17

Ppesign

definition, 23sbsetup, 23

SSecure Boot

«чорний» список, 19ключі, 17

(див. також ключі)обмеження, 20реалізація, 17

shimвизначення, 23ключ, 17пояснення, 19

sign-fileвизначення, 23

Підручник з uefi secure...

Documents