Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
On Sun, 30 Sep 2018 20:03:41 +1000 Andrew McGlashan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > On 30/09/18 16:44, deloptes wrote: > > Celejar wrote: > > > >> But grub itself and its configuration can't be encrypted, so an > >> attacker could still compromise that code / data. IIUC, your > >> solution basically just implies moving some of the logic > >> currently in the initramfs into grub. > > > > Yes, this is the point I am making. > > > >> One solution is to run grub from removable media, and preventing > >> attackers from getting physical access to it ... > > You can sometimes do remote mounting in something like HP's iLO > you could mount a floppy or ISO image and boot it with the image only > being available from a client machine using iLo. But it won't work > for machines without such capability. I actually do the equivalent using Dell's iDrac - I configure it (together with the machine's BIOS) to make the system console available over ssh (using iDrac ssh credentials), and then use that console to provide the credentials to unlock the system disk. IIUC, the security of this is equivalent to your method. Celejar
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 30/09/18 16:44, deloptes wrote: > Celejar wrote: > >> But grub itself and its configuration can't be encrypted, so an >> attacker could still compromise that code / data. IIUC, your >> solution basically just implies moving some of the logic >> currently in the initramfs into grub. > > Yes, this is the point I am making. > >> One solution is to run grub from removable media, and preventing >> attackers from getting physical access to it ... You can sometimes do remote mounting in something like HP's iLO you could mount a floppy or ISO image and boot it with the image only being available from a client machine using iLo. But it won't work for machines without such capability. Cheers A. -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW7CfdgAKCRCoFmvLt+/i +zdRAQDLYu/z/LeeYe0rEmjRhzOU/K9zFPOWiICf/1elYU1htQEAq8YIRVub6kjb Kw142B0ig3S0CkEY39l4Jq0IRbipGlY= =BYHj -END PGP SIGNATURE-
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
Celejar wrote: > But grub itself and its configuration can't be encrypted, so an > attacker could still compromise that code / data. IIUC, your solution > basically just implies moving some of the logic currently in the > initramfs into grub. > Yes, this is the point I am making. > One solution is to run grub from removable media, and preventing > attackers from getting physical access to it ... > But this does not apply for a server, where you do not have physical access, however in this case it is also obvious that no one can easily access the machine and alter anything on it, except it is stolen. > Disclaimer: I'm no expert, and am just expressing my understanding of > the underlying unsolvable problem based on what I've read about it. so do I
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
On Thu, 27 Sep 2018 17:54:26 +1000 Andrew McGlashan wrote: ... > The biggest weakness with the Dropbear setup is that the initramfs is > stored on an unencrypted partition (no matter which file system is > used). That means that someone with physical access can rebuild the > initramfs and include their own key as well as other stuff to > compromise the security of the server. > > Aside from the fact that the IME is suspect, it would be great if grub > can be, somehow, given a method that allows for full disk encryption > which will include everything in /boot -- especially initramfs. But grub itself and its configuration can't be encrypted, so an attacker could still compromise that code / data. IIUC, your solution basically just implies moving some of the logic currently in the initramfs into grub. One solution is to run grub from removable media, and preventing attackers from getting physical access to it ... Disclaimer: I'm no expert, and am just expressing my understanding of the underlying unsolvable problem based on what I've read about it. Celejar
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
On Fri, Sep 28, 2018 at 1:32 AM deloptes wrote: > Andrew McGlashan wrote: > > > The biggest weakness with the Dropbear setup is that the initramfs is > > stored on an unencrypted partition (no matter which file system is > > used). That means that someone with physical access can rebuild the > > initramfs and include their own key as well as other stuff to > > compromise the security of the server. > > > Exactly what I was saying > > > Aside from the fact that the IME is suspect, it would be great if grub > > can be, somehow, given a method that allows for full disk encryption > > which will include everything in /boot -- especially initramfs. > > > > but it would also mean that it should be accessible over the internet, > because I do not see any other way to reach the server and decrypt. > > > > Even so, then grub might have another attack vector of itself. But it > > would at least allow for encrypted /boot ... > > Well but again we shift from the boot partition to grub - hense if > probability that one has physical access to the server can be ignored, > dropbear is still practical solution. > > regards > That's why the reverse scenario is better, you include a client SSH key in the initramfs which you use to ssh to a remote server and download the encryption key. The way I see it an important part of all these remote storage methods, apart from automation, is prevention and remediation. First it can limit the resource access from only specific IP(s) so If someone heads off with your encrypted disk your data will stay protected since the key can not be retrieved from anywhere else but your IP. And second, although it seems that you have just replaced one kind of plain text credentials (the encryption key) with another one (ssh key or AWS IAM user credentials), you can actually still protect yourself by revoking those credentials on the remote server/storage side upon a security incident.
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
Andrew McGlashan wrote: > The biggest weakness with the Dropbear setup is that the initramfs is > stored on an unencrypted partition (no matter which file system is > used). That means that someone with physical access can rebuild the > initramfs and include their own key as well as other stuff to > compromise the security of the server. > Exactly what I was saying > Aside from the fact that the IME is suspect, it would be great if grub > can be, somehow, given a method that allows for full disk encryption > which will include everything in /boot -- especially initramfs. > but it would also mean that it should be accessible over the internet, because I do not see any other way to reach the server and decrypt. > Even so, then grub might have another attack vector of itself. But it > would at least allow for encrypted /boot ... Well but again we shift from the boot partition to grub - hense if probability that one has physical access to the server can be ignored, dropbear is still practical solution. regards
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/09/18 03:17, Jonathan Dowland wrote: > On Wed, Sep 26, 2018 at 06:14:42PM +0200, deloptes wrote: >> so how can we do it with initram and without some external key >> server? Imagine I have only boot not encrypted on the server. I >> want to boot the machine and get a prompt via SSH or something >> like SSH, where I can type in the password and decrypt root and >> all other volumes. I do not want to store password or anything >> sensitive in the boot directory. I can imagine one time ssh >> created when you try to login, but it is still not secure >> enough. > > What you describe is exactly how the dropbear/initramfs > integration works. The data stored in /boot is the initramfs, and > within that, the only material you might consider sensitive is an > SSH server keypair (public) for the SSHD instance in the > initramfs environment - this does not need to be the same as for > your running system; and an authorized_keys file, containing your > SSH *public* key. Are those too sensitive for you? The biggest weakness with the Dropbear setup is that the initramfs is stored on an unencrypted partition (no matter which file system is used). That means that someone with physical access can rebuild the initramfs and include their own key as well as other stuff to compromise the security of the server. Aside from the fact that the IME is suspect, it would be great if grub can be, somehow, given a method that allows for full disk encryption which will include everything in /boot -- especially initramfs. Even so, then grub might have another attack vector of itself. But it would at least allow for encrypted /boot ... Kind Regards AndrewM -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW6yMrQAKCRCoFmvLt+/i +xPvAQCW/jz4Iq50mRaz4hJrUWIKqbJ/iUpCCcMXntPfcZDwRwD/SuPsHGGVjMCi 1Vk/BfTPN27cRE3CtHIntxItupUqzJ0= =7lcL -END PGP SIGNATURE-
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
Jonathan Dowland wrote: > What you describe is exactly how the dropbear/initramfs integration > works. The data stored in /boot is the initramfs, and within that, the > only material you might consider sensitive is an SSH server keypair > (public) for the SSHD instance in the initramfs environment - > this does not need to be the same as for your running system; and an > authorized_keys file, containing your SSH *public* key. Are those too > sensitive for you? > thanks I read and this is what I think. I wanted to know how the other project can be adapted. I think dropbear is very close to what I wanted to have. > I suspect you could probably do without the SSHD public/private keypair > and have the initramfs environment generate a new pair each time, but > then you'd have no chain of trust for connecting to it; so you have to > weigh up those two scenarios. Yes it is two faces of same evil, but I would trust the guys behind dropbear and adopt what they suggest. regards
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
On Wed, Sep 26, 2018 at 06:14:42PM +0200, deloptes wrote: so how can we do it with initram and without some external key server? Imagine I have only boot not encrypted on the server. I want to boot the machine and get a prompt via SSH or something like SSH, where I can type in the password and decrypt root and all other volumes. I do not want to store password or anything sensitive in the boot directory. I can imagine one time ssh created when you try to login, but it is still not secure enough. What you describe is exactly how the dropbear/initramfs integration works. The data stored in /boot is the initramfs, and within that, the only material you might consider sensitive is an SSH server keypair (public) for the SSHD instance in the initramfs environment - this does not need to be the same as for your running system; and an authorized_keys file, containing your SSH *public* key. Are those too sensitive for you? I suspect you could probably do without the SSHD public/private keypair and have the initramfs environment generate a new pair each time, but then you'd have no chain of trust for connecting to it; so you have to weigh up those two scenarios. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
Igor Cicimov wrote: > 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. so how can we do it with initram and without some external key server? Imagine I have only boot not encrypted on the server. I want to boot the machine and get a prompt via SSH or something like SSH, where I can type in the password and decrypt root and all other volumes. I do not want to store password or anything sensitive in the boot directory. I can imagine one time ssh created when you try to login, but it is still not secure enough. Can you help with some thoughts on how to implement it? thanks
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
On Wed, 19 Sep 2018 12:58 pm Andy Smith 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. >
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/19/2018 02:57 AM, Andy Smith wrote: > 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." Another attack would be to note the exact time that you removed the servers, then when you wish to talk with them again, set up an NTP server to provide the old time (intercepting any requests trying to get the time from another server of course). Mandos does sound interesting though, but I don't think I'll be using it. Especially if it is possible to easily lock yourself out! Cheers AbndrewM -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCW6JvcgAKCRCoFmvLt+/i ++WrAPsFm6b0dUqtHGh3S4Nhyyc5nL2M6vyi880aAJwF3wHXIgEAxxtdKZAdePqQ aGe8EMYKDRsjhkP9Mxd74qtxVZ8S58E= =2TGh -END PGP SIGNATURE-
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
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
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 18/09/18 04:15, deloptes wrote: > I wanted to have a look at this link, that someone mentioned: > https://hamy.io/post/0009/how-to-install-luks-encrypted-ubuntu-18.04.x - -server-and-enable-remote-unlocking/ > > It seems to address the question above and it looks promising That link does, essentially, what I have been doing for a while -- NO ENCRYPTION of /boot I was hoping for a grub option to include dropbear ssh not included in initramfs Thanks anyway Cheers -BEGIN PGP SIGNATURE- iF4EAREIAAYFAluhPSoACgkQqBZry7fv4vujZAD+Nw/iemd8YwI13YnSxxYV8X2M +FTHl+Th4rXs83vmM6ABAM8r5dBRRbnHHFZXFM/jF76WNMc1/Z/fdd1ukrnHbBBX =cxZD -END PGP SIGNATURE-
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
Pascal Hambourg wrote: > How dos this address the above concern ? IMO this is not applicable when my server has to use encrypted root, which I would be able to decrypt via SSH at boot. The question is what do I gain when boot is not encrypted and I have there my SSH key and password and so on. I wanted to have a look at this link, that someone mentioned: https://hamy.io/post/0009/how-to-install-luks-encrypted-ubuntu-18.04.x-server-and-enable-remote-unlocking/ It seems to address the question above and it looks promising regards
Re: Decrypting LUKS from initramfs; was: Re: ext2 for /boot ???
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. For those who wanted to get more elaborate (and more likely to mess up and leave their server a useless encrypted brick), there are things like Mandos: https://wiki.recompile.se/wiki/Mandos https://www.recompile.se/mandos/man/intro.8mandos "This is the the Mandos system, which allows computers to have encrypted root file systems and at the same time be capable of remote and/or unattended reboots. The computers run a small client program in the initial RAM disk environment which will communicate with a server over a network. All network communication is encrypted using TLS. The clients are identified by the server using an OpenPGP key; each client has one unique to it. The server sends the clients an encrypted password. The encrypted password is decrypted by the clients using the same OpenPGP key, and the password is then used to unlock the root file system, whereupon the computers can continue booting normally." How dos this address the above concern ?
