Implement logic to securely store key

[andynog]

Crate

• ibc-relayer
• ibc-relayer-cli

Summary

Currently the key file for each chain is stored in plaintext mode on the host running the relayer

Problem Definition

When users add a key from a chain that can sign messages using the relayer command hermes keys add [chain-id] [filename] where filename is a JSON file that contains the mnemonic that can restore a private key (usually this file is generated and output from a chain command for example gaiad keys add.

After executing the keys add command, currently the implementation is just to copy the file in the hermes home folder, so for example, for a chain ibc-0 and filename key_seed.json the file will be stored using the key_name parameter from the config. So if the key_name is testkey the file will be stored in plaintext mode in the following path:

$HOME/.hermes/
├── config.toml
├── keys
│   ├── ibc-0
│   │   └── keyring-test
│   │       └── testkey.json

Proposal

Even though the key is stored as plaintext, node (relayer) operators should ensure the file permissions are properly setup in order to keep the key secure.

But we should look into ways to store the key in a way that is encrypted and not visible in plaintext mode. The solution would also allow the relayer process to retrieve and use the key without a user intervention since the relayer should be able to sign messages without human intervention.

Some ideas to implement this could be:

• Use a keyring solution:
  • Such as https://github.com/hwchen/keyring-rs
• Use a vault solution like Hashicorp vault:
  • Such as https://crates.io/crates/secret-keeper
• Use a kms service that supports hardware kms:
  • Such as https://github.com/iqlusioninc/tmkms

I expected that some discussion will happen related to benefits and trade-offs of each different approach especially from a production / devops / secops perspective until there's a decision on what is the best approach.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate milestone (priority) applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[tomtau]

I think the most flexible approach may be to utilize some "remote signing" interface -- e.g. tmkms has this: https://github.com/iqlusioninc/tmkms/blob/main/README.txsigner.md

[clemensgg]

bumping this because today we are facing operational situations where key protection makes more sense (chains with global account whitelisting) 🙏

[romac]

@clemensgg Which, if any, of the potential solutions listed above by @andynog would fit your use case the best?