导读

    “未来汽车”将具有更高的舒适性、便捷性和安全性，但同时也带来了很多潜在的脆弱环节。过去，只有直接的物理接触才能对汽车造成破坏。而现在，只要借助互联汽车的联网功能，无 需物理接触，汽车就可能受到破坏。随着行业向真正的自动驾驶体验迈进，如何应对不断增加的车内系统复杂性和相关信息安全漏洞，将成为汽车制造商和供应商更加重视的问题。其长期目标是开发能够应对不同威胁的自我防护系统。为了成功实现这个目标需要整体考虑功能安全、信息安全和可用性。

    由于消费者对车载连接和网络互联的技术需求增长，汽车软件和汽车网络变得愈发复杂。客户希望汽车集成可以快速更新和部署的移动设备、互联网服务和各种各样的应用程序。开发周期之短，给汽车软件提供商和汽车制造商带来了压力，迫使他们应用敏捷创新模式来满足需求。结果是，越来越多的车载系统和传感器必须能够相互通信，以及同外部站点通信（图 1）。不同设备之间交换的信号被用于功能安全应用，以及和 IT信息安全问题相关的领域。这方面的典型应用包括驾驶辅助系统和自动驾驶解决方案，并且能够支持汽车和道路基础设施之间交换交通和危险消息。功能安全和信息安全对彼此都有重大的影响。这一事实目前体现在常见功能安全标准的运用中，如 IEC 61508 和 ISO 26262。此外，甚至是政府组织（如欧盟委员会）也已经承认了功能安全与信息安全之间的直接关系。2012 年，Jose Manuel DuraÄ o Barroso 在核能安全演讲中强调了这个观点 ：“……没有信息安全就没有功能安全，反过来也一样。”因此，车载系统必须根据最新的技术发展，提供功能安全和信息安全如何共同运用的基本原则。

信息安全和功能安全机制

    有功能安全需求的车载软件系统中，基础软件必须提供相应机制，确保软件系统的功能安全。目前 AUTOSAR 框架已经充分建立了此类功能机制，并在 ISO 26262 中进行了描述。在此方面，我们区分了表示功能安全目的的三种互不干涉 (FFI) 类型。

    “空间上的互不干涉”指必须保护功能安全关键组件的相关数据，防止其他组件访问。在大多数软件架构中，操作系统提供了内存划分的机制。图 2 所示的架构，具有基于 AUTOSAR 的功能安全保护机制。内存保护由“Safety OS”提供。 

    “时间上的互不干涉”与时间组件有关 ：必须确保为功能安全关键软件分配所需的计算时间，并按照预期顺序执行。在图 2 中，它是以“Safety TimE Protection”模块的形式呈现。

    ISO 26262 将所谓的“信息交换”定义为 FFI 的第三 种类型——必须保护关键数据和信息，能够检测受到损坏或缺失的数据。在电子控制单元 (ECU) 中，可以直接通过 "RTE"（图2 中的 Safety RTE）实现防护。

信息安全机制

    功能安全关键系统可最大化地减少系统本身产生的错误，而信息安全机制则必须避免系统因未经授权的外部访问而遭到潜在的破坏。由于威胁在系统生命期内变化显著，人们在设计系统时基本无法预知外部的攻击方法，这就导致信息安全相关系统的威胁模型极具动态特点。这方面的关键因素主要包括不断增加的计算性能和攻击者的创造力。

    最重要的是，基础软件仍然必须能够提供确保系统信息安全的机制。可以通过扩展系统功能安全机制，加入信息安全相关措施来实现。鉴于对这两个方面的分析都有赖于风险模型，我们必须认可和发挥两者的协同作用。这样，在寻找信息安全漏洞时就有可能发现新的功能安全漏洞，反之亦然。

    堆栈溢出就是一个具有功能安全与信息安全影响的漏洞示例。堆栈溢出来自软件缺陷这个功能安全问题，或者因针对性攻击引发，而这就是一个信息安全漏洞。在这两种情况下，我们必须在相应分析中确定此类场景，通过合适的软件设计采取预防措施，或者在运行时执行检测。

    具体来说，可以通过上述的内存保护机制（“空间上的互不干涉”）防止出现此类错误和攻击。虽然这种措施本身不具备针对拒绝服务攻击的防护作用，但它可以确保系统不会处于未定义的状态，而是以前定义过的错误状态。此外，使用 FFI 推断还可以通过可靠的方式，分离功能安全相关软件部分与容易受到外部攻击的部分。一方面，现代 CPU 支持分配读取权⸺通过 MPU 提供写入保护。这样只有具有合适权限的模块可以读取信息安全相关数据，如加密密钥。另一方面，我们可以专门设置或撤销执行权。这样，用于访问敏感信息安全数据的代码就可以标记为不可执行，仅允许在计划执行时间访问敏感数据。

    此外，为堆栈分配适当限制的执行权，可以防止在错误环境下执行有害代码。因此，这两种机制相结 合可以防范来自两个典型攻击角度的危害。

