Search Results

Abstract Aircraft cybersecurity efforts have tended to focus at the strategic or tactical levels without a clear connection between the two. ...CSSEP’s process model postulates that security is best achieved by a balance of cybersecurity, cyber resiliency, defensibility, and recoverability and that control is best established by developing security constraints versus attempting to find every vulnerability. ...CSSEP identifies the major functions needed to do effective aircraft cybersecurity and provides a flexible framework as the “missing link” to connect the strategic and tactical levels of aircraft cybersecurity.

Abstract Connected autonomous vehicles that employ internet connectivity are technologically complex, which makes them vulnerable to cyberattacks. Many cybersecurity researchers, white hat hackers, and black hat hackers have discovered numerous exploitable vulnerabilities in connected vehicles. ...This study expanded the technology acceptance model (TAM) to include cybersecurity and level of trust as determinants of technology acceptance. This study surveyed a diverse sample of 209 licensed US drivers over 18 years old.

Abstract The United Nation Economic Commission for Europe (UNECE) Regulation 155—Cybersecurity and Cybersecurity Management System (UN R155) mandates the development of cybersecurity management systems (CSMS) as part of a vehicle’s lifecycle. ...Due to the focus of R155 and its suggested implementation guideline, ISO/SAE 21434:2021—Road Vehicle Cybersecurity Engineering, mainly centering on the alignment of cybersecurity risk management to the vehicle development lifecycle, there is a gap in knowledge of proscribed activities for validation and verification testing. ...An inherent component of the CSMS is cybersecurity risk management and assessment. Validation and verification testing is a key activity for measuring the effectiveness of risk management, and it is mandated by UN R155 for type approval.

Abstract Automotive cybersecurity engineers now have the challenge of delivering Risk Assessments of their products using a method that is described in the new standard for automotive cybersecurity: International Organization for Standardization/Society of Automotive Engineers (ISO/SAE) 21434. ...Abstract Automotive cybersecurity engineers now have the challenge of delivering Risk Assessments of their products using a method that is described in the new standard for automotive cybersecurity: International Organization for Standardization/Society of Automotive Engineers (ISO/SAE) 21434.

Abstract Automotive cybersecurity is steadily becoming a key factor in the worldwide adoption of connected and self-driving vehicles.

Abstract There are already a number of cybersecurity activities introduced in the development process in the automotive industry. For example, security testing of automotive components is often performed at the late stages of development.

Reviewer Acknowledgment

Abstract ICVs are expected to make the transportation safer, cleaner, and more comfortable in the near future. However, the trend of connectivity has greatly increased the attack surfaces of vehicles, which makes in-vehicle networks more vulnerable to cyberattacks which then causes serious security and safety issues. In this article, we therefore systematically analyzed cyberattacks and corresponding countermeasures for in-vehicle networks of intelligent and connected vehicles (ICVs). Firstly, we analyzed the security risk of ICVs and proposed an in-vehicle network model from a hierarchical point of view. Then, we discussed possible cyberattacks at each layer of proposed network model.

Abstract Secure boot, although known for more than 20 years, frequent attacks from hackers that show numerous ways to bypass the security mechanism, including electronic control units (ECUs) of the automotive industry. This paper investigates the major causes of security weaknesses of secure boot implementations. Based on penetration test experiences, we start from an attacker’s perspective to identify and outline common implementation weaknesses. Then, from a Tier-One perspective, we analyze challenges in the research and development process of ECUs between original equipment manufacturers (OEMs) and suppliers that amplify the probability of such weakness. The paper provides recommendations to increase the understanding of implementing secure boot securely on both sides and derives a set of reference requirements as a starting point for secure boot ECU requirements.

Abstract Connecting vehicles to various network services increases the risk of in-vehicle cyberattacks. For automotive industries, the supply chain for assembling a vehicle consists of many different organizations such as component suppliers, system suppliers, and car manufacturers (CMs). Moreover, once a vehicle has shipped from the factory of the CM, resellers, dealers, and owners of the vehicle may add and replace the optional authorized and third-party equipment. Such equipment may have serious security vulnerabilities that may be targeted by a malicious attacker. The key management system of a vehicle must be applicable to all use cases. We propose a novel key management system adaptable to the electronic control unit (ECU) lifecycle of a vehicle. The scope of our system is not only the vehicle product line but also the third-party vendors of automotive accessories and vehicle maintenance facilities, including resellers, dealers, and vehicle users.

Abstract Designers of automotive systems find themselves pulled in an impossible number of directions. Systems must use the most advanced security features, but at the same time run on low-cost and resource-constrained hardware. Ultimately, an engineering trade-off will eventually be made regarding how encryption and key management is used on these systems, potentially leaving them vulnerable to attack. In this paper, we detail the applicability of side-channel power analysis and fault injection on automotive electronic systems, showing how these dangerous techniques can be used to break an otherwise secure system. We build a small example network using AES-CCM to implement an encrypted, authenticated CAN protocol. We demonstrate how open-source hardware and software can easily recover the encryption keys from some of these nodes with side-channel power analysis, and we recover a full firmware image from one device with a fault-injection attack using the same tools.

Abstract The secure boot has successfully protected systems from executing untrusted software (SW), but low-power controllers lack sufficient time to check every memory cell while satisfying real-time functional safety requirements. Automotive controllers need to maintain security through multiple cycles of remote, unsupervised operation and safely reach a secure state when an anomaly is detected. To accelerate the boot time, we propose Sliced Secure Boot: build fingerprints by slicing orthogonally through memory blocks, protect each cell with a reusable fingerprint using a reproducible pattern with sufficient entropy, and randomly check one fingerprint pattern during boot. We do not claim that sampling offers equivalent protection to exhaustive checks but demonstrate that careful sampling can provide a sufficient level of detection while maintaining compatibility with both startup time and functional safety requirements.

