我想做什么
我试图将我的应用程序连接到需要配对的蓝牙LE设备.
当前行为
没有配对设备和我的iPhone应用程序没有问题.我能够连接,重新连接和读/写特性没有任何问题.
但是,如果设备需要配对,我只能在配对弹出确认之后首次读/写特性.下一次,我发现并将应用程序连接到我的设备,但是我没有权限读/写特征数据,因为(我猜)我没有使用配对信息.
最后…
花了几个小时搜索网路,没有运气这里是我的问题:
>如何使用我手机中存储的配对数据将iPhone应用程序从我的iPhone应用程序连接到蓝牙LE设备?我错过了什么吗?
>这可能不是IOS的问题,因为如果配对数据存在于连接设备的手机中,会自动使用?
有没有经验的蓝牙LE和IOS帮助我?
更新2013-10-27
我已经发现,如果配对存在(没有确认弹出),那么在发现特性之后,您无法通过配对认证来读取受保护的特性.没有保护特性的问题!我不知道为什么会发生,但是行为是IOS应用程序从来没有收到设备的答案.
所以如果一读完毕,就不会造成问题.这里是我用来发现在注释中的数据读取的特征的代码.
- (void) peripheral:(CBPeripheral *)peripheral didDiscoverCharacteristicsForService:(CBService *)service error:(NSError *)error; { NSArray *characteristics = [service characteristics]; CBCharacteristic *characteristic; if (peripheral != servicePeripheral) { NSLog(@"Wrong Peripheral.\n"); return ; } if (service != batteryService) { NSLog(@"Wrong Service.\n"); return ; } if (error != nil) { NSLog(@"Error %@\n",error); return ; } for (characteristic in characteristics) { NSLog(@"discovered characteristic %@",[characteristic UUID]); if ([[characteristic UUID] isEqual:[CBUUID UUIDWithString:kBatteryCharacteristicUUIDString]]) { // Bat NSLog(@"Discovered Bat Characteristic"); batteryCharacteristic = [characteristic retain]; //--> generate problem when pairing exists between IOS app and device //[peripheral readValueForCharacteristic:batteryCharacteristic]; } } }
解决方法
如果您的应用程序在LE Central模式下运行,并且外设响应于读/写请求发送不正确的身份验证错误代码,则iOS将自动与您的设备配对并重试该请求.
如果断开与设备的连接,然后再次重新连接,则外设需要再次发送不正确的验证错误代码以使iPhone重新启动加密.再次,你不必在你的应用程序中做任何特别的事情.
如果您的应用程序以LE Peripheral模式运行,则有所不同.设置GATT数据库时,请确保为CBAttributePermissions和CBCharacteristicProperties设置正确的标志.这将告诉iOS,如果没有配对,它应该发送不正确的身份验证错误代码本身.中央设备的责任就是开始加密过程.
在Bluetooth Accessory Design Guidelines for Apple Products年,进一步的限制被描述.
>您的配件需要解决专有蓝牙地址的功能. iPhone会随时更改其公共蓝牙地址,只有配对的设备才能正确的键解决公网地址并识别iPhone.
>“3.9节配对”也很有趣.
>请注意,如果您没有中间人(MITM)保护,您的外设可以使用结果键来解决iPhone的专用蓝牙地址.但是,您将无法加密频道.
与iOS上的MITM保护配对需要输入远程设备显示的PIN码.据我所知,iOS不支持通过外部通道发送配对数据的带外(OOB)配对(至少没有公开的API设置OOB数据).
长篇小说:如果您只有“对”/“取消”配对,则无法加密LE频道,但只能在将来的连接中识别iPhone.好的是,即使您在iPhone侧解除了iPhone,甚至还原iPhone固件,您仍然可以识别iPhone .-).
关于一般的LE加密:这是不安全的(见http://eprint.iacr.org/2013/309).