如何实现与CBPeripheral的安全连接? [英] How to implement secure connection to CBPeripheral?

查看:308
本文介绍了如何实现与CBPeripheral的安全连接?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我只希望将受信任的设备连接到我的外围设备。而且我不希望任何人都能发现我的外围设备的服务和特性。
因此,在连接外围设备之前,我想显示一个带有密码的警报。



我找不到此问题的答案,并试图通过向权限添加CBAttributePermissionsWriteEncryptionRequired来实现加密特征,这是可能的吗? :

  self.characteristic = [[CBMutableCharacteristic alloc] initWithType:[JUUIDBuilder uuidWith:@ 1706] 
属性:CBCharacteristicPropertyWrite
值:无权限:CBAttributePermissionsWriteEncryptionRequired];

由于某种原因,它无济于事,因为我能够从第二台设备全部写入值没有任何安全检查的时间。 (CBAttributePermissionsReadEncryptionRequired的文档说:


...该特征被配置为仅允许受信任的设备读取或订阅其值。连接,远程中心尝试读取或订阅此特征的值,Core Bluetooth尝试将您的本地外围设备与中心配对以创建安全连接。


这对我没有意义。这里的受信任设备是什么?



任何人都可以帮助我吗?

解决方案

您不能阻止服务和特征被发现。您可以宣传主要服务并拥有辅助服务,这些服务不做广告,但是一旦建立连接,所有服务和特征都会显示出来。



如果您指定属性需要加密,则首次尝试读取/写入特征时,将启动配对(技术上绑定)过程。此过程交换加密密钥,并导致设备彼此信任。



如果外围设备和中央设备都是iOS8设备,那么我发现如果这两个设备都是如果使用相同的iCloud帐户配置了该信任关系,则已经建立了信任关系(大概是针对此类切换的功能),您将永远不会看到配对对话框。当我尝试测试加密特征时,这引起了我很大的困惑。



如果您使用具有不同iCloud帐户的设备进行测试,则应该看到配对对话框。 / p>

如果攻击者控制了两个设备,那么即使配对过程也不能保护您的服务/特性,因为它们可以轻松完成配对过程。配对/绑定确实可以防止数据被窃听,因为传输将被加密。



要真正保护服务,您需要在暴露之前需要某种形式的挑战/响应,其中涉及特性数据。



例如,中央需要从特性 A中读取一个值,该值由外围设备随机设置。然后,中央需要计算对该值的正确响应,并将其写回 A。仅当该值正确时,外围设备才能设置其余特性(或从中央接受其他特性的输入)。



此解决方案只有在因为您的质询/响应机制不会受到影响,但可能会击败不确定的攻击者。


I want only trusted devices to connect to my peripheral. And I don't want anyone to be able to discover services and characteristics of my peripheral. So before connecting to the peripheral I would like to show an alert with a pin code. Is it possible to do it and what is the easiest way?

I couldn't find the answer to this question and tried to implement encrypted characteristic by adding CBAttributePermissionsWriteEncryptionRequired to the permissions:

self.characteristic = [[CBMutableCharacteristic alloc] initWithType:[JUUIDBuilder uuidWith:@"1706"]
                                                         properties: CBCharacteristicPropertyWrite
                                                              value:nil permissions:CBAttributePermissionsWriteEncryptionRequired];

For some reason it didn't help because I'm able to write values from my second device all the time without any security checks. (Documentation for CBAttributePermissionsReadEncryptionRequired says:

...the characteristic is configured to allow only trusted devices to read or subscribe to its value. When a connected, remote central tries to read or subscribe to this characteristic’s value, Core Bluetooth tries to pair your local peripheral with the central to create a secure connection.

which doesn't make sense to me. What is "trusted devices" here?

Can anyone help me? What is the best practice to allow connections only from trusted devices with pin code confirmation?

解决方案

You cannot prevent services and characteristics being discovered. You can advertise a primary service and have secondary services that aren't advertised, but once a connection is made all services and characteristics will be revealed.

If you specify that an attribute requires encryption, then a pairing (technically bonding) process will be initiated when you first try to read/write the characteristic. This process exchanges encryption keys and results in the devices 'trusting' each other.

If your peripheral and central are both iOS8 devices, then I have found that if both devices are configured with the same iCloud account then the trust is already established (presumably for functions such handoff) and you will never see the pairing dialog. This caused me quite a bit of confusion when I was trying to test encrypted characteristics.

If you test using devices with different iCloud accounts then you should see the pairing dialog.

Even the pairing process will not "protect" your service/characteristic if the "attacker" has control of both devices as they can simply complete the pairing process. Pairing/bonding does protect the data against eavesdropping as the transfer will be encrypted.

To actually protect the service you would need some form of challenge/response involving a characteristic before exposing data.

For example the central needs to read a value from characteristic "A" which is set at random by the peripheral. The central then needs to calculate the correct response to that value and write it back to "A". Only if this value is correct does the peripheral set values on the remaining characteristics (or accept inputs on the other characteristics from the central).

This solution is only secure as long as your challenge/response mechanism isn't compromised but will probably defeat non-determined attackers.

这篇关于如何实现与CBPeripheral的安全连接?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