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
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.
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.