On Tue, October 21, 2014 15:46, Arno Wagner wrote:
> On Tue, Oct 21, 2014 at 12:01:13 CEST, Sven Eschenberg wrote:
>> 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).
>
> It cannot. The TPM is basically akin to a fixedly-installed chipcard.
> The hardware all still works just ignoring it, and it is entirely
> possible to use a blue-pill rootkit to make the TPM think everything
> is fine, when it decidedly is not.
Imho this should work both ways. As the firmware entrypoint is not checked
or provided by the TPM you can easily interchange the firmware. And you
can interchange the TPM providing exactly the answers a bootloader (and
everything further on in the chain) would expect. And probably this ain't
the end of possible attack vectors.
>
>> Second problem is replacing/modifying the TPM. You'd have to mitigate
>> this
>> physicly I guess.
>
> The TPM is a low-cost solution, and its primary use is
> identification for DRM purposes, i.e. put media decryption
> keys in there. That only works if the OS collaporates with
> the TPM against the user.
I merely wanted to point out that most TPMs aren't even soldered. a
blackbox that can be exchanged in a plug'n'pray manner doesn't do you any
good. And even if it was soldered, there's still further options
(including resoldering or simple firmware exchange or other means of
skimming).
>
> Arno
>
Regards
-Sven
>>
>> 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
>
> --
> 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
