通过NFC进行蓝牙OOB切换，无需用户确认（或：Android Beam如何工作）

Question

我正在尝试在Android智能手机和Linux主机之间实现类似Android-Beam的行为。 Android智能手机（Galaxy Note 3，Android 4.4.2）触及连接到Linux主机的NFC Dongle，并通过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哈希和随机数发生器？这可能是我的配对需要用户确认的原因吗？
• 如果Android正在使用其他机制，那么HR消息大致如何？他们是否使用特殊类型名称（“application / vnd.bluetooth.ep.oob”除外）或其握手请求中的任何其他内容，这会绕过用户对BT配对的确认？
• Android Beam是否有任何技术文档（我目前无法找到）？ Android开发人员的NFC指南（http://developer.android.com/guide/topics/connectivity/nfc/nfc.html）对Android Beam没什么帮助。

非常感谢任何帮助：）

Answer 1

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

• 是的，Android正在使用SSP，但Hash和Randimizer不是必需的，所以必须它们包含在NDEF HR / HS消息中。
• Android 使用类型名称为“application / vnd.bluetooth.ep.oob”的HR消息，这是正确的。
• 如果一个设备确认配对过程，对SSP似乎就足够了。因此，我的问题的解决方案是，将Linux主机的IO功能设置为“DisplayYesNo”，然后自动确认授权请求。这样，Linux主机伪造用户输入，Android移动设备不再要求用户确认。快速（有点脏）的方法是改变BlueZs“simple-agent”脚本以确认每个授权请求。