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.
On Tue, Nov 19, 2013 at 7:01 AM, Etan Kissling
<email@hidden> wrote:
Darrin,
You won’t need to do a full pairing with PIN entry if it is only for private address resolving.
YesNo pairing can be initiated by registering as a device without display / button and works with the iPhone.
You will not be able to encrypt the channel, but can store the pairing information on the accessory for
associating a new address with the old identity.
This key still works for address resolving after BT off / on, unpair from the phone, phone reboot and even secure erase.
This means that you should not link the BT info to a specific identity - as it won’t change when the phone changes its owner.
If you still are not able to perform this initial Yes/No pairing, you could either connect to the phone and implement
a custom identity variable that contains the app-manufacturer-specific device UUID.
Or use Davids approach.
Note however, that using custom advertisement data works only properly in foreground mode, though.
When your app is in background, the local name may change, and the serviceUUIDs may be moved to an invisible area.
Also, I’m not sure if apple likes when you abuse the serviceUUIDs key for unintended purposes.
BTW:
I have never seen the iPhone change already after 15 mins - it often requires a reboot to happen,
or a significantly longer time to change addresses.
Maybe there are other workarounds like tracking of the RSSI and then mapping it to the new BD_ADDR (with a similar RSSI) when the address changes.
Or abusing the ANCS by injecting a custom hidden message in it that’s unique to a single device.
Have not experimented yet with the ANCS so not sure what’s possible with it :)
I would suggest that you provide us with the concrete use case, so we can discuss a solution that’s more tailored to your needs.
The only way I can think of is if the iOS Device advertised a serviceUUID or Local Name that was unique to only itself.
In CBPeripheralManager, the only advertising data that you are allowed to set are.
1. CBAvertisementDataLocalNameKey
2. CBAdvertisementDataServiceUUIDsKey
You could discovery the device and read the advertisingData dictionary without connecting to the device.
Dave
On Nov 19, 2013, at 1:24 PM, William Henderson <
email@hidden> wrote:
You can’t. You’ll need to connect and implement your own identification scheme.
--
William
Sent from my iPhone
On Monday, November 18, 2013 at 9:22 PM, Darrin Massena wrote:
An iOS device used as a Bluetooth LE peripheral changes its identifier every 15 mins or so. Scanning Centrals rediscover it and think it is a new peripheral. Without pairing with the peripheral, how can a Central recognize that this is the same peripheral
it has previously connected to?
Thanks,
Darrin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (
email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (
email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to
email@hidden