Skip to content

Conversation

@waynenilsen
Copy link
Contributor

Motivation

We currently use in memory keys for the Attestation key. While these keys are injected via an encrypted channel it is still not an ideal scenario. HSMs provide the highest level of security for private key management. In the AWS ecosystem, KMS provides a very cheap layer on top of HSMs with access managed by IAM roles.

Importantly, the key material can never leave the HSMs. This is a step in the direction of using HSMs to sign transactions inside nocturne services.

Solution

Introduce local-kms into our docker-compose file. This will allow us to interact with KMS using the same tools that we will use in AWS but for local dev.

We will likely allow in memory keys for backward compatibility and simplicity in local environments.

Proof

image

PR Checklist

  • [n/a] added tests
  • [n/a] updated documentation
  • [n/a] added changeset if necessary
  • [n/a] tested in dev/testnet
  • [n/a] tested site with snap (we haven't automated this yet)
  • [n/a] re-built & tested circuits if any of them changed
  • [n/a] updated contracts storage layout (if contracts were updated)

## Motivation

We currently use in memory keys for the Attestation key. While these
keys are injected via an encrypted channel it is still not an ideal
scenario. HSMs provide the highest level of security for private key
management. In the AWS ecosystem, KMS provides a very cheap layer on
top of HSMs with access managed by IAM roles.

Importantly, the key material can never leave the HSMs. This is a step
in the direction of using HSMs to sign transactions inside nocturne
services.

## Solution

Introduce local-kms into our docker-compose file. This will allow us to
interact with KMS using the same tools that we will use in AWS but for
local dev.

We will likely allow in memory keys for backward compatibility and
simplicity in local environments.

## Proof

WIP

## PR Checklist

- [n/a] added tests
- [n/a] updated documentation
- [n/a] added changeset if necessary
- [n/a] tested in dev/testnet
- [n/a] tested site with snap (we haven't automated this yet)
- [n/a] re-built & tested circuits if any of them changed
- [n/a] updated contracts storage layout (if contracts were updated)
@changeset-bot
Copy link

changeset-bot bot commented Oct 20, 2023

⚠️ No Changeset found

Latest commit: d9b45fc

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant