is there any use for TPM on Linux?

[-]

Arin_Horain@reddit

TPM doesn't encrypt, it's more like an integrated smartcard that holds keys. You can use it to decrypt a LUKS encrypted partition automatically, they're different things.

[-]

Farados55@reddit

Wait if if I encrypt my home partition when I install fedora, enabling secure boot can automatically unlock it?

[-]

Zettinator@reddit

That howto is pretty outdated. Nowadays you should use systemd-cryptenroll. It offers a much more streamlined operation, too.

[-]

Outdated and insecure. It does not measure boot stages (Bitlocker and systemd use PCR11 for that purpose) and the OS itself is not part of the trusted boot chain (the boot env boots any OS found in the partition with the desired uuid). So without tampering it, the boot env can be tricked to boot a rogue OS, from where an attacker can unseal the TPM secret. This attack has been shown multiple time, it is easy to conduct for anyone understanding the boot process, and many "tutorial" related to various distros have this flaw. In contrast, proper usage of measured boot phases fix this flaw. Ukify makes things easier

[-]

Waffle-HD@reddit

I wish I knew this a month ago when I spent forever setting up clevis.

Is there an easy way to remove clevis and replace it with systemd-cryptenroll?

[-]

brick-pop@reddit

Would atomic distros be any safer here?

[-]

NoArmNoChocoLAN@reddit

Not really. AFAIK, atomic distros looks for a "base layer" which is mounted read-only with a temporary writable overlay, but this base layer is still not authenticated, which makes the attack possible. Possible solutions are 1) to extend some PCR before switching root so that the LUKS key cannot be recovered anymore, from the (maybe rogue) system or 2) Make the kernel/initrd verify the mounted root filesystem before switching root (using something like dm-verity).

[-]

blarg-blarg-blarg@reddit

This ^

[-]

vip17@reddit

Actually it should be something like this: have separate / and home partitions, encrypt / with the key in TPM, and encrypt home with your login key, so that when booting up it'll enter the login screen directly. Something similar to Android: older versions use FDE and require you to unlock before it can boot up, and newer versions use FBE where the files needed for basic functions like alarm, timer, cellular... will be decrypted automatically by TPM, and your files will be decrypted when you unlock the device

[-]

Arin_Horain@reddit

Secure Boot ensures that your boot process wasn't tampered with by signing the kernel, boot loader and other stuff strictly relevant for booting and by only allowing signed software to run on boot. Drive/partition encryption is different from that but both can leverage a TPM.

[-]

hexagonum@reddit

https://wiki.archlinux.org/title/Trusted_Platform_Module

[-]

ledoscreen@reddit

TPM itself does not encrypt data on the disk. This is handled by solutions like LUKS in Linux or BitLocker in Windows.

It allows you to "seal" encryption keys for the disk in such a way that they can only be unsealed when the system boots into a known and verified state.

In my opinion, TPM is most useful on linux-servers because it provides automatic secure boot (which is critical for uptime), remote attestation, and the protection of keys, including those for VPNs, SSL/TLS certificates, and other critically important services.

[-]

mephinet@reddit

Aah, for servers - thanks for that insight! I was always thinking of notebooks and questioned its utility there (not knowing who is in front of the device) - but for servers, this argument doesn't count.

[-]

anxiousvater@reddit

Using secure boot helps protect your OS by locking down a few eBPF system calls (writing user memory one, esp). This helps Kernel protect against eBPF malware.

More on this here :: https://github.com/iovisor/bcc/issues/2565

[-]

Dannyps@reddit

What do you mean by saying that secure boot is critical for uptime?

[-]

damentz@reddit

He said it being automatic. Do you want to fly into the data center to type your boot time decryption password?

[-]

spin81@reddit

That's not how I understand secure boot works. I thought that was basically a signed boot loader.

[-]

fractalfocuser@reddit

TPM is still holding the sig of the bootloader
TPM can hold encryption keys as well. OP is talking about securely booting in terms of encryption and not Secure Boot^TM bootloader sig. Confusing word choice but valid

[-]

spin81@reddit

I guess I see what I'm confused by but also I should look into what Secure Boot (with capitals) actually is and isn't. I always figured it was just that Microsoft wanted to sign other people's boot loaders, but it looks like I'm way oversimplifying it. I figured it was security theater but if it can use a TPM then maybe not so much!

Thanks for indulging me by explaining.

[-]

biffbobfred@reddit

If you’re flying into the DC you should reconsider your workflow. You need something with an IPMI on it.

