1. 低功耗蓝牙安全场景下的随机数需求拆解低功耗蓝牙BLE从4.0版本开始就把低功耗作为核心卖点一颗纽扣电池撑几个月甚至几年是常态。但省电这件事本身和安全性存在天然矛盾——射频收发要省电、协议栈要省电、连随机数发生器都得省电。很多做BLE产品的团队在早期验证阶段安全部分往往是最后才补的等到要过认证或者客户做渗透测试时才发现随机数这一环出了问题。我接触过不少做智能门锁、医疗贴片、资产标签的团队他们在BLE配网、密钥协商、会话建立这些环节里随机数的质量直接决定了整套安全体系是否成立。如果随机数可预测那么配对过程中的临时密钥、会话密钥、挑战值都可能被推算出来攻击者甚至不需要破解加密算法本身直接从随机数源头绕过去。这篇文章面向的是正在做BLE产品安全设计或准备过安全认证的嵌入式工程师、固件开发者、安全测试人员。我会把TRNGTrue Random Number Generator真随机数发生器在BLE场景下的应用逻辑、设备安全认证的完整方案、以及实际落地时会踩的坑按我自己的项目经验拆开讲。你不需要有密码学背景但需要对BLE协议栈和MCU外设有基本了解。1.1 为什么BLE对随机数的依赖比经典蓝牙更深经典蓝牙的配对和加密流程相对固定很多安全参数在协议栈初始化阶段就确定了。BLE不一样它的连接过程高度动态广播、扫描、发起连接、配对、密钥分发、加密启动每一步都可能涉及随机数的生成。尤其是LE Secure Connections配对方式引入后椭圆曲线密钥交换ECDH成为标配私钥的生成质量直接决定了整个配对过程的安全性。BLE的配对流程里有几个关键随机数使用点发起方和响应方各自生成ECDH密钥对私钥必须是高质量的随机数配对过程中生成的确认值Confirm Value依赖于随机数会话密钥的派生也依赖随机数种子。如果这些随机数来自一个可预测的伪随机数发生器PRNG攻击者可以通过收集若干组配对数据反推出种子进而推算出后续所有会话密钥。更麻烦的是BLE设备通常是资源受限的。很多低成本BLE SoC没有硬件TRNG只能靠软件PRNG凑合。软件PRNG的种子来源往往是ADC采样、RTC计数、未初始化内存等这些熵源在实验室环境下看起来还行到了实际部署环境可能高度可预测。比如一个固定在室内工作的温度传感器ADC采样值波动很小RTC计数在设备刚上电时也是可预测的这些都会导致PRNG输出被压缩到一个很小的种子空间里。1.2 TRNG与PRNG的本质区别及在BLE中的定位TRNG和PRNG的区别不是“真”和“假”这么简单。TRNG从物理过程中提取熵比如热噪声、环形振荡器抖动、亚稳态触发器的随机翻转等这些物理过程在理论上不可预测。PRNG则是确定性算法给定相同的种子必然产生相同的序列。在BLE设备里TRNG通常不直接用于生成所有随机数因为TRNG的生成速率往往很低而且功耗不低。常见的做法是用TRNG生成一个高质量的种子然后喂给PRNG通常是CSPRNG密码学安全的伪随机数发生器由PRNG高速生成后续所需的随机数序列。这样既保证了熵源的质量又满足了BLE协议栈对随机数生成速率的要求。这里有个关键点TRNG的质量不是“有就行”而是要经过熵评估。很多MCU厂商在数据手册里写“内置TRNG”但实际输出的熵率可能只有几百比特每秒而且在不同温度、电压条件下质量会波动。如果TRNG输出的熵不够即使后面接了CSPRNG整个链条的安全性也会打折扣。1.3 BLE安全认证对随机数的硬性要求BLE设备要过安全认证随机数这一环通常会被重点审查。以蓝牙SIG的资格认证为例涉及安全的部分会检查配对流程是否符合规范但不会直接测试你的TRNG质量。真正会卡随机数的是行业认证比如金融支付类、医疗类、车规类认证。金融类认证通常要求设备通过FIPS 140-2或140-3的随机数测试包括NIST SP 800-22套件里的频率测试、块频率测试、游程测试、最长游程测试等。这些测试对TRNG的原始输出和CSPRNG的输出都有要求。医疗类认证会参考IEC 62304和ISO 14971对安全相关的随机数生成有风险管理要求。车规类认证则可能要求符合AEC-Q100和ISO 26262的功能安全等级随机数失效要被识别为安全目标的一部分。实际项目里我见过最容易被卡的是TRNG的启动时间。有些TRNG上电后需要一段时间才能输出稳定熵如果BLE协议栈在TRNG就绪之前就开始配对流程就会用到低质量的随机数。这个问题在实验室里很难复现因为实验室通常会给设备足够的启动时间但实际产品可能从按下按钮到开始广播只有几百毫秒。2. BLE协议栈中TRNG的集成位置与数据流BLE协议栈从下到上大致分为控制器Controller和主机Host两大部分。控制器包含物理层、链路层、以及部分HCI层主机包含L2CAP、ATT、GATT、SM安全管理器等。TRNG的集成位置决定了它能影响哪些安全环节。2.1 控制器层与主机层的随机数分工控制器层主要负责链路层的加密和部分随机数生成。比如BLE的跳频算法需要随机数来选择信道这个随机数通常由控制器内部的PRNG生成种子来自TRNG。链路层加密启动时加密引擎的初始化向量IV也需要随机数这个通常也由控制器处理。主机层的安全管理器SM负责配对和密钥分发这是随机数使用最密集的地方。LE Secure Connections配对中SM需要生成ECDH密钥对私钥必须是高质量的随机数。这个随机数通常由主机层的CSPRNG提供而CSPRNG的种子来自控制器的TRNG。这里有个常见的架构问题控制器和主机可能运行在不同的芯片上比如控制器在BLE SoC里主机在应用MCU里。这种情况下TRNG在控制器侧主机侧的CSPRNG需要通过HCI命令从控制器获取随机数。如果HCI通道被攻击者监听随机数种子就可能泄露。所以有些方案会在主机侧也集成一个TRNG或者使用控制器提供的随机数作为种子后再经过一次本地CSPRNG处理。2.2 TRNG种子注入CSPRNG的时机与频率TRNG种子注入CSPRNG的时机很关键。太早注入TRNG可能还没输出稳定熵太晚注入协议栈可能已经用到了低质量的随机数。我的经验是在BLE协议栈初始化之前就完成TRNG的启动和自检然后在协议栈初始化过程中注入种子。注入频率方面不是一次注入就一劳永逸。CSPRNG的输出序列在理论上是有周期的虽然密码学安全的CSPRNG周期极长但为了保险建议在每次BLE连接建立前重新注入一次TRNG种子。这样即使某次连接的随机数被预测也不会影响后续连接。具体实现上可以在BLE连接事件回调里触发TRNG采样将采样结果混入CSPRNG的状态。混入的方式可以用异或或者哈希我通常用SHA-256把TRNG输出和当前CSPRNG状态一起哈希然后更新CSPRNG状态。这样即使TRNG输出被部分预测CSPRNG的状态仍然难以反推。2.3 不同BLE SoC平台的TRNG集成差异不同厂商的BLE SoC在TRNG集成上差异很大。Nordic的nRF52系列和nRF53系列内置了TRNG外设通过寄存器读取随机数使用起来比较直接。TI的CC26xx系列也有硬件TRNG但需要配置熵源参数。Silicon Labs的EFR32系列TRNG质量不错但启动时间较长。ESP32系列有硬件随机数发生器但早期版本的熵源质量被社区质疑过后来通过软件混合改善了。STM32WBA65是ST比较新的BLE SoC内置了TRNG而且ST在安全方面做了不少工作包括安全启动、安全存储、TrustZone等。这颗芯片的TRNG在数据手册里标称的熵率比较高实际使用中启动时间也可以接受。不过它的TRNG配置比nRF系列复杂一些需要设置时钟源、采样速率、后处理参数等。选择平台时如果产品对安全认证有硬性要求建议优先选TRNG经过第三方评估的芯片。有些厂商会提供TRNG的熵评估报告这个在过认证时很有用。如果芯片厂商没有提供自己送第三方做评估也是一笔不小的开销。3. 设备安全认证方案的核心环节与TRNG的支撑作用BLE设备的安全认证不是单一认证而是一组认证的组合。不同行业、不同应用场景要求的认证不同但核心环节有共通之处。TRNG在这些环节里扮演的是“信任根”的角色如果信任根不牢上面的认证都是空中楼阁。3.1 安全启动与TRNG的关系安全启动的核心是验证固件的完整性和真实性。设备上电后BootROM先验证一级引导程序的签名一级引导程序验证二级引导程序以此类推直到应用固件。这个链条里签名验证用的是非对称加密算法比如ECDSA或RSA。非对称加密算法的安全性依赖于密钥对的生成质量。如果设备在出厂时生成密钥对私钥的随机数质量直接决定了密钥的安全性。如果私钥生成时用的随机数可预测攻击者可以推算出私钥进而伪造固件签名整个安全启动链条就崩了。所以安全启动的信任根其实在密钥生成那一刻就确定了。我的做法是在产线生成密钥对时使用经过认证的TRNG模块并且记录TRNG的熵评估数据。有些产线为了效率用软件PRNG生成密钥对这是很大的安全隐患。3.2 安全存储与密钥派生中的随机数BLE设备通常需要存储一些敏感信息比如配对密钥、身份密钥、加密密钥等。这些密钥不能明文存储在Flash里需要用设备唯一密钥加密后存储。设备唯一密钥的生成也依赖TRNG。密钥派生方面BLE的LE Secure Connections配对会产生LTK长期密钥这个LTK可以用于后续连接的加密。LTK的派生过程涉及随机数如果随机数质量不高LTK可能被预测。有些方案还会用HKDFHMAC-based Key Derivation Function从主密钥派生多个子密钥HKDF的salt值也需要随机数。安全存储的实现方式有几种一种是直接用MCU内置的安全存储区比如STM32WBA65的TrustZone安全区另一种是用外部安全芯片比如ATECC608A或SE050。无论哪种方式密钥的生成和派生都离不开TRNG。3.3 安全认证中的挑战-响应机制与TRNG很多安全认证方案会用挑战-响应机制来验证设备身份。认证方发送一个随机挑战值设备用私钥对挑战值签名认证方用公钥验证签名。这个机制的安全性依赖于挑战值的随机性。如果挑战值可预测攻击者可以重放之前的签名响应绕过认证。挑战值的生成通常由认证方负责但设备侧也可能生成挑战值用于双向认证。设备侧生成挑战值时TRNG的质量直接影响认证的安全性。我见过一些方案为了省事用时间戳作为挑战值这在时间同步的场景下可预测性很高容易被攻击。3.4 认证方案的整体架构与TRNG的定位一个完整的BLE设备安全认证方案通常包含以下层次硬件信任根TRNG、安全存储、安全启动、固件安全签名验证、安全更新、通信安全BLE配对加密、应用层加密、身份认证证书、挑战-响应、以及生命周期管理密钥更新、设备注销。TRNG位于最底层的硬件信任根它的质量决定了整个方案的上限。如果TRNG被攻破上面的所有安全机制都可以被绕过。所以我在设计认证方案时会把TRNG的评估和测试作为第一优先级而不是等到最后才补。4. 实操TRNG在BLE设备上的集成与测试流程这一部分我按实际项目的顺序来写从芯片选型到TRNG配置再到BLE协议栈集成最后是测试和认证准备。每一步都会给出具体的操作方法和参数建议。4.1 芯片选型与TRNG能力评估选芯片时TRNG能力要看几个指标熵率比特每秒、启动时间、功耗、温度稳定性、以及是否有第三方评估报告。熵率决定了TRNG能多快提供足够的熵启动时间决定了设备上电后多久才能开始安全操作功耗决定了TRNG是否适合电池供电的BLE设备。以nRF52840为例它的TRNG熵率在数据手册里没有明确标称但实测下来在室温下大约能提供几百比特每秒的熵。启动时间大约几毫秒。功耗在微安级别对BLE设备来说可以接受。STM32WBA65的TRNG熵率更高一些启动时间也在毫秒级但配置更复杂。如果芯片没有硬件TRNG可以考虑外部TRNG芯片比如Microchip的ATECC608A内置了TRNG同时还有安全存储和加密加速功能。外部芯片的好处是TRNG质量有保障缺点是增加了BOM成本和PCB面积。4.2 TRNG初始化与自检代码实现TRNG初始化通常包括时钟配置、熵源配置、后处理配置、以及自检。自检的目的是确认TRNG输出符合预期如果自检失败设备应该进入安全降级模式比如拒绝执行安全操作或者报警。以下是一个基于nRF52840的TRNG初始化示例伪代码实际使用时需要参考具体SDK// 使能TRNG时钟 NRF_CLOCK-EVENTS_HFCLKSTARTED 0; NRF_CLOCK-TASKS_HFCLKSTART 1; while (NRF_CLOCK-EVENTS_HFCLKSTARTED 0); // 配置TRNG NRF_RNG-CONFIG RNG_CONFIG_DERCEN_Msk; // 使能偏差校正 NRF_RNG-TASKS_START 1; // 等待TRNG就绪 while (NRF_RNG-EVENTS_VALRDY 0); NRF_RNG-EVENTS_VALRDY 0; // 读取随机数 uint32_t random_value NRF_RNG-VALUE;自检部分我通常会连续读取若干组随机数做基本的统计测试比如检查0和1的比例是否接近1:1检查是否有连续相同的字节。如果自检失败记录错误并触发安全策略。4.3 BLE协议栈集成TRNG的配置方法BLE协议栈集成TRNG的方式取决于协议栈的实现。以Nordic的SoftDevice为例SoftDevice内部有自己的随机数生成器但它的种子来自哪里需要确认。有些版本的SoftDevice会使用硬件TRNG作为种子有些则使用固定的种子。如果SoftDevice没有使用硬件TRNG需要在应用层通过API注入种子。以Zephyr的BLE协议栈为例Zephyr有统一的随机数APIsys_rand32_get()会调用底层的随机数驱动。如果底层驱动配置为使用硬件TRNG那么BLE协议栈的随机数就来自TRNG。配置方法是在设备树里使能TRNG节点并在Kconfig里选择对应的随机数驱动。ESP32的BLE协议栈Bluedroid或NimBLE也有类似的配置。ESP-IDF提供了esp_random()函数它会使用硬件随机数发生器。在BLE初始化之前建议先调用esp_random()几次确保TRNG已经就绪。4.4 TRNG输出质量测试与熵评估TRNG输出质量测试是认证准备的关键步骤。我通常用NIST SP 800-22套件做测试包括频率测试、块频率测试、游程测试、最长游程测试、二进制矩阵秩测试、离散傅里叶变换测试等。测试样本至少需要100万比特最好是多组样本在不同温度、电压条件下采集。测试工具可以用NIST提供的STSStatistical Test Suite也可以用开源的dieharder或TestU01。我一般先用dieharder做快速筛查再用NIST STS做正式测试。测试结果里p值大于0.01算通过但要注意多重测试校正避免假阳性。如果测试不通过可能的原因包括TRNG熵源质量不足、后处理参数配置不当、采样速率过高导致相邻样本相关、电源噪声干扰等。解决方法包括降低采样速率、增加后处理、改善电源滤波、或者换用质量更好的TRNG芯片。4.5 安全认证准备中的TRNG文档要求安全认证时TRNG相关的文档通常包括TRNG设计说明、熵源分析、熵评估报告、自检机制说明、失效模式分析、以及测试记录。这些文档需要在认证前准备好有些认证机构还会要求现场演示TRNG的自检和失效处理。熵评估报告最好由第三方实验室出具比如国内的赛宝实验室、中国信息安全测评中心或者国外的UL、TUV等。报告里要包含测试方法、测试条件、测试结果、以及结论。如果芯片厂商已经提供了评估报告可以直接引用但要注意报告的有效期和适用范围。5. 常见问题与排查技巧实录这一部分是我在实际项目中遇到过的典型问题和解决方法整理成速查表方便参考。5.1 TRNG启动失败或输出异常TRNG启动失败的表现通常是读取随机数时超时或者读到的值全是0或全是1。原因可能是时钟未使能、熵源未稳定、后处理配置错误、或者硬件故障。排查步骤先检查时钟配置确认TRNG时钟源已经使能并且稳定然后检查熵源配置有些TRNG需要配置采样速率和偏差校正接着检查后处理配置有些TRNG的后处理会引入偏差最后用示波器检查电源和地线排除硬件问题。我遇到过一次TRNG输出全是0的情况排查后发现是时钟配置错误TRNG的时钟源被误配置为低速时钟导致熵源采样速率过低输出被后处理滤成了0。改成高速时钟后问题解决。5.2 BLE配对过程中随机数相关错误BLE配对过程中随机数相关的错误通常表现为配对失败、密钥协商失败、或者配对后连接不稳定。原因可能是随机数质量不足导致ECDH密钥对生成失败或者CSPRNG种子注入时机不对导致密钥不一致。排查方法先在配对前打印TRNG自检结果确认TRNG正常然后在配对过程中打印ECDH公钥和确认值检查是否有异常最后用BLE抓包工具比如nRF Sniffer或Ellisys抓取配对过程分析配对数据。我遇到过一次配对失败抓包后发现发起方的ECDH公钥每次都不一样但响应方的公钥每次都一样。排查后发现响应方的CSPRNG种子在每次配对时没有更新导致私钥重复。修复方法是在每次配对前重新注入TRNG种子。5.3 安全认证测试不通过的典型原因安全认证测试不通过的原因很多TRNG相关的典型原因包括熵评估报告缺失或过期、自检机制不完善、失效处理不符合要求、测试样本不足、测试条件不符合认证要求等。解决方法提前了解认证机构的具体要求准备好完整的文档自检机制要覆盖TRNG启动、输出质量、以及失效处理测试样本要在不同条件下采集并且保留原始数据如果认证机构有现场测试要求提前演练。5.4 低功耗与TRNG的功耗平衡BLE设备对功耗敏感TRNG的功耗需要仔细管理。TRNG通常不需要一直运行只在需要生成随机数时启动生成完成后立即关闭。但频繁启动关闭会增加功耗因为每次启动都需要等待熵源稳定。我的做法是在BLE连接建立前启动TRNG生成种子后关闭在连接期间如果需要随机数用CSPRNG生成连接结束后如果下次连接间隔较长可以关闭CSPRNG下次连接前重新注入种子。这样在保证安全性的同时把TRNG的功耗降到最低。5.5 常见问题速查表问题现象可能原因排查方法解决方法TRNG读取超时时钟未使能或熵源未稳定检查时钟配置和熵源状态使能时钟等待熵源稳定TRNG输出全0或全1后处理配置错误或硬件故障检查后处理参数用示波器检查电源调整后处理参数修复硬件BLE配对失败随机数质量不足或种子未更新打印TRNG自检和配对数据提高TRNG质量更新种子认证测试不通过文档缺失或测试样本不足对照认证要求逐项检查补充文档增加测试样本功耗超标TRNG一直运行或频繁启动测量TRNG功耗按需启动TRNG优化启动策略6. 方案扩展与个人经验总结BLE设备的安全认证不是一锤子买卖产品上市后还需要考虑密钥更新、固件安全更新、设备注销等生命周期管理。TRNG在这些环节里同样重要比如密钥更新时需要生成新的密钥对固件安全更新时需要验证签名这些操作都依赖高质量的随机数。我在实际项目里踩过最大的坑是低估了TRNG启动时间对用户体验的影响。有一个项目设备从按下按钮到开始广播只有200毫秒但TRNG启动需要50毫秒加上协议栈初始化留给TRNG的时间窗口很窄。后来通过优化启动流程把TRNG启动提前到系统上电阶段问题才解决。另一个经验是不要迷信芯片厂商的TRNG标称参数。数据手册里的熵率通常是在理想条件下测的实际使用中受温度、电压、PCB布局影响很大。我的做法是在产品定型前用实际硬件在不同条件下采集TRNG输出做完整的熵评估确保留有余量。最后分享一个小技巧如果芯片的TRNG质量不够可以用多个熵源混合。比如把TRNG输出、ADC噪声、RTC抖动、以及未初始化RAM的内容一起哈希作为CSPRNG的种子。这样即使单个熵源质量不高混合后的熵也会好很多。当然这种方法不能替代高质量的TRNG但在成本受限的场景下是一个可行的折中方案。