[dm-crypt] LUKS disk encryption with remote boot authentication

[dm-crypt] LUKS disk encryption with remote boot authentication

[Cpp]

Hello,

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?

Kind regards!

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Ralf Ramsauer]

Hi,

I don't know any stock setup like this. But that doesn't imply, that it
is impossible.

What do you actually hope to gain from it?
I *suppose* you want to remotely obtain the key because you don't want
to type any passphrases onto a headless setup.

Sure, using a initrd, playing around with it a bit will probably solve
your problem, but keep in mind, that your Raspberry should authenticate
against the "key-server" (e.g. using a certificate) when using a TLS
connection.
During the bootup process, the Raspberry needs to have access to that
certificate. So if someone has physical access to your device, he can
steal your certificate and steal your passphrase.

Maybe it would be better to use a USB flash drive containing a keyfile.
During the bootup, you stick in the flash drive, afterwards you can
remove it and keep it at some secret place :-)

Cheers
  Ralf

On 10/14/14 14:42, Cpp wrote:
> Hello,
>
> 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?
>
> Kind regards!
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Arno Wagner]

Hi Cpp,

I do not think that is conceptually possible. Sure, you could, 
for ecample, do a password-less ssh to that server to
get the passphrase and pipe that directly to cryptsetup. But 
that is not more secre than storing the pasphrase on the device 
itself in plain, unless you can remove the passphrase on the
remote server in case of issues.

Basically, you would do something like this in the initrd:

  ssh remote_server "cat keyfile_mine" | cryptsetup <device> -d -

Of course, the ssh root-user key would need to be present
in the initrd for this to work and remote_server would
need to allow password-less logins for that key. You also
have to have the host key of remote_server in the local
known_hosts file on the initrd for this to be secure.

You should also know that LUKS does not do pre-boot. What
can be done is boot the OS in a minimal configuration from an 
initrd, map the encrypted container, and then replace the
root filesystem with that one from disk. But LUKS container 
mapping always happens and must happen _after_ the kernel
has finished comming up and some minimal OS has been booted.

Arno


On Tue, Oct 14, 2014 at 13:42:54 CEST, Cpp wrote:
> Hello,
> 
> 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?
> 
> Kind regards!
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Jonas Meurer]

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.

Cheers,
 jonas

[1] or: here
http://sources.debian.net/src/cryptsetup/2:1.6.6-2/debian/README.Debian/#L202

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Arno Wagner]

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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Cpp]

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@wagner.name> 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@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Sam Rakowski]

Sorry for the duplicate, Cpp. I meant this to go to the list. 

But physical access was always a problem (of the same magnitude), wasn't it? Consider an attacker modifying initramfs so that your password entered into cryptsetup is sent to a remote server, then used to unlock your luks device. Isn't that of equal likelihood?
Sent via BlackBerry

-----Original Message-----
From: Cpp <tzornik@gmail.com>
Sender: "dm-crypt" <dm-crypt-bounces@saout.de>Date: Wed, 15 Oct 2014 08:49:54 
To: <dm-crypt@saout.de>
Subject: Re: [dm-crypt] LUKS disk encryption with remote boot authentication

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@wagner.name> 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@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Alex Elsayed]

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@wagner.name>
> 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

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Alex Elsayed]

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.

Gah, forgot my footnote.

[1] https://github.com/shpedoikal/tpm-luks

<snip>

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Arno Wagner]

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@wagner.name>
> > 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Cpp]

I've been doing some thinking.....

The only way to secure a local device is to implement some
anti-tamering circuitry and have it running 24/7. This circuitry will
be reponsible for physical protection i.e. safe keeping the encryption
key and destroy it in case an attacker tries to access it. Then again
as soon as power is gone, all bets are off because the adversary can
hack the device while it's protection circuitry is offline. Therefore
the circuitry will have to be continuously powered up (i.e. by using
an UPS) so that it can do its job.

