19、安全与隐私：Android Automotive 安全模型、数据加密与存储、隐私权限管理
车载系统安全，说实话，跟手机安全完全是两码事。
手机丢了，最多损失点个人数据。车机被攻破了，那可是要命的事。我在做第一代量产项目时，就深刻体会到了这一点——安全不是功能，是底线。
这一章，我们聊聊Android Automotive的安全模型、数据怎么加密、权限怎么管。嗯，都是硬骨头，但必须啃下来。
19.1 Android Automotive 安全模型
Android Automotive的安全模型，说白了就是「隔离+授权」。隔离是让各模块互不干扰，授权是让该访问的才能访问。
19.1.1 系统架构安全分层
我习惯把安全模型分成三层来看：
- 硬件层：TrustZone、SE（安全元件）、HSM（硬件安全模块）
- 内核层：SELinux、dm-verity、文件系统加密
- 应用层：权限模型、Sandbox、签名验证
这三层缺一不可。我曾经在项目里只关注了应用层权限，结果内核层SELinux策略没配好，导致一个第三方应用能读到系统日志——嗯，那段时间加班改策略，记忆犹新。
19.1.2 SELinux 策略要点
Android Automotive里，SELinux是强制访问控制的核心。车机里多了很多汽车特有的服务，比如Vehicle HAL、CarService，这些都得单独配策略。
关键原则：最小权限原则。只给服务必要的权限，多一个都不要。
举个例子，Vehicle HAL需要访问CAN总线，但不需要访问网络。那策略里就要明确：
# 允许Vehicle HAL访问CAN设备
allow vehicle_hal vehicle_can_device:chr_file rw_file_perms;
# 明确禁止访问网络
neverallow vehicle_hal network_device:chr_file *;我见过一个项目，直接把车载服务放进了system_app域，结果权限大得吓人。后来花了三周才把策略拆干净。所以，一开始就按最小权限来，能省很多事。
19.1.3 安全启动链
安全启动链，就是确保从BootROM到内核再到系统，每一级都经过签名验证。Android Automotive要求必须启用Verified Boot。
这里有个坑：车机的OTA升级频率低，但一旦升级失败，车就变砖了。所以，我建议在安全启动链里加入「回滚保护」机制——新版本签名后，旧版本就不能再启动了。这样能防止攻击者刷回有漏洞的老版本。
注意：回滚保护要谨慎配置。如果新版本有bug，用户想降级都不行。所以，OTA前一定要充分测试。
19.2 数据加密与存储
车机里存的数据，比手机敏感得多。导航历史、驾驶行为、甚至家里的车库门密码——这些一旦泄露，后果很严重。
19.2.1 文件级加密 vs 全盘加密
Android Automotive 10之后，默认使用文件级加密（FBE）。全盘加密（FDE）已经过时了。
| 加密方式 | 特点 | 适用场景 |
|---|---|---|
| 全盘加密（FDE） | 整个分区一起加密，启动时需密码 | 早期Android版本 |
| 文件级加密（FBE） | 每个文件单独加密，不同用户不同密钥 | Android 10+，多用户场景 |
为什么FBE更适合车机？因为车机有多个用户：驾驶员、乘客、访客。FBE能让每个用户的数据隔离加密。我做过一个项目，需要支持「代客泊车模式」——代驾司机只能用车机导航，看不到车主的历史记录。用FBE，给代驾模式单独一个加密密钥，完美解决。
19.2.2 密钥管理
加密的密钥放哪？这是个核心问题。
Android Automotive使用Keymaster HAL来管理密钥。密钥存储在TrustZone或独立的安全芯片里，应用层拿不到明文密钥。
我建议：
- 用户密钥：用锁屏密码派生，存在TEE里
- 设备密钥：在工厂预置，用于OTA签名验证
- 临时密钥：用于会话加密，用完即销毁
小技巧：如果车机没有独立安全芯片，可以用Android的StrongBox KeyStore。它利用TEE提供硬件级密钥保护，性能稍差，但安全等级够用。
19.2.3 数据存储最佳实践
我总结了几条经验：
- 敏感数据必须加密存储：比如用户密码、Token、驾驶行为数据。用EncryptedSharedPreferences或Jetpack Security库。
- 日志里不要打印敏感信息：我见过有人把用户密码直接log出来，这简直是给攻击者送人头。
- 临时文件用完即删：车机内存有限，临时文件不及时清理，既占空间又留隐患。
- 使用Android Keystore：不要自己写加密算法，用系统提供的Keystore，它底层调用了硬件安全模块。
// 使用EncryptedSharedPreferences存储敏感数据
MasterKey masterKey = new MasterKey.Builder(context)
.setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
.build();
SharedPreferences sharedPreferences = EncryptedSharedPreferences.create(
context,
"secure_prefs",
masterKey,
EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
);
sharedPreferences.edit().putString("user_token", token).apply();19.3 隐私权限管理
隐私权限，是Android Automotive里最敏感的话题。车机上的传感器比手机多得多：GPS、摄像头、麦克风、车速传感器、方向盘角度传感器……这些数据一旦被滥用，用户毫无隐私可言。
19.3.1 权限模型的变化
Android Automotive的权限模型，跟手机版Android基本一致，但多了几个汽车特有的权限：
android.car.permission.CAR_SPEED：读取车速android.car.permission.CAR_MILEAGE：读取里程android.car.permission.CAR_INFO：读取车辆信息（VIN等）
这些权限默认只授予系统应用。第三方应用想用？得用户明确授权。
19.3.2 运行时权限申请
车机上的权限申请，跟手机有个很大的不同：用户可能正在开车。
你想想看，如果导航App突然弹出一个权限对话框，用户正在高速上，手一抖点错了怎么办？
所以，我建议：
- 权限申请时机要合理：不要在驾驶过程中弹窗。可以在停车时，或者App首次启动时申请。
- 使用HMI规范：车机的UI交互有严格规范，权限对话框要符合车载HMI设计，字体大、按钮大、操作简单。
- 提供「仅本次允许」选项：有些权限（比如麦克风），用户可能只想在打电话时用一次。给这个选项，能提升用户信任感。
核心原则：车机上的权限管理，安全第一，用户体验第二。不要为了用户体验而牺牲安全。
19.3.3 隐私仪表盘
Android 12之后，系统提供了隐私仪表盘（Privacy Dashboard）。用户可以一目了然地看到：哪些App在什么时间访问了哪些敏感权限。
在车机上，这个功能尤其重要。因为车机可能同时运行多个App，用户需要知道：导航App是不是在偷偷录音？音乐App是不是在读取位置？
我建议在车机设置里，把隐私仪表盘放在显眼位置。最好再加一个「一键关闭所有敏感权限」的开关——嗯，这个功能我曾在项目里强烈要求加上，用户反馈非常好。
19.3.4 汽车特有的隐私场景
有几个场景，是手机没有的，但车机必须处理：
- 代客模式：代驾司机用车时，车主的数据必须完全隔离。代驾模式结束后，所有临时数据要彻底清除。
- 租车场景：租车用户的数据，在还车后必须全部删除。包括导航历史、蓝牙配对记录、登录账号等。
- 紧急呼叫（eCall）：这个功能可以突破权限限制，在紧急情况下自动发送车辆位置。但要注意，eCall的数据只能用于救援，不能用于其他目的。
法律合规提醒：不同国家对车载数据隐私有不同法规。比如欧盟的GDPR、中国的《个人信息保护法》。做车机隐私功能时，一定要咨询法务团队。
19.4 安全与隐私的架构图
下面这张图，是我梳理的Android Automotive安全与隐私整体架构。从硬件到应用，每一层都有对应的安全机制。
这张图里，每一层都环环相扣。硬件层提供信任根，内核层做强制访问控制，框架层管理权限和加密，应用层负责用户体验。少了任何一层，安全模型都不完整。
19.5 总结
安全与隐私，是车载系统的生命线。Android Automotive提供了从硬件到应用的完整安全模型，但工具再好，也得会用。
我个人习惯，做安全设计时遵循三个原则：
- 最小权限：能不给的权限，坚决不给
- 纵深防御：多层防护，单点失效不影响整体
- 默认安全：出厂配置就是最安全的，用户不需要额外设置
记住，安全不是做完功能后加的补丁，而是从架构设计第一天就要考虑的事。希望这一章的内容，能帮你少踩一些坑。
公众号:蓝海资料掘金营，微信deep3321