我正在尝试使用许多信标开发一个应用程序，比如说在任何多层购物中心。在这种情况下，我该如何控制这些
假设有人克隆信标并开始使用相同的UUID，主要和次要广告信号，如何防止这种情况以及可以采取的其他安全措施是什么？
如何避免多个通知，假设两个信标冲突的地方任何区域对于多个信标都是常见的，如何在app中控制？
答案 0 :(得分：6)
iBeacon标准没有提供任何防止克隆的内置方法。 Apple限制iOS设备看到iBeacons，除了已知ProximityUUID的设备，这表明这可能是一项基本的安全尝试。但由于其他操作系统（Android，OSX Mavericks，Linux）允许读取所有iBeacons的标识符，因此这种限制似乎相当愚蠢。可以使用Android iBeacon Locate之类的工具读取标识符，并使用相同的标识符部署您自己的iBeacon。
解决此问题的四种常用方法：
什么都不做。这适用于大多数使用克隆信标会造成轻微后果的情况，或适用于低调部署的情况，因为这样做的风险很小。
旋转iBeacon标识符。您可以通过替换信标或定期手动更改其标识符来手动执行此操作。这并不能解决问题，但它会限制风险和对时间的影响。
使用自动旋转标识符与自动系统相结合，验证/将其转换为可信标识符。
放弃iBeacon标准并使用加密的专有信标技术。这应该被认为是最后的选择，因为这种选择使得无法使用广泛使用的开源和商业工具来使用iBeacons，并将您锁定在一个供应商中。
在您选择除第一个选项之外的任何选项之前，请务必仔细评估克隆的风险和后果，并确保您采取的任何对策确实值得克服。
在没有故意克隆的情况下，问题中描述的多重通知问题通常不是问题。只需将您的信标的ProximityUUID /主要/次要编号设计为您希望提供给用户的每个事件的唯一编号，并使您的应用做出适当的响应。
答案 1 :(得分：1)
对于信标克隆：
自定义您的信标固件并使用随机密钥加密主要/次要。如果beacon和app都可以访问云，可以通过云交换随机密钥来加密/解密主要/次要ID。如果不涉及云，则beacon和app需要处理随机密钥生成算法，使用时间作为种子。 （使用永久固定密钥加密是没用的，因为克隆或重播信标广告数据仍然可以欺骗应用程序）
使用预定义的基于表的列表旋转UUID。这只是通过定期更改UUID来降低风险，但并未真正解决安全问题。并且UUID列表的大小有限，因为列表中的所有UUID可能需要在App（例如iOS）中预先注册，以便iOS将其作为可识别区域，然后将数据传递到您的应用程序。
对于多重通知：
通常，这应由App处理。 当输入区域或信标触发器回调时，app应该通过uuid-major-minor信息检查它是否是重复区域。应用程序还应检查是否已将相关通知/信息发送给用户，以避免用户因重复通知而烦恼。