Using XBee (X2B) security to prevent join?

Question

Is it possible to use the XBee (X2B) security to prevent join? It doesn't seem to allow this - data comm is blocked, but not (from the remote router's view point) being joined to a coordinator with security enabled.

I am trying to salvage some nodes sealed inside cases. Unfortunately, things like PAN and SC are hard-coded in FW, so I have 2 sets of equipment which 'mix' on 2 different Digi-X2D gway.

I had thought I could use security, as the sealed nodes allow me to change EE and KY remotely, however what I am seeing:

In coordinator (in Digi-X2D), it set EE=1 and KY={some key}. Great - just like example in PDF doc.

In the routers, which have EE=0 ... they STILL happily join the coordinator, merrily blinking their LED.

However, the coordinator does NOT see them; they don't show up on the GWay's xbee list.

If I add another test Router API node, it also gets into this happily-but-sad mode. XCTU allows me to show the network, with the Digi-X2D as coordinator and all the dumb-happy routers who think they belong to this broken network.

Is there a setting in the Xbee coordinator (all are the 0x2?A7 FW) which would prevent it from offering joining to any node with security disabled (EE=0)?

Answer 1

This is actually kind of a tricky problem caused by the fact that join process is split across a couple layers.

First is the initial MAC association which does not require any encryption.

Second is the Transport Key which is used to exchange key data if/when EE=1.

By having EE=0 on the joining devices they stop at the successful MAC association and never fail out due to missing/incorrect Transport Key. There is no immediate method to determine the EO setting of a remote device from the coordinator in order to know if it should be kicked off or not. Edge cases abound and not a safe operation.

If you can set EE/KY on the sealed nodes why not just set them to match one of your gateways so they join successfully then update any additional parameters via remote AT requests?

Comments

Thanks JL - that's what I'm seeing; the EE=0/unaware nodes just join & sit there happy & broken.

My problem is the devices are 'sealed' & most settings hard-coded by FW over-writes. Really I am most concerned about a documentable procedure. So I thought I'd have 1 coordinator with EE=0, and 1 coordinator with EE=1 ... and if lucky, the raw devices would connect to the EE=0 coordinator, allowing us to force in the EE=1 plus KY=??, which would cause them to move the 'correct' coordinator. Slick assembly line!

My problem is once the units boot & join 'someone', there is no easy way to move them. So if they boot (with EE=0), join the 'wrong' coordinator (with EE=1), then I'm hosed! I cannot talk to them & have no way to 'move' or network reset them ... unless I turn EE=0 on that 'wrong' coordinator & do it that way. But that's not such a great process paradigm for production.

True, it is a very silly product design, but I am working with the products I've inherited! It is a pity the ZB 'join' process doesn't include a 'want encrypt' or 'no  encrypt' flag - as it now has the Zb version and XBee/Digi extensions or not flags. That way the 'wrong' coordinator would not offer joining to a unit with mismatched encryption settings.

---

Just to confirm...

You have existing devices that are configured with EE=0. They need to be commissioned on the factory floor with their production configuration (EE=1 and KY=?). The device is sealed/etc such that you can't connect direct to the enclosed XBee and need to join with a compatible gateway (EE=0) to configure via remote AT commands. However along with the EE=0 gateway you also have an EE=1 gateway in the vicinity which is capturing some of the uncommissioned units when they are turned on.

If I had to guess, the EE=1 gateway is for production test that the device commissioning is successful so you can't just disable it completely.

Without modifying the sealed devices I think the main option you have is control NJ on the EE=1 gateway to disable joining while an uncommissioned device is attempting join to the EE=0 gateway. Set NJ=0x0 when you need a device to join with the EE=0 gateway initially, then set NJ=0xFF when you need to confirm the commissioning.

In a future revision a slightly cleaner method to resolve this would be to have the device firmware set JV=1 if EE=0. This will cause the XBee to confirm contact with the coordinator. Will fail when the EE=0 device joins the EE=1 gateway at which point will leave and retry join and hopefully hit the EE=0 gateway. When comissioned and confirmed join to the EE=1 gateway force JV=0 so you don't have awkward field behavior.

Answer 2

If Coordinator is with encryption enabled, then no module can join it without knowledge of Encryption Key.

You can also take a look at Node Join Time "NJ" parameter on Coordinator. This will limit modules to join Coordinator only for certain time after powering up.

Comments

Not entirely correct. The initial MAC association phase does not require encryption. With a configured KY and EE=1 an XBee will expect to receive a Transport Key encrypted with its unique KY value in order to stay on the network. But with EE=0 the initial association is enough to have them stay on the network but unable to communicate.