Having Problem with encryption on iOS nRF51822

[Soan]

I am creating an iOS which needs to talk with nRF51822 Soft devices 100.

Problem i am facing is, I am not able to Encrypt the connection properly.

I am using

- security mode = 1 and level = 1 (open) for all custom characteristics, except level = 2 (encryption with no MITM protection) for notifications.

My iOS app can Discover the services/Characteristics.

When i try to Read/Write the data on Characteristics. i am able to do so without any kind of encryption.

When i try to Subscribe to Notifications iOS raises an alert if user wants to pair to Device. And everything works fine if user accepts Pairing.

But once I kill iOS App. i can see inside iOS logs that device adds the Device to RemoveFromWhiteList list. Which from sound of it looks like iOS is throwing away the keys.

And eventually if i try to reOpen the App. App is never able to connect to the BLE device.

iOS App acts like a Central.

BLE Device is Peripheral.

When looking at Wireshark Packets the logs which i can see are

Encrypted packet decrypted incorrectly (bad MIC)

Which is expected as iOS has thrown away the Keys and BLE Peripheral is still using the same keys.

Will appreciate any help regarding to this. It feels to me that some kind of encryption i am doing wrong.

Can i add encryption on connection level so that Pairing alert is raised during connection time.

Or Encryption is only defined on each characteristic.

I am facing this issue on iOS 10.3.3, iPhone 5.

[Vidar Berg]

Hi,

Will this code run on the nRF51 DK? In that case, can you upload the application FW along with the softdevice so I  can test it here? I'm pretty sure that the "RemoveFromWhiteList" line isn't related to pairing. You can check if the peripheral is bonded with the phone by looking at the "My device" list in Settings->Bluetooth. All bonded devices will be listed there.

Encrypted packet decrypted incorrectly (bad MIC)

Note that you will get the same error if the sniffer has not captured the long term key during the initial key exchange.

[Soan]

FacettWireSharkLogs.pcapng

Yes the above BAD MIC was because sniffer could not capture the long term key, My bad starting the Sniffer at the end of process.

The Logs i attached currently shows most of the interaction happening between iOS and BLE Device.

App Finds the Device.

Connects to it

Try to Retreive the Services and Characteristics

Tries to subscribe to notifications.(After which Pairing Alert is visible to user on UI)

Then you can see in Logs It proceeds with encryption.

Then on packet number 153. I terminate the App, which kills the connection between the device and iOS.

Then at around packet number 359, i again start the mobile app to connect to the BLE Device. but it never gets connected. It keeps on transferring data.

And yes i can see the Paired/Bonded device in iOS settings even after disconnection from App, So looks like Mobile is not throwing any kind of information. but BLE device is not responding to Mobiles encryption request.

[Vidar Berg]

Thanks for providing the sniffer trace. Have you tried to debug the code to see if the program gets stuck or reset once you re-connect after the bond is established? I see that there are lot of re-transmits after the slave sends the encryption request which indicate that the link becomes lost as soon as the request is sent.  

Edit. not related to the issue here, but wanted to add that you may impacted by this if you use s110: https://devzone.nordicsemi.com/b/blog/posts/what-impact-does-the-deprecation-and-withdrawal-of-bluetooth-core-specification-v4-0-and-v4-1-have-on-your-current-and-future-products?CommentId=84db79f6-ea63-4381-81f5-ca0520ab0cf4  

[Soan]

Thanks Vidar, For your response and Letting us know about the impact on s110 because of Deprecation.

I am sorry we dont have the Complete code, its the compiled system that has been passed on to me.

But if you can point me to some place which can detail out how should the encryption proceed if everything is right. And how to understand Packets being transmitted, while looking at sniffer logs.

And i am curious after analysing Sniffer Logs, i can see More Data bit is set to 1 in frame 371(Which is start Encryption request), But its 0 in frame 66, During first time Connection.

Much appreciate your help.

[Vidar Berg]

Have you tested this with other phones, an Android phone for instance? If it works with other phones you could use the sniffer trace from those connections to compare against. To me it looks more like an issue with the 51 FW. I couldn't spot any errors in the pairing procedure at least. 

Soan said:

And i am curious after analysing Sniffer Logs, i can see More Data bit is set to 1 in frame 371(Which is start Encryption request), But its 0 in frame 66, During first time Connection.

I'm afraid I don't have a good explanation for this. I don't think it's a spec. violation, but seems strange that the MD bit is always set on this control packet. 

[Soan]

We see the issue across all 3 iOS devices we have used in our testing, but the behaviour is slightly different across devices - they fail at different points. The WireShark logs show the following failure points when our custom app tries to reconnect with the aid:

- iPhone 7 (iOS 12.1.2) fails on CONNECT_REQ (frame 302)

- iPad 4 (iOS 10.3.3) fails on LL_VERSION_IND (frame 524)

- iPhone 5 (iOS 10.3.3) fails on LL_START_ENC_RSP (frame 559)

The test procedure that was followed to produce these logs was as follows:

a. Clear Devices from iOS Bluetooth Settings
b. Run the App
c. Search for Devices
d. Connect to Device
e. Subscribe to Notifications
f. Accept Pairing Alert Raised by iOS Platformg

g. Everything works fine(Read/Write Data)
h. Kill iOS Mobile APP
i. Disconnections Happens
j. Restart App
k. App Tries to Connect again to old Remembered Device.
l. App Never gets Connected

Today we noticed that the issue does not occur most of the time (but not all of the time) if we clear the bond table in the nRF51822 - can you confirm whether an overflowing bond table could be the cause of such re-connection issues?

[Vidar Berg]

Soan said:

Today we noticed that the issue does not occur most of the time (but not all of the time) if we clear the bond table in the nRF51822 - can you confirm whether an overflowing bond table could be the cause of such re-connection issues?

It depends on how it is implemented. Bonds are managed by the application code, not by the bluetooth stack. I think you need to debug the application FW to figure out why the disconnects occur.