But in theory, having an UPS to have the device running 24/7 defeats
the whole purpose of having a remote authentication mechanism in place
for cases like power cuts. It also defeats the purpose of having a
passphrase or encryption key stored somewhere other than the devices
RAM (i.e. NAND flash or USB key). In fact, the device should mount the
LUKS container and immediately wipe all LUKS key slots so that only
the master key remains in RAM. Once tampering is detected, the device
simply powers off. Use some epoxy to prevent easy access to RAM
chips... cold boot anyone?

Thoughts?

On 10/18/14, Arno Wagner <arno@wagner.name> 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@wagner.name>
>> > 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@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Ralf Ramsauer]

On 10/19/14 22:13, Cpp wrote:
> This circuitry will
> be reponsible for physical protection i.e. safe keeping the encryption
> key and destroy it in case an attacker tries to access it.
> Use some epoxy to prevent easy access to RAM
> chips... cold boot anyone?
Erm, just my two cents, but do you *really* think that this is a threat
to you?
In my opinion, costs and benefits should maintain balance...

And I am quite sure that your self-made tamper safe solution will
probably fail, if someone is really willing to break into your system.

So I think ssh'ing to your system and entering the passphrase manually
remains the best solution.

Cheers
  Ralf

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Arno Wagner]

On Sun, Oct 19, 2014 at 21:40:28 CEST, Ralf Ramsauer wrote:
> On 10/19/14 22:13, Cpp wrote:
> > This circuitry will
> > be reponsible for physical protection i.e. safe keeping the encryption
> > key and destroy it in case an attacker tries to access it.
> > Use some epoxy to prevent easy access to RAM
> > chips... cold boot anyone?
> Erm, just my two cents, but do you *really* think that this is a threat
> to you?
> In my opinion, costs and benefits should maintain balance...
> 
> And I am quite sure that your self-made tamper safe solution will
> probably fail, if someone is really willing to break into your system.

Actually, it has a pretty good chance of working well. Once.
And if it is not too obvious and nowhere documented that the
attacker can get at beforehand.

Arno
 
> So I think ssh'ing to your system and entering the passphrase manually
> remains the best solution.
> 
> Cheers
>   Ralf
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Cpp]

On 10/19/14, Arno Wagner <arno@wagner.name> wrote:
> Actually, it has a pretty good chance of working well. Once.
> And if it is not too obvious and nowhere documented that the
> attacker can get at beforehand.

So basically if a device like this is meant to be used and distributed
widely, one security requirement would be that each and every device
uses a custom anti-tampering circuitry setup so that no two setups are
identical. After one device has been compromised, a new custom setup
has to be made, possibly at a new location.

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Arno Wagner]

On Sun, Oct 19, 2014 at 22:59:21 CEST, Cpp wrote:
> On 10/19/14, Arno Wagner <arno@wagner.name> wrote:
> > Actually, it has a pretty good chance of working well. Once.
> > And if it is not too obvious and nowhere documented that the
> > attacker can get at beforehand.
> 
> So basically if a device like this is meant to be used and distributed
> widely, one security requirement would be that each and every device
> uses a custom anti-tampering circuitry setup so that no two setups are
> identical. After one device has been compromised, a new custom setup
> has to be made, possibly at a new location.

For DIY, yes. Commercial HSMs have another protection, namely
they are priced at EUR 50k+. That discourages most attackers from
buying a few to leant how to break into them.

But seriously, this is not a beginner's game. If you want to
keep out a low-resource attacker, just get a safe, drill some
holes for the cables, add an arduino or compatible with light, 
vibration and orientation sensors and make it protect the 
passphrase and pull the plug if it finds something fishy.
Attachment to computer via serial or USB as HID is fine.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Sven Eschenberg]

On Mon, October 20, 2014 00:10, Arno Wagner wrote:
> On Sun, Oct 19, 2014 at 22:59:21 CEST, Cpp wrote:
>> On 10/19/14, Arno Wagner <arno@wagner.name> wrote:
>> > Actually, it has a pretty good chance of working well. Once.
>> > And if it is not too obvious and nowhere documented that the
>> > attacker can get at beforehand.
>>
>> So basically if a device like this is meant to be used and distributed
>> widely, one security requirement would be that each and every device
>> uses a custom anti-tampering circuitry setup so that no two setups are
>> identical. After one device has been compromised, a new custom setup
>> has to be made, possibly at a new location.
>
> For DIY, yes. Commercial HSMs have another protection, namely
> they are priced at EUR 50k+. That discourages most attackers from
> buying a few to leant how to break into them.
>

