我们正在跨越多个地点讨论iBeaons的大规模部署方案。提出的问题是,iBeacons宣传其存在的ID是否是唯一的?因为我们的客户想要确定应用程序只响应特定的iBeacons,而不是用模拟相同ID的其他内容(即使是在不经意间)。
如果不是唯一的,协议是否允许iBecaons宣传任何其他身份验证信息?
答案 0 :(得分:14)
绝对有可能冒充另一个iBeacon。我带着Android iBeacon Locate app的副本去了华盛顿特区的Apple Store,用它来扫描iBeacons的标识符。 Apple的商店。然后我回到我的办公室并配置我自己的iBeacon来传输这个相同的三部分标识符,并且能够让我的iPhone在Apple的商店消息中得到相同的效果。如果他们真的想要,你不能阻止其他人这样做。但好消息是,对于大多数用例而言,其他人没有真正的动机去做这件事。
也就是说,iBeacon标识符的无意中重叠是不太可能的。如果您使用标准UUID生成器生成自己的ProximityUUID,另一个生成的ProximityUUID偶然相同的几率非常小 - less than the odds of being hit by a meteorite.
标准iBeacons没有任何其他认证机制。它们是无连接,仅传输设备,仅发送三部分标识符(Proximity UUID,Major,Minor)和发射机功率校准值。
答案 1 :(得分:2)
我在Gelo(http://www.getgelo.com)的信标工作。对我们的一些客户来说,有效负载保密和反欺骗是一个非常大的问题。
UUID本身并不保证是唯一的。完全可以欺骗UUID及其所有广告数据(包括主要/次要)。这带来了许多安全风险。
有些信标制造商采用旋转UUID方案,每隔X分钟,几秒或几小时UUID本身就会改变。这将意味着想要拦截和/或欺骗信标的人需要要么与原始设备处于相同的位置并且不断地匹配新值或者计算出旋转方案或算法。
旋转UUID方法的问题在于它不保护有效载荷(广告消息或扫描响应),因此攻击者可以模仿另一个信标并更改正在发送的值。根据信标通信的内容以及任何监听设备(观察者,BLE术语中的中心)或消费应用程序的使用方式,这可能不是问题,也可能是一个非常大的问题。
我们花时间研究如何在考虑功耗的同时降低各级风险。这是因为大多数BLE信标都是使用电池运行的,并且您希望尽可能延长电池寿命。我们已经提出了一种方法,可以成功地降低拥有近10万个地点的国际组织的风险。
解决这个问题是可能的,这是我们一直在努力的事情。如果您正在寻找这个,请给Gelo打个电话或发电子邮件。我们也许可以帮到你。
答案 2 :(得分:1)
肯定没有" UUID反欺骗"在iBeacon技术中实施。事实上,许多开发人员使情况更糟,只使用iBeacon供应商提供的默认UUID。因此,无论何时你去 - 在Estimote iBeacon周围,你都会看到一个在当前环境中无效的应用程序,因此只需添加到用户'混乱。
您可以通过为部署使用全球唯一的邻近UUID生成器和目录来帮助防止此问题并保持环境更清洁。
请参阅我们的OpenUUID服务,该服务旨在实现这一目标......
答案 3 :(得分:0)
iBeacon ID为20字节(16字节UUID,加上2字节“Major”号码和2字节“Minor”号码)。有人猜测或意外地选择完全相同的所有20个字节并且同时在同一个信标的范围内的几率非常小。 BLE信号的近似唯一数字和相对短距离的组合使得意外碰撞变得不太可能。
答案 4 :(得分:0)
除了感知上述参数外,您通常还可以获得有关信标mac地址的信息。如果它基于任何更常见的电路,例如TI CC240x芯片,则MAC地址是每个芯片唯一的硬编码。所以不容易欺骗。
如果您既是信标部署者又是应用程序提供者,那么一个典型的想法是将一些自定义服务/特性编程到信标中,以便您的应用程序可以连接到它并验证它是已知的信标。但如果您完全允许某人连接,则意味着信标对拒绝服务攻击极为敏感。大多数信标都是单任务,并且不能同时辐射和识别并处理连接尝试。因此,一些黑暗力量可以在附近安装“信标时间模块模块”,让你的信标忙于与浪费者交谈,而不是提供你想要的id辐射。那些旋转的UUID方案在恶劣的环境中可能已经足够好了。在大多数情况下,我会说信标可能几乎不受干扰。开发信标质量监控应用程序或自定义BLE设备非常容易,该设备将继续监听已部署的信标并报告正常运行时间。这样,如果节点停止服务,将会警告部署的信标场的部署者。