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

作者:wowo 发布于:2016-6-7 11:40 分类:蓝牙

1. 前言

也许关注BLE的同学都注意到了,BLE设备有多种类型的设备地址,如Public Device Address、Random Device Address、Static Device Address、Private Device Address等等。如果不了解内情,大家肯定会被它们绕晕。不过存在即合理,这样看似奇怪的设计,实际上反映了BLE的设计思路以及所针对的应用场景。让我们通过本文一窥究竟。

2. BLE设备的地址类型

一个BLE设备,可以使用两种类型的地址(一个BLE设备可同时具备两种地址):Public Device Address和Random Device Address。而Random Device Address又分为Static Device Address和Private Device Address两类。其中Private Device Address又可以分为Non-resolvable Private Address和Resolvable Private Address。它们的关系如下所示:


                        Public Device 
                  +--->    Address 
+-------------+   | 
|             |   | 
|     BLE     |   | 
|    Device   +---+       or/and           Static Device 
|             |   |                    +-->   Address 
+-------------+   |                    | 
                  |     Random Device  | 
                  +---->   Address   +-+       or               Non-resolvable 
                                       |                    +-> private address 
                                       |                    | 
                                       |   Private Device   |       or 
                                       +-->    Address   +--+ 
                                                            |      Resolvable 
                                                            +-> private address 

3. Public Device Address

在通信系统中,设备地址是用来唯一识别一个物理设备的,如TCP/IP网络中的MAC地址、传统蓝牙中的蓝牙地址等。对设备地址而言,一个重要的特性,就是唯一性(或者说一定范围内的唯一),否则很有可能造成很多问题。蓝牙通信系统也不例外。

对经典蓝牙(BR/EDR)来说,其设备地址是一个48bits的数字,称作"48-bit universal LAN MAC addresses(和电脑的MAC地址一样)“。正常情况下,该地址需要向IEEE申请(其实是购买[1],呵呵!)。企业交钱,IEEE保证地址的唯一性,皆大欢喜。

当然,这种地址分配方式,在BLE中也保留下来了,就是Public Device Address。Public Device Address由24-bit的company_id和24-bit的company_assigned组成,具体可参考蓝牙Spec中相关的说明[2]

4. Random Device Address

但是,在BLE时代,只有Public Device Address还不够,有如下原因:

1)Public Device Address需要向IEEE购买。虽然不贵,但在BLE时代,相比BLE IC的成本,还是不小的一笔开销。

2)Public Device Address的申请与管理是相当繁琐、复杂的一件事情,再加上BLE设备的数量众多(和传统蓝牙设备不是一个数量级的),导致维护成本增大。

3)安全因素。BLE很大一部分的应用场景是广播通信,这意味着只要知道设备的地址,就可以获取所有的信息,这是不安全的。因此固定的设备地址,加大了信息泄漏的风险。

为了解决上述问题,BLE协议新增了一种地址:Random Device Address,即设备地址不是固定分配的,而是在设备设备启动后随机生成的。根据不同的目的,Random Device Address分为Static Device Address和Private Device Address两类。

4.1 Static Device Address

Static Device Address是设备在上电时随机生成的地址,格式如下:

LSB                                        MSB 
+------------------------------------+---+---+ 
|    Random part of static address   | 1 | 1 | 
+------------------------------------+---+---+ 
                static address 
<--------------+  (48 bits)  +---------------> 

Static Device Address的特征可总结为:

1)最高两个bit为“11”。

2)剩余的46bits是一个随机数,不能全部为0,也不能全部为1。

3)在一个上电周期内保持不变

4)下一次上电的时候可以改变。但不是强制的,因此也可以保持不变。如果改变,上次保存的连接等信息,将不再有效。

Static Device Address的使用场景可总结为:

1)46bits的随机数,可以很好地解决“设备地址唯一性”的问题,因为两个地址相同的概率很小。

2)地址随机生成,可以解决Public Device Address申请所带来的费用和维护问题。

