Surprise me and don’t delete this post…
In March, some users discovered a critical vulnerability in Meshtastic’s use of AES encryption. Specifically, the node number (which is sent in the clear over the air) is used in combination with the “private” encryption key to generate the ciphertext.
As a result, an attacker can use the ciphertext and the nodenum to recover the encryption key, and can then decrypt the full message text.
Denial is not just a river in Egypt, fellas. This is a serious issue, and the refusal to acknowledge that it’s a problem is not a good look.
Is anyone planning on correcting this in the public repo?
No, I’m not submitting a pull request so it can be closed with a flip remark.
3 Likes
Are you perhaps referring to this issue discovered earlier in June?
[Bug]: missing integrity checks let attacker forge arbitrary message content using a known plaintext attack and replaying messages even when PSK is not known · Issue #4030 · meshtastic/firmware (github.com)
There is a pretty detailed write up of the problem in the Github issue. It affects the admin module and allows an attacker to modify a known admin packet. It’s quite a sophisticated attack that shouldn’t be any immediate risk to a mesh and steps to mitigate risk are mentioned. It does not allow an attacker to recover the pre-shared key.
There are plans to fix the issue, but the fix will be a breaking change to the protocol and as I mentioned, shouldn’t pose any immediate risk to your mesh.
2 Likes
No. This is a fundamental flaw in the AES enciphering method implementation, not a replay attack. Meshtastic uses the nodenum plus the private key to generate ciphertext. It should be a true random number instead of the node number. It’s a big problem - as it is now, no Meshtastic encryption is secured to the level that “AES256” implies. Fixing it would not break the protocol; the fix would be as invisible to most users as the current vulnerability is.
The IV is the node number. This is just lazy, and false security.
How would you change this so that old and new nodes can continue to communicate with each other and decrypt the content?
If that doesn’t work, the chain would be broken …
No, it’s a combination of the node number of the transmitter and the packet ID, which is randomized on boot: firmware/src/mesh/CryptoEngine.cpp at 3219d65387876e9582a5bd8c99bb5c15843d4344 · meshtastic/firmware · GitHub
I am pretty sure you are talking about the issues I found there are two bugs:
- [Bug]: missing integrity checks let attacker forge arbitrary message content using a known plaintext attack and replaying messages even when PSK is not known · Issue #4030 · meshtastic/firmware · GitHub RPC request forging using known plaintext attack
- [Bug]: nonces are only randomized with 31 bits, this make it rare but possible to see duplicated nonces in the wild threatening confidentiality of messages · Issue #4031 · meshtastic/firmware · GitHub decrypting messages sent with duplicated IVs with known plaintext attack
Neither allows to recover the encryption key, they use known plaintext attacks to recover the bitstream which is generated per Initial-Vector (nodeid concatenated with packetid), this means only particular messages can be attacked not the whole encryption key.
The first one #4030 is not a danger to almost anyone because it is dangerous only for the remote node administration module or other applications running on top of meshtastic. In the case
of remote administration there are a bunch of other requirements to perform the attack that makes is significantly less convenient than gaining hardware access.
Some guy trespassing with a ladder would be able to hack your nodes in minutes if not hours, while it is unlikely you even use the remote administration module.
The second one #4031 sounds more like what you describe but require high level (but not impossible) of lucks to even be exploitable, it allows to decrypt two messages that have duplicated Initial-Vectors if you know or guess one of the other messages (guessing is significantly easier to do than for #4030 in this case as we can assume sentences make sense and look like english and incrementally decrypt clusters of bits).
You need a node to reuse the IV (nodeid concatenated with packetid) for that attack to even be attemptable, you also need to capture the packets.
I don’t know how often reused IV happen in real life, we could scan MQTT packet databases to get an idea.
A node restarting often like once every second and sending a packet each time would happen in a couple of days if not weeks due to the birthday paradox.
For a node never restarting and sending one packet per second it would take 1/1hz * 2**31 ~= 60 years until IV reuse happens as packet ids are incremented sequentially.
Note: relayed packets don’t count.
3 Likes
I updated the encryption wiki page to add information about design decisions that make meshtastic less secure than other alternatives (see Is it as secure as Wi-Fi WPA3, HTTPS TLS1.3 or Signal ? and childrens sections) as well as include my opinions.
I think this is a good explanation of the main shortcomings.
Note: the shortcomings are design tradeoffs, fixing most of theses issues would:
- Make meshtastic packets bigger (thus less reliable).
- Interactive. You would need to first do a handshake, that means exchanging a couple packets in both directions before being able to talk to anyone, while right now meshtastic work with one way links.
- And lastly it makes trivial to skip not received messages (this avoid having to download 10 hrs of discussions at less than 1kb/s after someone move back in range before newer messages can be decrypted).
2 Likes
Someone capturing hardware that hasn’t been zeroized is always a serious concern with nearly any comm system, as is storage of traffic in anticipation of a future acquisition of a key.
I’m glad to see your edit. It does define the limitations far more clearly than the previous “It’s AES256, it’s secure” position.
In the short term, SSH or other applications that encrypt their traffic outside the Meshtastic protocol is probably the best solution.
It appears a redesign of the entire protocol, including routing issues, is ultimately needed to address this issue along with the other ones (unencrypted header/preamble, low reliability of message delivery, lack of authentication and PFS, etc.)
Thank you for publishing a more comprehensive statement of the security problem.
1 Like
This is the key thing I want everyone to get out 
, I’m very happy it worked on at least one person.