Abstract This work introduces the concept of a dual-layer specification structure for standards that separate interoperability functions, such as backward compatibility, localization, and deployment, from those essential to reliability, security, and functionality. The latter group of features, which constitute the actual standard, make up the baseline layer for instructions, while all the elements required for interoperability are specified in a second layer, known as a Protocols, Operations, Usage, and Formats (POUF) document. We applied this technique in the development of a standard for Uptane [1], a security framework for over-the-air (OTA) software updates used in many automobiles. This standard is a good candidate for a dual-layer specification because it requires communication between entities, but does not require a specific format for this communication.

Abstract Modern vehicles integrate Internet of Things (IoT) components to bring value-added services to both drivers and passengers. These components communicate with the external world through different types of interfaces including the on-board diagnostics (OBD-II) port, a mandatory interface in all vehicles in the United States and Europe. While this transformation has driven significant advancements in efficiency and safety, it has also opened a door to a wide variety of cyberattacks, as the architectures of vehicles were never designed with external connectivity in mind, and accordingly, security has never been pivotal in the design. As standardized, the OBD-II port allows not only direct access to the internal network of the vehicle but also installing software on the Electronic Control Units (ECUs).

Abstract In the automotive domain, the overall complexity of technical components has increased enormously. Formerly isolated, purely mechanical cars are now a multitude of cyber-physical systems that are continuously interacting with other IT systems, for example, with the smartphone of their driver or the backend servers of the car manufacturer. This has huge security implications as demonstrated by several recent research papers that document attacks endangering the safety of the car. However, there is, to the best of our knowledge, no holistic overview or structured description of the complex automotive domain. Without such a big picture, distinct security research remains isolated and is lacking interconnections between the different subsystems. Hence, it is difficult to draw conclusions about the overall security of a car or to identify aspects that have not been sufficiently covered by security analyses.

Abstract In the automotive domain, the evolution of electrical and electronic (E/E) architecture trend is toward consolidating multiple heterogeneous applications executing on individual devices onto a centralized powerful computing platform. Many forums debate the nature of this centralized computing platform. At least for another decade, automotive powertrain functions will continue their development on a multicore controller platform (MCU) instead of many core processors. Data security and the need to meet Automotive Safety Integrity Level D (ASIL-D)-compliant powertrain functions are some of the reasons for this preference. For the centralized computing platform, virtualizing the underlying MCU will facilitate the simultaneous execution of heterogeneous powertrain applications with guaranteed spatial and temporal isolation. A common problem in virtualizing the MCU is the sharing of peripherals, which are comparatively scarce.

Abstract Threat identification and security analysis have become mandatory steps in the engineering design process of high-assurance systems, where successful cyberattacks can lead to hazardous property damage or loss of lives. This article describes a novel approach to perform security analysis on embedded systems modeled at the architectural level. The tool, called Security Threat Evaluation and Mitigation (STEM), associates threats from the Common Attack Pattern Enumeration and Classification (CAPEC) library with components and connections and suggests potential defense patterns from the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 security standard. This article also provides an illustrative example based on a drone package delivery system modeled in AADL.

Abstract Identity-Anonymized CAN (IA-CAN) protocol is a secure CAN protocol, which provides the sender authentication by inserting a secret sequence of anonymous IDs (A-IDs) shared among the communication nodes. To prevent malicious attacks from the IA-CAN protocol, a secure and robust system error recovery mechanism is required. This article presents a central management method of IA-CAN, named the IA-CAN with a global A-ID, where a gateway plays a central role in the session initiation and system error recovery. Each ECU self-diagnoses the system errors, and (if an error happens) it automatically resynchronizes its A-ID generation by acquiring the recovery information from the gateway. We prototype both a hardware version of an IA-CAN controller and a system for the IA-CAN with a global A-ID using the controller to verify our concept.

Abstract Automotive software is increasingly complex and critical to safe vehicle operation, and related embedded systems must remain up to date to ensure long-term system performance. Update mechanisms and data modification tools introduce opportunities for malicious actors to compromise these cyber-physical systems, and for trusted actors to mistakenly install incompatible software versions. A distributed and stratified “black box” audit trail for automotive software and data provenance is proposed to assure users, service providers, and original equipment manufacturers (OEMs) of vehicular software integrity and reliability. The proposed black box architecture is both layered and diffuse, employing distributed hash tables (DHT), a parity system and a public blockchain to provide high resilience, assurance, scalability, and efficiency for automotive and other high-assurance systems.

Abstract The importance of in-vehicle network security has increased with an increase in automated and connected vehicles. Hence, many attacks and countermeasures have been proposed to secure the controller area network (CAN), which is an existent in-vehicle network protocol. At the same time, new protocols-such as FlexRay and Ethernet-which are faster and more reliable than CAN have also been proposed. European OEMs have adopted FlexRay as a control network that can perform the fundamental functions of a vehicle. However, there are few studies regarding FlexRay security. In particular, studies on attacks against FlexRay are limited to theoretical studies or simulation-based experiments. Hence, the vulnerability of FlexRay is unclear. Understanding this vulnerability is necessary for the application of countermeasures and improving the security of future vehicles. In this article, we highlight the vulnerability of FlexRay found in the experiments conducted on a real FlexRay network.