this post was submitted on 11 Aug 2025
20 points (100.0% liked)

meshtastic

244 readers
1 users here now

Meshtastic® is a project that enables you to use inexpensive LoRa radios as a long range off-grid communication platform in areas without existing or reliable communications infrastructure. This project is 100% community driven and open source!

https://meshtastic.org/

founded 2 years ago
MODERATORS
J4g2F@lemmy.ml
20
MeshMarauder: someone finally published a tool to demonstrate how trivial it is to defeat meshtastic's DM encryption (by replacing public keys in profile broadcasts) (partyon.xyz)
submitted 5 months ago by cypherpunks@lemmy.ml to c/meshtastic@lemmy.ml
10 comments fedilink hide all child comments
top 10 comments
sorted by: hot top controversial new old
[–] SanctimoniousApe@lemmings.world 5 points 5 months ago (2 children)

Security is not in my wheelhouse, so I'm curious what others think about this comment (pasted below as well) in the ensuing discussion. I think it makes a valid point - while also missing the point entirely. In a nutshell, should they even bother with security at all if they're not going to prioritize it? If so, why?

Ben @jianmin@defcon.social

Who is encouraging activists to use meshtastic or any lorawan devices? Probably they are the ones most at fault here.

I think the security docs from meshtastic are fairly transparent about what they offer and don't offer.

Correct me if I'm wrong, but your tool primarily abuses the Trust On First Use model for establishing trust. Also without digging into code, I suspect you can combine this with the limited space for nodes in the nodedb to easily spoof arbitrary users that aren't saved/favorited.

It's not as much of a bug as it is an artifact of how the designers decided to handle the limited bandwidth in terms of which features to prioritize. They don't claim to provide security or privacy and seem to prioritize lower bandwidth and operability.

[–] cypherpunks@lemmy.ml 5 points 5 months ago (2 children)

Who is encouraging activists to use meshtastic or any lorawan devices? Probably they are the ones most at fault here.

Agree. I am not going to name and shame but I have seen some people who should know better advocating for Meshtastic as a privacy-oriented technology.

I think the security docs from meshtastic are fairly transparent about what they offer and don’t offer.

key lines from https://meshtastic.org/docs/overview/encryption/ include:

  • "Each DM is encrypted using the recipient's public key, ensuring that only the recipient can decrypt the message with their private key."
  • "While PKC significantly enhances the security of DMs, it's still advisable to avoid sharing sensitive information in direct messages without proper verification of the recipient's public key."

They don't make it nearly as clear as they should that it is completely trivial to replace someone's key, and (last time I checked, anyway) even if one does actually verify a key manually there is no mechanism to prevent it from being replaced later.

Correct me if I’m wrong, but your tool primarily abuses the Trust On First Use model for establishing trust

They don't have a Trust On First Use model to abuse. Trust On First Use implies stickiness; meshtastic currently is trust any key at any time.

They don’t claim to provide security or privacy

They literally say that they are "ensuring that only the recipient can decrypt the message" and "allowing the recipient to verify the sender's identity and ensuring the integrity of the message". They do follow that up with some weak caveats but I think most people who read that assume that they are in fact claiming to provide some security and privacy.

imo the Meshtastic developers should immediately implement TOFU and then apologize to their users for having neither done so earlier nor made it clear to their users just how trivial it is to circumvent/disable their DM encryption in the absence of a TOFU mechanism.

[–] SanctimoniousApe@lemmings.world 4 points 5 months ago* (last edited 5 months ago) (1 children)

Yeah, that's why I said they missed the point. My question, tho, is should the devs even bother encrypting at all given that it's not a primary focus for them? I'm thinking if they're only going to half-ass it, then it's better to not bother and just say "encrypt it yourself before sending" so they can just focus on efficient transmission.

[–] cypherpunks@lemmy.ml 1 points 5 months ago* (last edited 5 months ago)

should the devs even bother encrypting at all given that it’s not a primary focus for them?

Yes, imo, even doing what they're doing now (without TOFU, trivially vulnerable to active attacks) is better than not encrypting at all - they should just have been forthright with users about it having been designed to only provide confidentiality from passive adversaries.

But also, they should actually mitigate active adversaries by implementing TOFU. And then still, they should be more forthright about Meshtastic not being designed for privacy (re: enabling location tracking, etc, even absent GPS).

[–] Rentlar@lemmy.ca 1 points 5 months ago (1 children)

On the encryption page you linked, there's a clear and conspicuous section on authentication:

Authentication

Authentication means nodes say who they are on the network. Meshtastic does not implement this, so it is trivial to impersonate anyone else if you have access to the channel key

This is because node IDs are based on hardware MAC address, which are hardcoded by the manufacturer.

So while the implementation of exploiting the lack of authentication is important to highlight, I wouldn't say that Meshtastic kept the fact authentication is missing a secret. It's right there in official documentation, not as a footnote or hidden in a code comment, social media statement or github issue.

Therefore, I see no reason for them to apologize for that, but they could definitely improve by implementing authentication.

[–] cypherpunks@lemmy.ml 1 points 5 months ago (1 children)

That section of the docs is about groups (channels), which use solely symmetric encryption (with a "pre-shared key" known by all group members) instead of the asymmetric encryption which is used by DMs.

Their group/channel encryption scheme is actually not trivially breakable to attackers who do not know the channel key. That warning is about how about people who do know the channel key (eg, group members) are able to impersonate other group members.

This is unrelated to the problem of their asymmetric DM encryption being trivially breakable by strangers.

