Key Management Meta-issue

[aaronc]

Summary

The 3 key management modules that Regen Network worked on (fee grants, msg authorization and groups), oftentimes referred to as "subkeys" support, were postponed from the Stargate release due to time constraints. Some of this work has already been migrated to protobuf and is near completion. This meta-issue tracks their progress towards completion for the next release.

Details

The design of these modules was initially described publicly in the following gist: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56. Issue #4480 describes "subkeys" functionality and influenced the design of the modules proposed below.

Fee Grants

Existing/Historical PRs:

• Enable Fee Delegation #5768
• Migrate x/feegrant to proto #5782
• Enable Fee Delegation #5207
• Add FeeAccount to StdTx and add fee-delegation module #4616

Needed for completion:

• ADR 029: Fee Grant Module #7106 ADR
• implementation (continue from Enable Fee Delegation #5768)

Msg Authorization

Existing/Historical PRs:

• Msg Authorization ADR #5235
• WIP: Add msg_authorization module #5412

Needed for completion:

• ADR 030: Authorization Module #7105 ADR (continue from Msg Authorization ADR #5235 and update to protobuf)
• implementation (continue from WIP: Add msg_authorization module #5412)

Groups

See #7633

secp256r1/NIST P-256 Signing

See #7718

[okwme]

do-not-edit-start-codetree-epic-issues

Issues in this epic:

Title	Milestone	Assignees	State
Add Group Module #7633	Feature Backlog	blushi	Open
Add secp256r1 Signing Keys #7718	v0.43	robert-zaremba	Closed
ADR 029: Fee Grant Module #7106	v0.43	N/A	Merged
ADR 030: Authorization Module #7105	v0.43	N/A	Merged

do-not-edit-end-codetree-epic-issues

cc/ @fadeev @dogemos @jgimeno @alessio @hxrts

[fadeev]

I strongly believe we should investigate WebAuthn (or to be more precise, FIDO2 CTAP) as an easy way for users to authenticate themselves.

cosmos/cosmjs#413

Relevant part of the implementation for EOS: https://github.com/EOSIO/eosio-webauthn-example-app/blob/master/src/client/wasig.ts

[aaronc]

@fadeev would WebAuthn be something we'd need to support on the blockchain side or just in client SDKs like cosmjs?

[fadeev]

@aaronc most likely there will have to be changes made to the blockchain. Primarily, due to the fact that WebAuthnas far as I know uses different signing algorithms and the one we need is in a Aug 2020 RFC.

@jordansexton can you comment on that based on your investigation into WebAuthn?

[aaronc]

@aaronc most likely there will have to be changes made to the blockchain. Primarily, due to the fact that WebAuthnas far as I know uses different signing algorithms and the one we need is in a Aug 2020 RFC.

Which signing algorithm? Is it just a different pubkey type?

[jordaaash]

WebAuthn doesn't yet support secp256k1 and it isn't supported in practice in my testing using Mac Touch ID or Google Titan keys. There is a recent RFC proposing support for it. There are some other challenges here as well. As EOSIO/eos#7421 demonstrates, more than just public key bytes would be required because of WebAuthn's attestation/assertion protocol. This implies to me that changes would be necessary to Tendermint's crypto module, the SDK, and various clients to support this.

[jordaaash]

The alg identifier of WebAuthn's JavaScript API configuration provides for selection of the encryption algorith from this list. However in practice, the algorithm must be supported by the browser and potentially by the hardware key itself (unclear to me). -47 is assigned for ECDSA using secp256k1 curve and SHA-256, but it is currently not recommended for use and unsupported by browsers. The only way I can think of to support this currently would be

1. Add support for secp256r1 keys (WebAuthn alg: -7 assigned to ECDSA w/ SHA-256) to Tendermint core. The public key bytes would need to contain all the data mentioned in WebAuthn key and signature support EOSIO/eos#7421.
2. Add support for signing and validating messages using these keys to the SDK.
3. Same as 2 but for any client implementations (e.g. CosmJS).

[ethanfrey]

For (1) why do we need to add it to Tendermint Core? We should add it to Cosmos SDK crypto (I think they are no longer the same?)

[jordaaash]

@ethanfrey you may be right about that. I wasn't aware of that change. Briefly glancing at the SDK code, there are still a lot of imports from tendermint/crypto but I don't know how they are used now.

[ethanfrey]

Also, since webauthn keys are tied to one https domain, we will likely need to allow multiple keys to control one account on chain. This will require some sort of group management (in cosmwasm, cw1-whitelist would provide sufficient functionality), but more importantly, some sort of fee delegation, so that my newly generated key on my browser can pay fees from the shared account (this is needed in the core sdk tx logic)

I think these are in 0.41 or 0.42 milestones for the SDK

[ethanfrey]

Basically, when I create such a key (and have one on 3 different devices), how do I tie them into one usable account?

[fadeev]

Have a module that maps several addresses/accounts to a single user.

[ethanfrey]

Have a module that maps several addresses/accounts to a single user.

In CosmWasm-land: cw1-whitelist does that. cw1-subkeys does so with more fine-grained permissions (but requires the original sender to be able to cover the fees)

In SDK land, the group accounts and fee delegations will enable that (with better/tighter integration, especially for fees)

The issue then becomes adding the new device to an account. You will need to have access to one existing device on the account to add the new device when it creates a new key. You could say.

1st device:

• create key
• hit faucet for tokens (or transfer them from exchange, etc)
• create cw1/group account as "1/1 multisig"
• device can interact with the chain via the group account

2nd, 3rd... device:

• create key
• (offchain -how? qr code?) send request to registered device to add to key
• previously registered device adds new key to the existing group account
• new devices can interact with the chain via group account

Removing:

• if device is lost, any other registered device may remove it from the list

Challenges:

• Getting the first tokens to start with (this is always a complicated mess in blockchain)
• Communicating between newly registered device and previously registered device (look to Ethereum for inspiration)

I think "Communicating between newly registered device and previously registered device" is a huge blind spot in Cosmos, and the extreme difficulty of using the current multisigs that require off-chain aggregation show this. I would love to hear any ideas on how to make that easier. Since those ideas do not touch the Cosmos-SDK and can be used for many workflows, that is a quick place to experiment and iterate.

[okwme]

WalletConnect is poised to begin work on multi-chain support. This may be an opportunity to leverage that protocol. I'm not sure what would be required for it to interface with WebAuthn though. Maybe @pedrouid already has some ideas?

[ethanfrey]

A lot of these pieces are orthogonal. Passing messages and partially signed tx between devices easily will be a huge ux bonus, then we can start building clients that use that.

Webauthn can be added on top, but web wallet, with 2fa on mobile wallet is a huge help, even if the web wallet isn't using webauthn

[jackzampolin]

Checking on the status here.

[aaronc]

All of the pieces have been merged and are in QA in preparation for the 0.43 release.