4.2 Private Device Address

Static Device Address通过地址随机生成的方式,解决了部分问题,Private Device Address则更进一步,通过定时更新和地址加密两种方法,提高蓝牙地址的可靠性和安全性。根据地址是否加密,Private Device Address又分为两类,Non-resolvable private address和Resolvable private address。下面我们分别描述。

4.2.1 Non-resolvable private address

Non-resolvable private address和Static Device Address类似,不同之处在于,Non-resolvable private address会定时更新。更新的周期称是由GAP规定的,称作T_GAP(private_addr_int) ,建议值是15分钟。其格式如下:

LSB                                        MSB 
+----------------------------------------+---+ 
|Random part of nonresolvable address| 0 | 0 | 
+----------------------------------------+---+ 
             nonresolvable address 
<--------------+  (48 bits)  +---------------> 

特征可总结为:

1)最高两个bit为“00”。

2)剩余的46bits是一个随机数,不能全部为0,也不能全部为1。

3)以T_GAP(private_addr_int)为周期,定时更新

注1:Non-resolvable private address有点奇怪,其应用场景并不是很清晰。地址变来变去的,确实是迷惑了敌人,但自己人不也一样被迷惑了吗?因此,实际产品中,该地址类型并不常用。

4.2.2 Resolvable private address

Resolvable private address比较有用,它通过一个随机数和一个称作identity resolving key (IRK) 的密码生成,因此只能被拥有相同IRK的设备扫描到,可以防止被未知设备扫描和追踪。其格式如下:

LSB                                                     MSB 
+--------------------------+----------------------+---+---+ 
|                          | Random part of prand | 1 | 0 | 
+--------------------------+----------------------+---+---+ 

<--------+ hash +---------> <-----------+ prand +-------> 
         (24 bits)                     (24 bits) 

特征如下:

1)由两部分组成:
     高位24bits是随机数部分,其中最高两个bit为“10”,用于标识地址类型;
     低位24bits是随机数和IRK经过hash运算得到的hash值,运算的公式为hash = ah(IRK, prand)。

2)当对端BLE设备扫描到该类型的蓝牙地址后,会使用保存在本机的IRK,和该地址中的prand,进行同样的hash运算,并将运算结果和地址中的hash字段比较,相同的时候,才进行后续的操作。这个过程称作resolve(解析),这也是Non-resolvable private address/Resolvable private address命名的由来。

3)以T_GAP(private_addr_int)为周期,定时更新。哪怕在广播、扫描、已连接等过程中,也可能改变。

4)Resolvable private address不能单独使用,因此需要使用该类型的地址的话,设备要同时具备Public Device Address或者Static Device Address中的一种。

5. Resolvable private address应用场景及HCI命令介绍

BLE Resolvable private address的解析和过滤操作是在Link Layer实现的,因而为BLE的广播通信提供了一个相对安全的加密环境。Link Layer以Resolving List的形式,通过HCI向Host提供相关的控制API,以实现相应的功能,相关的HCI命令介绍如下:

LE Set Random Address Command,设置一个新的Random地址,包括Resolvable private address类型的地址。

 

LE Add Device to Resolving List Command,将指定的设备添加到本机的Resolving List中,需要指定的参数包括:需要添加设备的地址(包括地址类型)、需要添加设备的IRK、本设备的IRK。

LE Remove Device From Resolving List Command,将指定设备从本机的Resolving List中删除。

LE Clear Resolving List Command,清除本机的Resolving List。

LE Read Resolving List Size Command,读取本机Resolving List的大小。

LE Read Peer Resolvable Address Command,读取对端设备解析后的Resolvable private address。

LE Read Local Resolvable Address Command,读取本机设备解析后的Resolvable private address。

LE Set Address Resolution Enable Command,禁止/使能地址解析功能。

总结和说明:

1)Resolvable private address的生成,是Host以T_GAP(private_addr_int)为周期,主动进行的,并通过“LE Set Random Address Command”告知Controller的Link Layer。因此,如果本地设备需要安全的环境,可以使用Resolvable private address作为广播和连接地址。

