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.