Secure bonding on iOS requires encrypted characteristic

Verification

• I searched for similar bug reports and found none was relevant.

What happened?

Secure bonding on iOS can't be manually initiated, and requires and encrypted characteristic to initiate

What should happen instead?

iOS tries to read encrypted characteristic, and then initiates pairing

Reproduction steps

I'm the InfiniLink dev, and in light of the 1.8.0 update I'm trying to set up secure bonding in iOS. Unfortunately iOS bonding is only triggered when the iOS Bluetooth central tries to read, write, or subscribe to a characteristic that utilizes encryption. I can't force the bonding process to occur programmatically, it can only be the result of accessing a characteristic that's encrypted.

Just to be sure, I added some code to print any of the indicators for encryption on every BLE characteristic that's discovered on connecting. None of them indicate encryption, so iOS cannot make an encrypted connection to InfiniTime

A while ago, I installed an early build of the bonding PR where the battery characteristic was encrypted, and the bonding process was smooth, and in fact worked appropriately with no modifications to InfiniLink. The instant I connected, the PIN prompt happened and a secure connection was established.

I'm sorry I didn't notice this sooner! I've been very busy IRL wasn't aware of the discussions happening in #796 and #880 until the update came out today. I know that the consensus in those threads was against leaving an encrypted characteristic to prompt bonding, but that means that iOS users will not be able to utilize encryption.

More details?

No response

Version

1.8.0

Companion app

InfiniLink

Start by reviewing the bonding discussions in issues #796 and #880, then inspect the BLE characteristics exposed by InfiniTime and how InfiniLink discovers their security properties. Done means iOS can trigger pairing by accessing an encrypted characteristic without regressing the agreed bonding behavior.