Thoughts on this?
If you’re looking for a Meshtastic alternative which was designed with cryptographic security in mind instead of adding it as an afterthought, check out Reticulum and its RNode firmware which lets it use (most) Meshtastic-compatible LoRa devices as a modem.
Reticulum also has much more intelligent routing, can work over things besides just LoRa (including the internet), and (some) applications built on it provide reliable transport.
see also
- Sideband - probably the app to start with, for Linux, Android, Mac, and Windows
- https://github.com/liberatedsystems/RNode_Firmware_CE - more actively developed fork of LoRa modem firmware which supports more devices than upstream
- https://rmap.world/ - despite being older and more mature, it unfortunately still has many fewer (publicly listed, at least) nodes than Meshtastic
- https://github.com/markqvist/Reticulum/wiki/Awesome-Reticulum - lots more
about iOS support...
- https://github.com/markqvist/Reticulum/issues/116 - explains some of the obstacles
- https://github.com/markqvist/Reticulum/discussions/117
- https://github.com/markqvist/Reticulum/discussions/307
- https://testflight.apple.com/join/ftgW9n0Z - i don’t know if this currently works; i only skimmed the above discussions
caveat about the license
The license of the Python reference implementation doesn’t meet the free or open source software definitions because it contains these two clauses:
-
The Software shall not be used in any kind of system which includes amongst its functions the ability to purposefully do harm to human beings.
-
The Software shall not be used, directly or indirectly, in the creation of an artificial intelligence, machine learning or language model training dataset, including but not limited to any use that contributes to the training or development of such a model or algorithm.
While I very much appreciate the intention of these clauses, they will inevitably inhibit adoption somewhat.
There are however already multiple compatible implementations in development under free licenses, as you can see on the Awesome-Reticulum wiki page. (Including one by a company marketing products based on it for military use 😦)
The Sideband app is also under a non-free license (CC BY-NC-SA).
I’m not familiar with the design philosophy of the original protocol, or if they decided the protocol should or should not attempt to impose any kind of a security model, but given that the project grew out of the same kind of ethos as HAM, I’d bet it was never a high priority.
That said, these exploits make the mesh untrustable and should be mitigated. If the devs don’t want to implement fixes, maybe the answer is stripping out all encryption entirely and adding a plugin system that allows anyone to implement a solution themselves. They could even move the current broken implementation to a plugin and make it the default.
In the future, they’d only ever need to handle requests for maybe new entry points or tweaks to the plugin system.
It is mitigated in 2.6.11 https://github.com/meshtastic/firmware/releases/tag/v2.6.11.60ec05e. When I re-generate keys on a node I get warnings that the public key of that node is changed, and I need to delete the node and wait for the next advertisement to update it. I haven’t tried running meshmarauder myself to see if the user profile tampering still works, if they sign and check the updates correctly I don’t see why that would still be broken. The other impersonation stuff does not seem to be released yet.
That said, I think Mestastic works as a kind of hobby, out of band public communication network first and foremost. Even in that kind of setting, knowing who sent which message is valuable, but not a deal breaker in my opinion. Not sure I’d trust it as a network for encrypted person to person messaging. And to be fair, compared to “normal” HAM, any kind of attestation is a bonus. And it’s license free and relatively cheap to get into.
It is mitigated in 2.6.11
That release mitigates a previous issue, where different devices would sometimes generate identical secret keys due to lack of entropy in their random number generation.
This is their response to the issues which this post is about.
-
I believe every single exploit we demo’d was previously documented in meshtastics bug tracker 1yr+ ago and were closed by the MT devs and largely ignored for a year.
-
When I began trying MT in 2024 the devs shutdown convos asking for security fixes saying people should use other comms tools if they wanted security. Rather than address fixable security bugs.
Well, that pretty much settles the Devs don’t care about security.
-
If I’m understanding correctly, they are actually addressing security issues. For example, they have a blog post called that one time at DEF CON where they discussed what happened and how they mitigated it in firmware 2.7.5.
this is never going to be and was not designed to be a secret spy movie text network anymore than it is an instant messager replacement. the encryption has a ways to go yes but its also come a long way. the benefit of the platform is zero licensing entry with cheap gear. that communities can stand up together and use. or organizers can flash devices between uses and swarm a mesh if needed.
its fun building meshes that can cover a hundred miles but, to function like that you have to drastically shorten the messages. and repeat messages to deal with drops. the encryption overall is fine for what the mesh can do and what the appropriate use cases could be. not great but it’ll do.
Is it legal to encrypt communications in the spectrum meshtastic is using?
I had thought it was not and therefore could not be built into the protocol and so securing communications (potentially illegally) is left as an exercise for the reader.
Is that not so?
It’s apparently legal if you don’t enable ham mode. Not a lawyer etc.
in the US at least its about broadcast power level. HAMs can broadcast louder but cant enable encryption. default firmware shipped to the US limits your power level so you remain legal.
*i should add that is MY understanding of the situation and i’m no lawyer.
You have it correct. If you’re using ham mode, you’re allowed to use more power, but hams cannot have encrypted data. Therefore, ham mode is disabled by default.
Also with Ham Mode, if you do enable it, you can only talk to other nodes also using Ham Mode, unencrypted. Therefore, you lose access to the majority of the mesh, which makes it kind of pointless, except for experiments.
