App is connecting to random nrf52 devices

[levshkatov]

How to solve problem with two (or more) simultaneously working devices with nrf52. I mean I have android app to connect to device. App is connecting to random device. I use simply the name of a device as id to connect to it. I know it's pretty dumb. I should use address instead, but how to do it if I have e.g. 1 million devices. Should I put all of 1 million addresses into app?

[endnode]

No, matching by MAC address works only if you have them static and you work in "few to few" scenario (few being <100 or rather <10). If you dream about large scale deployment (1,000 devices and more) where your devices should communicate over BLE GATT just between each other then you need to solve it on APP layer (on top of GATT):

• Define your own Service UUID which will be broadcasted.
• Even devices which don't fit (or don't allow you to put) custom 16-byte UUID into advertising data will work because any GAP Central/GATT Client device can discover it on the Server once connected.
• In "many to many" scenario BLE security doesn't work (because it doesn't scale) so you will need to add some security layer into your AP protocols on top of GATT (if you care about security). That will also be moment when your Server should kick-out the device which has connected, tries to use your Service but isn't authorized.
• Alternatively if you want to prevent people of mocking your UUID (which is easy attack) you could use Manufacturer Specific AD object in Advertising or Scan Response data (again only where you are allowed to access these and where you fit into) and design some authentication tokens which would already signal which devices are genuine. But as every such "DRM" scheme it's very hard to really implement it without security holes (it would probably be possible with on-line solution, very hard with complete off-line base).

Good luck!

[endnode]

The example you mention isn't really applicable because phone is paired with the headphones. They know each other by MAC (it can even be pseudo-random aka anonymous but as they exchanged the keys before they will deanonymize them internally) and they have long term keys to protect the link once they reconnect. But this again fails in any solution which has "many" in the topology ("one to many" or "many to many") because Bluetooth links (not speaking about some "over the top" solutions such as mash networking) are always peer to peer which means that you would need to store and search in as many records as you have met "peers". Typical max of devices today are 8/16/32 peers, many "embedded" devices (such as car handsfree or BT headsets) are not ashamed to limit maximum number to 3 (and if you want to provision more then you need to delete one).