mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2025-02-02 08:42:11 -08:00
Code Issues Actions Packages Projects Releases Wiki Activity

add Jorropo's encryption review

Browse source
This commit is contained in:
Jorropo 2024-06-04 02:43:02 +02:00
parent f3d9442be3
commit b610e34e08
1 changed files with 78 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

79
docs/about/overview/encryption.mdx
View file

@ -9,7 +9,7 @@ description: "Understand Meshtastic's encryption: optional network-wide AES256 s
## Explanation
Meshtastic provides AES256 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).
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.
@ -19,6 +19,72 @@ All periodic broadcasts (position, telemetry, etc.) the device sends out itself
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, see below 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 an other failure leaking the channel key such as:
- Accidently 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 encryption is not threatened by Quantum-Computers\* so realistic attack vectors are accidental miss-handling of channel keys and nodes being lost.
\*on the Quantum-Resistance of AES256 see:
- [this stackoverflow question, contain a bit of debates and two good answers](https://crypto.stackexchange.com/q/6712)
- [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, everything sent on a channel can be stored and decrypted later by anyone who gain access to the key even if you locally delete the messages.
- Change your Channel Keys from time to time.
### Integrity
Integrity means ensuring messages cannot be modified without the key.
Meshtastic does not check messages have not been tempered with, see [`#4030`](https://github.com/meshtastic/firmware/issues/4030) for details.
**Recommendations**:
- Keep in mind, by applying a known plaintext attack anyone *could* send messages on a channel even with 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).
### 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), theses 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 make all messages bigger and or require an interactive handshake process.
**Recommendations**:
- Keep in mind, the sender field is indicative and anyone with access to the channel key can trivially lie.
## Direct-Messages
Direct-Messages are implemented as channel messages which have a `to` protobuf field set.
This means anyone in the channel can read all your direct-messages.
Also the node needs to know the right channel to use, this is done by using the latest one a NodeInfo was received, due to the lack of `Authentication` this means anyone you share a channel with can send a spoofed NodeInfo and make you send direct-messages on an incorrect public channel.
**Recommendations**:
- Keep in mind, due to NodeInfo spoof issue Direct-Messages are **very significantly less secure than a private channel** with a secure PSK.
- Do not use Direct-Messages for anything private, instead ahead of time create a new private channel and share it with the person you want to message with.
- Nodes will relay encrypted packets even if they can't decrypt it, so you only loose on some [small DM optimizations](https://github.com/meshtastic/firmware/pull/3753).
- Do not send the private channel key in direct messages or a public channel, because then anyone listening gain access.
- Use a different private channel for each person you want to have private conversations with.
## Comments
Cryptography is tricky, so we've tried to 'simply' apply standard crypto solutions to our implementation. However, the project developers are not cryptography experts.
@ -72,3 +138,14 @@ I'm assuming that meshtastic is being used to hike in places where someone capab
- Two other things to keep in mind are that AES-CTR does not itself provide authenticity (e.g. an attacker can flip bits in replaying data and scramble the resulting plaintext), and that the current scheme gives some hints about transmission in the size. So, if you worry about an adversary deliberately messing-up messages or knowing the length of a text message, it looks like those might be possible.
I'm guessing that the network behaves somewhat like a store-and-forward network - or, at least, that the goal is to avoid establishing a two-way connection to transmit data. I'm afraid I haven't worked with mesh networks much, but remember studying them briefly in school about ten years ago.
### Comments from @Jorropo
- The IV initialization only use 31 random bits per reboot, it then increment messages sequentially. This is not high, it makes duplicate unlikely but probable given the complete scale of the network. Thankfully IV include lower 32 bits of the MAC address which should be unique per node, so each node is it's own birthday paradox, we aren't looking for network wide birthday paradox which would be easy to hack. See [`#4031`](https://github.com/meshtastic/firmware/issues/4031).
Could be fixed.
- The lack of [integrity wasn't properly considered](https://github.com/meshtastic/firmware/issues/4030), the remote administration module implements priviliged RPC calls over AES-CTR without any MAC or AEAD.
Could be fixed.
- The AES-CTR implementation looks like it protects Confidentiality assuming IVs are not duplicated.
- The lack of Forward Secrecy is a bit worrying for a chat messenger when new users lack the paranoid and annoying key management practice that would be required for safe operation.
- IMO the clients should have a big red box the first time you open a Direct-Message indicating theses are not private and not E2E. This was not clear to me without reading the code.
- This project is completely fine for chatting with strangers, using the default key and understanding everything is public, I would not trust it with anything private without some other layer or significant reworks. For example I would consider SSH or Signal over Meshtastic safe. Yet Meshtastic does not choose to have worse crypto for bad reasons, they make the network significantly more usable over the unreliable slow LoRa backhaul it is using.