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
