设为首页收藏本站

技术子

 找回密码
 速度加入

QQ登录

只需一步,快速开始

扫一扫,访问微社区

搜索
热搜: 活动 交友 discuz
查看: 4162|回复: 9

ble4.0协议之 3.6节 安全管理( Security Manager (SM)) 2

[复制链接]

61

主题

106

帖子

1万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
13843
发表于 2016-6-21 22:55:52 | 显示全部楼层 |阅读模式

    接上节 ble4.0协议之 3.6节 安全管理( Security Manager (SM))
    本贴内容:
QQ截图20160621225001.png


欢迎关注 一个 专为 低功耗蓝牙写笔记的论坛 bbs.codertown.cn

欢迎加入蓝牙BLE4.0协议研究 177341833 一起学习和讨论​​​

欢迎关注微信公众号 专门讲解 低功耗蓝牙4.0 协议​



3.6.3.1、配对特征交换得到临时密钥(TK)值
    这个过程上面已经提到决定了临时密钥(TK)的生成。那么到底是
怎么决定的呢?这里提到配对特征交换,为什么交换?交换了什么?
交换的输入输出(IO)功能, 这里拿 ATM 机取钱打个比方,插卡后你知
道要输入取款密码, 那么为什么可以输入密码,因为取款机有显示屏
和输入密码的键盘。这里对于临时密钥(TK)也是一个密码,这个密码
是不是也需要输入,但是如果有的蓝牙设备只有显示屏没有键盘或者
只有键盘没有显示屏,甚至什么都没有,怎么办呢?所以需要两个设
备进行基本输入输出(IO)功能的交换,以达到一个双方都能接收的方
式实现 TK 共享,实际上反过来讲 TK 的共享又并不是完全由 IO 决定
的,以信用卡刷卡为例,有的人不想对信用卡设置密码,这个也不犯
法吧! POS 机上有输入键盘和显示屏,但是使用没有设置密码的信用
卡,照样是可以的。 也就是根据保护程度,协议中将安全分为 3 种特

性:
  Authenticated MITM protection:可靠中间人保护
  Unauthenticated no MITM protection:不可靠无中间人保护
  No security requirements:无安全需求
    MITM 为 man-in-the-middle 即中间人的意思,而这里的“人”应
该是第三方蓝牙设备。可靠中间人保护就是在 TK 共享是不会有第三
方设备知道共享的 TK 密钥;不可靠无中间人保护就是说 TK 共享时第
三方蓝牙设备很容易知道共享的 TK 值,所以是不可靠的传输;而无
保护就是光屁股在外面跑,也不怕被别人盗取数据。
    然而事实上配对特征交换不只是简单的交换 IO 能力,同时 TK 也
不单单由 IO 决定,在安全管理协议中的配对特征交换主要完成:交
换 IO 能力、OOB(Out  Of  Band:带外)认证数据可用性、认证需求、秘
钥大小以及图 3-66 中第 3 阶段将要分配的特定密钥。IO 能力、OOB
认证数据可用性以及认证需求用来决定图 3-66 中第 2 阶段计算 STK
生成的方法,其实就是决定 TK 的生成方法。
  认证需求是指需不需绑定和需不需要防止 MITM。
  密钥大小:在协议规范中有规定密钥的大小为[7Bytes,16Bytes],
    也就是[56bits,128bits],但是注意在 BLE 中所有密钥都是 128bits
    长度的密钥,所以如果长度不够,那么就将高位补 0,从而达到
    128bits。
3.6.3.1.1、Input 和 Output 能力
    输入和输出的组合决定采用什么方式生成 TK。输入能力见表 3-17;
输出能力见表 3-18 所示。


QQ截图20160621223948.png
    特征交换时, 将自己的综合能力发送给对方设备,对方设备也会
把自己的 IO 综合能力发送过来,最后根据两个设备的能力最终选择
那种方式实现 TK 值的共享,也就是说 TK 值虽然需要共享,但是这个
密码不是两个设备通过无线进行通信得到的,而是通过人为输入或者
默认的方式实现的。 那么两个设备 IO 能力综合会有哪些产生 TK 的方
式呢?见表 3-20。