Would an attacker really spent 50k+ or would he/she spend 10% of that to
break into the company building the HSM? Or even less pricier, break
'into' one or more employees?

> But seriously, this is not a beginner's game. If you want to
> keep out a low-resource attacker, just get a safe, drill some
> holes for the cables, add an arduino or compatible with light,
> vibration and orientation sensors and make it protect the
> passphrase and pull the plug if it finds something fishy.
> Attachment to computer via serial or USB as HID is fine.
>
> Arno
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Regards

-Sven

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Arno Wagner]

On Mon, Oct 20, 2014 at 12:09:32 CEST, Sven Eschenberg wrote:
> On Mon, October 20, 2014 00:10, Arno Wagner wrote:
> > On Sun, Oct 19, 2014 at 22:59:21 CEST, Cpp wrote:
> >> On 10/19/14, Arno Wagner <arno@wagner.name> wrote:
> >> > Actually, it has a pretty good chance of working well. Once.
> >> > And if it is not too obvious and nowhere documented that the
> >> > attacker can get at beforehand.
> >>
> >> So basically if a device like this is meant to be used and distributed
> >> widely, one security requirement would be that each and every device
> >> uses a custom anti-tampering circuitry setup so that no two setups are
> >> identical. After one device has been compromised, a new custom setup
> >> has to be made, possibly at a new location.
> >
> > For DIY, yes. Commercial HSMs have another protection, namely
> > they are priced at EUR 50k+. That discourages most attackers from
> > buying a few to leant how to break into them.
> >
> 
> Would an attacker really spent 50k+ or would he/she spend 10% of that to
> break into the company building the HSM? Or even less pricier, break
> 'into' one or more employees?

I think you have no idea what professional, traceless B&E costs
for companies secured like this, if it is possible at all. And
then all you would be able to steal is some encrypted data.
And the Employee? You first need to find one that has the required 
knowledge and that you can make sure will not talk to his employer.

Sorry, but that does not sound like a valid approach at all.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Alex Elsayed]

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@wagner.name>
>> > 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@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Sven Eschenberg]

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@wagner.name>
>>> > 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@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Arno Wagner]

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.
 
> 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.

Arno

> 
> 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@wagner.name>
> >>> > 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@saout.de
> >>> http://www.saout.de/mailman/listinfo/dm-crypt
> >>
> >
> >
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Sven Eschenberg]

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@wagner.name>
>> >>> > 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@saout.de
>> >>> http://www.saout.de/mailman/listinfo/dm-crypt
>> >>
>> >
>> >
>> > _______________________________________________
>> > dm-crypt mailing list
>> > dm-crypt@saout.de
>> > http://www.saout.de/mailman/listinfo/dm-crypt
>> >
>>
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Arno Wagner]

On Tue, Oct 21, 2014 at 16:50:59 CEST, Sven Eschenberg wrote:
> 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.

I agree on both counts. There even was a TPM software emulator
project at one time (no idea whether it is still active).
 
> >
> >> 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).

Actually, if you free yourself from the idea that the TPM is 
about doing anything _for_ you, and make it entirely 
about enforcing DRM on people with low computer skills, it 
makes sense. The main feature of the TPM is that it can be 
identified over the net and cannot be cloned, not that it 
somehow protects the computer. Hence DRM-ed music, movies, 
etc. are tied to the TPM, not the computer.

Arno



> >
> > 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@wagner.name>
> >> >>> > 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@saout.de
> >> >>> http://www.saout.de/mailman/listinfo/dm-crypt
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > dm-crypt mailing list
> >> > dm-crypt@saout.de
> >> > http://www.saout.de/mailman/listinfo/dm-crypt
> >> >
> >>
> >>
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> >
> > --
> > Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> > 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@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] LUKS disk encryption with remote boot authentication

[Arno Wagner]

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@wagner.name>
> >> > 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@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> > 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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