Session Keys on Ten Gateway #2024
Conversation
|
Confused at how this works in the EVM side, do we somehow bypass the requirement for the EOA to have signed the transaction or will the actual on-chain battleship transactions have come from the account associated with the SK? I guess with this working then stealing the user's ID from their gateway URL is now more valuable than just read-only data. But the user is only risking the value that they have transferred in the pre-pay transaction of course. |
the latter. This is why we need to link the SK accounts to the main EOA on the enclave db.
Correct. I need to mention this. If the user loses the userid, then they lose that small amount. |
|
Ah ok, so the EOA owner is able to view information about its SK's transactions because the enclave knows they are linked, even after the SK has been deleted. So making sure the benefits of the transactions (prize tokens or whatever) go back to the EOA rather than accruing to the SK's acc would be the responsibility of the dapp developer (doesn't need to happen at a contract level though, could be done by having the front-end make the transactions to send things to the EOA separately). |
correct.
yeah, should be the responsibility of the dapp developer, who knows what this user has done during the game. You could in theory handcraft the transaction to transfer it back to the eoa, and ask the TG to sign, if the dapp crashes |
tudor-malene
changed the title
|
|
||
| The game will call `/session_key/activate/${sk_account}` | ||
|
|
||
| After the initialisation, the game will create unsigned move transactions and submit them to the TG. |
There was a problem hiding this comment.
Maybe worth saying explicitly how that tx part works, I guess it's like /session_key/submit_tx or something? And the payload is similar to eth_sendRawTransaction.
There was a problem hiding this comment.
in my mind it would be a normal transaction, sent via the normal rpc. Only that the signature fields are 0 or something
There was a problem hiding this comment.
Ah ok fair, yeah if the wallets let you do that then that'd work nicely
|
|
||
| #### Reuse | ||
|
|
||
| If the user already has a session key, the game can retrieve it with `/session_key/list`. This will return a list of `address, amount`. |
There was a problem hiding this comment.
I've just realised there's a bit of a security issue here. We have an rpc method that returns the user ID, which means if someone makes a webpage with a 'Connect wallet' button then it can:
- request userID
- request list of session keys for that user ID
- submit unsigned transactions to drain their balances
Possible solutions that spring to mind:
-
Remove query method that returns the user's ID, require all communcation to go via MM RPC without leaking the userID/RPC address (not sure if this is feasible with the initial signing part...)
-
Restrict the transactions that a session key can make. For example, when you call
/session_key/createyou could require a contract address be included in the request body and limit that session_key to creating transactions to that address. This would prevent anyone that knows the userID from draining the funds directly.
There was a problem hiding this comment.
Tbh I think number 1 needs to be seriously considered because even without session keys this means that whenever you connect your wallet to an app you risk them snooping through your 'private' tx data.
There was a problem hiding this comment.
Another option is that userIDs could be sessioned. If you make a request to a user ID from a different IP or after a long period of time then you're forced to re-authenticate with your EOA signature...
There was a problem hiding this comment.
Tbh I think number 1 needs to be seriously considered because even without session keys this means that whenever you connect your wallet to an app you risk them snooping through your 'private' tx data.
yeah, totally. I was thinking the same
Why this change is needed
We want to support no-click UXs