Komplett guide til /dev/tpm0, /dev/tpmrm0 og kommandoene tpm2_pcrread og tpm2_pcr_extend i Linux

I de senere årene har TPM 2.0-moduler gått fra å være et maskinvaremysterium til en vanlig del av enhver moderne datamaskin med UEFI og sikker oppstart. Denne artikkelen forklarer hva /dev/tpm0 og /dev/tpmrm0 er, og hvordan man bruker tpm2_pcrread og tpm2_pcrextend. (samt den faktiske kommandoen i tpm2-tools), samt forklaring av hvordan de passer inn i målt oppstart, diskkryptering og signerte PCR-policyer i Linux.

Nyttig dokumentasjon finnes, men den er spredt blant systemd man-sider, wiki-oppføringer og svært tette innlegg; Her samler vi all nøkkelinformasjon (PCR-er, praktiske eksempler, risikoer og forsvar) slik at tekniske personer, selv om de ikke er TPM-eksperter, kan jobbe med disse verktøyene uten å gå seg vill i obskure detaljer.

Hva er en TPM 2.0, og hvorfor du kanskje bryr deg?

En Trusted Platform Module er en sikkerhetsbrikke som ligger på hovedkortet ditt (eller inne i CPU-en som fTPM/Intel PTT) og fungerer som et sikkert lager, en tilfeldig tallgenerator og en tillitsrot for systemet. Den er passiv: hvis du ikke bruker den, gjør den ingenting., men når du integrerer den i oppstartsflyten og diskkrypteringen, gir den integritetsverifisering og maskinvarebeskyttede nøkler.

I praksis gir en TPM 2.0 deg to hovedmoduser for bruk i diskkryptering: a) generere/lagre en sterk nøkkel og beskytte bruken med en PIN-kode med anti-brute force-lås; b) aktivere den såkalte målte oppstarten, der Hver oppstartskomponent måles i PCR-poster, slik at nøkkelen bare «pakkes ut» hvis systemet ikke har blitt tuklet med (og eventuelt med en PIN-kode før oppstart).

/dev/tpm0 og /dev/tpmrm0: forskjeller og når man skal bruke hver av dem

På Linux vil du se to tegnenheter når TPM 2.0 er tilgjengelig. /dev/tpm0 er det «rå» grensesnittet til TPM-enMens /dev/tpmrm0 eksponerer tilgang gjennom ressursbehandleren (en manager som multipliserer klienter, administrerer økter og ressurser), som er den som anbefales av tpm2-tools i de fleste scenarier.

Hvis du er usikker på om det finnes en TPM eller ikke, kan du utføre en varmtest. Hvis /sys/class/tpm/ er tomt eller wiki-kommandoen ikke returnerer noe, ingen TPM er synlig: Den finnes kanskje ikke fysisk eller kan være deaktivert i fastvaren.

# ¿Hay TPM 2.0?
ls /sys/class/tpm/
cat /sys/class/tpm/tpm*/tpm_version_major
# Dispositivos
ls -l /dev/tpm*

Når begge enhetsnodene er til stede, vil tpm2-tools vanligvis oppdage /dev/tpmrm0 og bruke den automatisk. Hvis du trenger å tvinge en enhet, godtar de fleste verktøy –tcti eller bruk TCTI-miljøvariabler, men for vanlige oppgaver er det vanligvis ikke nødvendig.

TPM PCR-er: Hvordan de fungerer og hva de måler

Plattformkonfigurasjonsregistre er poster som lagrer hasher (vanligvis SHA-256) av tilstanden til kritiske komponenter i hver oppstartsfase. De initialiseres til null ved oppstartssyklus og kan bare "utvides": aldri omskriv eller slett (unntatt i feilsøkingstilfeller som PCR 16).

Den grunnleggende operasjonen er utvidelsen: ny_verdi = SHA256(gjeldende_verdi || SHA256(data))Slik kjedes målinger sammen uten å tillate opportunistiske tilbakestillinger. Dette mønsteret brukes til å måle blant annet fastvare, konfigurasjon, sikker oppstart, kjerne, initrd og kjerneparametere.

På moderne utstyr vil du se 24 PCR-er (0–23). De mest relevante i UEFI-oppstart med systemd er:
– PCR 0: fastvarekode.
– PCR 1: fastvarekonfigurasjon (UEFI-innstillinger).
– PCR 7: Status for sikker oppstart og sertifikater den stoler på.
– PCR 9: initrd(er) målt av kjernen.
– PCR 11: UKI (Unified Kernel Image) og fasemerker via systemd-stub/systemd-pcrphase.
– PCR 12: kjernekommandolinje.

