En els darrers anys, els mòduls TPM 2.0 han passat de ser un misteri de maquinari a una peça habitual a qualsevol equip modern amb UEFI i Secure Boot. Aquest article baixa a terra què són /dev/tpm0 i /dev/tpmrm0 i com fer servir tpm2_pcrread i tpm2_pcrextend (així com la seva ordre real a tpm2-tools), a més d'explicar com encaixen en l'arrencada mesurada, el xifratge de disc i les polítiques PCR signades a Linux.
La documentació útil existeix, però està dispersa entre man pages de systemd, entrades de wiki i posts molt densos; aquí reunim tot allò clau (PCRs, exemples pràctics, riscos i defenses) perquè persones tècniques, encara que no siguin expertes en TPM, puguin treballar amb aquestes eines sense perdre's en detalls foscos.
Què és un TPM 2.0 i per què t'interessa
Un Trusted Platform Module és un xip de seguretat que viu a la teva placa (o dins de la CPU com a fTPM/Intel PTT) i que actua com a magatzem segur, generador de números aleatoris i arrel de confiança del sistema. És passiu: si no el fas servir, no fa res, però quan l'integres al flux d'arrencada i xifratge de disc, aporta verificació d'integritat i claus protegides per maquinari.
A la pràctica, un TPM 2.0 et permet dos grans modes d'ús en xifratge de disc: a) generar/guardar una clau robusta i protegir-ne l'ús amb un PIN amb bloqueig antiforça bruta; b) activar l'anomenat measured boot, on cada component d'arrencada es mesura en registres PCR, de manera que la clau només es “desencapsula” si el sistema no ha estat alterat (i opcionalment amb un PIN de pre-boot).
/dev/tpm0 i /dev/tpmrm0: diferències i quan fer servir cadascun
A Linux veuràs dos dispositius de caràcter quan hi ha TPM 2.0 disponible. /dev/tpm0 és la interfície “crua” del TPM, mentre que /dev/tpmrm0 exposa l'accés a través del Resource Manager (gestor que multiplica clients, gestiona sessions i recursos), essent el recomanat per tpm2-tools a la majoria d'escenaris.
Si tens dubtes de si existeix o no un TPM, ho pots comprovar en calent. Si /sys/class/tpm/ està buit o la comanda de la wiki no torna res, no hi ha TPM visible: pot no existir físicament o estar desactivat al microprogramari.
# ¿Hay TPM 2.0?
ls /sys/class/tpm/
cat /sys/class/tpm/tpm*/tpm_version_major
# Dispositivos
ls -l /dev/tpm*
Quan hi hagi ambdós nodes de dispositiu, normalment és que tpm2-tools detecti /dev/tpmrm0 i l'utilitzi automàticament. Si necessiteu forçar un dispositiu, la majoria d'eines accepten –tcti o usen variables d'entorn TCTI, però per a tasques comunes no sol fer falta.
PCRs del TPM: com funcionen i què mesuren
Els Platform Configuration Registers són registres que emmagatzemen hashes (normalment SHA-256) de l'estat de components crítics a cada fase d'arrencada. S'inicialitzen a zero al cicle d'encesa i només es poden “estendre”: mai reescriure o esborrar (llevat de casos de debug com el PCR 16).
L'operació fonament és l'extensió: nou_valor = SHA256(valor_actual || SHA256(dades)). Així s'encadenen mesuraments sense permetre resets oportunistes. Aquest patró es fa servir per mesurar firmware, configuració, Secure Boot, kernel, initrd i paràmetres del kernel, entre d'altres.
En equips moderns veuràs 24 PCRs (0–23). Els més rellevants en arrencada UEFI amb systemd són:
– PCR 0: codi de microprogramari.
– PCR 1: configuració del microprogramari (UEFI settings).
– PCR 7: estat de Secure Boot i certificats en què confia.
– PCR 9: initrd(s) mesurats pel nucli.
– PCR 11: UKI (Unified Kernel Image) i marques de fase via systemd-stub/systemd-pcrphase.
– PCR 12: línia d'ordres del nucli.
Llegir i estendre PCRs amb tpm2-tools: tpm2_pcrread i tpm2_pcr_extend
A tpm2-tools la lectura es fa amb tpm2_pcrread i l'extensió amb tpm2_pcrextend. De vegades veuràs citat “tpm2_pcr_extend” per referir-se a l'operació conceptual d'extensió, però la comanda real de la suite és tpm2_pcrextend.
Per inspeccionar l'estat actual dels PCR SHA-256, És tan senzill com:
# 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
Per estendre un PCR amb el hash de dades arbitràries (com a exemple pedagògic, el hash de /etc/passwd), calcula el SHA-256 i esten-lo. Recorda: el TPM no rep dades gegantines, sinó el seu hash, per límits i disseny.
# 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
Si voleu reproduir la matemàtica de l'extensió fora del TPM, concatenes el valor actual del PCR (binari) amb el hash nou i tornes a aplicar SHA-256 per comprovar-ne el resultat.
Es pot resetejar un PCR?
En condicions normals, no. La filosofia és que un PCR només creix amb extensions. Hi ha una excepció: PCR 16 sol reservar-se com a “debug” i es pot resetejar en certs fluxos, però no és útil com a arrel de seguretat de la teva política.
Measured Boot, LUKS i systemd-cryptenroll: unir les peces
Quan integres el TPM al teu xifratge de disc, pots “lligar” el desbloqueig de la clau a un conjunt de PCRs. Si en l'arrencada actual aquests PCR tenen els mateixos valors que quan vas matricular la clau, el TPM desencapsula (unseal) i el volum LUKS s'obre automàticament (amb o sense PIN de pre-arrencada, segons configures).
Això es fa molt bé amb systemd-cryptenroll i systemd-cryptsetup. La idea és crear el teu volum, matricular la clau TPM i afegir clau de recuperació per no quedar-vos fora si canvien mesuraments (per exemple, després d'actualitzar firmware o kernel).
# 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
Si forces una discrepància (per exemple, estenes PCR 4 a propòsit), el TPM ja no alliberarà la clau i hauràs d'usar la de recuperació. Posteriorment pots tornar a matricular el TPM amb els nous valors actuals mitjançant –wipe-slot=tpm2 i una altra execució de systemd-cryptenroll.
Quins PCRs triar i per què
Com més PCR rellevants vincules, més superfície redueixes, però més sovint hauràs de re-matricular després de canvis legítims. Alguns criteris pràctics:
– PCR 7 (Secure Boot): hauria de ser molt estable si el teu set de claus no canvia.
– PCR 0/1 (firmware i configuració): poques vegades canvien; obliguen a re-matricular després dactualitzar firmware o tocar la BIOS/UEFI.
– PCR 9/11/12 (kernel, initrd, UKI i cmdline): canvien sovint si no uses UKI o signatura/política estable.
En alguns entorns s'ha vist enllaçar només PCR 7, recolzant-se que Secure Boot verifica kernel i initrd si s'arrenquen com a UKI signat i usant systemd-boot que no deixa editar paràmetres del nucli quan SB està actiu. Això funciona, però si el teu Secure Boot confia en claus de tercers (com Microsoft 3rd Party) és més fàcil orquestrar una arrencada alternativa que conservi PCR 7 i, per tant, no és l'opció més restrictiva.
UKI i polítiques PCR signades: estabilitat sense perdre seguretat
Una solució pràctica per evitar re-matricular cada vegada que actualitzes kernel consisteix a utilitzar UKI (Unified Kernel Image) i una política PCR signada. Generes un parell de claus, lligues la pública al TPM en matricular i firmes la teva UKI després de cada actualització; el TPM confia en aquesta signatura i permet el desbloqueig encara que el hash concret del nucli canviï.
L'eina systemd-measure i el helper systemd-ukify faciliten això: ukify empaqueta kernel, initrd i cmdline a l'UKI (mesurat habitualment en PCR 11) i systemd-measure signa la política. Amb mkinitcpi, ukify pot integrar-se perquè post-install la signatura s'executi sola.
# 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
D'aquesta manera, la teva política queda estable davant de canvis del kernel/initrd mentre segueixis signant l'UKI amb la teva clau. Si renoves claus o canvies el set de PCRs, tocarà rematricular.
Exemples de cadenes de mesura amb systemd
Durant l'arrencada, systemd-stub i systemd-pcrphase estenen PCRs en moments concrets. Per exemple, “enter-initrd” es registra a PCR 11, el que permet que un desbloqueig només sigui vàlid dins de la initrd (reduint vectors on un atacant intenti reutilitzar la clau més tard).
En sistemes amb UKI, el contingut de l'UKI es mesura en PCR 11; en sistemes sense UKI, el kernel mesura initrds a PCR 9 i el gestor d'arrencada pot mesurar la cmdline a PCR 12. Assegureu-vos de cobrir initrd i cmdline en la vostra política, o algú podria backdoorear la initrd o arrencar amb una cmdline maliciosa com init=/bin/bash.
Riscos reals: cold boot, sniffing TPM i més
Què pot sortir malament? Diverses coses que convé conèixer per modelar amenaces. Els atacs de cold boot segueixen sent viables: si el desbloqueig és totalment automàtic, un atacant pot repetir intents il·limitats. La mitigació clara és exigir un PIN de preboot (PBA) i reduir intents a un per cicle d'alimentació.
Una altra categoria són els sniffing attacks al bus TPM. La CPU sol·licita la clau, el TPM l'envia; si l'enllaç es punxa, la clau es pot filtrar. Per això, systemd implementa “parametre encryption” perquè l'intercanvi viatge xifrat; com a alternativa, utilitzar fTPM/Intel PTT o memòria xifrada redueix l'exposició. Hi ha demostracions públiques relativament assequibles (fins a microcontroladors) que il·lustren la viabilitat en portàtils de grans marques.
També hi ha hagut vulnerabilitats acadèmiques i pràctiques: TPM-Fail, faulTPM (amb impacte notable a AMD) i el cas bitpixie (CVE-2023-21563). No vol dir que el TPM sigui inútil, sinó que has de mantenir firmware al dia, entendre el teu model d'amenaces i no confiar cegament.
Estat de BitLocker davant d'aquestes amenaces
Al món Windows, el xifratge de disc àmpliament desplegat és BitLocker. Actualment s'ha assenyalat que la seva configuració per defecte (desbloqueig automàtic només amb TPM) deixa la porta oberta tant a cold boot com a sniffing del canal TPM, ja que no implementa xifrat de paràmetres a l'estil systemd. Això fa que certs equips corporatius siguin atacables en minuts.
La recomanació allà és habilitar autenticació prèvia a l'arrencada mitjançant polítiques/registre o CLI, cosa que no està prou exposada a l'usuari mitjà. A més, recordeu revisar on s'emmagatzema la clau de recuperació: sovint resideix al compte de Microsoft de l'usuari, la qual cosa és un altre angle de risc si no es controla.
Truc ofensiu/defensiu: substituir l'arrel LUKS per forçar la teva clau
Hi ha un vector interessant quan no hi ha pre-boot authentication. Un atacant pot clonar la partició LUKS real, substituir-la per una altra LUKS amb el mateix UUID i una contrasenya que ell coneix, i arrencar lequip. Com que els mesuraments PCR quadren, el TPM allibera la clau, però no coincideix amb la LUKS falsa, així que la initrd demanarà la clau “de recuperació”. En introduir la contrasenya coneguda per l'atacant, el vostre sistema s'executa com a root en initrd i ja pot orquestrar robatori de la clau original (per exemple, muntant la còpia veritable a través de xarxa i usant systemd-cryptsetup).
Mitigacions clares: activar pre-boot authentication, aprofitar systemd-pcrphase per lligar el desbloqueig estrictament a la fase d'initrd, i considerar mesurar/lligar també el volum LUKS objectiu (requereix un disseny curós per evitar cercles viciosos).
Triar particionament i segona clau: pràctica recomanable
mantenir una clau d'recuperació és obligatori: si el TPM o la placa moren, la teva clau lligada al TPM no et serveix. LUKS permet diversos slots (TPM utilitza un, la recuperació un altre). A més, separar particions / i /home té avantatges: pots aplicar mesurament estricta amb TPM a / i utilitzar una clau forta o un dispositiu FIDO2/YubiKey per a /home, reduint confiança total en un únic mecanisme.
Què passa quan actualitzes firmware o kernel
Si canvieu firmware o toqueu opcions UEFI, PCRs com 0/1 variaran i el TPM no alliberarà la clau fins que re-matricules. Per al kernel i initrd, els canvis són freqüents: si no empres UKI amb política signada, cada actualització pot obligar-te a fer servir la recovery i re-matricular després. Amb UKI signat, firmes i llest.
Notes i observacions de la comunitat
En algunes guies populars de certes distribucions s'ha recomanat lligar només PCR 7 sempre que es faci servir UKI i systemd-boot, recolzant-se en les garanties de Secure Boot i en la impossibilitat d'editar cmdline. Funciona, però hi ha riscos si confies en tercers. També s'ha documentat un bug en el passat on, en “martellejar” Enter, apareixia una shell de recuperació després del desbloqueig; convé mantenir versions actualitzades per evitar sorpreses.
El 2025/06 es van compartir comentaris interessants: faulTPM segueix afectant AMD en certa mesura; wikis han afegit seccions específiques sobre polítiques PCR signades; i es va provar l'instal·lador d'una distribució que ofereix FDE amb TPM com a funció experimental, amb algunes ensopegades pràctiques (demanar recovery a la primera arrencada, dependència de snaps, doble disc xifrat), tema que mereix una auditoria més profunda.
El 2025/07 es va publicar un seguiment centrat en xifrat de disc a Windows. La conclusió general reforça la necessitat de PBA i de xifrar el canal TPM, a més de limitar la confiança en claus de tercers a Secure Boot.
Consells operatius amb tpm2-tools i systemd
Pel dia a dia: instal·la tpm2-tools i tpm2-tss. Fes servir /dev/tpmrm0 per defecte, i tpm2_pcrread/tpm2_pcrextend per comprovar i experimentar amb PCRs. Evita estendre PCRs de producció amb dades arbitràries: fes-ho en laboratoris o fes servir PCR 16 per a proves.
En matricular amb systemd-cryptenroll: –tpm2-device=auto detecta el TPM; –tpm2-with-pin afegeix PBA; –tpm2-pcrs=… selecciona els teus PCRs; –tpm2-public-key=… i –tpm2-public-key-pcrs=… activen una política PCR signada (per exemple, lligada a PCR 11 per a UKI). No oblidis –wipe-slot quan vulguis netejar un slot previ.
Si no tens TPM i systemd et fa esperar a l'arrencada
Ocasionalment, després d'una actualització, algun servei intenta fer servir el TPM encara que la teva màquina no el tingui visible, causant esperes de timeout en arrencar. Comproveu primer que no aparegui cap /dev/tpm* ni entrades a /sys/class/tpm.
# Verificación rápida
ls /dev/tpm*
ls /sys/class/tpm/
Si no hi ha TPM, revisa que al teu /etc/crypttab no tinguis opcions com tpm2-device=auto. Si n'hi ha, elimina-les i regenera el teu initrd. També podeu desactivar la fase de mesura en equips sense 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
Amb això elimines esperes innecessàries si el teu equip no té TPM. Si més tard actives el TPM a BIOS/UEFI, retira el blacklist i desmascara la unitat per recuperar mesuraments.
Bones pràctiques i decisions de confiança
Hi ha qui recela del TPM per ser una “caixa negra”, igual que de discos autoxifrats. És un dubte raonable. Valoreu el vostre model d'amenaces i equilibra usabilitat, privadesa i manteniment. Per a moltes persones, TPM+PBA+UKI signat és un gran salt de seguretat sense fricció excessiva.
En maquinari que ho permeti, afegeix memòria xifrada i evita confiar en claus de tercers a Secure Boot; limita la cadena a les teves pròpies claus quan sigui viable. Mantingues firmware i kernel actualitzats per incorporar mitigacions de vulnerabilitats publicades.
Dominar /dev/tpm0, /dev/tpmrm0 i les operacions tpm2_pcrread/tpm2_pcr_extend t'obre la porta a una arrencada mesurada i un xifratge de disc robust a Linux; amb UKI i política PCR signada aconsegueixes estabilitat operativa, i si afegeixes PIN de pre-arrencada, blindes els atacs més pràctics. La clau és triar bé els PCRs, signar el que canvia sovint i conservar sempre una bona clau de recuperació.
