- 概述
- PSA概述
平台安全架构（PSA）从整体上考虑设备的安全性：安全必须在硬件和软件两个层面解决——仅仅是单纯的硬件安全是不够的。
前提：
- 大多数的物联网设备都包含多来源、复杂代码。
- 不论是恶意或者意外，复杂代码想要证明其没有任何错误都是很困难甚至是不可行的，即使有良好的设计过程。
- 被破坏的软件也会破坏硬件——即使底层硬件保护的信任根没有被直接破坏，被破坏的软件依旧可以充分利用硬件，包括克隆、模拟和访问数据。
PSA假定软件有缺陷，并且减少潜在的不可靠风险必须是任何设备安全架构的基本目标。应将信任根的概念从纯硬件扩展到硬件和软件的组合，并从不太可信的软件组件中隔离出相对可信的软件组件。
PSA旨在帮助合作伙伴和行业利益相关者开发和部署基于正式安全分析（进行正式威胁分析）的安全产品。
PSA定义了一个通用的硬件和软件安全平台，提供了一个通用的安全基础框架，并允许在其上开发安全的产品和功能。预计PSA合规（认证）将是实现大类别产品认证的必须和必要的要求。
合规主要有两种形式：
- 功能性合规
接口处理、功能是否满足，以及互操作性（互用性）。功能性合规包括了一般的产品特性以及安全特性。
- 健壮性评估与认证
健壮性评估和认证是基于威胁模型和安全分析（参见1.2中对应描述）实现的安全需求和管理，它定义了必要的措施与流程，确保产品功能兼容、关键资产不容易受到可识别的威胁。
注意：
- PSA SM主要关注健壮性需求，本文档中称为健壮性规则（robustness rules）。
- PSA SM所确定的硬件和软件服务，以及功能接口和技术实现要求，将在单独的技术规范中指定。
针对不同的应用程序和生态系统，将会有不同的安全需求、不同的成本及对于安全方面的不同取舍。这会在规范中反应，包括：
- 体系架构维度
对不同成本和不同的健壮性等级，拥有不同的技术参考实现。
- 健壮性等级设计
为不同的应用程序定义不同的健壮性属性，针对不同的成本和安全性之间找到权衡方案。
- PSA生态系统
图未上传
设备符合PSA，同样其部署也应在部署在支持安全流程的生态系统环境中，这种生态系统可以是如下模式：
- 垂直模式，即单个设备制造商（OEM）或者服务提供商围绕自己的产品创建生态系统；
- 围墙花园模式，即服务提供商作为终端客户的单一入口，面向合作伙伴的生态系统；
- 水平或开放模式，其中服务提供商、OEM、行业或者监管机构组成联盟，形成一个开放的竞争实体生态系统。
上图描述了这种生态系统的通用参考模型。
- 威胁模型和安全分析（TMSA）
威胁模型和安全分析（应简单保护配置文件）根据一系列行业用例识别和推动发现安全的需求。TMSA由Arm和行业利益相关者共同开发推广。
- PSA合规与认证
一些衍生的安全需求，被转换为不同应用程序的功能遵从性需求、健壮性评估和认证需求。针对不同的应用以及不同的成本和安全性的权衡考量，将会提供一系列的健壮性级别。
针对PSA功能遵从性和健壮性等级，合规测试程序和认证程序定义了相关流程。这些流程可能是自我评估，也可能需要第三方审核与测试，这取决于测试用例和生态系统的需求。
- 安全规范
安全规范定义了满足安全特性的技术体系架构和要求，提供了满足TMSA要求所需要的措施，并启用了符合PSA设备的设计和部署方案。
可将PSA SM（本文档）视为顶级安全规范，其确认并定义PSA信任根，以及与其相关的信任根服务。
其他规范提供了详细的硬件和软件功能，以及健壮性需求，同时也提供了标准化的功能接口。
- 设计和制造（工厂初始化）
设备的设计和和和制造都应符合安全规范（对等保的要求、相关管理员的要求等）。通用安全服务、接口和参考实现都应集成简单。
必须控制设备制造中涉及在工厂配置和初始化过程中提供根密钥和其他蜜柑信息，确保关键资产始终受到保护。
设备的制造是一个复杂的过程，其涉及多个步骤与多角色参与者，通常超出了本文档范围。然而该规范确实定义了安全工厂供应和制造过程的一般健壮性需求。
- 设备认证和验证
制造商在设备验证系统中注册设备，应支持认证验证，并在此过程中保证适当的健壮性水平和遵守相关规则。
认证和验证服务由制造商、服务提供商或者行业协会根据生态系统需求进行部署。
- 设备管理
制造商通过设备管理系统提供设备制造数据、固件更新、相关服务和其他支持功能。设备
管理服务遍及设备的整个生命周期，从工厂供应到生产使用、现场调试和维修，再到设备的报废。
- 部署
服务提供者可以部署安全服务，方法是通过社党的设备信任模型和设备认证服务对设备进行身份验证并识别其安全属性（健壮性级别）。
服务提供者可以通过适当的设备管理框架，管理和支持已部署的设备。
- PSA安全模型的安全目标
兼容PSA的设备的安全目标主要是允许允许后使用具有已知安全属性的设备部署安全服务。
通用的设备信任模型在下面的表中进行描述。这里使用的术语——验证实体，是指需要建立设备可靠性的任何实体。就PSA而言，它通常事一个服务提供商或是云服务，但它也可以说比如mesh或hive网络中的其他设备。
步骤 | 要求 | 详情 |
允许一个验证实体标识其设备，并验证其安全属性 | 设备唯一ID，以及设备认证 | 设备的唯一ID可以识别如下信息：
完成认证后，验证实体通常会建立一个安全且已认证的通信链路，和已认证的通信链路端点，它们可以用于进一步的服务交互，包括提供服务，也包括用户需要的特定凭证和数据。 |
允许一个验证实体标识其安全属性 | 鲁棒性（健壮性）认证 拥有的设备唯一ID应是底层硬件（不能被修改的组件） | 验证不同应用程序的健壮性级别 唯一ID可以识别如下信息
|
向验证实体保证其健壮性标准已满足 | 在参与生态系统前制造商应给予对应承诺 | 为生态系统建立相关管理模型 |
线上验证与认证服务 | 可信的验证体统 | 允许根据健壮性标准和生态系统管理过程验证与管理设备，例如警告和撤销。 |
目标一：PSA SM要求所有设备都是唯一可识别的
要保证身份在合适的安全模型和可信的验证系统的上下文中发布才有意义。
目标二：PSA SM要求所有的设备都要支持认证
对于一些特殊应用的敏感数据，比如用户生成的数据、用户凭证和服务凭据，必须受到保护并且要安全地存储在设备上，以确保不会被未授权的代理访问，也不会被克隆到其他设备中。
对于应用程序级别的数据、密钥和平局的安全存储，可以根据应用程序和设备需求以多种方式实现，比如blob存储（一种存储方式）、加密的文件系统和数据库。通用需求是唯一地将存储数据绑定到特定的设备实例中。
目标三：PSA SM要求所有设备需要支持将应用程序数据和敏感用户数据唯一地绑定到设备上，并且具备安全配置功能。
必须保护设备的配置，以确保只有经过授权的软件才能在设备上运行。未经授权的软件可能会泄露机密或数据，从而危及设备、用户或服务的安全性。
目标四：PSM SM要求所有设备都支持安全启动过程，确保只有授权的软件才能在设备上执行。
所有的软件都可以而且应该包含错误和设计缺陷，这些错误和设计缺陷可能会被用来破坏设备的安全性。软件越复杂，就越可能包含可被利用的漏洞。
软件需要分成可信和相对不可信的组件。不太可信的组件可能包括很难或不能证明没有漏洞的软件。单独的安全启动进程是不够的。软件隔离需要在软件组件的顶部进行隔离，以便在不太可信的组件中的漏洞不会影响到可信组件。
根据以下安全目标，本文档定义了几个隔离级别：
目标五：必须始终提供隔离。
至少在不安全的应用程序软件和信任软件的根之间。对于许多认证配置文件，还必须在实现信任根本身的组件之间提供隔离。
最后，必须能够升级设备以填补漏洞，并提供更新特性，软件更新不能损害设备的完整性，更新过程本身必须是健壮的。具体来说，不能滥用更新过程在设备上安装任意数据，所有更新都必须经过验证。
目标六：PSA SM要求所有设备支持安全升级过程
目标七：PSA SM要求任何升级在安装之前都必须经过验证
设备升级应该是渐进的，因为，最新的版本比旧版本更好，旧版本可能包含已知的功能或安全问题，可能在某种程度上危及设备。但与此同时，在正常操作中，设备有时可能需要退回到一些较早、已知是一个比较稳定的版本上。这可以是本地，比如更新使得设备不稳定，也可以是全局，比如新特性使得服务出现问题。
这意味着设备必须防止未授权的回滚，这样就不能强制回滚到具有已知漏洞的早期版本，但可以回滚到最后一个已知的稳定版本上。
目标八：PSA SM要求设备必须防止未授权的回滚——反回滚
上述安全目标将确保一个健壮性的设备能够从广泛的安全问题中恢复，并保护设备和用户敏感信息。但在实际部署中，还必须支持设备特性（包括安全特性）的开发和调试，并支持维修、服务开发和调试。对于这类场景，可能需要启用调试或开发模型，这可能降低设备的可靠性。
目标九：PSA SM要求设备支持本文档后面定义的安全生命周期
设备当前的安全生命周期必须是可测试的。
除了上述的PSA SM的核心安全特性外，安全设备还应支持一组最小的可信密码服务，以支持密钥和密钥安全管理。
目标十：PSA SM要求所有设备在系统最受信任的级别上实现通用的加密服务。
- 通用PSA设备模型
图未上传
上图描述了PSA设备的通用设备模型，这是本文档讨论设备安全属性的的参考模型，实际设计用推荐使用该参考模型。
PSA的设计是为了支持合作各方的生态系统，允许在一个共同的安全框架上开发应用程序：
- 硅制造商提供符合PSA的硬件。
- 本文档中定义的PSA信任根，提供一个通用的安全基础。（后期会提供经过PSA认证的PSA信任根的实现，并且将其移植到一系列与PSA兼容的设备上）
- 安全的应用程序，包括针对应用程序的信任扩展根，现在可以在通用的底层PSA信任根的基础上构建，用以支持更多的符合PSA要求的硬件。
下表描述符合PSA的通用产品：
组件 | 描述 | 备注 |
设备 | 交付的最终产品 | 比如网络安全摄像头或者资产管理跟踪装置等 |
系统 （硬件维度） | 集成所有处理元素的不可分割的组件，总线、主机、PSA信任根 | 通常是SoC或者同类产品，但是也可以包括其他部分，比如外部的SIM或者TPM，他们与其余部分通过密码方式或者物理方式不可分离的结合在了一起。 |
PSA不可变信任根 | 不可修改（只读）的硬件组件需要在整个设备中构建和维持信任，并且需要开放给服务提供商和设备用户 例如：
| 可信的可不变信任根只能被系统中最可信的软件访问（比如PSA可更新的信任根）。 |
可信子系统（硬件维度） | 不属于PSA可信根，但是也是在PSA信任根的信任边界之内的任何外部可信组件 | 例如：
这些都必须受到PSA保护（通过PSA信任根） |
外部资源 | 系统外部的硬件资源：如DDR、外部Flash、设备和外设、通信端口等 | 在PSA安全模型中，外部资源被认为是不可信的，因为其位于PSA信任根的可信边界之外。 |
可更新组件有系统上下文中的所有软件、固件、和其他可更新组件构成。任何PSA设备都可以说是由下列的可更新组件构成：
组件 | 描述 | 备注 |
PSA可更新的信任根 | 最受信任的软件在不可变信任根下运行，比如：
| PSA信任根的目的是提供一组通用且可移植的接口，这些服务可以在专用硬件上提供。 然后，可以在可移植接口上构建基于某个应用程序的信任根，而不必直接将其移植到专用硬件上。 |
可更新组件和可信子系统的配置 | 可信子系统的任何可更新组件，以及影响可信子系统操作的任何配置 |
|
应用程序可信根 | 设备所需的任何针对应用程序的信任根，比如服务提供者需要的远程认证协议或安全存储服务。 可信服务的可信根不应该能够直接访问底层不可变硬件。 | 应用程序可信根可能比PSA更更新的可信根更复杂，并且可能包含第三方代码。它的服务应该构建在PSA可更新的可信根之上，从而支持隔离、以及提供更新和恢复的路经。 针对于应用程序的可信根不在本文档的范围。 |
应用程序 | 所有不受信任的（从可信根的角度来看）应用程序级别的功能和服务，负责管理所有的应用数据和资源。 应用程序服务不应该能够直接访问基于可信根的可信软件或PSA可变信任根，或任何受可信根保护的密钥 | 应用软件有可能包含第三方代码或者库，通用可能包含开源代码、专有客户端和其他难以认证的组件。 从PSA的角度来看，所有的应用软件都应该被认为是不可信的，可以通过定期更新来修复漏洞或修改特性。 |
最后，可更新组件将会作为镜像打包、分发、不收和存储在相应设备上。根据用例、设备设计和操作的要求，可以采用不同的方式进行打包，比如：
- 单个设备镜像，包含所有可更新组件。
- 包含不同肯更新组件集合的多个镜像，例如包含可信组件（根）的固件镜像，以及包含所有应用程序的镜像。
不管使用何种方式打包，都应遵循下面的通用需求：
规则 | 基本要求 | 备注 |
所有可更新的组件都必须经过测量和验证。 | 只能加载经过签名和验证的代码。 | 度量操作是在引导和更新期间进行的，在引导期间是强制执行的。 |
可信软件和应用软件需要分来进行测量。 | 允许可信软件独立于应用软件进行验证和认证。 | 这并代表打包方式有什么不同，只是可信软件必须单独测量而已。 |
