凌晨两点，英国伯明翰。监控画面里，两个年轻人站在一户人家的门外，一人举起一个背包贴着墙壁，另一人走到停在门口的奔驰车前，拉开车门、按下启动键、扬长而去。全程不到60秒，没有任何破窗撬锁的痕迹。
这不是电影情节。这是2024年英国警方通报的真实案件------中继攻击（Relay Attack）。攻击者用几十块钱的信号中继器，把车主放在门厅鞋柜上的车钥匙信号"接力"到车旁，车子以为主人来了，乖乖开门。
而当车钥匙变成手机上的一个APP，攻击面只会更大，不会更小。
一、数字钥匙的三次进化：每一次升级都带来新问题
汽车数字钥匙的技术路线经历了三代演进，每一代都在解决上一代的问题，但同时也打开了新的攻击窗口。
第一代：NFC（近场通信）
最早的手机数字钥匙方案。把手机贴在车门B柱的NFC感应区，像刷公交卡一样解锁。
安全性相对较高------NFC的通信距离只有几厘米，攻击者几乎不可能在中途截获信号。但问题是体验太差：必须掏出手机、对准位置、保持1-2秒。下雨天站在车旁边手忙脚乱找NFC感应区的经历，开过特斯拉Model 3早期版本的人都懂。
第二代：蓝牙（BLE）
手机在口袋/包里，走到车边3-5米自动解锁------这是蓝牙数字钥匙带来的体验飞跃。
但蓝牙的通信距离比NFC大得多，中继攻击正是在这一代开始爆发。攻击者不需要破解蓝牙加密协议------他们只需要把信号原样转发。一个攻击者站在你家窗外捕捉手机蓝牙信号，另一个同伙站在车旁转发，车子检测到"手机在附近"，解锁。
更隐蔽的是蓝牙嗅探+重放：攻击者在公共场所（商场停车场、充电站）被动监听手机与车辆的蓝牙配对过程，提取配对参数后离线分析，找到密钥派生规律。
第三代：UWB（超宽带）
UWB是目前最先进的数字钥匙技术，通过飞行时间（ToF）测距，精度可以达到10厘米级别。车子不止知道"手机在附近"，还知道"手机距离车2.3米，在左前门方向"。理论上，中继攻击会因为引入的额外延迟而被检测出来。
但UWB也不是银弹。我们在实际项目中见过两个问题：
- UWB芯片兼容性：不同手机厂商的UWB芯片实现有差异，测距精度不一致，导致安全策略难以统一
- 降级攻击：如果系统支持UWB→BLE→NFC的兼容回退，攻击者可以干扰UWB信号，迫使系统降级到BLE，然后发动中继攻击
每代数字钥匙技术，密钥管理都是底座。钥匙形态从机械钥匙变成手机APP，但密钥保护的核心逻辑没有变------密钥存在哪、怎么用、谁来验。
二、数字钥匙安全的三个核心问题
抛开具体的无线协议不谈，数字钥匙安全最终可以归结为三个问题：
问题1：钥匙（密钥）存在哪？
数字钥匙本质上是一对公私钥。手机端存私钥，车端存公钥。解锁时手机用私钥签名一个挑战值，车端用公钥验签。
手机端的私钥安全是整个体系的基石。 如果私钥被提取------无论是通过APP逆向、系统漏洞还是越狱/Root------攻击者就可以克隆你的数字钥匙。
目前行业的做法是把私钥放在手机的安全元件（Secure Element，SE）或可信执行环境（TEE）中，APP层面的代码无法直接读取。Android的StrongBox和iOS的Secure Enclave是目前主流的两个方案。
但问题是：不同手机的SE/TEE能力参差不齐。 一台千元安卓机的TEE实现和iPhone 16的Secure Enclave是天壤之别。整车厂在设计数字钥匙方案时，不能假设用户的手机都是旗舰机。
我们遇到过一个OEM的数字钥匙项目，在测试阶段发现某款年销量30万+的中低端手机的TEE不支持ECC P-256曲线（数字钥匙联盟CCC标准要求的签名算法），最终只能做软件层兜底------用白盒加密把私钥保护在APP层。这降低了安全强度，但不是所有用户都买旗舰机，现实中你必须做妥协。
问题2：手机和车之间，怎么验证？
这是PKI体系的经典问题------证书管理。
CCC（Car Connectivity Consortium）数字钥匙规范要求使用两级PKI：OEM的根CA签发设备证书，设备证书再签发数字钥匙实例证书。每把数字钥匙都有独立的证书链，车主可以随时吊销某一把钥匙而不影响其他。
但这个证书体系在落地时有几个工程挑战：
- 证书数量爆炸：一台车可能有车主钥匙+3把分享钥匙+代客泊车钥匙+维修模式钥匙，每把钥匙一个证书。一个年产30万台的整车厂，一年产生的证书量是百万级。
- 证书生命周期管理：分享给朋友的钥匙过期了怎么自动吊销？手机丢了怎么紧急挂失？这些不是算法问题，是工程和体验问题。
- 离线场景：地下车库没信号，手机和车怎么验证证书状态？CCC的方案是车端缓存CRL（证书吊销列表），定期通过OTA更新。
数字钥匙的PKI不是"搭个CA签个证书"就完了。证书全生命周期管理（签发、更新、吊销、审计）才是真正的工程难点。
问题3：如果手机被攻破，怎么止损？
安全架构必须假设手机端是不安全的。这意味着：
- 车端要做独立的异常检测而不是完全信任手机端。比如多次解锁失败后锁定时长递增、异常时间段（凌晨2-5点）解锁触发额外验证。
- 密钥应该支持远程吊销。车主在另一台设备上登录账号，可以立即吊销丢失手机上的所有数字钥匙。
- 硬件隔离是最后一层防线。点火/行驶级别的操作（驱动电机、挂挡）应要求车端HSM独立验证，不能仅凭手机端的解锁信号。
三、数字钥匙安全架构的落地建议
基于我们在多个数字钥匙项目中的踩坑经验，以下是一个可落地的架构设计思路：
1. 手机端：分层保护
| 保护层 | 技术手段 | 保护目标 |
|---|---|---|
| 硬件层 | SE/TEE存储私钥 | 防止私钥被提取 |
| 应用层 | 代码混淆+反调试 | 防止APP被逆向找到密钥调用接口 |
| 通信层 | TLS 1.3+证书绑定 | 防止中间人攻击篡改通信内容 |
不要假设用户手机有SE。 在TEE不可用时，白盒加密+反逆向是必要的兜底方案。
2. 车端：以HSM为根信任
车端不信任手机，车端只信任自己的HSM。数字钥匙的验证流程必须到车端HSM内部完成，不能在应用处理器上明文处理。
具体做法：手机发送签名后的挑战值→车端网关转发→HSM内部验签→返回结果。私钥操作全程不离开HSM。
3. 云端：证书全生命周期管理
在云端部署KSP（密钥管理系统），统一管理所有数字钥匙证书的签发、更新、吊销：
- 车主购买数字钥匙功能 → 云端签发实例证书
- 车主分享钥匙给家人 → 云端签发子证书（可设有效期和权限限制）
- 车主手机丢失 → 云端吊销该设备的全部证书 → 车端CRL同步
- 每季度审计 → 查询全量证书状态，发现异常签发
证书管理不是一锤子买卖。 在设计架构的时候就要把整个证书生命周期画出来------从签发、续期、挂失、到最终销毁，每个环节都不能有管理盲区。
四、总结
从NFC到蓝牙到UWB，数字钥匙的体验越来越好，攻击面也越来越大。但万变不离其宗------把密钥保护好，把证书管好，把信任锚定在硬件上。
三个核心原则：
- 手机端不可信------私钥尽量放SE/TEE，放不了就加白盒加密+反逆向兜底
- 车端用HSM做最后一道防线------不信任任何外部信号，关键操作走HSM
- 证书管理要有始有终------签发、续期、吊销、审计，整个生命周期都不能有盲区
安当在数字钥匙安全方案上提供了从HSM（车端安全锚点）、KSP（证书全生命周期管理）到UKEY（离线场景下的强身份认证）的完整产品组合。这几个组件单独拿出来都不新鲜，但把它们串成一个完整的数字钥匙安全闭环------从手机到车端到云端------是这个方案最有价值的地方。
你们团队的数字钥匙用的是蓝牙还是UWB？在适配不同手机的TEE能力时遇到过什么坑？欢迎在评论区聊聊。