3 ms·

Evil mastermind, supervillains level :) I dig around. So to remotely unlock LUKS, on bare-metal in datacenter, one can use custom initramfs, like https://githu

Evil mastermind, supervillains level :) I dig around. So to remotely unlock LUKS, on bare-metal in datacenter, one can use custom initramfs, like https://github.com/mtth-bfft/dracut-dropbear-unlock https://github.com/mtth-bfft/dracut-dropbear-unlock But still "boot time SSH server's key is stored unencrypted, man-in-the-middle attacks can also be carried out to recover the encryption key at boot time". Ideas?

mirimir 8y ago
The full quote: > Full-disk encryption doesn't protect you against someone with physical access to the machine: the encryption key can be recovered from RAM at runtime (e.g. cold boot attacks), and since the boot time SSH server's key is stored unencrypted, man-in-the-middle attacks can also be carried out to recover the encryption key at boot time. Consider this in your threat model. So yes, for "Evil mastermind, supervillains level" you gotta embed the RAM, and everything that would give adversaries physical access to the RAM, in alumina-filled epoxy. Or better, alumina-and-fiberglass-filled epoxy. The alumina gives you heat condictivity, and the fiberglass strength. Plus embedded trip wires to nuke the board if they're cut. It's also prudent to disconnect all ports from the board, except for the NIC, and embed everything that could be used to reconnect them. With that, it'd be very difficult to get anything from RAM. Attempts at physical access would destroy the system.
- auslander 8y ago
  But is the storage hdd/ssd epoxied too? The ssh keys to do MITM are in cleartext on boot partition... FBI can put their box on your server's IP, and you'll happily connect, same fingerprint, and type unlock and passphrase.
  - mirimir 8y ago
    Sorry. Wasn't thinking clearly. I guess that you'd need to embed the SSD(s) too. But I wonder if there's a way to reproducibly generate SSH key pairs from hardware IDs. That way, there'd be no keys stored in /boot, and they'd be generated at each boot. So only your hardware would have the right keys.
    - auslander 8y ago
      This TPM guide describes TPM for LUKS. "PCR 0-7 Measured by BIOS" seems like HW fingerprint. https://github.com/morbitzer/linux-luks-tpm-boot https://github.com/morbitzer/linux-luks-tpm-boot If this thing works, there is no need for remote ssh FDE unlocking.
      - deleted 8y ago
        [deleted]
      - mirimir 8y ago
        Thanks. If I understand that correctly, the LUKS key is stored in the TPM. Which is protected by a password. So you boot into initramfs, and provide the password. And this could also work via dropbear. There'd still be an exposed dropbear SSH key in /boot. But it'd be the TPM that you're unlocking. And I assume that there are ways to verify the authenticity of the TPM via initramfs, before providing a password. Am I understanding that right? It does seem more complicated. Especially given that you don't have physical access to the server.
        auslander 8y ago
        > .. the LUKS key is stored in the TPM. Which is protected by a password. Yup. Nope. The key is protected by TPM magic :). TPM measures stuff, then we put the key in TPM and seal it to PCRs 0-13 measurements (whole boot environment). At boot, TPM will allow tcsd daemon (part of initrd) to read LUKS key once, and only if all measurements match, this is as far as I got. End result is unlocked volume, without any passphrase prompts, neither on console nor via ssh.

mirimir 8y ago

The full quote: > Full-disk encryption doesn't protect you against someone with physical access to the machine: the encryption key can be recovered from RAM at runtime (e.g. cold boot attacks), and since the boot time SSH server's key is stored unencrypted, man-in-the-middle attacks can also be carried out to recover the encryption key at boot time. Consider this in your threat model. So yes, for "Evil mastermind, supervillains level" you gotta embed the RAM, and everything that would give adversaries physical access to the RAM, in alumina-filled epoxy. Or better, alumina-and-fiberglass-filled epoxy. The alumina gives you heat condictivity, and the fiberglass strength. Plus embedded trip wires to nuke the board if they're cut. It's also prudent to disconnect all ports from the board, except for the NIC, and embed everything that could be used to reconnect them. With that, it'd be very difficult to get anything from RAM. Attempts at physical access would destroy the system.

auslander 8y ago
But is the storage hdd/ssd epoxied too? The ssh keys to do MITM are in cleartext on boot partition... FBI can put their box on your server's IP, and you'll happily connect, same fingerprint, and type unlock and passphrase.
- mirimir 8y ago
  Sorry. Wasn't thinking clearly. I guess that you'd need to embed the SSD(s) too. But I wonder if there's a way to reproducibly generate SSH key pairs from hardware IDs. That way, there'd be no keys stored in /boot, and they'd be generated at each boot. So only your hardware would have the right keys.
  - auslander 8y ago
    This TPM guide describes TPM for LUKS. "PCR 0-7 Measured by BIOS" seems like HW fingerprint. https://github.com/morbitzer/linux-luks-tpm-boot https://github.com/morbitzer/linux-luks-tpm-boot If this thing works, there is no need for remote ssh FDE unlocking.
    - deleted 8y ago
      [deleted]
    - mirimir 8y ago
      Thanks. If I understand that correctly, the LUKS key is stored in the TPM. Which is protected by a password. So you boot into initramfs, and provide the password. And this could also work via dropbear. There'd still be an exposed dropbear SSH key in /boot. But it'd be the TPM that you're unlocking. And I assume that there are ways to verify the authenticity of the TPM via initramfs, before providing a password. Am I understanding that right? It does seem more complicated. Especially given that you don't have physical access to the server.
      - auslander 8y ago
        > .. the LUKS key is stored in the TPM. Which is protected by a password. Yup. Nope. The key is protected by TPM magic :). TPM measures stuff, then we put the key in TPM and seal it to PCRs 0-13 measurements (whole boot environment). At boot, TPM will allow tcsd daemon (part of initrd) to read LUKS key once, and only if all measurements match, this is as far as I got. End result is unlocked volume, without any passphrase prompts, neither on console nor via ssh.