BLE Pairing w/ Display only?

[SWenn.1]

Can someone explain to me how the client would know what the server pairing number was if the user used a RNG in the server to create the pairing number?  I certainly see how a fixed number would work as a developer.  But when I try and connect using this method with ST BLE Toolbox it wants me to enter a number and if the server randomly generates this, well......????

Thanks

Steve

[STM_Thirty2]

If your server's IO capabilities are "Display Only" then it would use the Display to display the pin to the user. The user would enter the pin in their client device. So its up to the developer to display the pin using their display capabilities.

 
Should the server have IO capabilities set to "Keyboard Only" and the Client has Keyboard then in this case both devices would have to enter a matching pin, it can be any pin as long as they both match.

[SWenn.1]

Hello Eddie....

Pls bear with me as I still have a little confusion....

I am set to Display only and it is on a server.  I have a hard coded number in the firmware with the setting "Do not use a fixed pin (0x01)"

The client is nothing more than nRF Connect or ST BLE Toolbox (so no way to set Display Only or Keyboard Only here as it is what it is and I haven't developed an app)

My phone gets the following message to which I respond with the correct number.  What you seem to suggest is that I have a display on my server as well and then when the number pops up on the server display I am to use that on the phone end.  Does this sound correct??

What I am trying to imagine is after building say an IoT sensor when has one ever seen a keyboard or display connected to these rather small sensing devices.  In essence if a product like this was shipped out the customer would have to connect a display to the sensor just to pair or pair/bond??

Thanks

Steve

[STM_Thirty2]

---

  What you seem to suggest is that I have a display on my server as well and then when the number pops up on the server display I am to use that on the phone end.  Does this sound correct??

---

Yes that is correct. This is because you have the server IO capabilities set to Display only. Since the client is on the phone , the app developers obviously set the IO capabilities to "Keyboard and Display"  so you do not have to worry about that. 

In the scenario where either of the device has NO Keyboard and NO Display, per the diagram above, the BLE connection will be established with the "just works" mechanism. 

In applications like you suggest, typically the sensor/IoT device will advertise with a specific name that the client will recognize and they will connect without the need for a pin/passcode. For more security there is Out of Band Pairing, where the two devices briefly switch to something like NFC and get close enough to each other to share secret keys and pair and once the bonding is done they go back to BLE mode.

You can also implement your own out of band pairing and perhaps make the devices have to physically connect with a cable and share keys via UART, or any other mechanism.

[SWenn.1]

Thank you for the response Eddie.

With respect to Display Only....Can you tell me then why in the Display Only ST Video (starting at the 3 minute mark) why the console never shows the value to the user?

https://www.youtube.com/watch?v=VURSdbLbgnI&list=PLnMKNibPkDnGbiUxaLBqTdM2nNIVAk_MO&index=6 

Could you also do whitelisting as a security measure?

Power sensor up, pair then bond then whitelist....Would this keep anyone else from them accessing?

Once the sensor whitelisted I am guessing it could then authorize that client and only that client to have access to the characteristic values?

Thanks

Steve

[STM_Thirty2]

Thats a fair question, I do not think the application by default will display the pin since this is a user generated random pin, and thus should be logged to the console by the developer once you have established the pin through whatever RNG method you chose. 

As far as whitelisting, your solution seems feasible as long as you know the device you are about to whitelist was a genuine client. Which is why OOB pairing is the safest solution along with setting the MITM flag.