0

我正在尝试使用许多信标开发一个应用程序，例如在任何多层购物中心中说的。在这种情况下，我该如何控制这些

  1. 假设有人克隆了一个信标并开始使用相同的 UUID、主要和次要广告信号，如何防止这种情况以及可以采取哪些其他安全措施？

  2. 如何避免多个通知，假设某个地方与两个信标冲突，任何区域对多个信标都是通用的，如何在应用程序中控制它？

4

2 回答 2

7

iBeacon 标准不提供任何内置方法来防止克隆。Apple 限制 iOS 设备查看 iBeacons，除非是已知 ProximityUUID 的设备，这表明这可能是一种初步的安全尝试。但由于其他操作系统（Android、OSX Mavericks、Linux）允许读取所有 iBeacons 的标识符，这种限制似乎相当愚蠢。可以使用Android iBeacon 之类的工具读取标识符定位 并使用相同的标识符部署您自己的 iBeacon。

解决此问题的四种常见方法：

  1. 没做什么。这适用于克隆信标会导致轻微后果的大多数用例，或者适用于有人这样做的风险很小的低调部署。

  2. 轮换 iBeacon 标识符。您可以通过更换信标或定期手动更改其标识符来手动执行此操作。这并没有消除问题，但它限制了风险和对时间的影响。

  3. 使用与自动化系统相结合的自动轮换标识符来验证/将其转换为可信标识符。

  4. 放弃 iBeacon 标准并使用使用加密的专有信标技术。这应该被视为最后的手段，因为这种选择使得无法使用广泛可用的开源和商业工具来处理 iBeacons，并将您锁定在单一供应商中。

在您选择第一个以外的任何选项之前，请务必仔细评估克隆的风险和后果，并确保您采取的任何对策确实值得缺点。

问题中描述的多重通知问题在没有有意克隆的情况下通常不是问题。只需将信标的 ProximityUUID/主要/次要编号设计为对于您希望提供给用户的每个事件都是唯一的，并使您的应用程序做出适当的响应。

于 2014-04-30T11:34:57.937 回答
1

对于信标克隆：

  1. 自定义您的信标固件并使用随机密钥加密主要/次要。如果信标和应用程序都可以访问云，则可以通过云交换随机密钥以加密/解密主要/次要ID。如果不涉及云，信标和应用程序需要处理随机密钥生成算法，例如使用时间作为种子。（使用永远固定的密钥加密是没有用的，因为克隆或重放信标广告数据仍然可以欺骗应用程序）

  2. 使用预定义的基于表的列表轮换 UUID。这只是降低了定期更改 UUID 的风险，但并不能真正解决安全问题。并且 UUID 列表的大小是有限的，因为列表中的所有 UUID 可能需要在 App（例如 iOS）中预先注册，以让 iOS 将其作为识别区域，然后将数据传递给您的 App。

对于多通知：

通常，这应该由 App 处理。当进入区域或信标触发回调时，应用程序应通过 uuid-major-minor 信息检查它是否是重复区域。应用程序还应检查是否已将相关通知/信息发送给用户，以避免用户被重复通知所困扰。

于 2016-03-03T03:37:11.200 回答