5

我正在尝试在 Android 智能手机和 Linux 主机之间实现类似 Android 的行为。Android 智能手机（Galaxy Note 3、Android 4.4.2）触摸连接到 Linux 主机的 NFC 加密狗并通过 NFC 交换蓝牙运营商数据，然后它可以连接到同样连接到 Linux 主机的蓝牙加密狗。

现在的问题是，Android 智能手机总是询问用户（我）是否真的想与蓝牙适配器配对。在两部 Android 手机之间的 Android Beam 中，不会显示此用户确认，用户只需单击内容（即图片）即可发送（这是我试图达到的行为）。我正在使用“nfctool”来嗅探 Android 手机传入的握手请求消息（请参阅http://pastebin.com/Dr0D0nqn）。根据 NFC 论坛的“使用 NFC 进行蓝牙安全简单配对”文档（参见http://members.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf第 19 页），此握手请求应包含简单配对哈希和一个简单的配对随机化器，

所以我的问题是：

  • 首先，Android Beam 是完全使用带 OOB 的安全简单配对，还是其他机制？为什么两个 Android 设备之间的 Android Beam 在没有确认配对的情况下工作？
  • 如果是使用 SSP，为什么 HR 消息中缺少 SSP Hash 和 Randomizer？这可能是我的配对需要用户确认的原因吗？
  • 如果 Android 使用的是另一种机制，HR 消息大致是什么样的？他们是否在握手请求中使用了特殊类型名称（“application/vnd.bluetooth.ep.oob”除外）或其他任何内容，从而绕过了用户对 BT 配对的确认？
  • 是否有任何可用的 Android Beam 技术文档（到目前为止我找不到）？Android 开发人员的 NFC 指南 ( http://developer.android.com/guide/topics/connectivity/nfc/nfc.html ) 对 Android Beam 没有多大帮助。

任何帮助深表感谢 ：）

4

1 回答 1

4

我终于找到了这个问题的解决方案，并回答了我的大部分问题：

  • 是的，Android 正在使用 SSP，但 Hash 和 Randimizer 不是强制性的，因此不必将它们包含在 NDEF HR/HS 消息中。
  • Android正在使用类型名称为“application/vnd.bluetooth.ep.oob”的 HR 消息，这是正确的。
  • 如果一台设备确认配对过程，SSP 似乎就足够了。所以我的问题的解决方案是，将Linux主机的IO能力设置为“DisplayYesNo”，然后自动确认授权请求。这样，Linux 主机会伪造用户输入，Android 手机将不再要求用户确认。实现这一点的一种快速（但有点脏）的方法是更改​​ BlueZ 的“简单代理”脚本以确认每个授权请求。
于 2014-08-11T10:09:51.590 回答