From 99428fe0dfb71b67d21fa6031a3e4ee4288a05f9 Mon Sep 17 00:00:00 2001 From: akwizgran <michael@briarproject.org> Date: Fri, 15 Mar 2019 11:21:57 +0000 Subject: [PATCH] Update BTP.md --- protocols/BTP.md | 50 +++++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 26 deletions(-) diff --git a/protocols/BTP.md b/protocols/BTP.md index ebecb72..f46f83c 100644 --- a/protocols/BTP.md +++ b/protocols/BTP.md @@ -2,25 +2,23 @@ ## 1 Introduction -Bramble Transport Protocol (BTP) is a transport layer security protocol suitable for delay-tolerant networks. It provides a secure channel between two endpoint devices, ensuring the confidentiality, integrity, authenticity and forward secrecy of their communication across a wide range of underlying transports. +Bramble Transport Protocol (BTP) is a transport layer security protocol suitable for delay-tolerant networks. It provides a secure channel between two peers, ensuring the confidentiality, integrity, authenticity and forward secrecy of their communication across a wide range of underlying transports. BTP's main components are a time-based key management protocol and a wire protocol for securely transporting streams of data. -BTP is designed for use in censorship-resistant delay-tolerant overlays. By providing consistent security properties for a very wide range of transports, BTP simplifies the design and implementation of such overlays. - BTP can operate over any transport that can deliver a stream of bytes from one device to another on a best-effort basis, meaning that streams may be delayed, lost, reordered or duplicated. The underlying transport is not required to provide any security properties. The BTP wire protocol includes optional padding and does not use any timeouts, handshakes or plaintext headers. This makes BTP compatible with traffic analysis prevention techniques such as traffic morphing, with the goal of making it difficult to distinguish BTP from other protocols. BTP does not attempt to conceal the identities of the communicating parties or the fact that they are communicating - in other words, it does not provide anonymity, unlinkability or unobservability. If such properties are required, BTP can use an anonymity system such as Tor as the underlying transport. -Forward secrecy is achieved by establishing an initial root key between a pair of endpoint devices and using a one-way key derivation function to derive a series of temporary keys from the root key. Once both endpoints have deleted a given key, it cannot be re-derived if the endpoints are later compromised. +Forward secrecy is achieved by establishing an initial root key between two peers and using a one-way key derivation function to derive a series of temporary keys from the root key. Once both peers have deleted a given key, it cannot be re-derived if the peer devices are later compromised. ### 1.1 Motivation The primary motivation for BTP's design is to provide a versatile building block for censorship-resistant communication systems. BTP is therefore designed to be used across a diverse mixture of transports, both online and offline, with varying properties. The transports are not given access to unencrypted or unauthenticated data; nor are they required to ensure the confidentiality, integrity, authenticity or forward secrecy of the data they carry. BTP is responsible for providing those properties. -BTP is unusual in that it provides forward secrecy even for transports where one of the endpoints can only send and the other can only receive. It can be used on transports with very high latency, such as disks sent through the mail. +BTP is unusual in that it provides forward secrecy even for transports where one of the peers can only send and the other can only receive. It can be used on transports with very high latency, such as disks sent through the mail. ### 1.2 Design Requirements @@ -30,7 +28,7 @@ BTP is unusual in that it provides forward secrecy even for transports where one - **Layering** - The protocol should treat each underlying transport connection as a unidirectional or bidirectional sequence of bytes with a simple socket-like interface (open, read/write, close). Likewise, the protocol should provide a similar interface to higher protocol layers. + The protocol should treat each underlying transport connection as a unidirectional or bidirectional sequence of bytes with a simple socket-like interface (open, read/write, close). Likewise, the protocol should provide a socket-like interface to higher protocol layers. - **Concealability** @@ -42,15 +40,15 @@ BTP is unusual in that it provides forward secrecy even for transports where one - **Integrity** - The adversary should not be able to cause either endpoint to read data from the BTP layer that differs from the data written to the BTP layer by the other endpoint. If the adversary truncates the data, the receiving endpoint should be able to detect that this has happened. + The adversary should not be able to cause either peer to read data from the BTP layer that differs from the data written to the BTP layer by the other peer. If the adversary truncates the data, the receiving peer should be able to detect that this has happened. - **Authenticity** - The adversary should not be able to cause either endpoint to accept data from any third party as though it came from the other endpoint. + The adversary should not be able to cause either peer to accept data from any third party as though it came from the other peer. - **Forward Secrecy** - The adversary should not be able to learn what data was transported by the protocol if, at some later time, the adversary compromises one or both of the endpoint devices. + The adversary should not be able to learn what data was transported by the protocol if, at some later time, the adversary compromises one or both of the peer devices. The protocol is not required to conceal the identities of the communicating parties or the fact that they are communicating. @@ -62,7 +60,7 @@ BTP is intended to be used in systems that resist surveillance and censorship by - The adversary can choose the data written to the BTP layer by higher protocol layers. -- The adversary has a limited ability to compromise endpoint devices. If a device is compromised, the adversary can access any information held in the device's volatile memory or persistent storage. +- The adversary has a limited ability to compromise peer devices. If a device is compromised, the adversary can access any information held in the device's volatile memory or persistent storage. - The adversary cannot break standard cryptographic primitives such as ciphers and message authentication codes. @@ -82,19 +80,19 @@ Using BTP over a datagram-oriented transport such as UDP (which does not have a ### 1.5 Prerequisites -Before two endpoints can communicate using BTP they must agree on the following properties: +Before two peers can communicate using BTP they must agree on the following properties: -- **Roles of the two endpoints** +- **Roles of the peers** - The endpoints must agree which of them will play the role of **Alice** and which the role of **Bob**. The roles are identical except for some key derivation constants. It does not matter which endpoint plays which role, as long as one is Alice and the other Bob. + The peers must agree which of them will play the role of **Alice** and which the role of **Bob**. The roles are identical except for some key derivation constants. It does not matter which peer plays which role, as long as one is Alice and the other Bob. - **Maximum clock difference** - The endpoints must agree on the maximum expected difference between their clocks, **D**. This value may be hard-coded. The current version of BTP assumes D = 86,400 seconds (24 hours). This is to accommodate mobile devices, which often have inaccurate clocks. + The peers must agree on the maximum expected difference between their clocks, **D**. This value may be hard-coded. The current version of BTP assumes D = 86,400 seconds (24 hours). This is to accommodate mobile devices, which often have inaccurate clocks. - **Maximum latency** - The endpoints must agree on the maximum expected latency, **L**, of each transport they wish to use. This value may be hard-coded. For any given transport we can choose some maximum latency that is unlikely to be exceeded under normal conditions. For example, we might choose one minute as the maximum latency for TCP, or two weeks as the maximum latency for disks sent through the mail. If a connection exceeds the maximum latency, none of BTP's security properties are lost but it may reject the stream or streams carried by the connection. + The peers must agree on the maximum expected latency, **L**, of each transport they wish to use. This value may be hard-coded. For any given transport we can choose some maximum latency that is unlikely to be exceeded under normal conditions. For example, we might choose one minute as the maximum latency for TCP, or two weeks as the maximum latency for disks sent through the mail. If a connection exceeds the maximum latency, none of BTP's security properties are lost but it may reject the stream or streams carried by the connection. ### 1.6 Notation @@ -130,15 +128,15 @@ BTP uses a time-based key management protocol to derive a series of **temporary BTP has two key management modes, which are suitable for different purposes. -**Dynamic mode** provides forward secrecy for the data being transported, but requires the endpoints to delete the root key, and any information that could be used to re-derive it, before the temporary keys are used. Dynamic mode requires the endpoints to agree on a timestamp, **T**, which must be in the past according to both endpoints' clocks. +**Dynamic mode** provides forward secrecy for the data being transported, but requires the peers to delete the root key, and any information that could be used to re-derive it, before the temporary keys are used. Dynamic mode requires the peers to agree on a timestamp, **T**, which must be in the past according to both peers' clocks. -**Static mode** does not provide forward secrecy for the data being transported, but allows the endpoints to retain the root key or information that could be used to re-derive it. Static mode does not require a timestamp. +**Static mode** does not provide forward secrecy for the data being transported, but allows the peers to retain the root key or information that could be used to re-derive it. Static mode does not require a timestamp. These modes are intended to be complementary. Static mode can be used to bootstrap dynamic mode by transporting the messages of a key agreement protocol that establishes a root key and timestamp for dynamic mode. The establishment of root keys and timestamps is not handled by BTP itself. BTP is designed to be used with a separate key agreement protocol that securely establishes the initial state. -If two endpoints wish to communicate across more than one transport, they must establish a separate root key for each transport to ensure they do not reuse keys. +If two peers wish to communicate across more than one transport, they must establish a separate root key for each transport to ensure they do not reuse keys. ### 2.2 Key Derivation Function @@ -150,17 +148,17 @@ BTP uses a **key derivation function** to derive temporary keys from the root ke For each transport, BTP divides time into numbered periods, where period zero starts at the Unix epoch. A different set of temporary keys is used for each period. -The length of each period is D + L seconds, where D is the maximum expected difference between the endpoints' clocks and L is the maximum expected latency of the transport. +The length of each period is D + L seconds, where D is the maximum expected difference between the peers' clocks and L is the maximum expected latency of the transport. This ensures that if the sender starts sending a stream in period P0 according to the sender's clock, and if D and L are not exceeded, then the recipient will start receiving the stream in period P1 according to the recipient's clock, where abs(P1 - P0) <= 1. In other words, the recipient only needs to retain the temporary keys for the previous, current and next periods. ### 2.4 Key Derivation for Dynamic Mode -In dynamic mode, BTP achieves forward secrecy by periodically rotating and deleting the temporary keys. The key derivation function is deterministic, so endpoints that start from the same root key and timestamp will derive the same temporary keys for each time period. Forward secrecy relies on the one-way nature of the key derivation function: the keys of an earlier period cannot be re-derived from those of a later period. +In dynamic mode, BTP achieves forward secrecy by periodically rotating and deleting the temporary keys. The key derivation function is deterministic, so peers that start from the same root key and timestamp will derive the same temporary keys for each time period. Forward secrecy relies on the one-way nature of the key derivation function: the keys of an earlier period cannot be re-derived from those of a later period. ##### Initial Keys -Each endpoint derives four initial keys from the root key. Alice derives her initial keys as follows: +Each peer derives four initial keys from the root key. Alice derives her initial keys as follows: - outgoing\_tag\_key := KDF(root\_key, "ALICE\_TAG\_KEY") @@ -182,11 +180,11 @@ Bob derives his initial keys as follows: Thus Alice's outgoing keys are Bob's incoming keys and vice versa. -After deriving the initial keys, both endpoints must delete the root key. +After deriving the initial keys, both peers must delete the root key. The initial keys are used as the temporary keys for the period preceding the period containing the timestamp T. -The purpose of the timestamp is to save the cost of rotating keys from period zero up to the current period. If it is not possible or convenient to agree a timestamp T along with the root key then T can be hard-coded to some value that is certain to be in the past according to both endpoints' clocks, at the cost of some extra key rotations. +The purpose of the timestamp is to save the cost of rotating keys from period zero up to the current period. If it is not possible or convenient to agree a timestamp T along with the root key then T can be hard-coded to some value that is certain to be in the past according to both peers' clocks, at the cost of some extra key rotations. ##### Key Rotation @@ -204,7 +202,7 @@ To ensure forward secrecy, keys must be deleted when they are no longer needed. ### 2.5 Key Derivation for Static Mode -In static mode, BTP does not provide forward secrecy. The temporary keys for any period can be derived from the root key, which is retained by the endpoints. +In static mode, BTP does not provide forward secrecy. The temporary keys for any period can be derived from the root key, which is retained by the peers. Alice derives her temporary keys for each time period P as follows: @@ -292,7 +290,7 @@ The encrypted and authenticated frame header is 4 + AUTH\_LEN bytes long, while ## 4 Reordering Windows -BTP uses **reordering windows** to allow endpoints to recognise streams that are received out of order due to reordering or loss of connections by the underlying transport. Each endpoint maintains reordering windows for the previous, current and next time periods. The windows are used to recognise incoming streams by their tags. +BTP uses **reordering windows** to allow peers to recognise streams that are received out of order due to reordering or loss of connections by the underlying transport. Each peer maintains reordering windows for the previous, current and next time periods. The windows are used to recognise incoming streams by their tags. Each window contains **W** tags, each of which is marked as *seen* or *unseen*. W is an implementation parameter. Maintaining larger windows makes it possible to tolerate more reordering or loss by the transport, at the cost of storing more tags. (*Note:* In the current implementation of the protocol, W = 32.) @@ -304,6 +302,6 @@ When a previously unseen tag is marked as seen, the window slides according to t If the window slides past a tag that has not been seen, the recipient can no longer recognise the corresponding stream. -To avoid reusing tags, which would allow the adversary to distinguish BTP traffic from random, the sender must persistently store the number of streams sent to the recipient in the current time period. +To avoid reusing tags, which would allow the adversary to distinguish BTP traffic from other protocols, the sender must persistently store the number of streams sent to the recipient in the current time period. To avoid accepting replayed streams, the recipient must persistently store the reordering windows for the previous, current and next time periods. -- GitLab