4. 安全威胁模型

在安全分区与加密存储系统的工程实践中,威胁建模不是一次性的文档工作,而是贯穿设计、实现、部署与运维的持续活动。本章聚焦六类最典型、最具破坏力的威胁:数据泄露、物理窃取、侧信道攻击、恶意软件、内部威胁与供应链风险。理解它们的攻击路径、作用面与防御边界,是后续分区策略、密钥管理与加密存储设计的前提。

一、核心原理:威胁模型是“假设的显式化”

威胁模型的核心价值在于把系统对“敌人是谁、能力多大、目标是什么”的隐含假设写成可验证的工程约束。一个可用的威胁模型至少包含四个要素:资产(密钥、明文、固件、日志、配置)、攻击者能力(远程/本地、物理接触、时间窗口、预算)、攻击面(接口、总线、调试口、供电、缓存、供应链环节)以及安全目标(机密性、完整性、可用性、可审计性)。

在分区与加密存储系统中,资产通常按敏感度分层:根密钥与主密钥位于最高层,数据加密密钥位于中间层,业务明文与缓存位于最外层。威胁模型的作用,就是判断每一层资产在每一类威胁下是否仍然受到保护,以及保护失效时的爆炸半径。

关键判断:加密存储并不等于安全存储。若密钥与密文同处一个可被物理读取的介质,或解密发生在不受信任的执行环境中,加密只能延缓攻击,不能阻止攻击。

二、六类威胁的攻击路径与防御要点

下面用一张关系图展示六类威胁与分区、加密存储关键组件之间的作用关系。图中左侧为威胁源,中间为被攻击的系统资产与接口,右侧为对应的防御控制。

威胁源 → 资产/接口 → 防御控制 数据泄露 越权读取 / 接口泄露 物理窃取 拆机 / 取盘 / 探针 侧信道攻击 功耗 / 时序 / 电磁 恶意软件 勒索 / 窃密 / 提权 内部威胁 滥用权限 / 数据外带 供应链风险 固件 / 组件 / 更新 分区与加密存储系统 根密钥 / 主密钥 安全分区 · 密钥槽 数据加密密钥 按分区派生 · 轮换 密文存储介质 Flash / SSD / 外部盘 调试口 / 总线 / 供电 JTAG · SPI · 电源轨 固件与更新通道 Bootloader · OTA 防御控制 最小权限 · 分区隔离 密钥不落盘 · 安全元件 防拆封装 · 掉电自毁 常量时间 · 噪声注入 签名验证 · 可信启动 审计 · 双人复核

三、方法流程:从资产清单到控制矩阵

工程上建议按以下流程建立威胁模型,并把它固化为可评审的清单:

  1. 资产识别与分级:列出密钥、明文、固件、日志、配置、证书等资产,标注机密性/完整性/可用性等级。
  2. 攻击面枚举:按物理、本地、远程、供应链四类接口逐一登记,包括调试口、总线、更新通道、日志导出、备份接口。
  3. 威胁映射:将六类威胁与资产、接口做交叉映射,形成“威胁—资产—控制”矩阵。
  4. 控制选择:为每个高风险组合选择预防、检测、响应三类控制,并明确责任人与验证方法。
  5. 验证与复盘:通过渗透测试、故障注入、供应链审计验证控制有效性,并定期更新模型。

下面给出一个简化的控制矩阵示例,便于在评审中直接使用:

威胁类型 主要作用面 预防控制 检测/响应
数据泄露 越权接口、日志、备份 分区隔离、最小权限、字段级加密 访问审计、异常导出告警
物理窃取 整机、存储介质、调试口 防拆封装、密钥不落盘、掉电自毁 拆机检测、离线取证
侧信道攻击 功耗、时序、电磁、缓存 常量时间实现、噪声注入、屏蔽 泄漏评估、TVLA 测试
恶意软件 操作系统、应用、驱动 可信启动、签名校验、最小化攻击面 完整性度量、EDR 告警
内部威胁 运维权限、密钥操作 职责分离、双人复核、临时授权 操作留痕、行为基线
供应链风险 固件、组件、更新通道 供应商审计、SBOM、签名更新 版本比对、异常回滚检测

四、案例与场景:一次“物理窃取 + 侧信道”组合攻击

某边缘存储设备部署在无人值守机房,攻击者拆机后取走存储介质,并利用设备调试口进行功耗采集。若系统仅对数据做了软件层加密,而密钥在启动时从同一介质读取并常驻内存,攻击者可通过以下路径获取明文:

攻击链:
1. 物理拆机 → 取下 Flash 芯片
2. 读取固件与密钥槽 → 发现密钥与密文同介质
3. 重新上电 → 采集解密阶段功耗曲线
4. 相关性分析 → 恢复数据加密密钥
5. 离线解密 → 获得业务明文

防御改造:
- 根密钥写入安全元件,不随介质迁移
- 调试口熔断/密码保护,拆机触发密钥擦除
- 解密算法改为常量时间实现,加入随机延迟
- 分区密钥按会话派生,掉电即失效

该案例说明:单一控制往往不足以对抗组合威胁。物理窃取提供了接触能力,侧信道攻击把接触能力转化为密钥恢复能力,二者叠加会击穿仅依赖“加密存储”的防线。

常见误区:把“加密”当作万能解。若密钥管理、分区隔离、可信启动和物理防护缺失,加密只是把明文问题转化为密钥问题,而密钥往往更集中、更脆弱。

五、复盘:威胁模型的三个工程习惯

  • 假设显式化:把“攻击者能否物理接触”“更新通道是否可信”写成明确假设,避免团队各自理解不同。
  • 控制可验证:每项控制都要有对应的测试方法或日志证据,不能只停留在设计文档。
  • 持续更新:供应链、固件、业务接口变化时,威胁模型必须同步修订,否则会迅速过期。