📚 课程目录第3章功能安全与信息安全基础

3. 功能安全与信息安全基础

在AURIX安全软件与可信启动工程中，功能安全（Safety）与信息安全（Security）是两条并行且相互支撑的主线。功能安全关注的是“系统在发生随机硬件失效或系统性失效时，是否仍能进入安全状态，避免对人员造成不可接受的风险”；信息安全关注的是“系统是否能够抵御恶意攻击、未授权访问、篡改与窃取，保证资产的机密性、完整性与可用性”。二者目标不同，但在汽车电子控制单元（ECU）中往往共享同一套硬件资源、软件架构与验证证据，因此必须协同设计。

3.1 ISO 26262功能安全框架

ISO 26262是道路车辆功能安全国际标准，覆盖从概念阶段到生产、运行、报废的全生命周期。其核心思想是通过危害分析与风险评估（HARA）确定汽车安全完整性等级（ASIL），再据此分配安全目标与安全需求。ASIL分为A、B、C、D四个等级，D级要求最严格。AURIX TC3xx系列MCU通常用于ASIL-D级系统，例如电动助力转向、制动控制、安全气囊等。

功能安全开发的关键活动包括：相关项定义、HARA、安全目标制定、功能安全概念、技术安全需求、硬件/软件安全机制设计、集成与验证、安全案例编制。对于AURIX软件而言，常见安全机制包括锁步核（Lockstep Core）、ECC保护、内存保护单元（MPU）、看门狗、时钟监控、电压监控、端到端保护（E2E）等。

核心逻辑：危害 → 风险评估（S/E/C）→ ASIL等级 → 安全目标 → 安全需求 → 安全机制 → 验证证据。

3.2 ISO/SAE 21434网络安全框架

ISO/SAE 21434是道路车辆网络安全工程标准，强调“网络安全是贯穿全生命周期的持续过程”。它要求组织建立网络安全管理系统（CSMS），并在概念、开发、生产、运行、维护、报废各阶段执行威胁分析与风险评估（TARA）。TARA的输出包括资产识别、威胁场景、攻击路径、影响与可行性评估、风险值计算以及风险处置措施。

与功能安全不同，信息安全面对的是“主动的、智能的、不断演化的攻击者”。因此，ISO/SAE 21434更强调攻击面分析、漏洞管理、安全更新、入侵检测与响应。在AURIX项目中，常见安全需求包括：安全启动、安全通信（SecOC）、密钥管理、调试接口保护、HSM固件更新、访问控制与审计日志。

3.3 EVITA分级与硬件安全锚点

EVITA（E-safety Vehicle Intrusion Protected Applications）项目提出了车载网络节点的硬件安全分级，分为Full、Medium、Light三级。该分级依据计算能力、存储能力、安全功能与成本，指导不同ECU选择合适的安全硬件。AURIX集成了HSM（Hardware Security Module），通常可满足EVITA Full或Medium级别要求，支持AES、ECC、SHA、TRNG等密码算法，并提供安全密钥存储与安全启动服务。

3.4 安全目标与安全需求分析方法

安全目标（Safety Goal）是功能安全概念层的顶层要求，通常由HARA导出，例如“避免非预期的转向助力扭矩输出”。安全需求（Safety Requirement）则是安全目标的技术化分解，分为功能安全需求（FSR）和技术安全需求（TSR）。信息安全需求（Security Requirement）来自TARA，例如“防止通过调试接口篡改启动镜像”。

在实际项目中，建议采用“双轨并行、交叉映射”的方法：先分别完成HARA与TARA，再建立安全目标与安全需求的追溯矩阵，识别冲突与互补点。例如，安全启动既是信息安全需求，也是功能安全中“防止非预期软件运行”的安全机制。下表给出一个简化的需求映射示例。

来源标准	目标/需求编号	描述	对应AURIX机制	验证方式
ISO 26262	SG-01	避免非预期扭矩输出	锁步核、MPU、看门狗	故障注入测试
ISO 26262	TSR-01-01	检测CPU锁步比较错误	Lockstep Comparator	硬件诊断覆盖
ISO/SAE 21434	SR-01	防止未授权固件刷写	HSM安全启动、签名验证	渗透测试
ISO/SAE 21434	SR-02	保护调试接口不被滥用	调试认证、生命周期状态	接口模糊测试

3.5 常见误区与复盘

误区一：认为功能安全与信息安全可以独立开发。实际上，安全启动、安全通信等机制同时服务于两个目标，割裂开发会导致重复投入与证据冲突。

误区二：把ASIL等级直接等同于信息安全等级。ASIL衡量的是人身伤害风险，而信息安全风险还涉及隐私、财产与法规，二者不可直接换算。

误区三：只关注开发阶段，忽略运行与更新阶段。ISO/SAE 21434要求持续漏洞管理与安全更新，AURIX HSM需支持安全的OTA更新流程。

实践建议：在AURIX项目启动时，建立统一的安全需求管理库，将Safety Goal、TSR、Security Requirement、HSM服务、测试用例进行双向追溯。使用需求管理工具（如DOORS、Polarion）维护追溯矩阵，确保每个安全机制都有明确的来源与验证证据。

# 示例：安全需求追溯矩阵片段（YAML格式）
safety_goal:
  id: SG-01
  desc: "避免非预期扭矩输出"
  asil: D
  derived_tsr:
    - id: TSR-01-01
      desc: "检测CPU锁步比较错误"
      mechanism: "Lockstep Comparator"
      verification: "Fault Injection Test"
security_requirement:
  id: SR-01
  desc: "防止未授权固件刷写"
  source: "TARA-2024-001"
  mechanism: "HSM Secure Boot + Signature Verify"
  verification: "Penetration Test"

综上，ISO 26262与ISO/SAE 21434分别从功能安全与信息安全两个维度定义了汽车电子系统的开发要求，EVITA分级则为硬件安全能力提供了选型依据。在AURIX安全软件与可信启动工程中，只有将安全目标、安全需求、安全机制与验证证据形成闭环，才能构建真正可信的汽车电子安全体系。