Vastlopen op TPM hardware encryption bij Ubuntu 26.04

[Mative]

Ik probeer de nieuwe Ubuntu LTS op mijn laptop te installeren, maar ik loop vast bij de TPM.

Toen ik hem kocht heb ik er Ubuntu 24.04 op gezet om de laptop alvast te kunnen testen.
Om daarna de nieuwe LTS die nu is uitgekomen er op te zetten als daily driver

Ik heb toen 'disk encryption with passphrase' ingesteld (met de veronderstelling dat dit gewiped wordt bij een nieuwe clean install). Nu kan ik de nieuwe install ook encrypten via pasphrase, maar gezien Ubuntu de TPM ondersteund wil ik daar wel graag gebruik van maken.

Eerst liep ik vast omdat Secure Boot blijkbaar niet ingeschakeld stond.
Dit heb ik in de UEFI aangezet en via opties in de Ubuntu installer ook gelijk laten wipen.

Ik dacht dat het euvel verholpen was en probeerde opnieuw de LTS te installeren, maar ik liep tegen een ander foutmelding aan waarvan ik niet weet hoe dit precies op te lossen (of wat de melding überhaupt betekend):



Moet ik misschien Secure Boot resetten naar Setup Mode?



Of de PTT keys wissen (wat dat ook moge zijn)?



Of de laptop gewoon terug naar fabrieksinstellingen zetten.
(ik weet niet of dit ook direct effect heeft op de TPM)



Of geheel iets anders?
Ik hoop dat iemand hier wat licht op kan schijnen
Ik ben bang dat ik het probleem alleen maar groter maak
door misschien de verkeerde setting aan te passen.

[Hero of Time]

De error zegt in principe dat de TPM een andere eigenaar heeft en het deze niet zal toe-eigenen daardoor. Het clearen van de key wist eventuele informatie in de TPM register, terwijl het wijzigen naar setup mode de installer de mogelijkheid geeft om de eigenaar te worden.

Secure Boot is in principe niet nodig om TPM te kunnen gebruiken voor het unlocken van je volume. Ik heb het op m'n bedrijfslaptop namelijk zonder SB werken. Maar als je SB wel aan hebt, kan je de genoemde PCR7 gebruiken, wat gelinkt is aan je BIOS instellingen. Zou je namelijk je boot volgorde aanpassen, dan faalt de PCR7 attestation zoals dat heet. Zonder SB is PCR7 niet beschikbaar en heeft dat geen invloed op het wel of niet kunnen unlocken van je schijf omdat er andere registers gebruikt worden.

[Mative]

Dank voor je reactie.
Ik heb een aantal dingen geprobeerd, zit nu in een soort catch22 situatie denk ik.

Ik heb de PTT key gewiped en de Secure Boot staat op Setup-mode.
(Ubuntu blijft om 'deployed' secure boot vragen,
ik heb geen idee hoe daar omheen te gaan)

Daarna bleef ik tegen foutmeldingen aan lopen.

Uiteindelijk Ubuntu geïnstalleerd zonder hardware encryptie,
zodat alle encrypted volumes gewist worden voor een volledige nieuwe install.
En de Factory keys restored.

Daarna op een 'clean' systeem opnieuw een instal met Hardware encryption geprobeerd, maar kreeg weer een nieuwe foutmelding:



Secure boot is in de uefi 'Enabled', maar de Secure boot Mode blijft op 'Disabled' staan.

De boot volgorde (als het daar aan ligt) kan ik niet veranderen want de usb-stick met erop moet bovenaan blijven staan om het systeem opnieuw te kunnen installeren via de usb-stick.

Ik hoop dat er nog een andere methode voor een fix, ik heb geen idee wat ik nu nog kan proberen.
(of ik heb je uitleg gewoonweg niet goed begrepen)

[Hero of Time]

Je zou een toets moeten hebben om het boot menu te krijgen of vanuit het BIOS zelf een eenmalige boot override te doen.

Verders zijn dit soort zaken waarom men niet altijd even blij is met Secure Boot, want het geeft zoals nu te veel gezeik om iets te laten werken wat geadverteerd wordt als 'just works'. Zelfs met Windows heb ik op werk een laptop gehad die niet uit zichzelf Bitlocker activeerde, terwijl een ander systeem dat wel ging doen terwijl er niks was ingesteld om dit te regelen.

Je kan gelukkig altijd achteraf nog de hardware encryptie toevoegen, want wat het in feite doet is LUKS toepassen. Hier kan je extra unlock keys aan toevoegen, waaronder TPM. Zo heb ik met Clevis dit geregeld. Er is ook een Systemd optie en dat doet Ubuntu wellicht.

