Search Results

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.

This paper gives a definition of the SDV concept, provides views from different aspects, discusses the progress in vehicle E/E architecture, especially zone-based architecture with centralized computation, and various technologies including High-Performance Computing (HPC) platform, standardized vehicle software architecture, advanced onboard communication, Over-The-Air (OTA) update, and cybersecurity etc. that collectively enable the realization of SDV.

Consequently, rise of this technological trend is bringing forth safety and cybersecurity challenges in form of new threats, hazards and vulnerabilities. As per the recent UN vehicle regulation 155, several risk-based security models and assessment frameworks have been proposed to counter the growing cybersecurity issues, however, the high budgetary cost to develop the tool and train personnel along with high risk of leakage of trade secrets, hinders the automotive manufacturers from adapting these third party solutions. ...As per the recent UN vehicle regulation 155, several risk-based security models and assessment frameworks have been proposed to counter the growing cybersecurity issues, however, the high budgetary cost to develop the tool and train personnel along with high risk of leakage of trade secrets, hinders the automotive manufacturers from adapting these third party solutions.

It is essential to note that cybersecurity threats not only arise from inherent protocol defects but also consider software implementation vulnerabilities.

This method's detailed approach ensures that cybersecurity requirements can be readily implemented as a part of feature design, addressing the concerns of feature owners directly. ...This paper will discuss the merits of asset based approach to cybersecurity over attack based recognizing the inherent strengths and limitations of both methods and underscores the need for a unified approach.

The VCE Laboratory testbeds are connected with an Amazon Web Services (AWS) cloud-based Cyber-security Labs as a Service (CLaaS) system, which allows students and researchers to access the testbeds from any place that has a secure internet connection. ...VCE students are assigned predefined virtual machines to perform designated cyber-security experiments. The CLaaS system has low administrative overhead associated with experiment setup and management. ...VCE Laboratory CLaaS experiments have been developed for demonstrating man-in-the-middle cyber-security attacks from actual compromised hardware or software connected with the TestCube.

Since the early 1990’s, commercial vehicles have suffered from repeated vulnerability exploitations that resulted in a need for improved automotive cybersecurity. This paper outlines the strategies and challenges of implementing an automotive Zero Trust Architecture (ZTA) to secure intra-vehicle networks. ...This research successfully met the four requirements and demonstrated that using ZT principles in an on-vehicle network greatly improved the cybersecurity posture with manageable impact to system performance and deployment.

Advanced Autonomous Vehicles (AV) for SAE Level 3 and Level 4 functions will lead to a new understanding of the operation phase in the overall product lifecycle. Regulations such as the EU Implementing Act and the German L4 Act (AFGBV) request a continuous field surveillance, the handling of critical E/E faults and software updates during operation. This is required to enhance the Operational Design Domain (ODD) during operation, offering Functions on Demand (FoD), by increasing software features within these autonomous vehicle systems over the entire digital product lifecycle, and to avoid and reduce downtime by a malfunction of the Autonomous Driving (AD) software stack.

This exercise confirms the necessity of a more restrictive cybersecurity posture in automotive peripherals with access to critical systems, in particular VDAs, and especially when such peripherals present a wireless interface.

Classic vehicle production had limitations in bringing the driving commands to the actuators for vehicle motion (engine, steering and braking). Steering columns, hydraulic tubes or steel cables needed to be placed between the driver and actuator. Change began with the introduction of e-gas systems. Mechanical cables were replaced by thin, electric signal wires. The technical solutions and legal standardizations for addressing the steering and braking systems, were not defined at this time. Today, OEMs are starting E/E-Architecture transformations for manifold reasons and now have the chance to remove the long hydraulic tubes for braking and the solid metal columns used for steering. X-by-wire is the way forward and allows for higher Autonomous Driving (AD) levels for automated driving vehicles. This offers new opportunities to design the vehicle in-cabin space. This paper will start with the introduction of x-by-wire technologies.

There continues to be massive advancements in modern connected vehicles and with these advancements, connectivity continues to rapidly become more integral to the way these vehicles are designed and operated. Vehicle connectivity was originally introduced for the purpose of providing software updates to the vehicle’s main system software, and we have seen the adoption of Over The Air updates (OTA) become mainstream with most OEMs. The exploitation of this connectivity is far more reaching than just basic software updates. In the latest vehicles it is possible to update software not just on the main vehicle systems, but to potentially update embedded software in all smart ECUs within the vehicle. Only using the connectivity to push data to the vehicle is not making full use of the potential of this increased connectivity. Being able to collect vehicle data for offline analysis and processing also brings huge benefits to the use of this technology.

