On Wed, 19 Sep 2018 12:58 pm Andy Smith <a...@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. >