通过信息安全措施保护消息

    在功能安全方面，功能安全关键应用程序必须能够依赖已接收的消息。信息安全负责保护消息：必须确保通信伙伴和交换消息的真实性，数据完整性，以及消息内容的时效性和保密性。

    确保正确消息来源和内容真实性，需要检验已接收数据的完整性，从而排除任何消息篡改的操作。最常见的方式是使用消息认证码（MAC）。基于密码的消息认证码（CMAC）是一个不错的例子，随着 AUTOSAR 4.2.1 规范的发布而推出。CMAC 的基础是对称高级加密标准（AES）算法和相应的底层加密密钥。原始消息在递送之前要全部或部分附上已计算的 MAC。在接收侧，可以使用和发射侧执行的相同计算，检查消息的完整性。然后比较这两个结果（图 3）。

    但是，仅有 MAC 无法防范随时记录和之后（重新）发送的有效消息。保护系统防止此类入侵，需要对任何身份证明进行个性化定制，这就必须获得接收方的验证。这可以通过使用针对 MAC 生成且经常变化的值来实现，例如简单的单调计数器或可靠和防篡改时间戳。可以通过加密确保消息保密性，即防止第三方读取消息内容。最常见的方法是对称方法 AES。

系统和软件开发

    已经有很多经证明有效的方法能够执行功能安全方面的分析。它们通常基于经典风险分析，采用专门技术进行扩展，例如用于分析软件架构和实际执行。因此，系统风险和实施分析是功能安全应用开发最重要的扩展。但是，目前人们很少在 ECU 标准开发流程中应用信息安全分析。

    功能安全和信息安全分析有很多共性，比如二者都基于风险。分析越接近于实际实施，其相似度就越高。从软件设计开始的正式检查几乎一模一样。最终这两个方面都需要谨慎的软件开发。这样才能通过现在的常用方法和流程，避免或尽可能减少功能安全与信息安全领域的众多威胁。

AUTOSAR ECU 的功能安全与信息安全

    采用行之有效的功能安全机制的现有 AUTOSAR 架构可用于设计符合功能安全和 IT 信息安全要求的 ECU。要满足常见的信息安全要求，可以使用 EB tresos SecOC 等模块扩展恰当的用例，这个模块包含汽车通信的保护组件。此外还可以扩展各种措施，如更广泛的信息安全防护机制或保密防护方法。

    由于功能安全与信息安全密切相关，我们务必同时考虑这两个方面，并确定流程和方法协同。一些信息安全方法可通过额外的防护功能强化功能安全工程设计。反过来，必须检查具体信息安全措施是否包含已经考虑到功能安全用途的功能。

    此外，确保关键系统功能永久可用将成为自动驾驶汽车成为现实的关键。系统在检测到功能安全和信息安全风险时通常通过的安全状态是“关闭”。但这种情况对自动驾驶汽车来说是不可接受的，因为在任何情况下都必须确保基础功能的正常运行，绝无例外。这种全面的可用性非常依赖各种软件机制，但也需要相应的硬件支持。因此，实现全自动驾驶的中期目标就是全面审视车内系统组件，以便开发能够兼顾必要的功能安全、信息安全和可用性这些方面的系统，从而构建独立的防护系统。

本文作者

Elektrobit 针对汽车 ECU 的 AUTOSAR 软件产品和解决方案：

• Elektrobit 经典 AUTOSAR 基础软件、汽车操作系统和量身定制的工具环境：EB tresos

  www.elektrobit.cn/products/ecu/eb-tresos/

• Elektrobit 用于打造高性能计算平台（HPC）的自适应 AUTOSAR 基础软件、虚拟机监控程序（Hypervisor）、车规级操作系统和集成式开发环境：EB corbos

  www.elektrobit.cn/products/ecu/eb-corbos/

• Elektrobit 推出的业内首款能够实现安全、高性能车载网络通信的汽车以太网交换机固件：EB zoneo

  www.elektrobit.cn/products/ecu/eb-zoneo/

• Elektrobit 为汽车电子控制单元（ECU）提供的嵌入式安全解决方案：EB zentur

  www.elektrobit.cn/products/security/