Les og utvid PCR-er med tpm2-verktøyene: tpm2_pcrread og tpm2_pcr_extend

I tpm2-tools gjøres avlesningen med tpm2_pcrread og forlengelsen med tpm2_pcrextendDu vil noen ganger se «tpm2_pcr_extend» referert til som den konseptuelle operasjonen for å utvide, men Den faktiske suite-kommandoen er tpm2_pcrextend.

For å inspisere gjeldende status for PCR-ene SHA-256, det er så enkelt som:

# 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

For å utvide en PCR med hashen av vilkårlige data (som et pedagogisk eksempel, hashen til /etc/passwd), beregn SHA-256 og utvid den. Husk: TPM-en mottar ikke gigantiske data, men hashen, etter begrensninger og design.

# 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

Hvis du vil gjenskape utvidelsesmatematikken utenfor TPM-en, Du sammenkobler den nåværende PCR-verdien (binær) med den nye hashen og du bruker SHA-256 på nytt for å sjekke resultatet.

Kan en PCR nullstilles?

Under normale forhold, nei. Filosofien er at en PCR bare vokser med utvidelserDet finnes ett unntak: PCR 16 er vanligvis reservert for «feilsøking» og kan tilbakestilles i visse flyter, men den er ikke nyttig som sikkerhetsrot for policyen din.

Measured Boot, LUKS og systemd-cryptenroll: Å sette brikkene sammen

Når du integrerer TPM i diskkrypteringen, kan du «binde» nøkkelopplåsingen til et sett med PCR-er. Hvis disse PCR-ene har de samme verdiene i den nåværende oppstarten som da du registrerte nøkkelen, TPM-en blir avforseglet og LUKS-volumet åpnes automatisk (med eller uten en PIN-kode før oppstart, avhengig av konfigurasjonen).

Dette gjøres veldig fint med systemd-cryptenroll og systemd-cryptsetup. Tanken er å opprette volumet ditt, registrere TPM-nøkkelen og legge til en gjenopprettingsnøkkel. slik at du ikke blir utelatt hvis målingene endres (for eksempel etter oppdatering av fastvare eller kjerne).

# 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

Hvis du fremtvinger en avvik (for eksempel du forlenger PCR 4 med vilje), vil ikke lenger TPM-en frigi nøkkelen, og du må bruke gjenopprettingsnøkkelen. Du kan senere registrere TPM-en på nytt med de nye gjeldende verdiene ved å bruke –tørk-spor=tpm2 og en annen utførelse av systemd-cryptenroll.

Hvilke PCR-er skal man velge og hvorfor

Jo flere relevante PCR-er du lenker, desto mer overflateareal reduserer du, men desto oftere må du registrere deg på nytt etter legitime endringer. Noen praktiske kriterier:
– PCR 7 (sikker oppstart): Burde være veldig stabil hvis nøkkelsettet ditt ikke endres.
– PCR 0/1 (fastvare og konfigurasjon): Disse endres sjelden; de krever ny registrering etter oppdatering av fastvare eller endring av BIOS/UEFI.
– PCR 9/11/12 (kernel, initrd, UKI og cmdline): Disse endres ofte hvis du ikke bruker UKI eller stabil signatur/policy.

I noen miljøer har det blitt sett at det bare kobler PCR 7, og er avhengig av Secure Boot som verifiserer kernel og initrd hvis de startes som signert UKI og bruker systemd-boot som tillater ikke redigering av kjerneparametere når SB er aktivDet fungerer, men hvis den sikre oppstarten din er avhengig av tredjepartsnøkler (som Microsoft 3rd Party), er det enklere å orkestrere en alternativ oppstart som bevarer PCR 7 og dermed Det er ikke det mest restriktive alternativet.

UKI- og PCR-policyer signert: stabilitet uten tap av sikkerhet

En praktisk løsning for å unngå å måtte registrere seg på nytt hver gang du oppdaterer kjernen, er å bruke UKI (Unified Kernel Image) og en signert PCR-policyDu genererer et nøkkelpar, binder den offentlige nøkkelen til TPM-en ved registrering og signerer UKI-en din etter hver oppdatering. TPM-en stoler på denne signaturen og tillater opplåsing selv om den spesifikke kjernehashen endres.

Verktøyet systemd-measure og hjelperen systemd-ukify gjør dette enkelt: ukify pakker kernel, initrd og cmdline inn i UKI (vanligvis målt i PCR 11) og systemd-measure signerer policyen. Med mkinitcpio kan ukify integreres slik at etter installasjon signaturen utføres av seg selv.

# 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

På denne måten, Policyen din forblir stabil mot endringer i kernel/initrd så lenge du fortsetter å signere UKI-en med nøkkelen din.Hvis du fornyer passordene dine eller endrer PCR-settet ditt, må du registrere deg på nytt.

