Passphraseless Disk Encryption Options?

[Xin Li]

On 09/08/15 11:35, Li, Xiao via freebsd-hackers wrote:
> Agreed, that¹s why I¹m stuck in here: it seems like something either
> unachievable or haven¹t been done before. I mentioned Apple¹s method is
> only because it is something similar in that both requires a full disk
> encryption on startup disk. But Apple¹s way is like to decrypt the disk on
> login; I¹m trying to decrypt the disk during prelogin after the boot.

If the goal is to use the same key that can unlock the whole disk before
the user logs in and keep all data safe, then it's unachievable.

You could, however, split the system data into two parts, one is the
firmware-alike portion, for instance boot partition, the root filesystem
that holds all system executable and the kernel, etc., and the other is
the user data portion, where user home directory, temporary files, swap
are located.  Then, encrypt the user portion with a separate key
protected by the user's login.

Note that it's quite tricky to get the remote keying right, and it's not
always possible if you can't keep the local console and system data
safe.  A few years ago I have implemented something experimental, that
allowed me to unlock my laptop remotely that have a passphrase protected
GELI volume with it:

	https://lists.freebsd.org/pipermail/freebsd-security/2012-August/006547.html

You would be able to log in as root via SSH from remote, because the
script sets up network, and starts a SSH daemon, so a remote login and
entering GELI passphrase would unlock the provider; or alternatively if
someone is at the laptop side, they can press enter to stop the loop and
enter the passphrase directly from console.

As we can see, this setup is not 100% safe and rely on the fact that the
laptop has to be in a trustworthy place.  For instance, an attacker may
do this to completely defeat my experimental environment:

 - Turn off the power and copy the whole hard drive.
 - Because binaries are not encrypted nor signed (*), replace GELI
binary that does this:
    1. Ask for passphrase
    2. Attempt to unlock the provider, if success, send the passphrase
to the attacker and restore the old GELI binary.
 - The attacker in their place unlock my data on their copy once
passphrase is received.

So, while it's probably (practically) good enough to prevent data loss
for average theft (someone steal the laptop and sell it to someone who
is interested in the business data) and obviously better than not
encrypting at all, it does not protect the data if it's a deliberate and
targeted attack.

(*) It would be possible to prevent this by establishing a full trust
chain from the firmware to everything that gets run in the OS.  At this
time, FreeBSD do not verify executables/kernels/shared libraries before
mapping them as executable, and there is no way to safely verify the
system being uncompromised if you are paranoid enough.  Verification is
a low hanging fruit though, because the in-kernel cryptographic
infrastructures are already there.

Cheers,
-- 
Xin LI <delphij at delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20150908/065683e6/attachment.bin>