|
Darrin,
yes, it is possible to spoof a YesNo pairing with a Man in the middle attack.
Only PIN-based methods (supported by iOS) or transmitting the keys OOB (not supported by iOS)
protects against this.
BLE security is pretty weak, though, so if someone really wants to hack it, you should build an own
Both devices can choose their capabilities in the pairing process. You cannot control what the iOS
device will send (it’s always Display + Full Keyboard), but your remote device can send restricted
capabilities that prevent the automatic choice of the PIN-based pairing.
Based on your last message, it seems that you also use iOS for the central device. In this case,
you won’t be able to accomplish a YesNo pairing.
However, there might be another glimmer of hope: While normally, a BLE 4.0 peripheral can only
be connected to one central at a time, iOS leverages this restriction and allows multiple parallel
connections (at least in theory). Therefore, you shouldn’t worry about connecting and reading out
a custom characteristic that contains a unique identifier for your application.
Reports claimed that after 7 parallel connections, BT becomes unstable, even though BLE should
support many more connections. If you are only connecting to read out a single value, this shouldn’t
be a problem though.
Another advantage of using iOS-to-iOS connection is that you may be able to make use of the
“overflow area” in the advertisement packets. They provide a best-effort (sometimes work, sometimes
it doesn’t) way of adding multiple service UUIDs in a single advertisement packet. So you may try
approach were you inject the app identifier into one of those service UUIDs. It’s not a clean approach
though, and you may run into App store issues, as the service UUIDs are not intended for this use case.
Etan
On 20.11.2013, at 06:59, Darrin Massena < email@hidden> wrote:
Thanks Etan, David, William. Your responses are very helpful.
Etan, I'm trying to learn more about UI-less YesNo pairing but can't find discussion of it in the Core Bluetooth documentation. Can you provide a pointer? In my case, the peripheral is an iOS device so how would it indicate itself as a display/button-less
device?
If this can be made to work, would I be right to assume that such a peripheral would be spoofable? I.e. without encryption one can see how the pairing works and mimic it with a different device.
Regarding the identifier changing every 15 minutes, from my logs:
2013-11-19 21:24:55.005 CardsMac[40233:303] Discovered peripheral NameTag (<CBPeripheral: 0x6080000ad800 identifier = F3C38468-F250-4067-BACB-37A7D8DEF71A, Name = "NameTag", state = disconnected>) with RSSI -44 and advertisementData {
kCBAdvDataLocalName = NameTag;
kCBAdvDataServiceUUIDs = (
"Unknown (<0f4266cc 6ec44798 9fe087b3 5b7e8d1c>)"
);
}
<... intervening connect/cancelPeripheralConnection and stop/startScans removed ...>
2013-11-19 21:39:34.617 CardsMac[40233:303] Discovered peripheral NameTag (<CBPeripheral: 0x6180000aed00 identifier = B2E8A6AB-C9AC-4FA3-A35E-63FC92B3189B, Name = "NameTag", state = disconnected>) with RSSI -50 and advertisementData {
kCBAdvDataLocalName = NameTag;
kCBAdvDataServiceUUIDs = (
"Unknown (<0f4266cc 6ec44798 9fe087b3 5b7e8d1c>)"
);
}
Another thing I'm looking into is that when this rediscovery happens and I attempt to connect to the 'new' peripheral (note that I am not maintaining a connection to the original CBPeripheral), my connection attempt hangs, i.e. no did*Connect callbacks
are received. I'll have to figure that out for any of the connection-dependent solutions to this problem to be viable.
|