Is env.message.sender legit? Txs replay in a fork?

Secret Contracts and Secret Apps
#1

Hello everyone, I wonder whether the env.message.sender is legit and secure to be checked?
To return sensitive information based on a specific address only?
I see everywhere “secret passwords” / “viewing keys” are used in an input, if so, what is it’s purpose?
Or forking a chain and pretending to be any address is possible?

Another question, does transactions replay in a forked chain is possible?
If so, an attacker could probably replay all the txs and get to a state on a non-SGX (or tweaked) machine?

1 Like
#2

Yes, env.message.sender is legit and can be used securely inside contracts.

The returned result is decryptable only by env.message.sender, so you can return sensitive information addressed only to env.message.sender.

Viewing keys are used in queries, which are not singed and therefore the query sender can not be verified. Viewing keys are essentially passwords, we called them viewing keys in snip20 tokens because they are used to view your balance.

You cannot fork the chain and pretend to be another address, because you won’t be able to sign as this address and the chain and contracts won’t accept messages from you. Even if you modify the chain, you cannot modify the enclave.

Transaction repay in a forked chain is possible but you won’t be able to decrypt the input of the output of the transaction.

1 Like
#3

And if you try to run a forked chain without the SGX module, you won’t be able to execute transactions that were encrypted with keys intended to be decrypted inside SGX.

1 Like
#4

keep in mind though that depending on what queries and “handles” the contracts expose, replay attacks can still be a risk vector.
Just as an example, a voting contract must protect from partial replay attacks.
Some mechanism needs to be put in place by the contract to prevent exposing someone’s vote by replaying the entire vote-set, without the one vote you want to deanonymize.
This is possible if for example if the contract exposes an exact statistic on how many votes each option received. A possible solution (which isn’t great) is to require each vote mentions who the previous voter was, and have the vote admin close the vote with a message that mentions the last voter. That way replays can not be tampered with. Another solution might be to not expose precise statistics, but that’s not perfect either, especially for small voter sets

1 Like
#5

Thank you for taking time to answer my questions.

@assafmo
You said that viewing keys are used in queries which are not signed, I thought that any query/tx to secret smart contract is signed and input/output is encrypted. Isn’t it? Or queries are not signed because they are not transactions actually?

@reuven
Good point! Attack vectors are diversified.

1 Like
#6

Like you said, queries are not transactions, and are not saved on-chain. However, their inputs and outputs are still encrypted with a kind of session key that only the client knows.

@assafmo I think handles work that way too, right? the message is signed by the sender, which is authenticated in the enclave, but it’s encrypted with the session key, not with the account’s private key?

1 Like
#7

If so, env.message.sender is not trusted on Query… right? Hence you use passwords, did I get it right?

1 Like
#8

env.message.sender does not exist on Query as queries are anonymous. This is why we use passwords.

1 Like
#9

You’re correct. Queries are not signed because they are not transactions. They are encrypted, so only the query sender can decrypt the output.

1 Like
#10

Thank you very much for your assistance!
I demystified several things for me :slight_smile:

1 Like