Passphraseless Disk Encryption Options?

[Analysiser]

Hi all,

Thank you so much for all the insights here! I think I is my bad not to clarify the situation very well but still I found a lot of things I could try from the replies. In my case I could not do remote passphrase and and USB boot and/or USB hold key/passphrase since the device might not always have internet access and no ports (internally or externally are exposed). 

I think your suggestions in separating the root filesystem and user space applications and data and perform encryption only on user portion is a more reasonable practice given the time scale on the project I’m working on. Thanks again!

I still have some more detailed questions I’m seeking for an answer related to the full startup disk encryption:

Background is  I’m using geli that creates an encrypted partition that holds the whole OS and an unencrypted partition that has the symlink to /boot, which would boot first and ask for passphrase, my questions are:

	1. is it possible to provide a plain text passphrase on the unencrypted partition and feed it to GELI for decrypting the full disk at all?
	
	2. If 1 is possible, is it possible to seal that passphrase in TPM (as the locked box that holds the key for the house) and only provide the passphrase only when secure booted and system in a known status?
	
	3. If 2 is possible, is it possible for an attacker to recover the passphrase during the process when TPM gives it out? 

Hopefully if the answer is 110 then I think I would keep on experimenting on the full startup disk encryption, or else I would try to encrypt only part of the OS instead…


Thank you all so much!
Xiao


> On Sep 8, 2015, at 1:56 PM, Xin Li <delphij at delphij.net> wrote:
> 
> 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
>