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

我正试图在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的握手请求中丢失.

所以我的问题是：

>首先,Android Beam是否使用与OOB的安全简单配对或其他机制？为什么两台Android设备之间的Android Beam无法确认配对？
>如果它正在使用SSP,为什么HR消息中缺少SSP哈希和随机数发生器？这可能是原因,为什么我的配对需要用户确认？
>如果Android使用其他机制,那么HR消息大致如何？他们是否使用特殊类型名称(“application / vnd.bluetooth.ep.oob”除外)或其握手请求中的任何其他内容,这会绕过用户对BT配对的确认？
> Android Beam是否有任何技术文档(我目前无法找到)？ Android开发人员(http://developer.android.com/guide/topics/connectivity/nfc/nfc.html)的NFC指南对Android Beam没什么帮助.

任何帮助深表感谢 ：)

解决方法:

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

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

标签：android,bluetooth,nfc,android-beam
来源： https://codeday.me/bug/20190628/1320771.html