1. 凌晨三点车被开走中继攻击到底“中继”了什么1.1 一个让多少车主误判的案发场景先讲一个我在安全评估中反复看到的典型案例车主的蓝牙钥匙放在客厅餐桌上车辆就停在单元门口门窗完好、监控里只有两个戴着帽子的陌生人靠近车辆几十秒后车灯亮起车辆被直接开走。车主的第一反应通常都是“钥匙是不是被复制了”“是不是电子系统出故障了”甚至有人怀疑是4S店后台操作。实际上这类案件在无钥匙进入系统普及之后的几年里已经在不少城市出现过核心原因几乎都是同一个中继攻击Relay Attack。中继攻击这个名字听起来很技术但理解起来并不难。简单说攻击者根本没有破解蓝牙钥匙的任何密码也没有复制芯片他们只是把“钥匙在车旁边”这个事实远程搬到了车辆传感器面前。这个攻击对传统加密通信几乎是降维打击因为整套鉴权流程都是真实且合法的车端的每一句指令都得到了正确应答。所以这篇文章我打算把中继攻击的原理、为什么传统方案防不住、当前主流的防中继技术以及产品落地时的实测经验完整梳理一遍给正在做数字钥匙、蓝牙钥匙、车联网安全的工程师一个可以直接参考的完整思路。1.2 从钥匙到车辆信号被“接力”的完整链路要理解中继攻击先看一遍正常的蓝牙钥匙开锁流程。车主靠近车辆时车上的BLE模块持续广播或者等待连接钥匙端实体钥匙、手机NFC/蓝牙模拟、手表检测到车辆的广播信号后发起连接双方完成配对、鉴权、密钥协商然后执行双向认证。认证通过后系统确认“合法钥匙在有效范围内”于是执行解锁、上电、允许启动等动作。中继攻击在这个链条里插入的不是破解而是“搬运”。攻击者通常有两个人配合一个人拿着设备A站在车辆旁边另一个人拿着设备B贴近车主身上的真钥匙。设备B会伪装成车辆向真钥匙发起连接请求设备A则会伪装成钥匙向车辆发起连接请求。A和B之间通过WiFi、4G/5G甚至另一路蓝牙保持实时数据转发。于是真钥匙的每一次应答都被B实时传给了AA再原封不动地转交给车辆车辆发出的每一次挑战也被A传给了BB再转交给真钥匙。整条链路里车辆和钥匙都以为自己在和彼此通信实际上中间隔了两台转发设备。可以用一个更生活化的比喻来理解你家门口的门卫只认暗号。钥匙在家里的屋里攻击者甲站在门卫旁边攻击者乙站在你家窗户底下。乙问屋里的钥匙“今天的暗号是什么”钥匙回答了乙把答案告诉甲甲再对着门卫喊一遍。门卫听到暗号正确就开门了。整个过程里门卫没被骗去破解什么钥匙也没发现异常密码还是那个密码只是传递路径被人为拉长了。这条中继链路可以做到多远只要A和B之间的回程链路足够稳定跨城市把车开走理论上都做得到实际案件中几十米到几百米最常见。1.3 加密与滚动码为什么在这类攻击面前形同虚设很多做嵌入式安全的同行第一次接触中继攻击时都会有一个疑问我们用了AES-128加密密钥协商、滚动码、随机挑战防重放都做了中继攻击怎么可能绕得过去这个问题本身就是理解中继攻击的关键。加密、滚动码、挑战应答机制防护的对象是“伪造身份”和“重放旧数据”。攻击者如果想把一段录制好的开锁报文重放一次滚动码能让这段报文失效攻击者如果伪造一把假钥匙密钥协商能阻止它通过认证。但中继攻击从头到尾没有伪造任何东西没有重放任何旧数据。它做的只是把合法的密钥应答实时转发车辆收到的是一个正在实时响应挑战的合法钥匙这在协议层面完全无法被识别。换句话说传统安全机制验证的是“你知不知道密码”而中继攻击根本不需要知道密码它只需要让知道密码的那把钥匙“在线”。这也是为什么我一直跟团队强调无钥匙进入系统的安全模型不能只停留在“验证身份”层面必须加上“验证位置”。而验证位置这件事恰恰是传统蓝牙协议栈最不擅长的事。后面这几个章节我就把从信号强度门控到超宽带测距的演进路线以及每条路线的实际效果和坑逐一拆开讲。另外提一句NFC中继攻击最近讨论很多本质上和蓝牙钥匙中继攻击是同一类问题近场凭证被远程搬移这一节末我会专门放在一起分析。2. 防不住的根本原因一直验证的是“有没有”而不是“有多远”2.1 传统防入侵模型的盲区在哪里传统无钥匙进入系统的安全假设是攻击者无法同时满足“拥有合法密钥”和“物理接近车辆”这两个条件。只要加密足够强伪造钥匙足够难那么能通过认证的大概率就是车主本人站在车边。中继攻击恰恰把这条安全假设撕开了一个口子。攻击者不需要自己拥有合法密钥他借用了目标车主的真钥匙也不需要真的接近钥匙他让人把信号引到了钥匙旁边。于是“物理接近”这个条件被击穿了。这时候如果系统没有任何距离验证手段就会无条件放行。所以业界后来的共识非常明确身份认证只能说明“钥匙是真的”距离验证才能说明“钥匙真的在这里”两者必须同时成立。2.2 RSSI信号强度门控防线确实加过但漏洞明显最早被广泛采用的“距离”判断方案是测量接收信号强度指示RSSI。思路很直接信号强度会随距离衰减车端收到钥匙的信号如果太弱说明钥匙离得远就拒绝解锁。于是很多早期产品在BLE模块里设了一个简单门控RSSI低于某个阈值就直接丢弃连接请求。这个方法在空旷场地、理想方向上确实有效但拿到真实环境里问题不少。RSSI受太多因素影响发射功率、天线方向、人体对信号的吸收、金属车身的反射、地面和墙壁的多径效应都会让同样距离下测到的信号强度差出二三十dB。说个我们实测中遇到的例子钥匙拿在手里站在车侧B柱位置和钥匙放在外套内侧口袋里站在同样位置RSSI可能差8到12dB钥匙在二楼阳台上车辆在楼下正门口因为隔着阳台玻璃和金属梁RSSI反而可能比在车旁还高。多径效应尤其麻烦信号经过窗户反射、地面反弹之后叠加起来会让近处出现“弱信号”远处反而出现“强信号”完全没法用作精确边界。更致命的是RSSI是可以被攻击者反向利用的。中继设备只要使用高增益定向天线完全可以把远端转发过来的信号以相当大的功率注入车端接收机让车端测得的RSSI比真实钥匙在1米内的读数还漂亮。所以RSSI门控从来只能作为最低一档的辅助校验从来没有人敢把它当成真正的安全边界。2.3 响应时间测量原理上成立工程上难以落地既然RSSI不靠谱第二个自然想到的方案是测时间。逻辑也很直观如果钥匙离车只有1米那么从车辆发出挑战到收到应答物理传播时间只有大约3.3纳秒。如果测量到的往返时间明显超出合理范围说明钥匙根本不在附近。这个思路本身没有错问题出在当前蓝牙协议栈的延迟特性上。BLE芯片从收到数据到应用层处理、再到从空中接口发回响应中间要经过MAC层调度、协议栈排队、CPU调度、射频收发切换这部分延迟通常有几毫秒到几十毫秒的随机抖动远大于光速传播那几纳秒的分辨率。哪怕做多包往返求平均也很难把噪声收敛到足够小。简单算一笔账光速是每秒30万公里1纳秒对应约30厘米。要做0.5米的距离判定就需要约1.7纳秒的时间分辨率而BLE协议栈的毫秒级抖动对应的距离模糊度是百公里量级根本没有可比性。所以后来产业界达成的共识是要在物理层做高精度测距必须换一套更合适的通信技术带宽和计时机制这就是UWB能站上舞台的根本原因。3. 防护技术的新地基超宽带UWB如何把“距离”变成安全凭证3.1 为什么选UWB而不选蓝牙5.1测向蓝牙5.1加入了到达角AoA和离开角AoD测向能力一度让不少人认为可以用蓝牙完成定位和距离判断。但实际工程落地时你会发现单纯靠BLE的测向误差非常大。BLE信道带宽只有2MHz时间分辨率太差基于相位差的测角在反射严重、天线遮挡的场景下会剧烈漂移最终的定位精度通常只能做到几米甚至十几米。这个精度用来做“室内导航到哪个展柜”可以用来判断“车钥匙是不是在2米以内”就不够了。安全判定需要的不是“大概在附近”而是能以厘米级误差回答“到底在不在这一平方米”。UWB超宽带不一样。它使用3.1GHz到10.6GHz之间的超宽频谱单个脉冲带宽可达500MHz以上时域上非常窄时间分辨率能做到纳秒甚至亚纳秒级别。1纳秒对应30厘米亚纳秒就对应几厘米。同时UWB脉冲的抗多径能力比BLE强很多这让它在车辆周边这种复杂反射环境里依然能给出稳定测距结果。数字钥匙领域最激进的做法就是把UWB作为安全测距的硬件底座通过双向测距实现对钥匙真实物理位置的厘米级测量。下面这张表能清楚地看出几类方案在安全边界中的定位差异技术路径原理典型精度抗中继能力工程复杂度BLE RSSI门控信号强度与距离的近似关系波动大弱可被高增益天线欺骗低BLE 5.1 AoA测向天线阵相位差米级中反射环境下不稳定中响应时间测量挑战应答往返时间协议栈抖动过大难以落地中UWB双向测距物理层脉冲飞行时间厘米级强物理层加密抗欺骗高3.2 双向测距与STS扰码中继攻击为什么在这里被卡住UWB防中继的核心机制是双向测距再加上物理层的安全时间戳序列。先说双向测距的过程。简单看车端锚点A和钥匙端K之间交互两个报文K发送Poll帧并记录发送时间t1A收到后记录t2并回复Response帧且记录发送时间t3K收到Response帧后记录t4。这样K就拿到了两个关键量总往返时间t4 - t1和A的处理时延t3 - t2于是单程飞行时间就是二者之差的一半距离 ((t4 - t1) - (t3 - t2)) × 光速 / 2举个例子如果t4 - t1 100纳秒t3 - t2 60纳秒那么飞行时间就是20纳秒对应距离约3米。实际工程中更常用的DS-TWR会做两轮交互让时钟漂移误差进一步抵消这里不展开公式推导但你需要记住一个结论UWB测得的距离来自物理脉冲的真实飞行时间不是算法推断出来的强度或相位这条物理链路很难被伪造。真正让UWB具备抗中继能力的是IEEE 802.15.4z协议里定义的STS机制。STS是一串由合法双方共享密钥通过密码学方式生成的扰码时间戳序列它被直接用物理层脉冲发送出去接收方只有在正确掌握了密钥的情况下才能识别并验证这串序列。更关键的是STS序列在发送时和精确时间绑定接收方会同时验证序列的正确性和到达时间的合法性。中继设备如果想在中间“截住”一个合法的UWB测距帧再转发到另一个地方不仅要做到纳秒级转发否则时间延迟会暴露还要能实时处理STS序列的加密验证。这两点同时成立在工程上几乎是不可能的。这也是为什么业内普遍认为基于802.15.4z的UWB测距是目前抵抗中继攻击最可靠的一层物理基础。3.3 车载锚点布局与钥匙端实现从芯片到系统落地并不简单原理成立落地才是硬骨头。一个典型的UWB数字钥匙系统车内和车身周围会布置4到6个UWB锚点。为什么不是两个因为安全判定需要区分“车外还是车内”“主驾门还是副驾门”“车顶还是车底”。比如钥匙在车顶上方时UWB测距可能显示距离只有1米多但车辆不应开锁这就需要多锚点联合定位来识别空间位置。通常的做法是前排和后排分别布置锚点外加左右后视镜或B柱位置各一个通过多个锚点对同一钥匙的测距结果做三边定位解出钥匙的三维坐标再判断它是否落在“允许解锁区域”内。锚点之间还需要做到时间同步。如果每个锚点各自用独立晶振计时晶振偏差会在毫秒级同步误差上积累出数十厘米的测距偏差所以工程上要么用有线同步信号把各锚点拉齐要么在每轮测距前先做一次锚点间的无线测距校准。钥匙端的问题更多。独立UWB钥匙相对简单做好天线布局和功耗控制就行手机数字钥匙则需要考虑天线在手机里的位置、手机壳对信号的衰减、后台进程对UWB会话的挂起。我在项目里不止一次遇到iPhone和安卓旗舰机在同一个锚点下测距结果差半米的情况最终排查下来都是手机内天线方向图和系统UWB调度策略的差异导致的。CCC数字钥匙规范里把UWB作为关键启用技术之后整个产业链都在往这个方向收敛。现在已经很少见到只靠BLE做安全测距的新车型了基本都是BLE负责低功耗连接与唤醒、UWB负责安全测距与位置判定、NFC作为完全断电或紧急场景下的备份通路。后面这一节我要讲的正是这套组合怎么在软件算法层面兜住安全底牌以及它和NFC中继攻击之间的联动思考。4. 不止于测距多因子融合判定与NFC中继攻击的一体化思考4.1 角度、运动传感器与信道指纹各自补什么短板即便有了厘米级UWB测距单看距离仍然不够安全。举个例子钥匙放在二楼卧室车辆停在楼下门口UWB测距可能给出1.5米的结果但真实空间位置是“楼上”而不是“车旁”。这时候需要到达角AoA来补充方向信息。UWB锚点如果配备小型天线阵列就能估计出信号到达的方位角和俯仰角。测距结果加上角度约束之后系统可以把第二层判定条件设为“距离小于2米且角度落在车辆可解锁扇区内”楼上钥匙自然就被拦下了。运动传感器扮演的角色容易被忽略它更多是为了减少误判而不是直接防攻击。车钥匙里的人体存在传感器、加速度计和陀螺仪可以判断钥匙是否处于随身携带的移动状态。如果系统检测到钥匙静止放在桌上而车端却收到了“钥匙在车旁”的解锁请求这种场景本身就可疑。反过来用户正常走向车辆时钥匙的加速度变化和车辆位置会呈现规律性的关系这个动态信息可以用来提高真实解锁请求的置信度。信道脉冲响应CIR指纹则是更前沿的做法UWB脉冲在每次传输时会携带环境反射特征这个特征对特定的车辆内部空间来说是相对稳定的“签名”。把实时CIR和车辆出厂时建模的基准CIR比对攻击者要在中继的同时伪造信道特征难度又高了一个数量级。4.2 多因子可信度评分与阈值标定多因子融合并不是简单地把每个条件的通过与否做“与”运算因为每个传感器都有可能误判。更实用的做法是给每个因子打分最后看总分是否超过解锁阈值。下面这一小段伪代码体现的是我在项目里常用的一种简化的评分思路float score 0.0f; // 距离因子UWB测距结果越近分越高 if (uwb_distance 1.5f) score 50.0f; else if (uwb_distance 3.0f) score 25.0f; else if (uwb_distance 5.0f) score 5.0f; // 角度因子到达角是否落在合理扇区 if (aoa_azimuth_error 30.0f aoa_elevation_error 20.0f) score 20.0f; // 运动因子钥匙处于移动状态说明大概率被人随身携带 if (key_motion_active) score 15.0f; // 信道指纹因子CIR相似度 if (cir_similarity 0.85f) score 15.0f; bool allow_unlock (score 80.0f);这个模型故意做了线性简化实际产品还会考虑时间窗口、触发历史和车辆状态但核心思想是一样的任何一个因子单独异常都不至于致命多个因子同时被攻击者欺骗的概率则会显著下降。阈值的标定要平衡两个指标误纳率FAR把攻击者放进来和误拒率FRR把车主挡在门外。对车辆解锁这种场景我的经验是把FAR压到极低宁可偶尔让车主多按一下门把手也不能给攻击者可乘之机。标定过程需要大量采集不同身高、不同穿搭、不同手机型号、不同停车环境的真实数据把数据按位置和动作打标再去做阈值搜索。这里没有捷径只能靠数据积累。4.3 NFC中继攻击与近场安全的一体化思考最近“NFC中继攻击”这个词被频繁提起来原因很简单当门禁卡、手机NFC模拟卡、NFC数字钥匙越用越普遍时NFC“必须贴得很近才有效”这个特性本身成了一种安全假设。攻击者利用专门设备贴近用户的卡或手机把NFC信号变成更远程的无线信号传回入口处就等于把卡“透明化”地带进了门禁范围。这和蓝牙钥匙中继攻击在攻击范式上是同一类近场凭证的位置约束被远程通信链路打破。但在工程防护上NFC的处境更麻烦。因为NFC本身是为极近距离设计的技术没有内置UWB那样高精度的物理层测距能力所以你很难在NFC协议层去验证“这张卡是不是真的贴在了读卡器上”。当前数字钥匙系统里的处理策略普遍是把NFC定位为“降级恢复通道”只在手机没电、UWB失效等特殊条件下使用并且NFC开锁时要求用户进行额外的生物识别验证或者限制单次有效期。如果你正在设计门禁或数字钥匙系统我强烈建议不要在NFC链路上追求“最强的防中继”而是把NFC的使用场景收窄让它本身就不具备“只看一次NFC就放行”的能力这种设计思路比在协议层死磕更可靠。5. 产品化落地中的实测与踩坑记录5.1 从Demo到量产天线方向图畸变与温度漂移谁动过我的厘米级精度很多团队在开发板上做的UWB测距效果很好标称误差正负10厘米但装到真实车辆上之后发现精度明显下降。我们做过一次对比测试同一个锚点在实验室环境测距误差稳定在8厘米左右装到车辆B柱位置后误差跳到了30到40厘米部分角度甚至接近半米。排查下来问题主要出在金属车身边缘对天线方向图的畸变以及车窗玻璃、座椅皮革对多径反射条件的改变。天线设计在自由空间里的方向图是圆的装到车门夹层里就变成了起伏不平的形状天线增益在某些角度被压掉测距结果自然跟着漂。温度漂移是另一个容易被忽略的坑。UWB模块的晶振频率会随温度变化产生几十ppm量级的偏移这会让双向测距里的时间测量产生系统性误差。我们在高低温箱里测过常温下误差约正负15厘米把环境温度拉到零下20度或65度时误差能飙到正负40厘米以上。如果不做补偿冬天和夏天用户会明显感觉到解锁距离不一样。解决思路分两部分产线阶段给每台车做一次静态校准把每个锚点的天线相位延迟、天线延迟标定到位运行阶段在软件里维护一张温度补偿系数表根据模块实时温度对测距结果做一次修正。走完这两步我们最终把高低温下的误差压回到了正负20厘米以内。5.2 误拒与误纳的博弈安全优先还是体验优先中继攻击防护做太严最常见的后果是车主站在车边等了好几秒车门不解锁做太松攻击者半个身子探过来车门就开了。这个度非常难拿捏。我比较推荐的策略是“动态安全等级”而不是一个固定阈值。具体做法是区分几个场景车辆处于驻车锁定状态时安全等级最高解锁必须满足完整的距离、角度、运动因子校验用户正在拉门把手或者车内有人已经上电时可以适当放宽一些触发条件缩短响应时间车辆处于行驶状态时钥匙是否在车内用UWB做一次区间判定就够了不需要每次都做全链路多因子认证。另一个实测中经常踩的坑是很多工程师只调阈值不调场景最后用户频繁误触。比如用户只是路过车辆并不想解锁但系统因为“距离够近”就开了锁。后来我们加入了一个动作触发逻辑检测到用户的手靠近门把手、或者用户身体从远处朝车辆方向移动超过一定距离后再开始执行UWB多因子判定。这样既没有牺牲安全性也大幅度降低了无意义的误解锁。5.3 防中继攻击能力的实测验证方法安全功能上线之前一定要做针对性的攻防验证不能只在实验室里跑几个测距用例就宣布完成。我的团队现在每轮固件迭代都会做一套固定的测试矩阵这里列出来供你参考测试场景预期行为测试要点钥匙在1米内正常靠近解锁成功确认车主正常使用不受影响钥匙在10米外不解锁确认距离边界可靠钥匙在楼上车辆在楼下不解锁多锚点联合定位排除Z轴误判中继设备贴近真钥匙与车辆拒绝解锁验证UWB测距链路是否确认被拉长手机在包内、天线下压场景解锁成功率低于不压天线记录异常数据用于算法修正高低温环境下的测距精度误差保持在标定范围内验证温度补偿表是否生效测试工具方面我们不会去折腾攻击者使用的“黑盒”设备而是用标准的射频转发模块配合可调衰减器来模拟不同距离和不同时延下的中继条件。具体做法是把锚点和钥匙端分别放入两个屏蔽箱中间用一根可调衰减的同轴链路连接通过调节衰减量模拟“钥匙越来越远”再在中继链路上人为注入额外时延检验车端是否仍然能识别出距离异常。这样做既安全又复现性好测试结果能稳定反映系统对中继链路的容忍极限。我们在一款量产车型上做过的对比数据很有说服力仅开启BLE连接和身份认证时用中继设备把钥匙信号引到车边车辆开门成功率高到令人不安开启UWB测距且完成多因子融合判定后同样条件下车辆拒绝解锁的成功率提升到了99%以上剩下不到1%的场景是因为中继设备把原本的UWB测距帧完整捕获后做了极端低时延转发但这部分已经低于普通物理防线的风险水平需要在后续版本里结合信道指纹继续收敛。5.4 日志数据是安全迭代最值钱的资产最后分享一个经常被忽略但回报极高的习惯把所有防中继判定相关的原始数据完整记录到日志里。每次解锁被拒绝不要只记一行“unlock denied”把UWB测距值、到达角误差、CIR相似度、运动传感器数据、RSSI值、模块温度、天线路径信息全部落盘。这些数据在车辆回传后可以用于持续优化融合算法也能在出现真实攻击事件后辅助事后溯源。我们有一次接到用户投诉“车门突然解不开”排查了半天都无法复现后来就是靠日志里一条温度极高加上CIR相似度异常的记录发现是车辆停在高温暴晒场地后UWB模块出现了微小频率偏移进而补上了对应的补偿逻辑。安全功能不像一个普通业务功能它很难通过“看起来能用”来判断好坏。中继攻击的本质决定了防线必须建立在物理层面的真实测量之上而这条防线的每一处参数都需要真实数据来打磨。这也是为什么我一直认为防中继攻击的落地不是选一个UWB芯片就结束而是硬件、算法、标定、攻防测试、日志分析共同构成的系统工程。