Cybersecurity (CS) is crucial and significantly important in every product that is connected to the network/internet. ...Hence making it very important to guarantee that every single connected device shall have cybersecurity measures implemented to ensure the safety of the entire system. Looking into the forecasted worldwide growth in the electric vehicles (EV’s) segment, CS researchers have recently identified several vulnerabilities that exist in EV’s, electric vehicle supply equipment (EVSE) devices, communications to EVs, and upstream services, such as EVSE vendor cloud services, third party systems, and grid operators. ...Additional processes have been defined in the process reference and assessment model for the CS engineering in order to incorporate the cybersecurity related processes in the ASPICE scope. This paper aims at providing a model & brief overview to establish a correlation between the ASPICE, ISO/SAE 21434 and the ISO 26262 functional safety (FS) standards for development of a secured cybersecurity software with all the considerations that an organization can undertake.

Automotive electronics and enterprise IT are converging and thus open the doors for advanced hacking. With their immediate safety impact, cyberattacks on such systems will endanger passengers. Today, there are various methods of security verification and validation in the automotive industry. However, we realize that vulnerability detection is incomplete and inefficient with classic security testing. In this article, we show how an enhanced Grey-Box Penetration Test (GBPT) needs less test cases while being more effective in terms of coverage and indicating less false positives.

To build secure systems of road vehicles, the cybersecurity engineering standard ISO21434[11] suggests the evaluation of vulnerabilities throughout engineering process, such as attack path analysis, system requirement stage, software architecture, design, and implementation and testing phases. ...With my analysis and practices, it is appropriate to include the common vulnerabilities that ought to be an integral part of the automotive cybersecurity engineering process. In this paper, the author would like to provide a list of vulnerabilities that might be a suggestion for threat analysis and risk assessment and propose two solutions that may be adopted directly in the V-model for security-relevant software development.

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.

In agriculture industry, increasing use of Vehicle Internet of Things (IoT), telematics and emerging technologies are resulting in smarter machines with connected solutions. Inter and Intra Communication with vehicle to vehicle and inside vehicle - Electronic Control Unit (ECU) to ECU or ECU (Electronic Control Unit) to sensor, requirement for flow of data increased in-turn resulting in increased need for secure communication. In this paper, we focus on functional verification and validation of secure Controller Area Network (CAN) for intra vehicular communication to establish confidentiality, integrity, authenticity, and freshness of data, supporting safety, advanced automation, protection of sensitive data and IP (Intellectual Property) protection. Network security algorithms and software security processes are the layers supporting to achieve our cause.

In conjunction with an increasing number of related laws and regulations (such as UNECE R155 and ISO 21434), these drive security requirements in different domains and areas. 2 In this paper we examine the upcoming trends in EE architectures and investigate the underlying cyber-security threats and corresponding security requirements that lead to potential requirements for “Automotive Embedded Hardware Trust Anchors” (AEHTA).

As well, functional safety and cybersecurity constraints will increase. Electrification implies replacing energy from thermal sources with electricity from the wall and will include enhanced integration between sub-systems and components, along with higher speed in real time controls.

In order to enhance customer experience [5] and to reduce time to market, the manufacturers are constantly in need of being able to update software/firmware of the Electronic Control units (ECU) when the vehicle is in field operations. The updates could be a bug fix or a new feature release. Until the recent years, the updation of software/firmware used to be done using a physical hardwired connection to the Vehicle in a workshop. However, with the element of connectivity being added to the vehicle, the updation of software can be done remotely and wirelessly over the air using a feature called Flash over the air (FOTA) [2] and Software over the air (SOTA) [2]. In order to safeguard the telematics [3] ECU from tampering or hacking, the manufacturers are doing away with the ports on the underlying hardware through which manual flashing used to be done. This means that, the only option available to flash or update the ECU is using FOTA/SOTA.

Modern automobiles collect around 25 gigabytes of data per hour and autonomous vehicles are expected to generate more than 100 times that number. In comparison, the Apollo Guidance Computer assisting in the moon launches had only a 32-kilobtye hard disk. Without question, the breadth of in-vehicle data has opened new possibilities and challenges. The potential for accessing this data has led many entrepreneurs to claim that data is more valuable than even the vehicle itself. These intrepid data-miners seek to explore business opportunities in predictive maintenance, pay-as-you-drive features, and infrastructure services. Yet, the use of data comes with inherent challenges: accessibility, ownership, security, and privacy. Unsettled Legal Issues Facing Data in Autonomous, Connected, Electric, and Shared Vehicles examines some of the pressing questions on the minds of both industry and consumers. Who owns the data and how can it be used?