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
