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。

蓝牙协议分析(11)_BLE安全机制之SM的更多相关文章

  1. 蓝牙协议分析(10)_BLE安全机制之LE Encryption

    1. 前言 前面文章介绍了两种BLE的安全机制:白名单[4]和LL privacy[3].说实话,在这危机四伏的年代,这两种“捂着脸讲话(其它人不知道是谁在讲话,因而不能插话.不能假传圣旨,但讲话的内 ...

  2. 蓝牙协议分析(9)_BLE安全机制之LL Privacy

    1. 前言 在上一篇文章[1]中,我们介绍了BLE的白名单机制,这是一种通过地址进行简单的访问控制的安全机制.同时我们也提到了,这种安全机制只防君子,不防小人,试想这样一种场景: A设备表示只信任B. ...

  3. 蓝牙协议分析(8)_BLE安全机制之白名单

    1. 前言 在万物联网的时代,安全问题将会受到非常严峻的挑战(相应地,也会获得最大的关注度),因为我们身边的每一个IOT设备,都是一个处于封印状态的天眼,随时都有被开启的危险.想想下面的场景吧: 凌晨 ...

  4. 蓝牙协议分析(7)_BLE连接有关的技术分析

    转自:http://www.wowotech.net/bluetooth/ble_connection.html#comments 1. 前言 了解蓝牙的人都知道,在经典蓝牙中,保持连接(Connec ...

  5. 蓝牙协议分析(3)_BLE协议栈介绍

    1. 前言 通过“蓝牙协议分析(2)_协议架构”的介绍,大家对蓝牙协议栈应该有了简单的了解,但是,肯定还有“似懂非懂.欲说还休”的感觉.有这种感觉太正常了,毕竟蓝牙协议是一个历史悠久又比较庞大的协议, ...

  6. 蓝牙协议分析(5)_BLE广播通信相关的技术分析

    1. 前言 大家都知道,相比传统蓝牙,蓝牙低功耗(BLE)最大的突破就是加大了对广播通信(Advertising)的支持和利用.关于广播通信,通过“玩转BLE(1)_Eddystone beacon” ...

  7. 蓝牙协议分析(6)_BLE地址类型

    1. 前言 也许关注BLE的同学都注意到了,BLE设备有多种类型的设备地址,如Public Device Address.Random Device Address.Static Device Add ...

  8. 蓝牙协议分析(4)_IPv6 Over BLE介绍

    1. 前言 蓝牙是个奇葩的家伙:它总是以后来者的身份出现,很喜欢打仗,而且还不落下风(有点像某讯的风格).90年代末期和Wi-Fi的无线标准之争如此,当前和802.15.4系(ZigBee.RF4CE ...

  9. 蓝牙协议分析(12)_LQ和RSSI的原理及应用场景

    在蓝牙协议栈的物理层,有这样两个比较有用的参数:LQI和RSSI.它们都是通过接收端,判断当前无线环境的质量(链路质量),以指导后续的动作.但这两个数值的计算原理和使用场景又有很大的差别. LQI ( ...

随机推荐

  1. 记录:工作中用到的Js日期时间方法

    /** * 获取当前时间 */ function getDate() { return new Date(); } /** * 格式化当前时间 * @param {*} value */ functi ...

  2. zabbix自动发现自动注册

    一.自动发现 1. 2自动注册详细配置 二.自动注册 1. . 2.自动注册详细配置 三 自动安装zabbix客户端脚本 #!/bin/bash #robin path='/etc/zabbix/za ...

  3. Html select、option、optgroup 标签

    Html select 标签 </body> </html> <!-- select外部下拉选择框.name="xxx"标识后端获取名称 --> ...

  4. Docker Compose 常用命令

    Compose常用选项 # docker-compose主命令后面跟其他命令 docker-compose Usage: docker-compose [-f <arg>...] [opt ...

  5. MySql 中的<=>操作符

    今天在学习数据库的索引优化时,关于memory存储引擎的的hash索引时,看到了操作符<=> ,这个操作符还是第一次见到,于是上网查了一下.我想大家应该知道 =  !=   <> ...

  6. Bugku-CTF之变量1

    Day9 变量1 http://123.206.87.240:8004/index1.php      

  7. maven 执行testng.xml文件失败解决问题

    在pom.xml中配置了testng的依赖后,在surefire-plugin中又配置了suitexmlfiles指向testng.xml文件,但是使用mvn test运行时,没有运行testng.x ...

  8. 用bytomswap进行“跨链”资产转换

    bytom是专注资产领域的公有区块链平台,最近开发者社区基于比原做了一款资产转换平台.我们可以在上面通过自己现有的资产在比原上发行资产.然后达到资产转换的目的. 一. 以太币资产转换成比原上的资产 首 ...

  9. 【Entity Framework】Model First Approach

    EF中的model first 所谓mf, 就是使用vs提供的edm designer去设计model,然后将设计好的model使用vs在指定的数据库中生成数据库即可. 当你的项目既没有数据库也没有c ...

  10. CSS基础学习(一) 之 line-height 与 height 属性区别

    官方定义: height:定义了了元素的高度.默认情况下,该属性订了 content area(内容区域) 的高度.如果box-sizing属性设置为 border-box,那么height就表示bo ...