Securing Meshtastic traffic
This article will probably become outdated as Meshtastic grows. Please check Meshtastic documentation. More info: https://meshtastic.org/docs/overview/encryption/
Here’s how, from my understanding, one can secure it's Meshtastic traffic to ensure it remains private and protected.
Default Encryption: What You Need to Know
By default, Meshtastic encrypts data before it is transmitted over the air. However, the encryption key used is a well-known default key, "AQ=="
. This key provides minimal security and only obscures your data from the most inexperienced observers. To truly secure your transmissions, it’s crucial to replace this default key with a unique one.
Changing the default key is straightforward. Ensure that all devices on your network are configured with the same key to maintain communication compatibility.
The QR code is a handy mechanism that doesn't leak information unless a user accesses the QR code's URL on a javascript-enabled web browser, where the meshtastic.org website could access the part of the URL that includes the encryption key.
Using an MQTT Broker
When integrating Meshtastic with an MQTT Broker, you have the option to encrypt the messages sent to it. This encryption is the same as the one used over the air. If disabled, it will allow the data to travel in plain protobuf-encoded format.
And, if you choose to send information as JSON instead of as protobufs, this information arrives to the MQTT Broker unencrypted. This may perfectly be the intended effect (like if it is a private server or a public one where you expect to share information)... still, it is important to be aware of it.
Securing the MQTT Connection
The connection between a meshtastic device and the MQTT Broker can be in clear text or encrypted with TLS. A clear text connection offers no protection against eavesdropping, making it easy for anyone with network access to intercept your data.
Best Practices for Secure Meshtastic Communication
- Always Replace the Default Encryption Key: Never rely on the default key for securing your communications. Generate a strong, unique key for your network.
- Use Payload Encryption with MQTT: Even if your MQTT Broker is behind a firewall or VPN, encrypting the payload adds an additional layer of security.
- Enable TLS for MQTT Connections: This ensures that the connection to the broker is secure, preventing man-in-the-middle attacks and unauthorized data access.
By the way, as I was researching for this article, I've found this excellent article by Netscylla: https://www.netscylla.com/blog/2024/03/08/Meshtastic-Privacy.html that gives these additional recommendations:
- Disable the primary channel, or
- Change the channel name and encryption key
If you still want occasional access to LongFast, Set up a secondary channel, LongFast with the default encryption key
One key to rule them all
As all devices from the same network rely on a pre-shared key, if one devices is compromised the whole traffic of the network could be decrypted, and if a listener would have captured encrypted traffic over the air, it could also decrypt old messages.
So, the other strategy that needs to be considered is key rotation.
Have I missed something? What other things should be considered?
Member discussion