But even with an IPMI you have someone on a remote console typie typie typie. 4 9s is less than an hour. You getting a console working and typing a password that’s actually a big part of the downtime budget. You probably just blew a 6 9s budget just with that.

[-]

raedr7n@reddit

It being automatic is what's critical for uptime, is what I would guess they mean.

[-]

andymaclean19@reddit

Just be careful about backup / restore if you use it for SSL certificates, etc.

[-]

Successful-Whole8502@reddit

Tpm is like a doiramn... if he doesn't approve? You are not invited...

[-]

Dwedit@reddit

TPM connects to the LPC bus, which is actually an ISA bus. With an adapter, you can plug an oldschool Sound Blaster card in there.

[-]

Zettinator@reddit

While that is the classic way to add a TPM to a system, on most newer platforms, the TPM is embedded in the chipset or SoC. It offers much better security as the traffic between TPM and CPU cannot be intercepted.

[-]

CrazyKilla15@reddit

Newer platforms also encrypt the traffic over the bus anyway

[-]

bubblegumpuma@reddit

On some newer systems it can be SPI or some extension thereof, IIRC. But yes, it's quite fun. The older ASRock version of this header also has SMBus on it, which is a subset of I2C, so you can put some interesting things on there - I've put on a GPIO expander and an OLED screen, just for laughs. Who needs a Raspberry Pi? :)

They barely worked, and most drivers and programs for i2c devices expect capabilities SMBus doesn't have, but it's good for a laugh, could be fun for a purpose-built hack rather than trying to run ready-made programs / drivers like I was.

[-]

recaffeinated@reddit

Sure, it'll make it much easier for criminals and attackers to decrypt your data via security flaws in the TPM

https://www.tomshardware.com/pc-components/cpus/amd-partners-roll-out-new-bios-updates-to-patch-tpm-vulnerability-error-with-amd-cpus-addressed-with-agesa-1-2-0-3e

Especially when it emerges a few years from now that Microsoft have compromised the TPMs on the NSA's behalf to give them backdoor access.

It'll also make it easy for software companies to extend DRM to your Linux system, by ensuring that you can only use whatever software you've paid for on the machine with that TPM - since the primary advantage of TPMs to Microsoft is DRM

https://www.techtarget.com/whatis/definition/trusted-platform-module-TPM

And all of this so you don't have to type in a decryption password on boot. Such an inconvenience that is.

[-]

SaltDeception@reddit

Sure, it'll make it much easier for criminals and attackers to decrypt your data via security flaws in the TPM

Like any other security vulnerability, you patch or mitigate and move on.

Especially when it emerges a few years from now that Microsoft have compromised the TPMs on the NSA's behalf to give them backdoor access.

CPU vendors control the firmware, Window and Linux just use the API for TPM operations. Microsoft could theoretically give the NSA or someone else the BitLocker keys for a system under very specific circumstances that do not actually compromise the TPM, but they couldn't give Linux keys, even in a dual-boot scenario, since the TPM is never directly read by the OS. The whole point of the TPM is to perform the cryptographic operations itself; the OS hands off the operation to the TPM through the API.

Intel or AMD could technically do what you're saying through targeted firmware, I suppose, but if you're actually worried about nation states decrypting your drive, then yeah a TPM is probably not the route for you anyway.

It'll also make it easy for software companies to extend DRM to your Linux system, by ensuring that you can only use whatever software you've paid for on the machine with that TPM - since the primary advantage of TPMs to Microsoft is DRM

There is no evidence to suggest that Microsoft has ever used the TPM for DRM, nor is there any evidence to suggest that they have it in their plans. It is technically possible for them to do so, but there is no real advantage and the disadvantages are plenty.

If you want to hate on Microsoft and Windows, be my guest. But don't be an idiot about it if you want anyone to ever take you seriously.

[-]

Outrageous_Trade_303@reddit

https://wiki.archlinux.org/title/Trusted_Platform_Module

[-]

MantisShrimp05@reddit

as many have noted already the TMP works with your encryption of choice to hold the keys. Systemd folks have been pushing for stronger security by default on linux for awhile.

In this vision, every layer of the OS is encrypted from the bootloader with secure boot, to securing your partitions with dm-crytp, to your home directory with homed, leaving only user land applications which would be sandboxed into flatpak apps. All of the keys to these encrypted pieces will be self signed and stored in the TPM.

If security is a major goal for you then this should be exciting. I think trying to make linux more secure by default is an admirable goal and I look forward to the day it all just works.and if you are in an environment that requires some part of another be encrypted you can start assuming lots of hardware just has a TPM now with the requirement from windows.

