20、安全与隐私：权限模型、数据加密、安全通信、合规性要求
各位同学，今天我们来聊聊车机安全。说实话，在车载系统里谈安全，跟手机端还真不太一样。手机丢了你可以远程擦除，车机要是被攻破了，那可是关系到人身安全的大事。我在做某个车厂项目时，就亲眼见过测试车因为一个未授权的第三方应用读取了车辆CAN总线数据，导致仪表盘乱跳——嗯，那场面，至今难忘。
20.1 Android Automotive OS 的权限模型
Android Automotive 的权限模型，说白了就是「谁可以干什么」。它继承了AOSP的权限体系，但针对车载场景做了大量定制。
20.1.1 权限分级
我个人习惯把车机权限分成三个层级：
- 普通权限：比如访问网络、读取媒体文件。安装时自动授予，用户无感。
- 危险权限：比如读取位置、麦克风、摄像头。需要弹窗让用户确认。
- 签名权限：比如访问车辆信号（车速、车门状态）。只有系统应用或同签名的应用才能获取。
关键点：在车机上，很多危险权限其实不需要用户弹窗。比如导航应用读取位置——你想想看，用户都坐在车里了，还能去哪？所以系统会默认授予「同用户场景」下的权限。
20.1.2 车辆专属权限
Android Automotive 新增了一组 vehicle 开头的权限，专门控制车辆硬件接口。举个例子：
<!-- AndroidManifest.xml -->
<uses-permission android:name="android.car.permission.CAR_SPEED" />
<uses-permission android:name="android.car.permission.CAR_ENERGY" />
<uses-permission android:name="android.car.permission.CAR_INFO" />这些权限默认只授予系统应用。第三方应用想获取车速？门都没有。我在项目中遇到过，有个第三方地图厂商非要读取车速来做超速提醒，最后只能通过系统级代理服务间接提供——嗯，安全边界不能破。
20.2 数据加密：存储与传输
数据加密分两块：一块是存着的时候（静态数据），一块是传的时候（传输数据）。
20.2.1 静态数据加密
Android Automotive 默认启用了 文件级加密（File-Based Encryption, FBE）。每个用户的数据用不同的密钥加密，密钥由 GateKeeper 服务管理。
我个人建议，敏感数据一定要用 Android Keystore 来存储密钥。为什么？因为Keystore的密钥跑在TEE（可信执行环境）里，就算系统被root了，密钥也拿不走。
// 使用 Keystore 生成 AES 密钥
KeyGenerator keyGen = KeyGenerator.getInstance(
KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");
keyGen.init(
new KeyGenParameterSpec.Builder("my_car_key",
KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
.setBlockModes(KeyProperties.BLOCK_MODE_GCM)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
.build());
SecretKey key = keyGen.generateKey();避坑指南：我曾经把用户的车载支付密码直接存到SharedPreferences里，结果被安全审计打回来重做。记住：SharedPreferences是明文存储，永远不要放敏感信息。
20.2.2 传输数据加密
车机与云端通信，必须使用 TLS 1.2+。Android Automotive 默认启用了网络安全配置，禁止明文HTTP流量。
<!-- res/xml/network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config cleartextTrafficPermitted="false">
<trust-anchors>
<certificates src="system" />
</trust-anchors>
</base-config>
</network-security-config>你想想看，如果车机跟云端通信被中间人攻击，攻击者可以伪造OTA升级包，把恶意固件刷进车机——那后果就不只是隐私泄露了，是物理安全问题了。
20.3 安全通信：车内网络与外部连接
车机内部有多个ECU（电子控制单元），它们之间通过CAN、以太网、LIN等总线通信。Android Automotive 作为信息娱乐域的核心，必须保证这些通信的安全。
20.3.1 车内通信安全
Android Automotive 通过 CarService 来代理所有车辆信号访问。应用不能直接读写CAN总线，必须通过CarService的API。CarService内部做了权限校验和速率限制。
// 应用只能通过 CarService 获取车速
Car car = Car.createCar(context);
VehiclePropertyManager vpm =
(VehiclePropertyManager) car.getCarManager(VehiclePropertyManager.class);
int speed = vpm.getIntProperty(VehiclePropertyIds.PERF_VEHICLE_SPEED, 0);注意：千万不要在应用层直接打开Socket连接CAN总线。我曾经见过一个开发者为了「性能优化」直接访问CAN设备节点，结果导致车辆在行驶中误触发了刹车信号——嗯，这个开发者后来被调去写文档了。
20.3.2 外部通信安全
车机与手机、智能钥匙、路侧单元（RSU）的通信，建议使用 BLE（低功耗蓝牙） 或 NFC，并启用配对绑定和会话密钥协商。
Android Automotive 支持 Secure Element（安全元件），用于存储数字车钥匙的私钥。这个安全元件是独立的硬件芯片，跟主CPU隔离，就算系统被攻破，车钥匙也拿不走。
20.4 合规性要求
合规性这块，说白了就是「法律让你怎么做，你就得怎么做」。不同国家、不同地区的要求还不一样。
20.4.1 主要法规
| 法规/标准 | 适用地区 | 核心要求 |
|---|---|---|
| GDPR | 欧盟 | 用户数据收集需明确同意，支持数据删除 |
| CCPA | 美国加州 | 用户有权知道哪些数据被收集，有权拒绝出售 |
| 《个人信息保护法》 | 中国 | 最小必要原则，本地化存储，跨境传输需评估 |
| ISO 21434 | 全球 | 道路车辆网络安全工程，覆盖全生命周期 |
20.4.2 合规实践
我在做中国区项目时，遇到过最头疼的问题就是「数据本地化」。法规要求车辆位置数据、驾驶行为数据必须存储在中国境内的服务器上。我们当时做了两套后端：一套在国内，一套在海外，通过车机的区域码自动切换。
核心原则：
1. 只收集「最小必要」的数据——能不加就不加。
2. 数据加密存储，密钥与用户身份绑定。
3. 提供清晰的隐私政策，让用户知道数据去了哪里。
4. 支持用户一键删除所有个人数据（工厂重置）。
20.5 知识体系总览
下面这张图，是我自己整理的安全与隐私知识体系。你可以把它当成一张「检查清单」，做项目时对照着看，缺了哪块补哪块。
我的建议：做车机安全，不要想着「一步到位」。先搞定权限模型，再上加密，然后加固通信，最后过合规审计。一步一步来，稳扎稳打。我曾经见过一个团队，上来就搞硬件安全模块，结果基础权限都没配好，第三方应用直接读走了车辆VIN码——嗯，基础不牢，地动山摇。