A store is a Quorum Key Manager (QKM) component that interfaces with an underlying secure system storage (such as HashiCorp Vault, Azure Key Vault, or AWS KMS) to perform crypto-operations.
The store manager is a QKM component that uses store manifest to create and manage stores. Other QKM components use the store manager to access stores and perform crypto-operations.
QKM defines the following store interfaces:
A vault defines the user credentials required to access secure system storage, such as HashiCorp Vault, Azure Key Vault, or AWS KMS.
A secret store allows you to store and access secret values, but doesn’t expose any crypto-operations.
Depending on the implementation, a secret store:
- Can manage multiple versions of a secret.
- Has advanced capabilities to delete and recover secrets.
A key store manages keys and enables crypto-operations such as signing and encryption.
A key store can generate and import keys, but doesn’t allow access to the private part of a key.
Depending on the implementation, a key store:
- Has advanced capabilities to delete and recover keys.
You can implement a key store to:
- Delegate crypto-operations to an external dependency.
- Use the underlying secret store to perform crypto-operations locally.
An Ethereum store manages Ethereum accounts and performs Ethereum-related crypto-operations (for example, signing transactions).
An Ethereum store can generate and import accounts but does not expose the private key of any account.
You can implement an Ethereum store based on an underlying key store to perform signing, while the account store is responsible for performing Ethereum-specific processing, formatting, and encoding.
If you have existing Ethereum accounts in a secure storage system, you must index them in
your local QKM database in order to use them.
/ethereum REST API endpoint to
interact with an Ethereum store.