Secure bonding on iOS requires encrypted characteristic

[xan-m]

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

[JF002]

I am the one who insisted to keep secure pairing optional (the companion app decides to enable it or not).

I thought it was a good idea to keep secure pairing optional so we can make the move to secure mode a bit smoother : apps that support it use it and eventually enable it by default, and we don't break companion apps that do not support it. The goal was to create a transition period were both connection modes are available. For example, it worked out of the box with Gadgetbridge and ITD, but not with Amazfish on KDE plasma (the Bluetooth widget does not request the PIN code so it cannot connect using the secure mode).

According to Gadgetbridge, ITD and bluetoothctl, the companion app has the opportunity to activate or not the secure pairing mode even if no characteristic is encrypted in InfiniTime.

But, according to what you said, it looks like iOS does not want to do things like everyone else... again :-D

Could you please check that there's no way to force the secure mode without encrypted characteristics?

Also, what's your suggestion regarding encrypted characteristics? Should we crypt all characteristics from all services, or are there some characteristics we cannot encrypt because we won't be BLE compliant anymore?

[xan-m]

I totally agree with you, I think a slow rollout of a big change like this is always the prudent move! It just so happens to be out of sync with Apple's impossible standards :)

But, according to what you said, it looks like iOS does not want to do things like everyone else... again :-D

🤦 yep, yet again Apple's implementation has to be special! Per Apple's Accessory Design Guidelines (section 40.10):

If, for security reasons, the accessory requires a bonded relationship with the Central, the Peripheral
should reject the ATT request using the Insufficient Authentication error code, as appropriate. As a
result, the device may proceed with the necessary security procedures.

It's confirmed in a number of non-Apple articles about BLE implementation in apps as well, for example:

Much to the chagrin of many iOS developers, Core Bluetooth provides no insight into the pairing and bonding process, nor the peripheral’s paired/bonded state. The API only informs the developer whether the device is connected.

Core Bluetooth gives no real public API-level insight or control over the bonding process of the peripheral, other than what you can infer and trigger through encrypted services and characteristics

I can't even query whether or not the device is bonded through the API!

Also, what's your suggestion regarding encrypted characteristics? Should we crypt all characteristics from all services, or are there some characteristics we cannot encrypt because we won't be BLE compliant anymore?

These are great questions, but honestly they are a little out of my league. I'm not sure what the BLE compliance guidelines are regarding encryption. It doesn't say anything in the document I linked above about which characteristics can or can't be encrypted, for what it's worth.

Once the bonding occurs, aren't all other transmissions afterwards encrypted, even if they're not explicitly flagged as encrypted characteristics? In that case, I would only need one characteristic to demand authentication to trigger the pairing process in iOS. It could even be a dummy characteristic that doesn't actually hold valuable (or any) data as a kludge, and I could have the app side try to read that characteristic on connect, triggering the bonding process.

Just to reiterate: when testing a build from early in the bonding PR process (when the battery level characteristic was used to trigger bonding), the instant I connected the PineTime the bonding prompt with the PIN showed up on my phone and the watch. I don't have a sniffer so I'm not 100% sure to what degree my communications were encrypted after that bonding, but if my understanding of the process is right, it should only have to be one characteristic that requires authentication.

[evergreen22]

First, @xan-m, thanks so much for your report.

Just to reiterate: when testing a build from early in the bonding PR process (when the battery level characteristic was used to trigger bonding), the instant I connected the PineTime the bonding prompt with the PIN showed up on my phone and the watch.

