深入NXP蓝牙SDK开发(x)--深挖BLE配对过程

  • 0、开篇:
  • 1、两种配对模式能够分发的秘钥
  • 1.1、传统配对模式双端可以分发以下秘钥给对方:
  • 1.2、安全连接配对模式双端可以分发以下秘钥给对方:
  • 1.3、LTK为什么只在传统配对时分发:
  • 2、需要分发那些秘钥:
  • 2.1、EncKey:
  • 2.2、IdKey :
  • 2.2.1、IdKey 与蓝牙Mac地址相关:
  • 2.2.1.1、公共地址(Public Device Address):
  • 2.2.1.2、静态地址(Static Device Address):
  • 2.2.1.3、不可解析私有地址(Non-resolvable Private Address):
  • 2.2.1.4、 可解析私有地址(Resolvable Private Address):
  • 2.3、Sign:
  • 2.4、LinkKey:
  • 3、密钥分发



本文内容可在SIG蓝牙联盟发布的

Core_v4.2里找到,比较分散。

0、开篇:

  前两篇系列文章已经介绍了BLE配对过程的前两个阶段,接下来要想了解密钥分发,我们首先得确定,有哪些密钥需要分发,这些密钥是如何生成的,他们分发的过程又是怎么样的。

1、两种配对模式能够分发的秘钥

1.1、传统配对模式双端可以分发以下秘钥给对方:

    · LTK、EDIV 和 Rand(三者的作用在系列文章第一篇:配对特性交换 中有很好的解析);
    · IRK ;
    · CSRK。

1.2、安全连接配对模式双端可以分发以下秘钥给对方:

    · IRK;
    · CSRK

1.3、LTK为什么只在传统配对时分发:

  在以上两种模式中,你可能疑惑为什么LTK只有传统模式才能够被分发,这是因为两种配对方式之间的区别:传统模式需要先生成STK作为短期秘钥(可以理解为,第一次配对加密的会话都需要使用STK加解密,包括它的LTK分发都是使用STK加密的链路传输,在重新连接时,双端就会抛弃掉STK,直接使用LTK加密链路;所以最终的目的是生成LTK);而安全连接配对模式是双端直接协商生成LTK,因此不需要分发LTK;具体可以看一下系列文章其二:配对秘钥生成(STK | LTK);

2、需要分发那些秘钥:

  要想知道接下来分发哪些秘钥,需要分析一下第一阶段特性交换的报文最后两个字节,使能哪些秘钥需要分发给对端:

android 蓝牙开发 丢包 蓝牙sdk开发包_蓝牙


字节5和字节6两个字段结构一模一样,下面直接展开一个字段就可以了:

android 蓝牙开发 丢包 蓝牙sdk开发包_安全_02

2.1、EncKey:

  LTK 秘钥分发使能位,此位使能在此阶段将分发LTK、EDIV 和 Rand;此位在传统配对模式才有效,若是选择了安全连接配对模式,此位无论为0或1,都会被忽略,至于原因,看上一节。

  这里我们展开来说说为什么需要LTK;我们都有一个共识,LTK是加密无线中的数据的,在没有加密无线网络中,自己的数据很容易就被第三方嗅探,篡改以及伪装,这对于系统来说是非常危险的,就相当于大数据时代,我们的信息被各种平台获取了,共享了,就在数字世界中模拟出了一个自己,上一次在哪家超市买了多少抽纸巾,多少斤青菜,当时的价格是多少等等,被各大平台如数获取,随之而来的就是广告的精准投放等恶心的手段。相对应与蓝牙领域,有了一个加密的对策,让第三方获取到的是加密后的信息,他们没有LTK自然就无法破解密文,就无法获取到自己的真实信息。在这里我讲的还不够精彩,也为大家提供一篇写的非常好的文章,了解蓝牙的安全机制:BLE安全机制从入门到放弃。

android 蓝牙开发 丢包 蓝牙sdk开发包_协议栈_03

2.2、IdKey :

  身份解析秘钥使能位,该位为1,则会分发IRK给对端设备。此位在两种配对模式都有效。
  IRK 说白了就是解析蓝牙Mac地址所用的密钥,也许你会迷惑,蓝牙地址不是出厂时就被定义好,而且是一成不变的吗;

2.2.1、IdKey 与蓝牙Mac地址相关:

其实并不,蓝牙的地址可以被自定义,也可以向IEEE申请,也可以是随机的。下面我做了一张思维导图展示蓝牙地址类型:

android 蓝牙开发 丢包 蓝牙sdk开发包_协议栈_04