Eksempler på målekjeder med systemd

Under oppstart utvider systemd-stub og systemd-pcrphase PCR-er på bestemte tidspunkter. For eksempel er «enter-initrd» registrert i PCR 11, slik at en opplåsing bare er gyldig innenfor initrd (reduserer vektorer der en angriper prøver å bruke nøkkelen på nytt senere).

I systemer med UKI måles UKI-innholdet i PCR 11; i systemer uten UKI, Kjernen måler initrds i PCR 9 og oppstartslasteren kan måle cmdline i PCR 12. Sørg for at du dekker initrd og cmdline i policyen din, ellers kan noen andre gjøre det. bakdørør initrd eller oppstart med en ondsinnet cmdline som init=/bin/bash.

Reelle risikoer: kald oppstart, TPM-sniffing og mer

Hva kan gå galt? Det er flere ting å vite når man modellerer trusler. Kaldstartangrep er fortsatt levedyktige: hvis opplåsingen er helautomatisk, kan en angriper gjenta et ubegrenset antall forsøk. Den klare løsningen er å kreve en PIN-kode før oppstart (PBA), noe som reduserer forsøkene til ett per av/på-syklus.

En annen kategori er sniffeangrep på TPM-bussenCPU-en ber om nøkkelen, TPM-en sender den; hvis lenken trykkes, kan nøkkelen lekkes. For dette formålet implementerer systemd "parameterkryptering" slik at utvekslingen krypteres; alternativt reduserer bruk av fTPM/Intel PTT eller kryptert minne eksponeringen. Det finnes relativt rimelige offentlige demonstrasjoner (selv med mikrokontrollere) som illustrerer gjennomførbarheten på bærbare datamaskiner fra store merker.

Det har også vært akademiske og praktiske sårbarheter: TPM-feil, faultTPM (med merkbar innvirkning på AMD) og saken bitpixie (CVE-2023-21563)Dette betyr ikke at TPM er ubrukelig, men du bør holde fastvaren oppdatert, forstå trusselmodellen din og ikke stole blindt på den.

BitLocker-status mot disse truslene

I Windows-verdenen er BitLocker den mest utbredte diskkrypteringen. Det har nå blitt bemerket at standardkonfigurasjonen (automatisk opplåsing kun med TPM) Den åpner døren for både kaldstart og TPM-kanalsniffing, ettersom den ikke implementerer parameterkryptering i systemd-stil. Dette gjør visse bedriftsdatamaskiner sårbare for angrep i løpet av minutter.

Anbefalingen der er å aktivere autentisering før oppstart via policyer/register eller CLI, noe som ikke er tilstrekkelig eksponert for den gjennomsnittlige brukeren. Husk også å sjekke hvor gjenopprettingsnøkkelen er lagret: den ligger ofte i brukerens Microsoft-konto, som Det er en annen risikovinkel hvis ikke kontrollert.

Offensivt/defensivt triks: Erstatt LUKS-roten for å tvinge passordet ditt

Det finnes en interessant vektor når det ikke er noen autentisering før oppstart. En angriper kan klone den virkelige LUKS-partisjonen, erstatte den med en annen LUKS med samme UUID og et passord han kjenner, og start datamaskinen opp. Siden PCR-målingene samsvarer, frigir TPM-en nøkkelen, men den samsvarer ikke med den falske LUKS-en, så initrd vil be om «gjenopprettingsnøkkelen». Ved å skrive inn passordet som er kjent for angriperen, kjører systemet ditt som root i initrd, og du kan deretter orkestrere tyveriet av den opprinnelige nøkkelen (for eksempel ved å montere den virkelige kopien over nettverket og bruke systemd-cryptsetup).

Tydelige avbøtende tiltak: aktiver autentisering før oppstart, utnytt systemd-pcrphase til å binde opplåsing strengt til initrd-fasen, og vurder å måle/binde mål-LUKS-volumet også (krever nøye design for å unngå onde sirkler).

Valg av partisjonering og andre nøkkel: beste praksis

opprettholde en gjenopprettingsnøkkel Det er obligatorisk: hvis TPM-en eller hovedkortet slutter å virke, er nøkkelen din som er knyttet til TPM-en ubrukelig. LUKS tillater flere spor (TPM bruker ett, gjenoppretting bruker et annet). I tillegg har det fordeler å skille /- og /home-partisjonene: du kan bruke streng måling med TPM a/ og bruk en sterk nøkkel eller FIDO2/YubiKey-enhet for /home, noe som reduserer den generelle tilliten til en enkelt mekanisme.

Hva skjer når du oppdaterer firmware eller kjerne?

