Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Cosmos transaction signing support #386

Open
tarcieri opened this issue Dec 30, 2019 · 6 comments
Open

Proposal: Cosmos transaction signing support #386

tarcieri opened this issue Dec 30, 2019 · 6 comments

Comments

@tarcieri
Copy link
Collaborator

@tarcieri tarcieri commented Dec 30, 2019

Presently Tendermint KMS only supports signing consensus proposals/votes. That said, the prerequisites are all in place, both in the tendermint crate and the yubihsm crate, to sign data using account keys as well.

This proposal is to add first class support to sign transactions in the format used by the Cosmos SDK. Though this project is "Tendermint KMS" and intended to be agnostic to specific Tendermint applications, the Cosmos SDK's transaction format seems widely adopted among Tendermint applications, enough to warrant this support. (In the future there are various ways this support could be generalized to signing other transaction/object types, using e.g. WASM, but that sort of approach is considered out-of-scope for this particular proposal)

Motivation

Our initial use case at iqlusion is signing transactions for a Terra exchange rate oracle. The KMS-side goal of this proposal is to avoid making the KMS-side functionality hardcoded to this particular application, but rather to place a set of constraints (provided via tmkms.toml) on the transactions to be signed, and having the KMS assert those constraints are being met. Ideally this will allow the KMS to provide hardware-backed signing functionality for any type of Cosmos transaction, outsourcing the transaction composition to a separate service, but still allowing the KMS to constrain aspects of the signed transaction.

High-level Design

There are several ways such a feature could be implemented. The proposal below is one, with debatable details, which presently targets doing things as similarly to the existing Tendermint consensus signing as possible:

  • KMS is configured with a key usage policy and the address of a transaction-building service to connect to. Connection is encrypted using Secret Connection.
  • Transaction-building service sends a newly defined Amino-encoded request (e.g. SignTxRequest) to the KMS containing a transaction (or declaration of the desired transaction, with actual serialization handled by the KMS itself)
  • KMS validates the requested transaction according to a configured policy, and if the transaction is authorized according to that policy, signs the transaction (using either a software-backed or YubiHSM2-backed key. It may be possible to also support Ledger, but that might involved changes to the Ledger validator application)

Design Rationale

Here's a brief rationale and some alternatives to consider for each of these options:

  • Outbound Secret Connection: this follows the current approach used for connecting to validators. I still think it would be interesting for the KMS to support both inbound and outbound connections (as is otherwise presently possible with P2P traffic) which users can configure to their liking. Additionally there are many other options for transport encryption to consider (TLS, Noise, libp2p+Noise). However, using an outbound Secret Connection allows reuse of all of the existing networking code, and in doing so, means that we can also separately tackle the issues of different connection models or different transport encryption in a single place (in addition to moving to e.g. Tokio), rather than trying to shoehorn that work onto this proposal.
  • Amino: ...is not long for this world. Protobufs are probably the main alternative to consider. However, right now both tendermint-rs as well as tmkms itself import the main Protobuf library we'd like to use, Prost, in a way which precludes using it for proper Protobufs. We could pull in an additional Protobuf library now, but the other alternative there is to just use Amino for now and switch things over to Protobufs when Tendermint itself makes that transition. Once this has been addressed it would also be possible to consider e.g. gRPC libraries based on Prost, like Tonic.

Open Questions

  1. What restrictions should the KMS support on transaction signing?
  2. Could Ledgers be supported in addition to YubiHSM and soft sign backends?
  3. Is there a way to support generic signing with restrictions (i.e. not a pure signing oracle) without coupling directly to the Cosmos transaction format?

See Also

@tarcieri

This comment has been minimized.

Copy link
Collaborator Author

@tarcieri tarcieri commented Dec 30, 2019

Regarding building Cosmos SDK-compatible transactions from Rust, it looks like the deep_space crate is capable of this, but is a bit rough around the edges.

@jleni

This comment has been minimized.

Copy link
Collaborator

@jleni jleni commented Dec 30, 2019

About your open question wrt Ledger devices..
The cosmos app already does everything that is needed, however for security reasons, at the moment always requires manual confirmation.

Extending the rust driver to support both Tendermint and Cosmos apps, should be fairly easy.

The only change the app needs is to have a menu option so users can enable/disable "sign without confirmation". BUT, I am not sure Ledger will accept this feature unless it is released with a big warning.

I would prefer to limit by protocol which tx types can be signed without confirmation. That way the check can be done inside the secure element and not in the KMS software layer.

@tarcieri

This comment has been minimized.

Copy link
Collaborator Author

@tarcieri tarcieri commented Dec 30, 2019

@jleni would it be possible to compose and upload some sort of ACL which can be displayed on the device, confirmed, and then stored to enable subsequent "sign without confirmation" usage?

@gaia

This comment has been minimized.

Copy link

@gaia gaia commented Dec 30, 2019

(Maybe not the place for this suggestion, and definitely too early. LMK I will remove it)

Reading in #361 that proposal would give the ability to sign messages: please structure this so that (down the line) messages can be stored in IPFS (for larger files, such as PDFs) or similar file storage protocol. A digital notary is a real world business use case with large demand. The current landscape for PAdES-Long Term Validation PDF signature/certification is an oligopoly maintained by Adobe and a few trusted partners (AATL), with complex implementation, exorbitant costs, and outdated technology.

PS: I would be interested in using a PDF digital notary for my other (non blockchain related) company.

@tarcieri

This comment has been minimized.

Copy link
Collaborator Author

@tarcieri tarcieri commented Dec 30, 2019

@gaia to the extent this can be used as a digital notary service, I think the main idea here would be notarizing things as Cosmos transactions, which are validated and stored by a Tendermint application which understands the Cosmos SDK transaction format.

Anything more general than that, beyond generalizing something which could be used to produce Cosmos SDK-compatible transactions, I'd suggest discussing on #361 instead.

@jleni

This comment has been minimized.

Copy link
Collaborator

@jleni jleni commented Dec 30, 2019

@tarcieri yes, it should be possible. It should be quite simple due to hardware constraints.. but we could design some grammar + set of rules: and, not, field matches value, field greater than X, etc.

tarcieri pushed a commit that referenced this issue Dec 31, 2019
Support for ECDSA (secp256k1) account keys, with the goal of using them
to support KMS-backed Cosmos transaction signing (#386)
tarcieri pushed a commit that referenced this issue Jan 3, 2020
Support for ECDSA (secp256k1) account keys, with the goal of using them
to support KMS-backed Cosmos transaction signing (#386)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.