feat: KMS BlockSigner by sergerad · Pull Request #1677 · 0xMiden/node

sergerad · 2026-02-16T02:54:11Z

Context

The genesis bootstrap and validator processes currently only support ECDSA private keys via command line. We want to be able to perform genesis and validator block signing through more secure, remote backends such as AWS KMS.

Relates to #1316.

Tested locally against AWS KMS (both bootstrap and chain running with separate validator).

Changes

Add BlockSigner trait (removed from miden-base).
Add KmsSigner struct which implements BlockSigner.
Update all command scaffolding to allow for bootstrap command and validator command to use either local key or KMS key.
Bump toolchain to Rust 1.91 (for latest aws SDK support).

…gning-backend

bin/node/src/commands/bundled.rs

bin/node/src/commands/mod.rs

CHANGELOG.md

crates/validator/src/signers/kms.rs

Mirko-von-Leipzig · 2026-02-19T09:55:36Z

crates/validator/src/block_validation/mod.rs

    UnvalidatedTransactions(Vec<TransactionId>),
    #[error("failed to build block")]
-    BlockBuildingFailed(#[source] ProposedBlockError),
+    BlockBuildingFailed(#[from] ProposedBlockError),


Suggested change

BlockBuildingFailed(#[from] ProposedBlockError),

BlockBuildingFailed(#[source] ProposedBlockError),

We really should not use #[from]. It makes it too easy to cast things incorrectly.

Yea sorry I have been stubborn about this. Any references you have for me to look at on that topic? Like linters/style guides. If we have consensus about not using #[from] at all I'll make sure not to in the future.

I don't think we have anything explicitly about this; we had this general error discussion 0xMiden/protocol#966, maybe @PhilippGackstatter has one for #[from] vs `#[source]?

I think this blog post motivates adding context well: https://fast.github.io/blog/stop-forwarding-errors-start-designing-them/. In particular the "The Problem: Error Handling Without Purpose" section:

When debugging, does “serialization error: expected , or }” tell you which request, which field, which code path led here?

#[source] is better than #[from] because it forces you to give some thought on how to best add context.

Thanks yea the article is insightful.

#[source] is better than #[from] because it forces you to give some thought on how to best add context.

I agree with the notion that it could prompt you to add more context. But I don't think it ensures that. And I don't think it is necessary to achieve the goal of ensuring context being added when it is needed or formatting errors in such a way that they dont just forward/bubble up info.

Have updated the PR to use #[source] in any case!

crates/store/src/genesis/mod.rs

crates/utils/src/signer.rs

Mirko-von-Leipzig · 2026-02-19T10:02:14Z

crates/utils/src/signer.rs

+    async fn sign(&self, header: &BlockHeader) -> Result<Signature, Self::Error> {
+        Ok(self.sign(header.commitment()))
+    }


Is this not a blocking operation? How long does signing take?

Its async only because of the trait definition

Yes but we shouldn't make blocking calls in an async function. Apparently we can expect this to take a few ms to maybe 100ms which is high but probably acceptable for us.

Its the downside of having this trait -- it doesn't really match reality; one call is async IO, the other is local blocking sync function.

So really this should be doing something like

tokio::task::block_in_place(self.sign(header.commitment())).await

but that isn't great either.

Mirko-von-Leipzig · 2026-02-19T10:07:18Z

crates/validator/src/signers/kms.rs

+    type Error = KmsSignerError;
+
+    async fn sign(&self, header: &BlockHeader) -> Result<Signature, Self::Error> {
+        // KMS backend doesn't support Keccak-256 so we do it ourselves.


Could you expand on what this means?

Updated - anything still unclear?

// AWS KMS does not support SHA3 (Keccak-256), so we need to produce the digest ourselves.

Yes - I don't know how to produce such a digest. Is there an algorithm you followed, or how did you know what to do?

Currently I'm just taking it as being okay; but you could really have written any algorithm here and I wouldn't know any different.

aka how can I audit this code to ensure its correct.

How about now?

// The Validator produces Ethereum-style ECDSA (secp256k1) signatures over Keccak-256 // digests. AWS KMS does not support SHA-3 hashing for ECDSA keys // (ECC_SECG_P256K1 being the corresponding AWS key-spec), so we pre-hash the // message and pass MessageType::Digest. KMS signs the provided 32-byte digest // verbatim.

…gning-backend

bin/node/src/commands/mod.rs

Mirko-von-Leipzig · 2026-02-20T07:02:44Z

bin/node/src/commands/mod.rs

+#[group(required = true, multiple = false)]
+pub struct ValidatorKey {


Have you tested that this works as expected? The default with an optional and group required sounds like it might be wonky. I think its correctly defined, I'm just curious whether clap handles this properly.

❮ ./target/debug/miden-node validator start --data-directory /tmp/1 http://0.0.0.0:9191 --key.kms-id bded4b64-636a-4d27-8475-c2b8f8e76e75 --key.hex asdf error: the argument '--key.kms-id <VALIDATOR_KMS_KEY_ID>' cannot be used with '--key.hex <VALIDATOR_KEY>'

❯ ./target/debug/miden-node bundled bootstrap --validator.key.hex asdb --validator.key.kms-id asdf error: the argument '--validator.key.hex <VALIDATOR_KEY>' cannot be used with '--validator.key.kms-id <VALIDATOR_KMS_KEY_ID>'

Mirko-von-Leipzig · 2026-02-20T07:07:58Z

bin/node/src/commands/validator.rs

+        /// Cannot be used with `key.kms-id`.
+        #[arg(
+            long = "key.hex",
+            env = ENV_VALIDATOR_KEY,
+            value_name = "VALIDATOR_KEY",
+            default_value = INSECURE_VALIDATOR_KEY_HEX,
+            group = "key"
+        )]


Ah. And you have to repeat because its a different arg prefix?

We should take a look at conf which builds on top of clap-derive but seems less weird around use cases like this.

But for now this is fine 👍

Mirko-von-Leipzig · 2026-02-20T07:13:44Z

crates/validator/src/block_validation/mod.rs

    UnvalidatedTransactions(Vec<TransactionId>),
    #[error("failed to build block")]
-    BlockBuildingFailed(#[source] ProposedBlockError),
+    BlockBuildingFailed(#[from] ProposedBlockError),


I don't think we have anything explicitly about this; we had this general error discussion 0xMiden/protocol#966, maybe @PhilippGackstatter has one for #[from] vs `#[source]?

crates/utils/src/signer.rs

Mirko-von-Leipzig · 2026-02-20T07:21:26Z

crates/validator/src/signers/kms.rs

+    type Error = KmsSignerError;
+
+    async fn sign(&self, header: &BlockHeader) -> Result<Signature, Self::Error> {
+        // KMS backend doesn't support Keccak-256 so we do it ourselves.


Yes - I don't know how to produce such a digest. Is there an algorithm you followed, or how did you know what to do?

Currently I'm just taking it as being okay; but you could really have written any algorithm here and I wouldn't know any different.

Mirko-von-Leipzig · 2026-02-20T07:21:55Z

crates/validator/src/signers/kms.rs

+    type Error = KmsSignerError;
+
+    async fn sign(&self, header: &BlockHeader) -> Result<Signature, Self::Error> {
+        // KMS backend doesn't support Keccak-256 so we do it ourselves.


aka how can I audit this code to ensure its correct.

Mirko-von-Leipzig · 2026-02-20T07:22:13Z

crates/utils/src/signer.rs

+    async fn sign(&self, header: &BlockHeader) -> Result<Signature, Self::Error> {
+        Ok(self.sign(header.commitment()))
+    }


Yes but we shouldn't make blocking calls in an async function. Apparently we can expect this to take a few ms to maybe 100ms which is high but probably acceptable for us.

Its the downside of having this trait -- it doesn't really match reality; one call is async IO, the other is local blocking sync function.

So really this should be doing something like

tokio::task::block_in_place(self.sign(header.commitment())).await

but that isn't great either.

Mirko-von-Leipzig · 2026-02-20T07:26:09Z

bin/node/src/commands/store.rs

+        let signer = validator_key.into_signer().await?;
+        match signer {
+            ValidatorSigner::Kms(signer) => {
+                Self::bootstrap_with_signer(config, signer, accounts_directory, data_directory)
+                    .await
+            },
+            ValidatorSigner::Local(signer) => {
+                Self::bootstrap_with_signer(config, signer, accounts_directory, data_directory)
+                    .await
+            },
+        }
+    }
+
+    async fn bootstrap_with_signer(
+        config: GenesisConfig,
+        signer: impl BlockSigner,


Maybe &dyn would make it easier?

Suggested change

let signer = validator_key.into_signer().await?;

match signer {

ValidatorSigner::Kms(signer) => {

Self::bootstrap_with_signer(config, signer, accounts_directory, data_directory)

.await

},

ValidatorSigner::Local(signer) => {

Self::bootstrap_with_signer(config, signer, accounts_directory, data_directory)

.await

},

}

}

async fn bootstrap_with_signer(

config: GenesisConfig,

signer: impl BlockSigner,

let signer = validator_key.into_signer().await?;

Self::bootstrap_with_signer(config, &signer, accounts_directory, data_directory).await

}

async fn bootstrap_with_signer(

config: GenesisConfig,

signer: &dyn BlockSigner,

Unfortunately the associated (Error) type is problematic for trait object

the value of the associated type `Error` in `miden_node_utils::signer::BlockSigner` must be specified

We can look at removing the trait instead after this PR maybe.

CHANGELOG.md

crates/validator/Cargo.toml

…gning-backend

sergerad added 2 commits February 16, 2026 12:30

Add signers bump to 1.91

539e82f

Basic impl on current trait

51542fa

sergerad mentioned this pull request Feb 16, 2026

chore: Remove BlockSigner trait 0xMiden/protocol#2447

Merged

sergerad added 18 commits February 17, 2026 11:42

Add BlockSigner trait and update kms pub key logic

1a78747

Merge branch 'next' of github.com:0xMiden/miden-node into sergerad-si…

cf3d33d

…gning-backend

Changelog

bcf8ee6

Fix merge

8a510e2

Merge branch 'next' of github.com:0xMiden/miden-node into sergerad-si…

008bb5c

…gning-backend

command and kms error

1ebd952

RM clones

1dd7271

pub key der decode

daaf555

update bootstrap

05628b1

e2e working needs cleanup

6b85c15

Cleanup

73d52fd

More cleanup

b7dfece

Lint

939ecce

key id env

5f493ca

Machete

fef2deb

Dedupe

20467c6

typo

548eb0f

Dockerfile

8958797

sergerad marked this pull request as ready for review February 19, 2026 00:57

sergerad requested review from Mirko-von-Leipzig, bobbinth and igamigo February 19, 2026 00:59

Mirko-von-Leipzig reviewed Feb 19, 2026

View reviewed changes

sergerad added 4 commits February 20, 2026 06:44

Update comment

4e4239b

Add validator signer enum

f362668

anyhow context

6d96d51

fix changelog

23aaf30

sergerad added 2 commits February 20, 2026 12:19

RM block_on

77dcb9d

Merge branch 'next' of github.com:0xMiden/miden-node into sergerad-si…

38f34c3

…gning-backend

sergerad requested a review from Mirko-von-Leipzig February 20, 2026 00:45

Mirko-von-Leipzig approved these changes Feb 20, 2026

View reviewed changes

mmagician mentioned this pull request Feb 20, 2026

chore: migrate to base 0904e2c61 #1691

Open

sergerad added 4 commits February 23, 2026 11:32

Source not from

e307582

Update hashing comment

f3e0c55

reword

3272750

Fix flag

f284675

bobbinth reviewed Feb 22, 2026

View reviewed changes

crates/validator/Cargo.toml Show resolved Hide resolved

sergerad added 2 commits February 23, 2026 12:02

Changelog

9a27006

RM more #[from]

d35c8e4

sergerad force-pushed the sergerad-signing-backend branch from 34a4837 to d35c8e4 Compare February 23, 2026 00:06

Merge branch 'next' of github.com:0xMiden/miden-node into sergerad-si…

647c3e5

…gning-backend

sergerad mentioned this pull request Feb 23, 2026

Guardrails: Tx and Block Validation #1316

Open

12 tasks

sergerad added 3 commits February 24, 2026 14:39

Use from_der

dfa4712

Merge branch 'next' of github.com:0xMiden/miden-node into sergerad-si…

8f04063

…gning-backend

Improve comments and fix merge

6e4126a

sergerad requested a review from bobbinth February 24, 2026 02:06

	BlockBuildingFailed(#[from] ProposedBlockError),
	BlockBuildingFailed(#[source] ProposedBlockError),

		#[group(required = true, multiple = false)]
		pub struct ValidatorKey {

Comments

Conversation

sergerad commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context

Changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sergerad Feb 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

sergerad commented Feb 16, 2026 •

edited

Loading

sergerad Feb 22, 2026 •

edited

Loading