Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attestation problems when restarting entropy-tss nodes #1214

Open
ameba23 opened this issue Dec 12, 2024 · 1 comment
Open

Attestation problems when restarting entropy-tss nodes #1214

ameba23 opened this issue Dec 12, 2024 · 1 comment
Milestone

Comments

@ameba23
Copy link
Contributor

ameba23 commented Dec 12, 2024

Currently we persist the TSS mnemonic (from which account ID and x25519 keypair are derived) to disk.

Since these are used in attestation, it is important that they are generated in the trusted domain and never leave. Even if / when we figure out how to do encryption with the hardware key, we still cannot have these keypairs survive a VM reboot, as there could be some manipulation of the VM image while it is down, and we wouldn't know until we did another attestation.

For this reason i think we need to have these secret keys be stored only in memory and re-generated every time entropy-tss launches. This means we need to automate the process by which the new public keys are submitted to the chain - as we cannot expect the node operator to be around all hours of the day checking if the server has rebooted for some reason.

That is, as soon as entropy-tss starts, it should be able to submit an extrinsic with its TSS account ID and x25519 public key. There are two issues here:

  1. We need a funded account to be able to submit the extrinsic. This would be solved if we get free transactions working.
  2. The chain needs to know which stash account the TSS details should be associated with. Currently it knows this because the validator operator uses their stash account to submit the extrinsic.

The tricky thing about (2) is that the TSS node cannot know itself which stash account it is associated with. We can't include this information by customising the VM image, because ideally any change to the VM image will result in different measurements being used in the attestation (although we still haven't figured this part out and maybe there will be a way we can).

My proposal is that we have a local network service running as part of the chain node which the TSS node can communicate with. We can use QEMU guest forwarding to ensure that this service is only exposed to the confidential virtual machine and not accessible publicly.

This service would verify a quote from the TSS server, and then either:

  • Send a small amount of funds to it from the stash account so that the TSS server is able to submit extrinsics. Like a mini-faucet which is only exposed locally.
    OR:
  • Submit extrinsics from the stash account on behalf of the TSS server, meaning the TSS server itself doesn't need to hold funds.

This is potentially quite a big change to our design, but right now i don't see many other options.

@github-project-automation github-project-automation bot moved this to 📋 Backlog in Entropy Core Dec 12, 2024
@ameba23 ameba23 added this to the v0.4.0 milestone Dec 12, 2024
@ameba23 ameba23 moved this from 📋 Backlog to 🏗 In progress in Entropy Core Dec 12, 2024
@ameba23 ameba23 moved this from 🏗 In progress to 🌝 Soon in Entropy Core Dec 12, 2024
@ameba23
Copy link
Contributor Author

ameba23 commented Dec 13, 2024

Update to this following discussion in yesterdays core sync.

It seems under certain conditions its possible to force a balance transfer without a signature. So it would be an option that the validator operator can recover the balance from a TSS account after the private key has been lost following a CVM reboot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🌝 Soon
Development

No branches or pull requests

1 participant