Commit 37538637 authored by akwizgran's avatar akwizgran
Browse files

Add discussion of MITM attacks.

parent 5e3666b9
......@@ -6,15 +6,15 @@ Bramble Handshake Protocol (BHP) is a key agreement protocol for delay-tolerant
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 can operate over any connection-oriented, bidirectional transport protocol. Unidirectional transports are not suitable for BHP.
BHP can operate over any connection-oriented, bidirectional transport protocol. Unidirectional transports are not suitable.
### 1.1 Adversary Model
We assume the adversary can observe, block, delay, replay and modify traffic on all underlying transports.
We do not assume the peers exchanged their long-term public keys over a secure channel. If the adversary intercepted the prior exchange of public keys and replaced them with its own public keys then BHP does not detect or prevent man-in-the-middle attacks. If the adversary knows both peers' long-term public keys but did not replace them during the prior exchange then BHP prevents man-in-the-middle attacks.
We do not assume the peers exchanged their long-term public keys over a secure channel. If the adversary intercepted the prior exchange of long-term public keys and replaced them with its own public keys then BHP does not detect or prevent man-in-the-middle attacks. If the adversary knows both peers' long-term public keys but did not replace them during the prior exchange then BHP prevents man-in-the-middle attacks.
BHP does not rely on lower protocol layers to provide confidentiality, integrity, authenticity or forward secrecy. If the traffic between peers needs to be indistinguishable from random then BHP should be used with a protocol that provides this property, such as BTP in handshake mode.
BHP does not rely on lower protocol layers to provide confidentiality, integrity, authenticity or forward secrecy. If the traffic between peers needs to be indistinguishable from random then BHP should be used with a protocol that provides concealability, such as BTP.
### 1.2 Prerequisites
......@@ -101,7 +101,7 @@ 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 has not modified the long-term or ephemeral public keys, 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 **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)
......@@ -114,6 +114,8 @@ Each peer calculates its own message authentication code and the code it expects
- alice\_proof = MAC(master\_key, "org.briarproject.bramble.handshake/ALICE\_PROOF")
- bob\_proof = MAC(master\_key, "org.briarproject.bramble.handshake/BOB\_PROOF")
As noted above, if the adversary intercepted the prior exchange of long-term public keys and replaced them with its own public keys then BHP does not prevent a man-in-the-middle attack: the adversary can intercept the BHP connection, replace the peers' ephemeral public keys with its own public keys, and produce a proof of ownership of its own long-term and ephemeral public keys that will satisfy each peer.
## 3 Man-in-the-Middle Attacks
However, if the adversary did *not* intercept the prior exchange of long-term public keys, and if the adversary now intercepts the BHP connection and replaces the peers' ephemeral public keys with its own keys, then the adversary will not be able to produce a proof of ownership that will satisfy either peer.
As noted above, if an adversary intercepted the prior exchange of long-term public keys and replaced them with its own public keys then BHP does not prevent man-in-the-middle attacks. The adversary can intercept the BHP connection, replace the peers' ephemeral public keys with its own public keys, and produce a proof of ownership of its own long-term and ephemeral public keys that will satisfy each peer. Each peer will derive a master key that is known to the adversary rather than the other peer, giving the adversary access to any future communication between the peers that is secured with keys derived from the master key.
However, if the adversary did *not* intercept the prior exchange of long-term public keys then BHP prevents man-in-the-middle attacks. If the adversary intercepts the BHP connection and replaces the peers' ephemeral public keys with its own keys, the adversary will not be able to produce a proof of ownership that will satisfy either peer.
......@@ -4,7 +4,7 @@
Bramble Rendezvous Protocol (BRP) is a discovery protocol for peer-to-peer networks. It enables two peers that have previously exchanged public keys to connect to each other. No other information, such as network addresses, needs to be exchanged in advance.
BRP is designed to operate over connection-oriented, bidirectional transport protocols. Unidirectional transports are not suitable for BRP.
BRP is designed to operate over a connection-oriented, bidirectional transport protocol. Unidirectional transports are not suitable.
The current version of BRP uses the Tor hidden service protocol as its transport. Future versions of BRP may support other transports.
......@@ -20,7 +20,11 @@ To avoid exposing their network addresses, peers in BRP exchange public keys ins
We assume the adversary can read, modify, delete and insert traffic on all transports at will.
We do not assume the peers exchanged their public keys over a secure channel. If the adversary intercepted the prior exchange of public keys and replaced them with its own public keys then BRP does not detect or prevent man-in-the-middle attacks. If the adversary knows both peers' public keys but did not replace them during the prior exchange then BRP prevents man-in-the-middle attacks.
We do not assume the peers exchanged their public keys over a secure channel. If the adversary intercepted the prior exchange of public keys and replaced them with its own public keys then BRP does not detect or prevent man-in-the-middle attacks.
If the adversary knows both peers' public keys but did not replace them during the prior exchange then BRP prevents the adversary from knowing the peers' network addresses, unless the adversary can see the addresses by observing the underlying transport.
BRP does not exchange any data over the underlying transport; it just establishes connections. As such, it does not rely on lower protocol layers to provide confidentiality, integrity, authenticity, forward secrecy or concealability.
### 1.3 Notation
......@@ -73,7 +77,7 @@ Both peers calculate the "raw" shared secret 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 has not modified the public keys then both peers will calculate the same raw shared secret, which will be unknown to the adversary.
If the adversary did not intercept the prior exchange of public keys then both peers will calculate the same raw shared secret, which will be unknown to the adversary.
The peers then derive a "cooked" shared secret known as the **static master key**, which incorporates both peers' public keys:
......@@ -113,4 +117,8 @@ If no connection is made within 48 hours of the initial key exchange, the rendez
### 2.4 Use of Rendezvous Connections
The application layer is responsible for deciding how to use any rendezvous connections created by BRP. BRP does not authenticate the remote peer, but it makes the static master key available to the application layer so other protocols can derive keys from it, for example to encrypt and authenticate communication with the remote peer over a rendezvous connection.
The application layer is responsible for deciding how to use any rendezvous connections created by BRP. BRP does not authenticate the remote peer, but it makes the static master key available to the application layer so that other protocols can derive keys from it, for example to encrypt and authenticate communication with the remote peer over a rendezvous connection.
## 3 Man-in-the-Middle Attacks
As noted above, if an adversary intercepted the prior exchange of public keys and replaced them with its own public keys then BRP does not prevent man-in-the-middle attacks. Each peer will derive a static master key and network addresses that are known to the adversary rather than the other peer, allowing the adversary to interpose itself between the peers. The adversary will have access to any future communication between the peers that is secured with keys derived from the static master key.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment