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