蓝牙协议分析(10)_BLE安全机制之LE Encryption
作者:wowo 发布于:2017-3-28 11:52 分类:蓝牙
1. 前言
前面文章介绍了两种BLE的安全机制:白名单[4]和LL privacy[3]。说实话,在这危机四伏的年代,这两种“捂着脸讲话(其它人不知道是谁在讲话,因而不能插话、不能假传圣旨,但讲话的内容却听得一清二楚)”的方法,实在是小儿科。对于物联网的应用场景来说,要做到安全,就必须对传输的数据进行加密,这就是LE Encryption要完成的事情(当然,只针对面向连接的数据),具体请参考本文的介绍。
2. 基本概念
从字面理解,Encryption是一个名词,意思是“加密术”,因此LE Encryption就是“BLE所使用的加密技术”的意思。了解加密概念的同学应该都知道,通信过程中的加密无非就是如下简单的流程:
数据发送方在需要发送数据的时候,按照一定的加密算法,将数据加密;
数据接收方在接收到数据的时候,按照等同的解密算法,将数据解密。
因此,对LE Encryption来说,需要考虑的事情无非就两条:
1)加密/解密的事情,需要在协议的哪个层次去做?
2)使用什么样的加密/解密算法?
对问题1来说,很好回答:无论是从安全的角度,还是从通信效率的角度,都应该由链路层(LL,Link Layer[1])在发送/接收数据的时候,完成加密/解密动作(具体可参考)。而问题2呢,到底要使用什么的算法,这是蓝牙标准化组织的事情,我们在本文只需要了解最终的结论即可(具体可参考)。
3. packet的加密/解密过程
LE加密/解密的过程如下面图片1所示:
图片1 LE加密/解密过程
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解密生成明文数据包。
理解了加密/解密的过程之后,问题随之而来:
1)LTK是怎么来的?
2)SKD是个什么东西?怎么来的?
3)Encryption Engine又什么东西呢?
对于问题1,需要由SMP解答(也就是我们常说的配对过程),具体可参考后续的文章。问题3比较单纯,就是一个由Bluetooth specifiction所规定的加密算法,后面会单独写一篇文章介绍。而问题2,则涉及到LE Encryption的操作流程,具体可参考后面第4章的介绍。
4. 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”):
图片2 Start Encryption
1)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_KeyConnection_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。
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)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_DiversifierSubevent_Code为0x05;
Connection_Handle,连接句柄;
Random_Number和Encrypted_Diversifier就是LL_ENC_REQ PDU中的Rand和EDIV,最初是由Host A通过LE Start Encryption命令发送过来的。
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_Reply0x001A Connection_Handle
Long_Term_Keystatus
Connection_Handle
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。
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]中的相关描述。
5. 参考文档
[2] Core_v4.2.pdf
[3] 蓝牙协议分析(9)_BLE安全机制之LL Privacy
原创文章,转发请注明出处。蜗窝科技,www.wowotech.net。
标签: 蓝牙 Bluetooth BLE 安全 Encryption

评论:
2018-03-11 16:01
1、如果两台设备间进行了绑定,当每次重连时如果链路设置了安全模式(数据要加密),那么加密是不是要进行加密规程,比如发LL_ENC_REQ,那么发第一条LL_ENC_REQ时是没有加密的但从机设置了安全模式(数据要加密)要求第一请求都要加密,这个时候从机是不是要拒绝呢?
2、加密、认证等安全方案对LL Control PDU有用吗?
3、一台从机能绑定多少个中央主机,主机能绑定多少个从机?
2017-12-07 16:35
2017-12-07 16:37
2017-12-08 10:39
得到MIC之后,DATA PDU + MIC,然后去做后续的加密过程。
所以每一包的MIC,只和这个包有关。
2017-12-08 10:39
得到MIC之后,DATA PDU + MIC,然后去做后续的加密过程。
所以每一包的MIC,只和这个包有关。
2017-12-08 11:57
2017-12-08 14:07
https://en.wikipedia.org/wiki/File:MAC.svg
其实就是:
发送方:key+msg----MIC算法---->MIC
接收方:key+msg----MIC算法---->MIC,然后对比packet里面的MIC和计算得到的MIC。
和CRC的区别是,收发双方拥有同一个key(对称加密)。
最后,怎么做到鉴权呢?其实很简单:
MIC算法所使用的msg是加密前的msg,因此必须将其正确解密得到原始msg后,才能算出合法的MIC。
数据伪造方随便伪造一个数据,由于不知道具体的加密信息,是无法做出来一个可以让接收方正确解密的MIC的。
2017-12-11 21:57
2017-11-28 15:11
功能
最新评论
文章分类
随机文章
文章存档
- 2024年2月(1)
- 2023年5月(1)
- 2022年10月(1)
- 2022年8月(1)
- 2022年6月(1)
- 2022年5月(1)
- 2022年4月(2)
- 2022年2月(2)
- 2021年12月(1)
- 2021年11月(5)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(3)
- 2020年3月(3)
- 2020年2月(2)
- 2020年1月(3)
- 2019年12月(3)
- 2019年5月(4)
- 2019年3月(1)
- 2019年1月(3)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(2)
- 2018年8月(1)
- 2018年6月(1)
- 2018年5月(1)
- 2018年4月(7)
- 2018年2月(4)
- 2018年1月(5)
- 2017年12月(2)
- 2017年11月(2)
- 2017年10月(1)
- 2017年9月(5)
- 2017年8月(4)
- 2017年7月(4)
- 2017年6月(3)
- 2017年5月(3)
- 2017年4月(1)
- 2017年3月(8)
- 2017年2月(6)
- 2017年1月(5)
- 2016年12月(6)
- 2016年11月(11)
- 2016年10月(9)
- 2016年9月(6)
- 2016年8月(9)
- 2016年7月(5)
- 2016年6月(8)
- 2016年5月(8)
- 2016年4月(7)
- 2016年3月(5)
- 2016年2月(5)
- 2016年1月(6)
- 2015年12月(6)
- 2015年11月(9)
- 2015年10月(9)
- 2015年9月(4)
- 2015年8月(3)
- 2015年7月(7)
- 2015年6月(3)
- 2015年5月(6)
- 2015年4月(9)
- 2015年3月(9)
- 2015年2月(6)
- 2015年1月(6)
- 2014年12月(17)
- 2014年11月(8)
- 2014年10月(9)
- 2014年9月(7)
- 2014年8月(12)
- 2014年7月(6)
- 2014年6月(6)
- 2014年5月(9)
- 2014年4月(9)
- 2014年3月(7)
- 2014年2月(3)
- 2014年1月(4)
2019-03-12 11:23
最近接觸BLE
請教一下 https://blog.bluetooth.com/bluetooth-pairing-part-4
所謂的LTK 是用DHKey再算出來的是嘛? 為什麼已經算出共享金鑰DHkey了還要再算出LTK?
DHkey不能用來建立加密通道嗎?