search

cosmos / cosmos-sdk

:chains: A Framework for Building High Value Public Blockchains :sparkles:
https://cosmos.network/
Apache License 2.0
6.26k stars 3.62k forks source link

Key Management Meta-issue #7074

Closed aaronc closed 3 years ago

aaronc commented 4 years ago

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:

Needed for completion:

Msg Authorization

Existing/Historical PRs:

Needed for completion:

Groups

See #7633

secp256r1/NIST P-256 Signing

See #7718

okwme commented 4 years ago
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 commented 4 years ago

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

https://github.com/CosmWasm/cosmjs/issues/413

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

aaronc commented 4 years ago

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

fadeev commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 https://github.com/EOSIO/eos/pull/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 commented 4 years ago

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 https://github.com/EOSIO/eos/pull/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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

fadeev commented 4 years ago

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

ethanfrey commented 4 years ago

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:

2nd, 3rd... device:

Removing:

Challenges:

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

Checking on the status here.

aaronc commented 3 years ago

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