Create white list during production process

[Jos Bijma]

Hi,

I need to make it possible to allow connection to one specific central device. This with the thought that the user doesn't want to be bothered with bonding the device in our use case. So the device should be pre-paired during the production process.

I would like fill the white list of a nrf51822 peripheral in the production process without making use of the radio. The examples that I have seen from Nordic will fill the white list after having a connection with the central device. Is it possible to fill the white list using only the Device Address of the central without having the need of a connection?

[Ole Morten]

The definitely easiest way to do this would be to actually do the bonding as part of the production process. This would allow both the devices to store the proper encryption keys and system attributes as needed, and the devices will just work when they arrive in customer hands.

If this is absolutely not an option, you will have to come up with some other scheme, but this may be a tricky. One possibility, if you use static addresses, could perhaps be to write the address of the Central somewhere in the Peripherals flash, and then hard-code this address to be used as a manual whitelist, all until a proper bond have been established. Anything involving sharing the actual keys may be tricky, since there is a relation between the root keys stored in the chip and the key generation. Just sharing the address should however be sufficient, if you can't do the bond in the production line.

[Jos Bijma]

Hi Ole,

I did a test with storing the Device Address of the Central in the whitelist, the solution you mentioned. This seems to work properly. I think this solution will be acceptable for our use case! Thanks for your help!

[davman]

Hi Ole,

I have a somewhat related question. I'm looking for a smart way to "hand over" a pairing already done between a peripheral and a central to another central.

Let's say I have a nrf51822 based sensor-device, but on a bigger room/installation I want it to be able to talk to the nearest by (or rather first best central) it can connect to. So if loosing the connection to one central, the peripheral should be able to resume the connection with another one.

The central where the pairing was done is on a network so it could immediately distribute the pairing-info done with the peripheral to the other computers over tcp/ip.

Basically I want to achieve pair once, but then use anywhere in a big room regardless of central (without having to manually pair with each and every one).

/d

[Ole Morten]

This is really a very different question, and would have been better off separately.

However, what you want would be doable using the BLE standard mechanisms, but it wouldn't be very easy and it will probably require you to get a thorough understanding of the security specification in BLE to implement in a reasonable way.

The basic point is that on both the Central and the Peripheral, it is the application's responsibility to provide the softdevice with an LTK, the encryption key that is used for all data encryption. Hence, if you can pre-program this LTK in production, and just always supply this when you get an event asking for it, encryption will work fine.

However there are a couple of subtleties here. For instance, is it ok to share one LTK between all your devices? If not, you may have to come up with some scheme to generate an LTK for a certain device, based on something that's known about this device, for example it's Bluetooth address.

Secondly, does your sensors need to be connectable and bondable to other Central devices, for instance smart phones? If so, additional constraints may be put on how this LTK needs to be treated, and how to identify which LTK to use for the currently connected device.

If you want to go down this route, I'd recommend you to read the Core Specification, Volume 3, Part H very throughly, and look at the MSCs for Bonding in detail, to make sure you understand it all. If you have any specific questions, please post them separately.

A final, completely other option would be to do all the authentication on the application level. This would provide you with full freedom to design it the way you want. Depending on your security requirements, this may also be complicated, so which method to go for is basically up to you.