第3章：应用签名与认证——签名机制、密钥管理、V2/V3签名方案

说到车载应用的签名，我其实挺感慨的。早年做手机App的时候，签名这事儿经常被当成「最后打包前点一下按钮」的流程。但到了车载领域，签名直接关系到安全启动、权限校验、甚至整车的功能安全等级。说白了，签名就是应用的「身份证」，而且是带防伪芯片的那种。

3.1 签名机制：为什么车载应用必须签名？

先问一个问题：你的车机凭什么相信一个App是合法的？

答案就是签名。Android系统从诞生起就要求所有应用必须签名。车载系统在此基础上更严格——没有签名的应用，连安装都不让。

签名机制的核心作用有三个：

• 身份认证：证明这个App确实来自某个开发者或OEM
• 完整性校验：确保App没有被篡改过
• 权限继承：同一个签名的App可以共享权限和数据

我在项目中遇到过一件事：某Tier1供应商发来的导航App，签名证书过期了。结果车机死活装不上，排查了半天才发现是证书有效期的问题。嗯，从那以后我每次收到第三方App，第一件事就是检查签名有效期。

3.2 密钥管理：你的签名密钥比代码值钱

签名密钥一旦泄露，后果有多严重？

我见过最夸张的情况：某团队把签名密钥直接放在Git仓库里，还忘了加.gitignore。结果被扫描工具抓了个正着，整个项目组被安全部门约谈。你想想看，密钥泄露意味着任何人都可以用你的身份发布恶意应用，这比代码泄露可怕多了。

密钥管理的基本原则，我总结了几条：

1. 密钥必须离线存储：不要放在开发机、CI服务器、或者任何联网设备上。用硬件加密卡或者离线U盘。
2. 分级管理：开发密钥、测试密钥、发布密钥必须分开。开发密钥可以宽松点，发布密钥必须严格管控。
3. 定期轮换：我个人习惯是每年更新一次发布密钥。虽然Android支持密钥轮换，但车载项目建议更保守一些。
4. 备份要加密：密钥备份不是复制粘贴到另一个U盘就完事了。必须用强密码加密，并且分开存放。

密钥类型	使用场景	安全等级	建议存储方式
开发密钥	日常调试、单元测试	低	开发机本地，密码保护
测试密钥	集成测试、系统验证	中	测试服务器，访问控制
发布密钥	正式发布、OTA更新	高	离线硬件加密模块

3.3 V2/V3签名方案：从JAR签名到APK签名方案

Android的签名方案经历了几个版本。V1是传统的JAR签名，V2引入了APK签名方案，V3则增加了密钥轮换支持。车载系统现在基本要求V2以上，V1已经被标记为不安全。

3.3.1 V1签名（JAR签名）

V1签名说白了就是把签名信息放在META-INF目录下。它的问题是：只保护了ZIP包内的文件，不保护ZIP本身的元数据。攻击者可以删除签名文件，或者修改ZIP结构而不影响文件内容。

我记得早期有个漏洞，就是利用V1签名的这个缺陷，在APK里插入额外的文件而不破坏签名。嗯，所以V1现在基本被弃用了。

3.3.2 V2签名（APK签名方案）

V2签名是Google在Android 7.0引入的。它把签名信息嵌入到ZIP文件的中央目录之前，覆盖了整个APK文件。这意味着任何对APK的修改都会导致签名校验失败。

V2签名的优势很明显：

• 校验速度快（一次性校验整个文件）
• 安全性高（无法绕过签名校验）
• 支持增量更新

车载系统现在普遍要求V2签名。我建议所有新项目直接上V2，别再用V1了。

3.3.3 V3签名（密钥轮换）

V3签名在Android 9.0引入，最大的亮点是支持密钥轮换。什么意思呢？就是你可以用旧密钥签名的App，通过V3签名机制升级到新密钥，而不需要重新安装。

这个功能对车载系统特别有用。你想啊，一辆车可能要服役10年，签名密钥不可能10年不变。有了V3，OEM可以在OTA升级时无缝切换签名密钥。

3.4 实战：如何选择合适的签名方案？

说了这么多，到底该怎么选？我个人的建议是这样的：

1. 新项目：直接用V2签名。如果目标Android版本支持（9.0+），可以考虑V3。
2. 存量项目：如果还在用V1，尽快迁移到V2。迁移过程需要重新签名所有App，并且要确保系统支持V2校验。
3. OTA升级场景：强烈建议用V3。密钥轮换功能在车载生命周期管理里太重要了。

最后说一句：签名不是万能的，但不签名是万万不能的。车载系统的安全防线，签名是第一道门。把这道门守好了，后面的权限管理才能发挥作用。

下一章我们会聊到权限声明与用户授权，到时候再细说签名和权限之间的联动关系。