Hacker News Reader

Comment by java-man | Hacker News Reader

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/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.

View on HN

> 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.

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.

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

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.

How can you be sure data doesn't leave the cache if the kernel interrupts - or worse, the BIOS performs an SMM interrupt?

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.

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.

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

Can you guarantee that the storage driver doesn't DMA your key material to RAM during initial boot?

Reply on news.ycombinator.com