Search Results

Symbolic code execution is a powerful cybersecurity testing approach that facilitates the systematic exploration of all paths within a program to uncover previously unknown cybersecurity vulnerabilities. This is achieved through a Satisfiability Modulo Theory (SMT) solver, which operates on symbolic values for program inputs instead of using their concrete counterparts. However, in complex code bases, this approach faces significant limitations, such as program path explosions or unavailable dependencies, which can result in conditions that the SMT solver cannot reason about. Consequently, SMT solvers are often considered as too costly to implement for automotive testing use cases and are rarely employed within this domain. In contrast, fuzz testing has recently gained traction in the automotive industry as an invaluable testing technique for identifying previously unknown vulnerabilities. Its initial setup is straightforward and typically yields useful findings.

In recent years, fuzz testing has established itself as a reliable and indispensable testing method for finding previously unknown and product specific vulnerabilities within the code base of automotive systems. As such, we see increased requirements for automotive products that call for fuzz testing per default. Based on the semidecidable characteristic for finding fuzz testing results, i.e., virtually an infinite test space, it is a non-trivial task to generate plausible evidence that sufficient fuzz testing has been applied to the target system. In this paper, starting from fuzz test result generation, we specify the individual steps necessary for preparing a sound evidence report. We describe how evidence is created in this context and which information is relevant. The traceability of fuzz testing product requirements is a driving factor thereby.

With the rapid development of connected and autonomous vehicles, more sophisticated automotive systems running large portions of software and implementing a variety of communication interfaces are being developed. The ever-expanding codebase increases the risk for software vulnerabilities, while at the same time the large number of communication interfaces make the systems more susceptible to be targeted by attackers. As such, it is of utmost importance for automotive organizations to identify potential vulnerabilities early and continuously in the development lifecycle in an automated manner. In this paper, we suggest a practical approach for integrating fuzz testing into a Continuous Integration (CI) pipeline for automotive systems. As a first step, we have performed a Threat Analysis and Risk Assessment (TARA) of a general E/E architecture to identify high-risk interfaces and functions.

Cybersecurity for automotive systems is challenging, and one of the major challenges is how to measure this specific system property. With the increased need for cybersecurity in automotive systems due to the development of more advanced technologies and corresponding increased threat vectors, coupled with the upcoming International Organization for Standardization and the Society for Automotive Engineers (ISO/SAE) 21434 cybersecurity standard for automotive systems and cybersecurity regulations in The United Nations Economic Commission for Europe World Forum for Harmonization of Vehicle Regulations (UNECE WP.29), it is becoming increasingly important for auto manufacturers and suppliers to have a clear and common understanding and agreement of cybersecurity metrics for the development and deployment of vehicles. The main contribution of this article is the contextualization of existing metrics from literature and mapping out how they may fit within a standardized framework.

Automotive systems have become increasingly more complex, interconnected and prone to cyberattacks in recent years. With larger software bases and multiple external communication interfaces, the risks for new vulnerabilities and attack vectors on vehicles also increase. Therefore, modern cybersecurity validation is highly stressed for finding security vulnerabilities and robustness issues early and systematically at every stage of the product development process. The integration of a sophisticated fuzz testing program within the overall cybersecurity validation strategy allows for accommodating towards these challenging demands. In this paper, we review a general automotive cybersecurity engineering process containing functional testing, vulnerability scanning and penetration testing, and highlight shortcomings that can be complemented by fuzz testing.

Modern vehicles utilize various functionalities that require security solutions such as secure in-vehicle communication and ECU authentication. Cryptographic keys are the basis for such security solutions. We propose two approaches for secure and efficient invehicle key management. In both approaches, an ECU acting as a Key Master in the vehicle is required. The first approach is based on SHE. The Key Master generates and distributes new keys to all ECU based on the SHE key update protocol. The second approach performs key establishment based on key derivation. The Key Master sends a trigger in form of a counter and all ECUs derive new keys based on the received counter value and pre-shared keys. It is thus possible to handle in-vehicle key management without the need for an OEM backend to manage all keys. This reduces cost and complexity of the solution.

In this paper, we outline past, present and future applications of automotive security for engine ECUs. Electronic immobilizers and anti-tuning countermeasures have been used for several years. Recently, OEMs and suppliers are facing more and more powerful attackers, and as a result, have introduced stronger countermeasures based on hardware security. Finally, with the advent of connected cars, it is expected that many things that currently require a physical connection will be done remotely in a near future. This includes remote diagnostics, reprogramming and engine calibration.