5 ms·
You don't need a "protected processor". At PrivateCore, we kept all key material pinned in the L3 cache and ensured it was never evicted to main memory. Frozen
by sweis 12y ago
You don't need a "protected processor". At PrivateCore, we kept all key material pinned in the L3 cache and ensured it was never evicted to main memory.
Frozen Cache did something similar with No-Fill Mode.
Tresor used CPU debug registers.
- 0x0 12y agoHow can you be sure data doesn't leave the cache if the kernel interrupts - or worse, the BIOS performs an SMM interrupt?
- sweis 12y agoYou modify the kernel. As for SMIs, you know where SMRAM is located in memory and the cache geometry, so can ensure that there are cache ways available which SMIs won't evict. Cache evictions can also be monitored by CPU performance counters, so you can detect any that do occur.
- java-man 12y agoThere are cases when not only key material but also some data need to be protected. For example, in a context of password storage app, the passwords and associated text should not remain in the clear in memory, and possibly even the character buffer of entry fields such as JPasswordField. This is the reason for the MemCrypt code mentioned earlier.
- sweis 12y agoYep, we ran the entire Linux stack pinned in the L3 cache, so no data or code hit main memory which was not encrypted. Ironically, we could test this by disabling VT-d and using a DMA device to read encrypted main memory. Here's an old demo video: https://www.youtube.com/watch?v=chvJpEmXvDk https://www.youtube.com/watch?v=chvJpEmXvDk
- mjg59 12y agoCan you guarantee that the storage driver doesn't DMA your key material to RAM during initial boot?