Hvis du endrer fastvare eller berører UEFI-alternativer, vil PCR-er som 0/1 endres, og TPM-en vil ikke frigi nøkkelen før du registrerer deg på nytt. For kjerne og initrd, endringer er hyppigeHvis du ikke bruker en UKI med en signert policy, kan hver oppdatering tvinge deg til å bruke gjenopprettingsalternativet og registrere deg på nytt senere. Med en signert UKI signerer du den bare, og det er alt.

Fellesskapsnotater og observasjoner

I noen populære guider for visse distribusjoner har det blitt anbefalt bind kun PCR 7 når UKI og systemd-boot brukes, avhengig av Secure Boots sikkerhetstiltak og manglende evne til å redigere cmdlinjen. Det fungerer, men det er risikoer hvis du stoler på tredjeparter. Det har også blitt dokumentert en feil tidligere der trykk på Enter ville åpne et gjenopprettingsskall etter opplåsing. Det er lurt å holde versjonene dine oppdatert for å unngå overraskelser.

Interessante kommentarer ble delt i 2025/06: TPM-feilen fortsetter å påvirke AMD til en viss grad; wikier har lagt til spesifikke seksjoner om signerte PCR-policyer; og installasjonsprogrammet for en distribusjon som tilbyr FDE med TPM som en eksperimentell funksjon ble testet, med noen praktiske problemer (krever gjenoppretting ved første oppstart, avhengighet av snaps, dobbel diskkryptering), et problem som fortjener en grundigere revisjon.

En oppfølging med fokus på diskkryptering i Windows ble publisert i 2025/07. Den overordnede konklusjonen forsterker behovet for PBA og kryptering av TPM-kanalen., samt å begrense avhengigheten av tredjepartsnøkler i sikker oppstart.

Driftstips med tpm2-tools og systemd

For daglig bruk: Installer tpm2-tools og tpm2-tss. Bruker /dev/tpmrm0 som standard, og tpm2_pcrread/tpm2_pcrextend for testing og eksperimentering med PCR-er. Unngå å utvide produksjons-PCR-er med vilkårlige data: gjør dette i laboratorier eller bruk PCR 16 for testing.

Når du registrerer deg hos systemd-cryptenroll: –tpm2-enhet=auto oppdager TPM; –tpm2-med-pinne legger til PBA; –tpm2-pcrs=… velg PCR-ene dine; –tpm2-offentlig-nøkkel=… og –tpm2-offentlig-nøkkel-pcrs=… aktivere en signert PCR-policy (f.eks. knyttet til PCR 11 for UKI). Ikke glem –tørk-spor når du vil rengjøre et tidligere spor.

Hvis du ikke har TPM og systemd får deg til å vente på oppstart

Av og til, etter en oppdatering, prøver en tjeneste å bruke TPM selv om maskinen din ikke har den synlig, noe som forårsaker tidsavbrudd ved oppstart. Sjekk først at /dev/tpm* ikke vises heller ikke oppføringer i /sys/class/tpm.

# Verificación rápida
ls /dev/tpm*
ls /sys/class/tpm/

Hvis det ikke finnes noen TPM, sjekk /etc/crypttab har ikke alternativer som tpm2-device=autoHvis de finnes, slett dem og gjenoppbygg initrd-en din. Du kan også deaktivere målefasen på datamaskiner uten 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

Dette eliminerer unødvendig venting hvis utstyret ditt mangler TPM. Hvis du senere aktiverer TPM i BIOS/UEFI, fjern svartelisten og avmasker enheten for å gjenopprette målingene.

God praksis og tillitsbeslutninger

Noen er skeptiske til TPM fordi det er en «svart boks», akkurat som selvkrypterende disker. Dette er en rimelig tvil. Vurder trusselmodellen din og balanserer brukervennlighet, personvern og vedlikehold. For mange er TPM+PBA+signert UKI et stort sikkerhetssprang uten overdreven friksjon.

På maskinvare som tillater det, legg til kryptert minne og unngå å stole på tredjepartsnøkler i sikker oppstart; begrens kjeden til dine egne nøkler når det er mulig. Hold fastvare og kjerne oppdatert for å inkludere begrensninger for publiserte sårbarheter.

Å mestre /dev/tpm0, /dev/tpmrm0 og tpm2_pcrread/tpm2_pcr_extend-operasjonene åpner døren for målt oppstart og robust diskkryptering i Linux. Med UKI og en signert PCR-policy oppnår du driftsstabilitet, og å legge til en PIN-kode før oppstart beskytter deg også mot mer praktiske angrep. Nøkkelen er å velge PCR-er godt, signere det som endres ofte og alltid ha en god gjenopprettingsnøkkel..