且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

Android上的BLE外设配对引脚

更新时间:2023-01-24 07:38:46

摘要:将客户端的I/O功能设置为仅键盘".

说明:

我不太确定系统幕后"会发生什么.但是我可以告诉您根据BLE CoreSpec应该发生什么.首先请参阅CoreSpec V4.2,第1卷. 3,H部分,第二章. 2.3.5.1,表2.7& 2.8.根据身份验证要求和设备的I/O功能,在其中定义使用哪种配对.

I am not fully sure what happens "under the hood" of your system. But I can tell you what should be happening according to the BLE CoreSpec. First see CoreSpec V4.2, Vol. 3, Part H, chap. 2.3.5.1, table 2.7 & 2.8. There it is defined which pairing is used, depending on the authentication requirements and the I/O capabilities of the devices.

所需的内容描述为密码输入:响应者显示,发起者输入".如果使用旧式配对(根据Bluetooth V4.0配对),并且满足以下条件,则为这种情况:

What you want is described as "Passkey Entry: responder displays, initiator inputs". This is the case if legacy pairing (pairing according to Bluetooth V4.0) is used, and if:

  • 服务器(响应者)显示为AND
  • 客户端(发起者)具有键盘AND
  • 服务器和客户端都没有显示器和键盘.

(如果未使用OOB数据并且强制执行了MITM,但我假设是给定的,则应注意.)请注意,如果客户端和服务器都具有显示器和键盘,则默认情况是客户端显示并且服务器输入.看来,如果您的协议自动处理配对,它也会自动选择CoreSpec中定义的配对方法.

(And if OOB data is not used and MITM is enforced, but I assume this as given.) Note that if both client and server have display and keyboard, the default case is that the client displays and the server inputs. It would seem that if your protocol automatically handles pairing, it will also automatically chose the pairing method as defined in the CoreSpec.

因此,您所看到的对应于不同服务器的不同I/O功能.看来您的客户端具有显示器和键盘,因此,如果您使用具有显示器和键盘的服务器,则客户端将显示密码,响应者将等待输入(适合您的情况1).对于案例2,我们有数值比较;只有在客户端和服务器都支持LE安全连接(根据Bluetooth V4.2进行配对)的情况下,才有可能.

So what you see is corresponding to different I/O capabilities of different servers. It seems that your client has display and keyboard, so if you use a server with display and keyboard, the client will display the passkey and the responder will wait for input (which fits to your case 1). For case 2, we have Numeric Comparison; this is only possible if LE Secure Connections (pairing according to Bluetooth V4.2) is supported by both client and server.

对于情况3,我不知道发生了什么,但这可能是Android系统和iOS系统不能很好地运行(但我不知道为什么)之间的问题.

For case 3, I don't know what is going on, but it may be a problem between an Android system and an iOS system not operating well together (but I have no idea why).

由于配对似乎在此处已完全自动化,因此更改内容的唯一可能性是更改I/O功能.应该有一个更改这些功能的功能,请查阅手册.如果您不想在客户端上使用显示器,请将其I/O功能设置为仅键盘",它将显示您期望的行为.(*)

Since pairing seems to be fully automized here, the only possibility to change things is to change the I/O capabilities. There should be a function to change these capabilities, check your manual. If you do not want to use a display on the client, set its I/O capabilities to "Keyboard Only" and it will exhibit the behavior you expect.(*)

(*)仅在使用旧式配对时成立.如果两个设备均支持LE安全连接,则建议您使用此较新的配对协议,因为它消除了旧协议的安全性问题. (不过,我认为在这种情况下,无论如何都会自动使用较新的协议.)

(*) This holds only if you use legacy pairing. If both devices support LE Secure Connections, it is recommended that you use this newer pairing protocol, since it removes security issues with the old protocol. (I would however assume that in this case, the newer protocol is used automatically anyway.)