Skip to main content

Meshtastic Encryption

Explanation​

Meshtastic provides AES256-CTR encryption for the payload of each packet when sending via LoRa, with a different key for each channel. The packet header is always sent unencrypted, which allows nodes to relay packets they can't decrypt as well. One can disable this by setting a different rebroadcast mode.

By default, you have one primary channel, which is encrypted with a simple known key ("AQ=="), so to use proper encryption, you must change this key first, or create a new channel and share it with the ones you want to communicate with. However, if you don't have the default key, it means you will not be able to communicate with devices that don't have your key.

Direct messages to a specific node are now encrypted using Public Key Cryptography (PKC). Each node is equipped with a unique public/private key pair, and direct messages are encrypted with the recipient's public key. This ensures that only the recipient can decrypt the message using their private key. Additionally, messages are signed with the sender's private key, allowing the recipient to verify the sender's identity and ensuring the message's integrity.

All periodic broadcasts (position, telemetry, traceroutes, etc.) the device sends out itself are sent over the primary channel and thus encrypted with that key.

The device will decrypt the payload before sending it to a client app via BLE, serial, Wi-Fi/Ethernet. For MQTT, you can specify whether you want to send an encrypted or unencrypted payload.

Is it as secure as Wi-Fi WPA3, HTTPS TLS1.3, or Signal?​

No.

WPA3, TLS1.3, Signal, and Meshtastic can all use AES256. Yet AES is one of the many cogs required in a modern encryption system. Below are the main features "missing" in Meshtastic.

Perfect-Forward-Secrecy​

Perfect-Forward-Secrecy, also known as PFS, means previous communications and more generally anything passively captured cannot be decrypted even when the key is compromised.

This means Meshtastic is vulnerable to « Harvest now, Decrypt later » attacks. This attack itself is not enough to decrypt messages; it relies on another failure leaking the channel key, such as:

  • Accidentally sharing the channel key with the wrong person.
  • One of your nodes being stolen.
  • Any unknown bug revealing the channel key to an attacker.

Other protocols, such as misconfigured TLS1.2, are far more impacted by Harvest now, Decrypt later attacks because their keys will be broken by near-future Quantum-Computers, yet they do not provide PFS.

Meshtastic's AES256 encryption is considered quantum-resistant1, but the public/private key exchange for DMs is not, as current quantum-resistant cryptography schemes don't fit in LoRa packets or our IoT hardware; realistic attack vectors include accidental mishandling of channel keys, nodes being lost, and potential future quantum attacks on DM key exchanges.

Recommendations for users using private channels​

  • Do not configure private channels on unattended nodes. Nodes will relay Meshtastic traffic even if they are not able to decrypt it. Your unattended routers should not have the private PSK configured as it is easy to gain physical access and extract the channel key.
  • Keep in mind that everything sent on a channel can be stored and decrypted later by anyone who gains access to the key, even if you locally delete the messages.
  • Change your Channel Keys from time to time.

Changes since 2.5.0 Firmware release​

  • Direct Messages are now protected with PKC when messaging between devices on v2.5.0 or newer and key exchange has taken place, messaging to legacy 2.4.3 or older firmware versions are not protected.
  • Admin Messages between two v2.5.0 or newer nodes are now protected and additonal relay attack protection in place.

Integrity​

Integrity means ensuring messages cannot be modified without the key.

Meshtastic does not verify the integrity of channel messages to check if they have been tampered with (see issue #4030 for details).

Recommendations​

  • Keep in mind that by applying a known plaintext attack, anyone could send messages on a channel even if the channel key is private and secure.
  • For developers of third-party applications integrating Meshtastic, include a cryptographic MAC over the message content and PSK. We are also considering an AEAD secured channel mode which would provide this natively.

Changes since 2.5.0 Firmware release​

  • Message integrity is checked for Direct Messages or Admin Control when communication is between v2.5.0 or newer firmware.

Authentication​

Authentication means nodes say who they are on the network. Meshtastic does not implement this, so it is trivial to impersonate anyone else if you have access to the channel key

This is because node IDs are based on hardware MAC address, which are hardcoded by the manufacturer.

Some other networks like Yggdrasil, cjdns, or libp2p use public/private key pairs, and the Public Key becomes the Node Identity. This makes all messages bigger and/or requires an interactive handshake process.

Recommendations​

  • Keep in mind that the sender field is indicative, and anyone with access to the channel key can trivially lie.

Changes since 2.5.0 Firmware release​

  • The above now only relates to group chats/channels as DM's are protected when messaging between devices on 2.5 or newer, messaging to legacy 2.4 or older devices are not afforded this addition authentication.

Direct Messages​

Direct Messages (DMs) are now implemented using Public Key Cryptography (PKC). This provides a significant upgrade in security compared to the previous channel-based encryption:

  • Message Encryption: Each DM is encrypted using the recipient's public key, ensuring that only the recipient can decrypt the message with their private key.
  • Digital Signatures: Messages are signed with the sender's private key, allowing the recipient to verify the sender's identity and ensuring the integrity of the message.

Prior to 2.5.0 Firmware Release​

Previously, DMs were implemented as channel messages with a to protobuf field set. This meant anyone in the channel could read all your direct messages. With PKC, this issue is resolved, as only the intended recipient can decrypt and read the message.

Recommendations​

  • While PKC significantly enhances the security of DMs, it's still advisable to avoid sharing sensitive information in direct messages without proper verification of the recipient's public key.

Admin Messages​

Admin Messages/Control are now protected by enhanced security features, making sure that critical operations within the network are more secure than ever before.

  • Stronger Encryption: Admin Messages now use advanced encryption methods to ensure that only the intended recipients can access and read them.
  • Session IDs: Each administrative session is assigned a unique Session ID, which helps prevent unauthorized access and ensures that messages are not tampered with or replayed.

Prior to 2.5.0 Firmware Release​

Previously, admin messages were not as secure, but with these updates, they are now much better protected against potential attacks and replay attacks.

Recommendations​

  • Always ensure that your devices are using the latest firmware to benefit from these improved security features.
  • Regularly monitor your network for any unusual activity to maintain a high level of security.

Footnotes​

  1. On the Quantum-Resistance of AES256, see this stackoverflow question, containing a bit of debate and two good answers and the NIST's Post-Quantum FAQ section "To protect against the threat of quantum computers, should we double the key length for AES now? (added 11/18/18)" ↩