[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???





On Wed, 19 Sep 2018 12:58 pm Andy Smith <andy@strugglers.net> wrote:
Hello,

On Mon, Sep 17, 2018 at 08:00:50PM +0200, Pascal Hambourg wrote:
> Le 16/09/2018 à 00:39, Andy Smith a écrit :
> >
> >The obvious problem there is an attacker who gets hold of the
> >initramfs in order to be able to use the credentials to request the
> >passphrase themselves.

[…]

> >     https://wiki.recompile.se/wiki/Mandos

> How dos this address the above concern ?

It is of course impossible to have both entirely automated unlocking
and perfect protection against someone taking the credentials from
the unencrypted bootstrap environment.

Having a script in your initramfs that unlocks your encrypted
filesystem provides no protection at all from someone who obtains a
copy of your initramfs and your encrypted filesystem.

You could add some more protection by using an online key/value
store instead of hard-coded credentials, since the key/value server
could also enforce things other than simple access to a file. For
example, it could require the request to come from a certain IP
address.

Using something like Mandos is another step along this path, by
requiring the unlock attempt to come within some short time period
since the last time your server checked in. It has shifted the
requirements from "have a copy of the encrypted filesystem and a
copy of the initramfs" to "have a copy of the encrypted filesystem
and the initramfs and be able to talk to the Mandos server from the
correct IP address within the required time interval". All it can do
is make the attack harder, not make it impossible.

It also clearly adds a lot of opportunities for you to permanently
lock yourself out of the encrypted filesystem by accident, unless
you take the precaution of having another set of credentials for
"emergency manual unlock" that you keep elsewhere.

An attacker who is aware of requirements such as where the secrets
server is, how to interact with it, where requests must come from,
time window in which requests must be made, etc is not going to be
defeated. Mandos's argument seems to be that such attackers are rare
and will probably just use the law or techniques like memory dumping
in preference to all that anyway.

    https://www.recompile.se/mandos/man/intro.8mandos

    "FREQUENTLY ASKED QUESTIONS

    Couldn't the security be defeated by…

    Grabbing the Mandos client key from the initrd really quickly?

    This, as mentioned above, is the only real weak point. But if
    you set the timing values tight enough, this will be really
    difficult to do. An attacker would have to physically
    disassemble the client computer, extract the key from the
    initial RAM disk image, and then connect to a still online
    Mandos server to get the encrypted key, and do all this before
    the Mandos server timeout kicks in and the Mandos server refuses
    to give out the key to anyone.

    Now, as the typical procedure seems to be to barge in and turn
    off and grab all computers, to maybe look at them months later,
    this is not likely. If someone does that, the whole system will
    lock itself up completely, since Mandos servers are no longer
    running.

    For sophisticated attackers who could do the clever thing, and
    had physical access to the server for enough time, it would be
    simpler to get a key for an encrypted file system by using
    hardware memory scanners and reading it right off the memory
    bus."

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

An example for automation with AWS using SSM and KMS services https://icicimov.github.io/blog/server/LUKS-with-AWS-SSM-and-KMS-in-Systemd/
It can be modified for initramfs.

Reply to: