Date: Tue, 8 Sep 2015 16:39:55 -0400 From: Peter Beckman <beckman@angryox.com> To: "Li, Xiao" <xaol@amazon.com> Cc: Igor Mozolevsky <igor@hybrid-lab.co.uk>, Analysiser <analysiser@gmail.com>, Hackers freeBSD <freebsd-hackers@freebsd.org> Subject: Re: Passphraseless Disk Encryption Options? Message-ID: <alpine.BSF.2.00.1509081628520.11719@nog.angryox.com> In-Reply-To: <D2147620.1A4A%xaol@amazon.com> References: <8B7FEE2E-500E-49CF-AC5E-A2FA3054B152@gmail.com> <CADWvR2iv7xz02Fw9b=159%2BSMuphQGRKZsfyy9DDeqGMxn=p1BA@mail.gmail.com> <D214715D.1A32%xaol@amazon.com> <D2147620.1A4A%xaol@amazon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <owner-freebsd-hackers@freebsd.org>
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 <freebsd-hackers@mailman.ysv.freebsd.org>;
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 <freebsd-hackers@freebsd.org>; 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>
<CADWvR2iv7xz02Fw9b=159+SMuphQGRKZsfyy9DDeqGMxn=p1BA@mail.gmail.com>
<D214715D.1A32%xaol@amazon.com>
<CADWvR2iVubsBQjnvQ8mDGGS7ujsR8wPQ2RAxn=kvFkmVGQkXiQ@mail.gmail.com>
<D2147761.1A53%xaol@amazon.com>
To: "Li, Xiao" <xaol@amazon.com>, Igor Mozolevsky <igor@hybrid-lab.co.uk>
Cc: Hackers freeBSD <freebsd-hackers@freebsd.org>,
Analysiser <analysiser@gmail.com>
From: Xin Li <delphij@delphij.net>
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: <D2147761.1A53%xaol@amazon.com>
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
<freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>,
<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>;
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hackers-request@freebsd.org?subject=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 <delphij@delphij.net> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1509081628520.11719>