Authors: 🟢 @Daniel Sanchez Quiros

Reviewers: 🟢 @Youngjoon Lee 🔴 @Gusto Bacvinka

Introduction

Coming from Notes on KMS (Key Management System) discussion.

Nomos nodes must handle a set of keys for identification, signatures, and other encryption mechanisms.

The common and naive approach is to let the key where you need to use it. But this is not suitable for the following reasons:

• Keys may be duplicated and/or spread across different code locations
• It isn't easy to track the lifecycle of the keys (loading, usage, and free)
• It doesn’t fit with the rest of the node architecture
• more difficult to change, adapt, or refactor if any deviation needs to be made

Most Nomos components are divided into independent units that handle specific node behaviors. Key management shouldn’t be any different.

Requirements

KMS will fill the following characteristics:

• N Secrets are loaded from settings.
  • They can be loaded either from disk or environment variables.
  • In the future, if needed, we can enhance this by loading a single master secret from the settings and deriving keys from it using key paths.
• Secrets are clear from memory when not used (zeroize on drop is a good example).
  • This is a common security hygiene procedure.
• Access is centralized, meaning that the KMS will be the only one responsible for secrets.
  • Sharing the secrets to external services should be avoided. API should ensure that secrets are not accessed, moved, cloned, or copied anywhere outside the intended blocks.
• Keys have a human-readable identification that is used to distinguish them.
  • Since keys reside in a single place, they need to be differentiated somehow. Both for debugging purposes and ease of use.

Design

The system performs the following operations:

• Register key with the given key Id and type X (for example bls, secp, or any other supported)
  • A key is either loaded or generated based on the provided key Id and key type X. The logic depends on the implementation of the KMS backend.
  • The provided key Id is returned as a hook to operate with it later.
  • In case the key is not present or cannot be registered for any reason, this is a blocking path and the node should not start.