安全与隐私：数据加密存储、网络安全通信、用户隐私保护、合规性检查（GDPR/CCPA）

说实话，车载应用开发里，安全与隐私这块是最容易被忽视，但出事后果最严重的。我见过不少团队，功能做得花里胡哨，结果一上合规审计，直接被打回重做。今天咱们就把这块硬骨头啃下来。

一、数据加密存储：别让用户数据裸奔

车载系统里存着大量敏感数据：导航历史、通讯录、支付信息、甚至生物特征。这些数据如果明文存储，一旦设备被物理接触，后果不堪设想。

1.1 本地存储加密策略

我个人习惯把数据分成三个等级：

等级	示例数据	加密方式
L1-公开	系统设置、主题偏好	不加密或简单校验
L2-敏感	导航历史、收藏地点	AES-256-GCM + 密钥链
L3-高度敏感	支付令牌、生物特征	硬件安全模块(HSM) + 分段加密

1.2 密钥管理

密钥怎么存？这是个经典问题。Android Keystore 系统是你的好朋友。它把密钥放在 TEE（可信执行环境）里，应用层根本拿不到原始密钥。

// 生成主密钥
val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

// 创建加密文件
val encryptedFile = EncryptedFile.Builder(
    context,
    File(filesDir, "user_data.db"),
    masterKey,
    EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
).build()

二、网络安全通信：车联网的命门

车载应用和云端通信，说白了就是车在高速公路上跑，数据在互联网上飞。中间人攻击、重放攻击、数据篡改，这些都是真实威胁。

2.1 TLS 配置要点

别用默认配置。Android 的默认 TLS 配置其实挺宽松的，你得手动收紧：

• 强制使用 TLS 1.2+：TLS 1.0/1.1 已经过时了，很多合规要求直接禁止
• 证书固定（Certificate Pinning）：防止中间人用伪造证书解密流量
• 双向认证（mTLS）：车和服务器互相验证身份，不只是服务器验证车

// 证书固定示例
val certificatePinner = CertificatePinner.Builder()
    .add("api.vehicle-cloud.com", 
         "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

2.2 SDL 协议的安全通信

SDL 协议本身支持安全通道。如果你在用 SDL 做车载应用，记得启用 PROTOCOL_VERSION_5 以上的加密模式：

// SDL 安全配置
val sdlSecurityConfig = SdlSecurityConfig()
sdlSecurityConfig.setSecurityLevel(SecurityLevel.ENCRYPTED)
sdlSecurityConfig.setServiceEncryptionRequired(
    ServiceType.NAVIGATION, true
)

三、用户隐私保护：不只是法律要求

用户隐私保护，说白了就是尊重用户。你想想看，你的车知道你每天几点出门、去过哪里、和谁通话——这些数据如果被滥用，用户会怎么想？

3.1 最小化数据收集

只收集必要的数据。我见过有些应用连用户的车载蓝牙设备列表都上传，这完全没必要。

• 数据分类：明确哪些是业务必须的，哪些是可选的
• 本地处理优先：能本地处理的，就别上传云端
• 匿名化/去标识化：如果必须上传，去掉个人标识信息

3.2 用户控制权

用户应该能随时查看、修改、删除自己的数据。Android Automotive 提供了 PrivacyManager API，可以方便地管理权限：

// 检查位置权限
val locationManager = getSystemService(LocationManager::class.java)
if (locationManager.isLocationEnabled) {
    // 用户已授权位置访问
} else {
    // 引导用户开启权限
}

四、合规性检查：GDPR/CCPA 不是摆设

如果你的车卖到欧洲或加州，GDPR 和 CCPA 就是必须遵守的。这不是选择题，是必答题。

4.1 GDPR 核心要求

要求	实现方式
数据主体权利	提供数据导出、删除接口
数据最小化	只收集业务必需数据
数据保护影响评估	上线前完成 DPIA 文档
数据泄露通知	72 小时内通知监管机构

4.2 CCPA 特殊要求

CCPA 比 GDPR 更强调用户的「选择退出」权利。用户可以说「我不要你卖我的数据」，你必须尊重这个选择。

• 明确的退出按钮：在设置页面提供「不要出售我的个人信息」选项
• 数据分类清单：列出你收集的所有数据类型和用途
• 响应时限：用户请求后 45 天内必须响应

五、知识体系总览

下面这张图总结了本章的核心逻辑，你可以把它当作安全开发的检查清单：

这四个模块不是孤立的。数据加密存储是基础，网络安全通信是通道，用户隐私保护是目标，合规性检查是底线。少了任何一个，你的应用都可能出问题。