I still see two problems here: Can the TPM verify the firmware as it is interchangeable? And how should this be possible? (It would have to hook inbetween CPU and chipset AFAIK). Second problem is replacing/modifying the TPM. You'd have to mitigate this physicly I guess. Regards -Sven On Tue, October 21, 2014 06:37, Alex Elsayed wrote: > Pardon, but that's where the "predicated on the software state" comes in. > > TPM-based solutions (fully-implemented ones via tboot and such) verify the > entire chain - bootloader to kernel to initramfs. If the verifications > don't > match the saved values, the NVRAM PCRs don't unlock and are inaccessible. > > Your assessment would be true if a TPM was basically just something like a > smartcard - a HSM holding a key, that can encrypt/decrypt on behalf of the > user. However, that is not all a TPM is. > > This actually makes use of one of the features that made TPMs relatively > controversial - the ability to attest to the state of the system _as a > whole_, _including_ the running software. However, like all power, it can > be > used for 'evil' ("You jailbroke the machine, your keys to Hollywood Movies > #24601-#34159 are now revoked!") it can also be used for 'good' ("Sorry, > your initramfs has a rootkit in it, I don't feel safe handing over the > key.") > > Arno Wagner 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 >> > > > _______________________________________________ > 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