Imagine I have a token canister, where each account is certified via the subnet signature and a Merkle-tree (the same scheme that asset canister uses to certify frontend chunks).
Imagine a user who queries for their balance and receives back the balance alongside with the Merkle proof and the whole delegation chain of keys up to the Chain Key.
When such a query request happens, from my understanding, the request first goes to some boundary node and then to some individual subnet node and then the response comes back the same way. Both of these intermediate parties could be malicious.
The attack is as follows:
- when a user queries their balance for the first time, one of the intermediate parties remembers the valid response (balance + Merkle-proof + subnet signature + delegation chain);
- the user validates the response and is now sure that everything is good;
- then the user updates their balance via, for example, depositing more funds - so the real balance is now increased;
- when the user queries for their balance again, a malicious intermediate party replays previously recorded response, instead of giving the actual one;
- the user validates the response (since all the signatures are still valid), sees that their balance didn’t change despite the deposit they made and get very upset.
I know that this is a very synthetic example. But I thought it would be simpler to explain the idea that way. You can imagine another example, when I found a bug in my frontend, that, for example, leaks private user information, so I fixed it, but intermediate parties continue to serve the leaky version of it to users, because they somehow make money with this information.
Anyway. What measures does IC perform in order to prevent this kind of situation?