2)如果本地设备需要和某一个使用Resolvable private address的设备通信(扫描、连接等),则需要将该设备添加到Resolving List中,并使能地址解析功能。只有地址解析正确的时候,Link Layer才会继续后续的通信动作。

3)如果地址解析不正确,本地设备向对方发送的所有的数据包(扫描请求、连接请求等),都不能被正确接收(因为目的地址不正确)。但有一个例外,如果本地设备直接关闭地址解析功能,还是能收到对方的广播包,因此,Resolvable private address并不能保护广播包的数据。如果有敏感信息,放到scan response packet中应该是一个不错的选择。

4)上面分析是否正确?我也不是十分有把握,后续可以做个实验看看。

6. 参考文档

[1] OUI购买链接,http://cn.ieee.org/OUI_introduction.html,http://standards.ieee.org/develop/regauth/oui/index.html

[2] Core_v4.2.pdf

 

原创文章,转发请注明出处。蜗窝科技,www.wowotech.net

标签: 蓝牙 BLE public random static private resolvable address

评论:

helen
2020-09-16 14:01
wowo的总结中有相关说明
“如果地址解析不正确,本地设备向对方发送的所有的数据包(扫描请求、连接请求等),都不能被正确接收(因为目的地址不正确)。但有一个例外,如果本地设备直接关闭地址解析功能,还是能收到对方的广播包,因此,Resolvable private address并不能保护广播包的数据。如果有敏感信息,放到scan response packet中应该是一个不错的选择。”
cafp
2020-07-09 14:23
Resolvable private address比较有用,它通过一个随机数和一个称作identity resolving key (IRK) 的密码生成,因此只能被拥有相同IRK的设备扫描到,可以防止被未知设备扫描和追踪---------实验表明广播地址为Resolvable private address的设备是可以被任何一部无其IRK的手机扫描跟连接到的。
cafp
2020-07-09 14:21
Resolvable private address比较有用,它通过一个随机数和一个称作identity resolving key (IRK) 的密码生成,因此只能被拥有相同IRK的设备扫描到,可以防止被未知设备扫描和追踪.-----------通过实验表明地址为Resolvable private address设备是可以,被任何一部没有其IRK的手机扫描到,并且连接的!
yibin cai
2019-10-10 16:12
很好的总结。

存在则合理,哈哈,
Non-resolvable private address 该地址类型,可在以下情景中应用:

某公司在城市的各个商铺里布置了 beacon 设备,然后自己的 app 会识别 beacon 设备广播数据里已经加密过的内容,来判断已扫描到的设备所在的位置

此时有竞争对手公司,想要直接利用这个公司布置的 beacon 设备,若 beacon 设备上有可识别的唯一标识(如 public address),则他们可以比较简单的识别该标识,和位置配对保存,组成数据库。便可直接利用该公司的已有布置

