BLE蓝牙的连接和配对过程

一 连接

连接过程参考:
https://blog.csdn.net/iini01/article/details/80147232

二 配对

区别于传统蓝牙的配对过程,BLE的配对过程发生在连接过程之后

配对是一个三阶段的过程。前两个阶段是必须的,第三阶段是可选的。

  • 第一阶段:配对特征交换
  • 第二阶段:短期秘钥(STK)生成
  • 第三阶段: 传输特定秘钥分配

image

image

STK生成规则

  1. Just work: 没有加密 TK=0x00
  2. passkey entry: 密码输入如果 passkey 是 ‘019655’ TK的值就是0x00000000000000000000000000004CC7。
    将输入的值作为一个6位数的十进制,转换成16字节的十六进制。
  3. OOB: 带外的TK值是一个16字节的随机数,通过非BLE的方式传递给对端。

2.1 第一阶段

设备首先在配对特征交换阶段交换IO能力来决定在第二阶段使用下面哪种方法:

  • JustWorks:只工作
  • PasskeyEntry:输入密码
  • OutOfBand(OOB):带外

LE Legacy Pairing - Just Works
Just Works方式不能抵抗窃听者和中间人攻击,只有在配对过程时没有遭受攻击,后面加密的链路的数据传输才是可信的。安全级别很低。

LE Legacy Pairing - Passkey Entry
这种方式通过输入6位数字的方式来进行配对,生成STK。6位数是随机产生的在000000到999999之间的数值,这个数值相当于一个TK,比如远端显示这个数字,需要在本地端输入这个数字给本地设备与远端配对。如输入019655,那此时的临时Key–TK是:0x00000000000000000000000000004CC7。

Out of Band 带外
这种方式是通过BLE之外的,设备上的其他方式来获取这个OOB data,比如通过IR红外,或其余的方式,因此对于蓝牙窃听者/攻击者而言这个data的传输是不可见的了,因此会显得要安全些。

2.1.1 配对请求的数据格式

image

1. IO capabilities表明输入,输出的能力

输入是按键、键盘,输出是显示数字用的界面。

  • 0x00 DisplayOnly 只能是显示000000 ~ 999999的数字
  • 0x01 DisplayYesNo 显示Yes/No 的按钮
  • 0x02 KeyboardOnly 只能是输入000000 ~ 999999的数字
  • 0x03 NoinputNoOutput 没有输入也没有显示,只能用Just work工作方式
  • 0x04 KeyboardDisplay 能输入000000 ~ 999999的数字和输出

2. OOB data flag

  • 0x00 OOB 数据没有发送
  • 0x01 OOB 数据通过远端设备发送(如IR)
  • 0x02-0xFF 保留

3. 身份验证请求

image

  • Bonding_Flags b1b0 Bonding Type

    • 00 No Bonding
    • 01 Bonding
    • 10 Reserved
    • 11 Reserved
  • MITM

MITM域设置为1为请求MITM(中间人介入)保护,否则设置为0. 设备将标志设置为1为STK请求认证的安全属性。
选择Key生成的方法
如果auth Req中MITM没有,则说明不需要人参与中间,所以IO capabilities会被忽略,只用Just Works就OK了。
如果有OOB data,auth Req将可直接忽略,会直接选择OOB的方式了。

  • SC

SC字段是一个1位标志,设置为1以请求LE安全连接配对,否则应根据发起方和响应方支持的功能将其设置为0,可能的结果配对机制为:如果两个设备均支持 LE安全连接,使用LE安全连接; 否则,请使用LE旧式配对。

  • Keypress

keypress字段是一个1位标志,仅在Passkey Entry协议中使用,而在其他协议中将被忽略。 当双方将该字段设置为1时,应使用SMP配对按键通知PDU生成并发送按键通知。

4. MaximumEncryptionKeySize

最大秘钥长度,7到16字节之间

5. InitiatorKeyDistribution

发起者的秘钥分配,该域表明秘钥初始化设备请求分配使用。

配对请求命令中的“生成”字段由主机使用,以请求发起者向响应者分发或生成哪些密钥。

6. ResponderKeyDistribution

响应者的秘钥分配,该字段表明秘钥初始化设备请求响应设备来分配秘钥分配使用。

2.1.2 配对请求实例

image

1. Code (1 octet)

0x01 Pairing Request

2. IO Capability (1 octet)

0x03 NoInputNoOutput: 用just work 认证方式

3. OOB data