Sowieso is het heel onverstandig om puur en alleen op TPM te vertrouwen als je met schijfencryptie werkt. Want als je belangrijke bestanden erop hebt staan en om een of andere reden gaat je systeem stuk of faalt de attestation om je schijf te unlocken (BIOS update bijvoorbeeld of je past een instelling aan), kom je niet meer bij je data. Om extra unlock opties toe te kunnen voegen aan LUKS heb je een reeds geregistreerde methode nodig. Dit achteraf doen als TPM niet meer voldoet gaat dus niet.

[Mative]

Dus als ik het goed begrijp is het nu niet meer mogelijk om via de installer toegang te krijgen tot de TPM?

Weet je misschien waar ik een tutorial kan vinden om na de install de volumes te encrypten en via systemd de unlock key aan de TPM toe te voegen? Of is dit in mijn geval sowieso niet meer mogelijk en heb ik de TPM effectief... 'gebrickt'?

"Om extra unlock opties toe te kunnen voegen aan LUKS heb je een reeds geregistreerde methode nodig. Dit achteraf doen als TPM niet meer voldoet gaat dus niet."

Bedankt voor alle moeite!
Ik ben hier echt nog niet thuis in dit TPM gebeuren, ben al blij dat ik Ubuntu als daily kan gebruiken

[ Voor 5% gewijzigd door Mative op 27-04-2026 01:08 ]

[Hero of Time]

Wat is met het stukje dat je quote bedoel, is dat wanneer je achteraf, als je al niet meer bij je data kan, een andere unlock methode wil toevoegen, je te laat bent.

Het is ook niet mogelijk om achteraf de schijf te versleutelen, zoals dat bij Windows met Bitlocker wel kan. Je moet tijdens het partitioneren al een LUKS (dus encrypted) volume maken. Daar binnen maak je de effectieve partities met bijvoorbeeld ext4 of xfs als file system. Een LUKS volume werd in het verleden met een wachtwoord beveiligd en er zijn mogelijkheden om hier andere methodes aan toe te voegen, zoals een hardware key of TPM.

[Mative]

Oh sorry, dan heb ik je woorden in de quote verkeerd begrepen. Ik ben niet heel technisch
onderlegt, dus sommige verwoordingen komen bij mij blijkbaar niet altijd goed aan.

Ik dacht dat je bedoelde dat (omdat het mij niet meer lukt de settings
te veranderen) de TPM 'niet meer voldoet' (en dus effectief gebrickt is).

Zo ik het nu begrijp moet ik gewoon een nieuwe install met
encryptie (via LUKS) doen, want de TPM kom ik niet meer bij.

Wat mij nog niet duidelijk is of en in welk stadia kan ik een
andere unlock methode (zoals de TPM) nog toevoegen?
Is dat tijdens de installatie (die bij Ubuntu zo te zien niet mogelijk is) of achteraf wanneer
de install gelukt is en je een toevoeging toepast op de bestaande LUKS volumes?

[ Voor 5% gewijzigd door Mative op 27-04-2026 14:47 ]

[bikkel007]

Hi,

Ik zal de plank wel behoorlijk misslaan. Je zou eventeel kunnen kijken of je Hardware-based full disk encryption kan gebruiken. Er is dan wel een ssd nodig die SED /Opal ondersteunt.

https://wiki.archlinux.org/title/Self-encrypting_drives

[Mative]

@bikkel007
Ik heb geen idee of de SSD's dit ondersteunen.

Voor mij is het waarschijnlijk handiger om de boel via LUKS meteen te encrypten.
Dan maak ik het niet ingewikkelder dan het al is voor mezelf.

[Hero of Time]

@bikkel007, er is een verschil tussen een schijf die zelf encryptie doet, en software die het versleuteld. In veel gevallen wordt de data in de chips van een SSD al versleuteld en is de controller op de SSD verantwoordelijk voor de decryptie. Dus de memory chips zelf direct uitlezen levert onbruikbare rommel op.

@Mative, je kan zelfs een jaar nadat je LUKS hebt ingericht nog andere unlock methodes toevoegen, dus je zit niet vast aan het moment.

Wat is eigenlijk de reden om schijfversleuteling te willen toepassen? Is het een persoonlijke laptop of een van de zaak? Voor mijn persoonlijke systemen neem ik de moeite niet, mede omdat voor m'n hoofd pc beneden ik met een bluetooth toetsenbord en muis werk en BT werkt niet totdat de boel is opgestart. Ik zou dan een aparte, bedrade of via RF, toetsenbord moeten gebruiken om elke keer m'n schijf te unlocken als ik geen andere methode toevoeg dan passphrase.

