През последните години, TPM 2.0 модулите се превърнаха от хардуерна мистерия в обичайна част от всеки съвременен компютър с UEFI и Secure Boot. Тази статия обяснява какво представляват /dev/tpm0 и /dev/tpmrm0 и как да се използват tpm2_pcrread и tpm2_pcrextend. (както и действителната му команда в tpm2-tools), както и обяснение как те се вписват в политиките за измерено зареждане, криптиране на диска и подписана PCR в Linux.
Съществува полезна документация, но тя е разпръсната между страниците на systemd man, уики записи и много пълни публикации; Тук събираме цялата ключова информация (PCR, практически примери, рискове и защити) така че техническите специалисти, дори и да не са TPM експерти, да могат да работят с тези инструменти, без да се губят в неясни подробности.
Какво е TPM 2.0 и защо може да ви е интересно
Модулът за надеждна платформа (Trusted Platform Module) е чип за сигурност, който се намира на дънната ви платка (или вътре в процесора, като fTPM/Intel PTT) и действа като защитено хранилище, генератор на случайни числа и корен на доверие за системата. Пасивно е: ако не го използвате, не прави нищо., но когато го интегрирате в процеса на зареждане и криптирането на диска, той осигурява проверка на целостта и хардуерно защитени ключове.
На практика, TPM 2.0 ви позволява два основни режима на използване при криптиране на диск: а) генериране/запазване на силен ключ и защита на използването му с ПИН с анти-груба сила заключване; б) активиране на така нареченото измерено зареждане, където Всеки компонент на обувката се измерва в PCR записи, така че ключът се „разопакова“ само ако системата не е била подправена (и по избор с ПИН код преди зареждане).
/dev/tpm0 и /dev/tpmrm0: разлики и кога да използвате всеки от тях
В Linux ще видите две символни устройства, когато TPM 2.0 е наличен. /dev/tpm0 е „суровият“ интерфейс на TPMДокато /dev/tpmrm0 предоставя достъп чрез Resource Manager (мениджър, който умножава клиенти, управлява сесии и ресурси), като този, препоръчван от tpm2-tools в повечето сценарии.
Ако не сте сигурни дали съществува TPM или не, можете да го тествате на живо. Ако /sys/class/tpm/ е празно или командата wiki не връща нищо, не се вижда 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(данни))Ето как измерванията се свързват, без да се допускат опортюнистични нулирания. Този модел се използва за измерване на фърмуера, конфигурацията, Secure Boot, ядрото, initrd и параметрите на ядрото, наред с други.
На съвременното оборудване ще видите 24 PCR (0–23). Най-подходящите в UEFI boot със systemd са:
– PCR 0: код на фърмуера.
– PCR 1: конфигурация на фърмуера (настройки на UEFI).
– PCR 7: Състояние на защитено зареждане и сертификати, на които се доверява.
– PCR 9: initrd(s), измерени от ядрото.
– 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 да бъде нулиран?
При нормални условия, не. Философията е, че PCR расте само с разширения.Има едно изключение: PCR 16 обикновено е запазен за „отстраняване на грешки“ и може да бъде нулиран в определени потоци, но не е полезен като корен на сигурността на вашата политика.
Измерено зареждане, LUKS и systemd-cryptenroll: Сглобяване на парчетата
Когато интегрирате TPM в криптирането на диска си, можете да „свържете“ отключването с ключ към набор от PCR. Ако при текущото зареждане тези PCR имат същите стойности, както когато сте регистрирали ключа, TPM се разпечатва и томът LUKS се отваря автоматично (със или без ПИН код преди зареждане, в зависимост от вашата конфигурация).
Това се прави много добре със 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-та свържете, толкова повече площ намалявате, но толкова по-често ще трябва да се пререгистрирате след легитимни промени. Някои практически критерии:
– PCR 7 (Secure Boot): Трябва да е много стабилен, ако вашият набор от ключове не се променя.
– PCR 0/1 (фърмуер и конфигурация): Те рядко се променят; изискват пререгистрация след актуализиране на фърмуера или промяна на BIOS/UEFI.
– PCR 9/11/12 (ядро, initrd, UKI и cmdline): Тези настройки се променят често, ако не използвате UKI или стабилен подпис/политика.
В някои среди е наблюдавано свързване само на PCR 7, разчитайки на Secure Boot, който проверява ядрото и initrd дали са стартирани като подписан UKI и използва systemd-boot, който не позволява редактиране на параметрите на ядрото, когато SB е активенТова работи, но ако вашето Secure Boot разчита на ключове от трети страни (като например Microsoft 3rd Party), е по-лесно да се организира алтернативно зареждане, което запазва 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 sniffing и други
Какво може да се обърка? Няколко неща, които трябва да знаете, когато моделирате заплахи. Атаки от „студено зареждане“ все още са жизнеспособни: ако отключването е напълно автоматично, нападателят може да повтаря неограничен брой опити. Ясното смекчаване е да се изисква ПИН код преди зареждане (PBA), което намалява опитите до един на цикъл на захранване.
Друга категория е атаки чрез „sniffing“ на TPM шинатаПроцесорът изисква ключа, TPM го изпраща; ако връзката бъде подслушната, ключът може да бъде разкрит. За тази цел systemd внедрява „криптиране на параметри“, така че обменът да е криптиран; алтернативно, използването на fTPM/Intel PTT или криптирана памет намалява излагането на риск. Има сравнително достъпни публични демонстрации (дори с микроконтролери), които илюстрират осъществимостта на лаптопи от големи марки.
Съществуваха и академични и практически уязвимости: TPM-Fail, faultTPM (със забележимо въздействие върху AMD) и случаят битпикси (CVE-2023-21563)Това не означава, че TPM е безполезен, но трябва да поддържате фърмуера си актуален, да разбирате модела на заплахата си и да не му се доверявате сляпо.
Състояние на BitLocker срещу тези заплахи
В света на Windows, най-широко използваното криптиране на дискове е BitLocker. Вече е отбелязано, че конфигурацията му по подразбиране (автоматично отключване само с TPM) Това оставя вратата отворена както за студено зареждане, така и за TPM канално „sniffing“, тъй като не имплементира криптиране на параметри в стил systemd. Това прави определени корпоративни компютри уязвими за атака в рамките на минути.
Препоръката там е да се даде възможност удостоверяване преди зареждане чрез политики/регистър или CLI, нещо, което не е достатъчно достъпно за средностатистическия потребител. Също така, не забравяйте да проверите къде се съхранява ключът за възстановяване: той често се намира в акаунта на потребителя в Microsoft, който Това е друг ъгъл на риск ако не се контролира.
Офанзивен/Защитен трик: Заменете root-а на 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 като експериментална функция, беше тестван с някои практически трудности (изискване за възстановяване при първо зареждане, зависимост от snaps, двойно криптиране на диска), проблем, който заслужава по-задълбочен одит.
През 2025/07 беше публикувано продължение, фокусирано върху криптирането на дискове в Windows. Общото заключение подсилва необходимостта от PBA и криптиране на TPM канала., както и ограничаване на зависимостта от ключове на трети страни в Secure Boot.
Съвети за работа с tpm2-tools и systemd
За ежедневна употреба: Инсталирайте tpm2-tools и tpm2-tss. Използва /dev/tpmrm0 по подразбиранеи tpm2_pcrread/tpm2_pcrextend за тестване и експериментиране с PCR. Избягвайте разширяването на производствените PCR с произволни данни: правете това в лаборатории или използвайте PCR 16 за тестване.
При регистрация със systemd-cryptenroll: –tpm2-устройство=автоматично открива TPM; –tpm2-с-пин добавя ПБА; –tpm2-pcrs=… изберете вашите PCR; –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, да подписвате често промените и винаги да поддържате добър ключ за възстановяване..
