蓝牙车链与手机App攻击面：从KNOB/BIAS协议降级到OEM弱API远程解锁

一、车机蓝牙与 App 是被低估的攻击面

车主日常用蓝牙打电话、听音乐、同步通讯录，这套“日常蓝牙”实际上把车机密联到了一块被无线电包裹的攻击面上。攻击者只要靠近车辆几十米内，甚至更远，就可能完成这些事：

• 冒充已配对的手机，诱导车机主动连接过来
• 读取通讯录、SMS、通话记录
• 顺着车机内部的 CAN 网关，向动力域发送任意帧

更麻烦的是车企配套官方 App。它本质上是把“远程控制汽车”开放成一套 RESTful API，只要 App 鉴权设计存在缺陷，黑客就能跨城开锁。2022 年集中爆发的一系列事件，把这条从协议层到接口层的完整攻击链彻底暴露出来。

二、KNOB 协议层熵降级（CVE-2019-9506）

蓝牙会话建立时会协商会话密钥熵值（session key entropy），理论上要 16 字节。但 Bluetooth Classic 的协商协议没有做完整性校验，攻击者可以在第三个协商消息里把熵值改成 1 字节，而对端几乎都会接受。

为什么 1 字节就足以致命？因为 E0 流密码的会话密钥由 PK、两个 nonce 和协商熵值共同计算，熵从 16 字节降到 1 字节，相当于把密钥空间从 2^128 砍到 2^8。攻击者拿到一帧密文，在普通 CPU 上跑一分钟就能恢复 SK。蓝牙会话建立时会协商会话密钥熵值（session key entropy） 是 Bluetooth Classic 安全模型的关键前提，一旦这个前提被破坏，后续加密通道就失去了意义。

EPFL Antonioli 和 Payer 在 WOOT '22 论文里实测：5 台测试车机（KIA、Toyota、Mazda、Nissan、Subaru）以及 3 台实车（Suzuki IGNIS 2021、Skoda Fabia 2020、Skoda Octavia 2021）全部接受 1 字节熵协商。即便 KNOB 已经在蓝牙标准中被修补，所有这些车机依然敞着这个口子。

三、BIAS 协议层身份伪装（CVE-2020-10135）

BIAS 钻的是同一个会话建立协议的另一个空子：蓝牙单边认证（unilateral authentication）中的角色切换漏洞。

正常流程里，发起连接的一方是“验证者（verifier）”，被连接方是“被验证者（claimant）”。但蓝牙协议允许角色切换。攻击者在配对时声称“我们换个角色吧”，于是原本该发起认证的一方反而不需要认证了，攻击者可以直接免认证拿到会话。

把 KNOB 和 BIAS 串起来后，攻击者根本不需要偷取 PK，也不需要重新配对：

1. 用受害者的蓝牙地址发起到车机的连接
2. 利用 BIAS 跳到 verifier，绕开 PK 认证
3. 用 KNOB 把熵值砍到 1 字节
4. 用偷听来的密文离线爆破 SK
5. 拿着 SK 加密对话，车机便把攻击者当成已配对手机

EPFL 论文中复现使用的硬件配置是公开的：Cypress CYW920819 开发板、ThinkPad 和 internalblue 框架，全套开源代码位于 francozappa/bias。

四、BLE 链路层中继解锁 Tesla

经典蓝牙打得穿，BLE（低功耗蓝牙）同样逃不掉。NCC Group 在 2022 年公开了他们的 BLE 链路层中继工具，核心创新在于把 round-trip 延迟压到正常响应范围内，连“延迟上限防御”也一并骗过。

实际 PoC 思路如下：

• 攻击者 A 端靠近车主，贴近手机或钥匙
• 攻击者 B 端靠近 Tesla
• 链路层 relay 把 A 端的 BLE 流量真实转发到 B 端，连 L2CAP 加密通道一起搬过去
• B 端以“近在咫尺”的方式完成 Tesla 的 proximity 校验

NCC Group 公开演示显示，从几十米外打开一辆 Tesla Model 3 用时不到 10 秒，随后还可以无限次重复。Model Y 大概率同样受影响。Kwikset、Weiser Kevo 智能锁、楼宇门禁、笔记本、手机、医疗跟踪器，只要基于 BLE proximity 做鉴权，几乎都落在同一威胁模型里。

