Rolling static keys/rekeying for anonymity.

[ellenhp]

Hey, I'm wondering if there's been any thought put into the threat model of someone (let's say a state actor) monitoring an area for announce packets to keep track of who's present in an attempt to crack down on freedom of assembly. Not that any state actor has ever done that, but it might be something worth considering anyway.

The easiest way to handle this would be at the application level, by rotating through different identities/destinations and burning old ones, but without some cooperation at the protocol level you'd have to choose between blowing your cover by announcing an old destination with 0 hops, or risking non-delivery of packets addressed to your previous destinations.

I could imagine something as sophisticated as constructing an arbitrary social graph for your spoofed identities and setting the number of announced hops appropriately for the one you're announcing as. For added confusion, you could even exchange unused spoofed identities with trusted parties to subvert any attacker's attempts at clustering of identities by announced hop count, as the social graph would change dramatically if you exchanged an identity with a friend. As far as I can tell there are no facilities for this, but it's something I'd like to see. I don't think that a LoRa PHY layer can tolerate much chaff with its bandwidth constraints, but Reticulum or LXMF should probably have a story here because this is a legitimate threat in way too many places.

[faragher]

The ability to switch or discard identities is core to Reticulum. Rolling through them is generally as simple as switching out a file. Application-specific rolling identities is possible, but as you say, is application specific. There's no practical reason you can't make an LXMF client that aggregates multiple identities into a single message stream and sends to a random member on a list.

However, that's just "security through obscurity." While deception is a part of a layered defense, it's really just playing for time. A holistic approach to network security (in both pertinent definitions of "network") is warranted and, quite frankly, I should sit down and consider the situation more thoroughly. I don't have this library for show. :D

But it's worth a simple example to assess the threat posed by such an attack. Yes, this will get very long. I'm sorry.

Alice and Bob do not wish to be detected. Eve is a state actor hostile to Alice and Bob. There are three public distribution nodes, Alpha, Bravo, and Charlie, all secure, as well as Eve's node, Echo. They all see each other and have arbitrary interfaces attached.

Echo (and thus Eve) can see Alice and Bob's announces, and see they're two hops away, as well as if they're through A, B, or C, and thus Eve knows they're connected to those nodes. If their identities are compromised, that's a problem, but if it's a fresh identity and a widely used node, then there should be no need for suspicion. Alice sends a message to Bob. Eve never sees it, since it's not routed through Echo. Bob to Alice is the same.

Eve compromises Alpha. which is where Alice and Bob are connected. Alice sends Bob a message. Eve sees that Bob is receiving a message, but not that Alice sent it. Time of fight analysis can be an issue, but given an active node with multiple actors, it's difficult to determine who's talking to whom (assuming automatic receipts are off).

Bob moves to Bravo. Now Eve sees Bob's packets go to Bravo, but without an announce has no idea where they go from there.

Alice starts node Delta, attached only to Charlie, and now Eve sees announces come from Charlie, but three hops away. This means any node connected to Charlie could be the next step in the chain. Eve only knows that Alice's packets are going to Bob and routed through Delta, not who sent them or their exact node of origin.

Alice uses two identities, one attached to Alpha and the other to Delta. Both send to Bob, and it's impossible to link the two identities to the same sender without out of band knowledge.

A fully crosslinked network, while important for distribution at our current scale, is less secure than people spinning up their own node and linking to a single endpoint. This creates a fault intolerant network, but it also creates a path with multiple hops and added security. The more people run their own nodes, the more secure the network becomes. (at least in this threat case) If something is three hops away, and the node two hops away has five nodes attached, an announce leaks very little information.

It's also helpful to run a node with IFAC enabled, effectively making a password protected interface, so that node will always be one hop away from any malicious actor.

It might be worth the ability to hard-code or ingest paths and public keys using out of band communications, such as paper messages, but I think the threat of this kind of announce-based tracking is a wider operational security issue, where a healthy ecosystem provides all the protection necessary so long as the identity doesn't somehow out itself as suspicious.

I believe it to be an issue of network topology and how people intend to use the network as opposed to an engineering issue. If nations A and B don't want communication, then both nodes connecting to nation C completely obfuscates crossing the border. A only knows B is two hops away, not where the server is.

If there's a specific case I'm overlooking, please let me know, but I think auto-rotating identities due to announces isn't the best option.

[ellenhp]

My reticulum implementation doesn't need a SBC. It runs on bare metal. :) So yes I suppose I'm talking about running lightweight nodes, in reticulum parlance. But my implementation isn't complete and I'm trying to evaluate whether I should complete it. I'm very indecisive about it. It's a pretty heavyweight protocol and if it doesn't have a first-class way to obfuscate the identifiers I'm worried about then that's a real bummer.

I've witnessed with my own eyeballs situations with threat models like the one I'm describing, so I do think it's worth thinking about and that I'm not prematurely optimizing or anything like that. It's very easy to get caught up in cryptography-land and forget about the real world, but there are lots of situations where Alice and Bob may be able to use radios in a hostile area without fear for their immediate physical safety, but safety the next morning gets very complicated if they leak too much information.

Destination addresses are predictable in one direction. I'd need to check if announces are by identity or by address, but you could change aspects to completely alter your address. Obviously you'd need some kind of pre-arranged system, but if you keep your base identity hidden, then, say, LXMF.Message.JAN1 and LXMF,Message.JAN2 are both deterministic using a one way function, but cannot be traced back to the original identity (to a cryptographic definition of "cannot") Both use the same encryption and decryption key, but have a vastly different destination hash. If correlation of destination hashes is your primary concern, this can be an option (although it will require solid planning, a custom program, and some operational support).

This is again extremely clever. I'll need to read a bit too before I say something incorrect but I think this might just solve the problem entirely. I can't remember if announces include public keys in the clear though, as that would break this sort of obfuscation I think.

[faragher]

Yeah, I've seen too many people hyper-focus on one aspect rather than look at the entirety of the situation. Tracking metadata, targeting based on signatures, and network-centric operations are all pretty advanced in implementation, and I respect that you're addressing the whole problem. That being said, it's far easier to have an engineering solution than expect peak performance in a dynamic and high-fatigue environment.

The complication here is your requirements. You could have an end to end encrypted network with a single pre-shared key or even a one-time pad if you had the ability to pre-share information, or dynamically announce using Reticulum prior to entering the AO. Using a relatively rare protocol is suspicious on its face, though. It's a complicated problem, as you know.

If you store an identity's key for a long enough period, you could simply announce only once and prevent leaking your identity that way.

I'm uncertain Reticulum meets your needs, but I'm willing to keep trying if you are. :D

[ellenhp]

I'm uncertain Reticulum meets your needs, but I'm willing to keep trying if you are. :D

Same. I was hoping to avoid reinventing the wheel though! I wrote this spec up for something that might work better for my use-case. Currently trying to nerd snipe people into reviewing it/breaking it but fair warning: It's quite long. 😉 I think it has much lower overhead than reticulum, just 1 byte of header, an 8 byte message ID and 16 byte MAC per message once a channel is established. Establishing a channel takes <150 bytes exchanged and is 0-RTT. No public keys are transmitted, nor signatures, and there aren't any addresses or announces. It's a weird idea but I think it'll work. None of my friends have been able to break it yet but I'm sure it has flaws. It's not really a replacement for reticulum because it uses spray-and-wait instead of announces, meaning it's impossible to construct a routing table and message delivery rate will suffer because of that. But I just thought I'd close the loop here, because I did end up having to reinvent the wheel.

https://gist.github.com/ellenhp/149a6e3368f54917aab294375b7321dc

[faragher]

Based off a cursory look at your spec, it would prevent destination leakage at the cost of large-scale routability and increased raw number of transmissions. From a trilateration standpoint, or building a TEMPEST profile, you'd increase the risk of correlation with video or other detection mechanisms, as well as broadcasting your position much more frequently. As an attacker, I'd pivot to signatures, watching BT addresses and the like when a broadcast was detected and checking both transport and choke points near the times the transmissions started and ended.

However, as the old maxim goes, if you want to know if your door and windows are secure, ask a firefighter how they'd get in. When they tell you using an axe to go through the wall, your work is done.

[ellenhp]

Thanks for taking a look! And yeah if we're talking about physical link signatures or multilateration then I think my work at the protocol level is done. Routability outside of a few hops is going to be somewhere between inconsistent and terrible, but I may consider extending the protocol at some point to improve that, or just add optional support for a different protocol to the devices I'm building. I think the bundle protocol v7 could be better for reachability, or maybe I'll finish my reticulum port :)