SAE-2020-J3101 “ Hardware Protected Security for Ground Vehicle”，是美国汽车协会2016年发布的关于车辆硬件安全方面的标准，规定了地面车辆应用的硬件保护安全要求。这里的硬件特指 HSM等硬件。
SAE J3101 制定了针对这些硬件的需求，SAE J3101属于最佳实践类文档，关注整个网络安全体系中硬件的相关网络安全技术需求。
以下译文仅供业内学习参阅，如有不妥敬请见谅
6.一般要求
以下常见需求源自本文档稍后详述的用例，并代表了受硬件保护的安全环境功能的类别。
[续上集]
[强制性]要求_6.2.3.1_10：如果使用公钥（非对称密码），则硬件保护的安全环境应支持数字证书。数字证书应为X.509或IEEE 1609.2兼容格式。
[可选]要求_6.2.3.1_20：硬件保护的安全环境应支持短期或长期对称密钥，或同时支持两者。
密钥管理的这一方面定义了与密码密钥的安全持久和/或临时存储相关的规则和过程。适当的密钥存放可确保密钥材料处于静止状态。
[强制性]要求_6.2.3.2_10：受硬件保护的安全环境必须安全地存储所有加密密钥，并明确控制对每个密钥的访问。
[强制性]要求_6.2.3.2_20：密钥库可以是硬件保护的安全环境中密钥的直接存储，也可以是使用硬件保护安全环境外部的外部存储，该外部存储受硬件保护安全安全环境中实施的加密和完整性机制的保护。
[可选]要求_6.2.3.2_30：密钥存储容量应仅受底层硬件的物理限制限制。应在为硬件保护的安全环境指定的每个应用程序下定义不同用途之间的存储分配，包括最大值和最小值。由于可用资源耗尽而导致的拒绝服务应通过作为硬件保护安全环境的一部分在硬件或固件中实现的资源管理器来缓解。
注意：硬件保护的安全环境负责保护长期和短期非对称和对称密钥。短期密钥有时被称为临时密钥。
[强制性]要求_6.2.3.2_40：硬件保护的安全环境密钥库及其加密密钥内容应与任何其他非易失性数据保护分开管理。这包括硬件保护安全环境和正常环境中的其他非易失性数据。
[强制性]要求_6.2.3.2_50：受硬件保护的安全环境应明确管理密钥库与受硬件保护安全环境其他组件的密码完整性。
[强制性]要求_6.2.3.2_60：硬件保护的安全环境应在密钥库的任何更新（添加、修改或删除密钥）期间管理和维护整个密钥库的完整性。
[强制性]要求_6.2.3.2_70：硬件保护的安全环境应在使用存储密钥的任何事务之前检查密钥库的完整性，并响应系统设计规定的任何保证检查密钥库完整性的条件（例如，电源模式的正常或异常变化）。
[强制要求]要求_6.2.3.2_100：硬件保护的安全环境密钥库应保持每个加密密钥与其授权调用应用程序的标识和关联（称为密钥实体关联），无论应用程序位于硬件保护安全环境的内部还是外部，以及密钥是存储在受保护的硬件保护的安全环境边界内还是外部。
[强制性]要求_6.2.3.2_110：硬件保护的安全环境应维护密钥库中受其他存储的加密密钥保护的所有加密密钥的层次结构和/或关联。
[强制性]要求_6.2.3.2_130：密钥库中加密存储的所有加密密钥（硬件保护的安全环境安全边界的内部或外部）均应通过加密算法和密钥长度组合进行加密，从而产生等于或大于存储密钥的计算抗攻击能力。
[可选]要求_6.2.3.2_140：如果用于对任何内部或外部存储的密钥进行加密的加密模式需要初始化向量，则在每个密钥加密操作中都应不同。
[强制性]要求_6.2.3.2_150：受硬件保护的安全环境应支持将密钥库中加密存储的密钥绑定到特定设备。
注意：这可防止从给定设备传输存储在外部非易失性存储器中的加密密钥，以防止将存储的密钥复制到多个其他设备。
[强制性]要求_6.2.3.2.1_10：长期密钥在静止时必须受到保护，以确保机密性、完整性和防止重放攻击。这些攻击可以安装在包含这些密钥的非易失性存储设备上，或者如果安全模块不包含板载非易失存储器，则可以从非易失存储设备传输到安全模块。
[强制性]要求_6.2.3.2.2_20：受硬件保护的安全环境应保护会话期间（密钥交换操作期间）使用的短期密钥的机密性和完整性，防止重放攻击。
[强制性]要求_6.2.3.2.2_30：受硬件保护的安全环境应确保在会话基础上使用的任何短期密钥的暴露不会损害过去或未来会话中使用的任何其他短期密钥的完整性和保密性。
[可选]要求_6.2.3.2.2_10：硬件保护的安全环境应保护在会话基础上使用的短期密钥，以便在该会话终止时也终止其使用。
[强制性]要求_6.2.3.2.3_10：对称密钥（也称为共享密钥）应保留完整性、机密性和新鲜性。
[可选]要求_6.2.3.2.3_20：硬件保护的安全环境应使用内部存储的密钥加密密钥加密内部存储的对称密钥。
[强制性]要求6.2.3.2.3_30：硬件保护的安全环境应通过符合本文件密钥输出要求的方法输出外部存储的对称密钥。
[可选]要求_6.2.3.2.3_50：受硬件保护的安全环境应支持定义的生存期和对称密钥重密钥的方法。
注意：有多种方法可以确保定义的对称密钥寿命，而这些密钥寿命不一定是日期派生的，例如使用和/或启动周期和/或点火周期计数器。密钥生命周期的硬件保护安全环境强制执行至关重要。
[强制性]要求_6.2.3.2.4_10：受硬件保护的安全环境应通过使用受硬件保护安全环境的完整性设施来保护公钥，以防止未经授权的修改、替换或回滚。
[强制性]要求_6.2.3.2.4_15：为了保密，受硬件保护的安全环境应严格在受硬件保护安全环境内存储和使用私钥，以保密，即防止未经授权在环境外泄露私钥。
[强制性]要求_6.2.3.2.4_20：受硬件保护的安全环境应保持所有私钥与其各自公钥的关联。
安全密钥使用：安全密钥使用与硬件保护的安全环境有关，该环境控制特定实体（应用程序）出于特定目的使用（执行权限）加密密钥。假设需要一个API，通过该API，受硬件保护的安全环境之外的应用程序可以清楚地管理和使用密钥库，而不会未经授权地泄露密钥库。安全密钥使用与密钥存储API以及访问密钥和控制其使用的授权有关。
[强制性]要求_6.2.3.3_10：如果所有验证/授权成功通过，则硬件保护的安全环境应在硬件保护的环境中执行所有加密操作，并仅将生成的数据返回到正常环境。
[强制性]要求_6.2.3.3_20：硬件保护的安全环境应在使用期间维护所有加密算法密钥的安全。
[强制性]要求_6.2.3.4_10：硬件保护的安全环境不允许访问存储在硬件保护安全环境外部的任何密钥，除非是加密形式，并得到硬件保护安全安全环境的明确授权。
•使用JTAG、调试和查看日志不会清楚地显示密钥。
•如果产品规范要求，密钥生成和密钥迁移到系统外部的实体是在不知道密钥被披露给任何其他实体的情况下完成的。
密钥所有权是一种密钥实体关联（与密钥相关联的应用程序或实体），用于解决拥有或控制密钥的组织或用户及其在硬件保护的安全环境中的使用。
[可选]要求_6.2.3.4.1_10：受硬件保护的安全环境应通过独立管理密钥使用授权和密钥更改授权来管理密钥所有权。
[强制性]要求_6.2.3.4.1_20：如果指定密钥库来管理来自多个所有者（终端产品所有者或供应链实体）的密钥，则硬件保护的安全环境应检查请求在密钥库中安装密钥或使密钥失效的任何实体的授权，作为请求事务的一部分。
注：定义密钥所有权的要求超出了本文件的范围。当车辆/部件从一方出售给另一方时，OEM、部件制造商和/或客户之间的所有权转移可能需要一个系统程序来归零前车主的所有密钥和新车主的供应密钥。这也可能是车辆寿命结束的一部分。然而，这样的系统程序必须利用本文中所呈现的硬件保护的安全环境功能。
[强制性]要求_6.2.3.4.2_10：应维护硬件保护的安全环境，并在硬件保护安全环境的边界内执行所有密钥库管理和访问逻辑。
[强制性]要求_6.2.3.4.2_20：受硬件保护的安全环境应对存储在其硬件安全边界内的每个密钥实施访问控制。
[强制性]要求_6.2.3.4.2_30：受硬件保护的安全环境应验证并授权访问策略的所有更改，作为请求更改的事务的一部分。
[强制性]要求_6.2.3.4.2_40：如果受硬件保护的安全环境主机设备要求由受硬件保护安全环境执行任何密钥管理功能，则受硬件保护保护安全环境应验证请求实体的授权，作为执行操作的先决条件。
[强制性]要求_6.2.3.4.2_50：硬件保护的安全环境应禁止所有密码密钥访问和密码调用，直到其完成自己的通电完整性测试（参考NIST FIPS 140-2）。
[强制性]要求_6.2.3.4.2_60：受硬件保护的安全环境应保护明文密钥和私钥，使其不会通过所有物理和逻辑接口对受硬件保护安全环境及其密钥库进行未经授权的读取、写入和执行访问。
注：示例包括：JTAG、UART、调试接口、日志访问接口、API。
[可选]要求_6.2.3.4.2_70：受硬件保护的安全环境需要明确授权才能将任何密钥导出给经过验证和授权的用户。
[强制性]要求_6.2.3.4.2_80：如果产品规范要求将密钥导出到硬件保护的安全环境外部的实体，则硬件保护安全环境应完全在硬件保护的环境中执行该操作，而不向预期接收方以外的任何实体披露任何加密密钥属性。
[强制性]要求_6.2.3.4.2_110：受硬件保护的安全环境应管理其持有的每个密钥的指定使用策略（示例使用策略可能基于用途、应用程序、时间或上下文）。
[强制性]要求6.2.3.4.3_10：硬件保护的安全环境应根据密钥管理计划验证内部或外部应用程序要求的使用或有效性规则（例如有效期、地理围栏限制、使用频率等）。
[强制性]要求_ 6.2.3.4.3_20：硬件保护的安全环境应确保密码密钥使用规则/策略与其相关密钥的完整性、新鲜性和关联性。
[强制性]要求_ 6.2.3.4.3_30：如果请求的密钥使用的所有验证/授权均已通过，则硬件保护的安全环境应在硬件保护安全环境内或受硬件保护的环境保护的环境中执行请求的加密操作。[强制性]要求_6.2.3.4.3_40：硬件保护的安全环境应管理密钥属性，以防止密钥被不适当的功能或算法使用。（例如在加密算法中使用的签名密钥）。
[强制性]要求_6.2.3.4.4_10：在使用过程中，密钥库应通过加密或访问控制对私有非对称密钥和共享的秘密（对称）密钥进行保密。
[强制性]要求_6.2.3.4.4_20：在使用过程中，密钥库应通过身份验证、加密或访问控制来保持公共非对称密钥的完整性。
[强制性]要求_6.2.3.4.4_30：受硬件保护的安全环境应对存储在其受硬件保护安全环境中的每个密钥实施访问控制。
[强制性]要求_6.2.3.4.4_40：访问策略的更改应在硬件保护的安全环境中进行验证，作为请求更改的事务的一部分。
[强制性]要求_6.2.3.4.4_50：硬件保护的安全环境应在使用该密钥执行任何加密操作，将密钥访问作为单个交易之前验证请求实体的权限。
[强制性]要求_6.2.3.5_10：受硬件保护的安全环境应根据受硬件保护安全环境密钥管理计划中制定的策略管理所有密钥的有效性。
注：例如，有效性可能取决于时间、产品生命周期、市场区域等。
[强制性]要求_6.2.3.5_20：受硬件保护的安全环境不得再使用任何被撤销或以其他方式标记为无效的密钥（但是，重新提供新密钥是可接受的恢复策略）。
注：该概念可能存在于密钥空间内的无效密钥（例如，所有密钥）。可能需要硬件保护的安全环境强制执行指定的有效性规则。
注意：硬件保护的安全环境确保密码密钥有效期可以由日期、时间、属性或其他属性（如使用频率、启动周期计数、点火周期计数器，在某些情况下，甚至密码算法的估计寿命和密钥长度）决定。
注：受硬件保护的安全环境还可以将密钥有效性与正常环境固件/软件的成功认证联系起来。在这种情况下，在完成身份验证之前，密钥不会用于任何操作
注：使用一次性可编程（OTP）存储设备保存密钥可能会对管理这些密钥的有效性带来挑战。设计时应考虑到所有密钥的有效性进行适当管理。
加密密钥周期是指特定密钥被授权由合法实体使用的时间跨度，或者给定系统的密钥将保持有效。
3.限制特定算法的使用（例如，限制其估计有效寿命）。
4.限制试图穿透物理、程序和逻辑访问机制的可用时间，以保护密钥免受未经授权的泄露。
5.限制因向未经授权的实体无意泄露密钥材料而损害信息的期限。
6.限制可用于计算密集型密码分析攻击的时间（在不需要长期密钥保护的应用中）。
1.加密机制的强度（例如，算法、密钥长度、块大小和操作模式）。
6.安全功能（例如，数据加密、数字签名、密钥导出或密钥保护）。
12.对手对信息的威胁（例如，信息受到保护的对象，以及他们感知的发动攻击的技术能力和财力）。
13.新的破坏性技术（如量子计算机）对信息的威胁。
注：本文件未引用特定国家法规要求或禁止的算法；然而，这类法规表明，为了根据贸易法生产可在全球范围内销售的产品，加密货币的灵活性还有一个需要。
注：专有或定制的加密算法总是会增加意外安全漏洞的风险，因为它们无法从专业加密和安全社区的正式分析和测试中获益（因为设计文档和源代码通常不公开）。
注：NIST SP 800-131A中提供了有关弃用或过时密码算法的指南。
密钥记帐：密钥记帐是指在密钥的整个生命周期中记录、审计和报告与密钥相关的任何数据元素、事件或其他安全相关属性。本文件仅规定了硬件保护的安全环境特定密钥计费（即，日志记录相关）要求。本规范未涉及系统特定的会计和报告要求。
密钥托管：密钥托管是指导出加密密钥的过程，通常用于满足系统可用性要求所需的备份和恢复目的。本文件未涉及系统级密钥托管要求，仅涉及与硬件保护安全环境中的安全密钥传输（导出）相关的要求。
密钥迁移：密钥迁移是将所有操作密钥从一个设备导出到另一个设备；如果正在向托管的密钥集合或从托管的密钥集执行迁移，则该操作可以包括密钥托管的元素。这种类型的活动在汽车ECU中可能是必要的；例如如果需要更换ECU硬件并且其他车辆部件被配置为仅与安装在输出设备上的密钥通信。在这种情况下，迁移的密钥需要重新关联到新ECU的信任根。密钥迁移是一项非常敏感的操作，在运营客户使用生命周期状态下可能不允许进行此操作。密钥迁移需要最严格的规则/策略。
[强制性]要求_6.2.3.7_10：硬件保护的安全环境应满足为产品指定的任何密钥配置方案的功能要求，并且必须在对硬件安全环境的无缝单一API调用中执行每个此类功能，从而将受该功能影响的密钥库中的任何密钥的有效性作为该功能的一部分来维护。这可能包括供应、撤销、替换、迁移、注入或协商。
[强制性]要求_6.2.3.7_20：硬件保护的安全环境初始密钥材料应在初始产品制造期间的某个时间点安全地提供在硬件保护的环境中。
注：随后可以通过该初始密钥材料对后续密钥管理进行验证。
[强制性]要求_6.2.3.7_30：硬件保护的安全环境应根据NIST SP 800-57中概述的原则执行安全密钥管理。以硬件保护的安全环境为中心的密钥管理目标应满足FIPS 140-2中提供的要求。
[强制性]要求_6.2.3.7_60：硬件保护的安全环境应在整个硬件保护安全环境的生命周期内随时保持至少一个信任根的完整性，即，在产品正常运行期间，不应允许删除所有信任源。
[强制性]要求_6.2.3.7_70：受硬件保护的安全环境不得使用未经检查的原始非对称密钥。
[可选]要求_6.2.3.7_80：受硬件保护的安全环境应根据不同的生命周期状态，在整个受硬件保护安全环境的供应链中维护密码强制的信任链。
[可选]要求_6.2.3.7_100：硬件保护的安全环境应确保生命周期状态之间的每个转换都由允许的指定方进行加密认证。
[强制性]要求_6.2.3.7_110：受硬件保护的安全环境应支持密钥管理接口（示例接口包括密钥配置、撤销、替换、迁移、输入/输出和协商），该接口控制受硬件保护安全环境中所有加密密钥的功能和使用。示例接口包括密钥配置、撤销、替换、迁移、输入/输出和协商。
[强制性]要求_6.2.3.7_120：如果硬件保护的安全环境需要一个公共时间作为任何密钥管理操作安全的先决条件，则必须在硬件保护的环境中确认时间信号的真实性及其来源的授权，才能使其有效使用。
[强制性]要求_6.2.3.7_130：硬件保护的安全环境应防止试图执行未经授权的密钥更新的重放和回滚方案（例如，对策可能包括安全计数器或安全时间源）。
安全密钥管理和供应方案是一种系统机制，其在功能外部。在硬件保护的安全环境中使用密钥库本质上需要安全密钥配置算法。受硬件保护的安全环境的固件需要实现在此过程中指定的所有客户端机制。这些可能包括密钥的安全供应、管理、生成、派生、迁移和归零，所有这些都必须在不公开密钥的情况下完成。
密钥更新周期（密钥的特定有效期和更新频率）超出了本文档的范围，可由应用程序设计要求确定。然而，硬件保护的安全环境需要满足根据密钥管理计划生成密钥的有用频率的性能规范，以防止正常环境中的交替生成方案。
[可选]要求_6.2.3.7.1_10：受硬件保护的安全环境应验证密钥提供实体（例如，通过使用PKI）。
注意：因此，受硬件保护的安全环境可能需要预先配置接受的证书颁发机构的公钥。
注意：如果发现任何现有根密钥，攻击者可以更改这些密钥，并且可能无法恢复。现有根密钥的折衷可能超出硬件保护安全的范围；然而，硬件保护的安全环境应该提供资源，通过深度防御（声誉、多因素认证、抗侧信道攻击等）使这种妥协变得困难。
注意：建议避免创建这样一个系统：如果发现存储在一个部件实例上的信任根，则会危及对所有其他部件密钥的控制。
注意：非对称方案将信任根保持在部件外部，仅存储部件上的非机密公钥，从而无法确定同一产品线的另一部件的任何机密。例如，密钥卡特别容易受到攻击，因为一个样本可能被彻底攻击。袭击过程中泄露的任何秘密都不应导致其他车辆被盗。
注：选择使用长期密钥与临时密钥、使用主密钥与派生密钥、滚动代码定义、计数器或使用窗口超出了本规范的范围。然而，会话管理的实现必须利用在硬件保护的安全环境中实现的访问控制和有效性控制。
[强制性]要求_6.2.3.7.1_20：硬件保护的安全环境应防止以密钥更新为目标的重放和回滚方案。例如，这种支持可以包括安全计数器或安全时间源以及密钥撤销方案。
一些密钥配置算法使用公共时间作为输入，如果包括公共时间，则必须在硬件保护的安全环境中确认时间信号的真实性，然后才能有效使用。
[强制性]要求_6.2.3.7.1_40：在执行请求的功能之前，硬件保护的安全环境应检查硬件保护安全环境中外部实体的授权。
注意：由于技术人员可能不是受信任的实体，某些方案可能需要在不暴露任何秘密的情况下通过诊断（即车辆服务）会话接收密钥。
注意：密钥配置的挑战是通过交付方案维护信任链。端到端协议超出SAE J3101的范围。硬件保护的安全环境必须定义在配置密钥时验证可信源的要求。
[强制性]要求_6.2.3.7.1_50：硬件保护的安全环境应保护所有密钥交换操作免受未知密钥共享（UKS）攻击。[布雷克·威尔逊；梅内塞斯]
[强制性]要求_6.2.3.7.1_60：如果受硬件保护的安全环境执行密钥派生，并支持限制可以使用密钥执行的更新（派生）次数的策略，而无需重新密钥，则受硬件保护安全环境应跟踪更新次数并将其与密钥相关联。
密钥生成：密钥生成是使用确定性随机比特生成器（DRBG）或随机数生成器（RNG）生成对称密钥或非对称密钥对。密钥生成和密钥迁移应仅在硬件保护的安全环境中使用硬件保护的环境中的熵源来执行。
[强制性]要求_6.2.3.7.2_10：硬件保护的安全环境应具有用于密钥生成的认证RNG。
注：供应商选择和遵守特定密钥生成算法超出了本文件的范围，但可能由其他行业或监管要求决定。
[强制性]要求_6.2.3.7.2_20：受硬件保护的安全环境应在受硬件保护安全环境的边界内执行所有密钥生成功能。
[强制性]要求_6.2.3.7.2_50：应使用具有足够最小熵的RNG种子，以匹配生成密钥的预期抗攻击计算能力（即，需要128位最小熵种子来为生成128位密钥的RNG进行种子）。
[可选]要求_6.2.3.7.2_90：密钥生成应定义为本地操作，以区别于密钥供应或密钥派生。
密钥建立可以包括密钥协议、密钥协商、密钥导入或其他确定加密密钥的方法。
1.密钥协议：受硬件保护的安全环境基于预先共享的秘密（对称密钥）与另一实体就加密密钥达成一致，通常通过使用密钥导出函数。
2.密钥协商：硬件保护的安全环境使用密钥组成员的非对称公钥计算加密密钥。Diffie-Hellman是密钥协商协议的一个例子。
3.密钥导入：受硬件保护的安全环境从受硬件保护安全环境边界外部接收密钥。密钥和私钥的密钥导入需要对导入的密钥进行加密、完整性和身份验证控制。
[强制性]要求_6.2.3.7.3_10：虽然本文件未规定允许的密钥协议协议，但受硬件保护的安全环境应在所有受支持的密钥协议中使用认证。
[强制性]要求_6.2.3.7.3_20：受硬件保护的安全环境应确保所有密钥加密（“密钥包装”）算法（可以是对称的或非对称的）始终至少与对导入密钥攻击的计算抵抗力一样强。
注：示例密钥包装算法包括AES-WRAP（对称）和RSA公钥加密（非对称）。
注：供应商选择和遵守特定密钥建立协议超出了本文件的范围，但可能由其他行业或监管要求决定。
密钥派生：密钥派生是指通过向密钥派生算法（函数）中输入另一个加密密钥或秘密参数来派生一个密码密钥的过程。密钥推导用于各种加密协议和方案中。它经常用于密钥翻转方案或需要从已建立的主密钥导出可用密钥的密钥协议中。密钥推导是一个对称过程，通常由两个不同的方使用，它们需要从一个共同的已知秘密推导出相同的密钥。硬件保护的安全环境保护密钥导出功能的输入，就像保护任何其他密钥一样。当两个实体共享一个公共密钥并导出相同密钥时，使用密钥导出函数，特别是对于对称算法。受硬件保护的安全环境从共享密钥导出密钥，而不暴露共享密钥或派生密钥。
注：遵守特定密钥推导算法超出了本文件的范围，但可能受到其他行业或监管要求的限制。
[可选]要求_6.2.3.7.4_10：硬件保护的安全环境应将加密密钥导出算法的输入作为密钥进行管理和保护。
[可选]要求_6.2.3.7.4_20：硬件保护的安全环境应在不再需要密钥导出功能的所有输入时立即将其重置。
注：密钥重置的一种方法是将密钥归零，但这在某些内存技术中是不可能的。
[强制性]要求_6.2.3.7.4_30：硬件保护的安全环境应支持在硬件保护安全环境的生命周期内更新密钥推导算法，除非产品被声明为有限使用（见7.6）。
注：鉴于汽车寿命要求较长，密钥推导函数可能会过时。
密钥迁移：密钥迁移是指与在硬件保护的安全环境中直接向密钥库导入或从密钥库导出加密密钥相关的过程和规则。如果密钥未在本地迁移（例如，通过直接的、本地连接的密钥加载设备和/或人类用户），则称为密钥传输（密钥建立的子集）。当从安全硬件保护的安全环境边界输入或输出密钥或私钥时，需要对它们进行加密（包装）。密钥加密（包装）机制提供了一种保护密钥机密性的方法。
安全密钥迁移的示例用例是无密钥进入ECU更换，同时允许维护现有的遥控密钥。
另一个示例用例是通用密钥分发，用于迁移公钥以安装不同的ECU。
密钥迁移允许一个实体生成密钥并将其迁移到另一个实体。这对于仅为验证目的而迁移的共享密钥（对称密钥）（例如HMAC）尤为重要。
[强制性]要求_6.2.3.7.5.1_10：如果产品密钥管理策略允许，则受硬件保护的安全环境应支持打包要导出到受硬件保护安全环境安全边界之外的包装私钥。
注意：密钥包装机制提供了一种保护密钥机密性和真实性的方法。密钥包装机制还包括为了在硬件保护的安全环境安全边界之外输出或传输密钥而对私钥和秘密密钥进行加密。
[强制性]要求_6.2.3.7.5.1_20：如果产品密钥管理策略允许，则硬件保护的安全环境应支持将经过验证的公钥打包，以便与外部实体共享，同时匹配的私钥仍在硬件保护的安全环境的边界内受保护。
注意：在输出或导出到预期的远程实体之前，需要对用于输出的公钥进行完整性保护和认证。
[强制性]要求_6.2.3.7.5.1_30：如果产品密钥管理策略允许，则受硬件保护的安全环境应支持对称密钥导出，其中密钥经由硬件保护的安全环境密钥（其与另一硬件保护的环境实体在带外共享）加密和认证，并且仅当重新加载到导出设备或预期目标设备的硬件保护安全环境中时才能使用。
[强制性]要求_6.2.3.7.5.1_40：受硬件保护的安全环境不允许在受硬件保护安全环境的安全边界上输出明文密钥和私钥。
[可选]要求_6.2.3.7.5.2_10：如果产品密钥管理策略允许，则受硬件保护的安全环境应支持导入已通过可信外部实体加密和签名的私钥，对于该私钥，受硬件保护安全环境已具有可信外部实体的匹配公钥。
[可选]要求_6.2.3.7.5.2_20：如果在产品制造期间执行产品密钥管理，则受硬件保护的安全环境应支持通过无签名的对称密钥加密进行密钥导入。
注意：在这种情况下，可以根据设备生命周期阶段禁用某些保护，以启用设备的早期配置。
[可选]要求_6.2.3.7.5.2_30：如果产品密钥管理策略允许，则受硬件保护的安全环境应支持通过可信外部实体导入经过验证的公钥。
密钥归零：密钥归零是一种通过更改或删除数据存储的内容来擦除电子存储的数据、加密密钥和密钥安全参数的方法，以防止数据恢复。[图140-3]
可以通过直接调用或响应诸如篡改之类的敏感事件来执行密钥归零。在许多情况下，所有存储的密钥材料都不需要密钥归零。如果密钥是由密钥加密密钥加密存储的，那么它们通常不会被认为是高度敏感的，并且只有密钥加密密钥会被归零。
注：密钥归零策略需要作为硬件保护安全环境威胁环境的一个方面仔细考虑，以确保从未公开任何纯文本密钥材料，并且硬件保护安全安全环境不易遭受拒绝服务攻击（即调用密钥归零服务）。
[可选]要求_6.2.3.7.6_10：硬件保护的安全环境密钥管理计划应根据每个硬件保护安全环境生命周期状态，指定所有密钥归零的加密密钥，以及在何种情况下执行密钥归零。
[强制性]要求_6.2.3.7.6_30：受硬件保护的安全环境应将任何密钥归零命令视为特权事件，要求受影响的受硬件保护安全环境对请求实体进行认证和授权。
[可选]要求_6.2.3.7.6_40：受硬件保护的安全环境应实施篡改响应机制，该机制包括敏感加密密钥的自动密钥归零，并由受硬件保护安全环境内部启动。
原文始发于微信公众号（轩辕实验室）：标准 | SAE J3101车辆的硬件保护安全（4）
