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:
Sure... but that presupposes Unix based desktop and server systems are obscure and that the hardware in question is new. In reality, neither is accurate.
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).
The world's exactly as big as I think it is, and I've been playing with OpenBSD since 2004 or so.
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.
Lol, sorry... you're wrong. The question was posed as:
>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.
lol I'm not wrong, but this is so silly. What's not constructive is you really needing to have the last word. If you don't want to 'quibble', don't reply.
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...
Ok, congratulations... you're right. You can can have the last word instead. I must have said "OpenBSD fully supports every piece of hardware known to man" and missed it. I sincerely apologize for that. You, in no way, tried to put words into my mouth.
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!
It is designed for the very typical corporate situation of "I don't trust my users". If you don't have admin rights on that machine, you can't get or bypass them easily by e.g. taking the drive out, imaging it, and reading that on another computer. The keys stored in the TPM are also available to the domain controller, not (easily) to the (non-admin) Windows user.
It protects against data being directly copied off the disk, or modified, by anyone who may have physical access to the machine, but who lacks credentials to log in.
Wouldn't that require that the complete boot chain is totally locked down and cryptographically secure?
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.
TPM chips are specifically designed so that what you're suggesting won't work.
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...
> 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.
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.
For me personally as a non-corporate use, I use it to encrypt my laptop and not require a password to need to decrypt.
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.
Windows has this, and it permits booting without a passphrase being entered, but the disk will still be encrypted at rest.