crypto: implement basic secure heap support

[jasnell]

Adds two new command line arguments:

• --secure-heap=n, which causes node.js to initialize
  an openssl secure heap of n bytes on openssl initialization.
• --secure-heap-min=n, which specifies the minimum allocation
  from the secure heap.
• A new method crypto.secureHeapUsed() that returns details
  about the total and used secure heap allocation.

node --secure-heap=16384 --secure-heap-min=128

The secure heap is an openssl feature that allows certain kinds
of potentially sensitive information (such as private key
BigNums) to be allocated from a dedicated memory area that is
protected against pointer over- and underruns.

The secure heap is a fixed size, so it's important that users
pick a large enough size to cover the crypto operations they
intend to utilize.

The secure heap is disabled by default.

Signed-off-by: James M Snell [email protected]

Refs: #36729

/cc @nodejs/crypto @devsnek

[devsnek]

Would it be possible to ask openssl if there's a way we can do this without having to manually specify buffer sizes? I realize resizing allocations is a scary thing in terms of memory security so if they're against it I'd be okay with this but still very sad.

[jasnell]

You certainly could ask but it would likely be a very long time before that landed if at all.

[tniessen]

When I started working on this feature, I decided not to use OpenSSL's implementation, but to rewrite OpenSSL to accept custom secure heap implementations instead. I never finished it and moved the repository around a bit so I can't find it right now, but that is still an option if OpenSSL's implementation is too restrictive. I used a buddy-style allocator with dynamic memory allocations and memory locking.

Allocation failures are a severe problem. OpenSSL will store all kinds of data in secure memory, and denial of service via secure memory exhaustion is a potential attack vector.

[jasnell]

Yeah, the OpenSSL implementation leaves a bit to be desired. It may be worthwhile pulling @richsalz into the conversation here :-)

[richsalz]

The OpenSSL secure memory area implementation is limited (the code is a decade old, back when 512 and 1K RSA keys were all an https server needed). Probably the biggest limitations is that there is only a single fixed-size arena. That could be fixed by allocating additional heaps and linking them, all done at the "sh_xxx" layer in that one file. Secondarily fixing the "round to power of two" allocation would be a good idea.

OpenSSL doesn't put "all sorts of information" in the heap, only private key material. It is possible to have this as a DoS attack; in practice we haven't seen this at Akamai on our servers.

Hope this helps. If @tniessen finds his code, I'd be happy to review it and help push it upstream.

[jasnell]

Thanks @richsalz :) one other question for you .. do you have any references for studies or papers that talk about akamai's experience with secure heap? It would be great to help inform the discussion (for instance, anything that discusses ideal secure heap sizes for various use cases)

[richsalz]

No, we never wrote anything up beyond the commit message, sorry. For a long time secure heap was a sales differentiator for us; after heartbleed we decided to go "all in on openssl" and pushed the code upstream, with improvements (all private key material) and cleanups (it was way too tricky, and knew about ASN1 field names in RSA keys).

[tniessen]

OpenSSL doesn't put "all sorts of information" in the heap, only private key material.

I didn't mean any offense towards OpenSSL! :) I meant that, from the perspective of JavaScript, simple object allocations could use memory in the secure memory area if they wrap private keys, and that freeing secure memory can be delayed until garbage collection occurs. JavaScript allows very little control over memory management.

[richsalz]

No offense taken. :) Yes, if JS is going to put whole objects in the secure heap and can't do just key material it's not gonna be happy.

[jasnell]

Well, there definitely won't be whole objects in there :-) ... We have KeyObject objects that are allocated across several heaps (there's the JS Object wrapper that is part of V8's heap, there's the C++ KeyObjectHandle that is created in the process heap, and there's the EVP_PKEY that is retained. Only the EVP_PKEY (if it's a private key) would be using the secure heap here. We're also considering use of the secure heap to isolate cached entropy (see #36729).

[richsalz]

For key material, there is a flag to the "BN/BIGNUM" datatype that indicates this data should be stored on the secure heap. All key objects use the flags correctly. So if you're using EVP_PKEY it's automatic.

As for storing other things, you're kinda on your own. :)

[jasnell]

As for storing other things, you're kinda on your own. :)

Yep :-) ... the idea in this PR is to make use of the secure heap entirely opt-in, with the user determining the size on process startup. Really appreciate you jumping in @richsalz :-)

@tniessen @devsnek ... even if we add this now then change later to a dynamically sized heap, the command line arguments should be able to remain largely the same. With a dynamically allocated secure heap, --secure-heap=N could still indicate the initial size of the initial arena. We can introduce a --secure-heap-max=N later to enforce an upper-bound. If we eventually get around the power-of-two allocations when we decide whether to deprecate --secure-heap-min=N. But, until then, this still provides useful functionality I think. Even the proposed JS API bit should work well in a dynamic allocation approach later without requiring changes.

[jasnell]

This is ready to go, just waiting for another signoff

[jasnell]

Landed in a4fce32...03c0564

[richardlau]

It looks like the new test added in this PR is consistently failing the ASAN builds.