Linux and TPMs with systemd measured boot [video]
media.ccc.de
media.ccc.de
I am not a huge fan of relying on this, I cannot recall numer of times where I had to recover my files from live USB or by plugging my drive into another PC - both of which will get difficult to do when my true password sits in TPM on the (potentially bricked) motherboard. But I guess that if it can be used in addition to regular password (e.g. use regular password when TPM is missing, use PIN if it works) then it's fine
What's a good alternative for Linux?
[1]: Acronis TrueImage, but there are others.
Filesystems without snapshots can't be disk cloned that easily, but tools like Timeshift will try to replicate snapshot behaviour using hardlinks, so I assume backups of Timeshift snapshots should also suffice.
Timeshift can be configured in various ways, including making daily snapshots. I mostly use it for periodic snapshots and snapshots taken before the package manager runs (as a poor man's System Restore alternative).
I don't think Timeshift supports automatically sending snapshots just yet. For that, you'd need to set up a cronjob or systemd timer.
If you have a BTRFS volume on a server that exists purely to receive backups and separate the subvolumes sufficiently (i.e. using specific subvolumes for the different backed up devices), I don't think send/receive should be a problem.
I wouldn't back up to the root partition of a running system, I think a dedicated data volume makes a lot more sense design-wise.
And I seem to recall a recent vulnerability where people were able to bypass the display manager login on some graphical desktop Linux distro.
I just don't feel comfortable shifting the threat to this part of the OS, because desktop Linux has not had the extensive testing required yet. It reminds me of when I was in school and you could bypass NT4 or Windows 98 logins by mashing the Enter key or doing weird user input combinations. Basically manually fuzzing.
If TPM only adds convenience then I'd prefer to continue entering my LUKS password, and my login password, separately.
Isn't this the entire point of full disk encryption? You mention cost, but what is even the benefit of encryption that's unlocked by just booting?
So, data on a stolen laptop which has an unprotected TPM (no PIN to boot) can be considered compromised.
If a laptop is stolen the thief can wait sufficiently long for some vulnerability to be discovered somewhere in the stack. With LUKS only the LUKS encryption has to be good and full disk encryption protects the data.
Ideally, your login screen is secure and allows no bypasses into a shell or similar, so you cannot really access any files on the hard drive.
And if you modify some system files or boot another operating system to get around this, you are required to know the disk encryption password to get to them.
This gives you the benefit of system integrity verification at time of boot, but also requiring your input to release the keys (and meaning you can't get to the system lock screen without the PIN).
In my opinion all the TPM achieves in this case is ensuring you lose your data if the machine dies (or if some OS update fucks up and doesn't properly ensure the TPM acknowledges the new version as valid).
That said it does help against the so called evil maid attacks, given that it would lock itself out if anyone modifies the OS, so if that's part of your threat model then it is useful, I guess.
Because there are different kinds of keyboards out there, with different layouts, so if you switch keyboard you could find yourself unable to input the password. Imagine typing a "non-English" letter in the password and then switching to a US layout keyboard without that letter. Sure, a rare scenario, but with hundreds of millions of users you will hit it.
(for win home users: regedit?)
It doesn't "shift" it, it's not the same password. It doesn't work the way it does on a mac, where your user password unlocks the drive so you don't have to enter it again to unlock your user session.
Assuming you don't have autologon turned on, without this scheme, you'd have to enter two passwords: LUKS first during boot, then your user password in the XDM. With this scheme, you skip the first password.
But yeah, if you don't enable any other protection, like TPM+PIN, your PC will boot on its own all the way to the login manager. So if you don't trust your login manager, that's an issue.
Annoyingly, this is a random 16 byte value that's translated into a numeric string that only Ubuntus's cryptsetup wrapper seems to use. You need to convert it into an actual key if you want to re-enroll your TPM or add a key file/passphrase to another slot.
If you don't back up the recovery key, your data is lost.
For the curious, to avoid "most" QWERTZ/AZERTY differences among Latin layouts:
cbdefghijklnrtuv
Does anyone remember the good ol' days of hitting spaces 127 times at a SunOS "login:" prompt to gain its root shell?
Why should we trust such chips more than purely software based approach?
It's all trade-offs.
The separate authentication server can be configured to only hand out the storage encryption key on expected reboots, so if the machine unexpectedly walks off and then powers back on that server would refuse to hand out the key, thus the stolen machine is now useless.
Try it on a secure boot and tpm2 enabled Bitlocker encrypted drive, the only way to get in is via the recovery key after a configurable number of attempts.
For example I know that the police in my country use off the shelf disk cloning devices and then some basic forensics software for analyzing the disk image. This can be done by an average computer technician, and such a TPM scheme would totally prevent them from extracting data. Of course for bigger cases they can invest some more effort, but they would have to be sure that there is some important data there to justify the cost.
There's more applications of trusted computing and TPMs than that; one of them is using it to safeguard your own keys.
I think you misread the GP. Your definition of DRM is exactly what GP described as his use of the TPM.
>>I sell a device. There are lots of them in hands. You still aren’t getting my device key off of it. Yes, you can use that device all you like, but you aren’t going to clone it and make more.
What the GP describes is not safeguarding the nominal owner of the devices' keys. GP is restricting the nominal owner of the device on behalf of himself as the manufacturer. This is leveraging the TPM for DRM.
Other possible less nefarious uses of the TPM are irrelevant to this point.
Or something else! Payment cards work like that – they hold keys that nobody is supposed to be able to duplicate; certainly not third-parties, but also not the legitimate account-/cardholder.
There are plenty of uses for trusted computing other than DRM; they're just usually not as disruptive/frustrating to legitimate customers as DRM (and as a result are not as contentious), so they don't get as much attention.
TPMs jeopardize the ownership of a device. Consumer devices are already sold where you can't (easily) inspect or change anything.
Even a user-controlled TPM can be used as storage for keys used to usurp control of the device. The existence of IME and PSP enables manufacturers to have more control over computing devices than the people who buy and operate them.
There is no moral defense for sabotaging ownership.
That’s all very well until you start talking about hardware that does things like providing video of the inside of someone’s home. I’m still behind being able to modify them and use them as you please, but if you do so that should be self-evident, because otherwise *someone else* can do so, and you won’t know until video appears on the internet if you walking back from the shower.
TPMs don’t necessarily mean that you can’t modify a device you’ve bought, it just means that things like the API key which connected it to the backend will be invalidated and you’ll have to set the device up some other way. That’s a safety mechanism, and even I want it to be present in hardware I buy.
Likewise I don’t want someone to be able to take a doorbell from the front of my house, extract my wifi credentials from it, and pivot from that to compromising the entire network.
I’m sure some people will say “well just don’t have those things”, and I’m inclined to agree, despite having worked on such devices I’m not sure they’re actually hugely useful to most people. People are buying them though, they’re in the wild, let’s make them as secure as possible.
> No, DRM is safeguarding other people's keys on your device.
Correct - in this case, safeguarding mainly means making sure that the nominal owner of the device does not extract the keys.
> There's more applications of trusted computing and TPMs than that
Correct
> one of them is using it to safeguard your own keys.
Questionable - needs a definition of safeguarding. Making sure that the keys cannot be backed up would be a strange definition.
"What's your threat model?"
If it's people stealing your laptop and fear of identity theft, use the TPM.
If it's the NSA, ¯\_(ツ)_/¯
There's a poster below that provides a more reasonable use case for TPM. Headless server where asking for password on boot is undesirable (eg after a power failure)
A TPM provides hardware-backed bruteforce protection which means even an easy passphrase can be made secure as the number of attempts is rate-limited by the TPM (to a level much slower than even the hardest hashes).
People tend to trust them more because they belong to them, not Microsoft, or Hollywood, or the board manufacturer.
A YubiKey/external TPM in comparison has no way to know whether it's being fed true PCR readings from the host or fakes from a malicious attacker, so at this point it will be no different (in the context of full-disk-encryption) from just having a dumb USB storage device with your LUKS keyfile on it.
Netflix playing at lower resolution for example.
Widespread TPM is actively harmful for most people, and the biggest blow to general purpose computing in recent years.
Nobody is forcing you to use Netflix. If you don't like it, leave for a better DRM-free service. That's the free market at work.
Or maybe they will all move to TikTok and live from advertising and you'll get a chance to complain about how you hate ads then.
Which one?
Is it a free market if 99.9% of companies copy the single most profitable approach to stay afloat (see smartphones), or the entire market is dominated by content rights holders that would make you pay license fees to use the toilet if they could?
That doesn't entitle you to a specific video unprotected. But the video market is pretty unquestionably not dominated by content right holders (if by that we mean major studios).
TPM is pretty much useless for DRM.
However, TPM-backed DRM on general-purpose OSes is impossible in the current world and is fear-mongering. The TPM can attest to a remote party that you've booted a certain OS, but this OS would need to maintain that chain of trust all the way for it to be effective. That's impossible due to the number of device drivers (which need kernel-level access by design) and various other privileged components a general-purpose OS requires (security software, etc), not to mention the attack surface of all that.
For a hypothetical TPM-backed DRM to work, you'd need Netflix to ship you an entire OS image that you can boot (which the TPM will prove to them that you've booted), and that OS image needs to magically have all the drivers for every potential PC their customers might have, and you need to convince people to reboot their machine every time they want to watch it.
This is all unnecessary considering the current status-quo of DRM is good enough, Widewine does not require a TPM and relies entirely on security by obscurity and it's considered good enough by the industry.
This is all theory though - workable TPM-backed DRM would require so much vendor cooperation, secure programming and break legitimate use-cases that it won't happen any time soon on conventional hardware. It would be cheaper for the media industry to just sell streaming boxes or exclusively target more locked-down platforms (iOS, Android) than try to make it work on generic Windows PCs.
But as you say, that's a much, much smaller attack surface than trying to validate the OS.
Why don't you think that can work? Windows already limits drivers to ones signed by Microsoft - or else you have to be in "test mode" where - among other things - DRM-protected video playback is disabled!
And Windows already contains a "protected media path" component which protects encrypted DRMed video data.
Sure, there will probably be bugs in a drivers sometimes allowing for a signing bypass and then a DRM bypass if the DRM is done in software. Once they're discovered, those drivers will be blacklisted, and yes, that will mean you can't use that hardware. And the masses will blame the pirates.
I don't believe driver signature enforcement restricts what the driver can do, intentionally or as a result of a vulnerability. Maybe your driver intentionally allows user access to privileged kernel memory, or has a vulnerability that allows the same? Also, signing keys leak every so often.
A TPM is useless for DRM on a general purpose computing platform because it is significantly inferior to existing widely deployed solutions.
DRM is already a software thing - 720p video is protected by software Widevine. Has been for years.
Widevine's highest security level, L1, does not rely on security by obscurity. But it doesn't rely on a TPM either; rather, it relies on a trusted execution environment, like ARM TrustZone or Intel CSE[1], that is more highly privileged than the OS itself. Microsoft PlayReady is similar.
Apple FairPlay, in contrast, is worse: it's disabled if you turn off Secure Boot on Macs.
[1] https://www.intel.com/content/www/us/en/developer/articles/n...
In practice places that want "attestation-like" functionality, like Riot do for anti-cheat, just load mandatory kernel modules instead and require e.g. Type 1 hypervisor-based security in Windows to be enabled. Or they just obfuscate everything and run blobs. These can still be bypassed but it's still difficult and in contrast fully controlled by their software stack, which is more usable for them for more players. It's good enough, in other words.
Linux will never be approved, unless it's heavily locked down, by the way.
You can also look at how any other DRM works. It's all based on hardware and software locks very similar to what TPMs do.
But services still use that rather than a TPM, because a TPM is useless.
NOTE: This proposal is no longer pursued.
Thank you for all the constructive feedback and engagement on the topic. An Android-specific API that does not target the open web is being considered here.
And this is a supposedly tech focused platform where the tech literacy is at its highest. I wouldn't be surprised to read comments that TPM is used by Bill Gates to give you Covid.
> I wouldn't be surprised to read comments that TPM is used by Bill Gates to give you Covid.
One time on here, someone linked an academic paper describing an HTTP PCIe accelerator. One of the (eight) authors was from Tsinghua, and so naturally someone in the comments started freaking out about how this was a plan by the Chinese Deep State to fund this for mass surveillance. When I asked him how this would work and what threat he expected, he described an elaborate Tom Clancy plotline where these PCIe cards will actually be snooping every key exchange, keeping them in memory, and they would be secretly equipped and manufactured with short wave radio devices that would allow Chinese agents to "exfiltrate private keys" (whatever that means) by posing as janitors and technicians in the datacenter and beaming those radio messages to them.
That was his threat model for "thing you literally plug into your fucking server and put on a shared memory bus."
Now, how this is expected to work when most HTTP accelerators don't do key exchange (and never ever see long term keys), or how these keys would benefit them when presumably many encrypted comms do not go through cables controlled and spliced by the nefarious, evil-loving CCP -- well, that's left as an exercise for you!
No one would be the wiser.
https://www.ebay.com/itm/186136320010?chn=ps&mkevt=1&mkcid=2...
MS already has TPM and secure boot requirements. What's stopping them from colluding with the Copyright Cartel and embedding keys in the firmware that, if removed, disable functionality on the device or on property networks?
You are giving FAR too much trust to entities proven to have an interest in limiting computing freedoms.
That Nvidia, Intel and AMD already put a better black box with a smaller attack surface in the GPU years ago for them to use.
Why take unnecessary risks when you can just use GRUB+LUKS and type the passphrase at boot?
TPM is the same - any known vulnerabilities would generally get patched as part of firmware updates released by your vendor.
If the TPM is known vulnerable and a patch doesn't exist then fair enough you can stop using it depending on your threat model, but the same can be said for software implementations.
> when you can just use GRUB+LUKS and type the passphrase at boot?
This is a user experience drawback and opens you to other avenues of attack like passphrase bruteforce if you don't choose a strong (and inconvenient/slow to type) one. It's also impossible for servers or embedded devices which you want to be able to boot unattended.
It's not really: LUKS is an open standard and GRUB is a free software that implements it. With a TPM you're likely to get a chip that is 100% a black box, with the exception of a few people who signed NDAs and researches that have knowledge and tools to poke into it.
> generally get patched as part of firmware updates released by your vendor
If it can even be fixed with a softwar update. Also, you're very lucky to get maybe a couple of years of firmware updates, then your're on your own.
This is good enough for the 90% of people who currently operate without full-disk-encryption at all. It would be a huge improvement.
Obviously, it's up to each individual user to evaluate their threat model and proceed accordingly. Nobody is forcing you to use a TPM, you can still use LUKS/etc and completely ignore the TPM.
From my memory it was every zen module up to and including zen3.
It's possible that zen4 has been fixed but I'm not certain about that.
There is a "requirements" section of the PDF that talks a little bit more about which CPUs were effected but that isn't distilled!
I understand that I will be protected from removing the HDD/SSD and putting it into another machine to read the data, but does it really protect me from anything else?
Being unable to retrieve the data on protected drives (which could include cookies, passwords, ID, photos/videos, etc.) is the value.
In my experience, tpms are worse than worthless since they prevent rescuing garddrives from bricked systems. Nontpm luks can be unlocked on any system.
It'll only prevent you from recovering a hard drive if you configured it that way - ie it's doing its job as designed.
Just like HTTP vs HTTPS with LetsEncrypt. Even if an attacker can compromise a web-server rendering HTTPS protection useless, it's still better to always use HTTPS.
Besides, SecureBoot isn't strictly better in all scenarios. The most obvious one is the one where you forgot how to log in, and want to retrieve your data.
That's a use case typically better addressed with good backups, since there are indeed more failure modes when using effective full disk encryption.
That's just false. I've had SecureBoot enabled for 10 years and I didn't have more DRM because of this.
You're talking hypotheticals, slippery slope, etc...
> The most obvious one is the one where you forgot how to log in
SecureBoot is separate and does not imply full disk encryption. If you choose to use full disk encryption, yes, you can be locked out, with SecureBoot or not.
Maybe stop pretending to understand what the parent comment is talking about.
> SecureBoot is separate and does not imply full disk encryption. If you choose to use full disk encryption, yes, you can be locked out, SecureBoot or not.
There's no purpose to Secure Boot if I can just put your hard drive in a different computer without Secure Boot.
There are scenarios where you can't take the hard drive out (evil maid attacks, public computers, ...).
But regardless, you are attacking SecureBoot with an argument against full disk encryption.
I'm using Librem 14 with a TPM chip with exclusively free software.
How has your experience been with Qubes?
See also: https://forum.qubes-os.org/t/qubesos-4-2-rc3-clean-install-i...
But worrying about your TPM being backdoored is pointless anyway. If they can backdoor your TPM, they can backdoor anything.
[citation needed]
US intelligence agencies don't generally go around mass backdooring things. It's too risky. They carefully target their attacks.
Picture-of-a-Cisco-router-getting-a-hardware-implant-installed-after-being-indicted-during-shipping.snowden-files.jpg
They reduce the attack surface. Not only in terms of the actual interface, but in terms of who has the ability to subvert the security. Using TPM may or may not be effective security against governments, manufacturers, and the like, but they are effective security against a whole host of other bad actors.
It could be argued that's still a worthwhile improvement. You can engage in other layers of security regardless of whether TPM is being used to help cover the areas TPM may not.
However, that's the only way it can be turned against the user, and the other user security gains are real.
For some reason in these threads nobody seems to bring up or realize that modern AMD CPU's fTPM is completely broken and not fixable via ucode updates. The AMD TPM exploit is exploitable by a "regular" person too, it doesn't have to be a state level actor, just some techy person with a few tools and physical access to the system.
We can't audit these things at all and I don't think we should just trust that they are safe, and we know for a fact that many of them aren't safe, even against "regular" threats.
(AMD fTPM exploit source) https://arxiv.org/abs/2304.14717
Embrace the suck :) Sure, you can't truly trust hardware, but there's nothing to be done about it anyhow and so you may as well reap the benefits of trusting it.
Alternatively, you can avoid relying on any single thing to be secure and use layered security approaches instead.
On real computers you're also susceptible to the hardware simply not executing your code properly and a hundred other things.
Since you can't fully mitigate malicious hardware, you have to state a more limited threat model for there to be any useful discussion.
It's the whole trusting-trust thing. We don't really have a way to solve it, so it's best not to burn yourself out on it.
If you don't trust FIPS then you could support open source TPMs and help audit them.
Other than that if you care enough about it and had the prerequisite skills and money, you could develop your own TPM (the interface specifications are online) and run your own trusted and audited Linux system.
The more you research it, the more you find to be impressed with.
In other words the complaints are political, not technical.
Also, systemd made writing service definitions easy, hats off to them. With cgroups, namespaces and capabilities support out of the box - great.
However, every time I have to debug why some target wasn't reached (because some dependency of dependency failed), or why systemd mounted something wrongly, or just want to know how often and why some service restarted, I feel like the core part of systemd (which is, the systemd init and service runner) is working against me.
And let's not get started on journald, I declare it my enemy.
Boot charts and NIH syndrome for system level stuff ain't it for me. Binary journals ain't it, either. Services suck, you're never sure the difference between units, services, sockets, and other similar INI style files. Extra BS like $HOME management? Not necessary.
In over ten years, I've not found a single good reason to lean into systemd or like it. It runs my current computer, but not by choice and I will remedy that when I build my custom distro.
I'm quite curious what they've been doing. Security audits, maybe? Preparations for other integrations? I'm not criticizing here - I've been away from that scene for an year, and I wonder if there have been some new interesting developments or ideas that I'm not aware of.
A few hours time and a few tools can fully compromise the TPM's secrets. This can be performed by anyone who has a little experience tinkering with electronics, someone who can use a soldering iron for example can almost certainly pull this off.
From my understanding all of the "zen" CPUs are effected except for maybe the very most recent models.
"All Systems Go! is a conference focused on foundational user-space Linux technologies. Its goal is to provide a gathering place for both contributors and users of projects that make up the foundation of modern Linux systems."
So, summing up: maybe you are not part of the target audience?
So, it's really a bad (or s**ty) topic to talk about in front of an unsuspecting audience, but certainly there are people who would appreciate the work, especially in embedded/robotics fields (which have been rising slowly for a long time).
https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-...
https://0pointer.net/blog/the-wondrous-world-of-discoverable...
https://0pointer.net/blog/authenticated-boot-and-disk-encryp...
https://0pointer.net/blog/fitting-everything-together.html