3. PSA概述

PSA（Platform Security Architecture，平台安全架构）是Arm在2017年前后主导提出的一套面向物联网与嵌入式设备的安全工程框架。它并不是一款可以直接烧录进芯片的软件，也不是单一认证证书，而是一组可复用的安全原则、参考模型、规范接口、开源实现与认证体系的集合。理解PSA，关键要把它看作“从威胁建模到设备认证”的完整方法论，而非某个孤立组件。

3.1 起源：物联网安全碎片化催生统一架构

在PSA出现之前，嵌入式安全呈现明显的碎片化：不同芯片厂商提供各自的信任根（RoT）、不同RTOS有各自的权限模型、不同云平台要求不同的设备身份方案。结果是每个物联网项目都要重新回答同样的问题：密钥存哪里？安全启动怎么做？固件如何可信更新？设备身份如何证明？

Arm长期提供Cortex-M/A系列处理器IP，处于产业链上游，具备推动统一抽象的条件。PSA的提出借鉴了成熟领域的安全工程思想：先做威胁建模与安全分析，再定义安全需求，最后落到硬件信任根、隔离执行环境、可信服务与认证。它同时吸收了TEE、安全启动、证书链、最小权限等既有实践，将其整理为面向资源受限设备的可落地规范。

3.2 目标：四个可验证的安全承诺

PSA的目标可以概括为“让设备具备可被验证的安全能力”，具体分为四个层面：

• 可信身份：每台设备拥有唯一、不可篡改、可验证的身份密钥与证书，用于云侧认证与授权。
• 可信启动：从不可变信任根开始，逐级度量并验证下一阶段镜像，形成信任链。
• 可信更新：固件与安全配置能够经过签名验证后安全升级，且支持回滚保护。
• 可信隔离：通过安全分区与权限控制，把关键资产与普通应用代码隔离，降低攻击面。

这四个目标对应PSA的三大规范支柱：PSA Certified（认证方案）、PSA Firmware Framework（安全分区与IPC规范）、PSA Crypto / Attestation / Storage（可信服务API）。它们共同构成从芯片到应用的纵向安全栈。

3.3 适用场景：从Cortex-M到边缘网关

PSA最初面向Cortex-M类低功耗物联网终端，但适用范围已扩展到更广的设备形态。典型场景包括：

需要注意的是，PSA并不强制要求设备必须具备复杂的安全芯片。它允许通过“安全等级”分级实现：Level 1侧重基础安全原则与文档，Level 2要求独立测试实验室验证，Level 3进一步要求抗物理与侧信道攻击能力。厂商可根据产品风险与成本选择合适等级。

3.4 生态体系：规范、实现、认证与工具链

PSA的生命力来自生态，而不是单一规范文本。其生态大致分为四层：

1. 规范层：PSA Certified、PSA Firmware Framework、PSA Crypto API、PSA Attestation API、PSA Storage API等，定义接口与安全要求。
2. 实现层：Trusted Firmware-M（TF-M）是PSA在Cortex-M上的开源参考实现，提供安全分区、安全启动、密码与证明服务。
3. 芯片与RTOS层：芯片厂商在SoC中集成信任根、安全存储与隔离硬件；RTOS厂商适配PSA接口，使应用可跨平台调用。
4. 认证与工具层：认证实验室、测试套件、威胁建模工具、证书签发与云侧接入方案，形成闭环。

下面用一张结构图展示PSA生态中各层的关系与数据/信任流向。图中从硬件信任根出发，向上经过安全服务、应用框架，最终连接到云侧身份与更新服务，体现“信任链自下而上建立、安全服务按需向上暴露”的核心逻辑。

3.5 案例：一台智能门锁的PSA落地路径

假设某厂商开发一款支持远程开锁的智能门锁，主控为Cortex-M33，带TrustZone。若按PSA思路落地，典型路径如下：

1. 威胁建模：识别资产（开锁密钥、固件、用户凭证）、攻击面（BLE、云通道、调试口）
2. 安全需求：设备唯一身份、安全启动、加密存储、签名固件更新、关闭JTAG
3. 硬件选型：确认芯片提供不可变Boot ROM、OTP密钥区、TrustZone与安全存储
4. 集成TF-M：划分安全分区，启用Crypto/Attestation/Storage服务
5. 应用适配：业务代码通过PSA Client API调用安全服务，不直接接触密钥
6. 云侧对接：设备首次上线执行证明流程，云侧验证证书链后签发会话凭证
7. 认证测试：按PSA Certified Level 2要求完成测试并取得证书

这条路径的价值在于：安全能力不再由应用开发者“顺手实现”，而是由架构层统一提供，应用只需调用标准接口。即使后续更换芯片或RTOS，只要新平台通过PSA认证，上层业务代码的改动量可以显著降低。

3.6 常见误区与复盘