On Thu, Feb 19, 2009 at 12:03 AM, Isaac Dupree <m...@isaac.cedarswampstudios.org> wrote: >> I know. But there's no way to guard against this attack, so there's no >> sense fretting over it for now. > well, it's relatively straightforward for an attacker who knows what they're > doing, so perhaps you should assume that *privacy* is at least partly > compromised. I think there are ways to guard against this attack. There's 'freeze CPU cache' method and I'm also thinking about using GPU to perform decryption - this way decryption keys won't be in the main memory.
For now, I'm just planning to glue memory chips to the mainboard using epoxy resin. It'll make life much harder for the attacker. > but the most that attack can achieve is observing? Can that attack make it so > that, when the system starts running again, it will be in a compromised state? Attackers can steal decryption keys, connect hard drives from my computer to their computer and then copy everything. > - they can steal all crypto identity keys and try to run a completely > different > computer with different software there, if not for TPM > - I don't know how the magic of TPM knowing everything about the state of your > computer works, maybe they can modify what's in memory and put it back and > confuse things? No. TPM is a passive chip. It might be possible to use TPM as a hardware decryptor, but it's too slow to handle full-disk encryption. > Also why does GRUB need to do any explicit interaction with TPM? (I'm > ignorant and unimportant here, but maybe it will edify people, to have this > conversation.) BIOS is only able to attest that the first stage of GRUB (512-byte MBR) is not compromized. First stage then has to check the second stage and so on. So unmodified GRUB will happily load a compromised second stage even if the first stage is attested to be not modified. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
