1. 客户背景

奇瑞从项目启动之初，就将数字车钥匙定义为一种平台能力，而不是旗舰车型演示功能，也不是有限范围试点。

目标非常明确：覆盖全系车型、支持所有主流移动生态与主要数字钥匙标准，同时不绑定于任何单一硬件供应商。

真正的挑战，从来不是“手机能否解锁车辆”。

而是在量产环境下，车辆硬件、移动钱包、无线协议、安全标准、产线注入以及 OTA 运营体系，能否作为一个整体稳定协同运行。任何一个环节无法打通，数字钥匙都只能停留在原型阶段，而无法成为可规模化部署的平台能力。

奇瑞从一开始就选择了最具挑战性的路径：不分阶段上线，不仅限旗舰车型。所有车型在发布时即支持主流标准与主流手机生态。

2. 挑战

2.1 碎片化的标准体系

CCC、ICCOA 与 ICCE 分别采用不同的 PKI 架构、密码体系、Applet 与认证流程。

Apple Wallet 需要 CCC 与 MFi 认证；Android OEM Wallet 则主要围绕 ICCOA 与 ICCE 构建。同时，行业内仍广泛存在基于 BLE 的专有车辆访问方案。

为了覆盖完整移动生态，平台必须并行支持所有体系——即使它们的信任链、密钥系统与注入模型之间并不天然兼容。

2.2 三种无线协议协同为一个系统

NFC 用于近场触碰解锁，BLE 负责发现、唤醒与数据传输，UWB 则用于安全测距与无感进入。

每一种无线协议都对应不同的车辆与手机集成模型，而在量产环境中，它们必须作为一个统一的车辆访问体验协同运行。

2.3 完整移动生态覆盖

数字钥匙只有覆盖完整移动生态，才能真正成为量产功能，而不是局限于部分设备的演示能力。

Apple 拥有独立的安全域与 MFi 认证体系；Android OEM 则分别维护各自的钱包架构与接入流程。

因此，量产部署意味着需要同时完成多个移动生态的并行集成。

2.4 平台级集成能力

不同车型项目采用不同的 SE 芯片、MCU、ECU 与 Tier 1 供应体系，并拥有彼此独立的 OTA 节奏。

如果每个车型都从零开始集成，数字钥匙将始终停留在项目级能力，而无法成为可复用的平台能力。

3. 解决方案

3.1 面向多标准的统一云端安全基础设施

CCC 与 ICCOA 基于证书链信任模型，而 ICCE 基于对称密钥架构。

OnBoard™ 将两者统一到同一套安全基础设施中：

• PKI 负责从 Root CA 到车辆与手机的完整证书体系管理
• KMS 负责 ICCE 密钥生成与分发
• 所有密钥材料均保留在 HSM（FIPS 140-3 Level 3）硬件边界内

新增标准不再需要重建独立安全体系，而是在既有平台上扩展能力。

3.2 并行接入移动生态

OnBoard™ 并行完成 Apple Wallet 与主流 Android OEM Wallet 的整体接入，包括 CCC、ICCOA 与 ICCE 所需的 SE Applet、SDK 集成与认证支持。

Apple 需要 MFi 认证，而不同 Android OEM 则拥有各自独立的钱包架构与接入流程。

通过并行推进两条体系，奇瑞避免了认证流程占用核心研发资源，并显著降低了全系车型的部署复杂度。

3.3 跨芯片、跨车型复用

不同车型搭载不同 SE 芯片，并支持不同标准组合。

OnBoard™ 首先针对不同标准独立开发 Applet，并进一步建立跨芯片复用模型：

• 已验证的芯片与标准组合可直接复用既有 Applet
• 车型差异通过增量配置处理
• MCU 集成与 Bring-up 流程在全系车型中统一标准化

数字钥匙更新也不作为独立升级包管理，而是通过 SEMS Offline Path（SCP11-C）接入既有车辆 OTA 体系。

3.4 面向量产的安全注入体系

数字钥匙能力最终必须被安全写入每一台下线车辆。

SEMS 在产线节拍下直接管理车载 SE 内的安全域、Applet、证书与密钥注入流程。

每一次写入均可追溯、可审计。

正是这一层量产级集成能力，使数字钥匙从工程功能真正演进为覆盖奇瑞全系车型的量产平台能力。

4. 成果

奇瑞数字车钥匙平台现已在 20 款量产车型上稳定运行，累计发放超过 300 万份数字钥匙凭证。

标准支持、移动 OEM 接入、无线协议集成与安全基础设施均已统一收敛至平台层，使新车型能够直接继承既有能力，而无需从零开始重建整套数字钥匙体系。

‍