commit 26ae12e462ec74bcf858135a69c6ad32bfcfbd6b
parent c0eb84cd8a9f782201ec8478d6c99bf1809b142b
Author: Julius Bünger <buenger@mytum.de>
Date: Tue, 12 Mar 2024 15:45:28 +0100
cong: clarify attack scenario
Diffstat:
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -12,6 +12,9 @@ change.
..
TODO write a short overview
+ - peer ids
+ - libp2p
+ - protocol versioning
..
Design goals
@@ -39,6 +42,7 @@ Proposal:
We will have to replace the use of ``GNUNET_CRYPTO_symmetric_encrypt`` and
HMAC use in ``gnunet-service-core_kx.c`` including the respective keys and IVs.
+
.. _Peer-IDs:
Peer IDs
@@ -82,31 +86,14 @@ the different addresses that are tied to that peer id over time.
Attacker Model
""""""""""""""
-An attacker observes the hellos (containing ip addresses) published under a
-peer id and is thus capable of tracking locations and thus obtaining a movement
-profile of this peer.
+An attacker observes the hellos (containing ip and other addresses) published
+under a peer id and is thus capable of tracking locations and thus obtaining a
+movement profile of this peer.
With the proposed changes to the peer id an attacker can only see a peer id and
its connected set of addresses. A movement profile can not be obtained in the
previous way.
-Tracking of addresses/locations might still be possible in the scenario that a
-mobile client uses mobile broadband and wifi uplinks and uses them in an
-'overlapping' manner. (Switching on mobile broadband before leaving the range
-of a wifi hotspot.) The overlap can be used to link the 'before' and 'after'
-address and - in extreme scenarios - obtain the full movement profile again.
-Note that this does not work on all, not all the time and requires work for the
-correlation.
-
-A way to circumvent this tracking mechanism would be for an attacker to exploit
-the means for consistently connect to the same peer.
-For example gns. With the knowledge of the gns entry, its peer ids and thus its
-addresses can be fully tracked.
-
-..
- TODO explain that this limits the attack, is all we can do on this level and
- that onion routing/mix networking is supposed to circumvent this
-
..
TODO how much info can be gained by that? all an observing peer sees is the
ip addresses. how much can this tell?
@@ -114,6 +101,35 @@ addresses can be fully tracked.
- internet provider - home, company, public, ...
- region (country, city, building, ...)
+Tracking of addresses/locations might still be possible in the scenario that a
+mobile client uses mobile broadband and wifi uplinks and uses them in an
+'overlapping' manner. (Switching on mobile broadband before leaving the range
+of a wifi hotspot and vice versa Turning off mobile broadband after connecting
+to a wifi.) For the 'overlapping' time the peer would publish a HELLO
+containing the old and the new network addresses. After the overlapping time,
+the peer's HELLO would just contain the new network address, which was already
+in the HELLO from during the 'overlap'. That way the overlap can be used to
+link the old and new address and - in extreme scenarios - obtain the full
+movement profile again. Note that this does not work on all, not all the time
+and requires work for the correlation. It should be highlighted that, although
+this attack is possible, the new design still greatly reduces the attack
+surface.
+
+A way to circumvent this anti-tracking mechanism would be for an attacker to
+exploit the means for consistently connect to the same peer.
+.. TODO wording/conceptualisation - overlap with next sentence
+For example with the means of higher-layer services like gns. With the
+knowledge of the gns entry, its peer ids and thus its addresses can be fully
+tracked. Until the existence of an onion-routing service and its decoupling of
+identities and network addresses, this behavior is probably intended and maybe
+the only way to connect endpoints. Although this leak is still existent the
+new design still prevents a lot of other leakage. Also it is important to point
+out that it is impossible to prevent leakage at higher layers, but necessary to
+prevent leakage at this layer, because leakage at this level could not be fixed
+at higher layers.
+
+.. TODO review for wording/clarity
+
.. _Implications-PeerIDs:
