你有没有见过这样一幕一辆停在地库的车车主站在几米外聊微信车门却在没有任何解锁动作的情况下被拉开几分钟后车被直接开走。监控显示两个嫌疑人一个贴身靠近车主另一个蹲在车旁没有撬锁、没有破窗全程只靠手里的一个小盒子。这就是蓝牙钥匙面临的最大威胁——防中继攻击Relay Attack圈内也叫“两道门”攻击。我研究这个方向有些年头了从最初的车企安全测试到后来给手机厂商做数字车钥匙方案累计的项目实践和现场测试不下几十次这里把从攻击原理到防护技术实践的完整链条梳理一遍。这篇文章适合三类人一是自己开带蓝牙钥匙/数字钥匙车辆的普通车主想知道怎么判断自己的车有没有防护二是做汽车电子、Tier1、手机厂商的软硬件工程师想了解UWB等防中继方案的落地细节三是对无线安全感兴趣的技术爱好者想搞明白为什么加密通信也挡不住中继。我会把原理讲透把防护技术掰开揉碎最后附上一份避坑经验清单。1. 中继攻击的真相不是破解密码而是“把门卫请到钥匙身边”1.1 中继攻击到底怎么发生的好多人一听“攻击”两个字下意识以为是要破解蓝牙配对、逆向协议、抓包解密。中继攻击完全不是这个路子。它的核心思路极简不破解任何东西只是把“钥匙在场”这个事实通过远程链路搬运到车辆旁边。具体拆开看经典的中继攻击分两条腿。攻击者A拿着一个信号转发装置站在真实车主附近攻击者B拿着另一个装置蹲在目标车辆旁边。A的装置捕获车主手机发出的蓝牙广播或连接请求信号通过无线链路常见的用Wi-Fi、4G、或者大功率对传模块把这串信号实时转发给B的装置B再把这串信号“播放”给车辆。车辆端看到的就是一把信号特征完全合法、距离似乎很近的钥匙。这个过程里蓝牙的加密、配对、鉴权全部正常完成。车辆认为钥匙在合法范围内于是执行了解锁、启动等指令。攻击者不是客人冒充主人而是把主人的声音原封不动地传到了门口门卫听到主人说“开门”自然就开了。这也是为什么很多车企在常规安全测试中能防住代码层面的入侵却对中继攻击束手无策——对手压根不走逻辑漏洞走的是物理信号的时间差。1.2 NFC中继攻击被低估的近场威胁这两年“NFC中继攻击”这个关键词频繁出现在安全圈它和蓝牙钥匙的威胁是同一家族只是载体不同。NFC近场通信的工作距离通常在几厘米以内大家默认“必须贴得很近才能刷”因此很多人认为天然安全。但中继攻击恰恰把“近”这个前提给废掉了。攻击者把一台NFC中继设备贴在目标手机或NFC卡片旁边另一台贴在车辆或门禁的读卡区上两台设备之间通过无线链路实时转发数据。对读卡器来说它感知到的是一场合法且符合条件的近场通信对手机或卡片来说它以为自己正在被一台合法读卡器访问。现象就是手机在主人家里楼下的车门却被刷开了。NFC中继攻击和蓝牙中继攻击的最大差异在于“作案半径”。蓝牙中继可以做到几十米甚至几百米因为BLE的射频覆盖本身就有几十米NFC则需要攻击者把设备贴近目标持有者对物理接近的要求更高但反过来NFC钥匙往往被车主当成“最保险的备用方式”警惕性更低。一些老款车型的NFC卡片钥匙没有做距离绑定、没有随机挑战或者时间戳校验一旦被中继后果和蓝牙钥匙被中继一模一样。1.3 现实中的攻击场景与黑色产业链中继攻击不是实验室里的概念它已经是现实中的高发作案手法。海外不少汽车被盗案件里监控能看到两个嫌疑人分别站在住宅门口和车辆旁边配合得像日常散步十几秒就能把车开走。一些高端车型即使配备了无钥匙进入系统也因为蓝牙钥匙的防中继能力不足而成为目标。国内也陆续有车主反馈钥匙放在家里车在楼下莫名被开走甚至出现了一夜之间多辆车被解锁的团伙作案。作案工具方面网上能买到的中继设备价格从几百到两三千元不等有的甚至直接打包成“汽车钥匙信号放大器”出售宣传语里带着“加强信号”“扩大遥控距离”这类话术。这类设备本质就是射频转发模块不涉及复杂的破解能力门槛低到让传统安全从业者很无奈。更麻烦的是中继攻击不会留下物理撬痕车辆本身的防盗记录也不会报异常因为所有鉴权都通过了取证相当困难。这也解释了为什么整车厂和手机厂商这两年把防中继攻击提到了非常高的优先级——不是在防御一种高端黑客技术而是在应对一条清晰、低成本、可复制的作案链路。2. 蓝牙钥匙为什么防不住中继技术根源拆解2.1 蓝牙协议本身无法证明“钥匙在现场”蓝牙钥匙的工作流大致是手机上的密钥通过BLE与车辆建立连接双方完成配对鉴权后通过服务端和特征值读写来下发解锁、闭锁、启动等指令。整个过程里蓝牙协议栈关注的是“这把钥匙是不是合法的”但它天然不关注“这把钥匙物理上在哪里”。严格说BLE也有“距离”概念比如RSSI信号强度指示但协议层面的距离只是一个估算值而且非常粗糙。汽车的无钥匙进入系统要决定“允许解锁”通常要求钥匙在车外1.5米到2米范围内要决定“允许启动”通常要求钥匙在车厢内。这个内外判定传统方案只能靠信号强度去猜。可BLE从设计之初就不是为厘米级测距准备的它连“钥匙在车里还是车外”都很难准确判断更别说防御一个主动在中间转发的攻击者了。还有一个致命细节蓝牙跳频。BLE在连接后会按照固定序列在多个信道上跳频通信但中继设备无所谓它只是把整个射频带上的信号原样透传或者实时解码重传跳到哪个信道都跟着走。加密和跳频这些常规防护手段对“搬运信号”这种思路完全无效。2.2 RSSI测距为什么靠不住不少早期防中继方案试图用RSSI阈值来卡“钥匙必须足够近”。这听起来合理但RSSI本身就是个很不稳定的物理量。蓝牙2.4GHz频段信号在空气中衰减极快而且受环境影响巨大金属车身会反射和遮挡、人体含水量高会吸收信号、地库的柱子、旁边停的车都会让同一把钥匙在同一个位置测出来不同的信号强度。我做过一组实测数据同一个手机放在车辆左前门把手外10厘米处RSSI在-35dBm到-55dBm之间抖动人往手机旁边一靠信号直接掉到-65dBm。而中继攻击者根本不关心你的RSSI是多少他可以把转发设备的发射功率调到很大让车端收到的信号强度超过正常钥匙近距离的数值。也就是说RSSI阈值只能防君子防不了小人——攻击者不仅不遵守规则还能反过来利用规则。更麻烦的是RSSI测出来的是“相对强度”不是“绝对距离”。两米外没有遮挡的手机信号可能比50厘米外被身体挡住还要强。靠RSSI去区分“钥匙在驾驶员口袋里”和“钥匙在车外两米的人手里”置信度低得可怜。这也是为什么纯软件方案始终走不到C位。2.3 攻击者的工具实时转发为何能穿透加密为了说清楚中继为什么能绕过加密得把攻击者的两种实现方式分开看。第一种是模拟直放也叫透明中继。攻击者不对信号做任何解码直接把2.4GHz频段射频信号变频放大后转发出去。车辆和手机之间的蓝牙通信对攻击者来说是一团“透明的空气”双方协商的加密密钥完全不经过攻击者的逻辑处理。这种方式实现简单、延迟极低但容易受到跳频序列和双向鉴权时序的影响对射频前端设计要求高。第二种是数字中继也是现在主流的高级手法。攻击者用两个BLE芯片分别模拟“手机侧”和“车辆侧”完整参与蓝牙连接过程。A端芯片与真实手机完成连接B端芯片与目标车辆完成连接两端的协议栈把双方的数据流转发互通。这种方式不再依赖射频放大的“蛮力”而是像一根数字化导管把真实钥匙卡的协议数据和真实车辆的协议请求对接起来。加密通信对这根导管透明因为解密和加密发生在两端的合法设备上。无论是哪种方式攻击者全程不触碰业务逻辑层的密码和密钥。蓝牙的AES加密、配对绑定这些机制防范的是“篡改”和“伪装”但中继攻击做的是“原样搬运”加密机制根本派不上用场。所以单纯依赖加密算法对抗中继是一条死路必须回到一个朴素的问题上如何证明钥匙就在车辆附近而且相隔时间没被拉长。3. 防护技术全景从软方案到UWB硬方案3.1 软件层防护延时挑战、随机数签名与行为识别既然加密挡不住搬运软件层能做的是让“搬运”这个动作在业务逻辑层面露馅。延时挑战是一种非常经典的思路。车辆端在鉴权过程中给钥匙下发一个时间敏感挑战比如要求钥匙在极短时间内基于当前时间片生成响应签名。攻击者的中继链路无论如何都会引入额外时延。如果这个延迟超出了正常物理传播几微秒就能完成的范围车辆端就判定“当前会话可疑”。BLE本身没有严格的时间戳约束但应用层可以在鉴权交互中人为增加这种时间约束。随机数签名是另一种基础但必要的设计。每次鉴权都生成一次性随机数车辆把随机数发给钥匙钥匙用内置私钥签名后返回。攻击者中继的是“当前这一次”的通信无法预录无法重放。这个机制虽然不能直接挡住中继中继本来就是实时转发不重放但它能封死录放类攻击是所有更强方案的地基。行为识别属于体验层面的辅助手段。手机上的加速度计、陀螺仪可以判断使用者是不是正在走向车辆甚至可以判断“手机是否被人拿着移动”。如果一个数字钥匙请求来自一台静止在沙发上的手机却被车辆端认为“钥匙兑现在车门边”这个矛盾就能触发风险风控。这类方法误报率偏高不适合作为唯一门槛但作为对抗“钥匙被放在桌上、攻击者拿到信号”的场景确实是有效补充。3.2 距离证明UWB如何用飞行时间终结中继真正让防中继攻击质变的是UWBUltra-Wideband超宽带技术。UWB和蓝牙最大区别在于它能做真正意义上的厘米级测距而且测的是物理量——电磁波飞行时间Time of FlightToF不是信号强度。原理不复杂。UWB设备发送极窄的脉冲信号带宽通常在500MHz以上时间分辨能力可以做到纳秒级甚至亚纳秒级。车辆发起测距钥匙回应车辆记录下从发出到接收的总时间扣除钥匙端的响应延时再除以2就得到单程距离。换算过来1纳秒大约对应0.3米UWB设备的时间分辨率足以把测距误差控制在±10厘米左右。这个精度意味着车辆可以明确区分“钥匙在车外1米”和“钥匙在车外50米”——中继攻击者无法把飞行时间变短因为光速是物理常数他唯一能做的是把信号复制一份再转出去而转发必然引入额外延迟。更重要的是UWB测距过程加入了STSScrambled Timestamp Sequence扰码时间戳序列机制。STS由双方协商的密钥动态生成测距帧带上无法预测的时间戳序列攻击者无法提前录制或者修改测距交互。结合随机挑战与签名UWB等于同时完成了“距离证明”和“实时性证明”。这也是为什么CCC数字钥匙标准从3.0开始明确把UWB当作防中继攻击的核心技术选项。需要说明的是UWB并不是蓝牙的替代品而是蓝牙钥匙的增强安全锚点。实际方案里BLE负责连接建立、业务指令和低功耗待机UWB专职负责安全测距和位置判定两者配合各干各擅长的事。3.3 多种方案组合的选型建议防中继不是一个单一技术能解决的业内普遍接受的思路是多层次叠加。我把常见方案按“安全强度”和“成本”两个维度做了一张对比表方便不同角色做选型参考方案安全强度成本典型场景局限性RSSI距离阈值低极低软件升级即可受环境影响大可被功率放大绕过延时挑战中低软件升级即可对高速数字中继无效需严格控制时序随机数签名鉴权中低所有数字钥匙的基础无法防实时中继必须配合距离证明行为识别/风控中中App侧辅助判断误报率高只能降低风险UWB ToF安全测距高高新车前装、手机数字钥匙需要UWB硬件和天线布局投入UWBBLE签名组合高高当前主流高端方案需要在体验和误报之间精细调参从我的实际项目经验看一款合格的数字钥匙方案最低配置应该是“随机数签名延时挑战可靠的RSSI粗判”能挡住大部分初级中继攻击要挡高级数字中继就必须上UWB安全测距要兼顾安全性和日常体验UWB必须和BLE、应用层风控配合而不是单打独斗。4. 实操落地车主、硬件与App开发者的防护实践4.1 车主自查你的蓝牙钥匙到底安不安全普通车主不需要懂UWB协议但可以用几个简单方法判断自己的车有没有防中继能力。第一看配置表。车辆支持数字钥匙且宣传中明确提到“UWB数字钥匙”或者“超宽带精确感应”说明至少有一颗UWB节点在负责测距。第二看解锁体验。支持UWB的车你拿着手机靠近基本不需要掏出手机走到门边就会自动解锁而且不会出现“站在门边却因为某个角度迟迟不解锁”的情况因为测距是三维空间内的不会像RSSI那样随姿态大幅跳动。第三查手机钱包里的钥匙详情。iOS和Android的数字钥匙页面通常有“超宽带”或“精确距离感应”相关说明如果只有“NFC”或“蓝牙”那防中继能力就要打个问号。如果你确认自己的车只有普通蓝牙钥匙日常有几个习惯能显著降低风险。一是不要把遥控钥匙、手机长期放在玄关或窗户边尤其是离车比较近的楼层二是购买一个实测有效的信号屏蔽袋把不常用的备用钥匙放进去但注意市面上一些便宜“法拉第袋”屏蔽效果参差不齐买回来可以用手机放进去拨个电话实测打不通才算合格三是尽量避免把数字钥匙授权给不熟悉的人因为中继攻击利用的就是“钥匙存在”这件事授权链路越复杂暴露面越大。4.2 UWB部署中的天线、阈值与盲区处理如果你是有车规项目在做的硬件工程师UWB的落地远比想象中复杂。UWB模块本身不难难的是天线布局和判定逻辑。UWB测距是直线传播最好的技术但对金属环境非常敏感。车辆全身都是金属钣金和玻璃UWB天线放在车门把手、B柱、后视镜、尾标这些位置周围都有大量反射体。我的经验是至少要在车身前、后、左、右各布置一颗UWB锚点才能形成基本的空间覆盖。只放一颗锚点会出现一个致命问题测距值准确但方向不明车头钥匙和车尾钥匙测出来可能是同一个距离内外判定就直接失效。多锚点可以交叉定位判断钥匙是在车外环绕还是在车内空间。阈值设定同样要花心思。直接把“测得距离小于2米就解锁”写进逻辑会带来大量误判。一是UWB在拐角、车尾阴影处会有多径误差测距可能出现抖动二是车内和车外边界场景非常多比如钥匙从车窗递进去、人站在车门边半个身子探进车内这时内外判定会反复横跳。建议的做法是引入“迟滞机制”——解锁和闭锁的触发阈值不一样解锁需要连续N次测距确认在范围内落锁需要连续M次确认在范围外避免在临界区间里反复切换。4.3 App侧防中继的代码细节与降级策略在手机端做数字钥匙App或SDK的开发者最容易踩的坑是“只接UWB回调不做业务风控”。UWB给出的是一连串距离值如何把这些数值转成“解锁、不解锁、降级处理”的业务决策才是关键。我建议流程上至少分三步先做基础校验会话合法性、签名校验、STS校验再做测距逻辑连续读若干个测距点过滤异常点取稳定值最后做业务决策结合BLE状态、手机传感器、是否解锁屏幕等上下文综合判断。下面是一个简化伪代码展示的是“距离值上下文风控”的判断思路fun onUwbDistanceUpdated(distance: Float, confidence: Float, context: CarContext) { // 1. 粗过滤距离跳变超过0.5米且无法稳定判定为干扰 if (!distanceFilter.addAndCheckStable(distance)) return // 2. 结合上下文时间窗口要求连续3帧有效且都在阈值内 val inRange distanceFilter.lastThreeFrames().all { it unlockThreshold } confidence MIN_CONFIDENCE // 3. 业务决策如果UWB异常降级为BLE用户主动确认 val canUnlock when { inRange context.isScreenOff context.phoneInPocket - UnlockDecision.ALLOW inRange context.hasUserGesture - UnlockDecision.ALLOW !inRange context.hasValidUwbSession - UnlockDecision.WAIT else - UnlockDecision.DEGRADE_TO_BLE_CONFIRM } unlockController.applyDecision(canUnlock) }降级策略特别值得强调。当UWB因为遮挡、干扰或者模块故障没有拿到有效测距时千万不能直接把“允许解锁”降级成“只要BLE连上就解锁”那等于把防中继能力降成零。更稳妥的做法是把权限降级——比如只允许开启后备箱、不能用手机启动车辆或者要求用户在App上做一次指纹/面容确认。安全永远不能因为功能缺失而自动放宽。5. 实测记录与常见问题排查5.1 常见问题速查表我在项目现场和车主反馈里收集了不少典型问题整理成速查表方便大家对照故障现象可能原因排查建议站在车门旁5秒仍不解锁UWB判定阈值过严或手机位置处于锚点盲区检查天线覆盖率调整解锁阈值确认锚点是否被金属遮挡车外自动解锁正常人坐进车内却提示“未检测到钥匙”车内UWB覆盖不足车门外的部分锚点信号无法穿透座椅在车内中控或后排区域增加锚点测试座椅金属骨架带来的衰减手机放左裤兜感应正常放右裤兜时性能下降明显人体对UWB信号的吸收衰减加上天线极化方向变化合理设计手机天线极化方式车内增加锚点数量补盲地库场景下车主经过时车门偶尔自动解锁多径反射信号导致测距跳变临界区迟滞不够增加连续帧确认要求扩大解锁/闭锁阈值间隔手机开启省电模式后UWB测距频繁失败UWB模块被系统调度降频或挂起App内对数字钥匙场景申请高优先级传感器访问引导用户关闭省电优化车辆长时间停放后第一次解锁延迟明显UWB锚点休眠唤醒流程慢BLE与UWB会话建立超时优化休眠策略预留预热时间避免首次连接即要求高精度测距5.2 实测心得与避坑清单防中继项目做得久了有几条踩出来的经验值得单列出来。第一永远不要在主逻辑里只用RSSI。哪怕时间紧、成本压得低RSSI只配做辅助粗判。早期我们做过一个阶段用RSSI配合延挑战来防中继结果在机场停车场这种强反射环境下同一把钥匙的信号强度能飘出8米误差测试现场直接翻车。后来加入UWB做精确判定RSSI只负责“提前唤醒”UWB模块效果才稳定下来。第二中继攻击模拟测试要合法合规。想验证自己方案的防中继能力最好在自有车辆、自有钥匙、自建测试环境下进行不要拿别人车辆做测试更不要购买和使用不明来源的工具。正规的做法是找安全测试机构或者整车厂的安全测试团队在他们的认证实验场地里租借设备做验证。第三别把“UWB能防中继”当成万能解。UWB解决的是距离证明但如果业务流程里允许绕过UWB做免密解锁比如某种“快速解锁”开关或者“靠近自动解锁”的功能攻击者只要找到这个后门通道照样能突破。防中继是一个整体设计任何一条可被绕过的路径都等于把高成本的安全锚点白白浪费掉。第四误报控制比漏报控制更考验工程能力。中继攻击是低频事件而用户在车门口站着不解锁是高频事件。一个方案如果在安全上做到100分但让用户每天在车边罚站10秒用户很快就会把数字钥匙功能关掉转而用实体钥匙安全能力等于名存实亡。所以在阈值调优时我会格外关注“行走过程中经过车门不解锁”和“停住后快速解锁”这两种场景的区分。6. 车主日常防护与开发者的下一步动作对普通车主来说我的建议很具体如果你的车支持UWB数字钥匙正常用不用过度焦虑如果你的车只有普通蓝牙钥匙平时把备用钥匙放信号屏蔽袋手机端不常用的钥匙授权定期清理家里离车近的话玄关不要随手放钥匙。这些习惯不需要花什么钱但确实能挡住八成利用“感应钥匙在附近”的偷车场景。对正在做数字钥匙方案的开发者下一步最值得投入的方向是把UWB从“解锁功能”升级成“全程信任锚点”。比如启动车辆时也要求UWB判断钥匙在主驾驶位停车场记忆泊车时要求UWB验证车主在车边这些场景都能复用同一套安全测距能力摊薄硬件成本。同时别忘了NFC作为备用钥匙通道也要做中继检测至少要加签名挑战别让NFC成为整个系统里最薄弱的那个环节。我自己在实际测试里的一个体会是防中继攻击这件事技术难点其实排在工程调度后面。UWB的原理很清晰难的是让它在车规级环境里持续稳定工作难的是在误报和漏报之间找一个让用户无感的平衡点。这个方向还会持续演进但至少现在从原理到实践的路已经走通了。