Search Results

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.

With the development of vehicle intelligence and the Internet of Vehicles, how to protect the safety of the vehicle network system has become a focus issue that needs to be solved urgently. The Controller Area Network (CAN) bus is currently a very widely used vehicle-mounted bus, and its security largely determines the degree of vehicle-mounted information security. The CAN bus lacks adequate protection mechanisms and is vulnerable to external attacks such as replay attacks, modifying attacks, and so on. On the basis of the existing work, this paper proposes an authentication method that combines Hash-based Message Authentication Code (HMAC)-SHA256 and Tiny Encryption Algorithm (TEA) algorithms. This method is based on dynamic identity authentication in challenge/response made and combined with the characteristics of the CAN bus itself as it achieves the identity authentication between the gateway and multiple electronic control units (ECUs).

Abstract The innovations of vehicle connectivity have been increasing dramatically to enhance the safety and user experience of driving, while the rising numbers of interfaces to the external world also bring security threats to vehicles. Many security countermeasures have been proposed and discussed to protect the systems and services against attacks. To provide an overview of the current states in this research field, we conducted a systematic mapping study (SMS) on the topic area “security countermeasures of in-vehicle communication systems.” A total of 279 papers are identified based on the defined study identification strategy and criteria. We discussed four research questions (RQs) related to the security countermeasures, validation methods, publication patterns, and research trends and gaps based on the extracted and classified data. Finally, we evaluated the validity threats and the whole mapping process.

But unfortunately, automotive cybersecurity researchers hardly produce a comprehensive detection method due to the confidential nature of Controller Area Network (CAN) DBC format files, which is a standard long maintained by car manufacturers.

Abstract The automotive industry intends to create new services that involve sharing vehicle control information via a wide area network. In modern vehicles, an in-vehicle network shares information between more than 70 electronic control units (ECUs) inside a vehicle while it is driven. However, such a complicated system configuration can result in security vulnerabilities. The possibility of cyber-attacks on vehicles via external services has been demonstrated in many research projects. As advances in vehicle systems (e.g., autonomous drive) progress, the number of vulnerabilities to be exploited by cyber-attacks will also increase. Therefore, future vehicles need security measures to detect unknown cyber-attacks. We propose anomaly-based intrusion detection to detect unknown cyber-attacks for the Control Area Network (CAN) protocol, which is popular as a communication protocol for in-vehicle networks.

In adjusting the data flow, this is an option to increase the cybersecurity for a complete system. This addition to the cybersecurity system provides a clear benefit. ...While this is the traditional application experienced, there are other applications relevant to cybersecurity. As part of the blockchain technology, the nodes are responsible for decision-making.

Abstract Over the past forty years, the Electronic Control Unit (ECU) technology has grown in both sophistication and volume in the automotive sector, and modern vehicles may comprise hundreds of ECUs. ECUs typically communicate via a bus-based network architecture to collectively support a broad range of safety-critical capabilities, such as obstacle avoidance, lane management, and adaptive cruise control. However, this technology evolution has also brought about risks: if ECU firmware is compromised, then vehicle safety may be compromised. Recent experiments and demonstrations have shown that ECU firmware is not only poorly protected but also that compromised firmware may pose safety risks to occupants and bystanders.

This paper is the second in the series of documents designed to record the progress of a series of SAE documents - SAE J2836™, J2847, J2931, & J2953 - within the Plug-In Electric Vehicle (PEV) Communication Task Force. This follows the initial paper number 2010-01-0837, and continues with the test and modeling of the various PLC types for utility programs described in J2836/1™ & J2847/1. This also extends the communication to an off-board charger, described in J2836/2™ & J2847/2 and includes reverse energy flow described in J2836/3™ and J2847/3. The initial versions of J2836/1™ and J2847/1 were published early 2010. J2847/1 has now been re-opened to include updates from comments from the National Institute of Standards Technology (NIST) Smart Grid Interoperability Panel (SGIP), Smart Grid Architectural Committee (SGAC) and Cyber Security Working Group committee (SCWG).

This recommended practice provides guidance on vehicle Cybersecurity and was created based off of, and expanded on from, existing practices which are being implemented or reported in industry, government and conference papers. ...Other proprietary Cybersecurity development processes and standards may have been established to support a specific manufacturer’s development processes, and may not be comprehensively represented in this document, however, information contained in this document may help refine existing in-house processes, methods, etc. ...This recommended practice establishes a set of high-level guiding principles for Cybersecurity as it relates to cyber-physical vehicle systems. This includes: Defining a complete lifecycle process framework that can be tailored and utilized within each organization’s development processes to incorporate Cybersecurity into cyber-physical vehicle systems from concept phase through production, operation, service, and decommissioning.

This recommended practice provides guidance on vehicle Cybersecurity and was created based off of, and expanded on from, existing practices which are being implemented or reported in industry, government and conference papers. ...Other proprietary Cybersecurity development processes and standards may have been established to support a specific manufacturer’s development processes, and may not be comprehensively represented in this document, however, information contained in this document may help refine existing in-house processes, methods, etc. ...This recommended practice establishes a set of high-level guiding principles for Cybersecurity as it relates to cyber-physical vehicle systems. This includes: Defining a complete lifecycle process framework that can be tailored and utilized within each organization’s development processes to incorporate Cybersecurity into cyber-physical vehicle systems from concept phase through production, operation, service, and decommissioning.