0x00 OOB(out of band)
没有带外认证, 带外这种方式是通过BLE之外的,设备上的其他方式来获取这个OOB data,比如通过IR红外,或其余的方式,因此对于蓝牙窃听者/攻击者而言这个data的传输是不可见的了,因此会显得要安全些。

4. AuthReq (1 octet)

AuthReq字段是一个位字段,指示STK和LTK以及GAP绑定信息的请求安全属性
0x01 :表示绑定

5. MaxEncKeySize

0x10 表示最大认证key大小是0x10个字节

6. InitiatorKeyDistribution

该域表明秘钥初始化设备请求分配秘钥分配使用。

7. ResponderKeyDistribution

001 该字段表明秘钥初始化设备请求响应设备来分配秘钥分配使用。

2.1.3 从设备向主设备向发送配对回复报文

image

具体字段含义参考 配对请求报文。

2.2 第二阶段

2.2.1 配对确认

第一阶段的配对特征交换成功之后,用来启动STK生成。该命令被两个对等设备使用,来向对等设备发送确认值。初始化设备通过向响应设备发送配对确认命令启动STK生成。

报文格式
image

启动STK的生成,这一部分可简述为以下步骤的实现

  1. Initiator生成128-bit随机数Mrand,并使用这个Mrand结合一些其他的输入,使用密码工具箱中c1计算出一个128-bit的Mconfirm值:
Mconfirm = c1(TK, Mrand,
Pairing Request command, Pairing Response command,
initiating device address type, initiating device address,
responding device address type, responding device address)

Responder也生成一个128-bit随机数Srand,并使用这个Srand结合一些其他的输入,使用密码工具箱中c1计算出一个128-bit的Sconfirm值:

Sconfirm = c1(TK, Srand,
Pairing Request command, Pairing Response command,
initiating device address type, initiating device address,
responding device address type, responding device address)
  1. Initiator将其计算的Mconfirm值通过Pairing Confirm包发送给Responder,而Responder也将其计算的Sconfirm值通过Pairing Confirm包发送给Initiator;
  2. Initiator收到Sconfirm后,再将Mrand值通过Pairing Random包发送给Responder;
  3. Responder收到Mrand值后计算它的Mconfirm值,再跟前面那个Initiator送过来的Mconfirm值进行比较,若不同说明配对失败了。若相同,则Responder也会将它的Srand值通过Pairing Random包发送给Initiator;
  4. 而Initiator也会计算收到的Srand值的Sconfirm值,并跟前面那个Responder送过来的Sconfirm值进行比较,若不同说明配对失败了,若相同,继续。

报文实例

主设备向从设备发送配对确认报文,从设备也向主设备发送配对确认报文。

image

image

2.2.2 随机配对

该命令用来由初始化和响应设备发送,用来计算在配对确认命令中的确认值的随机数。

报文数据格式
image

报文实例

主设备向从设备发送配对随机值报文,从设备也向主设备发送配对随机值报文。
image

image

2.3 第三阶段

2.3.1 传输特定的密钥分发

所有的键和值都由主从设备分发。

要分发的密钥由配对请求和配对响应的密钥分发参数决定,
配对请求和配对响应来自第一阶段配对特征交换
image

BLE的SMP的一些Key相关定义

  1. Long Term Key (LTK):加密链路用,128-bit;

  2. Encrypted Diversifier (EDIV):在LE legacy pairing过程中,用于识别LTK分发,16-bit;

  3. Random Number (Rand):在LE legacy pairing过程中,用于识别LTK分发,64-bit。

  4. Identity Resolving Key (IRK):用于生成和解析random address用的,128-bit;

  5. AddrType (1 octet)
    如果BD_ADDR是公共设备地址,则AddrType应设置为0x00。
    如果BD_ADDR是静态随机设备地址,则AddrType应设置为0x01。
    BD_ADDR(6个八位字节)此字段设置为分发设备的公共设备地址或静态随机地址。

  6. Connection Signature Resolving Key (CSRK):用于对数据进行签名已经验证签名数据,128-bit;

2.3.2 特定key分发原因

密钥分发阶段的从设备将密钥发送给主设备,这样就可以对重新连接进行加密,并解析其随机地址。或者,主设备可以验证来自从设备的签名数据,主设备也可以向从设备提供密钥,这样,如果角色互换,可以对重连接进行加密,可以解析主设备的随机地址,或者从设备可以验证来自主设备的签名数据。

三 绑定

就是将配对阶段产生的一系列key 保持到flash中,以便后续使用。

以上这个过程的报文交互如下图,
image

发布了12 篇原创文章 · 获赞 5 · 访问量 2462

猜你喜欢

转载自blog.csdn.net/chengbaojin/article/details/103691046