Which brings me to part two, MeshMarauder.
An open source tool demonstrating proof-of-concept exploits against the DEFCON 33 Meshtastic firmware.
MeshMarauder will demostrate:
- Tracking user activity on any mesh regardless of encryption usage
- Hijack all meshtastic user profile metadata
- Change any users public key
- Send messages as any user in channel chats that appear authentic
- MITM direct messages
https://meshmarauder.net
#defcon #meshtastic #meshmarauder #cybersecurity
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.
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:
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
that these claims are in fact only true regarding a passive adversary, and
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.
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.
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.
Just to be clear, i wrote this comment about DM encryption in a thread about DM encryption:
which you appeared to refute, writing:
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:
…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:
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.