I enjoyed reading this and other prompt's you did, @dos2unix. Talking about transparency earlier, I'd enjoy it even more with the prompts included. Prompting the engines is a skill to learn and knowing the prompts is extremely important to interpret the results for yourself.
How To Disable The TPM Under Linux
- Thread starter Alexzee
- Start date
I have to say I feel more comfortable with TPM now. Not that I have a use for it. And of course the abuse of it by M$ encrypting drives without asking the user is just unethical and causes many issues when repairs need to be made of windoze and in many cases causes loss of everything on the system.
I have exactly one data point. In my defense, I've only done so once and don't know a darned thing about other people and their experiences.
When I installed Windows 11 in a VM, again just a single data point, it very much asked me if I wanted to use encryption. It even explained what it was and that it is called BitLocker.
It was optional, and I installed the VM without it.
That's just a single data point, but it is what I experienced. I'm not even sure if it was checked as a default. I don't recall that. I just know that it asked and I declined.
This was the bog-standard install from the current Windows 11 .iso file. The VM was via VirtualBox.
You were lucky. What happens to people using an actual pc is it installs and as soon as they do a M$ account the next update enables the encryption and never asks. People don't even know they have or need the key so when it comes to me for repair they lose it all as they are unable to retrieve the keys needed. That is on them of course but if they don't know then they get hurt by it. They do not know better. Just like they don't know any better than doing a M$ account. That is because it is hidden from the normal user. I tend to disable the bitlocker service entirely in windoze and I tell people it was done so if they object it can be turned back on but once they understand what it is they leave it off. I think your one data point was either great luck on your part or something to do with VM. I have qemu VM with win 11 and no issues with encryption either.
Thanks for the heads-up. I’m going to check out the DBSC tech in Chromium, looks pretty interesting.
So after reading this thread, I've been wondering what practical use TPM has in Linux — and I finally found one worth sharing!
I wrote a small tool for Devuan (and other non-systemd distros) that unlocks your LUKS full-disk encryption with a short PIN at boot — but only when you're in range of your home WiFi. Away from home, it falls back to your regular LUKS passphrase as usual.
The PIN is sealed inside the TPM chip — it cannot be extracted from the hardware. Make sure TPM is enabled in your UEFI before using it.
Useful if you have a fully encrypted laptop and travel regularly.
TL;DR: In home network - power on, enter short PIN, you're in. While travelling - long password to unlock, as usual. Perfect.
https://gitlab.com/UyosDP8sQsgO/tpm-luks-wifi-pin-unlocker
I wrote a small tool for Devuan (and other non-systemd distros) that unlocks your LUKS full-disk encryption with a short PIN at boot — but only when you're in range of your home WiFi. Away from home, it falls back to your regular LUKS passphrase as usual.
The PIN is sealed inside the TPM chip — it cannot be extracted from the hardware. Make sure TPM is enabled in your UEFI before using it.
Useful if you have a fully encrypted laptop and travel regularly.
TL;DR: In home network - power on, enter short PIN, you're in. While travelling - long password to unlock, as usual. Perfect.
https://gitlab.com/UyosDP8sQsgO/tpm-luks-wifi-pin-unlocker
OP
Good information and congratulations on writing the tool for Devuan.
Are you sure with certainty that the pin can not be extracted from the hardware?
Thank you.
The LUKS key is sealed inside the TPM chip and is not stored anywhere on disk. To unseal it, the correct PIN must be provided at boot. This protects against offline attacks — someone stealing your drive or your powered-off laptop cannot access your data without both the PIN and your specific hardware.
That said, TPM chips have been attacked in the wild in the past.
However, most modern laptops use a firmware TPM (Intel PTT) running inside the CPU itself, rather than a separate chip. This means the key never travels over an external bus, which eliminates bus sniffing attack class entirely.
So the honest answer is: TPM-based security is not unbreakable, but the realistic attack bar is very high.
Sounds interesting! What did you choose that over a tang/clevis setup, as that would also only work on your local lan?
It seems to me that they should exchange a key that's based on the private key and that it should be done in a rotating manner. This would essentially work like an OTP while using an accurate clock alongside it. This wouldn't be a unique application. It wouldn't be unlike some automobile security features -- except it's never broadcast over the air, and the allowed time would be measured in milliseconds. As it'd be tied to a clock signature, it'd make it difficult to do anything with it, even if they managed to capture it.
That seems like it'd be a good solution. It's not even unusual tech. Granted, it was not my major and I only had a few courses, but good crypto is pretty hard. Fortunately, in this case, the work has already been done. We have the building blocks for it. We just need to assemble them properly.
Add to that some interface security... For example, after 10 guesses, the system slows down, and you have to wait to try another password. After each failed password attempt, you increase the wait time. After x-number of failed attempts, the TPM data gets wiped, you lose the data, and your only choice is to do a clean install.
Also, it should be clearer for the generic end-user. They should know that encrypting their data means that the data is lost if they forget the password/passkey/PIN/etc... From what I've seen, people are genuinely surprised that encrypting data actually encrypts the data and that there's (usually) no way to recover said data. If it were possible to recover the data, it wouldn't be worth encrypting in the first place.
This was actually my first ever hands-on experience with TPM, I went in not knowing much and learned as I went.
The first thing I discovered is that clevis-tpm2 doesn't support interactive PIN prompts at boot. Clevis with TPM2 is designed for automatic, unattended unlocking, the PIN in its config is stored in the LUKS token header and fed to the TPM automatically, the user is never asked to type anything. So clevis on Devuan effectively gives you silent auto-unlock or nothing.
That's when I decided to script my own solution using initramfs and tpm2-tools directly.
As for Tang, yes, it's a more sophisticated approach, but it requires network infrastructure on a separate machine that gets queried at boot time. That felt like too much for a first attempt. The WiFi presence check is simpler and good enough for my needs right now.
Really interesting ideas, thanks for the detailed response. Something worth exploring for a future version.
OP
You're welcome.
