consensys / quorum-hashicorp-vault-plugin

This plugin enhances Hashicorp Vault Service with cryptographic operations to create, import and sign using different type of keypairs and Ethereum wallets, including signing operation for public ethereum transaction, EEA and Quorum

Quorum Hashicorp Vault plugin

The Quorum plugin enhances Hashicorp Vault Service with cryptographic operations under Vault engine, such as:

• Create and import keys with the following supported eliptic curve and signing algorithm: ecdsa+sepc256k1 or eddsa+babyjubjub
• Sign with every supported key pair.
• Create and import Ethereum wallets
• Sign Ethereum transactions
• Sign EEA private transaction
• Sign Quorum Tessera private transaction
• Create and import ZKP accounts
• ZKP signing operation

Development

Pre-requirements

• Go >= 1.15
• Makefile
• docker-compose

Running local version

Build plugin binary

$> make gobuild

To run our plugin in development mode you have to first build the plugin using:

$> make dev

Testing

Now you have your Vault running on port :8200. Open a new terminal to run the following command to enable Orchestrate plugin:

$> curl --header "X-Vault-Token: DevVaultToken" --request POST \
  --data '{"type": "plugin", "plugin_name": "quorum-hashicorp-vault-plugin", "config": {"force_no_cache": true, "passthrough_request_headers": ["X-Vault-Namespace"]} }' \
  ${VAULT_ADDR}/v1/sys/mounts/quorum

Now you already have your Vault running with Orchestrate plugin enable. The best way to understand the new integrate APIs is to use the help feature. To list a description of all the available endpoints you can run:

$> curl -H "X-Vault-Token: DevVaultToken" http://127.0.0.1:8200/v1/quorum?help=1

alternatively you can list only ethereum endpoints by using:

$> curl -H "X-Vault-Token: DevVaultToken" http://127.0.0.1:8200/v1/quorum/ethereum/accounts?help=1

Running using latest version

Running Quorum Hashicorp Vault Plugin plugin:

$> docker-compose -f docker-compose.yml up --build vault

Contributing

How to Contribute

License

Quorum Hashicorp Vault plugin is licensed under the BSL 1.1.

Please refer to the LICENSE file for a detailed description of the license.

Please contact [email protected] if you need to purchase a license for a production use-case.

quorum-hashicorp-vault-plugin's Issues

Permission Denied with Non-Root Tokens

Is there an example policy file for accessing quorum plugin?
I am getting permission denied error with the following policy:

path "quorum/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

Incompatible with Vault 1.9.3

I am getting the following error from calling quorum plugin mounts with Vault v1.9.3

{"errors":["1 error occurred:\n\t* Unrecognized remote plugin message: \n\nThis usually means that the plugin is either invalid or simply\nneeds to be recompiled to support the latest protocol.\n\n"]}

Signing arbitrary data doesn't support prehashed payloads

Signing arbitrary data doesn't seem to support custom prehashed payloads. It seems that the plugin internally hashes it with keccak256? This makes it harder to recover public keys when other hashing algorithms are used as a client (i.e, sha256, blake2b, blake2s, etc )

I know that the plugin is very ethereum specific, but is there a chance to have a more by-the-book ECDSA that allows prehashed payloads instead of assuming keccak256?

Or, is there an endpoint that doesn't do that?

Thanks!

Setcap on plugin file within image

In order to have an image compliant with Azure expectations it would be good to have the following setcap command run when building the Docker image

setcap cap_ipc_lock=+ep /vault/plugins/quorum-hashicorp-vault-plugin

Publish plugin checksum included in dockerhub images

Every compilation of the binary provides different outputs the value included in the github artifact (SHA256SUM) and the actual value for the plugin included in the built image does not match.

The goal of this ticket is to make available a version of the SHA256SUM included in the dockerhub image so it can be used in the k8s operator.

no handler for route \"quorum/\". route entry found, but backend is nil

Can u help me? how i can fix it?

2023-04-21T21:17:51.860Z [DEBUG] core.cluster-listener: performing server cert lookup
2023-04-21T21:17:51.866Z [DEBUG] storage.raft.autopilot: state update routine is now stopped
2023-04-21T21:17:51.866Z [DEBUG] storage.raft.autopilot: autopilot is now stopped
2023-04-21T21:17:51.873Z [INFO]  storage.raft: aborting pipeline replication: peer="{Voter vault-2 vault-2.vault-internal:8201}"
2023-04-21T21:17:51.929Z [DEBUG] storage.raft.raft-net: accepted connection: local-address=vault-0.vault-internal:8201 remote-address=10.244.0.250:56812
2023-04-21T21:17:51.931Z [DEBUG] storage.raft: lost leadership because received a requestVote with a newer term
2023-04-21T21:17:52.358Z [INFO]  core: stopping raft active node
2023-04-21T21:17:52.358Z [DEBUG] expiration: stop triggered
2023-04-21T21:17:52.358Z [DEBUG] expiration: finished stopping
2023-04-21T21:17:52.358Z [INFO]  rollback: stopping rollback manager
2023-04-21T21:17:52.365Z [WARN]  secrets.quorum-hashicorp-vault-plugin.quorum-hashicorp-vault-plugin_cc577e57.quorum-hashicorp-vault-plugin: error closing client during Kill: err="rpc error: code = Canceled desc = grpc: the client connection is closing"
2023-04-21T21:17:52.366Z [WARN]  secrets.quorum-hashicorp-vault-plugin.quorum-hashicorp-vault-plugin_cc577e57.quorum-hashicorp-vault-plugin: plugin failed to exit gracefully
2023-04-21T21:17:52.374Z [ERROR] secrets.quorum-hashicorp-vault-plugin.quorum-hashicorp-vault-plugin_cc577e57.quorum-hashicorp-vault-plugin: plugin process exited: path=/vault/data/plugin/quorum-hashicorp-vault-plugin pid=55 error="signal: killed"
2023-04-21T21:17:52.384Z [INFO]  core: pre-seal teardown complete

Incorrect ECDSA Format for arbitrary data signing

• When singing arbitrary data with the endpoint /sign; the description says Signs an arbitrary message using ECDSA

• The standard format for ECDSA should be comply with RFC6979.

• • Quote : The pair (r, s) is the signature. How a signature is to be encoded is not covered by the DSA and ECDSA standards themselves; a common way is to use a DER-encoded ASN.1 structure (a SEQUENCE of two INTEGERs, for r and s, in that order).

• The signature length should be of 64 bytes (R - 32 bytes, S - 32 bytes). But the signature returned in the endpoint is of 65 bytes.

• sample responses :

• • 0x0866a9ebb23cc4b047e398d7ede52b718a067c0d7f40595baa6b0d0c395152557a578887b7295152a2b9aeb01f96b11a28757b9f3722ddf4998353b643a4ecb900
• • 0xc1bdd9d097a131434115b563706bb94367fdb7c412f677b5fe8c26e181c579ae642ae3a8287bcc75add88932fe48d956aaf3cba5913ee8d185266d88b7ecd4ec00

The last trailing 00's i'm assuming are part of Ethereum's signature scheme for transactions specifically and as part of EIP-155 (Replay protection). Which is of the following format (r, s, v). Which would make send when using sign-transaction , but not for arbitrary data?

V is always 00 / 01 in this case and not part of standard ECDSA and as a client if we want to verify signatures without the private key; it means that we have to manually cut the last byte.

Add arm64 support image

Add arm64 support image into CI

https://consensys.slack.com/archives/CJKPYRUAZ/p1646302291648199