问题描述
我在我的IOS开发stucked，我需要帮助。我不是专家，这也许是一个愚蠢的问题。
我所试图做的
我想我的应用程序连接到需要被配对的蓝牙LE设备。
当前行为
有没有是配对的设备，我的iPhone应用程序没有问题。我能够连接，重新连接和读/写特性没有任何问题。
但是，如果该设备的进行配对，我只能读/写特性，首次配对弹出确认之后。接下来的时间，我发现和应用程序连接到我的设备，但我没有读的权利/我不使用配对信息，因为（我猜的）写的特性数据。
最后...
花几个小时在这里没有运气各地的网络搜索后是我的问题：
-
我如何我的应用程序连接到蓝牙LE设备从使用存储在我的手机配对数据我的iPhone应用程序？我缺少的东西吗？
-
是否有可能，这不是一个IOS问题，因为如果配对数据在手机present的连接装置，它会自动使用吗？
有没有人带蓝牙LE和IOS经验，帮助我吗？
更新2013年10月27日
我发现，你不能阅读保护特性按之后配对认证的特性已发现如果配对存在（没有确认弹出）。没有问题的非保护特性！我不知道为什么发生，但行为是IOS应用从未收到来自设备的答案。
因此，如果在第一读数后完成的，它不会引起问题。这里是code我使用发现，在注释中的数据读取性能。
- （无效）外围：（CBPeripheral *）周边didDiscoverCharacteristicsForService：（CBService *）服务错误：（NSError *）错误;
{
NSArray的*特征= [服务特色]
CBCharacteristic *特性; 如果（外设！= servicePeripheral）{
的NSLog（@错外设\\ n）;
返回;
} 如果（服务！= batteryService）{
的NSLog（@错服务\\ n）;
返回;
} 如果（错误！=无）{
的NSLog（@错误％@ \\ n，错误）;
返回;
} 对（在特征的特征）{
的NSLog（@发现特色％@，[特色UUID]）; 如果（[特点UUID]的isEqual：[CBUUID UUIDWithString：kBatteryCharacteristicUUIDString]]）{//蝙蝠
的NSLog（@发现蝙蝠特性）;
batteryCharacteristic = [特点保留]
// - ＆GT;当iOS应用和设备之间存在配对产生的问题
// [外设readValueForCharacteristic：batteryCharacteristic];
}
}
}
您不必配对管理做任何事情在你的应用程序。
如果您的应用LE环模式运行，并且外围发送一个不足认证错误code响应读/写请求，iOS设备会自动与您的设备配对，将重试请求。
如果您从设备断开连接，稍后再重新连接，外设需要发送不足认证错误code再次为iPhone重新启动加密。同样，你没有做什么特别在你的应用在这里。
如果您的应用LE外设模式运行，情况有点不同。当您设置关贸总协定的数据库，请务必设置正确的标志都在 CBAttributePermissions 和 CBCharacteristicProperties 。这将告诉它应该发送足够的验证错误code本身的iOS，如果不配对。它然后在中央装置的职责开始加密过程
在蓝牙附件设计指南，进一步限制了说明。
-
您需要的配件解决民营蓝牙地址的能力。而iPhone飘飞将改变其公共蓝牙地址，只有配对的设备将有正确的密钥，以解决公网地址，并承认了iPhone。
-
第3.9节配对也很有趣。
-
请注意，如果你没有配对人在这方面的中间人（MITM）的保护，你的周围可以使用生成的密钥，以解决iPhone的专用蓝牙地址。但是，您将无法通道进行加密。
配对与iOS上的MITM保护包括输入PIN码code由远程设备显示。出带外（OOB）配对，你通过外部渠道发送数据的配对iOS不，据我所知支持（至少没有公开的API来设置OOB数据）。
长话短说：如果你只有一个配对/取消配对，你不能加密LE通道，但只承认iPhone在未来的连接。这种做法的好处是，你仍然可以识别iPhone，即使你取消配对它在iPhone上侧，甚至恢复iPhone固件后， - 。）
对于一般LE加密：它不是反正安全（见 http://eprint.iacr.org/2013/309）。
I am stucked in my IOS dev and I need help. I am not an expert and it is perhaps a silly question.
What I am trying to do
I am trying to connect my app to a Bluetooth LE device which needs to be paired.
Current behaviour
There is no problem without pairing the device and my iPhone application. I am able to connect, reconnect and read/write characteristics without any problem.
But, if the device need to be paired, I am only able to read/write characteristics the first time, right after the pairing popup confirmation. The next time, I discover and connect the app to my device, but I don't have the rights to read/write characteristics data because (I guess) I am not using the pairing information.
Finally...
After spending few hours searching around the web with no luck here are my questions :
How can I connect my app to a Bluetooth LE device from my iPhone app using the pairing data stored in my phone? Am I missing something?
Is it possible that it is not an IOS problem because if pairing data are present in the phone for the connecting device, it is automatically used?
Is there someone with experience with Bluetooth LE and IOS to help me?
Update 2013-10-27
I have discovered that you can't read a protected characteristic by pairing authentication right after that the characteristic has been discovered if a pairing exists (no confirmation popup). No problem with non-protected characteristic! I don't know exactly why is happening, but the behavior is that the IOS app never receive answers from the device.
So if the first reading is done after, it doesn't cause problem. Here is the code I am using to discover characteristics with the data reading in comment.
- (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];
}
}
}
You don't have to do anything in your app for pairing management.
If your app runs in LE Central mode, and the peripheral sends an Insufficient Authentication error code in response to a read / write request, iOS will automatically pair with your device and will retry the request.
If you disconnect from the device, and later reconnect again, the peripheral needs to send the Insufficient Authentication error code again for the iPhone to restart encryption. Again, you don't have to do anything special in your app here.
If your app runs in LE Peripheral mode, things are a bit different. When you set up your GATT database, make sure to set correct flags for both the CBAttributePermissions and CBCharacteristicProperties. This will tell iOS that it should send the Insufficient Authentication error code itself, if it is not paired. It is then the responsibility of the central device to start the encryption process.
In the Bluetooth Accessory Design Guidelines for Apple Products, further restrictions are described.
Your accessory needs the capability to resolve private Bluetooth addresses. The iPhone will change its public Bluetooth address every now and then, and only paired devices will have the correct key to resolve that public address and recognize the iPhone.
"Section 3.9 Pairing" is also interesting.
Note that if you pair without man-in-the-middle (MITM) protection, your peripheral can use the resulting key to resolve the private Bluetooth address of the iPhone. However, you won't be able to encrypt the channel.
Pairing with MITM protection on iOS involves entering a PIN code that is displayed by the remote device. Out-of-band (OOB) pairing where you send pairing data over an external channel is not supported by iOS as far as I know (at least there's no public APIs to set OOB data).
Long story short: if you have only a "Pair" / "Cancel" pairing, you cannot encrypt the LE channel but only recognize the iPhone in future connections. The nice thing is that you can still recognize the iPhone even if you unpair it on the iPhone side, and even after restoring the iPhone firmware ;-).
Regarding LE encryption in general: it's not secure anyways (see http://eprint.iacr.org/2013/309).
这篇关于IOS蓝牙LE：不能使用存储的数据的配对连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！