4 ms·

Glad to see another example of this! Remote unlocking of your personal server's encrypted hard drive is PITA. Other options that I've investigated that involve

Glad to see another example of this! Remote unlocking of your personal server's encrypted hard drive is PITA. Other options that I've investigated that involve having a second server: * A second server with Tang, and Clevis in the initramfs OS * Keylime Putting tailscale in the initramfs, and then updating the certs on a frequent enough schedule, seems risky to me. I've already played around with limine enough that I know I don't want to install much in the initramfs...

SchemaLoad 8mo ago
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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo ago
      Don’t you just hit ESC during boot and change the Linux command line to init=/bin/sh?
      - 8mo ago
  - michaelt 8mo 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 8mo 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 8mo 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 8mo 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 8mo ago
  TPM is security theathre for disk encryption. If you steal the device, you have stolen the key

SchemaLoad 8mo ago

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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo ago
    Don’t you just hit ESC during boot and change the Linux command line to init=/bin/sh?
    - 8mo ago
- michaelt 8mo 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 8mo 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 8mo 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 8mo 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 8mo ago
TPM is security theathre for disk encryption. If you steal the device, you have stolen the key