在线时间4063 小时
UID3441752
注册时间2017-11-21
NXP金币759412
TA的每日心情 | 开心 3 天前 |
---|
签到天数: 266 天 [LV.8]以坛为家I
管理员
- 积分
- 31909
- 最后登录
- 2024-3-29
|
一、概述
BLE标准定义了非常多的安全机制,来保证BLE设备数据信息不被窃听、跟踪及设备本身不被攻击等。其中Privacy机制就是通过Resolvable Private Address(简称PRA),在通讯时对BLE设备地址进行保护,降低被窃听、伪装的可能性。
为方便理解,本文结合NXP QN908x/KW36 SDK先对BLE地址类型、白名单机制(White List)做个简单的介绍,再对地址解析列表(Resolving List)进行说明。
二、BLE设备地址类型
BLE地址有Public Device Address和Random Device Address两种类型,均为48位。一个BLE设备可同时具备这两种地址。
Public Device Address由24位 IEEE分配的Company Id及24位公司分配的序列号,组成48位唯一地址。唯一性导致安全性降低,在实际应用中往往还需Random Device Address配合使用。
Random Device Address分为Static Device Address和Private Device Address。Static Device Address为设备随机产生,最高2位为0b11,低46位需是不为全0和全1的随机码,在一个供电周期内保持不变。
Private Device Address包含Non-resolvable Private Address以及上面提到的Resolvable Private Address。顾名思义,Non-resolvable Private Address即不可解析私有地址,无法与真实设备地址对应,最高2位为0b00,低46位需是不为全0和全1的随机码,比较少用。
Resolvable Private Address,可被解析与真实设备地址对应,最高2位为0b01,高24位称为prand,prand的低22位需是不为全0和全1的随机码。低24位为hash部分,通过哈希算法ah获得,hash = ah(IRK, prand),其中IRK为Identity Resolving Key,主要用于解析和生成PRA,这是Privacy机制实现的关键。hash || prand即得到PRA。
恩智浦的QN908x/KW36 SDK提供了地址操作API,API执行完后会向application的通用回调函数BleApp_GenericCallback()推送对应的通用事件:
三、白名单机制
白名单(White List)是一组BLE设备地址列表,每项由地址类型和对端设备地址(Peer Device Address)组成。BLE设备可以只允许白名单中的设备扫描、连接,或者只扫描、连接白名单中的设备。需要指出的是白名单存储的一般是Identity Address,即为Public Device Address或Static Device Address。
在NXP的QN908x/KW36应用例程中,我们可以通过打开在app_preinclude.h的Pairing和Bonding两个宏来同时使能白名单功能:
#define gAppUsePairing_d 1
#define gAppUseBonding_d 1
另外还需使能NVM以保存白名单中的设备地址,以在重新上电时恢复白名单,名单最大数目由gMaxBondedDevices_c定义,比如定义为16:
#define gAppUseNvm_d 1
#define gMaxBondedDevices_c 16
BLE标准定义的白名单命令如增加条目、删除条目、读取大小等,NXP QN908x/KW36 SDK也定义了对应API。同样地,API执行完也会在application的通用回调函数BleApp_GenericCallback()产生相关事件:
四、Privacy特性
Privacy为BLE设备的可选特性,在NXP QN908x/KW36 应用程序可通过配置app_preinclude.h的宏使能:
#define gAppUsePrivacy_d 1
Privacy的实现需要相应的流程、模式支持配合,标准《Bluetooth Core Specification v5.1》中对此规定如下:
如上表所述,常见的BLE Peripheral若支持Privacy,需要同时支持RPA的生成和解析,以及Bonding。
1) Resolving List
Resolving List用于保存自己和对端设备的地址密钥信息,实现对自己和对端地址的保护。它的格式为Local IRK | Peer IRK | Peer Device Identity Address | Address Type。
它跟White List的关系如下,但实际实现时并不需要严格按照这种逻辑来设计,两者可互相独立。
Resolving List的大小在NXP QN908x/KW36应用程序中需提前定义,如:
#define gMaxResolvingListSize_c 16
Local IRK用于将自己的Identity Address转为PRA,若为0,则直接用Identity Address。
Peer IRK用于将对端设备PRA解析为IdentityAddress,若为0,表示对端设备所用地址即为Identity Address。
Host通过增加或删除设备条目来维护Resolving List,向Controller提供全部或部分的列表条目。地址解析和生成可在Host或Controller执行,分别称为Host-based Privacy和Controller-basedPrivacy。当使能Controller-based Privacy时,Host向Controller提供Identity Address和IRK后,由Controller解析和生成,而无需Host干预。需要指出的是,如果Controller无法存储所有的IRK信息,仍需要Host协助存储和提供;从Controller传递至Host的事件将均使用Identity Address,但若Controller无法解析RPA,它会抛RPA给到Host让Host解析。一般会默认使能Controller-basedPrivacy,在Controller即可做设备过滤,理论上可降低设备功耗。NXP QN908x/KW36 SDK的使能API有:
bleResult_t Gap_EnableHostPrivacy
(
bool_t enable,
uint8_t* aIrk
);
bleResult_t Gap_EnableControllerPrivacy
(
bool_t enable,
uint8_t* aOwnIrk,
uint8_t peerIdCount,
gapIdentityInformation_t* aPeerIdentities
);
在NXP SDK的实现中,若使能gAppUsePrivacy_d,Controller-based Privacy自动使能。
在Bluetooth v5.0及更新版本,定义了Privacy的两种模式:Device Privacy和Network Privacy。在Device Privacy 模式下,设备只关心自身隐私,会接受带Identify Address或者PRA的广播包,即使这个对端设备已在过去发布过IRK。而在Network Privacy模式下,设备只接受带有RPA的广播包。当Controller负责解析和生成RPA时,默认使用Network Privacy模式。
Resolving List在NXP SDK中的具体操作,在使能Privacy后会自动执行。可通过在应用程序中打印ble_globals.c里定义的全局变量来查看Resolving List的内容:
gapIdentityInformation_t gaControllerPrivacyIdentities[gMaxResolvingListSize_c];
2) RPA的使用
使能Privacy后,设备需要根据自身角色、状态将RPA设置进对应的地址段,并对接收到的RPA进行解析和进一步处理。
a. 广播状态(Advertising State)
此时设备为Advertiser。在发送ADV_IND包时,若Local IRK非0,则将Identity Address转化为RPA,填充进AdvA段;若Local IRK为0,则将Identity Address填充进AdvA段。在发送ADV_DIRECT_IND包时,除了填充AdvA,还需填充TargetA,若Peer IRK非0,则将Identity Address转化为RPA,填充进TargetA段;若Peer IRK为0,则将Identity Address填充进TargetA段。ADV_NONCONN_IND and ADV_SCAN_IND填充策略类似,不作赘述。
Advertiser在收到连接请求或扫描请求时,需判断InitA/ScanA的地址类型。若为RPA,则遍历Resolving List的Peer IRK进行解析,解析成功后则进行下一步处理,否则连接失败/不响应请求。若为Identity Address,则根据自身策略决定下一步处理。
b. 扫描状态(Scanning State)
此时设备为Scanner。在发送扫描请求填充ScanA、接收Scannable广播包的AdvA的策略与上面描述类似,不作赘述。发送扫描请求的AdvA需跟接收到的AdvA保持一致。
c. 连接发起状态(Initiating State)
此时设备为Initiator。在发送连接请求填充InitA、接收Connectable广播包的AdvA的策略与上面描述类似,不作赘述。发送连接请求的AdvA需跟接收到的AdvA保持一致。
五、后记
BLE标准不断更新,各个版本对Privacy的定义略有差异。不同厂家芯片、不同操作系统类别和版本对BLE Privacy的实现不太一致,这可能导致配对、回连失败等兼容性问题。遇到此类问题需具体问题具体分析,通过修改代码配置、逻辑或联系手机PC厂家一起定位解决。
作者:叶国欣Aaron@NXP 文章出处:恩智浦MCU加油站
|
|