1. 平板安全概述：平板面临的安全威胁、安全架构分层、硬件安全基础概念

大家好，我是你们这堂课的讲师。做了十几年嵌入式安全，从功能机时代一路摸爬滚打到现在的智能平板，说实话，这行水很深。今天咱们先聊聊平板安全到底是个什么事儿。

很多人觉得平板嘛，不就是个大号手机？安全思路照搬就行。嗯，这话对了一半。平板的使用场景更复杂——家里老人刷视频、孩子上网课、商务人士处理机密文件，甚至工厂里当控制终端。你想想看，攻击面比手机宽多了。

1.1 平板面临的安全威胁

我习惯把威胁分成三类：软件层、硬件层、物理层。咱们一个个说。

1.1.1 软件层威胁

  • 恶意应用：第三方应用商店、破解版软件，这是老生常谈了。我在项目中遇到过一款号称"省电神器"的App，后台偷偷上传通讯录和GPS数据。
  • 系统漏洞：Android/Linux内核漏洞、驱动提权。平板厂商的OTA更新往往比手机慢，漏洞窗口期更长。
  • 网络攻击：公共Wi-Fi中间人攻击、DNS劫持。平板经常在家和办公室之间切换，网络环境复杂。

1.1.2 硬件层威胁

  • JTAG/SWD调试接口：如果量产板没熔断efuse，攻击者可以直接通过调试接口读取内存。
  • 侧信道攻击：功耗分析、电磁辐射分析。别觉得这离你很远，我在实验室里用一台示波器加半小时，就能从平板的电源纹波里提取出AES密钥。
  • 故障注入：电压毛刺、时钟毛刺。曾经有个团队用激光照射芯片表面，成功绕过了安全启动校验。

1.1.3 物理层威胁

  • 设备丢失/被盗：这是最直接的。没有全盘加密的话，拆个eMMC用读卡器就能把数据全拷走。
  • 冷启动攻击：内存数据在断电后几十秒内不会完全消失，低温下能保持更久。攻击者可以重启设备并快速读取DRAM中的加密密钥。
⚠️ 注意： 很多平板厂商只关注软件安全，觉得装个杀毒软件就万事大吉。但真正的攻击者往往从硬件层面下手，因为硬件漏洞一旦被利用，软件层的防护形同虚设。

1.2 安全架构分层

我个人习惯把平板的安全架构分成四层。每一层都有自己的职责，也都有各自的坑。

层级 核心组件 主要职责
应用层 Android Framework、App沙箱 权限管理、数据隔离、应用签名校验
系统层 Linux内核、SELinux、KeyStore 进程隔离、文件系统加密、密钥管理
固件层 Bootloader、TrustZone、TEE 安全启动、可信执行环境、硬件密钥存储
硬件层 eFuse、TPM、安全元件(SE) 物理不可克隆、防篡改、真随机数生成

这里我想强调一点：安全是木桶效应。你应用层做得再严，如果Bootloader能被刷写，那一切归零。我曾经帮一家厂商做安全审计，他们的TEE里跑着指纹比对逻辑，但TEE的镜像竟然没有签名校验——攻击者直接替换TEE镜像就能拿到指纹数据。

1.3 硬件安全基础概念

好，接下来咱们聊聊硬件安全里几个绕不开的概念。这些是后面所有章节的基石。

1.3.1 信任根 (Root of Trust, RoT)

说白了，就是整个安全体系的"第一块砖"。它必须是硬件层面不可篡改的。常见的信任根有：

  • Boot ROM：芯片出厂时固化在ROM里的代码，只读不可写。它负责校验Bootloader的签名。
  • eFuse：一次性可编程存储单元。用来存储公钥哈希、设备状态等。熔断后不可恢复。
  • PUF (物理不可克隆函数)：利用芯片制造过程中的工艺偏差生成唯一ID。嗯，这个后面会专门讲。
💡 实战技巧： 我建议在设计安全启动链时，把信任根放在Boot ROM里。因为ROM是掩膜层，攻击者无法修改。eFuse虽然也安全，但需要保证熔断流程在生产线上不出错——我曾经见过一批平板因为eFuse熔断电压不稳，导致公钥哈希写入错误，整批设备变砖。

1.3.2 安全启动 (Secure Boot)

安全启动的流程其实不复杂：

  1. 上电后，Boot ROM执行，从eFuse读取公钥。
  2. 用公钥校验Bootloader的签名。
  3. Bootloader校验Linux内核的签名。
  4. 内核校验系统分区的dm-verity哈希树。

每一级都校验下一级的完整性，形成一条信任链。如果任何一级校验失败，设备拒绝启动。

// 伪代码示意
if (verify_signature(bootloader_img, pubkey_from_efuse) == FAIL) {
    halt(); // 死循环，拒绝启动
}
// 校验通过，跳转到Bootloader
jump_to(bootloader_img);

这里有个坑：回滚攻击。攻击者可能刷回一个旧版本的系统，旧版本可能有已知漏洞。所以安全启动必须结合版本号回滚防护——每次升级后，eFuse里记录当前版本号，禁止刷写更低版本。

1.3.3 可信执行环境 (TEE)

TEE是SoC内部的一个隔离区域，和普通操作系统（REE）并行运行。REE跑Android，TEE跑安全服务（指纹比对、支付认证、DRM解密）。

为什么需要TEE？因为Android系统再安全，内核也是宏内核，漏洞多。而TEE的内核极小（通常只有几万行代码），攻击面小得多。

🔑 关键点： TEE和REE之间的通信通过SMC（安全监控调用）指令完成。REE不能直接访问TEE的内存，只能通过共享缓冲区传递数据。这个共享缓冲区的大小和地址必须由TEE端严格校验——我见过一个案例，攻击者通过构造超长的共享缓冲区描述符，触发了TEE内核的缓冲区溢出。

1.3.4 硬件密钥管理

密钥不能裸奔。这是铁律。硬件安全模块（HSM）或者SoC内置的密钥管理单元（KMU）负责：

  • 密钥生成：使用硬件真随机数生成器（TRNG），而不是软件伪随机。
  • 密钥存储：存储在eFuse或OTP中，或者用PUF派生。绝对不能明文存在Flash里。
  • 密钥使用：密钥只在硬件内部使用，软件只能通过API调用加解密操作，永远拿不到密钥本身。

举个例子，Android的KeyStore在硬件支持下，会生成一个设备唯一密钥（Device Unique Key, DUK）。这个密钥由TEE管理，用来加密用户数据加密密钥（DEK）。DEK再加密实际的文件数据。这样即使攻击者物理拆了eMMC，拿到的也是密文。

⚠️ 避坑指南： 我曾经见过一个方案，厂商把DEK直接存在了eMMC的某个隐藏分区里，然后用一个固定的密钥加密。这相当于把家门钥匙放在门口地毯下面。真正的做法应该是：DEK由TEE内的硬件密钥派生，且每次启动时重新生成（因为DEK本身不持久化，持久化的是加密后的DEK）。

1.4 小结

这一章咱们把平板安全的整体轮廓画出来了。威胁从软件到硬件再到物理，层层递进。安全架构从应用层到硬件层，每一层都不能有短板。硬件安全的基础概念——信任根、安全启动、TEE、密钥管理——是后面所有章节的基石。

下一章我会深入讲安全启动链的实战设计，包括如何选择签名算法、如何设计密钥层级、以及生产线上如何安全地烧录密钥。到时候我会拿一个真实的SoC方案来拆解，咱们不见不散。

← 上一章 📖 返回目录 下一章 →