Is a mesh network secure?

In a familiar network, your message passes through equipment run by an operator you have chosen to trust: a mobile carrier, an internet provider, a messaging company. In a mesh network, it passes through whatever devices happen to sit between you and the recipient. Those may belong to strangers, and anyone can bring a device that joins in.

So the useful question is not whether the mesh shape is secure, but what a hostile or broken relay could do, and what stops it. Protection at the radio link is not enough on its own. NIST’s guide to Bluetooth security points out that Bluetooth encrypts and authenticates individual links only: data is decrypted at intermediate points, and end-to-end security has to be added on top. In a multi-hop mesh, every relay is one of those intermediate points.

The IETF’s catalogue of generic threats to routing protocols, RFC 4593, gives names to most of the problems a mesh faces, because in a mesh every device is a router.

• Eavesdropping. An attacker can sniff traffic on a link, or attract traffic through a node it controls, and read the data or at least the pattern of who sends what, and when.
• Tampering and replay. A forwarder can delete, insert or substitute data in what it passes on, or replay old data as if it were current.
• Impersonation. If devices cannot prove who they are, a node can claim to be someone else, inject messages in their name, or pretend to be the intended recipient.
• Dropping traffic. RFC 4593 describes a blackhole: traffic is drawn through one node, which then drops many or all packets. A relay can also delay or discard selected messages and keep forwarding the rest.
• Overload. A node can send so many routing messages that others exhaust memory, processor time or battery. RFC 4593 calls this a clog.
• False splits. An attacker can make part of the network believe it is cut off when it is not, the attack form of a network partition.

Three layers of defence answer most of this.

End-to-end encryption. If content is encrypted for the recipients alone, relays carry ciphertext they cannot read or alter undetected. This is end-to-end encryption, and it is what makes untrusted relays tolerable. Messaging Layer Security (MLS), standardised as RFC 9420, is built for exactly this setting: it assumes a largely untrusted delivery service and is designed to protect the confidentiality and integrity of group data even if that service is compromised.

Authentication. Encryption only helps if you are encrypting to the right key. Each device needs a key pair, and other devices need a way to bind a public key to an identity. MLS relies on an authentication service for this, and RFC 9420 notes that compromising it is much more serious than compromising delivery, because it allows impersonation. Without a central directory, devices can verify keys in person or rely on trust on first use.

Protected routing. Routing and control messages need integrity as well, or an outsider can steer traffic. For mobile ad hoc networks, the IETF defines integrity check values and timestamps that can be attached to packets and messages (RFC 7182), so a router can reject a control message as insecure before processing or forwarding it.

Signatures and encryption are different protections, and a design can mix them. In Offline Protocol’s mesh SDK, for instance, application messages and groups use MLS, while service advertisements, requests and responses are signed plaintext: tamper-evident and attributable, but readable by anyone who observes them.

Encryption and signatures stop relays reading and forging. They do not make relays cooperate. RFC 9420 is explicit that a compromised delivery service cannot forge messages but can selectively delay or remove them, or permanently block a member, and that this is not always detectable. In a mesh, every relay is part of the delivery service. Redundant paths, acknowledgments and retries are the practical answer.

Metadata is the other gap. Even when content is hidden, relays can see when traffic flows, how much, and often between which devices. What can go wrong with encryption in a mesh messaging app? covers this and other failures, such as unverified keys and shared group keys.

Finally, the endpoints still matter. A stolen phone with its keys, or an app that accepts any well-formed command from any authenticated device, is a weakness no transport can fix. Authorisation, which identities may do what, belongs to the application.

• Is content encrypted end to end, not just per link?
• How does a device learn that a public key belongs to the person or device it claims to?
• Are routing and control messages signed or integrity-protected?
• What happens when a relay silently drops messages?
• Which metadata is visible to relays?
• Where does the application check authorisation?