UNECE R155 explicitly references ISO/SAE 21434 and mandates a certified cybersecurity management system (CSMS) as a prerequisite for automotive manufacturers to achieve vehicle type approval and sell new vehicle types. ...However, the gap in the CSMS framework is a lack in a standardized system that provides guidance and common criteria for automakers to measure a vehicle’s level of compliance and compute a publicly accepted cybersecurity rating. To help establish increased consumer confidence, OEMs and smart mobility stakeholders could take additional proactive steps to ensure the safety and security of their products. ...This paper addresses the above requirement and discusses the cybersecurity rating framework (CSRF) that could establish a framework for rating vehicle cybersecurity by standardizing the measurement criteria, parameter vectors, process, and tools.

The lack of inherent security controls makes traditional Controller Area Network (CAN) buses vulnerable to Machine-In-The-Middle (MitM) cybersecurity attacks. Conventional vehicular MitM attacks involve tampering with the hardware to directly manipulate CAN bus traffic.

The basic requirements of AS9100A apply with the following clarifications. This document supplements the requirements of AS9100A for deliverable software. This supplement contains Quality System requirements for suppliers of products that contain deliverable embedded or loadable airborne, spaceborne or ground support software components that are part of an aircraft Type Design, weapon system, missile or spacecraft operational software and/or support software that is used in the development and maintenance of deliverable software. This includes the host operating system software including assemblers, compilers, linkers, loaders, editors, code generators, analyzers, ground simulators and trainers, flight test data reduction, etc., that directly support creation, test and maintenance of the deliverable software.

OBD, J1939 and UDS on CAN / IP), and a glimpse into the near future covering remote, cloud-based diagnostics and cybersecurity threats.

This document describes some of the actions that should be taken to help ensure safe vehicle operation in the case that any such connected device (external test equipment, connected data collection device) has been compromised by a source external to the vehicle. In particular, this document describes those actions specifically related to SAE J1979, ISO 15765, and ISO 14229 standardized diagnostic services. Generally, the following forms of communication bus connection topologies are used in current vehicles: a Open access to communication buses b Communication buses isolated via a gateway c Hybrid combinations of a. and b.

This document describes a set of recommended actions to take to increase the likelihood of safe vehicle operation when a device (external test equipment, data collection device, etc.) whose normal operation has been compromised by a source external to the vehicle is connected to the vehicle’s diagnostic system. The term “diagnostic system” is intended to be a generic way to reference all the different ways that diagnostic commands might be injected into the system. The guidance in this document is intended to improve security without significantly impacting the ability for franchised dealer or independent aftermarket external test tools to perform legitimate diagnosis and maintenance functions. The goal is that intrusive services are only allowed to be performed when the vehicle is in a Safe State such that even if the intrusive service were to be initiated with adversarial intent the consequences of such a service would still be acceptable.

This SAE Recommended Practice establishes a uniform practice for protecting vehicle components from "unauthorized" access through a vehicle data link connector (DLC). The document defines a security system for motor vehicle and tool manufacturers. It will provide flexibility to tailor systems to the security needs of the vehicle manufacturer. The vehicle modules addressed are those that are capable of having solid state memory contents accessed or altered through the data link connector. Improper memory content alteration could potentially damage the electronics or other vehicle modules; risk the vehicle compliance to government legislated requirements; or risk the vehicle manufacturer's security interests. This document does not imply that other security measures are not required nor possible.

This SAE Recommended Practice establishes a uniform practice for protecting vehicle components from "unauthorized" access through a vehicle data link connector (DLC). The document defines a security system for motor vehicle and tool manufacturers. It will provide flexibility to tailor systems to the security needs of the vehicle manufacturer. The vehicle modules addressed are those that are capable of having solid state memory contents accessed or altered through the data link connector. Improper memory content alteration could potentially damage the electronics or other vehicle modules; risk the vehicle compliance to government legislated requirements; or risk the vehicle manufacturer's security interests. This document does not imply that other security measures are not required nor possible.

This SAE Recommended Practice establishes a uniform practice for protecting vehicle components from "unauthorized" access through a vehicle data link connector (DLC). The document defines a security system for motor vehicle and tool manufacturers. It will provide flexibility to tailor systems to the security needs of the vehicle manufacturer. The vehicle modules addressed are those that are capable of having solid state memory contents accessed or altered through the data link connector. Improper memory content alteration could potentially damage the electronics or other vehicle modules; risk the vehicle compliance to government legislated requirements; or risk the vehicle manufacturer's security interests. This document does not imply that other security measures are not required nor possible.

Android applications have historically faced vulnerabilities to man-in-the-middle attacks due to insecure custom SSL/TLS certificate validation implementations. In response, Google introduced the Network Security Configuration (NSC) as a configuration-based solution to improve the security of certificate validation practices. NSC was initially developed to enhance the security of Android applications by providing developers with a framework to customize network security settings. However, recent studies have shown that it is often not being leveraged appropriately to enhance security. Motivated by the surge in vehicular connectivity and the corresponding impact on user security and data privacy, our research pivots to the domain of mobile applications for vehicles. As vehicles increasingly become repositories of personal data and integral nodes in the Internet of Things (IoT) ecosystem, ensuring their security moves beyond traditional issues to one of public safety and trust.