| 1 |
On Sat, Nov 28, 2009 at 06:55:09PM -0500, Mansour Moufid wrote: |
| 2 |
> If I understand correctly, your goal is simply to ensure that the |
| 3 |
> kernel on the USB drive doesn't get tampered with? In that case, |
| 4 |
> perhaps a solution would be to keep hashes of it on that same drive, |
| 5 |
> and sign those with, say, a key on a smart card. (The FSFE offers one |
| 6 |
> along with instructions. [1]) You could verify everything at boot |
| 7 |
> time, and if there were discrepancies, custom boot scripts (kept |
| 8 |
> alongside the kernel, also hashed and signed) could prevent the |
| 9 |
> machine from booting, or something along those lines... |
| 10 |
|
| 11 |
That's a very interesting card, but for different reasons. Since it's |
| 12 |
not integrated into the hardware of the system, it too is at the mercy |
| 13 |
of whatever the subverted kernel wants it to see. Nothing short of a |
| 14 |
hardware-integrated measurement from POST through kernel & initrd is |
| 15 |
going to guarantee (for some definition thereof) that there hasn't been |
| 16 |
some malicious modification of the process. |
| 17 |
|
| 18 |
There is vanishingly little chance that an adversary with the knowledge |
| 19 |
and motive to modify your kernel will miss whatever little userspace |
| 20 |
games you may play with hashes, kexec, or the like. It may take them |
| 21 |
a second attempt or more time than they'd like, or they may just beat |
| 22 |
you with a $5 wrench until you tell them what they want. We're not |
| 23 |
talking about casual attackers at this point, they're at least as |
| 24 |
knowledgeable as you, and typically well-financed to boot. Even so, |
| 25 |
you're far more likely to simply have your equipment stolen (which |
| 26 |
simple FDE with a strong passphrase solves) than you are to really |
| 27 |
encounter this type of threat. |
Archives