38 ms·

TPM is probably the best solution here. The key can be automatically fetched on reboot unless the boot order is changed or the drive is put in another computer.

TPM is probably the best solution here. The key can be automatically fetched on reboot unless the boot order is changed or the drive is put in another computer. Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace rather than the FBI raiding your nextcloud server. So TPM automated unlock is perfectly sufficient.

bogwog 7mo ago
> Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace If someone steals the entire machine, the drives will unlock themselves automatically. I don't think it's worth the risk to assume a hypothetical thief is too lazy to check if there's any valuable data on the disks. At the very least, they'll probably check for crypto wallets. With something like Clevis and Tang, you can set it up so it only auto unlocks while connected to your home network, or do something more complex as needed
- SchemaLoad 7mo ago
  They will unlock in to a password protected system. Unless the junkie who stole your server has an unpatched debian login bug, this won't be much use to them. If they remove the drive or attempt to boot off a USB, the drive is unreadable.
  - danparsonson 7mo ago
    What's the difference when booting off a USB drive? That's been my goto in the past when I forgot my login password; does the TPM only unlock boot devices?
    - NekkoDroid 7mo ago
      Generally you'll have your drive only unlock against certain PCRs and their values. It depends on which PCRs you select and then how exactly they are measured. E.g. systemd measures basically everything that is part of the boot process (kernel, kernel cli, initrd, ...[1]) into different PCRs, so if any of those are different they result in differen PCR values and won't unlock the boot device (depending on which PCRs you decided to encrypt against). I forgot what excatly it measures, but I remember that some PCRs also get measured during the switch_root operation from initrd -> rootfs which can be used to make something only unlock in the initrd. [1]: https://systemd.io/TPM2_PCR_MEASUREMENTS/ https://systemd.io/TPM2_PCR_MEASUREMENTS/
    - SchemaLoad 7mo ago
      The TPM holds the decryption keys and will unlock as long as all checks pass. Booting off the previously registered drive/kernel being one of them. If this fails you can always manually input the decryption key and reregister with the TPM. The whole point of this setup is you can't just use a bootable USB to reset the devices password.
    - vel0city 7mo ago
      If properly configured and the TPM implementation is good, no it shouldn't unlock the drive. Changing boot devices, and depending on how configured even changing boot options, can prevent the TPM from releasing the key and require a recovery key.
  - gorgoiler 7mo ago
    Don’t you just hit ESC during boot and change the Linux command line to init=/bin/sh?
    - Gigachad 7mo ago
      Looks like you can either password protect grub or have the kernel start command part of the list of things the TPM checks before unlocking the key.
    - izacus 7mo ago
      TPM will not unseal the key if you change kernel parameters. It's one of the PCRs. You'll be dropped into "enter disk crypt password please" prompt.
  - PunchyHamster 7mo ago
    Plenty of TPM bugs happened in the past and plenty of zero days in any code involved will happen. Having key off-machine mitigates a lot of that. > Unless the junkie who stole your server has an unpatched debian login bug, the key for disk decryption is in memory at that point. There are methods to take it out of it
- michaelt 7mo ago
  The hope with the TPM is that the system boots to a standard login screen, and the thief doesn't know any user's password. Much like someone snatching a laptop that's in 'suspend' mode. Of course, a thief could try to bypass the login screen by e.g. booting with a different kernel command line, or a different initramfs. If you want to avoid this vulnerability, TPM unlock can be configured as a very fragile house of cards - the tiniest change and it falls down. The jargon for this is "binding to PCRs"
  - SchemaLoad 7mo ago
    The fallback is you have to manually unlock the drive, the same as you did without a TPM. But the benefit is while things remain unchanged, the system can reboot itself.
    - fc417fc802 7mo ago
      You can reduce the frequency with which things change by adding an additional layer before the "real" kernel is loaded. A minimal image that does nothing but unlock any relevant secrets, verify the signature of the next image, and then hands off control.
  - kro 7mo ago
    TPM is good when combined with secureboot and these hashes being part of the attestation, that eliminates initramfs swapping. Still with Physical access being a factor bustapping can happen, ftpm - if available - is much harder to crack then than a discrete module. https://news.ycombinator.com/item?id=46676919 https://news.ycombinator.com/item?id=46676919
