В останні роки модулі TPM 2.0 перетворилися з апаратної загадки на звичайну частину будь-якого сучасного комп'ютера з UEFI та Secure Boot. У цій статті пояснюється, що таке /dev/tpm0 та /dev/tpmrm0, а також як використовувати tpm2_pcrread та tpm2_pcrextend. (а також його фактичну команду в tpm2-tools), а також пояснення того, як вони вписуються в політики вимірюваного завантаження, шифрування диска та підписаної PCR в Linux.
Корисна документація існує, але вона розкидана серед сторінок довідника systemd, записів вікі та дуже щільних публікацій; Тут ми зібрали всю ключову інформацію (PCR, практичні приклади, ризики та захист) щоб технічні спеціалісти, навіть якщо вони не є експертами з TPM, могли працювати з цими інструментами, не гублячись у незрозумілих деталях.
Що таке TPM 2.0 і чому це може вас цікавити
Модуль довіреної платформи (Trusted Platform Module) – це мікросхема безпеки, яка знаходиться на материнській платі (або всередині процесора, як-от fTPM/Intel PTT) і виконує роль безпечного сховища, генератора випадкових чисел і кореня довіри для системи. Він пасивний: якщо ви його не використовуєте, він нічого не робить., але коли ви інтегруєте його в процес завантаження та шифрування диска, він забезпечує перевірку цілісності та апаратно-захищені ключі.
На практиці, TPM 2.0 дозволяє використовувати два основні режими шифрування диска: а) генерувати/зберігати надійний ключ та захищати його використання за допомогою PIN-коду з захистом від грубої сили; б) активувати так зване виміряне завантаження, де Кожен компонент завантаження вимірюється в ПЛР-записах, тому ключ «розгортається» лише за умови, що система не була підроблена (і, за бажанням, з PIN-кодом перед завантаженням).
/dev/tpm0 та /dev/tpmrm0: відмінності та коли використовувати кожен з них
У Linux ви побачите два символьні пристрої, коли доступний TPM 2.0. /dev/tpm0 – це «сирий» інтерфейс TPM.У той час як /dev/tpmrm0 надає доступ через менеджер ресурсів (менеджер, який множить клієнтів, керує сеансами та ресурсами), саме його tpm2-tools рекомендує у більшості сценаріїв.
Якщо ви не впевнені, чи існує TPM, ви можете виконати його гаряче тестування. Якщо /sys/class/tpm/ порожній або команда вікі нічого не повертає, TPM не видно: можливо, його фізично немає або він вимкнено в прошивці.
# ¿Hay TPM 2.0?
ls /sys/class/tpm/
cat /sys/class/tpm/tpm*/tpm_version_major
# Dispositivos
ls -l /dev/tpm*
Коли присутні обидва вузли пристроїв, tpm2-tools зазвичай виявляє /dev/tpmrm0 та використовує його автоматично. Якщо вам потрібно примусово налаштувати пристрій, більшість інструментів приймають –tcti або використовувати змінні середовища TCTI, але для поширених завдань це зазвичай не потрібно.
TPM PCR: Як вони працюють і що вони вимірюють
Регістри конфігурації платформи – це записи, які зберігають хеші (зазвичай SHA-256) стану критичних компонентів на кожному етапі завантаження. Вони ініціалізуються до нуля під час циклу ввімкнення та можуть бути лише «розширені»: ніколи не перезаписувати та не стирати (за винятком випадків налагодження, таких як PCR 16).
Фундаментальна операція — це розширення: нове_значення = SHA256(поточне_значення || SHA256(дані))Ось так вимірювання об'єднуються в ланцюг, не допускаючи випадкових скидань. Цей шаблон використовується для вимірювання прошивки, конфігурації, безпечного завантаження, ядра, initrd та параметрів ядра, серед іншого.
На сучасному обладнанні ви побачите 24 ПЛР (0–23). Найбільш релевантними в завантаженні UEFI з systemd є:
– PCR 0: код прошивки.
– PCR 1: конфігурація прошивки (налаштування UEFI).
– PCR 7: Стан безпечного завантаження та сертифікати, яким він довіряє.
– PCR 9: initrd(и), виміряні ядром.
– PCR 11: UKI (Unified Kernel Image) та фазові мітки через systemd-stub/systemd-pcrphase.
– PCR 12: командний рядок ядра.
Зчитування та розширення PCR за допомогою tpm2-інструментів: tpm2_pcrread та tpm2_pcr_extend
У tpm2-tools зчитування виконується за допомогою tpm2_pcrread і розширення з tpm2_pcrextendІноді ви побачите, що «tpm2_pcr_extend» називається концептуальною операцією розширення, але Фактична команда пакету — tpm2_pcrextend.
Перевірити поточний стан PCR SHA-256, це так просто, як:
# Leer PCRs en SHA-256 (ejemplos de índices habituales)
sudo tpm2_pcrread sha256:0,1,7,9,11,12
# O todos los PCRs SHA-256 disponibles
tpm2_pcrread sha256:all
Щоб розширити PCR хешем довільних даних (як педагогічний приклад, хеш /etc/passwd), обчисліть SHA-256 та розширте його. Пам'ятайте: TPM отримує не гігантські дані, а їх хеш., за обмеженнями та дизайном.
# 1) Guardar el hash de /etc/passwd
echo -n $(sha256sum /etc/passwd | cut -d' ' -f1) > passwd.sha
# 2) Extender PCR 7 (ejemplo) con el hash previo
sudo tpm2_pcrextend 7:sha256=$(cat passwd.sha)
# 3) Ver el nuevo valor del PCR 7
tpm2_pcrread sha256:7
Якщо ви хочете відтворити математичні обчислення розширення поза межами TPM, Ви об'єднуєте поточне значення PCR (двійкове) з новим хешем і ви знову застосовуєте SHA-256, щоб перевірити результат.
Чи можна скинути ПЛР?
За нормальних умов, ні. Філософія полягає в тому, що ПЛР зростає лише за допомогою розширеньЄ один виняток: PCR 16 зазвичай зарезервовано для «налагодження» та може бути скинуто в певних потоках, але він не корисний як кореневий елемент безпеки вашої політики.
Виміряне завантаження, LUKS та systemd-cryptenroll: Збираємо все разом
Коли ви інтегруєте TPM у систему шифрування диска, ви можете «прив’язати» розблокування ключа до набору PCR. Якщо в поточному завантаженні ці PCR мають ті ж значення, що й під час реєстрації ключа, TPM розпечатується, і том LUKS відкривається автоматично (з PIN-кодом перед завантаженням або без нього, залежно від конфігурації).
Це дуже добре робиться за допомогою systemd-cryptenroll та systemd-cryptsetup. Ідея полягає в тому, щоб створити свій том, зареєструвати ключ TPM та додати ключ відновлення. щоб ви не залишилися осторонь, якщо вимірювання зміняться (наприклад, після оновлення прошивки або ядра).
# Ejemplo: crear LUKS, matricular TPM y añadir recuperación (pseudoflujo)
# 1) Crear el volumen con contraseña temporal
sudo cryptsetup luksFormat /dev/nvme0n1p2
# 2) Matricular TPM en LUKS usando PCRs concretos y PIN
sudo systemd-cryptenroll \
--tpm2-device=auto \
--tpm2-with-pin=yes \
--tpm2-pcrs=1+2+3+4 \
--wipe-slot=empty \
/dev/nvme0n1p2
# 3) Añadir clave de recuperación aleatoria
sudo systemd-cryptenroll --recovery-key /dev/nvme0n1p2
# 4) Abrir con TPM o con recovery cuando proceda
systemd-cryptsetup attach root /dev/nvme0n1p2 - tpm2-device=auto
Якщо ви нав'язуєте розбіжність (наприклад, Ви навмисно подовжуєте PCR 4), TPM більше не випускатиме ключ, і вам потрібно буде використовувати ключ відновлення. Пізніше ви можете повторно зареєструвати TPM з новими поточними значеннями за допомогою –wipe-slot=tpm2 та ще одне виконання systemd-cryptenroll.
Які ПЛР-тести вибрати та чому
Чим більше релевантних PCR ви пов’язуєте, тим більшу площу поверхні ви зменшуєте, але тим частіше вам доведеться перереєструватися після законних змін. Деякі практичні критерії:
– PCR 7 (Secure Boot): Має бути дуже стабільним, якщо ваш набір ключів не змінюється.
– PCR 0/1 (прошивка та конфігурація): вони рідко змінюються; потребують повторної реєстрації після оновлення прошивки або зміни BIOS/UEFI.
– PCR 9/11/12 (ядро, initrd, UKI та командний рядок): вони часто змінюються, якщо ви не використовуєте UKI або стабільний підпис/політику.
У деяких середовищах спостерігалося підключення лише PCR 7, покладаючись на Secure Boot, який перевіряє ядро та initrd, чи вони запущені як підписані UKI, та використовує systemd-boot, який не дозволяє редагувати параметри ядра, коли SB активнийЦе працює, але якщо ваше безпечне завантаження залежить від ключів сторонніх розробників (наприклад, від Microsoft), легше організувати альтернативне завантаження, яке зберігає PCR 7, і тому... Це не найобмежувальніший варіант.
Підписані політики UKI та PCR: стабільність без втрати безпеки
Практичним рішенням, щоб уникнути повторної реєстрації кожного разу під час оновлення ядра, є використання UKI (Уніфікований образ ядра) та підписана політика PCRВи генеруєте пару ключів, прив'язуєте відкритий ключ до TPM під час реєстрації та підписуєте свій UKI після кожного оновлення. TPM довіряє цьому підпису та дозволяє розблокування, навіть якщо зміниться конкретний хеш ядра.
Інструмент systemd-measure та допоміжний засіб systemd-ukify спрощують це: ukify пакети kernel, initrd та cmdline в UKI (зазвичай вимірюється в PCR 11) та systemd-measure підписує політику. За допомогою mkinitcpio можна інтегрувати ukify таким чином, щоб після встановлення підпис виконується самостійно.
# Esquema típico (pseudocomandos)
# 1) Crear claves para política PCR firmada
openssl genpkey -algorithm RSA -out /etc/kernel/pcr-initrd.key.pem -pkeyopt rsa_keygen_bits:3072
openssl req -new -x509 -key /etc/kernel/pcr-initrd.key.pem -out /etc/kernel/pcr-initrd.pub.pem -subj "/CN=UKI PCR Policy"
# 2) Configurar ukify/mkinitcpio para generar UKI y firmar política
# (consultar man ukify y systemd-measure para parámetros)
# 3) Matricular en LUKS atando PCRs y clave pública de la política
sudo systemd-cryptenroll \
--tpm2-device=auto \
--wipe-slot=tpm2 \
--tpm2-with-pin=yes \
--tpm2-pcrs=0+1+2+7 \
--tpm2-public-key=/etc/kernel/pcr-initrd.pub.pem \
--tpm2-public-key-pcrs=11 \
/dev/nvme0n1p2
Таким чином, Ваша політика залишається стабільною щодо змін ядра/initrd, доки ви продовжуєте підписувати UKI своїм ключем.Якщо ви поновлюєте паролі або змінюєте набір PCR, вам потрібно буде повторно зареєструватися.
Приклади ланцюжків вимірювань з systemd
Під час завантаження systemd-stub та systemd-pcrphase розширюють PCR у певний час. Наприклад, «enter-initrd» записано в PCR 11, що дозволяє розблокування бути дійсним лише в межах initrd (зменшуючи вектори, коли зловмисник намагається повторно використати ключ пізніше).
У системах з UKI вміст UKI вимірюється в PCR 11; у системах без UKI, ядро вимірює initrds в PCR 9 а завантажувач може виміряти командний рядок у PCR 12. Переконайтеся, що ви охопили initrd та cmdline у своїй політиці, інакше хтось може задні двері initrd або завантаження за допомогою шкідливого командного рядка, такого як init=/bin/bash.
Реальні ризики: холодне завантаження, перехоплення TPM та інше
Що може піти не так? Кілька речей, які слід знати під час моделювання загроз. Атаки холодного завантаження все ще життєздатні: якщо розблокування повністю автоматичне, зловмисник може повторювати необмежену кількість спроб. Очевидним пом'якшенням є вимога PIN-коду перед завантаженням (PBA), що зменшує спроби до однієї на цикл живлення.
Інша категорія – це атаки сніфінгу на шину TPMПроцесор запитує ключ, TPM надсилає його; якщо посилання перехоплено, ключ може бути витік. З цією метою systemd реалізує «шифрування параметрів», щоб обмін був зашифрованим; як варіант, використання fTPM/Intel PTT або зашифрованої пам'яті зменшує ризики. Існують відносно доступні публічні демонстрації (навіть з мікроконтролерами), які ілюструють можливість використання на ноутбуках основних брендів.
Також були академічні та практичні вразливості: Збій TPM, помилка TPM (із помітним впливом на AMD) і справа бітпіксі (CVE-2023-21563)Це не означає, що TPM марний, але вам слід оновлювати прошивку, розуміти модель загроз і не довіряти їй сліпо.
Стан BitLocker проти цих загроз
У світі Windows найпоширенішим засобом шифрування диска є BitLocker. Зараз зазначається, що його конфігурація за замовчуванням (автоматичне розблокування лише за допомогою TPM) Це залишає двері відкритими як для холодного завантаження, так і для перехоплення каналів TPM, оскільки не реалізує шифрування параметрів у стилі systemd. Це робить деякі корпоративні комп'ютери вразливими до атаки протягом кількох хвилин.
Рекомендація полягає в тому, щоб увімкнути аутентифікація перед завантаженням через політики/реєстр або CLI, що недостатньо доступно пересічному користувачеві. Також не забудьте перевірити, де зберігається ключ відновлення: він часто знаходиться в обліковому записі Microsoft користувача, який Це ще один ракурс ризику якщо не контролюється.
Наступальний/захисний трюк: замініть корінь LUKS, щоб примусово змінити пароль
Цікавий вектор спостерігається, коли немає автентифікації перед завантаженням. Зловмисник може клонувати справжній розділ LUKS, замініть його іншим LUKS з тим самим UUID та паролем, який він знає, і завантажте комп'ютер. Оскільки вимірювання PCR збігаються, TPM випускає ключ, але він не збігається з підробленим LUKS, тому initrd запитує ключ "відновлення". Ввівши пароль, відомий зловмиснику, ваша система запускається від імені root в initrd, і ви можете організувати крадіжку оригінального ключа (наприклад, змонтувавши справжню копію через мережу та використовуючи systemd-cryptsetup).
Чіткі пом'якшувальні заходи: активувати автентифікацію перед завантаженням, використовуйте systemd-pcrphase для суворої прив'язки розблокування до фази initrd, а також розгляньте можливість вимірювання/прив'язки цільового тома LUKS (потрібне ретельне проектування, щоб уникнути замкнених кіл).
Вибір розділення та другого ключа: найкраща практика
Тримайте ключ відновлення Це обов'язково: якщо TPM або материнська плата вийде з ладу, ваш ключ, прив'язаний до TPM, буде марним. LUKS дозволяє використовувати кілька слотів (TPM використовує один, відновлення — інший). Крім того, розділення розділів / та /home має переваги: ви можете застосувати суворе вимірювання за допомогою TPM a/ та використовувати надійний ключ або пристрій FIDO2/YubiKey для /home, що зменшує загальну довіру до одного механізму.
Що відбувається під час оновлення прошивки або ядра?
Якщо ви зміните прошивку або торкнетеся параметрів UEFI, PCR, такі як 0/1, зміняться, і TPM не відкриє ключ, доки ви не зареєструєте його повторно. Для ядро та initrd, зміни трапляються частоЯкщо ви не використовуєте UKI з підписаною політикою, кожне оновлення може змусити вас скористатися опцією відновлення та повторно зареєструватися пізніше. З підписаною UKI ви просто підписуєте її, і все.
Нотатки та спостереження спільноти
У деяких популярних посібниках з певних дистрибутивів рекомендується прив'язувати лише PCR 7 під час використання UKI та systemd-boot, покладаючись на захисні заходи Secure Boot та неможливість редагування командного рядка. Це працює, але є ризики, якщо ви покладаєтеся на сторонні ресурси. У минулому також було задокументовано помилку, коли натискання Enter викликало оболонку відновлення після розблокування; рекомендується оновлювати версії, щоб уникнути несподіванок.
Цікаві коментарі були опубліковані у 2025/06 році: Несправність TPM продовжує впливати на AMD певною мірою; вікі додали окремі розділи про підписані політики PCR; а інсталятор для дистрибутива, який пропонує FDE з TPM як експериментальну функцію, був протестований з деякими практичними труднощами (вимога відновлення під час першого завантаження, залежність від знімків, подвійне шифрування диска), проблема, яка заслуговує на більш глибокий аудит.
Подальша стаття, присвячена шифруванню диска у Windows, була опублікована у 2025/07 році. Загальний висновок підкреслює необхідність PBA та шифрування каналу TPM., а також обмеження залежності від ключів сторонніх розробників у Secure Boot.
Поради щодо роботи з tpm2-tools та systemd
Для щоденного використання: встановіть tpm2-tools та tpm2-tss. За замовчуванням використовується /dev/tpmrm0, а також tpm2_pcrread/tpm2_pcrextend для тестування та експериментів з ПЛР. Уникайте розширення виробничих ПЛР довільними даними: робіть це в лабораторіях або використовуйте PCR 16 для тестування.
Під час реєстрації за допомогою systemd-cryptenroll: –tpm2-пристрій=авто виявляє TPM; –tpm2-з-контактом додає ПБА; –tpm2-pcrs=… виберіть свої ПЛР; –tpm2-public-key=… та –tpm2-public-key-pcrs=… активуйте підписаний поліс PCR (наприклад, пов'язаний з PCR 11 для UKI). Не забудьте –щілина для стирання коли потрібно очистити попередній слот.
Якщо у вас немає TPM, а systemd змушує вас чекати на завантаження
Іноді після оновлення служба намагається використовувати TPM, навіть якщо на вашому комп’ютері він не відображається, що призводить до тайм-аутів під час завантаження. Спочатку перевірте, чи не відображається /dev/tpm* ані записи в /sys/class/tpm.
# Verificación rápida
ls /dev/tpm*
ls /sys/class/tpm/
Якщо TPM немає, перевірте файл /etc/crypttab немає таких опцій, як tpm2-device=autoЯкщо вони існують, видаліть їх та перебудуйте initrd. Ви також можете вимкнути фазу вимірювання на комп'ютерах без TPM:
# 1) Eliminar referencias TPM en /etc/crypttab y regenerar initrd
sudo mkinitcpio -P # (o dracut/rebuildinitrd según distro)
# 2) Evitar carga de módulos TPM si el firmware publica algo extraño
echo -e "blacklist tpm\nblacklist tpm_tis\nblacklist tpm_crb" | sudo tee /etc/modprobe.d/no-tpm.conf
# 3) Opcional: evitar pcrphase si te da problemas
sudo systemctl mask systemd-pcrphase.service
Це усуває непотрібне очікування, якщо на вашому обладнанні відсутній TPM. Якщо пізніше ви ввімкнете TPM у BIOS/UEFI, видаліть чорний список та розмаскуйте пристрій, щоб відновити вимірювання.
Належні практики та рішення щодо довіри
Деякі люди з обережністю ставляться до TPM, оскільки це «чорна скринька», як і самошифрувальні диски. Це обґрунтований сумнів. Оцініть свою модель загроз і поєднує зручність використання, конфіденційність та обслуговування. Для багатьох людей TPM+PBA+підписаний UKI – це величезний крок у сфері безпеки без надмірних труднощів.
На обладнанні, яке це дозволяє, додайте зашифрована пам'ять та уникайте використання сторонніх ключів у Secure Boot; обмежуйте ланцюжок власними ключами, коли це можливо. Оновлюйте прошивку та ядро, щоб включати засоби для пом'якшення опублікованих вразливостей.
Оволодіння операціями /dev/tpm0, /dev/tpmrm0 та tpm2_pcrread/tpm2_pcr_extend відкриває шлях до виміряного завантаження та надійного шифрування диска в Linux; за допомогою UKI та підписаної політики PCR ви досягаєте операційної стабільності, а додавання PIN-коду перед завантаженням також захищає вас від більш практичних атак. Головне — правильно вибирати PCR-записи, часто підписувати те, що змінюється, і завжди мати хороший ключ відновлення..
