I've been doing some thinking..... The only way to secure a local device is to implement some anti-tamering circuitry and have it running 24/7. This circuitry will be reponsible for physical protection i.e. safe keeping the encryption key and destroy it in case an attacker tries to access it. Then again as soon as power is gone, all bets are off because the adversary can hack the device while it's protection circuitry is offline. Therefore the circuitry will have to be continuously powered up (i.e. by using an UPS) so that it can do its job. But in theory, having an UPS to have the device running 24/7 defeats the whole purpose of having a remote authentication mechanism in place for cases like power cuts. It also defeats the purpose of having a passphrase or encryption key stored somewhere other than the devices RAM (i.e. NAND flash or USB key). In fact, the device should mount the LUKS container and immediately wipe all LUKS key slots so that only the master key remains in RAM. Once tampering is detected, the device simply powers off. Use some epoxy to prevent easy access to RAM chips... cold boot anyone? Thoughts? On 10/18/14, Arno Wagner <arno@xxxxxxxxxxx> wrote: > Unfortunately, that does not get you and real additional > security. If the initrd is compromised, then the attacker > can instead just leak the master-key from the mapped > LUKS container a bit later. And if the initrd is not > compromised, then the ssh-fetch (regardless of direction) > is just as secure as the version using the TPM. > > In practice, a TPM is pretty worthless for local > platform security. Its primary use is DRM, i.e. > helping to lock you out from using some functionality > of your own hardware. > > Incidentally, a system compromised in this way would > also not be secure if the passphrase was entered manually. > Protecting against an unnoticed system compromise is not > in the scope of disk encryption. > > Arno > > On Sat, Oct 18, 2014 at 01:47:24 CEST, Alex Elsayed wrote: >> Well, it actually _is_ entirely possible: >> >> If your machine has a TPM (yes, big 'if', but many laptops do although >> embedded boards don't), then tpm-luks[1] uses the TPM to store the >> cryptsetup key in the TPM's nvram, such that it can only be extracted if >> everything is unmodified. >> >> This isn't what you want, but it's enough to build it: >> >> Rather than use the key from NVRAM directly, use it as an encryption key >> for >> the keyfile fetched over (say) TLS or SSH. >> >> Thus, even if someone fetches the file when they aren't supposed to have >> it, >> it's just a blob - one that can only be used when the hardware and >> software >> are unmodified. >> >> It also works with the device as the client, unlike the dropbear method. >> >> Note that the same kind of thing can be done with smartcards - then it's >> just an extension of the old "cryptsetup + smartcard" setup, with the >> additional step of _fetching_ the encrypted keyfile, rather than just >> putting it in the initramfs. However, that doesn't bind to the state of >> software the way a TPM can, so you lose out on some security. >> >> Cpp wrote: >> >> > Thanks for the hints. >> > >> > Yeah, the main reason I wanted to implement something like this is to >> > avoid having to boot up each and every device individually after a >> > power cut. Most of my devices use disk encryption by default, let it >> > be a desktop computer, a laptop or an embedded board like Raspberry >> > Pi, Cubieboard, Beaglebone, etc. >> > >> > But after thinking about it for a while, I can't see a way how to >> > securely implement this. I mean even if I were to SSH to the device, >> > I'd still have no indication whether or not it was modified by an >> > intruder, so physical access is a real problem. The only way I can >> > think of is to equip all devices with physical protection circuitry, >> > and have them running 24/7 - each and every device would need an UPS >> > (uninterruptable power supply). >> > >> > Regards! >> > >> > On 10/14/14, Arno Wagner <arno@xxxxxxxxxxx> >> > wrote: >> >> On Tue, Oct 14, 2014 at 23:16:24 CEST, Jonas Meurer wrote: >> >>> Hi Cpp, >> >>> >> >>> Am 14.10.2014 um 13:42 schrieb Cpp: >> >>> > I'm interested in a solution for devices with LUKS disk encryption >> >>> > that use a remote server to securely obtain a decryption key upon >> >>> > boot. Let me elaborate: Suppose I have an embedded device i.e. >> >>> > Raspberry Pi with an external USB HDD or maybe a Cubieboard with a >> >>> > SATA-attached disk. The rootfs is located on an encrypted partition >> >>> > on >> >>> > the disk that has to be decrypted before the OS can boot. The boot >> >>> > partition is located on an unencrypted NAND/SD partition. >> >>> > >> >>> > Normally a modern linux distro will ask the user to type in the >> >>> > password via a keyboard upon boot, if disk encryption is being used. >> >>> > I >> >>> > am however interested in setups where this decryption key is >> >>> > obtained >> >>> > securely (TLS?) from a remote (secure) server via LAN. >> >>> > >> >>> > Are there any known setups like this that I can take a look at? >> >>> >> >>> Debian and Ubuntu cryptsetup packages (at least, I don't know about >> >>> other distributions) support remote unlocking in initramfs. It works >> >>> the >> >>> following way: the dropbear ssh server ist started in initramfs, you >> >>> ssh >> >>> into the initramfs and unlock the root partition, afterwards the boot >> >>> process is continued. See section 8. of README.Debian in the >> >>> distribution packages[1] for further information. >> >> >> >> Nice! For remotely-triggered unlocking, that is a good solution. >> >> >> >> Arno >> >> >> >> >> >>> Cheers, >> >>> jonas >> >>> >> >>> [1] or: here >> >>> >> http://sources.debian.net/src/cryptsetup/2:1.6.6-2/debian/README.Debian/#L202 >> >> >> >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 > ---- > A good decision is based on knowledge and not on numbers. -- Plato > > If it's in the news, don't worry about it. The very definition of > "news" is "something that hardly ever happens." -- Bruce Schneier > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
