在过去30年中，汽车电气化已经从最初简单的控制逻辑发展成为通过计算机完成各种高难度的任务，如动力总成控制和自动驾驶信号处理。现代汽车系统往往装有数十种包括传感器和高性能计算平台在内的不同计算机，即电子控制单元（ECU）。由于一辆现代汽车的生产通常需要很多供应商和制造商共同完成，因此需要建立一定的标准。20世纪90年代，从OSEK/ VDX等开始，AUTOSAR标准发展十分缓慢。该标准由AUTOSAR联盟开发，旨在为汽车行业的所有制造商和供应商提供通用的软件架构规范。
基于AUTOSAR的ECU威胁模型应包括本地和远程攻击者，以及不同预算、技术和动机的攻击者。尽管AUTOSAR及其据此所建立的标准（例如MISRA C）能够为具有较强鲁棒性的软件提供更高的安全性，但ECU还是有可能受到硬件的攻击。
本文不仅对AUTOSAR进行了详细介绍，同时还以此为背景展开了更为详细的论述。攻击者可以通过检查代码（如提供了源代码）或逆向工程（如仅提供二进制软件）来识别软件漏洞。我们使用了免费的AUTOSAR软件协议栈，并描述了几种具体情景，以便更好的描述将软件漏洞引入基于AUTOSAR的ECU中的方法。
当软件漏洞未知时，攻击者可能会采取其他类型的攻击。这里描述了其中几种类型，包括简单的PCB级攻击（例如调试接口）以及更高级的硬件攻击（如故障注入）。这些硬件攻击可能最终导致ECU失控和/或（安全的）信息提取失败。此外，如果未实施适当的代码签名机制（即安全启动），通常情况下，人们认为仅从内部存储器存储和执行代码的设备不需要安全启动，所以硬件攻击还有可能导致ECU固件被篡改。
01 AUTOSAR
汽车操作系统与经典计算机系统有着截然不同的任务和职责，汽车操作系统需要实时处理传感器信息，并大量使用总线协议与其他ECU通信。根据AUTOSAR规范，要求使用三层抽象方法来简化软件开发，其中特定微控制器驱动程序、内核以及通信协议栈需在基础软件层（BSW）中实现。同时，通过RTE可以开发出与基础硬件并行独立的用户应用程序以访问BSW的功能和特征。图1展示了该分层方法。
图1.AUTOSAR分层软件架构
AUTOSAR标准有两种不同的版本：AUTOSAR 传统平台和AUTOSAR 自适应平台。由于AUTOSAR 传统平台为静态链接，所以它通常用在汽车深处的核心ECU，并且灵活性较差。相反，AUTOSAR自适应平台是动态链接的，同时使用了C ++ 14功能，因此其通常用于高性能和高度连接的ECU，并具有较高灵活性。AUTOSAR系列标准已经在主要汽车供应商中得到广泛应用，本研究的主要对象为AUTOSAR 传统平台。
02 软件攻击
汽车AUTOSAR标准建立在诸如MISRA C和CERT C等公认的安全编码标准之上，主要用于为ECU生产安全、可靠的软件。因此可以认为基于AUTOSAR并完全依照以上两个编码标准所建立的软件应该是安全可靠的。本节提供了几种将软件漏洞引入不同的AUTOSAR组件的方案，但是值得注意的是文中的示例仅为个别展现。
A．MCAL漏洞
微控制器抽象层（MCAL）通常与MCU捆绑在一起，也就是说，MCAL往往是由MCU制造商所开发的。因此，保证MCU的MCAL完全符合AUTOSAR规范是实现MCU集成的前提。所有主要的MCU制造商都需要为其MCU提供此类符合AUTOSAR要求的MCAL软件包，否则就会有引入软件漏洞的风险。因此， MCAL的开发人员必须确保MCAL的安全实施。此外，MCAL的集成商也可以进行安全代码审查，以检查是否根据AUTOSAR的要求安全地实施了MCAL。
在通常情况下，MCAL的功能如何在AUTOSAR软件上层使用起到了决定性作用。例如，对于EEPROM驱动程序中存在一个可利用的整数溢出漏洞的情况，如果给此EEPROM驱动程序参数的传递设限，可能无法利用该漏洞。尽管如此，我们依旧认为在AUTOSAR软件体系架构的所有层上确保去除漏洞是至关重要的。特别是考虑到未来易受攻击的驱动程序在使用过程中可能会发生变化，从而使该软件漏洞变得可被利用。换句话说，MCAL不应盲目地信任上层传递的数据。
B．通信服务漏洞
新的复杂通信协议栈（例如以太网）的引入会对汽车行业产生影响。这是因为，与传统的通信协议栈（即CAN）相比，新的通信协议栈需要解析复杂的数据结构，从而导致建立在最上层的协议（即TCP/IP，UDS等）更容易受到软件漏洞的攻击。基于实时操作系统（RTOS）的ECU通常无法使用源自通用计算（例如Linux）的通信协议栈，因为它无法遵守RTOS的要求。通信协协议栈确实合格，但是通常没有经过适当试。最近的研究表明，FreeRTOS的TCP/IP堆栈充满了可利用的漏洞。SAFERTOS也使用了这个易受攻击的TCP/IP（这个TCP/IP是已通过ISO 26262 ASIL-D预先认证的协议栈）。因此，需要对通信协议栈进行适当的检查，同时这些通信协议栈的集成商需要确保进行相关验证测试。
03 硬件攻击
硬件攻击要求攻击者物理上出现在目标上。除使用外部暴露的接口外，大多数硬件攻击都要求攻击者打开设备。尽管本章中描述的几种攻击都需要专门的工具，但有些工具很容易获得。对于资金雄厚的攻击者（如有组织犯罪和国家执行者）来说，他们更有条件获得其他高端工具。
A．PCB级
印刷电路板（PCB）级别的攻击包括基本的硬件攻击，即攻击者打开ECU来探测和/或修改其PCB以提取非易失性存储器的内容，访问调试接口或侧录芯片之间的通信。根据ECU的设计不同，也可能存在其他攻击。如果未采取足够的措施来防止这些攻击，则ECU可能会完全受损。在无法完全破坏ECU的情况下，则通过从PCB级攻击获得的信息来执行更高级别的攻击，例如故障注入和侧信道分析。
1）修改外部存储器的内容：攻击者可以使用标准的闪存编程器来修改外部存储器的内容（例如eMMC）。换句话说，如果攻击者能够修改存储在外部存储器中的代码，便能够在ECU上执行任意代码。间接地，也可通过修改数据来实现内容的修改，从而导致软件漏洞。由于无法信任源于外部存储器的代码和数据的安全性，因此，在使用存储在外部存储器中的所有代码和数据之前都应进行身份验证（即实施安全启动）。
2）提取外部存储器的内容：攻击者可以使用标准的闪存编程器来提取外部存储器的内容（例如EEPROM）。对于存储在外部存储器中未经保护（即未加密）的安全敏感数据，则攻击者可以通过对设备进行物理访问来破坏此类数据。因此，有必要对存储在外部存储芯片上的安全敏感数据进行加密。
3）调试接口：所有MCU都有一个用于访问MCU内部的硬件调试接口，所以应正确地对这些调试接口采取保护。与硬件调试接口进行通信的工具和知识是在可以承受的范围内的。但是，如果攻击者能够与硬件调试接口进行通信，ECU的安全性便会遭受完全损害，所以大多数原始设备制造商（OEM）要求对这些调试接口采取保护措施以降低此类威胁
4）信号修改：不应将与安全性有关的数据存储在外部存储器中，尤其是在需要保证该数据完整性的情况下。UDS安全访问中的try counter就是一个比较容易出错的案例。try counter应根据AUTOSAR标准按原样实现，且在执行了三个错误的身份验证尝试后，将触发十分钟的尝试延迟。如果将try counter存储在外部闪存中，则攻击者可以通过修改PCB上的外部闪存信号来阻止try counter的正确写入。
B.故障注入
在故障注入攻击中，芯片预期的行为会在其环境条件的冲击下产生改变。具体来说，硬件和软件的预期行为会因为其目标中被注入的一些小故障而遭受影响。基本的故障注入技术会影响芯片的时钟和/或电压供应，而更高级的故障注入技术则会将电磁脉冲和/或激光脉冲注入芯片的表面。目前已经有一些大众接受度较高、价格合适的用于处理这类攻击的工具。
在学术界，由这些小故障注入引起的故障类型（即故障模型）已经得到广泛研究，其共同关注点是，在执行小故障注入时进行指令修改已经成为很强的攻击原语。列表1展示了关于ARM AArch32系统上损坏ADD指令的示例。仅通过翻转指令代码中的一位，就可以改变加法的结果，从而完全影响软件的预期行为。因此，故障注入攻击者可以完全破坏大多数ECU所依赖软件的安全模型。
传统的故障注入攻击的目的是在做出安全关键决策时更改芯片的预期行为，而更高级的攻击则通过执行任意代码来控制芯片。第五章中的案例研究证明了这种高级攻击。
C．侧信道分析
侧信道分析（SCA）攻击是一种使用侧信道从设备获取信息的被动攻击，通常用于从设备中提取密钥或绕过身份验证机制。常见的侧信道包括定时、功耗和电磁辐射，而侧信道攻击在软件和硬件实现上均会出现。在汽车行业，UDS安全访问检查和加密操作（例如HSM）是最典型的攻击目标。
本篇文章对AUTOSAR展开了介绍，描述了针对AUTOSAR的软件攻击和硬件攻击。下一篇的内容将详细为大家描述执行故障注入攻击的案例研究，敬请期待！