低功耗蓝牙设备这几年铺得很快，从智能门锁、穿戴设备到工业传感器，几乎只要涉及电池供电又要联网的场景，BLE都是默认选项。但真正把产品推到量产阶段，很多团队会卡在同一个地方：设备怎么证明"我是我"，而不是随便一个伪造终端就能接入网关、上报假数据或者下发控制指令。身份认证这件事在Wi-Fi和蜂窝网络里已经有成熟方案，搬到BLE上却处处受限——没有TCP/IP栈、内存以KB计、还要兼顾纽扣电池几年的续航。我前后做过几个BLE终端项目，从最初用固定密钥被安全审计打回，到后来把TRNG（真随机数发生器）和认证流程整合进量产固件，中间踩的坑足够写一篇长文。这篇就把低功耗蓝牙物联网终端的身份认证设计，以及TRNG在其中的实际落地方式，按我自己的项目经验完整拆一遍。
1. 为什么BLE终端的身份认证不能照搬传统方案
1.1 BLE协议栈本身提供的安全能力边界
BLE从4.2版本开始引入了LE Secure Connections，配对过程用上了ECDH密钥交换，理论上可以防窃听和中间人。但这里有个容易被忽略的前提：配对是"人机交互"场景设计的，需要用户确认或者输入配对码。放到无人值守的物联网终端上，设备开机就要自动连网关，根本没有人在旁边点确认。很多团队图省事，直接开Just Works配对模式，结果就是加密链路建立了，但双方身份完全没有验证——任何一台知道广播格式的设备都能连上来。
BLE的链路层加密解决的是"传输过程不被窃听"，它不解决"对面这个设备是不是合法终端"。这是两个层面的问题。链路加密像是给电话线加了扰码，但打电话的人是谁，协议栈不管。身份认证必须由应用层或者上层安全服务来补。
1.2 物联网终端面临的真实威胁模型
我在项目里梳理过几类实际会遇到的攻击场景。第一类是克隆终端，攻击者拆解一台合法设备，读出固件里的密钥，批量复制出假终端接入网络。第二类是重放攻击，抓取一次合法的认证报文，原样重发骗过网关。第三类是中间人，在终端和网关之间架一个转发节点，双向透传。第四类是物理侧信道，通过功耗分析或者电磁探测反推密钥。
这四类威胁里，克隆和重放是最常见的，成本也最低。固定密钥方案对克隆毫无抵抗力，因为密钥就存在Flash里，读出来就能用。重放攻击则要求认证报文每次都不一样，这就直接引出了随机数的需求——如果每次认证用的挑战值可以预测，重放就防不住。
1.3 资源约束下认证方案的设计取舍
BLE终端通常跑在Cortex-M0到M4这个级别，RAM从8KB到64KB不等，Flash从64KB到512KB。跑完整的TLS栈不现实，跑轻量级的DTLS也要几十KB。所以认证方案必须做减法。
我的取舍原则是：认证逻辑放在应用层，用挑战-响应模式，密码学原语只保留必要的几个。具体来说，网关下发一个随机挑战值，终端用私钥对挑战值做签名或者HMAC，网关用对应公钥验证。这样既不需要建立复杂的会话，也不需要传输证书链。代价是每次认证要做一次非对称运算，ECDSA在M4上大概几十毫秒，可以接受。
这里的关键是挑战值必须真随机，而且终端侧的密钥必须不可读出。前者靠TRNG，后者靠安全存储或者至少是读保护。下面几节分别展开。
2. TRNG在BLE终端里的真实作用与选型逻辑
2.1 伪随机数为什么在安全场景下不够用
很多MCU自带的是PRNG，基于线性反馈移位寄存器或者软件算法，种子来自某个固定值或者低熵的时钟抖动。这种随机数在功能测试里看不出问题，但它的输出序列是可预测的——只要知道算法和种子，就能推算出后续所有值。
在认证场景里，如果终端生成的nonce是可预测的，攻击者就能提前算出终端下一次会发什么，从而构造重放或者伪造响应。更隐蔽的风险是密钥生成：如果设备首次配网时用PRNG生成密钥对，而PRNG种子熵不足，不同设备可能生成相同的密钥，或者密钥落在攻击者可枚举的范围内。
我见过一个案例，某批次设备因为PRNG种子取自芯片唯一ID的低几位，导致几千台设备的密钥空间被压缩到实际只有几百种组合。这种问题在出厂测试时完全发现不了，只有做安全审计才会暴露。
2.2 TRNG的熵源类型与BLE芯片的适配
TRNG的熵源主要有几种：环形振荡器抖动、热噪声、亚稳态触发器、以及模拟电路的噪声。BLE芯片里常见的是环形振荡器方案，因为纯数字实现，不占模拟资源，面积小。
以nRF52840为例，它内置了硬件TRNG，基于多个环形振荡器的相位抖动，输出经过数字后处理。实测下来，在室温下产生128位随机数大概需要几十微秒，功耗增加可以忽略。但要注意，TRNG的熵率会受温度和电压影响，极端条件下（比如零下40度或者电压偏低）熵可能下降。所以固件里要有健康检测，如果TRNG输出没通过统计测试，要能降级或者报错，而不是继续用低质量的随机数。
选型时我会看几个指标：熵率（bit/s）、是否通过AIS-31或者NIST SP800-90B认证、有没有内置健康测试、以及驱动复杂度。有些芯片的TRNG需要手动触发多次采样再拼合，驱动写起来麻烦，量产时容易出问题。
2.3 从TRNG到可用随机数的后处理链路
硬件TRNG出来的原始比特流不能直接用，通常要做后处理。常见做法是用SHA-256或者AES-CBC-MAC做条件化，把原始熵压缩成均匀分布的密钥材料。这一步在软件里做，消耗一点CPU，但能显著提升随机数质量。
我的做法是：TRNG产生256位原始数据，经过SHA-256哈希后取前128位作为nonce，后128位混入密钥派生。每次认证前重新采样，不复用。这样即使TRNG某次输出有偏，哈希也能把偏差摊平。
要注意的是，后处理不能增加熵，只能把已有的熵均匀化。如果TRNG本身熵不足，哈希也救不回来。所以健康检测必须放在后处理之前，先确认原始数据有足够熵。
3. 挑战-响应认证流程的完整设计与实现
3.1 认证协议的报文交互时序
整个认证流程我设计成三步。第一步，终端广播或者连接后发送自己的设备ID，网关收到后生成一个128位随机挑战值，通过BLE的GATT写特征发给终端。第二步，终端用自己存储的私钥对挑战值做ECDSA签名，同时附上自己的设备证书或者公钥索引，通过GATT通知发回网关。第三步，网关用对应的公钥验证签名，验证通过则下发会话密钥，后续通信用它做对称加密。
这个流程里，挑战值每次不同，签名每次不同，重放攻击拿不到有效响应。克隆攻击则需要攻击者拿到私钥，而私钥存在芯片的读保护区域，常规手段读不出来。
时序上要注意BLE的连接间隔。如果连接间隔设成100ms，三步交互大概需要300到500ms。对于门锁这类场景可以接受，对于高频上报的传感器，可以考虑把认证结果缓存一段时间，比如24小时内复用会话密钥，不用每次连接都重新认证。
3.2 终端侧密钥存储与读保护配置
私钥存储是整条链路上最脆弱的一环。我的做法是优先用芯片内置的安全存储，比如nRF52840的KMU（密钥管理单元）或者带TrustZone的MCU的安全区。如果芯片没有硬件安全模块，退而求其次用Flash读保护加加密存储。
Flash读保护要配置成最高级别，禁用调试接口的读取权限。同时固件里不要有任何可以导出私钥的接口，哪怕是调试命令也不行。我见过有团队为了方便产线测试，留了一个通过串口读密钥的后门，结果被逆向出来，整个批次的安全性归零。
密钥注入要在产线完成，每台设备唯一。注入后立即锁定，锁定操作不可逆。产线工装要有审计日志，记录每台设备的注入时间和操作员。
3.3 网关侧的验证逻辑与防重放窗口
网关侧要维护一个挑战值池，每个挑战值只能用一次，用过的立即失效。同时要记录每个设备ID最近一次认证的时间戳，如果同一个设备在极短时间内发起多次认证，要触发告警。
验证签名时要用常量时间比较，防止时序侧信道。虽然BLE场景下远程做时序攻击难度很大，但这是基本的安全习惯。另外，网关的随机数生成也要用TRNG或者高质量的CSPRNG，不能用语言自带的random函数。
防重放窗口我一般设成挑战值有效期30秒，超过30秒的响应直接拒绝。这样即使攻击者截获了挑战值和响应，也没法在有效期内重放，因为挑战值已经失效了。
4. 量产落地时那些文档不会告诉你的坑
4.1 TRNG初始化失败的静默降级问题
这是我在量产测试时遇到的最坑的问题。某批次设备在低温测试时，TRNG初始化偶尔会失败，但驱动代码里写的是"如果初始化失败就返回一个默认值"，结果设备继续用默认值生成随机数，认证照样通过，测试完全看不出来。
后来我在固件里加了强制检查：TRNG初始化失败必须让设备进入安全模式，拒绝任何认证请求，同时通过状态灯或者日志上报。安全模式下的设备只能返厂或者通过特定的恢复流程重新初始化。这个改动让产线良率掉了一点，但安全性有了保障。
提示：任何安全相关的初始化失败都不能静默降级，必须显式失败并上报。这是安全设计的基本原则，但在实际代码里经常被忽略。
4.2 认证超时与BLE连接参数的相互影响
BLE的连接参数会直接影响认证超时。如果连接间隔设得太大，比如500ms，三步交互可能要1.5秒以上。如果网关侧的挑战值有效期设成1秒，就会大量超时失败。
我的经验是，认证期间临时把连接间隔调小，比如20ms到50ms，认证完成后再协商回省电的参数。这样既保证了认证速度，又不影响日常功耗。具体参数要根据实际芯片和协议栈调，nRF52系列在20ms间隔下认证可以在200ms内完成。
另外要注意BLE的MTU。默认MTU是23字节，签名数据有64字节，需要分片传输。分片会增加交互次数和失败概率。建议在认证前先协商一个较大的MTU，比如247字节，这样签名可以一包发完。
4.3 密钥注入产线的防错与追溯
产线密钥注入最容易出的错是重复注入和错配。重复注入是指同一台设备被注入了两次密钥，后一次覆盖前一次，导致网关侧记录的密钥和实际不符。错配是指设备A的密钥被注入到了设备B上。
防错的做法是：注入前先读设备唯一ID，和工单比对，确认匹配后再注入。注入后立即回读校验，确认写入成功。每台设备的注入记录要上传到MES系统，和序列号绑定。如果后续发现某台设备认证失败，可以通过序列号追溯到注入记录，排查是注入问题还是设备问题。
我还会在产线加一道抽检：随机抽取若干台设备，实际跑一遍完整认证流程，确认端到端可用。抽检比例不用高，1%就够，但必须做，因为产线环境和实验室环境差异很大。
5. 功耗、成本与安全性的三角平衡
5.1 认证频率与电池寿命的量化关系
每次ECDSA签名在nRF52840上大概消耗几毫安时？实测下来，一次完整认证（包括TRNG采样、签名、BLE传输）大约消耗0.1到0.2毫安时。如果设备用CR2032纽扣电池，容量约220毫安时，理论上可以支持1000到2000次认证。
如果设备每天认证一次，电池可以撑三年左右。如果每小时认证一次，就只能撑几个月。所以认证频率要根据实际安全需求定。对于门锁，每次开锁认证一次是合理的。对于温度传感器，可以每天认证一次建立会话，之后用会话密钥加密上报，不用每次上报都重新认证。
5.2 低成本MCU上TRNG的替代方案评估
不是所有BLE芯片都带硬件TRNG。如果用的是低成本方案，比如某些国产BLE SoC，可能只有PRNG。这种情况下有几个选择：一是外挂一颗带TRNG的安全芯片，成本增加几毛钱；二是用多个熵源混合，比如ADC采样热噪声加时钟抖动，软件后处理；三是接受PRNG但缩短密钥有效期，定期更换。
我的建议是，如果产品涉及门锁、支付、医疗这类高安全场景，必须上硬件TRNG或者安全芯片，不要省这个钱。如果是普通传感器，数据敏感度不高，可以用混合熵源方案，但要在文档里明确说明安全等级，不要宣称"银行级安全"。
5.3 安全等级与产品定价的匹配策略
安全是有成本的。硬件TRNG加安全存储，BOM可能增加1到2块钱。对于售价几十块的产品，这个比例不小。所以产品定义阶段就要想清楚安全等级。
我的做法是分档：基础款用软件混合熵源加PRNG，满足基本防重放；标准款用硬件TRNG加Flash读保护，满足防克隆；高安全款用安全芯片加TRNG，满足防物理攻击。不同档位对应不同价格和目标市场，不要试图用一个方案打所有场景。
6. 从实验室到现场：认证系统的验证方法
6.1 用抓包工具验证认证报文的新鲜性
验证认证流程最直接的方法是用BLE抓包工具，比如nRF Sniffer或者Ellisys，抓取完整的认证交互。重点看两个地方：一是挑战值是否每次不同，二是签名数据是否随挑战值变化。
我一般会连续抓10次认证，把挑战值和签名导出来做对比。如果发现挑战值有重复，或者签名和挑战值的对应关系有规律，就说明随机数生成有问题。这个测试在实验室很容易做，但很多团队跳过，直接上量产，结果现场出问题。
6.2 模拟重放攻击的测试用例设计
重放测试要模拟攻击者截获一次认证报文后原样重发。具体做法是：抓取一次完整的挑战值和响应，然后在网关侧手动重发这个响应，看网关是否拒绝。如果网关接受了，说明防重放机制失效。
更严格的测试是修改挑战值的时间戳，看网关是否检查有效期。还可以测试挑战值复用：用同一个挑战值让终端签两次，看网关是否拒绝第二次。这些测试用例要写进测试计划，每次固件更新都跑一遍。
6.3 长期运行下的TRNG健康监测
TRNG不是一劳永逸的，长期运行可能出现熵下降。所以固件里要有周期性的健康检测，比如每天跑一次NIST的统计测试套件里的几个简单测试，确认随机数质量。
如果检测失败，设备要能上报。网关侧可以统计各设备的健康状态，发现异常设备及时处理。这个机制在实验室短期测试里看不出价值，但现场运行几个月后，能提前发现硬件老化或者环境异常导致的随机数问题。
7. 认证体系上线后的运维与迭代
7.1 密钥轮换的触发条件与操作流程
密钥不能永久不变。我的做法是设置密钥有效期，比如两年。到期前三个月，网关开始提示设备需要轮换密钥。轮换流程是：网关生成新密钥对，通过安全通道下发给终端，终端写入新的密钥槽，验证成功后切换到新密钥，旧密钥保留一段时间作为回退。
轮换过程中要保证设备不断线。我的实现是双密钥槽，新旧密钥并存，认证时优先用新密钥，失败则回退到旧密钥。等所有设备都切换完成后，再统一废弃旧密钥。
7.2 认证失败率的监控与根因分类
上线后要监控认证失败率。失败原因要分类：是超时、签名验证失败、还是挑战值过期。不同原因对应不同问题。超时可能是BLE连接参数问题，签名失败可能是密钥错配，挑战值过期可能是时钟同步问题。
我一般会在网关侧记录每次失败的详细原因，按设备型号和固件版本做聚合分析。如果某个型号的失败率突然上升，可能是那批设备出了问题，要及时排查。
7.3 固件升级时认证逻辑的兼容性处理
固件升级会改变认证逻辑，新旧版本要能共存。我的做法是认证协议带版本号，网关根据版本号选择对应的验证逻辑。新固件上线时，网关同时支持新旧两个版本，等所有设备升级完成后再下线旧版本。
升级过程中要特别注意：如果升级失败，设备要能回退到旧固件，并且旧固件的认证逻辑仍然有效。所以升级前要确保旧固件的密钥和认证状态没有被破坏。
8. 一些实际项目中的经验碎片
做这类项目久了，会积累一些零散但有用的经验。比如TRNG采样时如果同时开射频，可能会引入干扰，导致随机数质量下降，所以认证期间最好错开射频活动。又比如BLE的GATT写操作有确认机制，但通知没有，认证响应用通知发送时要注意丢包重传。
还有一点是关于调试接口的。产品出厂前一定要禁用或者锁定调试接口，但产线测试又需要调试。我的做法是产线用临时解锁，测试完成后立即锁定，锁定状态记录在OTP区域，不可逆。这样既保证了产线效率，又保证了出厂安全。
最后说一个关于文档的体会。安全设计文档不要写得太详细，尤其是密钥管理和TRNG后处理的细节，避免文档泄露导致攻击者按图索骥。但内部要有完整的实现记录，方便后续维护和审计。这个平衡点要根据团队和产品情况把握。