QQ截图20160621224114.png
    从表 3-20 可以知道, IO 能力的交换决定的 TK 值的方式只有两种,
而协议规范中其实是有三种方式决定 TK 值的:
  Just Work:只工作----这时 TK 双方默认为 6 个 0,就是默认使用 0
  Passkey Entry:输入密码----这时 TK 为输入的 6 位数 000000-999999
  Out Of Band(OOB):带外----这个不懂,是通过另一种无线接入两个
设备的网络,同时将 TK 进行传送。

3.6.3.1.2、Just Work:只工作
    仅工作方式两设备使用的是默认的 TK 值,即 6 个 0。对于这种方式
是一个不可靠的加密链路,它不能防止 MITM 攻击。这种方式使
用时可靠的前提是,确保在配对绑定是能保证没有 MITM 攻击,那么
在之后的连接中加密的数据是无法被其它设备窃听的,也就是说这种
方式保护的是将来的加密链路安全,但是不能保护配对绑定过程。
3.6.3.1.3、Passkey Entry:输入密码
    上面有提到 TK 的共享并不会是通过无线传输的,而是通过人为
方式使两个设备使用的临时密钥一样。对于输入密钥来说,实现的方
式 是 : 两 个 设 备 中 , 一 个 蓝 牙 设 备 在 自 己 的 显 示 屏 上 显 示
[000000,999999]之间的随机 6 位数;而操作人员看到这 6 位数后,将
这 6 位数在另一个蓝牙设备中输入,从而实现两个设备的 TK 值一样。
这个过程能防止 MITM 攻击,但是它的保护还是受限制的,因为
毕竟这种方式中的 TK 值只有 6 位随机数,还是有概率被攻击者成功
攻击。 但是如果在配对绑定过程没有被攻击,那么在未来的加密链路
中一定是安全可靠的。
这里的输入值是 6 位数,假设输入的是“019655”,那么实际使
用的 TK 值为 0x00000000000000000000000000004CC7。 也就是用 0 补
满到 128bits。

3.6.3.1.4、Out of Band:带外
    带外是使用另一无线方式将数据传给蓝牙设备,如果带外本身能
防止 MITM 的攻击,那么传送的 TK 值肯定是受保护的。而且这种方

式下的 TK 值是 128bits 的随机数,被虽然还是有概率被第三方猜中,
但是猜中 128bits 随机数的概率远比输入密码时的 6bits 的随机数要小。
这个虽然更加安全,但是对蓝牙设备也有一定的要求:这两个设
备需要有能匹配的 OOB 接口。所以在特征交换时,还会传输一个信
息告诉对方设备自己具不具备带外认证数据的能力即 OOB(Out  Of
Band:带外)认证数据可用性。

3.6.3.2、身份确认以及短期秘钥(STK)生产
    配对的第 1 阶段通过特征交换仅仅得到 TK 值,而 TK 值是用来做
什么的呢?在第 2 阶段用来作为密钥进行计算两个重要的值:
  身份确认值
  短期秘钥(STK)值
3.6.3.2.1、身份确认值计算
    得到了 TK 值,但是为了保证和自己通信的设备是自己需要连接
的设备,必须通过某些计算从而确定对方的身份。 两个设备都需要计
算确认值,从而确定对方是所需要的连接的设备。所以分为主机确认
值 / 发起者确认值 (Mconfirm) 计算和从机确认值 / 响应者确认值
(Sconfirm)计算。确认值计算使用到的函数为 c1 函数见式(3-3)。式中
所有的参数有的由自己设备提供,有的是由对方设备提供。具体为:
    Mconfirm = c1(TK,  :短期秘钥
                             Mrand,:发起者发送给响应者的随机数

                            Pairing Request command,  :配对请求命令
                            Pairing Response command,  :配对应答命令
                            initiating device address type,  :发起者设备地址类型
                            initiating device address,  :发起者设备地址
                            responding device address type,  :应答者设备地址类型
                            responding devices address):应答者设备地址
            从机的确认值/响应者的确认值的计算:
Sconfirm  =  c1(TK,  Srand,  Pairing  Request  command,  Pairing  Response
command,  initiating  device  address  type,  initiating  devices  address,
responding device address type, responding device address)和主机的确
认值是一样的,只是将随机数变为了 Srand。

