Copay peer handshake

gistfile1.txt

Alice             Bob
=================================================
                  .generates Extended PrivKey, PubKey
                  CopayerId=pubkey
                  PeerId=hash(CopayerId)
                  
                  PeerID is provided to the PeerJS/WebRTC
                  P2P facilitator server
          
                  .Connects server with PeerId.
                  .Sends CopayerId to Alice 
                  using an off channel.

.generates Extended 
PrivKey, PubKey
CopayerId=pubkey
PeerId=hash(CopayerId)

.Connects server with PeerId.
BobPeerId = hash(CopayerId)

.Asks for a Bob's p2p channel
to the server using BobPeerId

                  .receives connection request

.sign a "HELLO" 
using HMAC / Bob's
pubkey. See its
pubkey ring.

                  .check sig of HELLO.
                  
                  start signing messages using ECDSA
                  and checking Alice message using her
                  public key.
                  
Only the HELLO message is signed/verified using HMAC. 
Then all messages are signed using ECDSA.

This attemps to remove the need of trust from 
the PeerJS server.

So the message from Alice to Bob is HMAC-signed with Bob's public key, which only Alice knows. I assume this is the extended public key, and not the regular public key. This allows Bob to know that it is indeed Alice that is connecting.

I still have a concern over encryption. I'm not convinced WebRTC does this correctly. If each person doesn't already know each other's public keys, and the peerjs server is required to establish the original, unauthenticated p2p connections, what's to stop them from redirecting traffic to the wrong place and doing a MITM attack? I think once we share the public keys, we should use them to sign and encrypt data, so that no MITM attack is possible.

• The initial exchange using HMAC in the HELLO message is only to allow Bob to send an authenticated message
  to Alice, so it is only the pubkey (not extended).
• Once both parties are authenticated, the extended pub keys are shared using PubKeyRing.

Encryption should be easy to implement once we have EC encryption support on bitcore (bitpay/bitcore#287), and using the same pubkeys for signing and encrypting data.