Sultan Qasim Khan 提到的攻击硬件并不难获得：市面上随便就能买到，淘宝几十块钱一对即可，唯一缺的是他的工具软件。

五、Honda Rolling Pwn：100 英尺外重放 key fob

更夸张的案例来自 Honda 和 Acura。

2022 年 3 月，The Hacker News 报道两位研究员公开了名为 Rolling Pwn 的 PoC：所有带无钥匙进入的 Honda/Acura 车型，遥控钥匙根本不滚动码。所谓“滚动码（rolling code）”本来是为了防重放，每次按下钥匙都应更换一次密钥码，但 Honda 的 key fob 直接没有使用这一机制。

攻击手法只有三步：

1. 使用 SDR，例如 HackRF 或 RTL-SDR，在 100 英尺（约 30 米）内嗅探车主按锁车键发出的无线信号
2. 把信号保存下来，里面包含解锁指令和静态身份码
3. 任何时候用同一 SDR 重放这帧信号，车辆照单全收，开锁、解锁、启动一条龙

Reddit、CivicX、CR-V Owners Club 上都有车主自行复现成功，这也是近两年车安全领域最具戏剧性的攻击之一。它的本质是密码工程失误：滚动码在 30 多年前 Keeloq 那一代就已经普及，而 Honda 直到 2022 年仍在使用静态码。

六、Honda Connect App：弱 API 直接开车门

App 侧的攻击比蓝牙层更直白。2022 年 8 月公开的 Honda Connect 漏洞演示显示，包括第 5 代 Honda City 等车型在内，App 后端服务的鉴权机制非常脆弱：

• API 端点缺少签名校验或会话校验
• 简单的逆向就能拿到查询指令用的端点和参数格式
• 鉴权只依赖用户登录态，没有“动作授权”的二次校验
• 车牌号或车架号一旦泄露，就能直接对绑定车辆下发“解锁/启动”指令

这已经不是 Bluetooth 层的问题，而是车企云端 API 的鉴权设计失误。攻击者甚至不需要进入车主附近范围，云端上一打一个准。

七、防御要点（红队 + 蓝队视角）

实战中要降低风险，至少要做到这五条：

1. 强制 SC（Secure Connections）模式：禁用旧的 E0 流密码和单边认证，让 KNOB/BIAS 无从下手
2. 绑定 KNOB 修复：在蓝牙协议栈实现里强制熵值不低于 7 字节，不接收协商下限
3. 角色切换拒绝：在认证阶段拒绝 verifier 角色变更，BIAS 就会直接失效
4. 车钥匙加滚动码：和 Keeloq、Hitag2 一样，每次发送唯一码，防止 SDR 重放
5. OEM 移动端 API 鉴权加固：App 调用必须带设备绑定、数字签名和服务端二次风控，单靠 cookie 不够

如果是有 IoT 背景的安全工程师，这五条和常规 BLE 安全基本是同一套清单。区别只在于它发生在车上，打通之后就是“远程开门 + 启动”。

八、思考题

1. KNOB 和 BIAS 同时打中一台车机的概率有多高？EPFL 论文里给出的实验是不是已经同时验证了？
2. BLE 中继攻击和经典蓝牙 KNOB/BIAS 在协议层有什么区别？为什么前者更难被发现？
3. Honda 重放事故后，HackerOne 上 OEM 厂商的 bug bounty 项目里，最容易拿到赏金的是哪一类漏洞？
4. 假如你是车厂安全负责人，30 天内只能上一个补丁，应该优先修哪一项？

九、素材出处

• Antonioli & Payer. "On the Insecurity of Vehicles Against Protocol-Level Bluetooth Threats" WOOT '22（素材 #73）
• Help Net Security. "BLE vulnerability may be exploited to unlock cars, smart locks, building doors, smartphones" 2022-05-17
• NCC Group. "Bluetooth Low Energy (BLE) link layer relay attack" 2022-05
• The Hacker News. "Honda's Keyless Access Bug Could Let Thieves Remotely Unlock and Start Vehicles" 2022-03
• The Drive. "I Tried the Honda Key Fob Hack on My Own Car. It Totally Worked" 2022-07
• Remote Exploitation of Honda Cars（YouTube, 2022）
• francozappa/bias - KNOB & BIAS 复现代码
• awesome-vehicle-security: #73 Bluetooth Protocol Threats / #37 Honda Remote Exploitation

---