Pre-boot authentication / geli-aware bootcode

[Robert Simmons]

On Fri, Jun 15, 2012 at 5:24 PM, Simon L. B. Nielsen <simon at freebsd.org> wrote:
> On Fri, Jun 15, 2012 at 7:11 PM, Matt Piechota <piechota at argolis.org> wrote:
>> On 06/15/2012 01:40 PM, Simon L. B. Nielsen wrote:
>>>
>>> On Jun 11, 2012 1:22 AM, "Robert Simmons"<rsimmons0 at gmail.com>  wrote:
>>>>
>>>> Would it be possible to make FreeBSD's bootcode aware of geli encrypted
>>>
>>> volumes?
>>>>
>>>> I would like to enter the password and begin decryption so that the
>>>> kernel and /boot are inside the encrypted volume.  Ideally the only
>>>> unencrypted area of the disk would be the gpt protected mbr and the
>>>> bootcode.
>>>>
>>>> I know that Truecrypt is able to do something like this with its
>>>> truecrypt boot loader, is something like this possible with FreeBSD
>>>> without using Truecrypt?
>>>
>>> I just booted off a USB flash key. Then your entire drive can be
>>> encrypted.
>>>
>>
>> While true, the point (to me at least) is that with your kernel (and in
>> Linux's case, initrd) in the clear it's possible for someone to bury a
>> trojan of some sort in there waiting for you to boot up and start doing
>> something nefarious (open backdoors, keylogging, etc.). I suppose you could
>> check hashes of the kernel stuff and whatnot on booting to see if they
>> haven't been modified, but that's not fool-proof either. That's obviously
>> some pretty cloak and dagger stuff, but the company I work for requires full
>> disk encryption. I've never actually asked if /boot counts, somewhat fearing
>> the answer and resulting hassle from the largely paper-pushing security
>> types.
>
> If you are worried about somebody compromising the system with direct
> access, you can't fix that if you are booting of it. Truecrypt does
> not prevent somebody compromising the truecrypt loader from gaining
> access to your system after you have supplied the compromised loader
> with your password.
>
> 10 seconds of google searching:
> http://theinvisiblethings.blogspot.ie/2009/10/evil-maid-goes-after-truecrypt.html
>
>> The USB key method isn't bad, but it realistically only adds obfuscation
>> unless you keep your laptop and the key separate. Knowing myself, I'd forget
>> one or the other fairly often. :)
>
> I got a USB key which was ~1.2x2cm (from memory) so I just kept it in
> my keychain, and it was only attached to a computer when the system
> was booting (well, mostly) and when I had to upgrade kernel so I would
> say it added more than obfuscation, but nothing is perfect. As I could
> not get in at home without said keychain forgetting it wasn't really
> much of a problem (or rather, more of a problem wrt. getting in than
> wrt. booting laptop :-) ).
>
> It also provide a second factor'ish authentcation for the laptop as I
> used GELI keyfiles on the USB key as part of the encryption key.
>
> Not saying it's perfect, but worked well for me (past tense as I don't
> use a FreeBSD laptop anymore).
>
> Frankly I think there is a much simpler solution to this problem... if
> you ever not loose access long enough to the laptop that somebody
> could have done something funny, wipe drive and reinstall. It all
> depends on your level of paranoia / requirements for security.
>
> PS. just because you are paranoid, doesn't mean they are not out to get you :-).

That article is a fascinating read.  I like the idea of the Disk
Hasher stick solution.  Perhaps that idea could be made more secure if
the hash stick itself was encrypted:
http://www.imation.com/en-US/Mobile-Security/Mobile-Security-Products/Secure-Data/Imation-Flash-Drives-Powered-by-IronKey/Imation-Enterprise-S200-Flash-Drive-Powered-by-IronKey/

Along those lines, I wonder if a
GPF Crypto Stick could be used to authenticate the geli decryption
process rather than your insecure USB stick?
http://www.privacyfoundation.de/crypto_stick/crypto_stick_english/