| I don’t think I can specify the key…I think it may come from iOS, the bluetooth stack on the central gives me the key anyway, and I don’t think there is a method to specify your own.
I may be able to specify OOB data, I might look at that, but in this case it’s not such a big deal if pairing doesn’t work fortunately.
That’s frustrating. I’ve been hoping that as bluetooth develops, CoreBluetooth would start adding that kind of depth, but I didn’t see much new recently.
Can you store a fixed PIN on a per-device basis on the headless central and force that to be used? I do that on my Nordic peripheral code, you return display only for the io properties, iOS has keyboard + display so your central gets to pick the key and ‘display’ it and you type it in on the iOS side. Nordic has a property you can set which forces the key in that case so it’s not actually displayed, because there’s nothing to actually display it on, apart from the piece of paper you stuck on the box.
Another option is to look into LE secure pairing, which I haven’t messed with and have no idea how it works and how you fulfil the out of bounds pairing information.
It appears your theory is correct. Enabling MITM on the central and setting the IO capabilities to ‘display only’, and logging the received code to my debug output, I was able to enter the code into iOS. This allowed the characteristics to be accessed.
Very disappointing that this is not included in the documentation Apple, and also disappointing that ‘just works’ cannot be used. As this is a headless central I will have to remove encryption.
I will create bug/feature reports for these two issues.
Thanks Roland.
I am using just works, I haven’t specified MITM on iOS or the central, is that implicit when EncryptionRequired?
I don’t know because the documentation glosses over all the complicated bits of bluetooth and doesn’t say. However, empirical evidence from your test says that it does require MITM, because that’s the only sequence I can come up with which gives you the Insufficient Authentication twice and, since the documentation for Core Bluetooth doesn’t even mention MITM my handwaving guess would be that encryption sets that requirement because that’s the more secure version (although that begs the question, what does just works pairing do apart from identify the device for the future and allow the link to be encrypted).
Can you get your central to use MITM, even with a fixed key or something dumb, see if it changes things? What’s the central implementation?
|