RWC 2017 - Erasing Secrets from RAM

One of my favourite talks from the Real World Crypto 2017 conference was given by Laurent Simon, on Erasing Secrets from RAM.

In short, it was found that in practice, many non-malicious programs handling keys and other sensitive data do not erase the RAM correctly. This would allow an attacker (that has access to all of a system's volatile memory and CPU state) access to any unerased sensitive data.

It was thought that compiler optimisation played a part in the lack of erasion. Take the code below:

void sensitive_function(...) {

   u8 sensitive_buffer[KEY_MAX] = "\0";
   ...
   zeromem(sensitive_buffer, KEY_MAX);

}

The compiler may choose to remove the zeromem line, as the sensitive_buffer is going out of scope anyway. This would leave sensitive data on the RAM, unbeknownst to the programmer.

So, the paper presents a tool that allows developers to mark sensitive variables in their code, and then see (post-compilation) any potential leakage of sensitive data.

They call this tool Secretgrind, based off the popular Valgrind.

Anyway, as it turns out, the compiler optimisation problem mentioned above wasn't actually a problem in practice - they didn't once encounter this problem in all their testing. Instead, the majority of sensitive leaks were down to developers' mistakes; they had forgotten to erase sensitive variables on both the stack and the heap.

There were a few issues with IO API's caching optimisations, though - such as when you read a line from a PEM file using mmap, it often loads the whole file into memory to save you the time. However, this is not immediately obvious, and when you go to delete the line from RAM, the rest of the file is still in memory!

Laurent concluded the talks saying Secretgrind was still in development, and although referring to it as a 'hack' (due to it's fragility), wishes for it to be used to "help you guys check your code".