All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Elsayed <eternaleye@gmail.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] LUKS disk encryption with remote boot authentication
Date: Fri, 17 Oct 2014 16:47:24 -0700	[thread overview]
Message-ID: <m1s9m3$3q9$1@ger.gmane.org> (raw)
In-Reply-To: CAHeB2AnC4h16rxvtXgTuwbFW0dcf+t+HqLs3yzT+x8M8kh7h=g@mail.gmail.com

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

  parent reply	other threads:[~2014-10-17 23:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-14 11:42 [dm-crypt] LUKS disk encryption with remote boot authentication Cpp
2014-10-14 12:42 ` Ralf Ramsauer
2014-10-14 13:12 ` Arno Wagner
2014-10-14 21:16 ` Jonas Meurer
2014-10-14 21:51   ` Arno Wagner
2014-10-15  6:49     ` Cpp
2014-10-15 11:37       ` Sam Rakowski
2014-10-17 23:47       ` Alex Elsayed [this message]
2014-10-17 23:51         ` Alex Elsayed
2014-10-18  3:37         ` Arno Wagner
2014-10-19 19:13           ` Cpp
2014-10-19 19:40             ` Ralf Ramsauer
2014-10-19 20:12               ` Arno Wagner
2014-10-19 20:59                 ` Cpp
2014-10-19 22:10                   ` Arno Wagner
2014-10-20 10:09                     ` Sven Eschenberg
2014-10-20 13:36                       ` Arno Wagner
2014-10-21  4:37           ` Alex Elsayed
2014-10-21 10:01             ` Sven Eschenberg
2014-10-21 13:46               ` Arno Wagner
2014-10-21 14:50                 ` Sven Eschenberg
2014-10-21 16:18                   ` Arno Wagner
2014-10-21 13:42             ` Arno Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='m1s9m3$3q9$1@ger.gmane.org' \
    --to=eternaleye@gmail.com \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.