Android Automotive与IoT组件安全：车载系统与物联网设备中组件的特殊安全考量
说实话，做移动端安全这么多年，我接触最多的还是手机和平板。但这两年，车载系统和IoT设备的安全需求突然就涌上来了。我记得第一次接到车载系统的安全审计任务时，心里还有点打鼓——这玩意儿跟手机完全不是一个玩法。
你想想看，手机被攻击了，最多是隐私泄露、钱包被盗。但车载系统呢？那可是关系到人身安全的东西。IoT设备也一样，智能门锁被攻破，你家就成了别人的后花园。所以这一章，我想跟你聊聊这些特殊场景下的组件安全。
车载系统的特殊性：不止是Android
Android Automotive跟手机上的Android，说白了就是同一个爹但性格完全不同的两个孩子。车载系统有几个让我印象深刻的点：
- 生命周期完全不同：手机App你可以随便杀后台，但车载的导航、音乐、电话这些服务，用户希望它们永远活着。这就导致Activity和Service的管理策略必须调整。
- 多用户场景：驾驶员、副驾、后排乘客，可能同时操作不同的屏幕。我记得在某个项目中，就因为没处理好跨用户组件调用，导致副驾能通过一个Intent直接拉起驾驶员的导航设置界面——这要是被恶意利用，后果不堪设想。
- 物理访问风险：车机就在车里，攻击者可能物理接触到设备。USB调试、ADB端口、甚至直接拆机，这些在手机端不太现实的攻击面，在车载场景下都是真实威胁。
核心差异点：车载系统的组件暴露面更大，且失效后果更严重。一个Provider数据泄露在手机上可能只是隐私问题，在车上可能意味着车辆控制信息被窃取。
车载Activity劫持：方向盘后的危机
Activity劫持在手机上我们已经聊了很多，但在车载场景下，这个问题被放大了。为什么？
驾驶员在开车时，注意力高度集中在路况上。如果这时候一个恶意Activity突然覆盖了导航界面，驾驶员可能根本不会注意到——他只会跟着导航走，结果被带到了错误的地方。我在一次测试中模拟过这个场景：一个后台Service通过FLAG_ACTIVITY_NEW_TASK启动了一个伪造的导航界面，覆盖了真实的导航App。说实话，我自己开车测试时都没第一时间发现异常。
防护上，我建议重点关注以下几点：
- 严格检查Intent的来源：使用
getCallingPackage()验证调用者身份，别让任何App都能启动你的导航Activity。 - 使用系统级窗口标志：比如
FLAG_WINDOW_IS_OBSCURED，检测是否有其他窗口覆盖在你的Activity之上。 - 关键操作二次确认：涉及车辆控制（如解锁、启动、导航目的地变更）的Activity，必须加入用户确认机制。
// 检查是否有窗口覆盖
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
val isObscured = window.attributes.flags and WindowManager.LayoutParams.FLAG_WINDOW_IS_OBSCURED != 0
if (isObscured) {
// 有覆盖窗口，拒绝执行敏感操作
showWarning("检测到屏幕覆盖，操作已取消")
return
}
}我的习惯：在车载App中，我会对所有涉及安全的关键Activity添加一个定时心跳检测。如果Activity在5秒内没有收到用户的有效交互（触摸、语音），就自动回退到安全界面。这个机制在手机端可能有点多余，但在车上非常实用。
Provider数据泄露：车载信息的潘多拉魔盒
ContentProvider在车载系统里用得比手机端更频繁。为什么？因为车载系统需要共享大量数据：车辆状态、位置信息、用户配置、甚至驾驶行为数据。这些数据如果被恶意App通过Provider窃取，后果非常严重。
我曾经审计过一个车载信息娱乐系统，发现它的车辆诊断Provider居然没有设置任何权限保护。任何安装在车机上的第三方App，都可以通过这个Provider读取发动机转速、车速、油量、甚至刹车状态。你想想看，如果这个数据被恶意App实时监控，攻击者就能知道你的驾驶习惯、常去的地点、甚至判断你什么时候在家。
| 数据类型 | 泄露风险 | 防护建议 |
|---|---|---|
| 车辆VIN码 | 车辆身份被冒用 | 仅允许系统级App读取 |
| 实时GPS位置 | 行踪被追踪 | 使用签名权限保护 |
| 驾驶行为数据 | 隐私泄露、保险欺诈 | 加密存储，按需授权 |
| 车辆控制指令 | 远程控制车辆 | 必须用户确认+签名验证 |
防护上，我建议采用分层策略：
- 权限分级：将Provider暴露的数据分为公开、受控、敏感三个等级。公开数据无需权限，受控数据需要普通权限，敏感数据必须签名权限。
- URI权限控制：使用
grantUriPermission机制，临时授权而不是永久开放。 - 数据脱敏：对于非必要的查询，返回脱敏后的数据。比如位置信息可以模糊到街道级别，而不是精确坐标。
<!-- AndroidManifest.xml 中的Provider声明 -->
<provider
android:name=".VehicleDataProvider"
android:authorities="com.example.vehicle.provider"
android:exported="true"
android:protectionLevel="signature"
android:permission="com.example.vehicle.READ_VEHICLE_DATA" />我曾经踩过的坑：在某个项目中，我为了调试方便，给Provider加了一个android:protectionLevel="dangerous"的权限。结果上线后才发现，任何App只要用户授权一次，就能永久读取车辆数据。后来我改成了signature级别，只允许同签名的App访问。这个教训让我明白：车载系统的权限策略一定要比手机端更严格。
IoT设备的组件安全：资源受限下的妥协
IoT设备跟手机、车机又不一样。它们的硬件资源极其有限——可能只有几百KB的内存，CPU主频也低得可怜。这就导致很多在手机上成熟的安全方案，在IoT上根本跑不起来。
我记得有一次帮客户审计一款智能门锁，它的Android系统是基于Android 6.0定制的。为什么用这么老的版本？因为新版本的Android对硬件要求太高，跑不动。但问题来了，Android 6.0的组件安全机制远不如现在完善，很多漏洞都是公开的。
IoT设备中常见的组件安全问题：
- BroadcastReceiver滥用：很多IoT设备用广播来传递状态信息（比如门锁状态、传感器数据）。但这些广播往往是隐式的，任何App都能监听。我见过一个智能灯泡，它的开关状态通过隐式广播发送，结果被隔壁的恶意App截获，实时监控用户是否在家。
- Service持久化问题：IoT设备通常需要Service长期运行。但如果Service的
onStartCommand返回START_STICKY，被杀死后会自动重启，这本身没问题。但有些开发者为了省电，把Service的优先级设得很低，结果系统频繁杀死又重启，反而更耗电。 - Provider的本地文件泄露：IoT设备的存储空间小，很多开发者直接把数据存在SharedPreferences或者本地文件里，然后通过Provider暴露出去。如果Provider没有做好路径遍历防护，攻击者可能读取到任意文件。
IoT安全的核心矛盾：安全性和资源消耗之间的平衡。你不能在128KB内存的设备上跑完整的TEE（可信执行环境），但也不能完全不设防。我的做法是：优先保护最关键的数据和功能，其他的可以适当放宽。
车载与IoT的组件安全框架
说了这么多，我想用一张图来总结一下车载和IoT场景下组件安全的特殊考量。这张图是我在实际项目中总结出来的，希望能帮你理清思路。
实战建议：从手机思维到车载/IoT思维的转变
如果你跟我一样，之前主要做手机端安全，那么切换到车载或IoT场景时，有几个思维转变是必须的：
- 从「用户主动操作」到「系统自动运行」：手机上的安全机制很多依赖用户判断（比如授权弹窗），但在车上，驾驶员没空看弹窗。所以安全策略必须自动化、无感化。
- 从「隐私保护」到「人身安全保护」：手机端我们最担心的是隐私泄露，但车载和IoT场景下，安全漏洞可能导致物理伤害。这个优先级的变化，会直接影响你的安全设计决策。
- 从「单一设备」到「多设备协同」：车载系统往往跟手机、云端、甚至其他车辆通信。组件安全不再局限于单个设备，而是要考虑整个生态的安全。
- 从「最新系统」到「老旧系统」：IoT设备经常使用定制化的老旧Android版本。你不能假设系统层面的安全补丁已经到位，必须在应用层自己做好防护。
我的建议：如果你刚开始接触车载或IoT安全，可以先从最基础的组件暴露面分析做起。用dumpsys package查看所有导出的组件，然后逐个评估它们是否真的需要暴露。很多时候，你会发现80%的导出组件其实都可以改成不导出。这一步做好了，后面的工作会轻松很多。
嗯，这一章的内容就到这里。车载和IoT的组件安全，说白了就是「场景决定策略」。手机上的经验可以借鉴，但不能照搬。下一章我们会聊聊更具体的攻击手法和防护方案，到时候我会分享一些我在实际项目中用过的工具和技巧。
公众号:蓝海资料掘金营，微信deep3321