Node: crypto.alloc() for encryption key memory management

Created on 21 Feb 2018  路  4Comments  路  Source: nodejs/node

@indutny and everyone working on the crypto module:

At present, using a Buffer for a crypto key exposes the key to core dumps, swapping, and forking. The user also has to remember to erase the key once done. Granted, core dumps and swapping can be disabled system wide, but some libraries such as libsodium take care of this automatically, without the user having to know the fine details.

Would you be open to a crypto.alloc() method to allocate buffers for use as crypto keys and help with crypto memory management, this would:

  1. Set the platform equivalents of MADV_DONTFORK, MADV_DONTDUMP, and mlock as far as possible.

  2. Automatically zero buffers at GC time before freeing, along the lines of https://github.com/jedisct1/libsodium/blob/be58b2e6664389d9c7993b55291402934b43b3ca/src/libsodium/sodium/utils.c#L78:L101

  3. Hopefully do guarded heap allocations, but 1 and 2 would be enough for a start.

crypto feature request memory

Most helpful comment

@bnoordhuis I have been experimenting with a secure heap implementation for node and OpenSSL, but I need to patch OpenSSL to make it work. Theoretically, we could consider a secure heap (in the OpenSSL sense) separately from crypto.alloc, but I guess it makes sense to do both the same way.

All 4 comments

I know it's been discussed before but I can't find the issue so I'll just summarize. :-)

It's not that useful while we're still using openssl 1.0.2 because even if node.js takes precautions, openssl won't - it doesn't mlock/madvise its copy of the key. That functionality only exists in 1.1.0 and above and, caveat emptor, openssl doesn't set MADV_DONTFORK because it has to support the pre-fork model.

It might be possible to make it work with 1.0.2 by means of CRYPTO_set_mem_ex_functions but it's unclear if that covers everything. There are a number of places where openssl calls plain malloc/free instead of CRYPTO_malloc/CRYPTO_free (but you would hope only where it doesn't matter) and there might be places where it keeps sensitive data in non-heap storage, like on the stack.

I'm afraid that it won't work as well as we could have hoped for (as @bnoordhuis said). Even if we'd make guarantees for such buffer very strong, there's still on-stack access and V8 heap values that could ruin them.

That functionality only exists in 1.1.0

We're at 1.1.0 now so that's one blocker less.

@tniessen I suspect you may have ideas on how to do key management?

@bnoordhuis I have been experimenting with a secure heap implementation for node and OpenSSL, but I need to patch OpenSSL to make it work. Theoretically, we could consider a secure heap (in the OpenSSL sense) separately from crypto.alloc, but I guess it makes sense to do both the same way.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

vsemozhetbyt picture vsemozhetbyt  路  3Comments

akdor1154 picture akdor1154  路  3Comments

danialkhansari picture danialkhansari  路  3Comments

cong88 picture cong88  路  3Comments

stevenvachon picture stevenvachon  路  3Comments