mirror of
https://github.com/meshtastic/meshtastic.git
synced 2024-11-15 18:14:19 -08:00
a5c740f542
* Initial Update to Encryption Overview for 2.5 PKI Updates * Additional changes from @Jorropo comments. * Padding and some seperation of Pre/Post 2.5 changes for DM and Admin Control * Added a Encryption Technical Located Under Dev > Reference Material Seperate for the Encryption Overview * Minor edits * Integrity updates for post v2.5.0 * trunk fmt and add security section (moves needed ones too) * formatting technical page, change PKI to PKC. * move comments to its own sub-page * feedback, change PKI to PKC, formatting * DontMqttMeBro * Fix Grammar in Mqtt Page * oopsies * add android and web * test * more fixes --------- Co-authored-by: rcarteraz <robert.l.carter2@gmail.com>
116 lines
8.7 KiB
Plaintext
116 lines
8.7 KiB
Plaintext
---
|
|
id: encryption
|
|
title: Meshtastic Encryption
|
|
sidebar_label: Encryption
|
|
slug: /overview/encryption
|
|
sidebar_position: 3
|
|
description: "Understand Meshtastic's encryption: optional network-wide AES256 security for off-grid communication, ensuring confidentiality against passive eavesdropping."
|
|
---
|
|
|
|
## Explanation
|
|
|
|
Meshtastic provides AES256-CTR encryption for the payload of each packet when sending via LoRa, with a different key for each [channel](/docs/configuration/radio/channels/). The [packet header](/docs/overview/mesh-algo/#layer-1-unreliable-zero-hop-messaging) 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](/docs/configuration/radio/device#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](/docs/configuration/module/mqtt#encryption-enabled) 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](https://en.wikipedia.org/wiki/WPA3), [TLS1.3](https://en.wikipedia.org/wiki/TLS1.3), [Signal](https://en.wikipedia.org/wiki/Signal_Protocol), 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
|
|
|
|
[**P**erfect-**F**orward-**S**ecrecy, also known as **PFS**](https://en.wikipedia.org/wiki/Forward_secrecy), 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 »**](https://en.wikipedia.org/wiki/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-resistant[^1], 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.
|
|
|
|
[^1]: On the Quantum-Resistance of AES256, see [this stackoverflow question, containing a bit of debate and two good answers](https://crypto.stackexchange.com/q/6712) and the [NIST's Post-Quantum FAQ](https://csrc.nist.gov/projects/post-quantum-cryptography/faqs) section "To protect against the threat of quantum computers, should we double the key length for AES now? (added 11/18/18)"
|
|
|
|
#### 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](https://github.com/meshtastic/firmware/issues/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](https://github.com/meshtastic/firmware/issues/4030).
|
|
|
|
#### 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](https://en.wikipedia.org/wiki/MAC_address), which are hardcoded by the manufacturer.
|
|
|
|
Some other networks like [Yggdrasil](https://yggdrasil-network.github.io/), [cjdns](https://github.com/cjdelisle/cjdns), or [libp2p](https://libp2p.io/) use [public/private key pairs](https://en.wikipedia.org/wiki/Public-key_cryptography), 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.
|