PunchyHamster 7mo ago
TPM is security theathre for disk encryption. If you steal the device, you have stolen the key

bogwog 7mo ago

> Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace If someone steals the entire machine, the drives will unlock themselves automatically. I don't think it's worth the risk to assume a hypothetical thief is too lazy to check if there's any valuable data on the disks. At the very least, they'll probably check for crypto wallets. With something like Clevis and Tang, you can set it up so it only auto unlocks while connected to your home network, or do something more complex as needed

SchemaLoad 7mo ago
They will unlock in to a password protected system. Unless the junkie who stole your server has an unpatched debian login bug, this won't be much use to them. If they remove the drive or attempt to boot off a USB, the drive is unreadable.
- danparsonson 7mo ago
  What's the difference when booting off a USB drive? That's been my goto in the past when I forgot my login password; does the TPM only unlock boot devices?
  - NekkoDroid 7mo ago
    Generally you'll have your drive only unlock against certain PCRs and their values. It depends on which PCRs you select and then how exactly they are measured. E.g. systemd measures basically everything that is part of the boot process (kernel, kernel cli, initrd, ...[1]) into different PCRs, so if any of those are different they result in differen PCR values and won't unlock the boot device (depending on which PCRs you decided to encrypt against). I forgot what excatly it measures, but I remember that some PCRs also get measured during the switch_root operation from initrd -> rootfs which can be used to make something only unlock in the initrd. [1]: https://systemd.io/TPM2_PCR_MEASUREMENTS/ https://systemd.io/TPM2_PCR_MEASUREMENTS/
  - SchemaLoad 7mo ago
    The TPM holds the decryption keys and will unlock as long as all checks pass. Booting off the previously registered drive/kernel being one of them. If this fails you can always manually input the decryption key and reregister with the TPM. The whole point of this setup is you can't just use a bootable USB to reset the devices password.
  - vel0city 7mo ago
    If properly configured and the TPM implementation is good, no it shouldn't unlock the drive. Changing boot devices, and depending on how configured even changing boot options, can prevent the TPM from releasing the key and require a recovery key.
- gorgoiler 7mo ago
  Don’t you just hit ESC during boot and change the Linux command line to init=/bin/sh?
  - Gigachad 7mo ago
    Looks like you can either password protect grub or have the kernel start command part of the list of things the TPM checks before unlocking the key.
  - izacus 7mo ago
    TPM will not unseal the key if you change kernel parameters. It's one of the PCRs. You'll be dropped into "enter disk crypt password please" prompt.
- PunchyHamster 7mo ago
  Plenty of TPM bugs happened in the past and plenty of zero days in any code involved will happen. Having key off-machine mitigates a lot of that. > Unless the junkie who stole your server has an unpatched debian login bug, the key for disk decryption is in memory at that point. There are methods to take it out of it
michaelt 7mo ago
The hope with the TPM is that the system boots to a standard login screen, and the thief doesn't know any user's password. Much like someone snatching a laptop that's in 'suspend' mode. Of course, a thief could try to bypass the login screen by e.g. booting with a different kernel command line, or a different initramfs. If you want to avoid this vulnerability, TPM unlock can be configured as a very fragile house of cards - the tiniest change and it falls down. The jargon for this is "binding to PCRs"
- SchemaLoad 7mo ago
  The fallback is you have to manually unlock the drive, the same as you did without a TPM. But the benefit is while things remain unchanged, the system can reboot itself.
  - fc417fc802 7mo ago
    You can reduce the frequency with which things change by adding an additional layer before the "real" kernel is loaded. A minimal image that does nothing but unlock any relevant secrets, verify the signature of the next image, and then hands off control.
- kro 7mo ago
  TPM is good when combined with secureboot and these hashes being part of the attestation, that eliminates initramfs swapping. Still with Physical access being a factor bustapping can happen, ftpm - if available - is much harder to crack then than a discrete module. https://news.ycombinator.com/item?id=46676919 https://news.ycombinator.com/item?id=46676919

PunchyHamster 7mo ago

TPM is security theathre for disk encryption. If you steal the device, you have stolen the key