keymanager: Validate latest trust root height in key manager requests #4910
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Key manager requests should include latest consensus trust root
The key manager protocol should add the latest known trust root (or just the height) to (private key) EnclaveRPC requests. This would allow the key manager to detect whether the runtimes querying it have a fresh enough state (e.g. within 50 blocks) and reject operations if not.
Obviously the bad view can be either on the key manager side (Byzantine key manager operator) or the runtime side (Byzantine runtime operator). In case the key manager node is Byzantine the runtime can just switch to a different one (this already happens automatically when key manager requests fail).
This should be supported in a backwards compatible manner by making the new field optional.
Test
Happy path is already covered with e2e tests. Unhappy path was tested locally.
height
is not sent and after decoding takes a default value ofNone
. Validation is skipped.height
is lower than trust root's height, the client will receive an error, e.g.private ephemeral key not available: call failed: height is not fresh
.height
but it will not decode properly. The client will again receive an error, e.g.private ephemeral key not available: call failed: unknown field
.