你有没有见过这样一幕：一辆停在地库的车，车主站在几米外聊微信，车门却在没有任何解锁动作的情况下被拉开，几分钟后车被直接开走。监控显示，两个嫌疑人一个贴身靠近车主，另一个蹲在车旁，没有撬锁、没有破窗，全程只靠手里的一个小盒子。这就是蓝牙钥匙面临的最大威胁——防中继攻击（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如何用飞行时间终结中继

真正让防中继攻击质变的，是UWB（Ultra-Wideband，超宽带）技术。UWB和蓝牙最大区别在于，它能做真正意义上的厘米级测距，而且测的是物理量——电磁波飞行时间（Time of Flight，ToF），不是信号强度。

原理不复杂。UWB设备发送极窄的脉冲信号，带宽通常在500MHz以上，时间分辨能力可以做到纳秒级甚至亚纳秒级。车辆发起测距，钥匙回应，车辆记录下从发出到接收的总时间，扣除钥匙端的响应延时，再除以2，就得到单程距离。换算过来，1纳秒大约对应0.3米，UWB设备的时间分辨率足以把测距误差控制在±10厘米左右。这个精度意味着车辆可以明确区分“钥匙在车外1米”和“钥匙在车外50米”——中继攻击者无法把飞行时间变短，因为光速是物理常数，他唯一能做的是把信号复制一份再转出去，而转发必然引入额外延迟。

更重要的是，UWB测距过程加入了STS（Scrambled Timestamp Sequence，扰码时间戳序列）机制。STS由双方协商的密钥动态生成，测距帧带上无法预测的时间戳序列，攻击者无法提前录制或者修改测距交互。结合随机挑战与签名，UWB等于同时完成了“距离证明”和“实时性证明”。这也是为什么CCC数字钥匙标准从3.0开始，明确把UWB当作防中继攻击的核心技术选项。

需要说明的是，UWB并不是蓝牙的替代品，而是蓝牙钥匙的增强安全锚点。实际方案里，BLE负责连接建立、业务指令和低功耗待机，UWB专职负责安全测距和位置判定，两者配合，各干各擅长的事。

3.3 多种方案组合的选型建议

防中继不是一个单一技术能解决的，业内普遍接受的思路是多层次叠加。

我把常见方案按“安全强度”和“成本”两个维度做了一张对比表，方便不同角色做选型参考：

从我的实际项目经验看，一款合格的数字钥匙方案，最低配置应该是“随机数签名+延时挑战+可靠的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.2 实测心得与避坑清单

防中继项目做得久了，有几条踩出来的经验值得单列出来。

第一，永远不要在主逻辑里只用RSSI。哪怕时间紧、成本压得低，RSSI只配做辅助粗判。早期我们做过一个阶段，用RSSI配合延挑战来防中继，结果在机场停车场这种强反射环境下，同一把钥匙的信号强度能飘出8米误差，测试现场直接翻车。后来加入UWB做精确判定，RSSI只负责“提前唤醒”UWB模块，效果才稳定下来。

第二，中继攻击模拟测试要合法合规。想验证自己方案的防中继能力，最好在自有车辆、自有钥匙、自建测试环境下进行，不要拿别人车辆做测试，更不要购买和使用不明来源的工具。正规的做法是找安全测试机构或者整车厂的安全测试团队，在他们的认证实验场地里租借设备做验证。

第三，别把“UWB能防中继”当成万能解。UWB解决的是距离证明，但如果业务流程里允许绕过UWB做免密解锁，比如某种“快速解锁”开关或者“靠近自动解锁”的功能，攻击者只要找到这个后门通道，照样能突破。防中继是一个整体设计，任何一条可被绕过的路径都等于把高成本的安全锚点白白浪费掉。

第四，误报控制比漏报控制更考验工程能力。中继攻击是低频事件，而用户在车门口站着不解锁是高频事件。一个方案如果在安全上做到100分但让用户每天在车边罚站10秒，用户很快就会把数字钥匙功能关掉，转而用实体钥匙，安全能力等于名存实亡。所以在阈值调优时，我会格外关注“行走过程中经过车门不解锁”和“停住后快速解锁”这两种场景的区分。

6. 车主日常防护与开发者的下一步动作

对普通车主来说，我的建议很具体：如果你的车支持UWB数字钥匙，正常用，不用过度焦虑；如果你的车只有普通蓝牙钥匙，平时把备用钥匙放信号屏蔽袋，手机端不常用的钥匙授权定期清理，家里离车近的话玄关不要随手放钥匙。这些习惯不需要花什么钱，但确实能挡住八成利用“感应钥匙在附近”的偷车场景。

对正在做数字钥匙方案的开发者，下一步最值得投入的方向是把UWB从“解锁功能”升级成“全程信任锚点”。比如启动车辆时也要求UWB判断钥匙在主驾驶位，停车场记忆泊车时要求UWB验证车主在车边，这些场景都能复用同一套安全测距能力，摊薄硬件成本。同时别忘了，NFC作为备用钥匙通道也要做中继检测，至少要加签名挑战，别让NFC成为整个系统里最薄弱的那个环节。

我自己在实际测试里的一个体会是，防中继攻击这件事，技术难点其实排在工程调度后面。UWB的原理很清晰，难的是让它在车规级环境里持续稳定工作，难的是在误报和漏报之间找一个让用户无感的平衡点。这个方向还会持续演进，但至少现在，从原理到实践的路已经走通了。