深入理解低功耗蓝牙的配对过程- Part 3 LE legacy Pairing Passkey Entry

在前一篇文章深入理解低功耗蓝牙的配对过程- Part 2 Key Generation Methods中,讨论了密钥生成方法,如果配对发起设备和响应设备满足一些IO功能的条件,它们将选择LE legacy Bluetooth配对Passkey Entry方法。

在此文中,我将研究legacy pairing with Passkey Entry的配对以及它是如何工作的。

 

Figure 1: LE Legacy Pairing, Passkey Entry

临时密钥(TK)和随机数生成

当您使用LE legacy pairing时,该配对双方各自将生成一个临时密钥(TK)。

  • 如果设备的IO功能(无论是配对发起设备还是响应设备)具有显示功能,那么它将显示随机生成的介于“000000”和“999999”之间的密钥值。而另外的设备应该具有类似键盘的输入功能,这样用户就可以通过键盘输入这个TK显示的值。例如手机和手环的配对方式,手环的屏幕可以显示TK值,而手机可通过键盘输入手环上显示的TK值完成配对。
  • 如果配对发起设行和响应设备的IO功能都没有显示功能,但都是“Keyboard Only”,那么用户需要确保发起设备和响应设备之间的临时密钥(TKs)是相同的。这是Passkey Entry的一个特殊情况。

下面是一个名为“Authentication”的设备,它希望与iOS设备配对,并在其输出接口上显示TK。然后iOS设备弹出一个对话框,要求用户输入TK值。

 

Picture 2: Passkey Entry on iOS Device

  • 当TK值准备好时,配对发起设备和响应设备生成一个128位的随机数: Mrand是发起设备产生的(“主随机”),Srand是由响应设备产生的(“从随机”)。

Mconfirm and Sconfirm

Mconfirm和Sconfirm是128位的确认值,可以使用确认值生成函数c1来计算。这个功能的详细信息可以在这里找到:蓝牙核心规范V4.2, Vol.3, Part H, Section 2.2.3。

c1函数的输入参数包括:

  • TK   Mrand for Mconfirm; or Srand for Sconfirm calculation
  • Pairing Request command 
  • Pairing Response command 
  • Initiating device address type
  • Initiating device address 
  • Responding device address type  
  • Responding device address 

验证

  • 当Mconfirm和Sconfirm就绪时,配对发起设备将Mconfirm发送给响应设备。当响应设备接收Mconfirm时,它将Sconfirm发送给发起设备。当发起设备接收到Sconfirm时,它将Mrand发送到响应设备。
  • 响应设备通过重复计算发起设备接收到的Mrand值得出的计算结果来验证Mconfirm值。
  • 如果响应设备计算的Mconfirm值与发起设备接收到的Mconfirm值不匹配,则配对过程将中止,响应设备将发送配对失败命令,并给出失改原因代码“Confirm value Failed”。
  • 如果响应设备计算的Mconfirm值与从发起设备接收到的Mconfirm值匹配,则响应设备将Srand传输给发起设备。
  • 发起设备通过重复使用接收到的Srand值执行响应设备的计算来验证接收到的Sconfirm值
  • 如果配对发起设备计算的Sconfirm值与从响应设备接收到的Sconfirm值不匹配,则配对过程将中止,发起设备将发送配对失败命令,并给出其中的失败原因代码为“Confirm value Failed”。
  • 如果发起设备计算的Sconfirm值与从响应设备接收到的Sconfirm值匹配,则发起设备计算短期密钥(STK)并告诉控制器启用加密。

短期密钥产生

您可以查阅蓝牙核心规范V4.2, Vol.3, Part H, Section 2.2.4,此章节中详细介绍的密钥生成函数s1来生成STK。

对于s1函数,输入参数包括:

  • TK
  • Srand
  • Mrand

已配对的设备用STK建立一个加密链接。

以下是Ellisys抓取的空中数据包,从中可以清楚的看到STK产生流程 ,如下:

在接下来的第4部分中,我介绍了LE Secure Connection中的一种新的配对算法: Numeric Comparison.

原文地址:https://www.cnblogs.com/lim11/p/11169109.html