> From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end):
They use the exploit to get dropped into a root shell, and then asks the TPM to unlock the disk for them, which it promptly does.
Technically, but really the fault lies in the OS for providing an exploitable prompt that doesn't break the chain of custody of the boot process on failure.
Ubuntu developer here. I don't think that's fair. The OS, as shipped today, isn't designed with this threat model in mind. It's correct to say that for TPM-based LUKS unlock to be safe, the initramfs must not allow the user to take control of it. But that's a new requirement introduced when the user modified their system to configure TPM-based LUKS unlock. This isn't the responsibility of an OS that doesn't ship with that support, and in fact, prior to TPMs, it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!
That's not to say that an improvement can't be made as we move towards a future where TPM+LUKS might be the norm - just that you can't retrospectively claim fault on an OS that doesn't claim to support that.
> This isn't the responsibility of an OS that doesn't ship with that support, and in fact, prior to TPMs, it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!
And it still is perfectly reasonable behavior. Any distribution that decides (perhaps as a consequence of this) that on any boot process abnormality the default response is to enter an immediate reboot loop would be called crazy.
> it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!
It’s still looks perfectly reasonable, just PCR should be fed with some value before that, maybe a hash of initramfs file? It seems to be reasonable as at this moment the state of the operating system differs from the one properly booted, which seems to fit the idea of secure boot.
This way it would be possible to still unlock LUKS with a pass phrase but not access TPM keys locked for configuration when initramfs shell is not running.
I still don't understand why people believe that you can have any expectation in these ludicrous scenarios.
Like, you are dropping a general purpose computer into the middle of Russia, expect to be able to command it remotely to do anything, even remotely update it and reboot it; and at the same time never bother to come check it up in person or even have minimum chassis intrussion detection. Do people really expect this to work just by adding some TPM craziness?
The article is just connecting a keyboard sniffer/simulator but it would have been as easy to do anything to the network traffic, SSD, motherboard/CPU JTAGs, RTC, etc.
Well, it's sorta possible. Just not with the TPM, and not in general purpose computing applications.
Games consoles are super locked down, to prevent piracy, and some modern consoles have gone years without a successful hack, despite being in the physical possession of the attacker. The iphone's activation lock is extremely hard to bypass, and even cops and border guards struggle to extract users' data.
Simply buy your PC from your operating system vendor directly, and forego options like being able to replace components and being able to install your own software, allowing the memory and PCI bus to be encrypted. Add some cloud backup features so the device can wipe itself at the drop of a hat without losing your data. After that, just have your OS vendor produce perfect code with no exploits, and you're secure!
I did. It says 'From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end)'
However screenshot says 'Unsealing failing'. Yet Ubuntu-lv is mounted.
I don't follow how Luks password was guessed for it.
There wasn't a password necessary, the TPM was an unlocking mechanism.
Secure Boot with TPM-backed disk encryption works off of a series of numbered hashes. The idea of TPM based FDE is that the machine will use Secure Boot to boot only a software chain that the end-user trusts not to contain authentication bypasses. In Secure Boot, the EFI firmware provides hashes of each stage in the boot chain to the TPM, and the TPM only unlocks the full-disk encryption key (really the key encryption key, since the TPM isn't fast enough to actually decrypt the disk) slot if each stage / configuration is valid.
This issue breaks that chain. In some sense it's an illustration of this system being silly conceptually, but it is a real issue IMO.
No LUKS password was guessed, clevis-disk-unlock command in the last screenshot used the TPM to provide a key to a LUKS keyslot for getting at the actual decryption key to decrypt the disk. The TPM should have had information about the boot state to be able to refuse to provide the key, but didn't.
The system that should only unlock the drive after the appropriate remote command has been provided, unlocks the drive without the remote command being provided. That's the problem.
I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least.
You'd still be at risk because of this flaw, because the root shell would allow sniffing the key from a secure session. Ideally, attempts to brute force the user account should prevent further attempts by rebooting or refusing further interactive input.
> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least.
I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted"
If your organisation is large enough to start losing track of entire servers, and yet small enough you can't adopt effective organisational controls to prevent such losses, even mediocre encryption might give you some peace of mind - and it lets you avoid reporting data breaches, as the lost data was 'encrypted'.
Looks like so.
From https://rogueai.github.io/posts/arch-luks-tpm/#unlock-the-lu...
'From a security point of view, passwordless LUKS unclocking might look like we’re giving up some security, as booting will go straight to login without asking any password whatsoever. We’re indeed trading a bit of security in favour of convenience, it’s important to note though that binding the LUKS to the TPM ensures the volume will only unlock in our machine, with Secure Boot enabled and our signed boot image.'
So there we are somewhat breaking 'Secure Boot' process in general.
Another potential use is encrypted root with home directories subsequently requiring login password to decrypt (using pam_ecryptfs, pam_mount, etc). Less secure than root fe needing a PIN/password but can still defend against some threat models.
It's not a totally meaningless check box. If the key for decrypting the disk is in the TPM, this fixes the case where the drive gets pulled and thrown in a recycle bin, then someone recovers data from it later.
> this fixes the case where the drive gets pulled and thrown in a recycle bin
Also allows you to do that when you retire a server or cluster. I've been in situations where we had to wipe hundreds of multi-TB hard drives. If you've never done it, that takes a good deal of time. You can get appliances that do it, or try to build your own DBAN rig, but it still takes days. Or you can just shred them, but hard drive shredders are not cheap either, and that's rather wasteful and may not be environmentally conscious.
Yes, when I say "small enough you can't adopt effective organisational controls" I mean organisations that are large enough that they're discarding so many disks they might accidentally forget to wipe some, and yet small enough they don't have procedures and record-keeping that prevent such accidents.
A large organisation will usually have tedious checks and record-keeping for wiping and discarding hardware, probably instituted after they wiped and discarded the wrong hardware.
It is not about forgetting to wipe a disk. A realistic scenario is that an SSD fails in a way that it ceases to be recognized by the system. At this point, you have no way to wipe it. Still, you may be required to return it to the vendor (by the contract that gave you the discounted price in the first place) - and they can read it using their tools not available to mere mortals.
In addition to sibling replies, I'll add that a common important use for encryption (and reason to have it be completely standard 100% of the time, even in fully transparent mode) is storage EOL procedures. It's much easier/cheaper/safer to get rid of an HDD or SSD and feel confident everything is gone if it was all fully encrypted from the beginning and you just need to trash the key.
The threat vector mitigated by Clevis[1] is someone with physical access (e.g. an insider) removing the server from the data center and being able to access its data.
