You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
We need a funded account to be able to submit the extrinsic. This would be solved if we get free transactions working.
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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:
OR:
This is potentially quite a big change to our design, but right now i don't see many other options.
The text was updated successfully, but these errors were encountered: