Meshtastic Encryption
Explanation
Meshtastic provides AES256-CTR encryption for the payload of each packet when sending via LoRaLoRaA low-power, long-range wireless communication technology used by Meshtastic devices to enable communication over distances of several kilometers without the need for cellular, Wi-Fi, or other traditional network infrastructures., 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, without a channel using the default key, communication with devices still using it will not be possible.
Direct messages to a specific node are now encrypted using Public Key CryptographyPKC (Public Key Cryptography). A cryptographic method introduced in Meshtastic v2.5 for Direct Messages and Admin Messages, where each device uses a unique public and private key pair. The public key, shared with other devices, enables secure message encryption, while the private key allows only the intended recipient to decrypt and authenticate the message. This approach enhances privacy and integrity for both direct device-to-device communication and sensitive admin functions. (PKCPKC (Public Key Cryptography). A cryptographic method introduced in Meshtastic v2.5 for Direct Messages and Admin Messages, where each device uses a unique public and private key pair. The public key, shared with other devices, enables secure message encryption, while the private key allows only the intended recipient to decrypt and authenticate the message. This approach enhances privacy and integrity for both direct device-to-device communication and sensitive admin functions.). 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 BLEBLE (Bluetooth Low Energy). The default wireless connection between a node and a phone client., serial, Wi-Fi/Ethernet. For MQTTMQTT (Message Queuing Telemetry Transport). A lightweight messaging protocol designed for small sensors and mobile devices, enabling efficient data transmission in the Meshtastic network for Internet connectivity and integration with IoT platforms. See https://en.wikipedia.org/wiki/MQTT. In Meshtastic, MQTT is used to connect a node to the internet, and can be used to connect multiple meshes to each other., 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 either.
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 LoRaLoRaA low-power, long-range wireless communication technology used by Meshtastic devices to enable communication over distances of several kilometers without the need for cellular, Wi-Fi, or other traditional network infrastructures. 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 PSKPSK (Pre-Shared Key). A secret code or passphrase used in Meshtastic channels for encryption, ensuring that only devices with the matching PSK can communicate within that specific channel. 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 PKCPKC (Public Key Cryptography). A cryptographic method introduced in Meshtastic v2.5 for Direct Messages and Admin Messages, where each device uses a unique public and private key pair. The public key, shared with other devices, enables secure message encryption, while the private key allows only the intended recipient to decrypt and authenticate the message. This approach enhances privacy and integrity for both direct device-to-device communication and sensitive admin functions. 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 additional relay attack protection is 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 PSKPSK (Pre-Shared Key). A secret code or passphrase used in Meshtastic channels for encryption, ensuring that only devices with the matching PSK can communicate within that specific channel.. 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 CryptographyPKC (Public Key Cryptography). A cryptographic method introduced in Meshtastic v2.5 for Direct Messages and Admin Messages, where each device uses a unique public and private key pair. The public key, shared with other devices, enables secure message encryption, while the private key allows only the intended recipient to decrypt and authenticate the message. This approach enhances privacy and integrity for both direct device-to-device communication and sensitive admin functions. (PKCPKC (Public Key Cryptography). A cryptographic method introduced in Meshtastic v2.5 for Direct Messages and Admin Messages, where each device uses a unique public and private key pair. The public key, shared with other devices, enables secure message encryption, while the private key allows only the intended recipient to decrypt and authenticate the message. This approach enhances privacy and integrity for both direct device-to-device communication and sensitive admin functions.). 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 protobufProtobuf (Protocol Buffers). A method developed by Google for serializing structured data, used in Meshtastic for efficient communication protocol between devices. field set. This meant anyone in the channel could read all your direct messages. With PKCPKC (Public Key Cryptography). A cryptographic method introduced in Meshtastic v2.5 for Direct Messages and Admin Messages, where each device uses a unique public and private key pair. The public key, shared with other devices, enables secure message encryption, while the private key allows only the intended recipient to decrypt and authenticate the message. This approach enhances privacy and integrity for both direct device-to-device communication and sensitive admin functions., this issue is resolved, as only the intended recipient can decrypt and read the message.
Recommendations
- While PKCPKC (Public Key Cryptography). A cryptographic method introduced in Meshtastic v2.5 for Direct Messages and Admin Messages, where each device uses a unique public and private key pair. The public key, shared with other devices, enables secure message encryption, while the private key allows only the intended recipient to decrypt and authenticate the message. This approach enhances privacy and integrity for both direct device-to-device communication and sensitive admin functions. 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.