Hi, on our meeting today we discussed multiple cases and potential issues of PeerID changes regarding attackers potentially tracking users/devices via HELLO strings.
Because of that the PILS service is planned to allow PeerID changes so that different addresses from communicators (their network interfaces) cause a new PeerID making it much more difficult to track a device around its addresses. However one possible case would be that a mobile device might have an interface for mobile traffic or even a Wifi connection that reaches far enough, so that its address might be part of multiple HELLO strings with different PeerIDs. Allowing tracking of a device via intersections of addresses in the HELLO strings. One possible way to solve this issue might be to use some sort of sub- PeerIDs bound to communicator addresses which do not change. However they for an attacker they would look like a fully separate PeerID with its own HELLO string, not intersecting with the original one. A device could configure address interfaces to use such a sub-PeerID or not (with it being disabled by default). Another options would also be to disable specific address interfaces completely for TRANSPORT (or communicators) to avoid the issue. I'm not sure whether it would be required to make a connection between the original PeerID and such a sub-PeerID (like a signature from one to another, authenticating to be a sub-PeerID from a specific PeerID for example) or not. Because higher level APIs could effectively treat both as fully separate devices as well. If there's such a connection between them, it might help for finding a back-channel. But it shouldn't be directly discoverable via HELLO strings to avoid same kind of tracking as before. Additionally the sub- PeerIDs could be rotated after a configured time interval. So even if an attacker would discover such a connection, it wouldn't be possible to easily track it over a longer period of time. Essentially the idea is to have an artificial PeerID per address in case of a long term address which doesn't change regardless of moving a device significantly to avoid tracking. It would be implemented most likely in TRANSPORT and operate additionally to the changing PeerIDs via PILS. What do you think? Best regards Jacki
