-
Notifications
You must be signed in to change notification settings - Fork 42
yubihsm: Support for exporting/importing wrapped (encrypted) keys #197
Conversation
Tested manually locally:
This could use some better CI testing, but it's a bit tricky because the MockHSM is not set up to persist state between commands (perhaps it could use some sort of state file), which is needed to test generating and exporting a key as two separate steps. |
Adds support directly to the KMS to make encrypted backups of keys which have been generated inside of the YubiHSM (retroactively, as there exists a similar feature as part of key generation). Also adds a corresponding command to import the encrypted backups. There was already a `tmkms yubihsm keys import` command so this overloads the command to handle both importing existing `priv_validator.json` files (the previous functionality) and importing encrypted backups, with the former ideally going away with time.
41e0ab8
to
ece16ae
Compare
This is the last thing (aside from documentation) I'd like to do before cutting a v0.4.0 release of We should also probably cut a proper v0.3.0 release of the |
@@ -119,6 +119,7 @@ impl Callable for GenerateCommand { | |||
impl_command!(GenerateCommand); | |||
|
|||
/// Create an encrypted backup of this key under the given wrap key ID | |||
// TODO(tarcieri): unify this with the similar code in export? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would definitely be nice to do this before landing this PR as it's otherwise code duplication.
process::exit(1); | ||
}); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some weird magic/guesswork/detection for what type of key to import if it isn't explicitly specified.
I think this should work right most of the time (and if it guesses wrong, it will only result in an error), however it'd be nice to eventually deprecate and remove the overloaded priv_validator.json
import functionality, at least at such a time as people are no longer importing priv_validator.json
keys in practice.
@@ -42,7 +42,7 @@ signatory-ledger-tm = { version = "0.11", optional = true } | |||
subtle-encoding = { version = "0.3", features = ["bech32-preview"] } | |||
tendermint = { version = "0.3.0-beta1", path = "tendermint-rs" } | |||
tiny-bip39 = "0.6" | |||
yubihsm = { version = "0.22.0-alpha2", features = ["setup", "usb"], optional = true } | |||
yubihsm = { version = "0.22", features = ["setup", "usb"], optional = true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bumped this to the final release (no changes from v0.22.0-alpha2 other than the version bump):
I'm tacking the YubiHSM documentation onto this commit (in 2ae8002), with the hope I can address UX concerns encountered actually trying to run these commands at the same time. I'd appreciate any early feedback. |
2ae8002
to
8aaa1bd
Compare
Adds support directly to the KMS to make encrypted backups of keys which have been generated inside of the YubiHSM (retroactively, as there exists a similar feature as part of key generation).
Also adds a corresponding command to import the encrypted backups. There was already a
tmkms yubihsm keys import
command so this overloads the command to handle both importing existingpriv_validator.json
files (the previous functionality) and importing encrypted backups, with the former ideally going away with time.