3.6.3.2.2、短期秘钥(STK)值计算
    得到 TK 后的另一个作用是计算短期秘钥,短期秘钥的使用的函
数为 s1 函数见式(3-4)。具体的 STK 计算如下:
                STK = s1(TK, Srand, Mrand)
      其中 Srand 和 Mrand 和计算确认值时使用的值一样。
      短期密钥 STK 计算了干什么呢?为什么叫做“短期秘钥”呢?STK
存在的目的在于配对绑定过程的第 3 阶段不再使用明文进行数据传
输,而是使用 STK 作为长期秘钥 LTK 将需要交互的数据进行加密,第
3 阶段传输是在未来加密链路中使用到的 LTK、IRK 以及 CSRK 等等密
钥,所以必须进行加密处理,也就是说在绑定配对过程中,第 3 阶段

就已经使用加密的密文传输。
    然而 STK 或者 LTK 并不能直接作为将要发送的数据包进行加密的
密钥,为了传输的数据包更加的安全,加密数据包的密钥是会话密钥
Session Key(SK),也就是说会话密钥 SK 是用 STK 或者 LTK 当做密钥通
过加密引擎函数 e 计算得到的,计算公式如下:
                 SK=e(LTK,(SKDslave||SKDmaste))
       参数 LTK 即为长期密钥,上文提到 STK 可以代替 LTK 作为密钥计
算 SK,但是什么情况下可以使用 STK 代替 LTK 呢?当两个设备第一
次进行配对绑定时,在第 3 阶段就需要进行加密链路传输数据,而此
时长期密钥 LTK 是没有共享的,所以需要通过第 2 阶段计算得到的
STK 作为长期密钥 LTK 来计算会话密钥 SK。也就是说只要加密链路传
输数据包那么必须使用会话秘钥 SK 进行链路加密。那么具体判断使
用 STK 和 LTK 作为密钥见 3.6.5 章节。
3.6.3.3、特定密钥计算
    在配对绑定的第 3 个阶段传输就是两个设备商量好了的特定的
密钥,然而是不是有个问题,这些密钥到底是从哪儿来的呢?所有密
钥都是通过计算得到。
3.6.3.3.1、长期密钥 LTK 计算
    长期密钥 LTK 使用的函数是 d1 函数见式(3-6)。计算如下:
                     LTK=d1(ER,DIV,0)=e(ER,0||DIV)

      然而这里最难搞定的还是 ER 和 DIV 这两个参数。ER(Encryption
Root)在 nrf51822 中其实是一个 128bits 的伪随机数,并掩膜在 Flash
。协议原文:

    ER is used to generate LTK and CSRK. ER can be assigned, randomly gene rated by the
device during manufacturing or some other method could be used, that results in ER
having 128 bits of entropy

    这参数就这一句话,但是我在协议中却找了好长时间啊!DIV 它
是“Diversifying”这个单词的前 3 个字母吧!意思为“分散器”。目
的是将一些数据分散然后通过计算将数据还原。DIV 的计算如下:
               DIV=EDIV XOR Y  或 EDIV=DIV XOR Y
    EDIV 即为加密分散器,这个值是在配对绑定过程中是由从机发送
给主机, 而配对绑定完之后的连接是由主机发送给从机,从而计算出
长期密钥 LTK。 一方面在未来的连接过程 LTK 不通过明文发送保证 LTK
的安全性;另一方面从机不存储配对过程中交换的某些密钥信息,可
以减少对从机硬件要求。 计算式中是个鸡生蛋蛋生鸡的过程, 到底从
机是怎么产生 EDIV 的,目前我也不清楚,现在我怀疑是伪随机数,
但是到底是不是伪随机没有从协议规范中找到根据。
    Y 也是通过计算得到的, 使用的是 dm 函数见式(3-5)。 计算如下:
                      Y=dm(DHK,Rand)=e(DHK,Rand’) mod 2^16
     后面 mod 2^16的目的是保留结果的低 16 字节。 Rand 和 EDIV 是同
