1 |
On Thu, May 25, 2017 at 7:04 AM, Kai Krakow <hurikhan77@×××××.com> wrote: |
2 |
> Am Thu, 25 May 2017 08:34:10 +0200 |
3 |
> schrieb "J. Roeleveld" <joost@××××××××.org>: |
4 |
> |
5 |
>> It is possible. I have it set up like that on my laptop. |
6 |
>> Apart from a small /boot partition. The whole drive is encrypted. |
7 |
>> Decryption keys are stored encrypted in the initramfs, which is |
8 |
>> embedded in the kernel. |
9 |
> |
10 |
> And the kernel is on /boot which is unencrypted, so are your encryption |
11 |
> keys. This is not much better, I guess... |
12 |
> |
13 |
|
14 |
Agree. There are only a few ways to do persistent encryption in a secure way: |
15 |
1. Require entry of a key during boot, protected by lots of rounds to |
16 |
deter brute force. |
17 |
2. Store the key on some kind of hardware token that the user keeps |
18 |
on their person. |
19 |
3. Store the key in a TPM, protected either by: |
20 |
a. entry of a PIN/password of some sort with protections on attempt |
21 |
frequency/total |
22 |
b. verification of the boot path (which should be possible with |
23 |
existing software on linux, but I'm not aware of any distro that |
24 |
actually implements this) |
25 |
|
26 |
If you don't have hibernation then you can just generate a random key |
27 |
on boot, and that is very secure, but your swap is unrecoverable after |
28 |
power-off. |
29 |
|
30 |
Of the options above 3b is the only one that really lets you do this |
31 |
with the same level of convenience. This is how most full-drive |
32 |
encryption solutions work in the Windows world. Chromebooks use a |
33 |
variation on 3a I believe using your google account password as one |
34 |
component of the key and putting it through the TPM to have a hardware |
35 |
component and to throttle attempts. |
36 |
|
37 |
-- |
38 |
Rich |