1 |
On Sat, Nov 28, 2009 at 11:44 PM, <schism@×××××××××.org> wrote: |
2 |
> That's a very interesting card, but for different reasons. Since it's |
3 |
> not integrated into the hardware of the system, it too is at the mercy |
4 |
> of whatever the subverted kernel wants it to see. Nothing short of a |
5 |
> hardware-integrated measurement from POST through kernel & initrd is |
6 |
> going to guarantee (for some definition thereof) that there hasn't been |
7 |
> some malicious modification of the process. |
8 |
|
9 |
Yes, that's true. I just saw the flaw in this scheme. (An attacker |
10 |
would simply replace gpg on the USB drive with one that has the |
11 |
attacker's keys hard-coded, made to completely ignore the smart card, |
12 |
and re-hash/sign everything...) |
13 |
|
14 |
Google's new OS claims to prevent exactly this sort of attack by using |
15 |
"custom" firmware to conduct regular checks: |
16 |
http://www.youtube.com/watch?v=A9WVmNfgjtQ#t=2m24s |
17 |
Apparently, the key used to check the kernel for modification is kept |
18 |
in "read-only" firmware, along with "verifier logic" (hash test |
19 |
cases?). If they're successful, perhaps Gentoo Hardened could adopt |
20 |
these methods. |
21 |
|
22 |
Digressing... Given that we cannot ensure the integrity of our kernel, |
23 |
presumably the attacker cannot ensure theirs either. Short of |
24 |
preventing tampering, the next best thing would be to detect it, and |
25 |
in some cases knowing that data was tampered with is potentially more |
26 |
valuable than the data itself. For example, one could "bait" an "evil |
27 |
maid" attack, and later study the modified kernel, to phone home with |
28 |
a dupe payload, etc... Now that would make a good movie. ; ) |
29 |
|
30 |
-- |
31 |
Mansour Moufid |