Hi, I recently learned about Meshtastic an I’m very excited as it could be a huge problem solver for my organization. However, one thing I want to be more sure of is the security of the communication. My organization works in some counties that are hostile to free and open journalism, as well in very remote regions. Naturally for these two reasons Meshtastic seems very appealing.
My organization is willing to put up some bounties on bountysource to encourage the development of strong encryption standards and software hardening of these devices. But, as you may be able to tell, I am no developer myself and I need someone to open issues in the github to that I can post to bountysource. Ideally these issues would address strengthening the encryption implementation and another issue of hardening potential attack surfaces.
Let me know if this would be possible. Thank you for everyone’s hard work on this project!
I’m one of the authors of meshtastic.js, I originally started contributing to the library with crypto in mind.
I’m aiming to to hardware crypto on the client device, including mixed symmetrical and asymmetrical encryption supporting secure group messaging and validation using ECDSA.
This is all possible by simply passing your encrypted data via the sendData() which accepts simple byte arrays
That desire seems quite reasonable. With a bit of work to make the meshtastic security more secure (and provably secure) I could see this as a great possible application. ie: secure messaging in a region without needing sats, and with each node able to store and forward for any other (optionally with location info).
In particular you might find the list of four areas for future work to be helpful. This list was prepared as part of our initial implementation review.
How about adding support in the android and web apps for disappearing messages.
All the security in the world doesn’t help if the end user device can simply be snatched and read.
Support for a panic button could be useful as well. A physical button (or combination of) could send a predefined message to alert other users you may be compromised then reset the device to a default channel and clear any potentially sensitive information.
Along those lines a private mode of the apps could be added that requires a pin code to view anything within the app with the option of clearing data if the wrong, or another defined pin is provided. With a timeout setting this could make it harder to compromise to network and communications if a user is physically compromised.
A physical wrench is likely a bigger security threat than an agency using advanced hardware and software to covertly monitor the wireless transmissions.
IMHO, packet integrity (“authentication”) is worth investigating. While easy to implement (Encrypt-then-MAC), the problem is that it will increase packet length and thus airtime.
Perfect forward secrecy as mentioned on Github requires public key cryptography and will be difficult to realize in a mesh where some nodes have intermittent connectivity or new nodes join and old leave the mesh.