Om achteraf TPM toe te voegen, kijk eens op de Arch wiki: https://wiki.archlinux.org/title/Systemd-cryptenroll. Dit heb ik ook geprobeerd, maar helaas mist een module bij mij waardoor het niet werkt en ik het nog met Clevis doe.

[Soldaatje]

Kan ook een BIOS probleem zijn, dat met een update verholpen is. Welke BIOS versie staat er op? De laatste is van februari ook met veiligheids-updates.

[Mative]

@Hero of Time
Het is een persoonlijke laptop waar ik ook wel wat administratie op doe.
De data kwijtraken is een kleiner probleem aangezien ik ook gewoon back-ups bijhoud.
Ik vind het een fijne gedachte dat als hij gestolen wordt of hem verlies de data niet op straat ligt.

Normaal doe ik dit met een passphrase. Simpele oplossing en makkelijk in te stellen. Nu de TPM zijn intrede heeft gedaan (en mijn laptop er toch een heeft) vind ik het fijner om daar gebruik van te maken. Dan hoef ik niet elke keer een passphrase in te voeren, is de data veilig en je hebt gelijk (aanname) een extra beveiligingslaag erbij.

Systemd-cryptenroll lijkt me zo te zien een mooie manier om (na de install) toch gebruik te kunnen maken van de TPM, zodat ik geen passsphrase meer hoef in te voeren en er na het instellen ook geen omkijken meer naar heb. Nu heb ik niet bepaald een hoog threat model, maar vind het wel fijn om te weten dat alles goed is beveiligd.


Je voorbeeld van een bluetooth toetsenbord had ik nog niet bij stilgestaan trouwens.
Ik heb voor mijn desktop een bedraad toetsenbord en gelukkig is dit voor een laptop geen probleem.

[Mative]

@Soldaatje
De laatste bij mij is van november.

Het was mijn veronderstelling dat met de BIOS het devies is 'don't fix if its not broken'.
Misschien zou dit kunnen helpen, maar ik ben bang dat ik dan mogelijk andere problemen in huis haal hiermee.

[Hero of Time]

Tegenwoordig is het helaas eerder nodig om je BIOS bij te werken vergeleken met vroeger. Kijk maar naar de nieuwsberichten van ~2 jaar geleden betreffende Intel's 13e en 14e generatie Core i processors. Daar zit een productiefout in dat icm agressief stroomverbruik tot razendsnelle degradatie resulteerde.
AMD had ook een issue toen de 7800X3D uit kwam en in sommige gevallen letterlijk ontplofte in de socket.
BIOS update loste beide issues op.

Overigens denk ik dat Ubuntu ook gewoon systemd-cryptenroll gebruikt. Ze hebben wel eens er een handje van om zelf iets te maken voor een reeds bestaande oplossing, maar hiermee verwacht ik eerder dat ze voor bewezen oplossingen gaan.

[bikkel007]

@Hero of Time

Ah, bedankt voor de uitleg.

Zelf heb ik dit ooit werkende gekregen en het werkte razendsnel. Ik ben alleen vergeten hoe ik dit voor elkaar gekregen had.

[Mative]

Dan probeer ik wel de BIOS te updaten om te zien of dat nog een effect heeft.

En ik ga kijken of ik met systemd-cryptenrol een TPM toe kan voegen.


Bedankt voor alle input!!!

[ Voor 13% gewijzigd door Mative op 28-04-2026 14:35 ]

[L0g0ff]

Hier staat nog een script die je kunt gebruiken luks met tpm te activeren.

Dat script is bedoeld voor ujust maar je kunt je kunt het zo ombouwen naar bash of een oneliner.

https://github.com/projectbluefin/common/blob/da96da288e1933b05d92c8a36ad72ee0df955b96/system_files/shared/usr/bin/luks-tpm2-autounlock#L43

[Mative]

@L0g0ff
Ik ga kijken of ik hier kaas van kan maken.

Bedankt voor de tip!

[segil]

Interessant topic, ik volg deze even.
Ik ben een half jaar geleden overgestapt van Windows en het gemak daar om naderhand Bitlocker + TPM te gebruiken, i.c.m. hibernation, mis ik wel in Linux. Het liefst hibernate ik mijn desktop elke avond om stroomkosten te besparen, en weer snel verder te kunnen de volgende dag. Maar de support voor hibernation lijkt al beperkt te zijn onder Linux, laat staan i.c.m. disk encryption.

Ben ik en Mative dan ook de enige die liever z'n persoonlijke data versleutelt, tegen diefstal, zodat het niet op straat komt te liggen? En het hoeft niet eens alleen te gaan om diefstal. Stel dat mijn nieuwe disk defect raakt en ik 'm wil opsturen onder garantie voor reparatie, dan is het wel een fijne gedachte dat niets mis kan gaan met mijn data. Idem dito als ik 'm wil doorverkopen in de toekomst.

