Key managment / whitelist questions

[Chad Goyette]

I’m looking for more detailed information on controlling which devices connect to a particular gateway. all my edge devices deployed will have the same network name and passkey credentials. There will be instances where multiple gateways may be in the same vicinity where device-A instead of connecting to gateway-A may connect to gateway-B. Is there a way at the gateway level to include the devices I want to connect based on the node ID (or something else) and have all other devices rejected?
the whitelist feature sounds like the tool I want to use but my next question is can this be maintained remotely? I have seen in device HQ a reference to cloud key management, what is this, and how do you manage it? Is there documentation on this providing more details to uses and limitations?

[Steve Kovarik]

Hi Chad

If all your LoRa end devices are configured identically and you use the same
network name and passkey credentials in the Gateways it becomes difficult.
If using the LoRa Network Server in the Gateway one possibility is to configure
different Gateways for a different “frequency sub band (FSB)”. The Conduit has a FSB configuration setting between 1 and 8 and is an 8-channel hybrid of
64 total channels. Configuring adjacent Gateways for a different FSB is one
way to filter LoRa end devices. However for this to work you will need to
configure the (same) frequency sub band setting in the LoRa endpoint device
relative to the Gateway you want it to Join. The cloud key management is a
future feature release with no documentation available yet. Configuring
unique keys per LoRa end device and in each Gateway is another way to filter
LoRa end nodes per gateway.

-Best Regards

[Jason Reiss]

With Steve’s advice the end-devices can be left at AT+FSB=0 64 channel mode. They will try each FSB until they join a conduit. It will join in less than 16 attempts.

The whitelist is configured in the db.json file within a config.tar.gz uploaded to DeviceHQ. This list can be modified on a PC or extracted from a development Conduit and pushed down to production Conduits through DeviceHQ.

Otherwise an application can enforce a whitelist by sending MQTT message to lora/EUI/clear topic when the lora/EUI/joined message is seen for end-devices you do not want to join.

[Chad Goyette]

Hi Jason,
Just to make sure I’m following you, you’re saying I can reject nodes with my current setup if my application has a whitelist and clears join messages for nodes, not on the list. What I’m trying to avoid is my installers reprogramming edge devices in the field with custom credentials.

[Jason Reiss]

Yes the application can stop the Join Accept from being sent based on EUI of the end-device.

A record will be entered into the database for the end-device that you may also want the application to clear out.

$ lora-query -x device delete EUI

As seen in the example below, the clear command blocks the packet_sent message. The second join_request is with the block disabled.

admin@mtcdt:/var/run/lora/1# mosquitto_sub -v -t lora/+/+
lora/00-00-00-00-00-00-27-10/join_request {"tmst":1150039354,"chan":8, ...
lora/00-00-00-00-00-00-27-10/packet_recv {"tmst":1150039354,"chan":8, ...
lora/00-00-00-00-00-00-27-10/joined {"remote_js":false}
lora/00-00-00-00-00-00-27-10/clear {"remote_js":false}

lora/00-00-00-00-00-00-27-10/join_request {"tmst":1167037612,"chan":7, ...
lora/00-00-00-00-00-00-27-10/packet_recv {"tmst":1167037612,"chan":7,...
lora/00-00-00-00-00-00-27-10/joined {"remote_js":false}
lora/00-00-00-00-00-00-27-10/packet_sent {"appeui":"16-ea-76-f6-ab-66-3d-80", ...

[Author]

Posts