When do encryption keys exchange?

[MC]

I have a problem with bonding with a static passkey. I have some sensors, which have a static passkey hardcoded in them. If I want to bond with them, I have to provide this passkey from my custom central app, which uses s120 and SDK 8.1.0. For the past few days I wasn't able to make a successfull bond, because I keep getting BLE_GAP_SEC_STATUS_AUTH_REQ from the sensor. I can't find much information on what to do in this case. I can bond with MCP just fine.

I compared log file from MCP and sniffer trace from my central bonding attempt and they are different in one very impotant aspect. MCP exchanges keys and encrypts the connection before trying to authenticate the link. Default behavioral of the device manage in SDK 8.1.0 is not the same. If I call dm_security_setup_req it only forces authentication without previous key exchange. This is why authentication fails. If I go into debug mode, I can see that keys are always 0. Does anyone have any suggestions about this matter? Are there any examples that mimic MCP behavioral?

Edit: added trace logs for windows phone, s120 and MCP log file, all done with the same sensor (which uses TI stack).

Windows phone pairing attempt: windows_pairing_with_adv.pcapng

S120 pairing attempt: s120_central_pairing.pcapng

MCP log file: log.txt

Android bonding attempt: android_bonding.pcapng

[Petter Myhre]

I'm not familiar with that event. Could you provide some more information so I can try to reproduce it?

[MC]

First, you will need a peripheral, which has a static passkey hardcoded in the code. In my case, I have "000000". The sensors I have, require this passkey at bonding (pairing) procedure. Second, use some example code, lets say s120 multilink central example. Please use SDK 8.1.0. Then, connect to the peripheral and inside the client_handling_create function, call the function dm_security_setup_req.

After that, you should get an event from DM DM_EVT_SECURITY_SETUP_COMPLETE in main() with event_result 0x83. This comes from the fact, that dm_security_setup_req function forces authentication for unbonded devices by calling initiate_security_request. Because authentication function requires encryption keys to be available, it will always fail, given the fact that link hasn't been encrypted. Edit: added PNGs to my main question for clarification of the problem.

[Petter Myhre]

You could have mentioned that your peripheral was from TI :) Then it may be difficult for me to reproduce it. From your pictures I can't really see what the difference is, you haven't included the Pairing Request in both. Maybe you can just upload the files? Does it change anything if you set MITM? I suspect that the TI chip rejects the pairing request because the central says it doesn't support MITM.

[MC]

I thought that it doesn't matter if it is from TI, as BLE responses and protocols should be standardised :) As for the pairing request, this is the main difference I was talking about, device manager in SDK 8 doesn't include sending the pairing request prior to authentication, or I don't know how to do it.

Both files I included were done at roughly the same time, after connection was established. In my attemt, no pairing request is ever sent, even if I set MITM. I tried all the combinations with and without MITM/bonding, the response is the same. If you could tell me how to initiate pairing request from s120, I think, it will solve my problem.

[Petter Myhre]

I'm confused. I thought the lower picture was S120? The pairing request is sent in that picture. What do you mean by sending pairing request prior to authentication? The authentication is part of the pairing process, it is not done before the pairing request is sent. Please upload the sniffer files instead of pictures, and mark clearly what trace is from what device. You send a pairing request by calling sd_ble_gap_authenticate(). You can do this directly, or you can let device manager handle this for you, then you should call dm_security_setup_req(). If you call this, the central will request to pair/bond if the peer is not bonded, if it is bonded, the link will be re-encrypted using existing bond information.