Date: Tue, 8 Sep 2015 14:50:10 -0700 From: Analysiser <analysiser@gmail.com> To: d@delphij.net Cc: Igor Mozolevsky <igor@hybrid-lab.co.uk>, Hackers freeBSD <freebsd-hackers@freebsd.org> Subject: Re: Passphraseless Disk Encryption Options? Message-ID: <D5104DE1-F889-422E-8017-25B6555396F0@gmail.com> In-Reply-To: <55EF4B65.8030905@delphij.net> References: <8B7FEE2E-500E-49CF-AC5E-A2FA3054B152@gmail.com> <CADWvR2iv7xz02Fw9b=159%2BSMuphQGRKZsfyy9DDeqGMxn=p1BA@mail.gmail.com> <D214715D.1A32%xaol@amazon.com> <CADWvR2iVubsBQjnvQ8mDGGS7ujsR8wPQ2RAxn=kvFkmVGQkXiQ@mail.gmail.com> <D2147761.1A53%xaol@amazon.com> <55EF4B65.8030905@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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).=20 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=92m = working on. Thanks again! I still have some more detailed questions I=92m seeking for an answer = related to the full startup disk encryption: Background is I=92m 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? =09 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? =09 3. If 2 is possible, is it possible for an attacker to recover = the passphrase during the process when TPM gives it out?=20 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=85 Thank you all so much! Xiao > On Sep 8, 2015, at 1:56 PM, Xin Li <delphij@delphij.net> wrote: >=20 > On 09/08/15 11:35, Li, Xiao via freebsd-hackers wrote: >> Agreed, that=B9s why I=B9m stuck in here: it seems like something = either >> unachievable or haven=B9t been done before. I mentioned Apple=B9s = method is >> only because it is something similar in that both requires a full = disk >> encryption on startup disk. But Apple=B9s way is like to decrypt the = disk on >> login; I=B9m trying to decrypt the disk during prelogin after the = boot. >=20 > 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. >=20 > 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. >=20 > 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: >=20 > = https://lists.freebsd.org/pipermail/freebsd-security/2012-August/006547.ht= ml >=20 > 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. >=20 > 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: >=20 > - 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. >=20 > 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. >=20 > (*) 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. >=20 > Cheers, > --=20 > Xin LI <delphij@delphij.net> https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D5104DE1-F889-422E-8017-25B6555396F0>