[Hero of Time]

segil schreef op vrijdag 1 mei 2026 @ 11:11:
Interessant topic, ik volg deze even.
Ik ben een half jaar geleden overgestapt van Windows en het gemak daar om naderhand Bitlocker + TPM te gebruiken, i.c.m. hibernation, mis ik wel in Linux. Het liefst hibernate ik mijn desktop elke avond om stroomkosten te besparen, en weer snel verder te kunnen de volgende dag. Maar de support voor hibernation lijkt al beperkt te zijn onder Linux, laat staan i.c.m. disk encryption.

Zakelijk heb ik m'n installatie wel volledig versleuteld, met de EFI en Boot partities buiten LUKS zodat het nog kan opstarten. Unlock via Clevis-TPM* en kan hibernate gebruiken. Enige moment dat hibernate niet meer mogelijk is, is als je secure boot gebruikt. Voor het unlocken via TPM ben je dus niet afhankelijk van SB, maar het geeft wel een extra PCR die 'fatsoenlijk' getriggered wordt als er iets aan de opstartvolgorde wordt gerommeld.

* Kan ook met systemd-cryptenroll, zolang je initramfs de juiste modules bevat.

Ben ik en Mative dan ook de enige die liever z'n persoonlijke data versleutelt, tegen diefstal, zodat het niet op straat komt te liggen? En het hoeft niet eens alleen te gaan om diefstal. Stel dat mijn nieuwe disk defect raakt en ik 'm wil opsturen onder garantie voor reparatie, dan is het wel een fijne gedachte dat niets mis kan gaan met mijn data. Idem dito als ik 'm wil doorverkopen in de toekomst.

Laptops versleutelen begrijp ik wel met diefstal. Een desktop, zeker een redelijk grote behuizing, is wat lastiger om even onder je arm mee te nemen. Defecte schijven laat je eigenlijk niet meer repareren, als het stuk is, is het stuk. Een SSD is sowieso kansloos om het repareren. Als het om een defecte memory chip gaat, heb je aan de individuele chip toch geen klap om data te lezen, dat is al versleuteld door de controller en mogelijk zelfs gefragmenteerd over andere chips.

Ik ben dus niet zo bang dat wanneer m'n SSD ontoegankelijk wordt, men de data eruit kan peuteren. Iig niet eenvoudig door 'm in een USB dingetje te steken.

[segil]

Hero of Time schreef op vrijdag 1 mei 2026 @ 20:02:
[...]

Zakelijk heb ik m'n installatie wel volledig versleuteld, met de EFI en Boot partities buiten LUKS zodat het nog kan opstarten. Unlock via Clevis-TPM* en kan hibernate gebruiken. Enige moment dat hibernate niet meer mogelijk is, is als je secure boot gebruikt. Voor het unlocken via TPM ben je dus niet afhankelijk van SB, maar het geeft wel een extra PCR die 'fatsoenlijk' getriggered wordt als er iets aan de opstartvolgorde wordt gerommeld.

* Kan ook met systemd-cryptenroll, zolang je initramfs de juiste modules bevat.


[...]

Laptops versleutelen begrijp ik wel met diefstal. Een desktop, zeker een redelijk grote behuizing, is wat lastiger om even onder je arm mee te nemen. Defecte schijven laat je eigenlijk niet meer repareren, als het stuk is, is het stuk. Een SSD is sowieso kansloos om het repareren. Als het om een defecte memory chip gaat, heb je aan de individuele chip toch geen klap om data te lezen, dat is al versleuteld door de controller en mogelijk zelfs gefragmenteerd over andere chips.

Ik ben dus niet zo bang dat wanneer m'n SSD ontoegankelijk wordt, men de data eruit kan peuteren. Iig niet eenvoudig door 'm in een USB dingetje te steken.

Mag ik vragen wat jij doet op je prive computer aan einde van de dag, als je deze wilt afsluiten? Suspend? Power off? Of laat je 'm 24/7 draaien? Ik doe nu suspend, maar liever hibernation vanwege de stroomkosten.

[Hero of Time]

segil schreef op zondag 3 mei 2026 @ 10:56:
[...]

Mag ik vragen wat jij doet op je prive computer aan einde van de dag, als je deze wilt afsluiten? Suspend? Power off? Of laat je 'm 24/7 draaien? Ik doe nu suspend, maar liever hibernation vanwege de stroomkosten.

Ik zet 'm in slaapstand, o.a. omdat ik geen swap heb. Ik ben verders alleen en heb zonnepanelen, puur voor stroomkosten zal volgend jaar spannender zijn dan m'n pc in slaapstand aan laten.