It was discovered that the flashing procedure of several hardware vendors was resulting in duplicated public/private keys. Additionally, while triaging this issue, it was discovered that the Meshtastic usage of the rweather/crypto library was failing to properly initialize the internal randomness pool on some platforms, leading to possible low-entropy key generation.
Impact
When users with an affected key pair sent Direct Messages, those message could be captured and decrypted by an attacker that has compiled the list of compromised keys.
The remote administration feature is also affected in two ways. First, if a compromised key is added as a remote administrator, anyone with access to that private key could admin the node. The case of the remotely administrated node having the compromised key pair is slightly more complex. Here an attacker would have to determine the public key of an authorized administrator, and use the compromised private key to produce the resulting shared_key, and use that to impersonate the administrator, and send commands to the remote node.
Patches
Version 2.6.11 will warn users when a compromised key is detected. It also delays key generation til the first time the LoRa region is set, eliminating the vendor cloning issue. It also adds multiple sources of randomness to the rweather/crypto RND initialization. Version 2.6.12 will be released as a future update, and will automatically wipe known compromised keys when found.
Workarounds
A user can do a complete device wipe, using the Python Command Line Interface: "meshtastic --factory-reset-device"
While this will clear a vendor-cloned key, it may still be somewhat low entropy depending on the platform. If a truly high-entropy key is required, you can use the Openssl program and convert the result to base64: openssl genpkey -algorithm x25519 -outform DER | tail -c32 | base64
It was discovered that the flashing procedure of several hardware vendors was resulting in duplicated public/private keys. Additionally, while triaging this issue, it was discovered that the Meshtastic usage of the rweather/crypto library was failing to properly initialize the internal randomness pool on some platforms, leading to possible low-entropy key generation.
Impact
When users with an affected key pair sent Direct Messages, those message could be captured and decrypted by an attacker that has compiled the list of compromised keys.
The remote administration feature is also affected in two ways. First, if a compromised key is added as a remote administrator, anyone with access to that private key could admin the node. The case of the remotely administrated node having the compromised key pair is slightly more complex. Here an attacker would have to determine the public key of an authorized administrator, and use the compromised private key to produce the resulting shared_key, and use that to impersonate the administrator, and send commands to the remote node.
Patches
Version 2.6.11 will warn users when a compromised key is detected. It also delays key generation til the first time the LoRa region is set, eliminating the vendor cloning issue. It also adds multiple sources of randomness to the rweather/crypto RND initialization. Version 2.6.12 will be released as a future update, and will automatically wipe known compromised keys when found.
Workarounds
A user can do a complete device wipe, using the Python Command Line Interface: "meshtastic --factory-reset-device"
While this will clear a vendor-cloned key, it may still be somewhat low entropy depending on the platform. If a truly high-entropy key is required, you can use the Openssl program and convert the result to base64:
openssl genpkey -algorithm x25519 -outform DER | tail -c32 | base64