3. 安全基础概念
在S32G这类面向车载与工业网关的高可靠SoC上谈“安全”，不能只停留在“加密算法够不够强”的层面。安全工程真正要回答的是：我们要保护什么、防谁、防到什么程度、失败时如何降级。CIA三元组（机密性、完整性、可用性）是安全目标的骨架，真实性与不可否认性则补上了“身份可信”和“行为可追溯”两块拼图。理解这些概念，是后续设计可信启动、密钥管理和安全刷写流程的前提。
一、五个核心安全属性
机密性（Confidentiality）：确保信息只被授权主体读取。在S32G上，典型场景是密钥、证书私钥、诊断解锁种子、OTA固件包中的敏感字段。实现手段包括AES对称加密、RSA/ECC非对称加密、安全存储区（如HSE的密钥槽）以及总线级加密。机密性失效往往不是算法被攻破，而是密钥泄露、调试口未关闭或内存残留。
完整性（Integrity）：确保数据未被未授权篡改。它回答的是“这份固件还是原厂那份吗”。常用机制是哈希（SHA-256/384）加消息认证码（HMAC）或数字签名。S32G的HSE（Hardware Security Engine）可在启动阶段对BootROM、HSE固件、应用镜像逐级校验，任何一级哈希不匹配即中止启动。
真实性（Authenticity）：确认消息或实体确实来自声称的来源。完整性和真实性常被混淆：完整性防“改”，真实性防“冒”。数字签名同时提供两者——用私钥签名、公钥验签，既证明来源，又证明内容未变。
可用性（Availability）：确保授权用户在需要时能访问资源。对车载ECU而言，可用性直接关联功能安全。攻击者可能用拒绝服务、刷写失败、密钥误擦除等方式让系统“安全地变砖”。因此安全设计必须包含回滚、双备份、恢复模式等可用性保障。
不可否认性（Non-repudiation）：确保行为发生后无法抵赖。它依赖数字签名、时间戳和审计日志。例如OTA服务器下发固件、诊断工具执行解锁，都应有可验证的签名记录，便于事后追责与取证。
二、安全威胁模型：先定义敌人，再设计防线
威胁模型（Threat Model）是对“谁、用什么能力、攻击哪里、造成什么后果”的结构化描述。没有威胁模型的安全设计，容易变成“堆算法”。在S32G项目中，常用STRIDE方法对资产逐项分析：Spoofing（冒充）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（提权）。
结合S32G的实际攻击面，可把威胁模型分为四类：远程网络攻击（OTA、诊断、车云通道）、本地物理攻击（JTAG、调试口、拆机读取Flash）、供应链攻击（固件植入、密钥泄露）、内部误操作（误擦密钥、错误刷写）。每一类对应不同的防护强度：远程攻击靠签名与加密，物理攻击靠安全启动、调试口熔断与HSE密钥保护，供应链靠密钥分级与签名链，误操作靠A/B分区与回滚机制。
核心原则：安全不是“有没有加密”，而是“在给定威胁模型下，攻击成本是否高于攻击收益”。对S32G而言，可信启动链（BootROM → HSE固件 → 应用镜像）是完整性与真实性的第一道闸门；HSE密钥槽是机密性的根；A/B分区与回滚是可用性的兜底。
三、从属性到机制：一张对照清单
| 安全属性 | 防护目标 | S32G典型机制 | 失效后果 |
|---|---|---|---|
| 机密性 | 密钥、敏感数据不被读取 | HSE密钥槽、AES加密、调试口保护 | 密钥泄露、固件被逆向 |
| 完整性 | 固件与配置未被篡改 | SHA-256哈希、HMAC、安全启动校验 | 恶意固件运行、系统被控 |
| 真实性 | 来源身份可信 | X.509证书、ECC/RSA签名验签 | 伪造OTA包、冒充诊断工具 |
| 可用性 | 授权用户可正常使用 | A/B分区、回滚、恢复模式 | 刷写失败变砖、服务中断 |
| 不可否认性 | 行为可追溯、不可抵赖 | 签名日志、时间戳、审计记录 | 无法追责、取证困难 |
四、案例与误区复盘
案例：OTA升级中的属性协同。一次安全的OTA升级，需要五个属性同时在线：服务器用私钥对固件签名（真实性），车端用公钥验签（真实性+完整性），固件包传输可加密（机密性），升级失败可回滚到旧分区（可用性），升级记录带签名日志（不可否认性）。任何一环缺失，都会让整条链路的防护等级下降。
误区一：把完整性当真实性。只做哈希校验，攻击者可以同时替换固件和哈希值。必须用签名把“来源”和“内容”绑定在一起。
误区二：忽视可用性。很多团队把安全等同于“锁死”，结果一次误操作导致设备无法启动。安全设计必须包含恢复路径。
误区三：威胁模型缺失。不定义攻击者能力，就无法判断防护是否足够。例如，是否考虑物理拆机？是否考虑供应链内鬼？这些直接决定密钥管理和调试口策略。
工程建议：在S32G项目启动阶段，先列出资产清单（密钥、固件、配置、日志），再对每项资产标注CIA+真实性+不可否认性的需求等级，最后映射到HSE、安全启动、A/B分区等具体机制。这样形成的安全需求表，比“堆算法”更可验证、更可审计。
理解这五个属性及其威胁模型，是后续学习S32G可信启动、HSE密钥管理和安全刷写流程的概念基础。安全不是单点技术，而是一组目标在具体攻击面下的协同实现。