Secure memory storage of private keys

[clintfred]

ironoxide should, ideally, provide better in memory security measures for private keys and other sensitive data types.

Starting points for research:

• https://users.rust-lang.org/t/handling-sensitive-data-in-memory/14388
• https://github.com/quininer/memsec
• https://github.com/quininer/seckey
• https://github.com/stouset/secrets
• https://github.com/myfreeweb/secstr

[BobWall23]

These methods use the Linux kernel functions mlock/munlock and mprotect to safeguard key storage memory from within the process. However, this doesn't protect against RowHammer-type attacks. A recent patch to OpenSSL adds protection for this - they generate 16kbytes of random data on process startup, derive a symmetric key from that (probably just a sha256 hash), and use that key to encrypt the secret before it is stored in memory. The key is re-derived each time the secret is needed.

The error rate of RowHammer is sufficiently high that recovering the full 16kbytes of random data (referred to as a pre-key) is very unlikely.

[zmre]

@BobWall23 I recommend we spin out a separate issue for rowhammer protection. I dug into this today and here are some conclusions:

• If you want to prevent anyone from accessing memory except in specific contexts, then you can use mprotect. For our use cases, this doesn't make sense as we do need the private key to be passed to various functions.
• mlock/munlock will pin blocks of memory so they don't go to swap, which we want for our purposes.
• madvise is used in specific operating systems to prevent the protected memory for showing up in core dumps.

I reviewed the options that Clint referenced and read the thread and then poked around man pages. Basically I think secstr is the best starting point. memsec shows how to make this work in windows though. I'm going to mix these together and make them work on arbitrary structs. These libraries have a bunch of other functionality and we only really need a few lines out of them, slightly adapted, so I don't think it makes sense to pull in the dependencies. We have existing solutions for zeroing memory and constant time equality checks, for example.

The hardest thing with this is confirming that it's working as expected. That is, how can we prove that the private keys aren't being written to swap or pushed to disk in a core dump? None of the referenced libraries have tests for this. I think we have to take it on faith. I'm open to suggestions though.