Date: Wed, 9 Sep 2015 11:23:01 +0100 From: Igor Mozolevsky <igor@hybrid-lab.co.uk> To: Fabian Keil <freebsd-listen@fabiankeil.de> Cc: Hackers freeBSD <freebsd-hackers@freebsd.org> Subject: Re: Passphraseless Disk Encryption Options? Message-ID: <CADWvR2jXzwewnWeZ_a30YSRMVtdGNjKUOBJaL2efyzU02hQo0Q@mail.gmail.com> In-Reply-To: <74e08b7d.41e63923@fabiankeil.de> 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> <D5104DE1-F889-422E-8017-25B6555396F0@gmail.com> <CADWvR2gkLR2VLsUw_MRyLBaFmftP0WuJqR3_n1SpT_WEDRuL6w@mail.gmail.com> <74385D4D-48C7-4B5B-BF94-B99806C667EE@gmail.com> <74e08b7d.41e63923@fabiankeil.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 September 2015 at 10:56, Fabian Keil <freebsd-listen@fabiankeil.de> wrote: > Analysiser <analysiser@gmail.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADWvR2jXzwewnWeZ_a30YSRMVtdGNjKUOBJaL2efyzU02hQo0Q>