Adding Statefulness to HSM Demo

[l-monninger]

Summary

Statefulness in the HSM Demo app will allow us to work on key rotation concepts in a flexible manner.

Storing an Application Public Key that can be modified independently of the cryptographic material in the signing backend would mimic many of the systems where the HSMs would be applied.

Suggested Approach

1. Create some internal state in the HSM demo app that stores a public key. Optionally, persist this state to disk.
2. Add API paths /public_key/set and /public_key/get to perform basic setting and getting operations against this public key.
3. Perform a key rotation operation and verify thereafter that the signed bytes were signed by the provided public key.

[andygolay]

So the rotation operation will be manual, and then we use the alias for setting and getting against the public key?

[andygolay]

Is the 2-PC / 3-PC approach required for this "adding statefulness" milestone?

[radupopa369]

The public_key here is to represent state outside of the signing infrastructure, i.e., in the application.

Well the public key is created when private key is created. So it kind of needs to be communicated to the application by the "secure signing" IaC pipeline

[andygolay]

For reference, here's what we have so far in PMIP-8 for a three-phase commitment:

**Phase 1: Key Preparation**

Create a new version or replica of the key.
Assign a unique identifier following the naming convention (e.g., replica-2).
Update key metadata to include a rotating status.

**Phase 2: Application Update**

Update applications to use the new key version.
Test applications to confirm successful integration.

**Phase 3: Decommissioning**

Mark the old key version as deprecated in metadata.
Restrict access to the old key for all roles except auditors.
Delete the old key after a grace period.

[l-monninger]

The 2-PCor 3-PC will be an artifact of playing with this demo app. Just add the statefulness first and go from there.

[andygolay]

Ok sounds good, will do.

[nicholasflintwillow]

@l-monninger Maybe I'm misunderstanding something here but I have one really big concern. I was under the impression we were setting up all of the key infrastructure to not store keys on machines and instead always making a call out to another service to pull them in. I especially think storing that state on disk is an anti-pattern to the secure handling of keys.

What's the justification for needing to store the keys and not just make a call out to KMS and vault whenever the application needs them?

[nicholasflintwillow]

What I've done in the past when needing to work with keys is design the signing application to require auth to AWS and anytime I needed the public or private keys that application would call out kms with the id of the key being an env var.

When these keys would need to be rotated we had a pipeline that issued a new key, updated the environment variables on the containers with the id of the new key, and then restarted the containers to make sure they had the updated id.

[l-monninger]

@mcmillennick @andygolay

You are not storing the private key on disk. Applications in our space, however, rely on a public key or derivation thereof to indicate an identity to which privileges, balances, state are attached. For example, an ETH address.

[andygolay]

@l-monninger I've created and merged PR #1001 into #986.

This adds an AppState struct containing a public_key field with the app's public key.

It can be updated with a curl request to the public_key/set endpoint:

 curl -X POST http://localhost:3000/public_key/set \
    -H "Content-Type: application/json" \
    -d '{"public_key":[136,6,216,124,249,60,46,100,190,3,189,18,232,184,5,108,135,63,20,54,18,59,30,239,51,178,34,250,219,173,171,99]}'

Look up the public key:

curl -X GET http://localhost:3000/public_key/get