5 ms·

This attack is relevant for password storage apps. As an additional countermeasure, I encrypt editor field and text area buffers that might contain sensitive i

This attack is relevant for password storage apps. As an additional countermeasure, I encrypt editor field and text area buffers that might contain sensitive information, see for example: https://github.com/andy-goryachev/PasswordSafe/blob/master/src/goryachev/crypto/MemCrypt.java https://github.com/andy-goryachev/PasswordSafe/blob/master/s... A symmetric key used to encrypt/decrypt RAM-based data is generated on the fly. There is a brief period in time when data is present in the clear in memory - when it's used - but nothing can be done about it, short of moving the code to some kind of protected processor.

teacup50 12y ago
> There is a brief period in time when data is present in the clear in memory - when it's used - but nothing can be done about it, short of moving the code to some kind of protected processor. `mlock()` can be used to prevent the memory from being paged out, but the DMA issue itself isn't something that can be (or should be) solved in userspace; if someone can do DMA reads/writes, rewriting any code or data, there's nothing an application can do.
- java-man 12y ago
  I agree, there should exists explicit OS mechanisms to prevent leakage, be it via DMA, paging, or any other way. In the absence of such mechanisms, especially when mlock() is unavailable (if running a Java app, for example), the app designer can use tricks like one described above to increase the level of difficulty for an attacker. It is not a solution, but an additional countermeasure.
  - potatosareok 12y ago
    You can disable paging if you really care about that but setting swapiness to 0. Or use something like https://github.com/LucidWorks/mlockall-agent https://github.com/LucidWorks/mlockall-agent
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 ago
  How can you be sure data doesn't leave the cache if the kernel interrupts - or worse, the BIOS performs an SMM interrupt?
  - sweis 12y ago
    You 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 ago
  There 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 ago
    Yep, 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 ago
  Can you guarantee that the storage driver doesn't DMA your key material to RAM during initial boot?

teacup50 12y ago

> There is a brief period in time when data is present in the clear in memory - when it's used - but nothing can be done about it, short of moving the code to some kind of protected processor. `mlock()` can be used to prevent the memory from being paged out, but the DMA issue itself isn't something that can be (or should be) solved in userspace; if someone can do DMA reads/writes, rewriting any code or data, there's nothing an application can do.

java-man 12y ago
I agree, there should exists explicit OS mechanisms to prevent leakage, be it via DMA, paging, or any other way. In the absence of such mechanisms, especially when mlock() is unavailable (if running a Java app, for example), the app designer can use tricks like one described above to increase the level of difficulty for an attacker. It is not a solution, but an additional countermeasure.
- potatosareok 12y ago
  You can disable paging if you really care about that but setting swapiness to 0. Or use something like https://github.com/LucidWorks/mlockall-agent https://github.com/LucidWorks/mlockall-agent

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 ago
How can you be sure data doesn't leave the cache if the kernel interrupts - or worse, the BIOS performs an SMM interrupt?
- sweis 12y ago
  You 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 ago
There 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 ago
  Yep, 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 ago
Can you guarantee that the storage driver doesn't DMA your key material to RAM during initial boot?