11.BLE---安全机制之LE Encryption

1. 基本概念

  • LE Encryption要完成的事情是面向连接的数据进行加密。
  • 加密/解密的事情,需要在协议的哪个层次去做? ----链路层。
  • 使用什么样的加密/解密算法? ----有一定的标准,未做研究

2.packet的加密/解密过程

 

  • Master/Slave的LE Host会保存一个LTK(Long Term Key,至少128bits),对BLE用户(或者应用)来说,这个Key是所有加密/解密动作源头;
  • 每当为某个LE连接启动加密传输的时候,Master和Slave的LL会协商生成一个128bits的随机数SKD(Session Key Diversifier,128bits),并以它为输入,以LTK为key,通过Encryption Engine加密生成SessionKey;
  • 每当有明文数据包需要发送的时候,需要对明文进行加密。加密的过程,是以明文数据包为输入,以SessionKey为Key,同样通过Encryption Engine加密生成密文数据包;
  • 同样,每当收到密文数据包的时候,需要对密文解密。解密的过程,是以密文数据包为输入,以SessionKey为Key,同样通过Encryption Engine解密生成明文数据包。

3.Encryption Procedure

  • LE Encryption的过程主要由Link Layer控制(具体可参考"BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B] 5.1.3 Encryption Procedure")。
  • 当连接建立之后,Link Layer可以应Host的请求,使能对数据包的Encryption操作,过程如下(具体可参考"BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part D]  6.6 START ENCRYPTION"):

 

3.1 请求Link Layer启动加密

Host A发送LE Start Encryption HCI命令,请求Link Layer启动加密。该命令的格式如下:

Command

OCF

Command parameters

Return Parameters

HCI_LE_Start_Encryption

0x0019

Connection_Handle
Random_Number
Encrypted_Diversifier
Long_Term_Key

   

Connection_Handle,连接句柄;
Random_Number和Encrypted_Diversifier分别简称为Rand和EDIV(Rand是一个64bits的随机数,EDIV是一个16bits的Diversifier),它们在LE Legacy Pairing的过程中,用于在多个LTK标识某一个具体的LTK。而在新的LE Secure Connections Pairing过程中,则不再使用(赋值为0即可)。关于LE的配对过程,可参考后面SMP的分析文章,这里不再详细描述;
Long_Term_Key,保存在Host段的加密key。

3.2 LL A收到Host的加密请求之后,会向LL B发送LL_ENC_REQ PDU以请求加密,该PDU的格式为:

Rand (8 octets)

EDIV (2 octets)

SKDm (8 octets)

IVm (4 octets)

Rand和EDIV就是上面的Random_Number和Encrypted_Diversifier;
SKDm(session key diversifier ),是一个64bits的随机数,用于和SKDs一起,生成本次加密的SessionKey;
IVm(initialization vector ),一个32bits的随机数,和IVs一起组成64bits的IV,后面Encryption Engine会使用。

3.3 LL B收到LL_ENC_REQ PDU之后,会向Host B发送LE Long Term Key Request HCI Event,该Event的格式为:

Event

Event code

Event Parameters

LE Long Term Key Request

0x3E

Subevent_Code
Connection_Handle
Random_Number
Encryption_Diversifier

Subevent_Code为0x05;
Connection_Handle,连接句柄;
Random_Number和Encrypted_Diversifier就是LL_ENC_REQ PDU中的Rand和EDIV,最初是由Host A通过LE Start Encryption命令发送过来的。

3.4 如果Host B能提供LTK,则通过LE Long Term Key Request Reply HCI命令,将LTK提供给LL B,该命令的格式为:

Command

OCF

Command parameters

Return Parameters

HCI_LE_Long_Term_Key_
Request_Reply

0x001A

Connection_Handle
Long_Term_Key

status
Connection_Handle

3.5 LL B收到LTK之后,会向LL A回应一个LL_ENC_ RSP PDU,该PDU的格式为:

SKDs (8 octets)

IVs (4 octets)

SKDs和LL A的SDKm共同组成128bits的SKD;
IVs和LL A的IVm共同组成64bits的IV。

3.6 LL A收到LL_ENC_ RSP PDU之后,可以向LL B发送LL_START_ENC_REQ PDU,开启Encryption,LL B则回应LL_START_ENC_RSP PDU,这两个PDU均不携带任何的参数。

加密start之后,双方就可以安全的通信了。当然,LE encryption还提供了其它诸如暂停加密(LL_PAUSE_ENC_REQ/LL_PAUSE_ENC_RSP)、重启加密等过程,比较简单,这里就不详细介绍了,具体可参考BLE Spec[2]中的相关描述。

猜你喜欢

转载自www.cnblogs.com/yuqilihualuo/p/9568211.html