Про безпеку UEFI, заключна частина

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

Якщо вам цікаво, чим безпеки прошивки можуть допомогти STM, SGX PSP — чекаю вас під катом.

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

Частина сьома. Технології майбутнього

Незважаючи на те, що всі описувані далі технології вже давно представлені офіційно, розповідати про них я все одно буду як про можливості завтрашнього дня, з доволі прозаїчної причини — навіть у такій бистроразвівающейся середовищі як UEFI від подання якийсь технології її впровадження можуть пройти роки (досить згадати PFAT, що з'явилася ще в Haswell, але не впроваджену толком досі).

Про SGX і STM я вже згадував в кінці третьої частини, тому почну розповідь з PSP, яким тепер без варіантів комплектуються всі нові APU AMD.

AMD Platfrom Security Processor
Спостерігаючи за успіхами Intel Management Engine, яким останні 5 років обладнаний кожен чіпсет і SoC Intel, AMD теж вирішили не відставати від прогресу і вбудувати в свої SoC'і чого-небудь такого.

Ще б — хочеться мати апаратний корінь довіри, хочеться нормальний генератор випадкових чисел, хочеться криптоускоритель і емулятор TPM 2.0, загалом — багато всього хочеться, і реалізувати це все не важко — купи IP Core якого-небудь постачальника, напиши до нього прошивку і навесь на нього побільше системних функцій, щоб користувач твоєї платформи навіть не здумав відключити те, за що стільки грошей уплочено.

У підсумку IP Core купили ядро ARM Cortex-A5 з підтримкою технології TrustZone, для емуляції TPM 2.0 придбали у Trustonic код TEE, решта реалізували самі і представили отриманий SoC-всередині-SoC'а в 2013 році на черговому UEFI Plugfest.


Оригінальна схема PSP, про емуляцію TPM мови тоді ще не йшло.

Для забезпечення безпеки UEFI цей самий PSP надає наступне: підсистему HVB, внутрішнє сховище для S3 BootScript, емулятор TPM для реалізації Measured Boot, генератор випадкових чисел і прискорювач криптографічних операцій.

Hardvare Validated Boot
Про цю технологію я вже розповідав в першої частини, тепер розповім більш докладно. Суть її проста — PSP отримує управління до старту BSP і перевіряє, щоб вміст другої стадії його прошивки і стартового коду не було змінено, у разі успіху BSP стартує з ResetVector'а та машина завантажується як зазвичай, а в разі невдачі користувачеві показують код помилки на POST-кодері, а BSP крутить мертвий цикл до hard reset'а, після якого все повторюється заново.

HVB, таким чином, є апаратним коренем довіри для системи, але захищає ця технологія тільки PEI-те, перевірка ж всього іншого — на совісті авторів прошивки.


Оригінальна схема AMD HVB

За замовчуванням HVB відключений на всіх платформах і для включення необхідна досить нетривіальне його конфігурування, тому я поки що і сам не відчував технологію на практиці (хоча безпосередньо працюю з прошивками для другого покоління процесорів з PSP), і машин з включеним HVB на відкритому ринку не бачив.

Integrated TPM 2.0
До релізу Windows 10 робоча група TCG підготувала цікаве нововведення: замість використовувався раніше інтерфейсу TIS для взаємодії з модулями TPM тепер можна використовувати виклики ACPI, що дозволяє виробникам процесорів реалізувати TPM не на зовнішньому чіпі, а прямо в чіпсеті, та ще й половину реалізації зробити програмної. Таке рішення має як переваги (замінити чіпсет складніше, ніж чіп TPM в корпусі SSOP-28), так і недоліки (vendor lock-in), але реалізували його на даний момент і Intel (Skylake) і AMD (в APU з PSP). Стандарт TPM 2.0 підтримується обома рішеннями не цілком, а лише настільки, щоб система з вбудованим TPM могла використовувати BitLocker і отримати сертифікат Windows 10 Ready. Тим не менше, тепер полку користувачів TPM однозначно прибуде. Разом з вбудованим TPM з'явилися також апаратний генератор випадкових чисел і криптоускоритель, які, при бажанні, можна використовувати окремо.

Secure S3 BootScript Storage
Ще одна фішка PSP — вбудований NVRAM, в якому можна безпечно зберігати якісь дані користувача. На даний момент AMD зберігає туди S3 BootScript, що добре захищає систему від атак на нього. При цьому трохи страждає час виходу з S3, але зайві 50-100 мс заради безпеки цілком можна терпіти.

На жаль, в AMD з відкритою документацією на PSP дуже сумно, тому дати корисних посилань не можу, все, що міг розповісти без порушення NDA — вже розповів.

Intel Software Guard Extensions
Повернемося тепер до технологій Intel. Про SGX почали говорити близько року тому, але для кінцевого користувача вона стала доступна всього кілька тижнів тому, коли Intel включила її для процесорів Skylake в чергове оновлення мікрокоду. SGX — це новий набір інструкцій, що дозволяють додаткам створювати т. н. «анклави», тобто регіони пам'яті для коду та даних, апаратно захищені від доступу ззовні, навіть якщо цей доступ проводиться з більш привілейованих режимів виконання зразок ring 0 і SMM.

Технологія досить складна для розуміння і використання (майже 200 сторінок Programming Reference), але потенційно дуже потужна, тому Intel почала займатися її просуванням.


Принципова схема роботи SGX, один з понад 200 слайдів ось цієї презентації, вона ж у вигляді 80-хвилинного відео.

Intel називає SGX «зворотного пісочницею», тобто замість того, щоб намагатися ізолювати потенційно шкідливе або недоверенное, за допомогою SGX програма може ізолювати себе від решти світу. Ідея схожа з ARM TrustZone, але якщо у ARM світ ділиться на звичайний і довірений і вони виконуються на різних ядрах, взаємодіючи тільки через виклик інструкції SMC, то у Intel ядро одне і те ж, зате пам'ять ділиться звичайну і безпечну:


Безпечний анклав посеред звичайної пам'яті.

Моє ставлення до цієї технології поки ще не сформувалося — я її просто ще не пробував, т. к. не працюю над Skylake в даний момент. Тим не менш, намагаюся не відставати від прогресу надто сильно, тому читаю краєм вуха все, що пишуть про SGX, наприклад:
Портал про SGX на сайті Intel.
Оглядова лекція про SGX з сайту Дармштадтського Технічного Університету.
Оглядова стаття NccGroup з купою цікавих посилань.
Відкрита платформа для написання свого коду для SGX.
І взагалі,весь розділ про SGX на firmwaresecury.com.

Intel SMI Transfer Monitor
Друга технологія Intel, про яку я вже згадував — STM. Перші згадки про нього датовані 2009 роком, і після 6 років розробки технологія нарешті була представлена в серпні 2015. Суть її проста: замість диспетчера SMM в SMRAM запускається гіпервізор, і всі обробники SMI виконуються в виртуализованном оточенні, що дозволяє заборонити їм шкідливі дії на кшталт зміни даних в пам'яті ядра і тому подібні.


Слайд з презентації STM на IDF2015

Технологія дозволяє значно зменшити як «поверхня атаки» на обробники SMM, так і руйнівність наслідків злому обробників SMI. Приміром, заборонивши доступ до MMIO чіпсету для всіх фінансових посередників, крім використовуваного для оновлення прошивки, можна захистити її від інших обробників, шлях навіть вони зламані атакуючим і він має можливість виконати в них довільний код.
Найголовніша перевага — невибагливість, для роботи STM потрібні тільки включені VT-x/AMDV і правильні настройки рівнів доступу. На даний момент попередня підтримка STM реалізована в EDK2 тільки для тестової плати MinnowBoard Max, але в найближчі півроку-рік IBV адаптують її для своїх платформ, і злому SMM можна буде побоюватися набагато менше. Зрозуміло, що безоплатної безпеки не буває, і STM вносить додаткову складність в отже не найпростіший процес ініціалізації SMM, плюс обробка SMI займає більше часу (страшніше, насправді, те, що воно займає ще більш невизначений час, знову страждають користувачі жорстких ОСРЧ), плюс віртуалізацію невчений користувач платформи може відключити і STM не вийде використовувати в таких умовах. Тим не менш, я потикав в STM гілкою на MinnowBoard і можу сказати: чим швидше IBV запровадять її — тим краще.

Додаткова інформація для бажаючих:
Пост Вінсента Циммера з анонсом STM.
Портал про STM на сайті Intel, з корисними посиланнями.

Висновок

Ну ось і підійшов до кінця цей цикл статей, сподіваюся читачеві було цікаво.
Технології розвиваються швидко, і якщо завтра з'явиться якась новітня технологія (або знайдуть зяючу діру в існуючих) — постараюся про них написати.

В наступній статті буде приборкувати SecureBoot — згенеруємо свої ключ PK і KEK, а параноїки зможуть заборонити завантаження будь-яких речей, не підписаних їх ключами. Дякую за увагу.

p.s. Обіцяв в останній частині підсумкову таблицю, але не зміг у неї. Кодити — можу, писати по-російськи — туди-сюди, красиво розмічати таблиці — не виходить кам'яна квітка. Прошу щирої пардону.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.