汽车互联互通的快速发展为新功能和创新的商业模式提供了许多机会。与此同时，汽车网络受到黑客攻击的可能性也在增加。此类攻击威胁到车辆的功能安全(Safety)，并可能造成经济损失。AutoSAR标准为运行在ECU上的软件定义了基本的软件功能和接口，确保车辆在出厂时就具备必要的安全防护和检测能力。现代车辆E/E架构不断发展,但总体来看，无论E/E架构如何发展，ECU还是可以简单的划分为两大类型：

1) CP(Classic Platform):计算能力、存储空间大小、网络带宽等都通常十分有限，而实时性要求又很高，这类ECU通常要求部署轻量级的安全措施，重点解决运行在ECU上的软件和网络报文的完整性和真实性。

2) AP(Adaptive Platform):各类资源相对丰富。可以提供更多的资源给Security，因此可以部署一些入侵检测特性以及整车安全管理类的特性。未来E/E架构越来越走向融合的道路，整车的核心功能会集中在少量的高性能计算芯片中，有的文献中成为汽车计算机(Vehicle Computer),我们仍然归类为AP类。

本文先介绍一下AutoSAR标准定义的基础安全特性，再从行业角度介绍一些其他安全机制。这样在进行ECU设计的时候就可以根据TARA分析的结果选择合适的安全机制。

1. 纵深防御架构

因此讲整车的信息安全架构，在充分做好TARA的前提下，再综合考虑各ECU的资源情况、每个ECU对Safety的影响情况以及成本允许的情况下选择合适的安全架构。安全架构要体现每个ECU上部署的安全机制，各安全机制之间又是如何进行安全通信和协作 。不能简单和孤立的看单个ECU的安全能力。新冠病毒每次在国内传播的疫情分析看，也可以发现类似情况：病毒（黑客）总是从整个国家防疫体系最薄弱的环节（漏洞）开始侵入，再辐射到其他地区。可见纵深防御是核心的安全理念，见图1。

图1：“纵深防御”包括从微控制器到基础设施的各个层次的车辆架构和通信的安全措施

Source:https://www.escrypt.com/en/news-events/automated-driving-when-safety-meets-security

后续我们将按照上图介绍的框架分若干系列进行介绍，本周介绍ECU的安全机制。下面按照AP和CP来简单介绍一下其相应的采用较多的安全机制。

2. CP安全机制介绍

图2：vector 标准软件栈（红色部分为security相关的组件）

source：https://www.vector.com/int/en/products/solutions/safety-security/automotive-cybersecurity/#c2920

• 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)

Source:https://www.vector.com/int/en/products/solutions/safety-security/automotive-cybersecurity/#c66952

• 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保护方式通信的网络进行测试

Source:https://www.vector.com/int/en/products/solutions/safety-security/automotive-cybersecurity/#c66952

• 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)更新。

3.3 展望

2020年，RTA-VRTE开始在世界各地的项目中使用，旨在将AUTOSAR自适应车辆平台投入生产。此外，ETAS和ESCRYPT还提供了一个早期访问计划(EAP)，使oem和供应商能够建立下一代混合E/E架构的开发方法，同时实现AUTOSAR Adaptive已经可用的安全组件。除了这些安全模块，还需要真正全面的网络安全概念，用于互联的自动化车辆。首先，硬件安全模块(hms)作为信任锚，在VC微控制器或ecu中物理封装加密密钥材料。此外，它还可以扩展到整个生命周期内的车队范围内的车辆保护，以及嵌入式车辆攻击检测、后端车辆安全操作中心(VSOC)和无线固件(FOTA)安全更新(图12)。

图12:集成汽车网络安全与硬件安全模块作为微控制器的信任锚，并在整个汽车生命周期内监控车辆安全

Source:https://www.etas.com/download-center-files/DLC_realtimes/RT_2021_EN_18.pdf

RTA-VRTE平台软件框架使开发者能够将基于AUTOSAR自适应的E/E架构应用到虚拟环境中。这样做，它扩大了针对网络攻击的全面保护的基础，在未来的车辆中，这将不得不从微控制器扩展到车载网络，并扩展到终生的车队监控。

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.通常适合保护知识产权的场景。

4.6 基于硬件辅助的安全机制

基于硬件辅助的安全机制比较多，请参考青骥公众号文章（谈谈汽车芯片信息安全）

5. 总结

ECU相关的安全机制除了本文的基本介绍外，还有许多其他创新的安全机制，本文难以详尽，后续作者再继续撰文介绍。