标准 | SAE J3101车辆的硬件保护安全（2） - 网络安全

SAE-2020-J3101 “ Hardware Protected Security for Ground Vehicle”，是美国汽车协会2016年发布的关于车辆硬件安全方面的标准，规定了地面车辆应用的硬件保护安全要求。这里的硬件特指 HSM等硬件。

SAE J3101 制定了针对这些硬件的需求，SAE J3101属于最佳实践类文档，关注整个网络安全体系中硬件的相关网络安全技术需求。

以下译文仅供业内学习参阅，如有不妥敬请见谅

4.硬件保护的安全环境

4.1定义

SAE J3101中概述的要求主体应定义称为硬件保护安全环境的安全环境。

车辆硬件保护安全中概述的要求范围之外的所有其他内容将代表“正常环境”（例如，应用程序执行环境），与硬件保护安全环境相比，它代表了更大的攻击面，是不太可信的域。

硬件保护的安全环境提供了由硬件支持实现的至少一种安全机制，固件可以进一步利用或扩展硬件支持。

硬件保护的安全性提供了硬件机制，这些机制可能需要物理存在来执行超出正常环境范围的特定安全功能。

为扩展受硬件保护的安全环境而编写的固件（可能利用共享硬件资源）必须以这样的方式操作，即以扎根于微控制器的硬件安全机制的安全方式扩展提供受硬件保护安全环境的服务的信任链中的可用硬件元件的安全性。

硬件硬件保护安全环境的主要目的之一是减少整个系统的信任基础的大小、复杂性和攻击面，从而形成一个最小的信任锚点，该锚点是隐式信任的。然后，信任锚形成可以验证所有其他功能的基础。此外，受硬件保护的安全环境包括一种将机密与正常环境隔离并防止机密暴露的方法。

硬件保护的安全环境中的固件可以利用硬件来保护静态和使用中的数据。

正常环境应用程序可以利用安全环境来代表此类应用程序保护数据；此外，正常环境应用程序可以直接使用硬件保护的安全环境的硬件，然而，仅以不受信任的方式使用它。

4.2硬件保护安全环境的设计

硬件保护的安全环境可能是一个封闭系统，其中输入被控制，并且可以实现关于RAM、密钥存储等的要求。通过这种封闭系统，可以实现一般的构建块。如果适当和适用，可以在系统级别使用这些块。利用此构建块模型，某些硬件保护的安全环境要求可能适用于车辆网络内的任何ECU，而其他要求可能仅适用于专用ECU，如网关和车外通信ECU。

例如，在仅使用非常小的微控制器的智能传感器的使用情况下，建议将安全性推入智能传感器，或者也依赖于信号接收侧（ECU上游）的安全性。最佳实践是，即使在下游且不在另一个ECU内部（具有硬件保护的安全环境）的受约束传感器中，也应设置硬件保护的环境。这将提供安全防御能力，以避免对车载网络的内部攻击行为。

如果一个ECU内设计有多个芯片，那么可以设计芯片的交互以仅依赖该ECU内的单个硬件保护安全环境。

硬件保护安全环境的一个目标是避免所有供应商都需要成为密码专家，并将密码的实现集中在一个相对隔离的子系统中。

正常环境应用中的安全设计超出了SAE J3101的范围。

4.3硬件保护的安全抽象层

SAE J3101涵盖了物理层和第一硬件抽象层以及在其中实现的安全机制。正常环境中间件和应用程序超出了SAE J3101的范围，不得用于实现SAE J3101中概述的任何要求。

注意，一些其他物理接口和硬件抽象层组件可以与正常环境共享。在正常环境和受保护环境之间共享的任何硬件组件都不应有任何内存或任何秘密材料的滞后，因此使用共享硬件组件的正常应用程序无法通过该硬件组件确定安全机制的任何特征；例如，硬件内存保护单元、计时器、计数器、外围接口。

请注意，某些硬件组件不能在安全环境之外共享并维护安全，这些组件必须专用于安全环境，以避免向正常应用程序提供提升的权限。

图1-硬件保护的安全环境抽象层

4.4由硬件保护的安全环境保护的系统的功能安全性确定

根据目标应用，利用到硬件保护的安全环境的接口的应用的用例可以被认为是功能安全相关的。系统设计者应参考ISO 26262以获得功能安全要求的指导。硬件保护的安全环境可用于遵守功能安全目标，或可能是违反功能安全目标的潜在原因。在这种情况下，硬件保护的安全环境将被视为具有功能安全相关要求的组件。

示例：硬件保护的安全环境可能影响功能安全目标的常见示例是使用基于密码的消息认证码（CMAC）作为网络通信端到端保护的安全机制。如果硬件保护的安全环境由于系统或随机故障而提供假阳性，则系统的功能安全性可能受到影响。重要的是要注意，不同的系统架构可以允许通过系统级冗余安全机制来实现功能安全目标，这将使硬件保护的安全环境不必满足严格的功能安全要求。

宙飒天下网