2.2.1.1、公共地址(Public Device Address):

  这个是我们最常用的地址,按合法的做法这类地址是需要向IEEE申请的(需要付授权费),具有全球唯一性,有与私人自定义的Mac地址碰撞的几率。此类地址绑定设备,掉电上电以及复位,Mac地址不变。
向IEEE 申请的Mac地址,IEEE 会将此ID与你的公司绑定,所以高24bit 以及低24bit 都会与公司有关。

LSB

MSB

company-assigned (24bit)

company-id (24bit)

2.2.1.2、静态地址(Static Device Address):

  每次开机地址都会改变,一旦上电,地址有效至本次掉电或者复位。此类地址不常用。此类地址格式参照下表,具体规则是高两位必须为1,剩下的46bit 由随机数生成。

LSB

MSB

Radom part of static address (46bit)

1

1

2.2.1.3、不可解析私有地址(Non-resolvable Private Address):

  此类地址会定时更新,更新频率由GAP层设定,此类地址可以说是最迷的。跟新前的地址和更新后的地址没有任何的联系,也没有什么密钥之类的可以解析出两个地址是同一设备不同时间上的Mac地址,这样一来就算第三方第一次跟设备连接上了,但地址更新后,第三方就被断开连接了,要想重新连接,就需要再次破解了,这一定成都加强了设备的私密性,但这也迷惑了队友,队友想要再次连接上设备也是需要重新一次连接。因此在这种特性的驱使下,此类地址应用场景并不是很太清晰,,所以它的实用性不会很高,一般都不会使用。不可解析私有地址有如下规则:
  · 大端最高两位必须为0;
  ·随机部分至少有一位为1;
  ·随机部分至少有一位为0;
  ·不能够与公共地址相等。

LSB

MSB

Radom part of non-resolvable address (46bit)

0

0

2.2.1.4、 可解析私有地址(Resolvable Private Address):

  要用到此类地址,设备必须具备自身的 IRK 或者对端设备的 IRK,除此之外,还需要具备24bit 的随机数 Prand ;它的地址生成规则使用到 IRK 以及 Prand ,所以它既具备随机性,也具备可解析性,第三方没有IRK,就无法解析出Mac地址,这样就做到了既迷惑了敌人,又能让队友使用 IRK 解析出自己的身份,从而进行通信。具备以上的优点,所以此类地址还是比较常用的。可解析私有地址有如下规则:
  · 最高两位必须为 0 和 1;
  · 随机部分至少有一位为0;
  · 随机部分至少有一位为1;

LSB

MSB

hash (24bit)

Random(22bit)

1

0

0 、1 和 Random三部分共同组成Prand。

hash的生成公式:hash(24bit)= ah(IRK,Prand);ah是安全模块的api 函数,参数输入 IRK以及Prand

那么就得出 RandomAdress = hash || Prand ;此公式完完全全来自于核心规范5.0,至于 || 运算符号,我猜测是将两个合并,并且Prand作为高24bit,hash作为低24bit。解密也就是说得到IRK 和 RandomAddress即可解析出hash,即可辨认对端身份。IRK的作用也就是这么个样了。

android 蓝牙开发 丢包 蓝牙sdk开发包_nxp_05

2.3、Sign:

  CRSK 签名密钥分发使能位,CSRK与上面的所有密钥有点不一样,上面的密钥是面对连接和地址这些底层驱动类的加密密钥,而CSRK是面向于应用层以及GATT服务层的加密密钥。所以蓝牙将安全模式分为两个模式,分别是安全模式1和安全模式2。面向底层驱动的加密密钥在两种安全模式都可以被应用到。而CSRK只能实在安全模式2中使用。关于安全模式的详细介绍,在这里我就不做搬运工了,可以戳链接看这篇文章:关于低功耗蓝牙(BLE)的安全机制,解析的比较清楚。

2.4、LinkKey:

  暂未得到满意的文字描述,稍稍看了一遍核心规范,像是与经典蓝牙有关,还没看到与BLE有无关系,所以后续攻读核心规范,得到满意的答案后再给出。

3、密钥分发

  密钥的分发,首先我们在第一阶段选择需要分发的密钥,等第二阶段密钥协商完成,即可进行密钥的分发,当然密钥分发是基于第二阶段协商出来的密钥加密过后以密文的形式分发给对端。对端再对密文解密,即可得到相应的密钥。在流程图里面表现就是一个密钥交换一条报文:看绿色部分(Phase):

android 蓝牙开发 丢包 蓝牙sdk开发包_android 蓝牙开发 丢包_06


附加一个链接,也是与蓝牙安全相关。