Re: Remote authentication?

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

 



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

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux