That does not work either. In effect, the TPM has no power
to do anything, it is just a chip attached to a bus that
can be queried or ignored.
Just boot up a blue-pill rootkit and pretend towards the
TPM that all is fine. It cannot tell the difference.
Arno
On Tue, Oct 21, 2014 at 06:37:06 CEST, 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
--
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