[–] Rentlar@lemmy.ca 1 points 5 months ago* (last edited 5 months ago) (1 children)

Correct, it's two/multiple set of issues brought up with MeshMarauder. As I replied to the other user, I recommended a 1-on-1 channel (group) with the PSK shared over a separate secure communication band, instead of DMs as the most secure communication Meshtastic can offer at the moment.

Similarly, DMs on Lemmy and many other social sites aren't private either. The terminology Direct message differentiates it from a Private message, so I hope nobody got the wrong idea or felt tricked by some privacy or confidentiality assurance that Meshtastic never claimed to offer.

[–] cypherpunks@lemmy.ml 1 points 5 months ago* (last edited 5 months ago) (1 children)

Just to be clear, i wrote this comment about DM encryption in a thread about DM encryption:

They literally say that they are “ensuring that only the recipient can decrypt the message” and “allowing the recipient to verify the sender’s identity and ensuring the integrity of the message”.

which you appeared to refute, writing:

I wouldn’t say that Meshtastic kept the fact authentication is missing a secret. It’s right there in official documentation, not as a footnote or hidden in a code comment, social media statement or github issue.

But, I also wouldn't (and in fact didn't) say that they kept the lack of authentication in their channel encryption a secret.

And when i pointed out that you are refuting my statements about their DM encryption by citing their statements about their channel encryption, you replied with this:

Correct, it’s two/multiple set of issues brought up with MeshMarauder.

...pretending as if you actually realized that the section of the docs you were citing was unrelated to DM encryption at the time you posted it here. (or am i missing something?)

I hope we can actually agree that, regarding their DM encryption:

  1. they do say that they are “ensuring that only the recipient can decrypt the message” and “allowing the recipient to verify the sender’s identity and ensuring the integrity of the message”, and
  2. that these claims are in fact only true regarding a passive adversary, and
  3. they (still, as of today) don't mention that the claimed confidentiality and integrity properties of their DMs can be trivially defeated by an active adversary.
[–] Rentlar@lemmy.ca 1 points 5 months ago* (last edited 5 months ago)

Sorry for the long back and forth, you make many good points and identify where there is room for improvement but TLDR I maintain that Meshtastic does what it says it does, no more, anything beyond that such as complete invulnerability to spoofing attacks is an incorrect assumption.

What Meshtastic is saying is correct, though, and while you rightly point out the potential for improvements in this thread, Meshtastic doesn't owe an apology because they haven't lied by omission or gravely misrepresented anything.

If the key on a profile changes, since there is no authentication, you have to assume that you are talking to someone else since can only verify you are talking to the same person if the key remains the same. That key-pair is the verification for whether you are assured you are talking to the same endpoint or not, maybe Meshtastic could improve their description of how it works directly on their docs, but they clearly say not to use DMs for sensitive info. If a user ignores the notification of the key change on their meshtastic device (or perhaps they are using a standalone device with a UI that doesn't notify) without negotiating that and assumes it's the same person, that's at their own peril (or the firmware dev's problem for not notifying).

On their blog, they stated that the key-pair is generated at first boot, so a key change in the middle of a conversation, if they are the same person, would mean they reflashed their device, which is not unheard of but an unlikely scenario during a session. (A portion of this blog post could help being shown in the overview section of the official docs). This is the vulnerability in DMs that is "trivially defeated". It could use better explanation but this encryption mechanism was never made to verify DMs across changing keys. The key change notification satisfies Meshtastic's claim, the sender's identity is no longer verified to the recipient from then on. To give an analogy, if I changed to my alt @rentlar@lemmy.world and started replying, that's up to you and I, not Lemmy, to verify we are the same user from that point.

Some frontend improvements might be to send it as a separate DM thread named the same, then prompt the user to verify/manually authenticate that this person with the same hardware ID but different key before merging the conversations together. Improvements in the communication protocol would be nice I agree, but at the moment the tradeoffs in bandwidth were considered to be too great to negotiate keys OTA and increase security.

I offered the privately negotiated channel encryption as a better alternative to DMs on Meshtastic for the other user, because it is almost the same principle, but more secure against the exploits MeshMarauder (topic of the thread) implements.

[–] Rentlar@lemmy.ca 2 points 5 months ago* (last edited 5 months ago)

I responded to the OP about authentication in another reply, how Meshtastic developers aren't hiding the fact it's completely missing.

On the channel security element: I dived into it a little bit and looked at the MeshMarauder code.

Edit: I'll quickly preface with appreciation that the developer of MeshMarauder brings attention to these issues with open-sourced implementation of the vulnerability exploit. Review and constructive criticism would not be possible without it.

From this file: https://github.com/datapartyjs/meshmarauder/blob/main/src/lorapipe-raw-packet.mjs

Essentially the DefCon 33 channels were pre-defined keys for users of that event, "DEFCONnect", "HackerComms", "Default" etc. So any user with knowledge of the key can wreak havoc, but if there's another channel with the PSK kept secret, that has not been necessarily defeated by MeshMarauder. Though the documentation says that divulging the key through any means to an untrusted person, guessing an insecure key, access to a device to extract the key, or any undiscovered bug that might give away the key, would fully compromise the security.

DMs are vulnerable to the lack of authentication (allowing impersonation and changing of keys that are notified but may go unnoticed by the user), but this is where network bandwidth limitations come in. Setting up a 1-on-1 channel with a shared key sent via a separate trusted and secure means, is currently the best alternative Meshtastic can offer from a security standpoint, still with significant but known limitations.