ARM平台安全要求1.0

本文翻译自文档Platform Security Requirements 1.0

术语和缩写

本文档使用以下术语和缩写。

术语	含义
Cryptographic hash	加密哈希 一种单向函数，可将任意大小的数据映射到固定大小的位串。
DPM	Debug Protection Mechanism，调试保护机制
HUK	Hardware Unique Key，硬件唯一密钥
MTP	Multi-time programmable，多次可编程
NVM	Non-volatile memory，非易失性存储器
OTP	One-time programmable，一次可编程
PE	Processing Element，处理单元
PSA	Platform Security Architecture，平台安全架构
ROTPK	Root of Trust Public Key，信任根公钥；也称为启动验证密钥。
SoC	System-on-Chip，片上系统
TRTC	Trusted Real Time Clock，可信实时时钟

一、简介

本文档规定了对片上系统(SoC)期望的多个市场最低安全要求。它主要面向需要符合各种安全性的芯片组设计人员要求。架构师、设计师和验证工程师可以使用这个规范来支持这个过程独立实验室的认证。

本文档未指定特定的系统架构或特定组件的使用。另外Arm的文档提供了如何使用Arm最佳地满足安全要求的指导架构和系统IP。鼓励系统设计者检查是否符合规定的安全性要求。

二、安全目标

PSA安全模型以安全目标的形式概述了安全系统的重要原则。这些目标体现在各种Arm规范中，并用作开发详细硬件的基础。本文件中的安全要求。

2.1密码身份

为了安全地与特定系统通信，每个系统必须是唯一可识别的。

2.2安全生命周期

系统必须确保资产保护和设备功能可用性符合规定以及从制造到设备处置的受限路径。因此，系统必须有一个状态机它可以用来在特定上下文中做出适当的安全决策。这被称为安全生命周期。

安全生命周期中的每个安全状态都定义了系统的安全属性。安全状态取决于软件度量、硬件配置、调试模式和生命周期阶段。对于例如，生命周期状态可以涵盖开发、供应、部署、返回和生命结束等场景。

2.3证明

系统必须能够向依赖方提供其可信性的证据，这需要身份以及通过认证证明系统的安全状态。为了具有有效性，系统必须是管理计划。此类计划包括评估实验室、认证验证者和依赖双方。

2.4安全启动

安全启动和安全加载过程对于防止未经授权的软件被执行是必要的。

2.5安全更新

当引入新功能或漏洞已修复。更新过程本身必须确保不被滥用。

2.6回滚保护

随着时间的推移，以前版本的软件可能包含可利用的漏洞。因此，防止必须将固件回滚到以前的版本；但是，出于恢复目的的回滚，如果授权，则可能是允许的。此外，配置数据可能需要版本控制和回滚保护。

2.7隔离安全

将可信服务和资源与不太可信的服务隔离是至关重要的。隔离旨在防止服务不会损害其他服务的资产。软件很可能包含可能被利用以危害系统安全。

本文档使用术语“受信任的世界”来指其状态支持受信任的硬件资源服务和术语“不可信世界”是指其状态支持不可信的硬件资源服务。

通过隔离使用安全性的示例软件架构是PSA固件框架[2][5]。

2.8安全接口

如果隔离服务有其用途，那么隔离边界上的交互是必不可少的。然而，接口必须确保它们不会被用来危害系统。还可能需要确保通过此类接口交换的任何数据的机密性和完整性。

2.9绑定Binding

敏感数据(例如用户或服务凭证以及密钥)必须绑定到系统，以防止在拥有数据的系统之外克隆和公开。如果存储在非私有存储中，这可能需要机密性和完整性保证。密钥通常用于保护敏感数据本身是系统敏感数据，必须绑定到系统。可能还需要绑定数据到安全生命周期状态。

2.10可信服务

可信服务必须确保满足其他目标。受信任的服务可能包括支持安全生命周期、隔离和加密服务的硬件，这些服务可能使用绑定的机密来支持证明、安全启动、安全加载以及数据绑定。

三、范围

本文件涵盖了以下几类威胁：

威胁	概要
T.ROGUE_CODE	攻击者成功地在设备上加载并执行流氓代码，以便获取资产或升级特权。
T.TAMPERING	攻击者替换或篡改片外存储、内存或外围设备获取资产或升级特权。
T.CLONING	具有物理访问权限的攻击者读取芯片外存储器或内存中的数据。这支持将资产反向工程或克隆到其他系统。
T.DEBUG_ABUSE	攻击者成功访问调试功能，以便非法修改系统行为或访问资产。
T.WEAK_CRYPTO	攻击者破解设备所使用的密码，以便访问资产或模拟设备。这种威胁只与算法强度、密钥大小有关，以及随机数生成。
T.IMPERSONATION	攻击者伪装成该设备，以便截取被证明的资产。
T.POWER_ABUSE	攻击者滥用使用软件的电源管理控制，以便访问资产。
T.SOFT_SIDE_CHANNELS	攻击者使用软件可观察的侧信道来推断关于资产的信息。

以下威胁超出了本文档的范围，其中一些可能需要缓解特定市场或认证级别:

威胁	概要
T.INVASIVE_ATTACK	攻击者使用入侵技术，在这种技术中，系统在物理上是未打包的，并进行调查，以追回资产。
T.GLITCHING	物理上存在的攻击者使用功率、时钟、温度和能量毛刺 导致错误(如指令跳过、数据格式错误)的攻击， 读/写或指令解码错误。
T.PHYS_SIDE_CHANNELS	攻击者通过使用物理的非侵入性技术，例如差分功率分析或定时攻击，推断敏感的片上代码或数据的值。一个 示例：资产可以是一个加密密钥。
T.DENIAL_OF_SERVICE	攻击者损坏资产或阻止资产被访问。
T.SUPPLY_CHAIN	虽然本文档中的指导提供了针对潜在攻击的缓解措施， 一个供应链，如固件篡改，它不直接解决供应链安全。
T.APPLICATIONS	对不可信世界和一般应用程序安全的威胁。

四、合规性

为了符合本文件，必须有证据支持的文件显示设计满足本文件描述的所有适用要求。通常，设计团队通过以下方式实现这一点系统设计评审的验证输出。Arm建议将此评估作为安全的开发生命周期。

表中描述了规范性要求。表外的文本是信息性的。

设计团队必须提供满足每个要求的证据。此确认必须包括以简要大纲的形式证明合规性，并参考相关详细信息规格。一般来说，如果可以向客户展示需求所缓解的威胁，则需求可能不适用不构成系统威胁模型的一部分，或不满足可以用另一种方式证明可以减轻需求。在某些情况下，有必要提供更多强大的安全性。在这些情况下，支持证据必须与要求一起记录。

本文件在几个方面提供了建议。在可能的情况下，这些建议是为合理的默认设计选择提供指导。威胁模型和功能要求在确定如何满足要求和遵循的建议方面，系统的性能至关重要。这个产品威胁模型的开发超出了本文的范围。