Is there any support in OpenBSD, or indeed any Unix-based desktop/server operating system, for storing key material in a TPM?
Windows has this, and it permits booting without a passphrase being entered, but the disk will still be encrypted at rest.
Windows has this, and it permits booting without a passphrase being entered, but the disk will still be encrypted at rest.
https://github.com/01org/tpm2.0-tools http://trousers.sourceforge.net
You can also emulate a TPM in recent versions of QEMU...
https://tpm2-software.github.io/2020/10/19/TPM2-Device-Emula...
I wrote a couple of scripts meant to help me lock down a machine for colocation in this "BitLocker" type manner. And, as luck would have it, lol... I'll (again) shamelessly self-promote the Show HN I wrote just a short while ago:
A huge number of people and organizations run Unix based systems and TPM devices have been around for a pretty long time (at least by tech standards).
Might the world be a bigger place than you think?
The point was projects like OpenBSD often don't have support for more recent hardware, and given OpenBSD is used much more as a router than a server, it's a very reasonable presupposition.
>there any support in OpenBSD, or indeed any Unix-based desktop/server operating system
That's a wide swath and TPM 1.2 was finalized in 2011, saying "of course" was perfectly fair. It's one thing to say that such a device, perhaps a specific revision from a specific manufacturer, might not be supported on a specific release of an even more specific distribution... but that wasn't the case.
Trolling and quibbling over a common colloquialism such as using the phrase "of course" is not constructive.
I'll just say this. Saying 'of course' that an obscure OSS OS (and yes, OBSD IS obscure, and anyone not being emotional should be able to admit that) having full hardware support is silly, when so many similar OS projects still don't have support for much hardware.
Besides, TPM is at version 2 now which was announced in 2014, so where is the OBSD support for TPM 2.0? Why does it not support it?
Saying 'of course' it supports it was indeed silly when it doesn't support the more recent spec which is still 9 years old and isn't backwards compatible...
And here I thought I was merely stating that there is some Unix variant somewhere on this planet that supports a TPM, any TPM. I'm a boob; sincere apologies. You've made the world a much better place!
https://access.redhat.com/documentation/en-us/red_hat_enterp...
Looks like clevis is gpl3 - so I expect it's not packaged as standard for any of the bsds?
https://github.com/latchset/clevis
See also:
Ed: and: https://github.com/kmille/cryptboot
https://security.stackexchange.com/questions/194081/use-tpm2...
https://security.stackexchange.com/questions/39329/how-does-...
https://superuser.com/questions/619721/can-i-use-the-tpm-on-...
That a thief opens your laptop and steal the harddrive instead of the complete machine?
Or is this just a solution that is meant to check a checkbox to make an auditor happy?
If you can insert a usb-plug and boot from that you could unlock the disk with the help of the tpm, or interrupt grub and set init=/bin/bash.
Or since the scenario is that the attacker have physical access, maybe desolder the tpm chip and move it to another computer where they have control over how the machine boots.
I guess modern gaming consoles are locked down in such a way so that this makes sense, but I have never seen a general purpose computer secured like this.
Thanks for explaining, I guess the above was mostly my stream of consciousness ranting.
You can't easily do that as the platform control headers will be different to those set by Windows. You can't brute-force it as they have a realtime clock and lock after about 32 attempts, granting one more attempt for each ten minutes. Getting the bit-locker key from a discrete TPM v1.2 or v2.0 requires being a bus pirate [1]. Getting it from a "soft" TPM inside a CPU is likely much, much harder.
Their PCR registers (Platform Configuration Registers) act as sort of tripwires so that the boot chain isn't "locked down" but "measured". Each step of the boot chain updates a register with it's own hash that's hashed with the prior step's hash. What a tangled web, huh?
That way, if you're sealing your data to the appropriate PCR registers, the data won't be able to be retrieved if any part of the boot is changed... e.g. usb device plugged in or kernel/grub parameters changed.
In addition, TPM chips are "married" to the computers they're plugged into. Once you remove a TPM and put it in a different computer it will reset itself.
I just did a fairly deep dive into all this getting a machine up and running for co-location. Coincidentally, I just posted a "Show HN" here...
This is deliberate as I protect my important stuff again with VeraCrypt.
The reason for the automatic login via TPM is have a windows guest account that automatically logs into a very restricted guest account (that can only use a locked down chrome and play movies from usb, nothing else) that can't be changed (not without resetting the bios or replacing/wiping the hdd).
Since the laptop is running prey, my hope is any thieves would be using it. Without an automatic login with a key obtained from TPM, I couldn't have the same setup.