2

I am using crytsetup with LUKS to encrypt a data drive, separate to the system drive, under Ubuntu 16.04. The issue I am facing is that this system will also be required to automatically start itself up in the event of power loss. The other constraint is that this system can not be connected to a network.

Essentially the only security risk with respect to the data is the case that someone physically steals the system with the HD on board. So of course I can provide an associated key to the drive but given that I have no network access, and yet I still require unattended rebooting, I'm a bit lost on how to proceed.

Looking for general thoughts on how to handle such a situation. Perhaps there are physical security solutions (i.e. self destructing USB -though who knows upon what condition given my requirements!) that might be helpful. Or really any comments from anyone who has faced the same constraint: i.e. encrypted drive with unattended reboot, and no network. Maybe I'm thinking about the problem the wrong way?

Thank you in advance.

Tyler
  • 21
  • 1
  • With it not being on a network, it would only be used interactively I think? Does it definitely need automatic reboot? Maybe the user could enter a boot password? – paj28 Dec 31 '19 at 18:00
  • 2
    USB extension cable to a key drive in a locked box? – user Dec 31 '19 at 18:00
  • Is it a cold or warm reboot? You say power loss, so without a UPS at least, that would be a cold reboot. If it was warm, then you could get away with storing the key in the x86 debug registers, which don't get cleared on CPU reset and have enough room for 256 bits of material. Or you could even store in VRAM. For a cold reboot, you'd need to keep the keys somewhere persistent, which isn't ideal. You could seal them with a TPM or put them in NVRAM (assuming you aren't using UEFI and clobbering NVRAM is acceptable; this is something I've done), but that would leave the keys exposed... – forest Jan 01 '20 at 12:52
  • @ThoriumBR A TPM wouldn't be ideal for this case. If the TPM is the exclusive authority for the disk encryption, then anyone with physical access will be able to extract the key (at a minimum, sniff the LPC bus while booting). A TPM is mostly useful for preventing someone who steals only the _hard drive_ from being able to decrypt it. If someone has the hard drive and server, it's next to useless for FDE. – forest Jan 01 '20 at 12:56
  • @forest you are slightly wrong: if someone steals the server and the drive, TPM *is* useless for FDE. You are absolutely right on point. – ThoriumBR Jan 01 '20 at 16:52
  • Thanks all! Great ideas here. For the moment, I've implemented LUKS + TPM as described at https://github.com/vchatterji/tpm2-luks. But now I see TPM is may not suffice, and therefore I wonder. 1. @ThoriumBR/@forest you say TPM is actually useless if they have the server. Doesn't TPM protect against configuration changes with the PCR? For example, If I boot from a ubuntu LiveCD and get access to the system, can I get the TPM unseal the passphrase even though the configuration has changed? 2. Are there any simple tests I can perform? I.e. any simple hacks I can attempt? Thanks all! – Tyler Jan 03 '20 at 02:14
  • @ThoriumBR I know. I mean that the TPM is useless if someone steals the server and drive (with the motherboard, you also get the TPM which means you can decrypt the drive). – forest Jan 03 '20 at 08:43
  • @Tyler TPM does indeed protect from configuration changes, but only against a non-physical attacker. A physical attacker can just feed the "correct" configuration over the LPC bus, but give the CPU something different. This could easily be done by switching the BIOS chip for a modified one, since the security of the TPM relies on the assumption that a specific area of the BIOS, called the CRTM, is hardware read-only. – forest Jan 04 '20 at 07:45

0 Answers0