What's a reasonably-secure, reasonably-portable way to allocate memory for private keys? [closed]

Question

I'm looking for a "best practice" for allocating storage for 256-bit private keys. I'm thinking at minimum, keys shouldn't be paged to disk, and there are maybe some other attack vectors to worry about (a la Hearbleed). The solution must be portable to Linux and BSD.

Some thing I have looked at:

• TRESOR (not BSD-portable)
• Akamai's "secure heap"
• David Shaw's secmalloc
• Use mlock to forbid paging
• Just use malloc and don't worry. A cursory reading suggests this may be what LibreSSL does.

Any recommendations?

Answer 1

Unless you have special requirements, just using malloc is the sane approach. It has the advantage that valgrind and similar can catch usage errors, which are one of the main ways the type of vulnerabilities you may be worried about come into existence. As the OpenSSL fiasco showed us, trying to do something fancy and botching it is a major risk.

If you have more demanding requirements, it really depends a lot on your usage case. I'm going to assume your keys are transient, or else avoiding storing them on disk doesn't make a lot of sense. Here are my recommended mitigations for particular risks:

• Swapping to disk: If your system requires security against physical attacks, you should not have swap at all. Individually trying to protect specific data with mlock is something of a joke. Just turn swap off and install enough memory and it's a non-issue. mlock should be considered a realtime scheduling feature, not a security feature.

• Heartbleed-like issues, moderate defense: Allocating your memory via mmap with guard pages on both sides: first mmap 2 pages more than you need, all with PROT_NONE, then use mprotect to make all but the first and last page PROT_READ|PROT_WRITE. Free it with munmap as soon as you're done with it.

• Heartbleed-like issues, strong defense: Fork a child process to do all the cryptography.