一、安全目标概述：从业务需求到安全起点
各位同学，咱们今天聊的是整个课程的第一块基石——安全目标。我做了十几年芯片安全，见过太多项目上来就画架构、写代码，结果流片回来发现安全漏洞，那叫一个痛苦。所以，先把安全目标搞清楚，比什么都重要。
1.1 什么是安全目标？
安全目标，说白了就是——你希望你的系统在安全方面达到什么效果。它不是一句空话，而是一个可衡量、可验证的声明。
举个例子：
- “我的芯片要防攻击”——这不是安全目标，太模糊了。
- “我的芯片在侧信道攻击下，密钥泄露概率低于 10⁻⁶”——这才是安全目标。
我个人习惯把安全目标拆成两个层面：
- 业务层面：系统要保护什么资产？谁可以访问？
- 技术层面：用什么机制来保护？抵抗什么强度的攻击？
核心观点：安全目标是连接“业务需求”和“技术实现”的桥梁。没有它，你的安全设计就是无头苍蝇。
1.2 安全目标与业务需求的关系
你想想看，业务部门说“我们要做一款支付芯片”，那安全目标就得跟着业务走：
| 业务需求 | 对应的安全目标 | 我见过的坑 |
|---|---|---|
| 用户支付数据不能泄露 | 机密性：传输和存储加密 | 有人只加密了传输，存储是明文 |
| 交易记录不能篡改 | 完整性：HMAC 或数字签名 | 忘了保护日志，攻击者改了审计记录 |
| 系统不能随便宕机 | 可用性：冗余设计、抗 DoS | 安全模块成了单点故障 |
| 确认是合法用户在操作 | 真实性：身份认证、生物识别 | 只验密码，没防重放攻击 |
| 用户不能抵赖自己发起的交易 | 不可否认性：数字签名、审计日志 | 日志没防篡改，法庭上不认 |
我曾经在一个项目中，业务方说“我们要防黑客”，结果安全团队直接上了全套军用级加密。芯片面积翻倍、功耗超标，最后产品根本没法量产。嗯，这就是安全目标和业务需求脱节的典型下场。
我的建议：每次定义安全目标前，先问三个问题：1）业务最怕什么？2）攻击者有什么资源？3）我们愿意花多少成本？
1.3 常见的安全目标分类
安全目标分类，业内基本沿用 CIA 三元组，再加两个扩展。我按自己的理解给你捋一遍：
1. 机密性（Confidentiality）
说白了就是——不该看的人看不到。在硬件层面，这涉及到：
- 存储加密（比如 eMMC 加密、NAND 加密）
- 总线加密（防止嗅探）
- 侧信道防护（防止通过功耗、电磁泄露偷密钥）
我记得有一次做智能卡芯片，攻击者通过分析功耗曲线，直接把 AES 密钥还原出来了。从那以后，我对侧信道防护再也不敢马虎。
2. 完整性（Integrity）
就是——数据没被改过。硬件上常用：
- HMAC（哈希消息认证码）
- 数字签名
- 安全启动（Secure Boot）——验证固件没被篡改
你想想看，如果攻击者改了你的固件，你的芯片就成了人家的傀儡。完整性是底线。
3. 可用性（Availability）
系统该干活的时候得能干活。硬件层面：
- 冗余设计（双核、热备份）
- 抗 DoS 攻击（比如限制错误尝试次数）
- 安全模块不能成为瓶颈
我曾经见过一个设计，安全模块每次操作要 100ms，结果整个系统响应时间超标，产品直接被客户退货。
4. 真实性（Authenticity）
确认你是谁。硬件上常见：
- 物理不可克隆函数（PUF）——芯片唯一的“指纹”
- 安全元件（SE）——存储密钥和证书
- 硬件信任根（RoT）——从启动开始就验证身份
5. 不可否认性（Non-repudiation）
做了就是做了，赖不掉。硬件层面：
- 安全时钟（确保时间戳可信）
- 防篡改日志（写进去就改不了）
- 数字签名（私钥在硬件里，别人伪造不了）
注意：不可否认性在硬件里最容易出问题。我见过一个项目，日志存在外部 Flash 里，攻击者直接拔掉 Flash 换了块空的，所有审计记录全没了。所以，硬件级别的防篡改存储是必须的。
1.4 安全目标之间的关系
这五个目标不是孤立的，它们经常互相影响。我画了一张图，帮你理清关系：
从图上你能看到：
- 业务需求是源头，驱动所有安全目标
- 机密性和完整性是基础，几乎所有安全系统都离不开
- 真实性和不可否认性往往依赖完整性（比如签名防篡改）
- 可用性经常和其他目标冲突——加密太强了，性能就下来了
实战经验：我在做车规芯片时，业务要求“紧急制动指令必须在 10ms 内响应”。这时候可用性优先级最高，机密性可以适当让步（比如用轻量级加密）。安全目标之间要有取舍，没有银弹。
1.5 小结：安全目标不是写文档，是指挥棒
好了，这一章的核心就这些。记住：
- 安全目标要可衡量、可验证
- 它必须从业务需求来，不能拍脑袋
- 五个目标（CIA + 真实性 + 不可否认性）要综合考虑
- 目标之间有冲突，需要权衡