2. 安全基础
在PSA安全架构与设备可信工程中,所有安全机制最终都可以追溯到几个最基础的安全属性。理解这些属性之间的边界、依赖与冲突,是后续设计可信根、安全启动、访问控制和审计体系的前提。本节围绕CIA三元组、认证、授权、审计以及常见术语展开,帮助建立统一的安全语言。
一、核心原理:CIA三元组与安全目标
信息安全领域最经典的模型是CIA三元组,即机密性(Confidentiality)、完整性(Integrity)和可用性(Availability)。它们分别回答三个问题:信息是否只被该看的人看到、信息是否未被非法篡改、信息和服务是否在需要时可用。
- 机密性:防止未授权读取。典型手段包括加密、访问控制、密钥管理、最小权限。在设备可信工程中,机密性不仅保护用户数据,也保护设备密钥、证书私钥和固件中的敏感配置。
- 完整性:防止未授权修改。典型手段包括哈希、消息认证码(MAC)、数字签名、安全启动、度量与远程证明。完整性是可信链的核心,因为只有代码和数据的完整性可验证,系统才可能被信任。
- 可用性:确保授权用户在需要时能访问资源。典型手段包括冗余、容错、抗拒绝服务、资源配额和恢复机制。在嵌入式设备中,可用性还涉及看门狗、安全恢复模式和防变砖设计。
除CIA之外,实际系统还常引入真实性(Authenticity)、不可否认性(Non-repudiation)和可问责性(Accountability)。真实性确保通信实体或数据来源真实;不可否认性通过数字签名等机制防止事后抵赖;可问责性则依赖审计日志将操作绑定到主体。
关键理解:CIA不是三个孤立目标,而是相互制约的三角。例如,过度加密可能降低可用性;为了高可用而开放过多接口,又可能削弱机密性和完整性。安全设计本质上是在三者之间做有依据的权衡。
二、认证、授权与审计:访问控制的三个环节
认证(Authentication)、授权(Authorization)和审计(Audit)常被称为AAA中的三个A(另一个A是Accounting,计费/记账)。它们构成访问控制的完整链条:先确认“你是谁”,再决定“你能做什么”,最后记录“你做了什么”。
- 认证:验证主体身份。常见因子包括知识因子(口令)、持有因子(令牌、智能卡)、生物因子(指纹)以及设备身份因子(证书、TPM/TPM2.0、PUF)。多因子认证(MFA)要求组合两类以上因子。
- 授权:在认证通过后,依据策略决定主体对客体的操作权限。常见模型包括ACL、RBAC(基于角色)、ABAC(基于属性)和MAC(强制访问控制)。在设备侧,授权常体现为能力令牌、策略文件和权限位。
- 审计:记录安全相关事件,支持事后追溯、入侵检测和合规证明。审计日志应包含时间、主体、客体、操作、结果和上下文,并具备防篡改和完整性保护。
三者顺序不可颠倒:没有认证的授权是空授权;没有授权的认证无法控制行为;没有审计的认证和授权在出事后无法复盘。在PSA可信模型中,认证还进一步分为“平台认证”和“设备认证”,前者证明设备符合安全基线,后者证明设备身份真实。
三、方法流程:一次受控访问的完整路径
下面以设备端一次受控访问为例,说明从请求到审计的典型流程。该流程体现了认证、授权、审计与CIA属性的协同。
1. 主体发起请求 → 携带身份凭证(证书/令牌/口令)
2. 认证模块验证凭证 → 检查签名、有效期、吊销状态
3. 认证通过 → 生成会话上下文(主体ID、角色、属性)
4. 授权模块加载策略 → 判断主体对客体的操作是否允许
5. 允许 → 执行操作;拒绝 → 返回错误并记录
6. 审计模块写入日志 → 时间、主体、客体、操作、结果
7. 日志完整性保护 → 哈希链/签名,防止篡改
8. 定期审计与告警 → 异常行为检测与合规报告
在可信设备中,第2步的认证往往依赖硬件可信根,例如将设备私钥保存在安全存储中,由安全核完成签名验证;第7步的日志完整性则可能通过TPM的单调计数器或安全世界中的哈希链实现。
四、常见术语与对比
安全领域术语容易混淆,下表对高频概念进行对照,帮助在PSA架构文档和评审中准确使用。
| 术语 | 核心问题 | 典型机制 | 在设备可信中的体现 |
|---|---|---|---|
| 机密性 | 谁能看? | 加密、访问控制 | 密钥保护、安全存储 |
| 完整性 | 是否被改? | 哈希、MAC、签名 | 安全启动、度量、远程证明 |
| 可用性 | 能否使用? | 冗余、容错、限流 | 看门狗、安全恢复模式 |
| 认证 | 你是谁? | 口令、证书、MFA | 设备身份、平台认证 |
| 授权 | 你能做什么? | RBAC、ABAC、ACL | 能力令牌、策略执行点 |
| 审计 | 你做了什么? | 日志、告警、追溯 | 安全日志、防篡改记录 |
| 不可否认性 | 能否抵赖? | 数字签名、时间戳 | 固件签名、交易凭证 |
五、案例/场景:智能门锁的一次开锁请求
以智能门锁为例。用户手机通过蓝牙发送开锁指令,门锁需要确认:指令来自已配对用户(认证)、该用户是否有开锁权限(授权)、本次操作是否被记录(审计)。同时,通信内容需要加密防止窃听(机密性),指令需要MAC或签名防止重放和篡改(完整性),门锁在断网时仍需本地开锁(可用性)。如果门锁只做了加密而没有防重放,攻击者可以录制合法开锁指令并重放,机密性仍在,但完整性和认证实际已被绕过。
场景启示:安全属性必须组合使用。单独强调某一项,往往会在其他维度留下可被利用的缺口。PSA认证强调的“安全基线”正是要求设备在多个属性上达到最低可信水平。
六、误区与复盘
- 误区一:加密等于安全。加密只解决机密性,不能防止篡改、重放或权限提升。必须配合完整性校验和认证机制。
- 误区二:认证通过就万事大吉。认证只回答身份问题,授权策略错误仍会导致越权。例如普通用户被错误赋予管理员角色。
- 误区三:审计日志只是运维数据。审计日志是安全事件追溯和合规证明的关键证据,必须防篡改、防删除,并设置合理保留周期。
- 误区四:可用性与安全无关。拒绝服务、资源耗尽和变砖都会直接破坏可用性,进而影响业务连续性。安全设计必须包含恢复与降级策略。
- 误区五:术语混用导致评审偏差。把“认证”说成“授权”、把“完整性”说成“机密性”,会在需求评审和测试用例设计中产生严重歧义。
复盘要点:在PSA安全架构中,每一个安全需求都应明确它保护的是CIA中的哪一项,依赖认证、授权、审计中的哪些环节,并给出可验证的测试方法。术语清晰、边界明确,才能避免“看起来安全、实际上脆弱”的架构。