Skip to main content

Updated Security Implementation

PSK for Channels, PKC for Direct Messages and Admin Messages​

Up to version 2.4.x of the firmware, Meshtastic relied entirely on Pre-Shared Key (PSK) cryptography for all messaging. Starting with firmware version 2.5.0, Meshtastic introduced Public Key Cryptography (PKC) for Direct Messages (DMs) and added Session IDs for Admin Messages. Together, these enhancements bring the security architecture of Meshtastic to a new level of robustness.

Below is a detailed overview of how PSK, PKC, and Session IDs are integrated into your system to secure Channels, Direct Messages, and Admin Messages.

1. Chat Channels Using PSK​

  • PSK Overview:

    • Chat Channels continue to utilize a PSK for encrypting communications.
    • All participants share the same PSK for their Channels, which is used for both encryption and decryption within the channel.

  • Security Considerations:

    • Confidentiality: Only participants with the correct PSK can access messages within the Chat Channel.
    • Key Management: Secure distribution and regular rotation of the PSK are essential to maintaining the channel's security.

2. DMs Now Using PKC​

  • PKC Implementation for DMs:

    • Public/Private Key Pairs: Each node is equipped with a unique public/private key pair. The private key is securely stored on the node, and the public key is shared with other nodes, allowing for secure, authenticated communication.
    • Encryption and Signature:
      • Encryption: DMs are encrypted using the recipient’s public key, ensuring only the recipient with the corresponding private key can decrypt the message.
      • Digital Signatures: DMs are signed with the sender’s private key before encryption, allowing the recipient to verify the sender’s identity and the message’s integrity using the sender’s public key.

  • Security Enhancements with PKC:

    • Message Confidentiality and Integrity: With PKC, each DM is encrypted and signed, ensuring that only the intended recipient can read the message, and verifying that it has not been tampered with.

3. Admin Messages: Enhanced Security with PKC and Session IDs​

  • Key Exchange with DH Curve25519:

    • Initial Key Exchange Setup:

      • Key Generation: A Diffie-Hellman (DH) key exchange occurs using Curve25519 upon first communication between nodes. This generates a shared secret for establishing a symmetric encryption key.
      • Hardware Support: Curve25519 is supported in hardware, ensuring efficient and secure key exchanges.
      • Shared Secret: The derived shared secret is used for all subsequent communications between the nodes.

    • Use of Shared Secret for Encryption:

      • Symmetric Encryption: Following the key exchange, messages are encrypted and decrypted using the shared secret with symmetric encryption algorithms like AES-CTR or AES-CCM.
      • Efficiency: Symmetric encryption, especially when based on a secure DH exchange, balances security and performance, making it ideal for real-time applications.

  • Session ID for Admin Messages:

    • Session ID Usage: Session IDs are generated for each admin session and used as an additional value inside the encrypted packet. This ensures that each session is secure and unique.

    • Session Duration: The session ID is valid only for a short duration (e.g., 300 seconds) and is discarded once the session ends or after the next control message is sent.

    • Security Enhancements with PKC and Session ID:

      • Replay Attack Mitigation: By utilizing session IDs, replay attacks are effectively mitigated. Old session IDs cannot be reused, ensuring that intercepted packets are invalidated.
      • Isolated Impact: The use of session IDs confines any issues related to session management to admin messages, without affecting broader communication functions like DMs or Chat Channels.

4. Overall Security Architecture​

  • Integration of PKC with Existing Systems:

    • Direct Messages: PKC enhances the security of DMs by providing encryption, authentication, and integrity through the use of asymmetric encryption and digital signatures.
    • Admin Messages: The combination of PKC and session IDs secures admin-related operations, providing an additional layer of protection for critical functions.

  • Use of PSK with Existing Systems:

    • Channels: PSKs continue to be used for group communication, ensuring secure message exchanges within the channel.

  • Scalability and Performance:

    • Efficient Use of Resources: PKC for DMs leverages asymmetric encryption for secure communication, while PSKs for Chat Channels and session IDs for admin messages optimize resource consumption on the platform.
    • Memory Management: The selective use of PKC, PSKs, and session IDs ensures that memory and computational resources are effectively managed, allowing the system to scale while maintaining high security.

Trust Model and Operational Security​

The cryptographic protections described above (PSK, PKC, Session IDs) defend messages as they traverse the LoRa mesh. They sit on top of two assumptions that operators should understand: the link between a node and a directly connected client is trusted, and node identity is established via Trust On First Use rather than a signing authority.

Local Trust Boundary​

A client connected to a node over Bluetooth, USB serial, WiFi, or Ethernet has full local API access. From that local connection, a client can read decrypted channel traffic, send messages as the node, change configuration (subject to managed mode), and read the node's private key for backup. The on-air cryptography does not extend below this boundary. Anything inside scope of the local trust relationship (a shared LAN, a USB cable to an untrusted host, a phone paired over Bluetooth) should be treated as an extension of the node itself.

Node Identity: Trust On First Use (TOFU)​

Meshtastic uses a Trust On First Use (TOFU) model for node identity. There is no central authority that signs node keys, so the first public key a node hears for a given NodeNum is the one it binds to that NodeNum going forward. This is a hard requirement of operating as a decentralized ad-hoc mesh.

Client applications and the firmware include mitigations for the consequences of TOFU, such as favoriting nodes to prevent NodeDB rolloff and surfacing public-key changes in the UI. Firmware 2.8.X further strengthens node identity claims and message authenticity by adding XEdDSA packet signing, which reuses each node's existing X25519 key pair to sign User packets and other short packets so receivers can verify that a packet came from the holder of the bound public key. For the detailed discussion of NodeDB limits, spoofing edge cases, and the XEdDSA design, see Known Limitations and Future Plans of Meshtastic's Encryption.

Local Administration Over WiFi​

warning

Administering a Meshtastic node over an untrusted WiFi network, including setting WiFi credentials on an ESP32, is not recommended. All local admin traffic, not just the initial credential write, is exposed to that network.

When a client reaches a node over WiFi or Ethernet, that connection is part of the trust boundary described above. If the underlying network is untrusted (open WiFi, a network shared with parties you do not control), config writes, key reads, decrypted message traffic, and the WiFi PSK itself during provisioning are all exposed on that network. Setting network.wifi_ssid and network.wifi_psk over an untrusted WiFi connection is a common case of this exposure but not the only one.

The recommended pattern is to provision and administer nodes over a trusted channel: Bluetooth from a phone, USB serial to a trusted host, or Remote Administration over the mesh itself. There is no current roadmap item to secure local administration over untrusted WiFi; it may be addressed in a future release.

Conclusion​

Meshtastic layers three mechanisms: PSK encryption for channels, PKC for direct and admin messages, and session IDs for replay protection on admin sessions. These choices are shaped by hard platform constraints, chiefly the 256 byte LoRa packet limit and the limited memory of the supported MCUs, which bound how much cryptographic overhead each packet and each node can carry. These mechanisms operate within the trust and identity model described above: protections on the air do not extend to the local API surface, and node identity rests on TOFU rather than a signing authority.

DiscordXFacebookInstagramYouTubeRedditBlueskyMastodonTelegram