[Feature Request]: Stronger cryptographic guarantees and discussion of threat model

[xloem]

Platform

other

Description

I saw in the documentation that the current cryptography has been reviewed and has concerns. The reviewer stated an attacker can scramble content such that it arrives corrupt, for example at the bottom of their review.

• It would be good to make the issues the reviewer found more prominent somewhere so developers and designers can work on them, and of course to do so.

• It could make sense to apply an existing cryptosystem such as the popular double ratchet algorithm or even one with anonymity guarantees.

• If there were a threat model or imagined scenario, such as a telecommunications takedown in a situation of political strife, this would really help reviewers and possibly designers too.

[tim292stro]

I brought up a similar idea very early in the project, but after meditating on it for months I decided it really wasn't the right way to approach the question.

My $0.02, if the threat model is a telecommunications take-down in a situation of political strife, you are probably talking about a Nation-State adversary. If that case, the Meshtastic node should be presumed insecure, and radio emissions should be used sparingly if at all. Narrower bandwidth, more directional antennas using less RF power, shorter duration transmissions (using brevity codes: https://en.wikipedia.org/wiki/Brevity_code) on predetermined randomized and rotating schedules - move transmitting equipment often (this brings up the vulnerability of someone going to retrieve a node rather than just running it until its battery runs out and abandoning it). I also wouldn't rely on the in-built encryption - HMAC-sign (user), encrypt, and re-HMAC-sign (network) every message being sent into the Meshtastic ecosystem as you would any other publicly available message transport. Nothing beats PSK-OTPs. Take lessons away from TOR, the entry and exit points are the real vulnerability.

Link Labs has an analysis of radio direction finding of LoRa (no affiliation, but linked for reference: https://www.link-labs.com/blog/lora-localization), one can use COTS equipment to localize down to 500Meters with 125kHz using TDOA - here narrower bandwidth makes it harder to discriminate between multipath signals. Nation-States would also have access to other more expensive equipment, the nature of the communications disruption needed by your adversary would determine the resources put in play to counter alternative communication methods (i.e. tanks/bombs vs. cops/bureaucrats).

With a Meshtastic node as an entry point, presuming Bluetooth communication to the user terminal (phone, etc.), your unmodified range will be less than 15Meters. So a skilled RDF operator having found a Meshtastic/LoRa signal in their area, could begin a directional search for correlated frequencies (800/900MHz + 2.4GHz Bluetooth with a WIDE bandwidth, and is intentionally designed to be direction found, see Bluetooth Channel Sounding Localization) - and call in an air asset towards the center of that 500meter circle with a lot of juicy 2.4GHz traffic. The effective radius for a 500lb JDAM (a small one) is about 230ft/70Meters, with a high probability kill radius of 65feet/20meters - note that your 15Meter Bluetooth range is well inside that kill radius. They don't even have to be right on your forehead for you to have a bad day.

My summary is, if your life depends on it, and your adversary is in control of general communications in your battle space - don't use a $20-30 RF node whose code was developed in the clear. At least not without some modifications. You can receive all day long and it's less likely to be RDF'd (we're ignoring LO leakage out the receive antenna, as an unintentional emitter), having something that gets you onto the Meshtastic system without RF emissions would be recommended. ESP32 has an IR receiver block, there's something to be said about lasers and omni-directional optical receivers here... If you can make the point of entry into the network appear further away from you than you are, that stand-off distance is a start.

If your adversary is significantly less capable and equipped, the same advice about short-duration/agreed-schedule messages and directional antennas applies, just communicating using a OTP cipher (where the key is correctly NEVER reused) to encrypt a message before putting it on Meshtastic and blocking the node location transmission is sufficient. This can be done now with a 6-sided game die and a pencil (again no affiliation, but for reference: https://www.youtube.com/watch?v=QRa_zzQOEe8).

[xloem]

Noting that there are different degrees of strife.

Did I miss something in my issue? I have not reviewed the project in depth.

[tim292stro]

I'm presenting the general opinion that was shared with me in chats earlier in the project, the remaining bulk of the response related to your specific proposed scenario (even if it's a riot where a Government will take down communication, one should assume they are also listening-to/targeting what traffic remains - a $40 RTL SDR can do this now). I am told that Meshtastic has been used in areas recently where "strife" is Nation-State against Nation-State, and I have recommended against that for the reasons above.

As it was explained to me earlier, if you were attempting to address this specific cryptographic attack (as in your second bullet point), it would require a near rewrite of the Meshtastic protocol stack to accommodate the necessary changes, some of which would not be supported on low cost nodes (which is why the effort was initially declined). Another contributor suggested using it as a moment to adopt the Reticulum protocol which is hardened to this type of attack (and arguably more flexible in general as a transport), a suggestion which was declined.

The encryption payload being corrupted by an attacker as eluded to in the security review, is a form of denial of service attack, but it requires some technical sophistication to inject (i.e. Meshtastic protocol knowledge, and received-rewritten-retransmitted during a hop period). A much lower tech DoS attack on the nodes would be to simply jam (bringing the noise floor up above a level the link margin was designed for). At least at this point the corrupt payload acts as a terrible form of tamper detection. Adding in message integrity code has the side-effect of attribution - as validating that a message is what user "X" sent, means you need something that can be traced back to user "X" (like one half of a public key pair).

If you read the Comments section of that page above where your analysis link follows through to, you'll see that the "encryption" is for a network not node-to-node, it's intended to prevent casual reading by the protocol layer but allow the payload to be rebroadcast by nodes which are not on the same encrypted network. There is enough information in the cleartext portion of the message packet, that if someone finds ("captures") a node you should presume the network is compromised, including old message packets that were previously captured/recorded.

The take-away being, Meshtastic as conceived and implemented is fine for backpackers chatting, dog trackers, community aid response after a disaster, or checking the water level of a tank that doesn't have consequences - but should not be mistaken as a security product, or guaranteed to survive intentional disruption.

[xloem]

It’s generally true that major changes can involve rewrites, but I don’t mean to be pushing a particular solution, simply that the guarantees be decided upon and met.

If the current product does not mean desired guarantees, a second product would be appropriate to plan. Maybe that means merging with Reticulum? But what guarantees it does meet, users would benefit by knowing precisely and clearly what they are, maybe even what to consider or do if they have greater needs.

It seems like this is already somewhat clear in the documentation, but not formally tracked or addressed. The comments section you link does not yet have information on the attacks the reviewer found.

[tim292stro]

I understood the complaints in the analysis at face value. And it seems despite previous positions to the contrary, it appears that others also did, and recent work is being done on this issue:

[Bug]: missing integrity checks let attacker forge arbitrary message content using a known plaintext attack and replaying messages even when PSK is not known #4030
[Bug]: nonces are only randomized with 31 bits, this make it rare but possible to see duplicated nonces in the wild threatening confidentiality of messages #4031

I'll add a final comment on merging with Reticulum, there has been little interest in nearly 5 years to do that (with the understanding that Meshtastic is designed for a different purpose - like a star-driver versus a Philips screwdriver). Reticulum is also open source and available on GitHub. If you really require increased security guarantees, Reticulum runs on most of the same hardware as Meshtastic (actually works on more stuff and over more types of interfaces - even paper), so the cost to move between is pretty low (just time). I personally use a mix.