From owner-freebsd-hackers@freebsd.org Tue Sep 8 21:50:13 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 147CB9CD178 for ; Tue, 8 Sep 2015 21:50:13 +0000 (UTC) (envelope-from analysiser@gmail.com) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7D3C1D31 for ; Tue, 8 Sep 2015 21:50:12 +0000 (UTC) (envelope-from analysiser@gmail.com) Received: by pacfv12 with SMTP id fv12so138165365pac.2 for ; Tue, 08 Sep 2015 14:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=a2TYn14d4Z6f51wyjisCRGbaR8Am6X/ukDjqc2nM+BM=; b=patOAQJVPfdtopsrSwFfWRHGxG7AtYHfhC+w8b5n2jiroTZeP/ZQ/1pVevYlFpNW1v 2AKtYjiLDRfGKDLbU3ciPDlawVXMou60B4Nug8I8OhOEvw0IIkNHhTU80RFiU5FM/GtQ LpgYB2FjBp+TfgS6Kx7iD2FFGeh9QcKGgrrnL0bamCGYV266NBcI3MqMsvffa+rjCjbn Z18tdfHfkqrpuLBJBTkylYgnLx1qrYfgr+WbJVtuIilw+zvkeOCHtbX2PChtjlw7lgeM /W7sPmAybq0Vylmx5Z7YPmNuvFeGklPZS42jIwAWbF1Ls/+2/tH/HTL9Bno7a7yO2Ir4 UC3Q== X-Received: by 10.68.136.234 with SMTP id qd10mr63374198pbb.162.1441749012220; Tue, 08 Sep 2015 14:50:12 -0700 (PDT) Received: from a45e60cc77bb.amazon.com (54-240-196-185.amazon.com. [54.240.196.185]) by smtp.gmail.com with ESMTPSA id kr1sm4524630pbc.93.2015.09.08.14.50.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Sep 2015 14:50:11 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Passphraseless Disk Encryption Options? From: Analysiser In-Reply-To: <55EF4B65.8030905@delphij.net> Date: Tue, 8 Sep 2015 14:50:10 -0700 Cc: Igor Mozolevsky , Hackers freeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B7FEE2E-500E-49CF-AC5E-A2FA3054B152@gmail.com> <55EF4B65.8030905@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 21:50:13 -0000 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 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 https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die >=20