From owner-freebsd-hackers@freebsd.org Tue Sep 8 20:50:48 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 62427A00FA1 for ; Tue, 8 Sep 2015 20:50:48 +0000 (UTC) (envelope-from beckman@angryox.com) Received: from nog.angryox.com (nog.angryox.com [70.164.19.87]) by mx1.freebsd.org (Postfix) with ESMTP id 1760A142B for ; Tue, 8 Sep 2015 20:50:47 +0000 (UTC) (envelope-from beckman@angryox.com) Received: from nog.angryox.com (localhost [127.0.0.1]) by nog.angryox.com (Postfix) with ESMTP id 3F9052C48DF; Tue, 8 Sep 2015 20:39:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=angryox.com; h=date:from :to:cc:subject:in-reply-to:message-id:references:mime-version :content-type; s=powerfulgood; bh=rDqvQPJi5ckePy3dYD0Yrg64KhM=; b= QQtJgUZLRIbmX4CuA7Dv03RHMr86OmxO4Dt2Y8fVbkAjpoDMTw5TcPxySzaTaueO eYIW4JoTtjKoc62P3zHh53vXF0w/4SeWeI5D7dB7jTEoUgtTu8+Xwq3+gCoxVp0m l5PcHy0qac3OXp2PjhWDaAtnWJmSfgPxQ/58oFYFFAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=angryox.com; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type; q=dns; s=powerfulgood; b=vWnTJUZY6eA9Ah/P95JqbZ/+ GgaD1UkccnA/zGY6A7hXPL3MjLu5f7+2wg8iXhWx6rRXRxtrNLwJtnaseROe39ZT 2Rczn4lV/iqfGrcLCxZTpx8IjtlZ0vsggJB7Cg0VKpprnw6ODIKaUX/0AMLcYU9w PGnDJry5VWkUlEYO50o= Received: by nog.angryox.com (Postfix, from userid 1001) id EDF3A2C48DC; Tue, 8 Sep 2015 20:39:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nog.angryox.com (Postfix) with ESMTP id EBA062C48D4; Tue, 8 Sep 2015 16:39:55 -0400 (EDT) Date: Tue, 8 Sep 2015 16:39:55 -0400 From: Peter Beckman To: "Li, Xiao" cc: Igor Mozolevsky , Analysiser , Hackers freeBSD Subject: Re: Passphraseless Disk Encryption Options? In-Reply-To: Message-ID: References: <8B7FEE2E-500E-49CF-AC5E-A2FA3054B152@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 20:50:48 -0000 On Tue, 8 Sep 2015, Li, Xiao via freebsd-hackers wrote: > To clarify more, I=E2=80=99m trying to protect a headless device that h= as FreeBSD > installed on it. There is no usb/video input, only NIC and power are > exposed. And I=E2=80=99m trying to protect its bootable drive. Seems to me that you would need one of the following: a) An unencrypted boot system that started up networking and an SSH daemon. Then you connect via SSH, "enter the encryption pass phra= se" and then the system shuts down the bootstrapped system and boots = the real OS. b) A USB key, or some other hardware, installed in the physical syst= em that the booting OS can access to magically auto-decrypt the OS a= s it boots. If they steal the drive but not the hardware, the drive is safe. If they steal it all, you're hosed. c) A network device which the OS knows to pass a public-key signed request to in order to receive back a private-key signed response= that, when decrypted, contains the decryption passphrase. An HSM might work here What most people are saying is that FileVault requires you to enter a password to decrypt your account. You don't want to/can't do this. And = if you store the decryption key on the server, as others have said, you ha= ve no security. Like leaving your house key under the front door mat. Maybe what you need is instead of disk-level encryption is account-leve= l encryption if you are more worried about the security of the data store= d in non-root accounts. Beckman -------------------------------------------------------------------------= -- Peter Beckman Internet G= uy beckman@angryox.com http://www.angryox.co= m/ -------------------------------------------------------------------------= -- From owner-freebsd-hackers@freebsd.org Tue Sep 8 20:56:16 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 6F2FC9CC421 for ; Tue, 8 Sep 2015 20:56:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 53EAA1B1A for ; Tue, 8 Sep 2015 20:56:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 9A063F6B4; Tue, 8 Sep 2015 13:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1441745769; x=1441760169; bh=6SUQcE2KDgO9XMcbznTcXhoSt+/XnzabbK5FkIS9Qm4=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=EV6h+mbo2upiMBR2kWVOU8kcblnWmG1YcBsDON0JrvG+WJrCjFPJe8lkL0CuMUaUy c5ARcghqGvS8p7YjAT6o81GYW2WQ/Fb2eg+fYLMvA7NYXAeWIdveI92pWIjSWKDBQv llbuRuThp0uzgQjILK9s4NhOExbnlQZ4Xl/eh4rs= Reply-To: d@delphij.net Subject: Re: Passphraseless Disk Encryption Options? References: <8B7FEE2E-500E-49CF-AC5E-A2FA3054B152@gmail.com> To: "Li, Xiao" , Igor Mozolevsky Cc: Hackers freeBSD , Analysiser From: Xin Li X-Enigmail-Draft-Status: N1110 Organization: The FreeBSD Project Message-ID: <55EF4B65.8030905@delphij.net> Date: Tue, 8 Sep 2015 13:56:05 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ss8fIUN2t1HGMDxiBCvajjrHdblIL9nmL" 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 20:56:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ss8fIUN2t1HGMDxiBCvajjrHdblIL9nmL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 eithe= r > unachievable or haven=B9t been done before. I mentioned Apple=B9s metho= d 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 di= sk on > login; I=B9m 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, --=20 Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die --ss8fIUN2t1HGMDxiBCvajjrHdblIL9nmL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.7 (FreeBSD) iQIcBAEBCgAGBQJV70toAAoJEJW2GBstM+nsJNgP/2oskJgFQ9G5kx4yCPdEAPiq NfRjuZkUfa+s1lpgMaZQepIaw1rOWyg4NDkADRH2qpzzmKsgOWPGl9GvTiD9OTYY mgUT6rK4AjjkixCDjiNzP5fOCcxw/3pKrah9apEuKEpWJUn/J/r7StTrSAQVXhmx Z9gAUd4bHNZMVsYJO2+3eK7M/HsTDRX8PXMh7u2xu54HR8yj8xONmOT+fl3spkmG JNhWfMgf3heBQu1+JxMShdN+aAe4CvWvxmnIZjXroiemDCiavIzcHnI+VsLwQw5d fZRTjvVwylPoEJilufpxBAypU5nErhN7ddOk+fLGC+kNY32UGntvLWgsL0zKos1R n80Z2XRgPEPXkO1RjDPHo3Me+dIRh1WfPKdsYkQGECnLxKkmU5iS9I8oV6xtwmx/ gEh6PkNR8Ap/iXFFqLAbdHKNi3eXZUIOrfzK4DK8QodCmTo5eiUC7u0I16Cvl7HV 4/4YwPcj0Pwjd/A10FuHypgLNDgb64ZS7P7FDqXi9xEhIO39iUbyZmQHgZAjVxEA eOyuK68bqrndZOnXxltIVLyDu1uPyufNaUmEweDbms+gfRoo+ftzLLxsQkZLemdg Bblsf5ClDJomO1VbRqhK2Qch1keD9MtHkCG63+iSQje9dYiPlmb2bLUj628XZ3fj ln9NATtpabuMX102mCUT =E2W3 -----END PGP SIGNATURE----- --ss8fIUN2t1HGMDxiBCvajjrHdblIL9nmL--