Issue B: No Zeroization of Secret Data

[mpguerra]

Location

Examples (non-exhaustive):

• participant/src/cli.rs#L47
• frost-client/src/trusted_dealer.rs#L64
• dkg/src/cli.rs#L72

Synopsis

Secret data, such as the nonce or the secret key, is not erased from memory and could be leaked.

Impact

This issue could potentially result in the full disclosure of secrets.

Preconditions

Root access to the machine is required, enabling the reading of process memory from other processes.

Severity

Low.

Technical Details

As highlighted in RFC 9591 and other related documentation, secret data, such as the nonce, must be deleted after it has been used. More specifically:

• For the nonce and commitment in RFC 9591, Section 5.2: “Each participant MUST delete the nonce and corresponding commitment after completing sign.”
• For the trusted dealer key generation in RFC 9591, Appendix C: “delete secret values after distributing shares to each participant” and “The trusted dealer MUST delete the secret_key and secret_key_shares upon completion.”
• For the DKG protocol described in KG20, in Figure 1, the paper states that the proofs of knowledge sigma_i from Round 1, Step 5, as well as the polynomial evaluations from Round 2, Step 3, should be deleted.

Currently, secret data is stored in memory, while it is likely overwritten during normal code execution. This is neither a best practice nor a secure method for deleting secret data. Instead, zeroization should be implemented.

Remediation

We recommend utilizing memory zeroization of all sensitive values.