Rule of thumb: If an adversary has physical access to the system, he can bypass any mean of protection, if you don't know he had access. In these cases, when there's a possibility, someone has physical access, you should always consider the system as compromised and you neither unlock anything, no matter if you do it remotely or locally. Regards -Sven On Mon, September 21, 2009 15:47, Niall Murphy wrote: > ----- Jonas Meurer <jonas@xxxxxxxxxxxxxxx> wrote: >> it depends on whether you want to encrypt the whole system, including >> root filesystem, or if encrypting the data partitions is enough. >> >> for the latter case you can ssh-login into the machine after boot, >> unlock the encrypted data partitions and start services manually. >> >> in case that the root partition should be encrypted, you'll need to >> start a minimal ssh daemon in the initramfs in order to login remotely >> and unlock the root partition before the root filesystem is mounted. >> >> the debian cryptsetup package supports remote unlocking of the root >> partition with the help of a dropbear ssh server inside the initramfs. >> see README.remote for more information: >> http://svn.debian.org/wsvn/pkg-cryptsetup/cryptsetup/trunk/debian/README.remote >> >> please note that this information is specific to the debian and ubuntu >> distributions. it doesn't apply if you use any other linux distribution. >> > Thanks Jonas, > > That sounds ideal. However, i came across this so have some reservations. > http://www.howtoforge.com/unlock-a-luks-encrypted-root-partition-via-ssh-on-ubuntu > > It lists two types of attack to this approach: > > (1) ColdBoot Attack by reading the crypto password from the ram blocks > (not much you can't do against that without special hardware, see here) > > (2) The created initrd can be manipulated so that it logs the crypto > password somewhere. As /boot is not encrypted an attacker may gain this > way the password for the LUKS-devices. You could, to prevent that, make a > bootable cd with the according kernels and initrds and implement some kind > of hash check... maybe there are other methods... feedback is welcomed > here. > > > If you could elaborate on this i'd appreciate it. > > > -- > Niall > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt