Private keys in RAM

[mmeijeri]

After the heartbleed scare I've been thinking if perhaps we shouldn't make an effort to store private keys more securely. This isn't a new issue of course, and there are lots of existing techniques and best practices I'm only dimly aware of, including things like PKCS #11 and HSMs. I know work is also being done on Bitcoin-specific hardware solutions like Trezor.

Maybe we all need to move to hardware-based solutions in the future, but maybe there is also room for software-only solutions. Right now most people don't use specialised crypto hardware, and I was wondering if it would help if signing operations were at least located in a separate process with an independent address space. There is a library called SoftHSM which is a software-only implementation of PKCS #11. I think it's supposed to be linked directly to the application, but maybe it can be used as a starting point.

So, what do you think? Would this be a useful near-term improvement, or an undesirable half solution that discourages people from using dedicated hardware, if we believe that's the real solution?

[mmeijeri]

Well, that too of course, but 2/3 of the web was vulnerable to this one, whether they updated regularly or not. Layered defence is good.

[Sukrim]

The real solution is simply to not get malware and update often, IMO.

If you did NOT update to OpenSSL 1.0.1 (thus updating rarely/late) you were not hit by heartbleed...
You might be exposed to other (less severe) security issues that way though.

[wumpus]

For operating systems that support a secure execution environment it'd make sense to move generating/encrypting/decrypting private keys and signing there. I'm not sure how useable this is in practice at this point. This could use TPM or HSMs if available.

And AFAIK some of the Android wallets use the OS-specific secure key storage for wallet keys.

Moving those operations to a separate, isolated process would already be a start. There are certainly baby steps to be made.

[Sukrim]

Private keys anyways should be in RAM only for a few fractions of a second: read them from HDD, decrypt them, sign whatever you need to sign (message, transaction...), zero them out again and done.

[wumpus]

Private keys anyways should be in RAM only for a few fractions of a second: read them from HDD, decrypt them, sign whatever you need to sign (message, transaction...), zero them out again and done.

With the Bitcoin Core wallet this is already the case. The encrypted keys are stored in RAM, but they are only decrypted when necessary and zeroed afterwards (given that you use wallet encryption, of course). The memory used for storing keys is also locked, to avoid it from being swapped to disk.

[mmeijeri]

Interesting OpenSSL patch by Akamai related to this, via @csoandy on Twitter:

http://marc.info/?l=openssl-users&m=139723710923076&w=2

[oakpacific]

Would it be easier to just make sure your signed tx always get on the chain first?

[chen18127]

make it faster is the most improtant thing

[noviapriani]

It's entirely possible that either a program with necessary privilege to read the memory location holding the key, or hardware utilizing DMA, can grab a private key from RAM.

[mmeijeri]

Interesting OpenSSL patch by Akamai related to this, via @csoandy on Twitter:

http://marc.info/?l=openssl-users&m=139723710923076&w=2

Turns out this patch doesn't work at all, several experts panned it.

[jd_grinder]

my 2c. if possible use a physical storage device like a SAM module or in case of servers an HSM. storing in ram makes them vulnerable. Keyloggers and ramscrapers are just the tip of the iceberg.