Governance Stage 0: Signing Key Generation and Use

[l-monninger]

Summary

The current proposal for Governance Stage 0 (#421) is to generate all signing keys on trusted hardware and prevent direct access. This roughly means that each place we currently use a signing key needs to be evaluated for use via a HSM/TPM or enclave.

An enclave-based solution is likely most generalizable, as we can push existing (and potentially already audited) logic directly down into the logic of the program running in the enclave. However, AWS Nitro Enclaves (the product we would likely use) do not have backups, meaning we have to consider some additional patterns.

A KMS approach may also be deemed just as viable, given the control of access to the signing capabilities poses a similar attack to access to the signing keys themselves.

Aptos

We keep a maptos_signing_key which is used to:

1. derive the public key for the genesis transaction, this function should be written out;
2. sign all faucet transactions, which will not be a function at mainnet, but needs to be preserved for testing.

Thus, the primary modification here needs to be to sign raw Aptos transactions for the faucet with trusted compute. A discussion about how difficult this would be to implement non-destructively in aptos-core has already started here at #387. If we wanted to do this in the faucet app-logic, that might be easier.

Celestia

1. We use a private key stored in a well-known directory to request and auth token stored in our config as celestia_auth_token. We then use this token to sign blob submission transactions.
   • This, will require closer inspection of the cel-key binary. We may be able to use backends available via https://github.com/iqlusioninc/tmkms Cosmos-SDK (in Go).
2. We will need to sign blob content--likely with keys that need to validated on ETH--in order to prevent low-grade DOS attacks in the same vein as the Woods Attack.
   • This can be a fairly general HSM/TPM abstraction or enclave service for singing data. This is arguably where we have the most flexibility.

ETH Signing: Contract Upgrades, Contract Method Calls, and Staking

Most of these transaction calls will already have to be written from scratch--which is a blessing and a curse. We could therefore simply send raw transactions to a HSM/TPM for signing. Secp256k1 is not supported by any TPM I'm aware of. It is supported by AWS HSM. But, this could also take place in an enclave, but...

General Key Generation and Signing

In general, keys should be generated in a place which is recoverable, reliable, and able to restricted from direct access. This place also somehow has to be able perform the necessary signing logic.

• Generating a key directly in an AWS Nitro Enclave, for example, is probably not a good idea because the enclave could crash and the key would be unrecoverable--as I don't believe AWS Nitro Enclaves have backups.
• HSM and TPM products generally have backup support. But, products with Dalek support are experimental, e.g., tkms.
• Simply using KMS is problematic because it is essentially subject to governance by IAM roles.

The following are some strategies which could contend with this:

• Key Encryption w/ HSM: we could encrypt a private key with an HMS-supported algorithm and then decrypt it in the Nitro Enclave to perform the appropriate signing. Similar patterns are presented here: https://d1.awsstatic.com/events/Summits/reinvent2022/BLC401_Using-AWS-Nitro-Enclaves-for-secure-blockchain-key-management.pdf
• Shamir's Secret Sharing: we could use SSS to split shares of the secret into multiple keys and share these between enclaves. However, this could only be used to improve crash resistance and does not absolutely ensure recoverability. It would also require generating several enclaves immediately.
• Attestation-based Role Claiming: for cases where we have smart contracts, we could set up a scheme for potentially multiple schemes to claim a role-based on attestation to enclave logic. We could use public nonces to map the enclave attestation to a given claimed sender in a contract. This would essentially be as secure as trusting AWS enclave attestations and the internal logic of enclave signer.

Combatting Misuse of Enclaves

If we do go for an enclave-based signing approach, there a couple more clever things that can be done to make misusing the enclave more difficult:

• Context-aware Signing: this basically means pushing more logical checks down into the enclave instead of just signing anything that comes along. You could use certain commit-reveal and challenge-response approaches here as is discussed below.
• Smart-contract Pre-approval: this is basically a more expensive and involved commit-reveal, but you could essentially submit a proposal on-chain and then have the enclave check the state and authorize it. This would require verifying signatures or inclusion proofs that appropriately attest to the state in the enclave, otherwise it is susceptible to having its context manipulated.
• Security through Obscurity, Generalized Commit Reveals, and Beyond: you write the enclave and the client, i.e., the software using the enclave in such a way that they submit challenges to one another that are consistently upgraded with stateful logic that would be hard to fake. For example, you could store two pseudorandom nonces in the enclave client, one will be for the current request and the other for the next. The enclave validates this commit-reveal. Initially, you would need a trusted setup, but you could assign a timelock that makes it so an exploiter would have to wait a while before being able to use the enclave. You can see this then starts to invoke cryptographic prover and argument systems, but those are prohibitively expensive (or else we would be building ZK tech). Instead, it's really the initial timelock here and the concealment of the secretes commit to by the client that does the trick.

[l-monninger]

The thing I will say in favor of just using KMS though, is even with HSM, TPM, or enclave setups, whoever controls the logic in the enclave (and any checks for attestation), for example, can still control what the keys are doing in pretty dangerous ways.

So, your best line of defense still ends up being things on chain which can be kind of double-up with attestations and similar, but is still really more about the actual voting and time locks.

[mzabaluev]

From the built-in docs of cel-key:

The keyring supports the following backends:

    os          Uses the operating system's default credentials store.
    file        Uses encrypted file-based keystore within the app's configuration directory.
                This keyring will request a password each time it is accessed, which may occur
                multiple times in a single command resulting in repeated password prompts.
    kwallet     Uses KDE Wallet Manager as a credentials management application.
    pass        Uses the pass command line utility to store and retrieve keys.
    test        Stores keys insecurely to disk. It does not prompt for a password to be unlocked
                and it should be use only for testing purposes.

This mostly means optionally encrypted well-known files; pass is based on GnuPG.

[l-monninger]

So, we might have to go to something straight out of tkms or just do some Tendermint signing in an enclave.

[mzabaluev]

I think there are secret sharing algorithms with recovery from M out of N shares. This could be used to guard against a single (or multiple) enclaves crashing. However, successful recovery depends on timely detection of loss of some shares.

There are also projects for decentralized secret storage, one example being Nillion.

[l-monninger]

For Nillion, we would then have to use Nada language I think.

The Shamir Secret Share approach I referenced is essentially that M of N. The issue is it doesn't provide an ability to absolutely recover the secrets.

Also, for the purposes of the actual governance, I generally think it's better to just split influence over multiple secrets. So, our stake should be split over a number of signers. Our multisig wallets would require quite a few signatures. So on.

I do think think the hybrid HSM Enclave approach is a pretty good one to ensuring secrets used by enclaves are recoverable.

[l-monninger]

Ah, the HSM, Enclave approach actually does not work. I though AWS had a special product for communication between the two, but alas no.

[l-monninger]

Here's a thread perhaps worth following: https://repost.aws/questions/QUGBs0NmjASOO6Z12WlSlf0g/is-it-possible-to-backup-or-snapshot-aws-nitro-enclave-instances

[l-monninger]

On-chain ends up being best again.

[l-monninger]

Proposed to this end: movementlabsxyz/MIP#1

[mzabaluev]

On remote signing with Celestia:

The light and bridge nodes can add a PayForBlobs transaction with a signature obtained from one of the keyring backends from Cosmos SDK.
None of the currently available backends support cloud-based remote secure signing. If we decide to go this route, we need to write a Keyring backend for Vault or AWS.

[mzabaluev]

Filed a tracking issue: #999