As @JF002 detailed above, we are aware that the BLE spec strongly recommends that developers use an encrypted characteristic to trigger secure pairing (that's why I did it that way in the original PR and why it initially worked for you). It isn't necessary, or recommended, to require encryption or authentication on all characteristics. Just a key one is all that is needed to kick off secure pairing.

Secure pairing is the process of generating and exchanging security keys for encryption and identification. Bonding is the process of storing this cryptographic material for subsequent automatic reconnects. You cannot bond unless you are securely paired.

However, as @JF002 also stated above, requiring encryption and authentication on the battery characteristic today creates problems for several of our testers (and users) who are using companion apps that do not yet properly support secure pairing. I agree that this needs to be done in order for the secure pairing and bonding to compliant with the BLE specs. We are hopeful that the companion apps will hear our pleas and update soon. During my testing, Gadgetbridge worked beautifully with the encryption requirement. C'est la vie.

[xan-m]

requiring encryption and authentication on the battery characteristic today creates problems for several of our testers (and users) who are using companion apps that do not yet properly support secure pairing

Totally understand this! I just wanted to flag that having an encrypted characteristic is a requirement for iOS for future reference.

Honestly, knowing that it has worked (based on the earlier build successfully bonding) is kind of good enough for now, I think. Until ANCS is implemented, the data being transferred to iOS devices is largely trivial and doesn't contain much, if any, sensitive data/PII. I'm sure some people with a tighter threat model than me will disagree, but for now I don't think this is an urgent issue. Come to think of it, if ANCS was implemented in the meantime that would probably be enough to trigger the secure pairing on iOS devices.

Also thank you for all of your hard work on this feature!

[JF002]

@xan-m Thank you for your researches! In my opinion, enabling secure pairing/bonding as a by-product of a failed read operation (because the security was not enabled from the beginning) does not seem right but... my opinion is not the Apple people's opinion sooo... :-D

So, yes, we can enable security on the battery level as @evergreen22 suggested, or create a dummy characteristic with security enable so companion app can read it to force secure pairing. Or even enable security on all services and characteristics (if the standard allows that). It just feels strange to activate a feature by triggering an error on another feature...

I think we can see how secure pairing works for our users as it's implemented right now, and see how fast we can enable security on some or all characteristics.

[xan-m]

In my opinion, enabling secure pairing/bonding as a by-product of a failed read operation (because the security was not enabled from the beginning) does not seem right

Absolutely, it’s completely backwards to me too!

I think we can see how secure pairing works for our users as it's implemented right now, and see how fast we can enable security on some or all characteristics.

Yup this seems like a good plan. Also as I mentioned above, if someone smarter than me can get ANCS or AMS enabled in the meantime, requiring authentication on those could be an Apple-specific bonding trigger and would obviate the need for encrypting a universal characteristic that would cause problems for other users.

[arjanvlek]

However, as @JF002 also stated above, requiring encryption and authentication on the battery characteristic today creates problems for several of our testers (and users) who are using companion apps that do not yet properly support secure pairing. I agree that this needs to be done in order for the secure pairing and bonding to compliant with the BLE specs. We are hopeful that the companion apps will hear our pleas and update soon. During my testing, Gadgetbridge worked beautifully with the encryption requirement. C'est la vie.

In the meantime, wouldn’t it be possible to offer a checkbox labeled “enable encryption” in the settings of the watch that toggles encryption on one of the characteristics, so iOS can trigger the secure pairing already?

[kieranc]

or create a dummy characteristic with security enable so companion app can read it to force secure pairing.

Is there a downside to this approach? It seems like it could work to me, and should leave all the legacy setup functional unless the companion app touches the encrypted endpoint, in which case it switches to secure connection.

[wandering-hacker]

I'm glad to see that you're cracking at this! I was going to get started but at this point I'm in over my head... I've fallen down the rabbit hole of poking at my phone's GATT.
If I'm not mistaken, this is on the path to allowing Infinitime to talk ANCS, right?

[evergreen22]

I'm glad to see that you're cracking at this! I was going to get started but at this point I'm in over my head... I've fallen down the rabbit hole of poking at my phone's GATT.

I solved secure bonding in the initial PR. We chose to delay the full implementation until more companion apps comply.

If I'm not mistaken, this would allow Infinitime to talk ANCS, right?

My PR? No. See here what needs to be done: https://developer.apple.com/library/archive/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Introduction/Introduction.html

[wandering-hacker]

Yes, I have read the spec. I wasn't very clear in my earlier comment, but what I meant by 'this' is the secure bond with iOS (beyond the normal companion-app communication), and, by extension, the connection with a secure characteristic.
Please correct me if I am wrong, as it is, unfortunately, likely.