Context

It is very important than under no circumstances that Nimbus never leaks private keys.
Ideally, Nimbus never has knowledge of those and all private key manipulations are done in a separate library or even hardware.

Issues

At the moment, Nimbus does manipulate the private key in non-test/mocking files for the ValidatorPool (search: https://github.com/status-im/nim-beacon-chain/search?p=1&q=ValidatorPrivKey&unscoped_q=ValidatorPrivKey).

https://github.com/status-im/nim-beacon-chain/blob/136a11f681508dde4fb1f030cc673259312757ab/beacon_chain/beacon_node_types.nim#L219-L241

It is also used in genRandaoReveal but that is much easier to offload to a library:
https://github.com/status-im/nim-beacon-chain/blob/63e621c27d66f8f61796033a602eb3999b9e94c9/beacon_chain/validator_pool.nim#L67-L73

Furthermore the data is heap-allocated, this means that it could be written to disk via core dumps or when swapping (see our recommendation to use lot of swap for Raspberry Pi).

Recommendation

Create a set of API that will be exposed by an external library that will be in charge of just handling private keys and where we could focus special security efforts.

In particular, if heap allocation is needed, it should not be dumpable or swappable and erasing/wiping it should not be optimized away by the compiler.

Unknown

GDB and other debuggers. While we can strongly recommend to setuid or equivalent to prevent attaching, there doesn't seem to be a way to prevent secrets from leaking when gdb is launched by root.

References

CERT Secure coding rules for C:
https://wiki.sei.cmu.edu/confluence/display/c/MEM06-C.+Ensure+that+sensitive+data+is+not+written+out+to+disk

Encrypting secrets in-memory:
https://spacetime.dev/encrypting-secrets-in-memory

Implementation in Go:
https://github.com/awnumar/memguard

Memory retention attacks:
https://spacetime.dev/memory-retention-attacks