search

WalletConnect / WCIPs

WalletConnect Improvement Proposals
13 stars 5 forks source link

WCIP-9: Asymmetric Initial Key Exchange #9

Open pedrouid opened 5 years ago

pedrouid commented 5 years ago

As a result of the discussion of the proposal #2 for refactoring the key exchange flow for WalletConnect v1.0 protocol, it was clear that the complexity for adding a key exchange during a session on the current protocol architecture was not sufficiently secure and introduced the chance for race conditions for payloads sent during the key exchange.

Therefore the solution would be to introduce an initial key exchange before the session is established. Because this would be a significant breaking change to the current v1.0 protocol, it will only be introduced on the v2.0 protocol.

The idea is to generate an asymmetric key pair from the initiating peer, A,(usually a Dapp) and provide its public key using the URI schema for WalletConnect through an "offline" method such as a QR Code or Deep Link.

The counter peer, B, will be able to generate a symmetric key for communication and include its own peerId (or a one time handshake topic) to receive the session request. The peer A will receive the payload including (peerId + symKey) encrypted with its own pubKey and will be able to decrypt it with the privKey.

At this point the peer A can now create a session request and encrypt it securely with the symKey only known by the peer B. Then the peer B will be able to respond with the session approval or rejection and the rest of the communication should follow as previously with v1.0 protocol.

pedrouid commented 5 years ago

walletconnect-v2-key-exchange

rmeissner commented 5 years ago

The previous proposal allowed to change the SymKey at any point in time, would this still be the case here?

pedrouid commented 5 years ago

The previous proposal allowed to change the SymKey at any point in time, would this still be the case here?

That could be open for discussion. On the WCIP-2 we discussed that we didn't have in place a way to determine wether payloads were sent before or after the key exchange which could lead to payloads being unable to be decrypted.

In this proposal, we exchangeKeys before sending any payloads at all. But if we had the ability to perform a key exchange in the middle of the session, then we would need to determine how to track which payloads were encrypted with the previous key or the new one.

For the sake of simplicity, I would scope this proposal within only the initial key exchange that happens before the session is established. Therefore it only concerns with protecting from symKey which is currently exposed through a QR Code or Deep Link.

However it could be useful to create a new proposal to exchange keys during the session to protect persisted keys in browser implementations from cross-site scripting.