diff --git a/protocols/BHP.md b/protocols/BHP.md index 58c735794e501cc1da2f1410e4a2fbe14cd44f6e..33b1aef50495ce413f89535536a6992c1dc37c45 100644 --- a/protocols/BHP.md +++ b/protocols/BHP.md @@ -2,9 +2,9 @@ ## 1 Introduction -Bramble Handshake Protocol (BHP) is a key agreement protocol for delay-tolerant networks. It enables two peers that have previously exchanged long-term public keys to establish an ephemeral shared secret that is not known to any other party. +Bramble Handshake Protocol (BHP) is a key agreement protocol for delay-tolerant networks. It enables two peers that have previously exchanged long-term public keys to establish an ephemeral shared secret key that is not known to any other party. -BHP is designed to be used with Bramble Transport Protocol (BTP) in handshake mode. The shared secret produced by BHP can be used to derive a root key for upgrading BTP to transport mode, which provides forward secrecy. +BHP is designed to be used with Bramble Transport Protocol (BTP) in handshake mode, which does not provide forward secrecy. The shared key produced by BHP can be used to upgrade BTP to transport mode, which provides forward secrecy. BHP can operate over any connection-oriented, bidirectional transport protocol. @@ -20,7 +20,7 @@ BHP does not rely on lower protocol layers to provide confidentiality, integrity Before two peers can communicate using BHP they must exchange long-term public keys. BHP does not specify how this should be done. Any synchronous or asynchronous communication channel can be used, subject to the caveat that if an adversary can replace the keys being exchanged then the adversary can carry out a man-in-the-middle attack against BHP. -The peers must also establish a connection over a bidirectional transport. Each peer needs to know which peer it's connected to so it can use the appropriate long-term public key for authenticating the other peer. When BHP is used with BTP in handshake mode, BTP enables the peers to identify each other so they can look up the appropriate long-term public keys. If BHP is used without BTP then some other means must be used to determine which long-term public key to use for authenticating the peer. +The peers must also establish a connection over a bidirectional transport. Each peer needs to know which long-term public key to use for authenticating the other peer. When BHP is used with BTP in handshake mode, BTP enables the peers to identify each other so they can look up the appropriate long-term public keys. If BHP is used without BTP then some other means must be provided to determine which long-term public key to use. The peers take the roles of **Alice** and **Bob** according to the lexicographic order of their long-term public keys, compared as byte strings. The peer with the earlier key plays the role of Alice, while the peer with the later key plays the role of Bob. The roles are symmetrical except for the order of the protocol steps. @@ -82,8 +82,8 @@ The protocol has four steps: 1. Alice generates an ephemeral key pair and sends an EPHEMERAL\_PUBLIC\_KEY record 2. Bob generates an ephemeral key pair and sends an EPHEMERAL\_PUBLIC\_KEY record -3. Alice derives the master key and sends a PROOF\_OF\_OWNERSHIP record -4. Bob derives the master key and sends a PROOF\_OF\_OWNERSHIP record +3. Alice derives the shared secret and sends a PROOF\_OF\_OWNERSHIP record +4. Bob derives the shared secret and sends a PROOF\_OF\_OWNERSHIP record ### 2.3 Key Derivation @@ -101,9 +101,11 @@ Bob calculates three "raw" shared secrets as follows: (*Note:* If a peer calculates an X25519 raw shared secret that is all zeroes, the peer must abort the protocol.) -If the adversary did not intercept the prior exchange of long-term public keys and has not modified the EPHEMERAL\_PUBLIC\_KEY records then both peers will calculate the same shared secrets. The peers then derive a "cooked" shared secret known as the **master key**, which incorporates both peers' long-term and ephemeral public keys: +If the adversary did not intercept the prior exchange of long-term public keys and has not modified the EPHEMERAL\_PUBLIC\_KEY records then both peers will calculate the same shared secrets. The peers then derive a "cooked" shared secret known as the **ephemeral master key**, which incorporates both peers' long-term and ephemeral public keys: -- master\_key = HASH("org.briarproject.bramble.handshake/MASTER\_KEY", raw\_static, raw\_static\_ephemeral, raw\_ephemeral\_static, pub\_long\_term\_a, pub\_long\_term\_b, pub\_ephemeral\_a, pub\_ephemeral\_b) +- ephemeral\_master\_key = HASH("org.briarproject.bramble.handshake/MASTER\_KEY", raw\_static, raw\_static\_ephemeral, raw\_ephemeral\_static, pub\_long\_term\_a, pub\_long\_term\_b, pub\_ephemeral\_a, pub\_ephemeral\_b) + +The peers must then delete their ephemeral private keys and the raw shared secrets, allowing the calling application to use the master key for forward secret communication if required. ### 2.4 Proof of Ownership @@ -111,8 +113,10 @@ The master key depends on both peers' long-term and ephemeral public keys, as we Each peer calculates its own proof and the proof it expects to receive from the other peer. If the proof received from the other peer differs from the expected proof then the peer must abort the protocol. -- alice\_proof = MAC(master\_key, "org.briarproject.bramble.handshake/ALICE\_PROOF") -- bob\_proof = MAC(master\_key, "org.briarproject.bramble.handshake/BOB\_PROOF") +- alice\_proof = KDF(ephemeral\_master\_key, "org.briarproject.bramble.handshake/ALICE\_PROOF") +- bob\_proof = KDF(ephemeral\_master\_key, "org.briarproject.bramble.handshake/BOB\_PROOF") + +If the proof received from the other peer matches the expected proof, BHP returns the master key to the calling application, together with the open transport connection and a flag indicating whether the peer played the role of Alice or Bob. The application may use the master key and flag to derive keys for communicating securely over the transport connection, or for any other purpose. ## 3 Man-in-the-Middle Attacks