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)
This is the kind of security research we need. By bringing up these issues, they can be fixed.
25
Rentlar - 4mon
Yeah, I didn't have any current expectations about the privacy, anything beyond security-by-obscurity which is absolutely not reliable for any important private conversation.
I'm pretty much chatting with complete strangers on the network anyway, and the usefulness I see is as a secondary communication band if traditional networks aren't available in a crisis. The PSK sounded more like a channel filter than an encryption mechanism to me anyway (I hope my past comments describing meshtastic were clear about this).
I'm all for identifying these flaws and fixing them, improving the protocol in future version so that maybe eventually it can be suitable for sensitive information than hobbyist blather or emergency info.
12
sobchak @programming.dev - 4mon
Yeah, I just started messing around with Meshtastic, and it is apparent it's more of a beta project. Has lots of little bugs, no real routing, etc. Seems like the user-base outpaced development. It is pretty cool though, and I hope they fix the glaring issues quickly.
2
lightrush - 4mon
You're in the GTA right? What's your tag? I'm OO1, OO2, OO3.
2
Rentlar - 4mon
Currently in Vancouver. I play with it on certain weekends only though so far with some Heltecs. I'll be in Toronto next in the fall sometime (hopefully after the fabled Eglinton Crosstown opens 🤣).
3
shortwavesurfer @lemmy.zip - 4mon
My first thought would be to encrypt the profile broadcast with your private key and then broadcast it and then broadcast the public key second. That way, if the public key was not correct, they could not decrypt the profile broadcast at all.
Then again, I'm just a normie, so that's just a thought from somebody who doesn't fully understand the intricacies, so I could be way off base.
9
Arthur Besse - 4mon
In asymmetric encryption, the private key is used for decrypting things which were encrypted using the corresponding public key. You don't encrypt things using the private key.
The problem here is that Meshtastic doesn't have any means whatsoever of ensuring that a public key is authentic, and they allow keys to be replaced at any time. Verifying keys out-of-band would be the most secure approach, but to enable encryption between nodes who don't do that the thing Meshtastic should be doing is ssh-style TOFU (meaning that users must explicitly acknowledge when a key changes before using the new key).
9
shortwavesurfer @lemmy.zip - 4mon
Oh, definitely, when keys change, you should be required to acknowledge the new key.
7
shortwavesurfer @lemmy.zip - 4mon
I may be thinking of signing. The idea is that you would have a message that's only proven to be authentic if you get the corresponding key. I probably just have the wrong terminology or something.
6
Arthur Besse - 4mon
Yes, you can make a signature using the private key and anyone can verify it using the corresponding public key.
But, if the attacker can replace the public key they can also replace the signature with one made using their own key - so this doesn't solve the problem of keys being unverified.
If public keys were actually verified, signatures could protect the other fields in the profile packet from being modified. You could also theoretically use signatures to authenticate key rotation, by signing a packet containing your new public key using your old private key. But this doesn't really work in the unreliable radio setting where some messages are likely to be missed.
7
shortwavesurfer @lemmy.zip - 4mon
Yeah, you absolutely need trust on first use and not allowing a new key to be used until the user has said that they trust it.
3
lightrush - 4mon
Err, is it just me or does the Android client stop exchanging DMs in an existing chat if a public key changes? I've had to delete conversations between my nodes to reenable comm after regenerating one node's public key.
1
borokov @lemmy.world - 4mon
Meanwhile, radioamater enthusiasts chatting clear morse that you can listen from literally anywhere in the globe 🤣
6
Captain Aggravated - 4mon
Encryption is almost entirely illegal on the ham bands. You can encrypt control signals to satellites but that's about it.
3
deafboy @lemmy.world - 4mon
As far as I remember, the end-to-end encrypted DMs are relatively recent thing in Meshtastic. Before, the messages were just encrypted with the symetric channel key.
The scale of meshtastics avoidance of building security into the design is pretty epic.
This is not an easy problem to solve. Each possible solution requires a trade-off.
4
Hello Hotel - 3mon
Meshtastic's low privicy design is just dissappointing! I wish persistant identifiers were way less relied apon as they are given out freely in order for the system to work. Verry much NOT designed for urban areas or being in the presence of adversaries.
There should be "discovery" metadata, encrypted "known" and encrypted "well known" metadata, each with a diffrent encryption key that is given out in stages over a few round trips and maybe some user TOFU prompts and/or auto promotion on a timer. Brand new radios will gain trust with other radios.
"Known" gives an identifier and public key based on the context, maybe per gps area or per individual device.
"well known" being enough to preform persistant non contextual identification for the lifetime of the device.
Actions like karking a device as a "favorite" may also push it into the "well known" catagory.
cypherpunks in meshtastic
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)
https://partyon.xyz/@nullagent/115005279479795061This is the kind of security research we need. By bringing up these issues, they can be fixed.
Yeah, I didn't have any current expectations about the privacy, anything beyond security-by-obscurity which is absolutely not reliable for any important private conversation.
I'm pretty much chatting with complete strangers on the network anyway, and the usefulness I see is as a secondary communication band if traditional networks aren't available in a crisis. The PSK sounded more like a channel filter than an encryption mechanism to me anyway (I hope my past comments describing meshtastic were clear about this).
I'm all for identifying these flaws and fixing them, improving the protocol in future version so that maybe eventually it can be suitable for sensitive information than hobbyist blather or emergency info.
Yeah, I just started messing around with Meshtastic, and it is apparent it's more of a beta project. Has lots of little bugs, no real routing, etc. Seems like the user-base outpaced development. It is pretty cool though, and I hope they fix the glaring issues quickly.
You're in the GTA right? What's your tag? I'm OO1, OO2, OO3.
Currently in Vancouver. I play with it on certain weekends only though so far with some Heltecs. I'll be in Toronto next in the fall sometime (hopefully after the fabled Eglinton Crosstown opens 🤣).
My first thought would be to encrypt the profile broadcast with your private key and then broadcast it and then broadcast the public key second. That way, if the public key was not correct, they could not decrypt the profile broadcast at all.
Then again, I'm just a normie, so that's just a thought from somebody who doesn't fully understand the intricacies, so I could be way off base.
In asymmetric encryption, the private key is used for decrypting things which were encrypted using the corresponding public key. You don't encrypt things using the private key.
The problem here is that Meshtastic doesn't have any means whatsoever of ensuring that a public key is authentic, and they allow keys to be replaced at any time. Verifying keys out-of-band would be the most secure approach, but to enable encryption between nodes who don't do that the thing Meshtastic should be doing is ssh-style TOFU (meaning that users must explicitly acknowledge when a key changes before using the new key).
Oh, definitely, when keys change, you should be required to acknowledge the new key.
I may be thinking of signing. The idea is that you would have a message that's only proven to be authentic if you get the corresponding key. I probably just have the wrong terminology or something.
Yes, you can make a signature using the private key and anyone can verify it using the corresponding public key.
But, if the attacker can replace the public key they can also replace the signature with one made using their own key - so this doesn't solve the problem of keys being unverified.
If public keys were actually verified, signatures could protect the other fields in the profile packet from being modified. You could also theoretically use signatures to authenticate key rotation, by signing a packet containing your new public key using your old private key. But this doesn't really work in the unreliable radio setting where some messages are likely to be missed.
Yeah, you absolutely need trust on first use and not allowing a new key to be used until the user has said that they trust it.
Err, is it just me or does the Android client stop exchanging DMs in an existing chat if a public key changes? I've had to delete conversations between my nodes to reenable comm after regenerating one node's public key.
Meanwhile, radioamater enthusiasts chatting clear morse that you can listen from literally anywhere in the globe 🤣
Encryption is almost entirely illegal on the ham bands. You can encrypt control signals to satellites but that's about it.
As far as I remember, the end-to-end encrypted DMs are relatively recent thing in Meshtastic. Before, the messages were just encrypted with the symetric channel key.
This is not an easy problem to solve. Each possible solution requires a trade-off.
Meshtastic's low privicy design is just dissappointing! I wish persistant identifiers were way less relied apon as they are given out freely in order for the system to work. Verry much NOT designed for urban areas or being in the presence of adversaries.
There should be "discovery" metadata, encrypted "known" and encrypted "well known" metadata, each with a diffrent encryption key that is given out in stages over a few round trips and maybe some user TOFU prompts and/or auto promotion on a timer. Brand new radios will gain trust with other radios.
"Known" gives an identifier and public key based on the context, maybe per gps area or per individual device.
"well known" being enough to preform persistant non contextual identification for the lifetime of the device.
Actions like karking a device as a "favorite" may also push it into the "well known" catagory.