How to prevent "unauthorized" nodes to connect to the mesh?

[NorbertSandor]

Is there a way to "authorize" nodes connecting to the mesh? How can I avoid foreign nodes from my neighborhood connecting to my master? I'm thinking of very simple things, like the requirement to send a "secret key" to the master node when connecting to the mesh...

[2bndy5]

There's nothing built into the library for this. TMRh20 made some headway in nrf_to_nrf lib which uses the nRF52840's embedded crypto chip/lib (see TMRh20/nrf_to_nrf#7).

Otherwise you would have to filter out (or augment) NETWORK_REQ_ADDRESS (system message) types on the mesh master (between calls to mesh.update() and mesh.DHCP()). Then do some kind of security check...

I'm not going to lie; this isn't a beginner task. It would involve changing some of the default behavior in the network layers (RF24Network & RF24Mesh).

[TMRh20]

There is a simple method that I use on my master node that just uses a list of authorized nodes. For unauthorized nodes it checks against the address list and sets the network address to 0 so they cannot communicate properly using rf24 mesh.

[NorbertSandor]

Thanks for the tips!

One more idea: is there a way on the master to disconnect a node? The idea is to let any node connect but kick out the nodes not sending an "authorization message" in 2-3 seconds.

[2bndy5]

Again security measures were not part of the network layers' design. Looking at how mesh.releaseAddress() works, I think all master needs to do is de-allocate the assigned address as is done with a MESH_ADDR_RELEASE type message: https://github.com/nRF24/RF24Mesh/blob/38ee0225c336349fab513907f9798d308d2db497/RF24Mesh.cpp#L90-L97

There is no way to explicitly tell a child node to disconnect. A disconnection from mesh is mainly implied through failure to communicate with master.

[NorbertSandor]

Thanks for the insights!

[Avamander]

I'd direct the attention here to the actual attack model, how and what is being attacked and why?

Is it to protect against some kind of resource exhaustion attack? In that case the issue is that the available bandwidth on a channel with these radios is really small anyways, there's also no spread spectrum or RTS in the radio itself, so rejecting nodes doesn't protect against a DoS. An attacker can just spam whatever and drown other stuff out.

So all that remains after DoS protection is protecting against forgeries. That can be achieved on the layer above. I'm not super sure how nrf_to_nrf does it, but RF24Signing I wrote for fun at some point just uses an HMAC for that.

There might be other smaller attack vectors, but I can't recall any right this instant.

EDIT: Didn't see the last comment before submitting mine 😃

[2bndy5]

Security features for the network layers aren't queried/requested often, but it would be more convenient (and require a considerable effort) to #ifdef some basic security measures into the network layers. It could even use a "leveling" hierarchy:

• RF24Mesh_SECURE_LVL0 could just employ a hard-coded key (limited to 24 bytes because we wouldn't fragment network poll messages)
• RF24Mesh_SECURE_LVL[n-m] (where [n-m] spans levels of stricter security measures) could employ an external crypto chip

Extra compensation (like extended wait time for response from master) may be needed when augmenting the mesh connection process

Anything using an external crypto chip wouldn't work with ATTiny (obviously), so the theorized security features would have to be disabled by default (to preserve backward compatibility).