AutoSAR 标准--基础安全特性
—— CSM:密码服务管理器(Crypto Service Manager)：
· 访问加密服务
· 配置用于执行服务的加密服务和算
· 同步或异步执行的配置
· 安全计数器的配置
· 对加密密钥的操作配置
· 配置证书操作
—— CRYIF:密码算法接口(Interface for cryptographic algorithms)
CryIf 模块使使用 CSM 基于硬件和基于软件的加密解决方案成为可能。必要的分配方案由加密接口管理。CRYIF 模块为不同的加密解决方案提供了统一的接口，例如:
· 基于软件的算法实现，由 Crypto (SW)模块提供
· 基于硬件的加密功能，由安全硬件扩展(SHE)或硬件安全模块(HSM)通过加密(HW)模块实现。
—— Crypto (HW)
Crypto (HW)模块作为访问安全算法和函数的驱动程序，通过硬件信任锚(HTA)提供。有不同的 HTA 类型，如安全硬件扩展(SHE)和硬件安全模块(HSM)。
—— SecOC: 安全通信（Secure Onboard Communication）
SecOC 模块，也称为身份验证消息，用于验证两个 ecu 之间的通信。这种验证可以防止第三方注入或仿冒正确的通信伙伴。SecOC 与 PDU 路由器进行交互。这种交互可以由应用程序控制。该模块提供以下功能:
· 通过认证和完整性保护 PDU 的传输。
· 使用消息认证码(MAC)进行认证。消息身份验证码的实际生成和验证由 CSM 执行。
· 防止重放攻击。
这里使用了一个计数器“新鲜度值”。它由一个独立组件生成，即新鲜度值管理器(FVM)。支持不同的方法来生成新鲜度值。
图 3：为了模拟和测试 secoc 安全通信，安全管理器生成(左)并验证(右)消息验证码(MACs)
—— TLS: TLS 客户端，用于在以太网上进行安全通信
此模块包含传输层安全客户端。使用 vTls 对基于 TCP 的协议的通信进行加密。vtls (Client)的使用仅限于智能充电用例。对于 TCP/ UDP 级别上的安全客户端-服务器通信，使用 TLS 协议(传输层安全)。安全管理器为以太网通信提供 TLS 协议栈。这允许工具方便地使用协议(包括参数化)来测试由 TLS 保护的通信。除了所需的证书层次结构外，还可以配置要使用的密码套件。这些包含用于建立安全数据连接的算法和参数。见图 4.
图 4：TLS 握手示意图
—— IPSec:Internet 协议安全(IPSec)
附加的 vIpSec 允许根据 IETF RfC 4301 建立 IPsec 通信。根据 RfC 4302，功能被限制在传输模式和 Authentication Header 的使用。身份验证头将数据完整性和数据验证添加到有效载荷，但不允许保密。
通过这种方式，您可以实现经典的保护目标，如机密性、真实性和完整性。通过对 IP 层的保护，实现了以上各层的保护目标。IPsec 协议的使用实现了对一些/IP、DoIP、TLS 和 HTTP 等较高层协议的透明保护。Security Manager 提供了一个包含 IPsec 协议中最重要元素的 IPsec 堆栈:
· 在传输模式中使用“认证头”安全方法全面保护以太网通信
· 实现 IKEv2 协议(Internet Key Exchange v2)，为基于证书的会话灵活、安全地生成密钥材料。
除了提供协议栈之外，Security Manager 还支持 IPsec 协议的全面配置。安全配置文件用于此目的，它结合了所有必要的配置参数。其中包括密码套件、证书和安全策略。
图 5：CANoe 支持对 ecu 和以 ipsec 保护方式通信的网络进行测试
—— vXMLSecurity :XML 安全
此模块用于生成或验证 XML 签名，这些签名将附加到基于 W3C XML 安全标准的 exi 编码的数据中。根据 ISO 15118，当使用“Plug and Charge”时，这个功能是必需的。
—— ETHFW: 静态的以太网报文过滤防火墙（见图 6）
图 6：Vector Eth 协议栈（包括防火墙模块）
—— SEM:安全事件内存（Security Event Memory）
用于安全事件的防篡改保存
—— KEYM: AUTOSAR 密钥管理器
KeyM 用于管理和分发加密材料，如对称和不对称密钥和证书。Key Manager 提供基于可配置规则的解析和验证证书的功能。它使用 CSM 接口来存储证书和执行加密操作。
· 通过诊断例程接收新的加密材料(密钥、证书)
· 验证密码材料的真实性、完整性和新鲜度
· 提供与业务逻辑集成的调用，用于不同典型的关键生命周期阶段(生产、初始化、更新、修复、替换)
· 支持 SecOC
· 支持共享密钥的安全分发
· 记录安全事件到 SEM (security event memory)。
图 7：AutoSAR KeyM 上下文
Source:https://assets.vector.com/cms/content/events/2019/Webinars19/Vecto_Webinar_Automotive_Cyber_Security.pdf
KeyM 自身又由两个组件组成：Crypto Key 和 Certificates,分别管理密钥和证书，见图 8.
图 8：AutoSAR KeyM 组件
Source:https://assets.vector.com/cms/content/events/2019/Webinars19/Vecto_Webinar_Automotive_Cyber_Security.pdf
—— 安全诊断:AUTOSAR 支持在安全内存中记录 IT 安全事件。
它还监控通过 UDS 服务 0x27 (SecurityAccess)和 0x29 (Authentication)的授权访问数据。例如，诊断测试设备只有在以前执行过质询-响应通信或使用证书对自身进行身份验证时才能访问已记录的安全事件。
3. AP 安全机制介绍
AP 上的重要特征是软件服务化，软件服务化导致组件之间的通信是动态的，组件可以根据需要动态订阅或者取消其他组件提供 服务。另外一个特征是较多的不同信任级别的服务运行在相同的芯片里，这就要求芯片具有很强的隔离能力。
AUTOSAR 自适应平台使动态适应应用软件成为可能，并使用 AUTOSAR Runtime for Adaptive Applications (ARA)接口与基于 posix 的操作系统(如 Linux)建立连接(图 9)。为了确保来自不同厂商和不同 ASIL 类别的软件在 VC（vehicle computers）上安全运行，管理程序用于预配置分区。
图 9:AUTOSAR Classic 支持具有固定实时需求的系统，而 AUTOSAR Adaptive 将自己作为动态应用程序的标准
Source:https://www.etas.com/download-center-files/DLC_realtimes/RT_2021_EN_18.pdf
3.1 AP 安全机制简介
—— 网络安全管理
智能互联汽车无法通过单独的措施来确保安全，而只能通过基于整个车辆架构风险分析的集成概念来实现。 这些概念必须分解为各个组件、ECU 及其逻辑分区的安全要求。因此，AUTOSAR Adaptive 具有一组集成的基本安全功能，开发人员可以使用这些功能来满足联网自动车辆系统不断变化的定量和定性保护要求。鉴于分布式、基于软件的 E/E 架构会在实时条件下增加数据负载，因此必须设计安全措施以提高性能。这就是为什么将以下安全功能集成到 AUTOSAR Adaptive 中的原因（图 10）
图 10:AUTOSAR Adaptive 中的中央安全组件
图片来源：https://www.etas.com/download-center-files/DLC_realtimes/RT_2021_EN_18.pdf
AUTOSAR Adaptive 中的安全组件
· 用于管理密钥材料和访问加密原语的加密堆栈
· 通过 TLS 和 IPSec 进行安全通信
· 敏感资源的访问保护（例如，通过身份和访问管理模块的密钥
· 从单个应用程序到完整平台的所有内容的安全更新
· 由于继续将安全启动信任链作为“可信平台”的一部分而获得正宗软件
—— 作为“关键组件”的密码学套件
许多安全用例依赖于加密原语，例如，加密机密数据或验证软件更新的签名。为此所需的加密密钥和证书必须安全存储，并由授权的应用程序管理，有时甚至在多个 ecu 之间进行同步。在 AUTOSAR Adaptive 中，这些原语是通过加密功能集(也称为加密 API)提供的。它提供了所提供接口的抽象，从而提高了整体软件的可移植性。为了确保安全的数据交换，AUTOSAR Adaptive 遵循最新的标准，包括 TCP/IP 通信通过以太网。使用 TLS 和 IPSec (IT 世界中已建立的协议)，可以在车辆内部和与外部实例建立不受操纵或窃听影响的通信安全通道。
AUTOSAR Adaptive 管理对系统资源的访问，如持久内存、通信通道和加密密钥。AUTOSAR 身份和访问管理模块提供了一个看门人，只允许显式授权的应用程序访问各自的资源。访问权限可以根据需要进行配置，并随时更新。
—— 安全更新和可信平台
AUTOSAR Adaptive 中的安全更新功能有助于修复检测到的漏洞，例如 IDS(入侵检测系统)发现的漏洞。它接收并处理单个应用程序甚至整个平台的安全更新。每个 Update blob 都由后端签名，以便只执行来自受信任源的更新。除了更新，ECU 和 VC（vehicle computer）应用程序也必须定期进行验证。这需要安全引导或 AUTOSAR Adaptive 中的可信平台功能，作为一个信任锚，验证所有应用程序以及平台本身。通过维护从引导到平台到应用程序的信任链，只执行受信任的软件。
3.2 RTA-VRTE：AUTOSAR Adaptive 的平台软件框架
对于 AUTOSAR Adaptive 的未来用户来说，熟悉当前的新架构至关重要。车辆运行时环境(RTA-VRTE)平台软件框架是集成和实现安全功能以及所有其他 AUTOSAR 自适应兼容流程的理想基础。RTA-VRTE 包含了基于微处理器的车载计算机的所有重要中间件元素。该平台的软件框架使虚拟 ecu 的功能可以在传统的桌面 pc 上进行仿真，并通过以太网进行联网。RTA-VRTE 创建一个由四层基本软件架构组成的虚拟机，第五层包含特定于车辆的平台服务，见图 11。
图 11:RTA-VRTE 五层模型支持 VCs 的重要软件功能和需求
Source:https://www.etas.com/download-center-files/DLC_realtimes/RT_2021_EN_18.pdf
级别 1 和 2 包含用于硬件的基础架构软件(例如，设备驱动程序)和 posix 兼容的操作系统。第 2 级还提供了源自 AUTOSAR 自适应规范的特定于平台的元素——首先也是最重要的执行管理。这将管理动态分配的应用程序，确保它们正确地启动和停止，并监视对分配的资源和执行限制的遵守情况。因此，执行管理是 IT 安全的关键功能，提供可信平台，并验证自适应应用程序的完整性和真实性。这样，可能的操纵或损坏就可以提前检测出来。
此外，三级通信中间件保证了动态、灵活的自适应应用程序和其他软件应用程序可以集成到系统中。通信管理作为 RTA-VRTE 的核心组件，控制和规范各层之间的交互，保证 ECU、车载平台服务等封装软件在 4、5 层的正常运行。在保护通过身份验证的应用程序提供的服务之间的端到端通信方面，该功能也与网络安全高度相关。
RTA-VRTE 通信管理和特定 ecu 的服务在 level 4 上为应用程序开发人员提供了一个通用的汽车应用框架。为了提供安全性，该级别还提供了一个更新和配置管理器(UCM)，它支持单个应用程序的经过身份验证的更新，并在整个平台上协调它们。在 RTA-VRTE 的第 5 级中，AUTOSAR++方面允许集成整个车辆甚至整个车队的功能，为 RTA-VRTE AUTOSAR 自适应应用程序集提供强大的空中(OTA)更新。
4. 其他安全机制
4.1 CFI(Control Flow Integrity)
CFI 用来防止漏洞利用的技术，通过确保 ECU 的程序不违反预期的执行流。该技术适合 AP 和 CP。不少安全厂商已经支持该功能。见图 13.
4.2 ECU Firewall
ECU 级防火墙，通过深度报文解析（Deep Packet Inspection）用来防止 ECU 内部通信的攻击。该技术适合 AP 和 CP。见图 13.
4.3 应用程序控制
主要是防止 ECU 在启动和运行时刻运行非法软件。通常适合 AP 架构。见图 13.
4.4 入侵检测系统
入侵检测模块不在本文赘述，可以参考青骥的 AutoSAR IDS 专题文章（青骥原创 l AutoSAR IDS 标准介绍）。见图 13.
图 13: Argus ECU 安全机制示意图
图片来源：https://argus-sec.com/connected-ecu-protection/
4.5 软件保护（白盒密码技术）
当设备部署到黑客手中时，保护设备的难度要大几个数量级。对设备具有物理访问权限的坚定黑客可以做很多事情来获得超级用户访问权限并危及系统安全：提取固件映像、逆向工程软件、重新激活调试软件等。历史上充斥着成功入侵设备的例子——从网络路由器到医疗设备，再到信用卡系统、远程信息处理单元和整车。普遍存在的软件安全威胁包括逆向工程、软件篡改、复制/克隆和自动攻击。针对这些威胁的成功安全策略是多维方法——数据安全、网络/API 安全和软件保护。
软件保护往往成为最后也是最关键的防线。
软件保护是一套先进的网络安全技术、库和工具，使用户能够自定义对其关键数字资产（例如密钥、代码和数据）的保护。该产品对于需要最佳可更新软件安全性的安全精明的组织特别有用。软件保护的安全技术通过复杂的数据、功能和控制流转换、反调试、白盒密码术提供应用程序保护，以及主动完整性验证。软件保护将这些安全技术直接集成到客户的软件构建过程中，在源代码级别工作，还具有互补的、特定于平台的二进制保护，以确保在不影响易用性的情况下实现最高级别的软件保护和快速部署。关于白盒密码的介绍请阅读附件 3.通常适合保护知识产权的场景。