Framework for managing secrets

[mzabaluev]

At the bare minimum, we need a way to provision node's secret keys in a way that is not easily available for inspection with common system tools, such as an environment variable or a command-line option value. To allow future security enhancements, out-of-process secret management should be supported.

Alternatives

Open Question: Check if this is mitigated by container tools: if we can run the node in deployment such that the container runner sets an environment variable from a source that is not available for inspection by unauthorized parties, this solves our current problem.
Still, in-process management of secrets is weak security in the long term.

Use of secrets

See also #435 and MIP-1.

Aptos

A signing key is used to:

1. Derive the public key for the genesis transaction.
2. Sign all faucet transactions.

Secure out-of-process signing is therefore not required for mainnet operations, but would be nice to have for development and the testnet.

Celestia

• A private key is generated by the cel-key utility and is used to obtain an auth token from the API. The utility support multiple backends, mostly based on local files. The os backend integrates with the OS key management (to be clarified).

• We need to start signing blob content. The API and choice of key algorithms is entirely under our control.

MCR settlement

The MCR signing key is used to sign Eth transaction. The signing API for Ethereum is already extensibly abstracted by alloy-signer, with backends available for in-memory local keys, AWS KMS, YubiHSM, and other signer implementations.

API design

The API should support out-of-process private keys with challenge-response auth.

• Check if aptos-core provides the hooks. If not, modifications need to be designed.
• Async, no need to block if key auth is done out of process.
• Only needs to covers the current operations and key algorithm.

The MVP features

Backends for:

• Local private key file (separate from config)
• AWS KMS.

[l-monninger]

MVP: support local file (separate from config) and AWS Secrets (or KMS?).

I think we should write this as an abstraction layer with the first "backends" to be implemented being local files and KMS. If you agree, maybe let's sketch some type-level programming for that.

challenge-response auth.

How would you generalize challenge-response auth?

[mzabaluev]

First off, I need to check if we get the necessary hooks from aptos-core.

If that can be solved, I think we can start with a simple async trait API to abstract the private key operations that are currently used by the node. The key type could be hardcoded, or we can design some future extensibility at this point already.

[l-monninger]

So, I think as a first objective, we should just be to worry about loading keys into the the current Aptos types. I think the more extensive setup is better suited for a TPM abstraction PR'd into aptos-core.

This would also be more generally useful, e.g., for keys for other platforms.

[mzabaluev]

How would you generalize challenge-response auth?

I've followed successfully used designs in this API sketch.
A protocol involving nonces (like MIP-1) does not need to be represented in this abstraction, but an implementation of it is possible.

[l-monninger]

Yeah, it can be another client object that is hidden under the trait below.

[mzabaluev]

The only secret that a Suzuka node currently needs to operate seems to be the MCR signing key. The signing API for Ethereum is already abstracted by alloy-signer, with backends available for in-memory local keys, AWS KMS, and other signer implementations. We only need to adapt the client and configuration to be able to use any other backends we decide to support.

[mzabaluev]

The API for asynchronous signers can be a synthesis of essential parts of alloy-signer (for which it could be a backend) and async-signature API.

/// Signature error, deliberately opaque to prevent side-channel leakage
pub struct Error {
    // ...
}

/// A possibly remote agent that signs messages with a digital signature.
pub trait Signer<Signature> {
    /// The type of the public key that can be used to verify the signatures.
    type PublicKey: Verifier<Signature>;

    /// Returns the public key used by the signer.
    /// The signer entity must have been initialized and its public key interrogated
    /// before this API is available.
    fn public_key(&self) -> Result<Self::PublicKey, Error>;

    /// Signs the message.
    async fn sign(&self, msg: &[u8]) -> Result<Signature, Error>;
}

[l-monninger]

I'm mostly good with this trait.

How confident are we that this will hold for all backends?;

/// The signer entity must have been initialized and its public key interrogated
/// before this API is available.

[mzabaluev]

A backend that needs asynchronous setup should have it in its construction API, before producing a Signer. So a client using MIP-1 to talk with an enclave would have a handshake async method/future type to synchronize the nonce and query the public key via its APP protocol before producing the object encapsulating the synchronized nonce and the public key and implementing Signer.

My doubt is more about there being a single public key at all. But for multisig algorithms, evolving keys, and the like, we can always create another trait if needed (implementers of Verifier can be versatile too, except I'd like it to be synchronous and assume lightweight state).