2 芯片安全属性模型:核心概念、原理机制、实战要点
问题背景:为什么需要安全属性模型
芯片安全验证首先要回答一个问题:我们要证明什么?功能验证关注“功能是否符合规格”,而安全验证关注“攻击者能否破坏某一安全属性”。如果没有安全属性模型,漏洞分析就会失去目标,测试结果也难以定性、定级。
核心概念:五大安全属性
安全属性模型是芯片安全验证的测量坐标。每个属性代表一类需要被保护的安全能力,也为漏洞分析提供判定基准。
- 保密性(Confidentiality):密钥、固件、用户数据等敏感信息不能被未授权读取或泄露。
- 完整性(Integrity):代码、数据、配置、校验值等不能被非授权修改或替换。
- 可用性(Availability):芯片在预期条件下可持续提供正确服务,不能因攻击导致拒绝服务。
- 真实性(Authenticity):芯片、用户、代码、消息的身份可验证,认证流程不可被绕过。
- 不可否认性(Non-repudiation):安全操作行为可记录、可追踪,不能抵赖或伪造。
原理机制:属性-威胁-验证映射
在工程实践中,安全属性不是静态标签,而是驱动验证活动的引擎。每种属性都对应一条可追踪的验证链路:安全目标 → 威胁模型 → 测试方案 → 判定准则。
安全属性 = 安全目标 + 攻击面 + 验证判据
失效结果 = 攻击是否破坏了目标属性
其工作机制分为三个环节:
- 安全目标分解:将加密、认证、安全启动等功能映射为具体安全属性。
- 威胁建模关联:为每个属性定义攻击面,如侧信道、故障注入、物理篡改、逻辑漏洞。
- 验证闭环:执行攻击测试,判定属性是否被破坏,并将结果回注设计修复。
安全属性验证流程步骤
- 资产识别:明确密钥、固件、PUF、安全存储、调试接口等资产分布。
- 属性映射:为每项资产建立安全属性矩阵,确定主要属性与从属属性。
- 威胁建模:基于资产、攻击面、攻击路径建立威胁清单。
- 用例设计:针对属性-威胁条目,设计功能测试、负向测试和攻击测试用例。
- 攻击模拟:执行侧信道采集、故障注入、接口协议攻击等测试。
- 失效判定:依据判定准则确认安全属性是否被破坏,并评定严重等级。
- 风险收敛:验证缓解措施后,对关键攻击场景进行回归复测。
案例说明:安全MCU属性验证
- 保密性验证:对 AES-128 执行 CPA 侧信道分析,使用 10000 条能量迹恢复密钥,判定“保密性失效”。
- 完整性验证:绕过固件签名校验,在 Flash 中注入 1 字节改变,观察安全启动是否被阻断。
- 真实性验证:利用电压故障注入跳过 RSA-SHA256 校验代码段,使设备进入未授权调试模式,判定“真实性失效”。
- 可用性验证:向安全邮箱发送大量非法指令,占满硬件密码引擎,导致合法操作超时。
- 不可否认性验证:检查安全日志是否可被外部重置或伪造,若审计记录缺失,判定“不可追溯”。
核心属性与验证焦点总结
| 安全属性 | 核心问题 | 验证焦点 | 典型攻击手段 | 失效判定示例 |
|---|---|---|---|---|
| 保密性 | 敏感数据是否泄露? | 密钥、数据非授权读取 | 侧信道、内存探针 | 测试密钥被恢复 |
| 完整性 | 数据或代码是否被篡改? | 安全启动链、固件校验 | Flash注入、总线篡改 | 哈希校验被绕过 |
| 可用性 | 攻击者能否中断服务? | 硬件引擎、安全通信 | 拒绝服务、资源耗尽 | 合法操作超时失败 |
| 真实性 | 身份是否可被伪造? | 认证流程、数字签名 | 故障注入、协议重放 | 绕过签名验证进入调试模式 |
| 不可否认性 | 行为是否可追溯? | 安全日志、审计记录 | 日志擦除、日志伪造 | 审计记录缺失或不可信 |
常见误区提醒
- 误区1:把安全属性当成文档清单,没有映射到具体攻击路径。
- 误区2:混淆功能验证与安全验证,以为“功能正常”等于“属性安全”。
- 误区3:只关注保密性和完整性,忽略真实性、可用性与不可否认性。
- 误区4:发现漏洞后不判断破坏了哪些属性,导致漏洞报告难以定级。
- 误区5:先做渗透测试后做威胁建模,造成测试用例覆盖不完整。
实战准备清单
- 验证开始前,建立安全属性矩阵,明确每个资产的属性优先级。
- 为每个属性编写可执行的攻击场景和明确判定标准。
- 安全验证报告必须标注“破坏属性”和“攻击路径”。
- 每次回归测试至少覆盖核心属性的代表性攻击用例。
提示:安全属性模型应在芯片开发全周期中保持稳定。新攻击手段出现时,只扩展威胁库和测试用例,不轻易改变属性定义。