Re: [gentoo-user] {OT} Allow work from home?

[Rich Freeman]

On Sat, Feb 20, 2016 at 5:55 AM, lee <lee@××××××××.de> wrote:
> Rich Freeman <rich0@g.o> writes:
>
>> develop.  (Before somebody points out LUKS, be aware that Bitlocker
>> lets you do full-disk encyption that is secure without having to
>> actually type a decryption key at any point.  Remove the hard drive or
>> boot from a CD, and the disks are unreadable - you can only read them
>> if you boot off them on the original PC.)
>
> And how do you read the disks when this original machine is broken?
>

Well, in general you still want to have backups.  I believe many of
these sorts of solutions do let you escrow a key elsewhere.

> It doesn't seem very secure, either.  When your laptop that uses
> Bitlocker gets into the wrong hands, whoever has it can read the disks.

Kinda-sorta.  They can boot the machine, but now they're stuck at a
login prompt.  In order to extract data from the computer they need to
defeat password-throttling, the kernel, and so on.  They have to go
through the front-door.  The main protection is against offline
password cracking/etc.

I'd think the biggest vulnerability of something like Bitlocker would
be against direct memory attacks.  I assume that the session keys are
stored in RAM - I can't imagine that all drive reads/writes are
streamed through the TPM.  So, extracting the keys from RAM after
bootup would be the biggest risk.  If the user data is encrypted using
user-entered passwords you're still going to have all the security of
a LUKS-like solution but with the advantage of rate limiting of
attacks.

In ChromeOS they took a different approach.  They use UEFI secure boot
to protect the OS, and then encrypt user data using a key derived from
the user's password and the TPM, using the TPM to rate-limit attacks.
In this design only the user's private data is protected from reading,
but to crack it they still have to boot the system normally and go
through the front door.  There is no way to offline-crack the user's
weak hand-entered password.  They either need to send that password
through the TPM (I'm not sure if they can do that offline or not -
probably they can, but it is still rate-limited by the TPM itself), or
they need to directly brute-force the AES key which is of course
impractical.

The problem with LUKS is that it doesn't do anything to rate-limit
attacks since there is no hardware component to it.  Of course it is
designed to make attacks more expensive using multiple rounds/etc to
make up for the weakness of memorized passwords.

-- 
Rich