此时,beacon 设备上不能存在一个唯一标识,于是 Non-resolvable private address 便应用于此场景
星星
2018-12-26 11:26
咨询一下,最近在做测试时发现有几款手机,跟BLE HID设备连接OK之后,然后在两端同时删除配对信息,发现此款手机还会发起重连(抓包发现,感觉是个手机bug),只是重连失败(log提示),但是手机上看不出变化,此时设备是public地址,但是若是把设备改成random地址,手机就不会发起重连,会有什么区别吗
David
2018-08-24 08:31
想問一下如host 是resolvable private address,已和設備機配對完成
如設備想做direct connecteable advertisement? 是否可以?
如果可以,那我應用甚麼address 來做? 是否應用第一次連接時的random address 來做direct advertisement?
謝謝!
wowo
2018-08-24 10:10
@David:广播的时候,无论是什么类型的广播,都包括local或remote两种地址,这两种地址都可以是private地址或random地址(以及是否加密,可参考http://www.wowotech.net/bluetooth/ble_broadcast.html的介绍),具体的原理,是类似的。如果是local地址,则用local的ipk加密,或者,用remote的ipk加密。只要对方能够正确解密即可。
David
2018-08-24 12:52
@wowo:謝謝回覆! 在direct advertisement中,
我的advertiser address 是固定的, type是public type.
在第1次連接時會得到Host 的random address, 在回連時會得到Host 的Public Identity Address. (可能是... API 的問題..)

在15分鐘內, 我把random address放在Initiator Address 中, 是可以回連
但過了一段時間,便不能了..
我試過放public identity address 在initiator address中也是不成..

所以好奇direct advertising 是否可以在host 是resolvable private address下使用, 或是只可以用15分鐘?
wowo
2018-08-24 16:16
@David:这说明host的random address是定时在改变的。
虎妞
2019-09-02 11:37
@David:Note that directed advertising will only be used when the Central has a random static address type (address is static and does not change). If the Central has a resolvable address (address changes over time), undirected advertising with whitelist is used instead.
这是nordic一个键盘的文档中摘下来的一段话。可能可以回复你的问题。
eshin
2022-05-05 18:07
@David:您提问题的时间是2018年,这时候发布的规格书是4.2.这里只讨论device支持privacy mode的情况,应该是这样:
1. initiator address只能是RPA(resolvable private address)地址.具体可见蓝牙核心协议core4.2及以上 [Vol 6, Part B]6.4节.具体内容:
An initiator that has been instructed by the Host to use Resolvable Private Addresses shall not respond to directed connectable advertising events that contain Public or Static addresses for the initiator address, (InitA field).

2. 而对于device不支持privacy mode的情况,可能是如@虎妞所回复.具体还要看规格分析下.我见过部分鼠标这种情况下,发的是direct广播,initiator address刚好也是静态地址.
mkseven32
2018-05-29 15:22
如果是随机产生的, 那会不会出现 地址冲突的现象? 出现了如何解决冲突?
wowo
2018-05-30 10:36
@mkseven32:从概率上来看,确实有地址冲突的可能,不过概率太低了,基本不可能碰到。所以蓝牙现在并没有定义怎么解决这种冲突。
mkseven32
2018-05-30 13:40
@wowo:嗯,谢谢博主回复! 可能目前ble 的设备还不多,如果向后大规模使用时,我觉得发生的概率应该是比较大的!
春春1028
2018-06-15 13:53
@mkseven32:我认为蓝牙的通信距离限制了一定区域的设备数量,所以即使是大规模使用地址冲突的概率也会很小
小怂包
2018-03-25 15:39
想问问:
1.如果设备地址已经改变,手机怎么知道现在这个设备就是之前那个设备呢?
2.如果有人恶意攻击中心设备,派了很多的BLE来连接它,那么如果没有保护措施,中心设备不是很快就挂掉了?
wowo
2018-05-30 10:34
@小怂包:地址如果已经改变,手机就不知道这个设备是不是之前那个了;
这种时候,中心设备要用其它机制过滤非法设备地址。
chenchuangchn
2018-01-15 16:40
wowo大神:
1.文中提到的IPK是什么意思啊,24bits是随机数和IRK经过hash运算得到的hash值?
2.“以T_GAP(private_addr_int)为周期”更新的是随机数吗。
3. 大神有没有计划写写关于bluez上层的东西,比如gatt的通信,音频的连接与通信等。
wowo
2018-01-16 09:42
@chenchuangchn:抱歉啊,IPK是写错了,应该是IRK;
更新的是地址哦;
暂时没有时间写啊~~
三九感冒灵
2017-07-22 11:56
感谢分享,希望楼主有时间可以写写classic BT 部分的东西,毕竟两者的差异还是比较大。
wowo
2017-07-24 09:04
@三九感冒灵:多谢关注,有时间的话可以试试,不过经典蓝牙的复杂度和ble不是一个数量级的,不太好写。真的需要了解的话,最好的资料还是那一个厚厚的core spec。

发表评论:

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog