6 ms·

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

by disvor 4y ago

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.

capitol_ 4y ago
I have never understood what threat scenario this is meant to protect against. 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?
- disvor 4y ago
  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.
  - capitol_ 4y ago
    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.
    - azalemeth 4y ago
      > 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. [1] https://pulsesecurity.co.nz/articles/TPM-sniffing https://pulsesecurity.co.nz/articles/TPM-sniffing
    - dinom 4y ago
      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... https://news.ycombinator.com/item?id=35066894 https://news.ycombinator.com/item?id=35066894
- azalemeth 4y ago
  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.
- Zurrrrr 4y ago
  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.
e12e 4y ago
Interesting question. I think so? https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening 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 https://github.com/latchset/clevis See also: Ed: and: https://github.com/kmille/cryptboot https://github.com/kmille/cryptboot https://security.stackexchange.com/questions/194081/use-tpm2-0-to-securely-decrypt-the-hard-drive-in-linux-unattended https://security.stackexchange.com/questions/194081/use-tpm2... https://security.stackexchange.com/questions/39329/how-does-the-tpm-perform-integrity-measurements-on-a-system/44350 https://security.stackexchange.com/questions/39329/how-does-... https://superuser.com/questions/619721/can-i-use-the-tpm-on-linux-without-trustedgrub https://superuser.com/questions/619721/can-i-use-the-tpm-on-...
dinom 4y ago
Yes, of course there is... https://github.com/01org/tpm2.0-tools https://github.com/01org/tpm2.0-tools http://trousers.sourceforge.net 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-Emulation-With-QEMU.html 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: https://news.ycombinator.com/item?id=35066894 https://news.ycombinator.com/item?id=35066894
- Zurrrrr 4y ago
  Saying "of course there is..." in response to someone asking if an obscure oss OS has support for a new hardware feature seems odd.
  - dinom 4y 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). Might the world be a bigger place than you think?
    - Zurrrrr 4y ago
      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.
      - dinom 4y ago
        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.

by disvor 4y ago

capitol_ 4y ago

I have never understood what threat scenario this is meant to protect against. 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?

disvor 4y ago
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.
- capitol_ 4y ago
  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.
  - azalemeth 4y ago
    > 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. [1] https://pulsesecurity.co.nz/articles/TPM-sniffing https://pulsesecurity.co.nz/articles/TPM-sniffing
  - dinom 4y ago
    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... https://news.ycombinator.com/item?id=35066894 https://news.ycombinator.com/item?id=35066894
azalemeth 4y ago
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.
Zurrrrr 4y ago
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.

e12e 4y ago

Interesting question. I think so? https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening 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 https://github.com/latchset/clevis See also: Ed: and: https://github.com/kmille/cryptboot https://github.com/kmille/cryptboot https://security.stackexchange.com/questions/194081/use-tpm2-0-to-securely-decrypt-the-hard-drive-in-linux-unattended https://security.stackexchange.com/questions/194081/use-tpm2... https://security.stackexchange.com/questions/39329/how-does-the-tpm-perform-integrity-measurements-on-a-system/44350 https://security.stackexchange.com/questions/39329/how-does-... https://superuser.com/questions/619721/can-i-use-the-tpm-on-linux-without-trustedgrub https://superuser.com/questions/619721/can-i-use-the-tpm-on-...

dinom 4y ago

Yes, of course there is... https://github.com/01org/tpm2.0-tools https://github.com/01org/tpm2.0-tools http://trousers.sourceforge.net 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-Emulation-With-QEMU.html 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: https://news.ycombinator.com/item?id=35066894 https://news.ycombinator.com/item?id=35066894

Zurrrrr 4y ago
Saying "of course there is..." in response to someone asking if an obscure oss OS has support for a new hardware feature seems odd.
- dinom 4y 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). Might the world be a bigger place than you think?
  - Zurrrrr 4y ago
    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.
    - dinom 4y ago
      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.