With that said, as of right now, setting all this up is something that is up to the user and so how much its worth it depends on your use case. I would ask what needs to be encrypted.

For example, I have a portable homed ssd that attaches to different computers and I use a hardware key since they need to travel. But my partitions on my desktop are encrypted and the keys live on the TPM.

[-]

arkane-linux@reddit

It can store passwords, keys etc..

For example, the TPM can release they password to your LUKS partition to automatically unlock it on boot.

You could also store SSH or PGP keys inside of it. So even if someone has physical access to the machine they will be unable to extract them.

It can be used to validate if the machine was tampered with at software or hardware level by messuring the boot process, this test has to pass or it will not unlock and release its contents.

Linux may also use it for cryptographical operations.

[-]

Damglador@reddit

You could also store SSH or PGP keys inside of it.

For anyone interested, there's an Arch wiki page (of course there is) for TPM with links to respective guides: https://wiki.archlinux.org/title/Trusted_Platform_Module

[-]

garmzon@reddit

I use mine

[-]

andymaclean19@reddit

Bitlocker like functionality is a good use case. If you are an employer and you want to give out Linux laptops that boot securely and are tamper proof this is the way. It’s what it gets used for in Windows a lot.

The alternative is giving the user the decryption key to decrypt the file system and making them type it in every time they boot up, which is annoying and technically less secure.

[-]

Jumpy-Dig5503@reddit

As others have said, the TPM can be used to store the encryption key for LUKS, preferably in combination with Secure Boot.

Secure Boot can keep your OS from booting if its boot loader is corrupted and/or tampered with. Maybe also the kernel and init RD depending on how your distro is set up.

TPM can check for Secure Boot tampering before unlocking the LUKS key.

LUKS would still secure the main system.

I know there are other things that TPM and Secure Boot do, but I didn't want to clutter my post too much.

[-]

PrerakNepali@reddit

Yeah, TPM is useful on Linux. It doesn’t do encryption like LUKS, but it can securely store keys and auto-unlock LUKS if the system is trusted. It’s good for extra security, especially with LUKS2.

[-]

Virtual-Cobbler-9930@reddit

Yeah, it's very useful!

...I passthrough it to windows VM.

[-]

Klapperatismus@reddit

It’s a tamper protection that is secure against most professionals.

[-]

elfmad@reddit

Luks (sometimes disks mysteriously disapear in datacenters), store certificates for booting iPXE and UKIs, store certificates for server identification.

[-]

Misicks0349@reddit

the TPM can be used for signing your entire system all the way to your login prompt so you have a fully verified boot chain using dm-verity, so yeah its pretty important and work is going into making distros that work that way

[-]

Tyr3al@reddit

Well you could use it as a storage for SSH keys. Never tried it, but a saw a talk at the CCC about it. Here is a reference from the Arch Wiki: https://wiki.archlinux.org/title/Trusted_Platform_Module#SSH

[-]

Traace@reddit

I use TPM on Linux to hold my custom Keys for secure boot

[-]

IBNash@reddit

BIOS level TCG/OPAL disk lock + FDE that uses TPM with tpm-key provides peace of mind for stolen laptops.

[-]

zam0th@reddit

There isn't even a use for TPM on Windows.

[-]

fishter_uk@reddit

If you like analogies, then a TPM is like a key safe. But the key safe can be configured to hand out a key when certain conditions are met.

[-]

senectus@reddit

In the Corp space hell yes

[-]

JuliusFIN@reddit

One thing I do with TPM is I store an age-key in it with age-plugin-tpm. This age key is used to decrypt all my other secrets which I encrypt with sops using age. This means the TPM backed master age key can never be read.

[-]

OMPCritical@reddit

An interesting video on tpm & bit locker hacking that some of you might find interesting. :)

https://youtu.be/wTl4vEednkQ?si=eD4H9qlPQ_pUtTI1

[-]

nightblackdragon@reddit

TPM is not doing any encryption. What TPM can do is store encryption key that can be released when certain conditions are met and allow BitLocker on Windows or LUKS on Linux to decrypt your hard drive without asking for password. When you configure it you are storing trusted system state (on Linux you can choose what is it but it can be firmware integrity, Secure Boot state, kernel, initrd, command line, bootloader etc.) with encryption key in TPM. During boot system sends its current state to the TPM and if it matches with the state stored in TPM then TPM releases encryption key. When something changes (for example you changed command line) then current state won't match state stored in TPM and it will refuse to release key prompting you to enter decryption password.

[-]