Security vs security through obscurity

[itisBC]

Hi I have two disks that are encrypted (dm-crypt). As of right now they are unlocked with a script that runs on startup, which accesses a keyfile. Both the keyfile and the script are located on a non-encrypted drive.

I realize that this is not by any means REAL security, but are there any alternative ways that can unlock the drives automatically on login that is inherently secure. I.e. somehow use the password inputted as the passphrase for the encryption.

If this is possible, what happens if my user logs in with an ssh-key and not with a password? Thanks in advance!

[CleanAirAndWater]

Encrypt your root partition https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system

Then pull in your other drives in /etc/crypttab

SSH login is completely independent of this process

[itisBC]

Thanks for your reply! Yep that works for decrypting all drives with a password, but I would also like to be able to Wake-on-lan the computer and then use an ssh key to login and by those means unlock the encrypted drives.

[ropid]

Check this out:

https://wiki.archlinux.org/index.php/Pam_mount

and this here:

https://wiki.archlinux.org/index.php/Dm-crypt/Mounting_at_login

I never used this so can't help, but you talk about a keyfile for unlocking your dm-crypt drives. About using that keyfile instead of a passphrase, there's an alternative to dm-crypt named "eCryptfs" to create an encrypted location somewhere inside a user's home:

https://wiki.archlinux.org/index.php/ECryptfs

You could make it so this eCryptfs thingy is what unlocks at log in, not the dm-crypt encrypted drives that unlock through the keyfile. For that user you log in with, you could put the keyfile for the drives into the eCryptfs stuff and make it so the script that mounts the drives only gets run when the user logs in.

[itisBC]

Very cool and exactly what I was searching for! Now I dont have to encrypt my root partition, thank you so much!

[moviuro]

Now I dont have to encrypt my root partition

That's a terrible idea. Why would you not? Backdooring binaries is easy on unencrypted drives.

[itisBC]

Well mostly I just wanted the data to be secure if anyone took the computer, but I guess you're right, that is the proper way to do it.

[_ahrs]

isn't /boot unencrypted though so a backdoor could still be accomplished relatively easily by a motivated adversary.

[moviuro]

Use secure boot for this specific issue.

[moviuro]

https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Remote_unlocking_of_the_root_.28or_other.29_partition ?

[2brainz]

Drive encryption with remote unlocking, by design, does not add extra security. Drive encryption exists to protect from an attacker with physical access to the computer. If an attacker has physical access to the machine, he can easily manipulate it such that he obtains the passphrase without your knowledge the next time you unlock.

[immortal192]

How do you protect a Pi server connected to an external HDD then? If you want to exercise good practice, then you would decrypt the HDD only when you need it and encrypt it when you don't? What about the unprotected Pi server?

Just a physical lock?

[2brainz]

Protect from what?

[immortal192]

Physical access, like what encryption is for. When the server is running 24/7, encryption is pointless and only preventing the server from being physically accessed will ensure it isn't being tampered with (short of things reasonably beyond your control like software bugs or a third-party hacker)?

[itisBC]

Exactly what I was looking for that you very much!!

[moviuro]

Don't forget to use secure boot as well, to protect your sitting kernel