一、一个中继盒，30米距离，10秒开走一辆车
先看一组真实数据。2025年8月，英国某保险公司的一则报告引起了不少人的注意：2024年全年，通过中继攻击被盗的车辆数量比前一年增长了37%，平均每起盗窃用时不到60秒。攻击方式其实并不复杂——两个几百元的中继设备，一个在车主家门口捕捉钥匙信号，另一个在车门旁接收转发。车机以为钥匙就在身边，解锁、启动一气呵成。
说起来，这当然不是数字钥匙本身的新问题。但真正让人警惕的是另一个现象：不少已经搭载了UWB数字钥匙的车型，理论上应该是中继攻击的终结者才对——UWB通过飞行时间测距，能精确判断钥匙的真实距离。然而实测发现，部分车型的UWB实现仅仅把测距结果当作“辅助参考”，并没有真正绑定到安全决策逻辑中。攻击者绕过UWB，降级攻击BLE，车机照样开门。
更值得玩味的是，CCC（车联网联盟）的Digital Key 3.0规范早已明确要求UWB测距结果必须作为安全决策的强制输入。从规范发布到量产落地之间，中间隔着多少“实现细节”，安全水平就在这短短的距离里被一点点消耗掉了。
二、数字钥匙的“三重防护”与“三重突破”
2.1 主流数字钥匙技术栈
CCC Digital Key规范经历了三代演进，从技术路线来看，每个版本的安全锚点都不一样：
| 版本 | 通信技术 | 安全锚点 | 定位精度 | 主要威胁 |
|---|---|---|---|---|
| DK 1.0 | NFC | SE (Secure Element) | 厘米级（接触） | 物理窃取 |
| DK 2.0 | NFC + BLE | SE + 应用层加密 | 米级 | BLE中继攻击 |
| DK 3.0 | NFC + BLE + UWB | SE + UWB ToF测距 | 10cm级 | 降级攻击 + UWB测距欺骗 |
DK 3.0的核心理念是三层防御体系：
- NFC：作为终极备用通道，手机没电也能用。通信距离小于10cm，天然防远程中继。
- BLE：负责设备发现和连接建立，通信距离10-30米，也是中继攻击的主要入口。
- UWB：负责精确测距和活体检测，通过ToF计算钥匙真实距离，是这一版规范的核心升级。
2.2 攻击者如何突破三层防线
攻击手法1：BLE中继攻击（经典，但仍然有效）
攻击链路并不复杂：
车主手机（在家） ←→ 中继设备A ←→ 中继设备B ←→ 车辆 (BLE)(4G/WiFi) (BLE)
中继设备的延迟通常不到10毫秒，而BLE协议本身不做距离检测，车机根本无法区分信号来自1米还是30米。
攻击手法2：UWB测距欺骗
理论上UWB的ToF测距不会被中继——因为无线电波的飞行时间与物理距离强相关，中继会引入额外延迟。但现实是，攻击者可以通过信号放大重放或PHY层时序操纵来欺骗测距结果。2024年的Black Hat大会上，就有研究者演示了对特定UWB芯片的Cicada攻击，成功把实际15米的测量距离缩短到了虚假的2米。
攻击手法3：降级到BLE
这是目前量产车型中最常见的漏洞。车机在UWB测距失败时，降级策略往往不够严密——比如UWB模块初始化超时，或者手机电量过低关闭了UWB，车机就直接回退到仅BLE验证。攻击者可以主动干扰UWB频段（6-8.5GHz），迫使系统降级。
三、CCC DK 3.0的安全架构要点
3.1 密钥分层体系
CCC数字钥匙的密钥管理分为四个层次，清晰且严谨：
┌────────────────────────────────────┐
│L4: 车主账号密钥 (Owner Key) │← 绑定OEM账户
├────────────────────────────────────┤
│L3: 车辆密钥 (Vehicle Key) │← 每车唯一，存储在SE
├────────────────────────────────────┤
│L2: 朋友密钥 (Friend Key) │← 分享给家人/代驾，可撤销
├────────────────────────────────────┤
│L1: 会话密钥 (Session Key) │← 每次解锁临时生成
└────────────────────────────────────┘
这里有一个关键设计值得单独拿出来说：朋友密钥可以由车主通过OEM App随时创建和撤销，不需要物理接触车辆。这种“可撤销的临时授权”机制，正是CCC规范的核心创新之一。
3.2 UWB安全测距的关键参数
要让UWB真正发挥作用，下面三个参数必须有严格的阈值设定：
| 参数 | 含义 | 推荐阈值 | 攻击降级风险 |
|---|---|---|---|
| ToF距离 | 飞行时间换算距离 | ≤2米（解锁）/ ≤0.5米（启动） | 测距欺骗 |
| 信号到达角 AoA | 钥匙相对车辆的方向 | ±15度 | 定向天线欺骗 |
| STS（扰频时间戳） | 加密时间戳防重放 | 强制验证 | 重放攻击 |
实践中最容易踩的一个坑是：很多OEM只检查ToF距离，而忽略了AoA和STS。攻击者使用定向天线从另一个方向发送UWB信号，ToF距离通过，但实际钥匙在反方向——这就是物理上的“盲区”。
四、四个真实踩坑场景
坑1：BLE配对绑定在手机重启后丢失
某车型的数字钥匙在iPhone重启后，BLE配对信息丢失，用户需要重新掏出手机用NFC贴车门才能恢复。产品经理觉得这只是个“体验问题”，但安全团队指出：如果每次重启手机都必须通过NFC恢复配对，假设用户在地下车库手机重启——BLE和UWB都无法工作，NFC需要靠近车门感应区——如果攻击者在这个过程中盗取了车辆的离线解锁Token，后果不堪设想。
修复方案其实不复杂：BLE配对的恢复不应依赖单一通道，应该在SE中持久化配对密钥，手机重启后自动通过SE恢复。
坑2：朋友钥匙的撤销存在“时间窗口”
某车主把数字钥匙分享给代驾后，在App上点击了“撤销”。App上显示撤销成功，但代驾的手机在断网状态下仍然可以解锁车辆——因为车辆SE中缓存的朋友钥匙吊销列表更新周期是24小时。
根因在于：朋友钥匙的撤销依赖车辆联网更新CRL，而车辆并非时刻在线。
修复方案是：朋友钥匙应该设置短有效期（默认24小时或单次使用）+ 联机强制验证双重机制。同时引入宽限期的时间限制——如果车辆超过X小时未联网，拒绝所有朋友钥匙的离线验证。
坑3：UWB测距的“蓝牙锚点”被欺骗
UWB的测距需要先在BLE上完成时间同步（锚点建立），然后切换到UWB进行精密测距。如果攻击者在BLE锚点建立阶段注入伪造的时间戳，后续UWB的ToF计算基础就已经错了。
根因在于：BLE锚点的时间戳没有经过加密签名保护。
修复方案：BLE锚点的同步消息应使用车辆SE中的预共享密钥签名，接收端验证签名后再建立时间基准。
五、落地建议
- UWB不能只是“增强体验”
如果UWB测距失败，不应降级到仅BLE验证。正确的策略是：UWB失败 → 要求NFC接触验证 → 降级BLE仅用于“迎宾灯光”等非安全功能。 - 朋友钥匙的撤销链路需要多通道保障
不能仅依赖车辆联网更新。建议引入SMS推送 + App后台静默同步 + 下次连接时服务器强制握手这三道防线。 - 密钥生命周期管理需要统一化
数字钥匙涉及SE、手机安全区、云端车主账户、车辆BLE/UWB模块等多方参与。密钥管理层面，可基于支持CCC规范的KMS方案（比如安当KMS）统一编排车主密钥、朋友密钥、会话密钥的生成、分发和撤销流程，避免各端密钥同步不一致导致的授权残留。
六、总结
数字钥匙的安全水平，本质上不取决于最强的那层防护——UWB，而取决于最弱的那层——BLE的降级策略。CCC DK 3.0规范给出了正确的架构方向，但从规范到量产，中间隔着一大堆实现细节：UWB测距结果是否真正参与了安全决策、BLE锚点是否经过了签名保护、朋友钥匙的撤销能否实时生效……这些问题，才是决定一辆车会不会在30米外被人开走的关键所在。