一个命令传输的,所以它的传输和 EDIV 传输的有相同的特征。
       DHK 由 d1 函数计算得到,计算如下:
                       DHK=d1(IR,3,0)=e(IR,0||3)
        IR(Identity  Root)和 ER 一样,也是一个固定的值,在 nrf51822 中

也被固定在 flash 中,协议原文:
IR can be used to generate IRK and other requ ired keys. IR can be assigned, randomly
generated by the device during manufacturing or some other method could be used,
that results in IR having 128 bits of entropy.



欢迎关注 一个 专为 低功耗蓝牙写笔记的论坛 bbs.codertown.cn

欢迎加入蓝牙BLE4.0协议研究 177341833 一起学习和讨论​​​

欢迎关注微信公众号 专门讲解 低功耗蓝牙4.0 协议​

133328x5azda7ocyyaxjfj.jpg



本帖被以下淘专辑推荐:

回复

使用道具 举报

0

主题

6

帖子

246

积分

中级会员

Rank: 3Rank: 3

积分
246
发表于 2016-6-22 13:48:16 | 显示全部楼层
牛!!!!!
回复

使用道具 举报

0

主题

13

帖子

74

积分

注册会员

Rank: 2

积分
74
发表于 2016-6-30 20:21:33 | 显示全部楼层
请教一个问题,Just Work 和Passkey 方式,如果在配对时没受到攻击,是不是意味着这两者之后的数据交换安全性是一样的,就没有什么区别了吗
回复 支持 反对

使用道具 举报

61

主题

106

帖子

1万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
13843
 楼主| 发表于 2016-6-30 22:06:32 | 显示全部楼层
是的
回复

使用道具 举报

1

主题

10

帖子

237

积分

中级会员

Rank: 3Rank: 3

积分
237
发表于 2016-7-2 00:36:44 | 显示全部楼层
LTK                                        LTK = dl(ER, DIV, 0)

其中涉及到的参数有下面几个:
        ER, DIV, EDIV, Y, DHK, Rand, IR,这几个绕晕我了.

太复杂了!
回复 支持 反对

使用道具 举报

1

主题

10

帖子

237

积分

中级会员

Rank: 3Rank: 3

积分
237
发表于 2016-7-2 00:40:14 | 显示全部楼层
因为蓝牙的微微网络是一主的,
所以ER, EDIV, IR 这3个固定值都是由从机提供。保证每个从机值得不一样,
在这里面有主机提供的值吗?如果没有主机提供的基值。
那么我是不是认为一个从机绑定另外一个主机的LTK有可能会相同,这样不利于设备的模块化?
回复 支持 反对

使用道具 举报

0

主题

1

帖子

22

积分

新手上路

Rank: 1

积分
22
发表于 2016-7-3 16:47:11 | 显示全部楼层
NFC 是OOB配对的一种
回复 支持 反对

使用道具 举报

0

主题

13

帖子

74

积分

注册会员

Rank: 2

积分
74
发表于 2016-7-4 20:11:50 | 显示全部楼层
楼主,请教个问题,使用C1函数计算确认值时, 主机和从机使用的随机数不一致,他们计算的结果应该不一样,怎么确认,请指教 感激不尽
回复 支持 反对

使用道具 举报

61

主题

106

帖子

1万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
13843
 楼主| 发表于 2016-7-4 22:21:27 | 显示全部楼层
如影随行 发表于 2016-7-4 20:11
楼主,请教个问题,使用C1函数计算确认值时, 主机和从机使用的随机数不一致,他们计算的结果应该不一样, ...

你  看   ble4.0协议之 3.6节 安全管理( Security Manager (SM)) 5
http://bbs.codertown.cn/forum.ph ... d=107&fromuid=3
(出处: 技术子)
这节  就明白了
回复 支持 反对

使用道具 举报

0

主题

25

帖子

66

积分

注册会员

Rank: 2

积分
66
发表于 2016-7-5 14:16:42 | 显示全部楼层
学习了,谢谢楼主
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 速度加入

本版积分规则

Archiver|手机版|小黑屋|技术子 ( 粤ICP备14028582号  

GMT+8, 2020-11-28 13:14 , Processed in 0.116777 second(s), 34 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表