From owner-freebsd-hackers@freebsd.org Wed Sep 9 10:23:41 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 D93BE9CDFB2 for ; Wed, 9 Sep 2015 10:23:41 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 A02451F03 for ; Wed, 9 Sep 2015 10:23:41 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by igxx6 with SMTP id x6so10542392igx.1 for ; Wed, 09 Sep 2015 03:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iTan7PT4z6I2O0uxPuBU6gC7yf5Lv3QO4kiiC5yGJkI=; b=AbXtbjzgQZP1iuSSsGzKKWO1HTEpGV9BF0hsk0v8zDPkWwLIZN2QAMWrGUqAfieVKV O+cBMRv9XzmfQ9FQWjO/gAPHoXcnSCUiWA9Zhc9pBbjOhZcZa6OQi2gCC7MwdojDgaua HT3z8ur2CeZAGNyOeD7QZvNygINCsPm90TOXtcZmcT93BnAF4GTabd8ZiQ27pfyzXZHd 2vQ9AsfqtdQzt1kp3xwlOAkpTI4fXNAdBh4O4er/TBPGlC7cmwub/z88/JrNOtjwa1XM wMOKZXluWHQgGxZ4sRDcGEXTRBDL6P1a6O0zadEhq61g6t35dgtkpEUOE7nld7dB7/P/ kgcQ== X-Received: by 10.50.127.177 with SMTP id nh17mr40607071igb.40.1441794220961; Wed, 09 Sep 2015 03:23:40 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.79.92.198 with HTTP; Wed, 9 Sep 2015 03:23:01 -0700 (PDT) In-Reply-To: <74e08b7d.41e63923@fabiankeil.de> References: <8B7FEE2E-500E-49CF-AC5E-A2FA3054B152@gmail.com> <55EF4B65.8030905@delphij.net> <74385D4D-48C7-4B5B-BF94-B99806C667EE@gmail.com> <74e08b7d.41e63923@fabiankeil.de> From: Igor Mozolevsky Date: Wed, 9 Sep 2015 11:23:01 +0100 X-Google-Sender-Auth: ZADqV0G7DqN06oXprW50w6oMQc0 Message-ID: Subject: Re: Passphraseless Disk Encryption Options? To: Fabian Keil Cc: Hackers freeBSD Content-Type: text/plain; charset=UTF-8 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: Wed, 09 Sep 2015 10:23:41 -0000 On 9 September 2015 at 10:56, Fabian Keil wrote: > Analysiser wrote: > > > I=E2=80=99m trying to protect my startup disk=E2=80=99s data from being= tampered with > > by someone who has physically access to the disk. He might put it on so= me > > other machine, add some malicious code or check the logs stored in /var= , > > and then put it back my machine, when the machine is stayed in some > public > > untrusted environment. When I regain the machine from a public untruste= d > > environment and boot the disk, some malicious code might running and tr= y > > to contaminate my own network or other machines, or monitor my activiti= es > > with the machine. > > You can boot the system using an encrypted root pool by putting a > geli keyfile and essential parts of the kernel on an unencrypted > boot pool that is destroyed and overwritten once the system has > booted. > > I do that with ElectroBSD but it works on vanilla FreeBSD as > well. It's not perfect, but depending on your threat model it > may be good enough: > https://www.fabiankeil.de/gehacktes/electrobsd/#fde > https://www.fabiankeil.de/gehacktes/cloudiatr/ Can't this be simply undermined by the adversary yanking the power cord resulting in the disk being but a source of entropy? There is, of course, a number of scenarios where that would be a perfectly desirable outcome, but based on what was said earlier, I doubt this is one of them. I am still unclear what the OP is trying to achieve: first the requirement was to protect the data on disk from being taken by third party, then the OP said they just wanted to prevent tampering because they'd be bringing the box back into their network=E2=80=A6 Then, there's the whole headless issue: it was said that there's only the NIC and the power cord. If that is true, the only way to tamper with data is to gain physical access to the device. The OP thinks that TPM+trusted gptBoot waves some magic wand and makes the system secure from tampering; I seriously doubt that- if one can replace the disk, why can't their replace TPM, clear BIOS with a jumper, or replace the board all together? The point I'm driving at is that it seems that the threat model and attack vectors are not properly analysed for that particular environment, and there's wishful thinking about a magic genie-in-a-box solution. The final point is: you cannot have a device that guarantees confidentiality, availability, and integrity of data in the circumstances described- you have to sacrifice at least one of the three. If you are storing the decryption key alongside the encrypted data, no sane person should ever think that data is actually encrypted. --=20 Igor M.