蓝牙车钥匙被「中继攻击」打穿的故事安全研究者演示过不止一次两个盒子把钥匙信号原样放大转发车就以为钥匙在身边——物理上钥匙可能远在数十米外。UWB 数字钥匙的解法不是「更强的加密」而是换判据从信号强度换成飞行时间。强度可以放大时间不行。这篇从 CCC Digital Key 的三层 stack 讲起拆开 STS 静态/动态的防护差异、成本结构为什么才是普及推手以及实测联调里三个真实的坑。文末给选型的人一份五问清单。先给结论1. UWB 数字钥匙的安全感不来自「UWB 很先进」来自一个物理事实它测的是飞行时间不是信号强度——强度可以放大时间不行。 2. 一套 CCC Digital Key 是三层 stackBLE 负责发现和会话、UWB 负责厘米级测距、NFC 负责没电兜底。少任何一层就多一个明确的失效模式。 3. 安全是配出来的不是芯片自带静态 STS 和动态 STS 对重放/中继攻击的防护差着一整个等级实测联调里绝大多数「测不通」最后都归到配置差异上。一、引子中继攻击是怎么把蓝牙钥匙打穿的被动无钥匙进入蓝牙钥匙刚普及那几年安全研究者反复演示过同一种攻击中继攻击。原理朴素得近乎无聊车主钥匙还在包里攻击者 A 在车附近放一个盒子攻击者 B 跟着车主两个盒子把钥匙和车之间的信号原样放大转发。车收到的信号「够强」于是判定钥匙就在旁边——解锁、启动。物理上钥匙可能远在数十米外链路却被「拉长」到了攻击者手里。问题的根子在于判据蓝牙钥匙靠信号强度RSSI判断远近而强度是最容易被操纵的量。2026 年这个方向的升级明显在加速三个信号2026 年 9 月 30 日FCC 发布拟议规则要更新沿用二十多年的 UWB 监管框架CCC 公开表态支持——监管现代化是数字钥匙规模化部署的前提2026 年 8 月NXP 宣布其车规 UWB 单芯片Trimension 系列进入宝马 2026 年车型同一颗芯片同时做数字钥匙与舱内儿童存在检测2026 年 2 月Aliro 1.0 标准发布把跨品牌数字钥匙带进智能锁9 月已有支持 UWB Aliro 的锁具上市。技术没变场景在铺开。这篇文章就把这套东西拆开看。二、三层 stack每层只干一件事CCC Digital Key车连接联盟的数字钥匙规范把一次「用手机开车门」拆成了三层每层有明确的最小职责图1手机与车之间由 BLE、UWB、NFC 三层各司其职——BLE 负责「找到你」UWB 负责「确认你在哪」NFC 负责「万一都不行」。BLE发现、会话建立、参数交换。功耗低、可以常开负责把两边的会话参数协商好这些参数走带外通道交换。但它只能判到「米级附近」——精度上不了台面。UWB精确测距安全核心。厘米级判据是飞行时间。这是整套方案的安全根后面单独讲。NFC兜底凭证。手机没电了贴一下车门照样能开。可靠但必须贴身——它是「最后一道」不是主力。为什么必须是三层不能合并成一层因为每层各自解决一个不同约束BLE 省电但粗、UWB 准但要先建会话、NFC 可靠但得贴身。少任何一层就多一个明确的失效模式——没 BLE每次开门都要先掏手机点两下没 NFC手机没电就被关在车外没 UWB就退回蓝牙钥匙的中继攻击困局。顺带一个容易被忽略的点CCC 这套规范里UWB 只负责测距不测角。要做「车找人在哪」这类需要方位的功能得另想办法。三、UWB 凭什么防住中继攻击图2左——蓝牙钥匙靠 RSSI 判断远近中继盒把链路拉长即可欺骗右——UWB 测飞行时间链路拉长导致时间变长车辆判定钥匙不在身边拒绝解锁。第 1 篇算过一笔账UWB 信号带宽在 500MHz 量级对应约 1ns 的时间分辨率乘上光速就是30cm 量级的距离误差上限。数字钥匙要的是「钥匙在车边 1 米内才解锁」这种判断UWB 的误差预算绰绰有余。关键在于中继攻击在这个判据下直接失效。攻击者把链路拉长无线电波的传播时间就实实在在地变长了——d c·ToF/2时间造不了假。想骗过一个 10cm 量级的判定窗口转发时延就得压到亚纳秒这已经不是「加个盒子」能搞定的事。这就是标题里那个问题的答案强度可以放大时间不行。但「测距准」只是拿到了安全的一个必要条件另一个必要条件在密钥那一层。四、STS安全是配出来的不是芯片自带UWB 的测距帧里带一段加扰时间戳序列STS它的作用之一是防重放——把每一轮的测距帧变成「一次性」的录下来重发没有。STS 有两种模式差别很大模式工作机制对重放/中继攻击静态 STS每轮复用同一段序列实现简化易受重放/中继攻击动态 STS序列按索引逐时隙滚动每轮不同缓解公开文档里有一张更细的威胁矩阵三种攻击方式对两种 STS 的防护结果大致是攻击方式静态 STS动态 STS空中被动监听缓解缓解信号放大缓解缓解重放 / 中继攻击易受缓解安全等级还有一档可调从「不加密不认证」到「加密 认证 128 位消息认证码」分多级fiRa 协议里常见的是「认证 64 位 MIC」这一档。选哪档是产品定义阶段的决定不是固件默认值。这里有个实测踩出来的教训联调客户车钥匙时备份脚本里的 STS 配置预置明文密钥模式和标准配置动态 STS不是一回事跳窝开关连续跳 vs 关闭、PSDU 速率6.81M vs 850K也对不上。脚本能跑通不代表跑的是标准配置——能跑和跑对是两回事。五、一颗芯片的生意成本结构才是普及的推手回到工程视角为什么车企愿意为 UWB 数字钥匙买单NXP 那颗进宝马的单芯片是个很好的样本它把「安全测距」和「短距雷达」合到了一颗芯片上。数字钥匙用测距舱内儿童存在检测用雷达回波——后者正在进入欧洲和中国的 NCAP 评价体系是法规驱动的刚需。一颗芯片摊两个功能成本账才合得上。这正是第 2 篇讲的逻辑技术可行性只决定「能不能做」成本结构决定「会不会普及」。认证侧的进展同向CCC 的数字钥匙认证产品 2025 年达到了 115 个2025 年 3 月认证范围扩展之后明显放量FiRa Core 3.0 已把 CCC Digital Key 的 UWB 特性纳入认证2026 年 3 月出现了首家通过 FiRa Core 4.0 认证的芯片。国内这边数字车钥匙也有了自己的行业标准——T-CAAMTB 223.4-2024《数字车钥匙系统》第 4 部分就是 UWB 系统。标准先行通常意味着量产落地跟着来。市场预测同向UWB 芯片组市场规模预计从 2026 年约 25 亿美元增长到 2032 年约 47 亿美元数字车钥匙市场 2025 年约 27 亿美元2032 年预计超 125 亿年复合约 25%第三方研究机构口径仅看量级。需求端的结构很清楚手机侧 UWB 保有量扩大 车钥匙升级是两轮独立的驱动。六、工程视角实测联调里的三个坑前面都是公开层面能查到的。下面三个坑是我自己踩过的按踩的深浅排序。坑一影响不大但很典型标准默认的 960ms 间隔低功耗调度下有细微影响。CCC 规范的测距间隔是 96ms 的整数倍标准默认取 960ms。我在联调环境实测过按默认值跑测距会时不时失败——指令发下去没有结果。把间隔从 960ms 调到 96ms成功率明显提高。但要诚实说这不是量级级的差异是细节级的不值得为它改架构但值得知道它为什么发生。机制上说清三件事含混在一起就会夸大单轮测距值的误差不随间隔放大。DS-TWR 一轮内部有三次交换两端时钟偏差在这一轮内就被抵掉见第 1 篇——不是「间隔越长、每轮偏得越多」。慢时钟的漂移有固件兜底不会无界累积。低功耗场景下设备大部分时间在睡靠片上低功耗时钟32k 量级维持调度、计算唤醒时刻。这种时钟精度有限几十 ppm 量级但固件会周期性拿快时钟124.8M 量级把它校准回来——「睡久了就一路漂下去」并不会发生这是这件事「还好」的原因。间隔真正动的是校准之间的残余。校准之后的漂移仍随时间线性增长按 20ppm 估960ms 距上次锚定最远时能漂出约 20µs96ms 只有约 2µs——而 UWB 前导捕获的窗口正是微秒量级。间隔越短唤醒时刻离上次锚定越近漂出捕获窗口、这一轮同步失败的概率越低。调到 96ms等于把锚定密度提高十倍——成功率有改善但改善的是边际概率不是根因。这背后还是那个天平间隔越短同步越稳但空口和功耗的账越大。标准默认值取的是「及格线」现场值要按现场重算。坑二状态显示「成功」距离却是负的。实测中遇到过一种现象测距状态一切正常上报的距离却是负数。第一反应是算法错了最后定位到的是天线时延没标定——第 2 篇讲过芯片时间戳和电磁波离开天线口之间差一个固定时延不标就会系统性偏掉偏过头距离就「减」成了负的。负距离不是 bug是标定缺失的直接信号。标定不是仪式是每次测量的前提。坑三备份脚本 ≠ 标准配置差异点要逐项对。这一条最费时间。联调时拿出的「以前能跑的备份脚本」和标准配置差在 STS 模式、跳窝开关、PSDU 速率上再加上一些场景性约束密钥轮转开关两端要一致、响应方时隙索引每个节点必须不同重复了结果就乱套、一对多场景要逐个配索引。任何一项对不上现象都是「测不通」。教训车钥匙是配置密集型工程。「先跑起来再对齐」在这个场景里行不通——配置错了跑起来的也是个错的。七、收敛如果你要选型问这五句#该问的问题对应本文1认证清单是什么——CCC Digital Key / FiRa 认证做到哪个版本、覆盖哪些特性第五节2STS 用静态还是动态密钥怎么 provisioning重放/中继攻击的防护做到哪一级第四节3失效链路是什么——手机没电时 NFC 兜底有没有、体验如何第二节4整机形态下的天线时延标定数据能不能看回接第 2 篇负距离就是没标定的信号第六节5目标市场的法规核对过吗——FCC 框架正在改中国有 T-CAAMTB 标准第一节给工程师的三句话时钟同步的账按现场重算标定先行负距离就是警报配置逐项对标准别信备份脚本。收尾所以「手机当车钥匙安不安全」这个问题答案不在发布会上在三个地方物理层测的是时间还是强度、协议层 STS 配的是静态还是动态、工程层配置有没有逐项对标准。蓝牙钥匙是被中继攻击打穿的UWB 数字钥匙能不能立住取决于上面三件事有没有做对。不谈参数只看跑出来的数。
蓝牙车钥匙被「中继攻击」打穿的故事安全研究者演示过不止一次两个盒子把钥匙信号原样放大转发车就以为钥匙在身边——物理上钥匙可能远在数十米外。UWB 数字钥匙的解法不是「更强的加密」而是换判据从信号强度换成飞行时间。强度可以放大时间不行。这篇从 CCC Digital Key 的三层 stack 讲起拆开 STS 静态/动态的防护差异、成本结构为什么才是普及推手以及实测联调里三个真实的坑。文末给选型的人一份五问清单。先给结论1. UWB 数字钥匙的安全感不来自「UWB 很先进」来自一个物理事实它测的是飞行时间不是信号强度——强度可以放大时间不行。 2. 一套 CCC Digital Key 是三层 stackBLE 负责发现和会话、UWB 负责厘米级测距、NFC 负责没电兜底。少任何一层就多一个明确的失效模式。 3. 安全是配出来的不是芯片自带静态 STS 和动态 STS 对重放/中继攻击的防护差着一整个等级实测联调里绝大多数「测不通」最后都归到配置差异上。一、引子中继攻击是怎么把蓝牙钥匙打穿的被动无钥匙进入蓝牙钥匙刚普及那几年安全研究者反复演示过同一种攻击中继攻击。原理朴素得近乎无聊车主钥匙还在包里攻击者 A 在车附近放一个盒子攻击者 B 跟着车主两个盒子把钥匙和车之间的信号原样放大转发。车收到的信号「够强」于是判定钥匙就在旁边——解锁、启动。物理上钥匙可能远在数十米外链路却被「拉长」到了攻击者手里。问题的根子在于判据蓝牙钥匙靠信号强度RSSI判断远近而强度是最容易被操纵的量。2026 年这个方向的升级明显在加速三个信号2026 年 9 月 30 日FCC 发布拟议规则要更新沿用二十多年的 UWB 监管框架CCC 公开表态支持——监管现代化是数字钥匙规模化部署的前提2026 年 8 月NXP 宣布其车规 UWB 单芯片Trimension 系列进入宝马 2026 年车型同一颗芯片同时做数字钥匙与舱内儿童存在检测2026 年 2 月Aliro 1.0 标准发布把跨品牌数字钥匙带进智能锁9 月已有支持 UWB Aliro 的锁具上市。技术没变场景在铺开。这篇文章就把这套东西拆开看。二、三层 stack每层只干一件事CCC Digital Key车连接联盟的数字钥匙规范把一次「用手机开车门」拆成了三层每层有明确的最小职责图1手机与车之间由 BLE、UWB、NFC 三层各司其职——BLE 负责「找到你」UWB 负责「确认你在哪」NFC 负责「万一都不行」。BLE发现、会话建立、参数交换。功耗低、可以常开负责把两边的会话参数协商好这些参数走带外通道交换。但它只能判到「米级附近」——精度上不了台面。UWB精确测距安全核心。厘米级判据是飞行时间。这是整套方案的安全根后面单独讲。NFC兜底凭证。手机没电了贴一下车门照样能开。可靠但必须贴身——它是「最后一道」不是主力。为什么必须是三层不能合并成一层因为每层各自解决一个不同约束BLE 省电但粗、UWB 准但要先建会话、NFC 可靠但得贴身。少任何一层就多一个明确的失效模式——没 BLE每次开门都要先掏手机点两下没 NFC手机没电就被关在车外没 UWB就退回蓝牙钥匙的中继攻击困局。顺带一个容易被忽略的点CCC 这套规范里UWB 只负责测距不测角。要做「车找人在哪」这类需要方位的功能得另想办法。三、UWB 凭什么防住中继攻击图2左——蓝牙钥匙靠 RSSI 判断远近中继盒把链路拉长即可欺骗右——UWB 测飞行时间链路拉长导致时间变长车辆判定钥匙不在身边拒绝解锁。第 1 篇算过一笔账UWB 信号带宽在 500MHz 量级对应约 1ns 的时间分辨率乘上光速就是30cm 量级的距离误差上限。数字钥匙要的是「钥匙在车边 1 米内才解锁」这种判断UWB 的误差预算绰绰有余。关键在于中继攻击在这个判据下直接失效。攻击者把链路拉长无线电波的传播时间就实实在在地变长了——d c·ToF/2时间造不了假。想骗过一个 10cm 量级的判定窗口转发时延就得压到亚纳秒这已经不是「加个盒子」能搞定的事。这就是标题里那个问题的答案强度可以放大时间不行。但「测距准」只是拿到了安全的一个必要条件另一个必要条件在密钥那一层。四、STS安全是配出来的不是芯片自带UWB 的测距帧里带一段加扰时间戳序列STS它的作用之一是防重放——把每一轮的测距帧变成「一次性」的录下来重发没有。STS 有两种模式差别很大模式工作机制对重放/中继攻击静态 STS每轮复用同一段序列实现简化易受重放/中继攻击动态 STS序列按索引逐时隙滚动每轮不同缓解公开文档里有一张更细的威胁矩阵三种攻击方式对两种 STS 的防护结果大致是攻击方式静态 STS动态 STS空中被动监听缓解缓解信号放大缓解缓解重放 / 中继攻击易受缓解安全等级还有一档可调从「不加密不认证」到「加密 认证 128 位消息认证码」分多级fiRa 协议里常见的是「认证 64 位 MIC」这一档。选哪档是产品定义阶段的决定不是固件默认值。这里有个实测踩出来的教训联调客户车钥匙时备份脚本里的 STS 配置预置明文密钥模式和标准配置动态 STS不是一回事跳窝开关连续跳 vs 关闭、PSDU 速率6.81M vs 850K也对不上。脚本能跑通不代表跑的是标准配置——能跑和跑对是两回事。五、一颗芯片的生意成本结构才是普及的推手回到工程视角为什么车企愿意为 UWB 数字钥匙买单NXP 那颗进宝马的单芯片是个很好的样本它把「安全测距」和「短距雷达」合到了一颗芯片上。数字钥匙用测距舱内儿童存在检测用雷达回波——后者正在进入欧洲和中国的 NCAP 评价体系是法规驱动的刚需。一颗芯片摊两个功能成本账才合得上。这正是第 2 篇讲的逻辑技术可行性只决定「能不能做」成本结构决定「会不会普及」。认证侧的进展同向CCC 的数字钥匙认证产品 2025 年达到了 115 个2025 年 3 月认证范围扩展之后明显放量FiRa Core 3.0 已把 CCC Digital Key 的 UWB 特性纳入认证2026 年 3 月出现了首家通过 FiRa Core 4.0 认证的芯片。国内这边数字车钥匙也有了自己的行业标准——T-CAAMTB 223.4-2024《数字车钥匙系统》第 4 部分就是 UWB 系统。标准先行通常意味着量产落地跟着来。市场预测同向UWB 芯片组市场规模预计从 2026 年约 25 亿美元增长到 2032 年约 47 亿美元数字车钥匙市场 2025 年约 27 亿美元2032 年预计超 125 亿年复合约 25%第三方研究机构口径仅看量级。需求端的结构很清楚手机侧 UWB 保有量扩大 车钥匙升级是两轮独立的驱动。六、工程视角实测联调里的三个坑前面都是公开层面能查到的。下面三个坑是我自己踩过的按踩的深浅排序。坑一影响不大但很典型标准默认的 960ms 间隔低功耗调度下有细微影响。CCC 规范的测距间隔是 96ms 的整数倍标准默认取 960ms。我在联调环境实测过按默认值跑测距会时不时失败——指令发下去没有结果。把间隔从 960ms 调到 96ms成功率明显提高。但要诚实说这不是量级级的差异是细节级的不值得为它改架构但值得知道它为什么发生。机制上说清三件事含混在一起就会夸大单轮测距值的误差不随间隔放大。DS-TWR 一轮内部有三次交换两端时钟偏差在这一轮内就被抵掉见第 1 篇——不是「间隔越长、每轮偏得越多」。慢时钟的漂移有固件兜底不会无界累积。低功耗场景下设备大部分时间在睡靠片上低功耗时钟32k 量级维持调度、计算唤醒时刻。这种时钟精度有限几十 ppm 量级但固件会周期性拿快时钟124.8M 量级把它校准回来——「睡久了就一路漂下去」并不会发生这是这件事「还好」的原因。间隔真正动的是校准之间的残余。校准之后的漂移仍随时间线性增长按 20ppm 估960ms 距上次锚定最远时能漂出约 20µs96ms 只有约 2µs——而 UWB 前导捕获的窗口正是微秒量级。间隔越短唤醒时刻离上次锚定越近漂出捕获窗口、这一轮同步失败的概率越低。调到 96ms等于把锚定密度提高十倍——成功率有改善但改善的是边际概率不是根因。这背后还是那个天平间隔越短同步越稳但空口和功耗的账越大。标准默认值取的是「及格线」现场值要按现场重算。坑二状态显示「成功」距离却是负的。实测中遇到过一种现象测距状态一切正常上报的距离却是负数。第一反应是算法错了最后定位到的是天线时延没标定——第 2 篇讲过芯片时间戳和电磁波离开天线口之间差一个固定时延不标就会系统性偏掉偏过头距离就「减」成了负的。负距离不是 bug是标定缺失的直接信号。标定不是仪式是每次测量的前提。坑三备份脚本 ≠ 标准配置差异点要逐项对。这一条最费时间。联调时拿出的「以前能跑的备份脚本」和标准配置差在 STS 模式、跳窝开关、PSDU 速率上再加上一些场景性约束密钥轮转开关两端要一致、响应方时隙索引每个节点必须不同重复了结果就乱套、一对多场景要逐个配索引。任何一项对不上现象都是「测不通」。教训车钥匙是配置密集型工程。「先跑起来再对齐」在这个场景里行不通——配置错了跑起来的也是个错的。七、收敛如果你要选型问这五句#该问的问题对应本文1认证清单是什么——CCC Digital Key / FiRa 认证做到哪个版本、覆盖哪些特性第五节2STS 用静态还是动态密钥怎么 provisioning重放/中继攻击的防护做到哪一级第四节3失效链路是什么——手机没电时 NFC 兜底有没有、体验如何第二节4整机形态下的天线时延标定数据能不能看回接第 2 篇负距离就是没标定的信号第六节5目标市场的法规核对过吗——FCC 框架正在改中国有 T-CAAMTB 标准第一节给工程师的三句话时钟同步的账按现场重算标定先行负距离就是警报配置逐项对标准别信备份脚本。收尾所以「手机当车钥匙安不安全」这个问题答案不在发布会上在三个地方物理层测的是时间还是强度、协议层 STS 配的是静态还是动态、工程层配置有没有逐项对标准。蓝牙钥匙是被中继攻击打穿的UWB 数字钥匙能不能立住取决于上面三件事有没有做对。不谈参数只看跑出来的数。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
