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>
index | next in thread | previous in thread | raw e-mail
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 Im working on. Thanks again! I still have some more detailed questions Im seeking for an answer related to the full startup disk encryption: Background is Im 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@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@delphij.net> https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die >help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D5104DE1-F889-422E-8017-25B6555396F0>