Running the chain node outside of TDX causes potential malicious problems

[JesseAbram]

The TSS being locked down in TDX is awesome and solves a lot of problems, however the chain node is currently passing messages into the TSS from outside the enclave.

Specifically in one scenario this brings up an issue. In sign_tx if a malicious operator is able to mock the chain and send a message that says sign this and replace the programs it pulls down it can force a signature that should not sign.

This is a really insanely hard attack as it would have to control a relayer and a T of signers (or all the signers since the relayer randomly selects the T) (also to note the signers looks to the chain to get the relayer).

Potential Solutions

• require a signature with the sign_tx that is also tied to the derivation path (but this significantly hurts the UX
• run the chain node in the enclave as well @ameba23 really want your input there
• select the endpoint the tss talks to (centralized and hard to update)

This is problem is important but not a full blocker to launch

[ameba23]

If having the chain node running in an enclave - my initial thought was to have it in a separate one to the TSS, to minimise how many open ports we need to have.

But the problem becomes how to do the attestation - we then need a separate identity and attestation mechanism for the chain node.

So if so i would have a single enclave with both chain node and TS server. I can't think of a reason why this wouldn't work. Possible concerns would be performance of runnning in a VM, and storage issues.

[ameba23]

@HCastano suggested we could have the TS server get extra chain endpoints by using the same libp2p-based discovery mechanism that the chain node uses (a kademlia DHT), in order to be able to randomly select one from a large set when making queries.

I think this is a promising solution definitely worth looking into.

Although it does just move the problem from having a hard-coded chain endpoint to having hard-coded DHT bootstrap nodes. And you would have the same problem if having the chain node inside the enclave. I think it is impossible to avoid some having centralization here - somewhere you need to have one or more trusted chain endpoint(s) as a starting point.

In terms of how we would actually implement this, im not sure whether we could use sc-authority-discovery directly as some of the traits it requires you to implement have substrate specific methods like best_hash(). But having looked at its implementation of Worker i think it would be not too difficult to write something similar if it turns out too complicated to implement those traits without having an internal chain client.