This is hard issue, that likely requires many changes. But it's important and worthwhile to reduce our attack surface. In general, whenever we are done with any type of sensitive information (public keys, private keys, hex codes for websocket encryption, etc), we should set the memory to zero.
This defensive programming will help in a situation where some type of memory corruption or Virtual Machine exploit is being used, and potentially one user on a physical server is trying to read the memory from another user on the same physical server (but maybe different VM).
Since our full node would also need to do this to be really effective, this is a nice-to-have but is not critical for SD. This task is more valuable for SilentDragonLite + SilentDragonAndroid, since no full node is running on the same computer there, and these security practices actually have a large improvement in safety.
TOB-ZEC-022 from https://github.com/trailofbits/publications/blob/master/reviews/zecwallet.pdf
This is hard issue, that likely requires many changes. But it's important and worthwhile to reduce our attack surface. In general, whenever we are done with any type of sensitive information (public keys, private keys, hex codes for websocket encryption, etc), we should set the memory to zero.
This defensive programming will help in a situation where some type of memory corruption or Virtual Machine exploit is being used, and potentially one user on a physical server is trying to read the memory from another user on the same physical server (but maybe different VM).
Since our full node would also need to do this to be really effective, this is a nice-to-have but is not critical for SD. This task is more valuable for SilentDragonLite + SilentDragonAndroid, since no full node is running on the same computer there, and these security practices actually have a large improvement in safety.
TOB-ZEC-022 from https://github.com/trailofbits/publications/blob/master/reviews/zecwallet.pdf
This is hard issue, that likely requires many changes. But it's important and worthwhile to reduce our attack surface. In general, whenever we are done with any type of sensitive information (public keys, private keys, hex codes for websocket encryption, etc), we should set the memory to zero.
This defensive programming will help in a situation where some type of memory corruption or Virtual Machine exploit is being used, and potentially one user on a physical server is trying to read the memory from another user on the same physical server (but maybe different VM).
Since our full node would also need to do this to be really effective, this is a nice-to-have but is not critical for SD. This task is more valuable for SilentDragonLite + SilentDragonAndroid, since no full node is running on the same computer there, and these security practices actually have a large improvement in safety.