蓝牙协议分析(11)_BLE安全机制之SM
作者:wowo 发布于:2017-9-7 19:49 分类:蓝牙
1. 前言
注1:此SM是Security Manager的缩写,非彼SM,大家不要理解歪了!
书接上文,我们在“蓝牙协议分析(10)_BLE安全机制之LE Encryption”中介绍了BLE安全机制中的终极武器----数据加密。不过使用这把武器有个前提,那就是双方要共同拥有一个加密key(LTK,Long Term Key)。这个key至关重要,怎么生成、怎么由通信的双方共享,关系到加密的成败。因此蓝牙协议定义了一系列的复杂机制,用于处理和加密key有关的操作,这就是SM(Security Manager)。
另外,在加密链路建立之后,通信的双方可以在该链路上共享其它的key(例如在“蓝牙协议分析(9)_BLE安全机制之LL Privacy”中提到的IRK),SM也顺便定义了相应的规范。
2. Security Manager介绍
SM在蓝牙协议中的位置如下图:
图片1 SM_in_BLE_protocol
它的主要目的是为LE设备(LE only或者BR/EDR/LE)提供建立加密连接所需的key(STK or LTK)。为了达到这个目的,它定义了如下几类规范:
1)将生成加密key的过程称为Pairing(配对),并详细定义了Pairing的概念、操作步骤、实现细节等。
2)定义一个密码工具箱(Cryptographic Toolbox),其中包含了配对、加密等过程中所需的各种加密算法。
3)定义一个协议(Security Manager Protocol,简称SMP),基于L2CAP连接,实现master和slave之间的配对、密码传输等操作。
3. Pairing(配对)
在SM的规范中,配对是指“Master和Slave通过协商确立用于加(解)密的key的过程”,主要由三个阶段组成:
图片2 LE Pairing Phases
阶段1,称作“Pairing Feature Exchange”,用于交换双方有关鉴权的需求(authentication requirements),以及双方具有怎么的人机交互能力(IO capabilities)。
阶段2,通过SMP协议进行实际的配对操作,根据阶段1 “Feature Exchange”的结果,有两种配对方法可选:LE legacy pairing和LE Secure Connections。
阶段3是可选的,经过阶段1和阶段2之后,双方已经产生了加密key,因而可以建立加密的连接。加密连接建立后,可以互相传送一些私密的信息,例如Encryption Information、Identity Information、Identity Address Information等。
3.1 Pairing Feature Exchange
配对的过程总是以Pairing Request和Pairing Response的协议交互开始,通过这两个命令,配对的发起者(Initiator,总是Master)和配对的回应者(Responder,总是Slave)可以交换足够的信息,以决定在阶段2使用哪种配对方法、哪种鉴权方式、等等,具体包括:
3.1.1 配对方法
Master和Slave有两种可选的配对方法:LE legacy pairing和LE Secure Connections(具体可参考后面3.2和3.3章节的介绍)。从命名上看,前者是过去的方法,后者是新方法。选择的依据是:
当Master和Slave都支持LE Secure Connections(新方法)的时候,则使用LE Secure Connections。否则,使用LE legacy pairing。
3.1.2 鉴权方式
所谓的鉴权(Authentication),就是要保证执行某一操作的双方(或者多方,这里就是配对的双方)的身份的合法性,不能出现“上错花轿嫁对郎”的情况。那怎么保证呢?从本质上来说就是通过一些额外的信息,告诉对方:现在正在和你配对的是“我”,是那个你正要配对的“我”!说起来挺饶舌,没关系,看看下面的实现方法就清楚了。
对BLE来说,主要有三类鉴权的方法(其实是两种),如下:
1)由配对的双方,在配对过程之外,额外的交互一些信息,并以这些信息为输入,进行后续的配对操作。这些额外信息也称作OOB(out of band),OOB的交互过程称为OOB protocol(是一个稍微繁琐的过程,这里不在详细介绍了)。
2)让“人(human)”参与进来,例如:
手机A向手机B发起配对操作的时候,手机A在界面上显示一串6位数字的配对码,并将该配对码发送给手机B,手机B在界面上显示同样的配对码,并要求用户确认A和B显示的配对码是否相同,如果相同,在B设备上点击配对即可配对成功(如下如所示)。
图片3 配对码
这种需要人参与的鉴权方式,在蓝牙协议里面称作MITM(man-in-the-middle)authentication,不过由于BLE设备的形态千差万别,硬件配置也各不相同,有些可以输入可以显示、有些只可输入不可显示、有些只可显示不可输入、有些即可输入也可显示,因此无法使用统一的方式进行MITM鉴权(例如没有显示的设备无法使用上面例子的方式进行鉴权)。为此Security Manager定义了多种交互方法:
2a)Passkey Entry,通过输入配对码的方式鉴权,有两种操作方法
用户在两个设备上输入相同的6个数字(要求两个设备都有数字输入的能力),接下来的配对过程会进行相应的校验;
一个设备(A)随机生成并显示6个数字(要求该设备有显示能力),用户记下这个数字,并在另一个设备(B)上输入。设备B在输入的同时,会通过SMP协议将输入的数字同步的传输给设备A,设备A会校验数字是否正确,以达到鉴权的目的。
2b)Numeric Comparison,两个设备自行协商生成6个数字,并显示出来(要求两个设备具有显示能力),用户比较后进行确认(一致,或者不一致,要求设备有简单的yes or no的确认能力)。
2c)Just Work,不需要用户参与,两个设备自行协商。
3)不需要鉴权,和2c中的Just work的性质一样。
3.1.3 IO Capabilities
由3.1.2的介绍可知,Security Manager抽象出来了三种MITM类型的鉴权方法,这三种方法是根据两个设备的IO能力,在“Pairing Feature Exchange”阶段自动选择的。IO的能力可以归纳为如下的六种:
NoInputNoOutput
DisplayOnly
NoInputNoOutput1
DisplayYesNo
KeyboardOnly
KeyboardDisplay
具体可参考BT SPEC[3] “BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H]” “2.3.2 IO Capabilities”中的介绍。
3.1.4 鉴权方法的选择
在“Pairing Feature Exchange”阶段,配对的双方以下面的原则选择鉴权方法:
1)如果双方都支持OOB鉴权,则选择该方式(优先级最高)。
2)否则,如果双方都支持MITM鉴权,则根据双方的IO Capabilities(并结合具体的配对方法),选择合适的鉴权方式(具体可参考BT SPEC[3] “BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H]”“2.3.5.1 Selecting Key Generation Method”中的介绍)。
3)否则,使用Just work的方式(不再鉴权)。
3.2 LE legacy pairing
LE legacy pairing的过程比较简单,总结如下(可以参考下面的流程以辅助理解):
图片4 LE legacy pairing过程
1)LE legacy pairing最终生成的是Short Term Key(双方共享),生成STK之后,参考[1]中的介绍,用STK充当LTK,并将EDIV和Rand设置为0,去建立加密连接。
2)加密连接建立之后,双方可以自行生成Long Term Key(以及相应的EDIV和Rand),并通过后续的“Transport Specific Key Distribution”将它们共享给对方,以便后面重新建立加密连接所使用:
master和slave都要生成各自的LTK/EDIV/Rand组合,并共享给对方。因为加密链路的发起者需要知道对方的LTK/EDIV/Rand组合,而Master或者Slave都有可能重新发起连接。
另外我们可以思考一个问题(在[1]中就应该有这个疑问):为什么LE legacy pairing的LTK需要EDIV/Rand信息呢?因为LTK是各自生成的,不一样,因而需要一个索引去查找某一个LTK(对比后面介绍的LE Secure Connections,LTK是直接在配对是生成的,因而就不需要这两个东西)。
3)STK的生成也比较简单,双方各提供一个随机数(MRand和SRand),并以TK为密码,执行S1加密算法即可。
4)TK是实在鉴权的过程中得到的,根据在阶段一选择的鉴权方法,TK可以是通过OOB得到,也可以是通过Passkey Entry得到,也可以是0(Just Work)。
LE legacy pairing只能使用OOB、Passkey Entry或者Just Work三种鉴权方法(Numeric Comparison只有在LE Secure Connections时才会使用)。
3.3 LE Secure Connections Pairing
LE Secure Connections pairing利用了椭圆曲线加密算法(P-256 elliptic curve),简单说明如下(具体细节可参考看蓝牙SPEC[3],就不在这里罗列了):
1)可以使用OOB、Passkey Entry、Just Work以及Numeric Comparison四种鉴权方法。其中Numeric Comparison的流程和Just Work基本一样。
2)可以直接生成LTK(双方共享),然后直接使用LTK进行后续的链路加密,以及重新连接时的加密。
3.4 Transport Specific Key Distribution
加密链路建立之后,通信的双方就可以传输一些比较私密的信息,主要包括:
Encryption Information (Long Term Key)
Master Identification (EDIV, Rand)
Identity Information (Identity Resolving Key)
Identity Address Information (AddrType, BD_ADDR)
Signing Information (Signature Key)
至于这些私密信息要怎么使用,就不在本文的讨论范围了,后续碰到的时候再介绍。
4. Security Manager Protocol介绍
SMP使用固定的L2CAP channel(CID为0x0006)传输Security相关的命令。它主要从如下的方面定义SM的行为(比较简单,不再详细介绍):
1)规定L2CAP channel的特性,MTU、QoS等。
2)规定SM命令格式。
3)定义配对相关的命令,包括:
Pairing Request
Pairing Response
Pairing Confirm
Pairing Random
Pairing Failed
Pairing Public Key
Pairing DHKey Check
Keypress Notification
4)定义鉴权、配对、密码交互等各个过程。
5. 密码工具箱介绍
为了执行鉴权、配对等过程,SM定义了一组密码工具箱,提供了十八般加密算法,由于太专业,就不在这里介绍了,感兴趣的读者直接去看spec就行了(“BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H] 2.2 CRYPTOGRAPHIC TOOLBOX”)。
6. Security Manager的使用
相信经过本文的介绍,大家对BLE的SM有了一定的了解,不过应该会有一个疑问:
这么复杂的过程,从应用角度该怎么使用呢?
放心,蓝牙协议不会给我们提供这么简陋的接口的,参考上面图片1,SM之上不是还有GAP吗?对了,真正使用SM功能之前,需要再经过GAP进行一次封装,具体可参考本站后续的文章。
7. 参考文档
[1] 蓝牙协议分析(10)_BLE安全机制之LE Encryption
[2] 蓝牙协议分析(9)_BLE安全机制之LL Privacy
[3] Core_v4.2.pdf
原创文章,转发请注明出处。蜗窝科技,www.wowotech.net。
标签: 蓝牙 Bluetooth BLE SMP 配对 pairing 鉴权 authentication security
评论:
2018-04-04 15:27
重新配对了,肯定会更新LTK;
角色转换了,如果要重新配对,也会更新LTK;
至于IRK,是用于地址解析的,需要在重新配对前,广播的地址需要解析,就需要提前把IRK告诉对方;
把这几个信息揉在一起,好好想想,就是你所要的答案了~
2017-11-28 16:10
2017-09-07 23:30
我在用BLE4.0的时候,好像作为Slave时候并不能主动发起START ENCRYPTION啊,Slave调用加密函数时候,用抓包软件发现Slave发出的是一个Security request,然后之前已经与之绑定过的Master收到这个Security request之后,主动发起START ENCRYPTION开始加密,所以我还是不太明白这个角色反转发起连接是怎么一回事,就是Slave如何发起START ENCRYPTION,求wowo指导指导。
2017-09-08 09:12
2017-09-08 23:45
2018-03-29 10:48
The master may also provide keys to the slave device so a reconnection can be encrypted if the roles are reversed, the master’s random addresses can be resolved, or the slave can verify signed data from the master.
1、其中the roles are reversed是不是只针对LTK,没有反转前用的是从机的LTK,反转后用的主机的LTK(此时其实已是从机角色)?
2、其中the roles are reversed是不是只针对LTK,对CSRK,IRK都没有意义,这两个密钥只关注是谁生成的和是谁接收的跟角色没有关系,发送时对自己的数据或地址用自己生成的密钥,接收时验证或解析用分发者给的密钥,请问是不是这样的?
3、但对于LTK如你上文所说,具体的一次加密和解密双方都用到相同LTK,而对于CSRK,IRK,如果一方没有发给对方,那么验证和解析都是单向的?
谢谢啦:)
2018-04-04 12:55
When using LE legacy pairing, the keys shall be distributed in the following
order:
1. LTK by the slave
2. EDIV and Rand by the slave
3. IRK by the slave
4. BD ADDR by the slave
5. CSRK by the slave
6. LTK by the master
7. EDIV and Rand by the master
8. IRK by the master
9. BD_ADDR by the master
10. CSRK by the master
功能
最新评论
- ylsislove
感谢大佬的文章 - xing
@王:牛逼 - 白璐
@linuxer:学长 还要人吗 - muto
终于看到更新了,赞 +1 - piter
在linux 4.14 的版本中 struct clk... - lingkep
考古到了大佬的文章 看的好爽 另外有个疑问想请教下,在__i...
文章分类
随机文章
文章存档
- 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)
2024-12-05 15:39