Hi,
I realise that SimpliciTI is probably not the best stack to use when constructing a fully secure RF network. That being said, I wanted to better understand the security benefits of using peer-to-peer links (using a link token) vs simply broadcasting messages using the UUD token.
It seems reasonable that P2P linking should provide some degree of extra security, but after looking at the SimpliciTI source code, I'm not sure what it might be. For instance, it seems to me that both a broadcast message and a unicast packet can be picked up just as easily by a rogue device. But presumably the unicast packet must be blocked at some point (in the NWK layer?) since the rogue device would not possess the correct link token.
I suppose if I could understand where the packet is being blocked, that would give me a better idea of whether link token unicasting is more secure.
Thanks,
Jimbo
Hello.
A complete response to your concerns would be quite lengthy but here are some quick thoughts.
Take a look at Section 8 in the Developer's Notes which deals with network access control. Linking and the Link Token have nothing to do with blocking packets. They address setting up a connection initially. The design idea behind the Link Token was to provide a means to reduce the likelihood of a device participating in establishing a P2P connection if it is the "wrong" device. You don't want your garage door opener to open your neighbor's garage door so you don't want your transmitting device to talk to the wrong receiver. If there is no connection to the "wrong" receiver this can't happen. If Link tokens don't match during the linking phase the connection won't be established.
Having an Access Point adds an additional means of access control (and therefore connection capability) by requiring the correct Join Token at which time the AP distributes the Link Token for that network. Only devices that have successfully joined (i.e., have the right Join Token) will get the correct Link Token for that network. If you have only 2 devices you can make one of them an AP and you will have two layers of access control using both tokens. It is a star configuration with a hub and only 1 spoke. If you have more than 2 devices and want the End Devices to connect P2P using an Access point is still better because again the correct Link token must be received from the AP. The AP can of course be one of the peers.
In these two cases packets are "blocked" at the NWK layer if a received packet does not come from a device that has previously established a connection. Information for each connection is kept in the connection table and is validated at the NWK level. Broadcast packets, represented in SimpliciTI by using the Unconnected User Datagram (UUD) Link ID at the application layer for both sending and receiving, are not connection based so there is no way to block them at the NWK layer. It is up to the application to validate them based on some kind of token in the application message.
Neither of these access control mechanisms will defend against a rogue device purposely listening and trying to disrupt communication, especially in the UUD case. A listening device could figure out both the Join and Link Tokens and under the right conditions could masquerade as a valid device because everything is sent in clear text. This leads to a third mechanism called out in the Developer's Notes: encryption. The encryption capability in SimpliciTI is pretty basic but it does work and will give a rogue device a hard(er) time. But there is no protocol for key distribution or any other more sophisticated schemes for controlling the encyption environment. It was just to give an idea how things might work.
In summary, the Link and Join Tokens were not meant to discourage purposely rogue devices and they are not very strong deterrents. Add encryption, and you'd have a better shot. You could use the native capability in SimpliciTI or if you want you could just encrypt the application message yourself and do things that way. YMMV.
Hope this helps.
lfriedman
Thank you for such a comprehensive answer. That certainly clarifies things for me.
On a related note, I notice that when a packet is sent, the link ID is not included as part of the MRFI frame. However, the source address is. So I assume that the destination NWK layer takes the source address, and tries to match it to an address which has a valid link ID associated with it. Is this correct?
Yes.
So if you want to produce 100 garage openers and receivers, you'd have to compile 100 times each with a different join and link tokens?
Is there a more practical way of generating these tokens?
Thank you
Amer
both join and link token can be modified during run-time by using SMPL_Ioctl() function with IOCTL_OBJ_TOKEN object.
Regards,
Leo Hendrawan
- Now that my signature has caught your attention, please click the "Verify Answer" button if this post answers your question. Thanks! -