A Survey of Critical Cybersecurity Risks in Electric Vehicle Mobile Applications: Vulnerabilities, Permissions, and Mitigation Strategies

1. Introduction

EVs are gaining traction as an eco-friendly and economical substitute for traditional cars that run on gasoline. Unlike conventional cars that rely on internal combustion engines burning fossil fuels, EVs utilize one or more electric motors for propulsion [1]. Depending on the electricity source and storage, EVs can be classified into various types such as battery electric vehicles (BEV), plug-in hybrid electric vehicles (PHEV), and fuel cell electric vehicles (FCEVs) [2]. Compared to their conventional counterparts, EVs offer numerous advantages. They help reduce greenhouse gas emissions, improve air quality, bolster energy security, and create new economic opportunities [3].

The International Energy Agency projects that by 2030, 125 million EVs will be on the road, accounting for nearly a third of all passenger vehicles [4]. Many factors are driving its growth, including rising fuel costs, rising concerns about climate change, and government incentives to adopt electric vehicle EVs to deliver economic benefits in addition to environmental benefits. Because EVs require less fuel and maintenance than gasoline-powered vehicles, they are generally cheaper to maintain. In addition, many countries around the world offer them various subsidies and incentives, such as tax credits and tax exemptions [5]. For example, in the United States, EV buyers can claim a federal tax credit of up to $7,500 depending [6]. In China, the world’s largest EV market, EV buyers can receive a 10% reduction in consumption tax and a subsidy of up to 18,000 yuan [7].

The rapid growth of EVs has led to a parallel increase in the demand for mobile applications that facilitate the management and monitoring of these vehicles. Most EVs are equipped with a proprietary mobile application provided by the manufacturer, explicitly designed to control and monitor certain types of EVs. These applications enable users to efficiently manage and monitor their EV usage [8]. These mobile applications offer a plethora of conveniences to the user. They provide real-time tracking of charging status, battery levels, and travel range. They also send notifications upon charging completion and facilitate payment at public charging stations. Some manufacturers even allow users to remotely control certain vehicle functions such as door locks, climate control systems, headlights, maintenance schedules, and charging station payment [9].

Apart from the applications offered by EV manufacturers, there are many applications developed and uploaded by third-party developers [10]. Although, these applications help consumers, but they also provide developers and manufacturers with useful information on everyday activities, driving patterns, vehicle use, and user behavior [11]. Therefore, the security and integrity of these applications play a crucial role, considering that the data they manage is sensitive. The data collected by these applications can be used for advertising, insurance, and product development. Most applications collect data—which includes car performance metrics, location, infotainment system data, sensor data, driving patterns, personal information, financial details, and user activities [12]. Figure ?? provides an overview of real-time functionality and important EV application features that are common in most EV applications. It illustrates the key significance and dependency of mobile applications for EV owners and drivers. The image represents that applications can be used for vehicle tracking, remote unlock, and charging updates among others [13].

To address these cybersecurity challenges and defend against vulnerabilities in mobile application security, we provide a comprehensive cybersecurity assessment of EV mobile applications. We chose these applications from the application distribution platforms and divided them into two groups based on the developers: (1) Applications developed by EV manufacturers and (2) Applications developed by independent third-party developers. We then developed a comprehensive methodology to analyze these applications which allowed us to perform permission analysis, common weakness enumeration (CWE) [14], and the most critical security vulnerabilities based on the open web-application-security-project (OWASP) security standards [15]. After the identification of vulnerabilities, defensive measures are proposed to enhance the security of these applications. The novelty of our work lies in the comprehensive nature of assessment, identifying the features that attract users to install third-party applications, and proposing solutions to improve the security.

• The paper presents a thorough security assessment of EV Android applications. This includes both static and dynamic analysis phases, knowledge building, and a security assessment phase, providing a detailed understanding of the cybersecurity landscape in these applications.
• The research identifies major security flaws such as poor authentication, broken encryption, insecure communication, and more. It also pinpoints the OWASP top ten vulnerabilities and analyzes for CWE, contributing valuable insights to the field of cybersecurity in EV applications.
• The paper conducts a detailed analysis of the requested permissions in these applications. It also identifies functionalities that are not present in official EV applications, leading users to rely on third-party applications, thereby increasing their attack surface.
• Finally, the research proposes defensive measures based on OWASP and CWE defenses to mitigate the identified security issues to enhance the security of EV Android applications.

1.1. Paper Organization

The remainder of this paper is organized as follows: Section 2 reviews the literature on EVs and identifies research gaps. Section 3 selects applications for security assessment and compares the functionalities and features of the applications. Section 4 describes the methodology and procedure of the assessment. Section 5 presents the results and findings of the analysis. Section 6 provides valuable insights on results. Section 7 suggests defensive measures to improve the security of applications. Section 8 concludes the article and discusses future work.

2. Literature Review

The increasing popularity and mass production of EVs raise challenges related to cybersecurity concerns. There are five components of EV security profiling: charging station security, information privacy, software security, connected vehicle security, and autonomous driving security [16]. Most vehicles now come with mobile applications that use cloud and fog computing paradigms. These applications communicate with trusted cloud servers through intermediary node servers and possess multiple data entry and exit points where security is needed [17].

Additionally, the growth of electric vehicle adoption has led to increased demand for electric vehicle supply equipment (EVSE) infrastructure and mobile applications. This has also exposed vulnerabilities in EVSE systems, including weak authentication mechanisms and end-to-end communications [18].

EV mobile applications are among customer-valued areas that may encourage adoption, with security having a significant impact on this [19]. The landscape of mobile applications available to EV drivers is highly fragmented and lacks uniformity and standards and cybersecurity measures [20].

EV applications can misuse sensitive data if they have security flaws, such as over-claimed permissions, obsolete API calls, vulnerabilities, and weaknesses [21]. Among all the mobile applications connected with Android Auto infotainment systems, nearly 80% of the applications are potentially vulnerable, with 25% posing security threats related to the execution of JavaScript [22]. There are security concerns associated with connecting Android devices to car infotainment systems, which can be exploited to read sensitive data and send dangerous commands to the car’s hardware [23].

Popular EV applications from manufacturers and third-party developers exhibit security vulnerabilities, potentially compromising sensitive information such as vehicle location, statistics, and personally identifiable information (PII) stored in mobile devices [24]. There is a possibility of remote attacks on mobile applications used for locating EV charging points [25]. There is also the possibility of hacking through existing vulnerabilities in various mobile EV applications application authentication and insecure communication. Moreover, there are cyber threats to EVs, third-party libraries, and implemented sensors [26]. There are many other security vulnerabilities that exist in Android vehicle-related applications. As, these applications use network security configuration (NSC) in enhancing security practices, which if not effectively utilized, can create security vulnerabilities [27].

There is a need for security assessment of EV mobile applications, as they collect data from EV sensors, such as LiDAR, radar, and cameras, to enhance 3D object detection and visualization, having vulnerability in these applications can put users on risk [28]. Also, it is equally important to ensure secure vehicle-to-everything (V2X) communications in connected car mobile applications. [11]. Safeguards and defensive controls are needed to address the security vulnerabilities in EV applications, particularly focusing on encryption for data transmission and secure data storage to prevent potential security incidents.

Moreover, vehicular technology is also evolving to attain emerging technologies and blockchain-based self-certified key exchange protocols, which proposes a highly secure self-certified key exchange protocol that if used in mobile applications, can provide enhanced security, authenticity and privacy [29].

The existing literature has identified some of the cybersecurity risks and threats that affect EV mobile applications. However, some identified limitations may include a lack of systematic studies that analyze the security of a wide range of EV mobile applications using various tools and techniques. Also, there is a lack of comparative analysis of the functionality of EV mobile applications which becomes the reason to influence the users into installing these applications. Therefore, this article aims to provide a detailed cybersecurity assessment of popular EV mobile applications, identify the features that attract users to install third-party applications, and propose defenses to mitigate the vulnerabilities, and build resilience.

3. Application Selection and Functionality Influence

This section describes the selection criteria and functionality of the applications that we used for the underlined article. First, applications were downloaded from the Google Play Store. There are a total of twenty applications which are divided into two groups, Group:1 represents EV manufacturers-developed applications, and Group:2 shows third-party developers applications.

3.1. Group:1 - EV Manufacturers Applications

• TESLA: this user-friendly application is designed for managing Tesla vehicles. It offers features like tracking your vehicle, starting or stopping charging remotely, and even locking and unlocking your car. Additionally, it helps users locate charging stations, schedule service appointments, and download the latest updates.
• Mercedes: this application locks or unlocks the doors, remote starts, tracks the vehicle, records driving habits, and schedules service appointments.
• BMW: it performs vehicle tracking, allows remote starts, schedules service appointments, and allows maintenance updates.
• Nissan: this application is all about convenience for Nissan vehicle owners. It enables users to locate and track their vehicles and even offers keyless entry and remote start capabilities. It’s compatible with Alexa-enabled devices and Google Assistant, allowing users to use voice commands to start the car, turn on the lights, and interact with their vehicle in various other ways.
• Volkswagen: the application provides remote access, reserves parking spots, schedules service appointments, and downloads updates.
• Jaguar InControl: it can schedule maintenance and service appointments, remotely activate the vehicle’s horn and lights, access trip history and driving statistics, and remotely start.
• FordPass: it provides details on ingress fuel levels, allows lock/unlock of Ford vehicles, checks vehicle health information, finds parking spots, and uses platform assistance.
• MITSUBISHI: enables users to remotely control climate settings, manage anti-theft functions, monitor current travel information, and manage chargings.
• Land Rover InControl: allows users to remotely unlock doors, start the engine, update climate settings, use the vehicle locator, and receive maintenance alerts.
• MY FERRARI: allows users to oversee and manage Ferrari vehicles from a distance, review details of the vehicle, access vehicle location tracking, and start or stop the engine, and manage vehicular updates.

3.2. Group:2 - Third-Party Applications

• EVConnect: this app is a handy tool for EV drivers. It helps users find EV charging stations, pay for charging services, and send notifications when the charging is complete.
• EVgo: allows users to check charging information, locate charging stations, and book a charger. This application also supports loyalty programs and coupons.
• Plugshare: this app helps users find charging stations, pay for services, and monitor the charging process. It allows users to share their experiences, stories, and photos, and rate their overall experience.
• ChargeHub: this app is a helpful assistant for electric vehicle owners. It helps users find, compare, and navigate to charging stations. It provides updates on the availability of stations, making it easier for users to plan their charging.
• EV-Energy: this app is designed to help EV owners manage their home charging needs. It includes features like setting reminders, tracking charging time, and monitoring energy use, making home charging an ease for EV owners.
• A better route planner (ABRP): offers trip planning tools for, taking into account weather updates, traffic situations, and charging station amenities.
• Caura: it allows users to track car-related expenses, track charging costs, update reminders, and track vehicles.
• Bp Plus: this application is designed for businesses that manage fleets and provide battery-saving insights, find nearby charging stations, and give driving habits.
• Optiwatt: allows EV owners to optimize their charging schedule based on energy costs and grid demand. The application also provides analytics and reports on charging behavior and energy consumption.
• Octopus electroverse: gives users access to electric vehicle charging stations and uses smart charging features to take advantage of off-peak electricity pricing.

3.3. Comparative Analysis of Functionalities Offered by EV Applications

Application functionality is an important factor that influences users to retain a specific application. The functionalities present in chosen applications are classified into 12 groups, denoted by F1 to F12, where F represents functionality. This notation is consistent with the previous scheme of using a letter and a number to represent the applications and optimize the table structures in subsequent sections.

F1.

Charging points- These features allow users to search nearby charging point locations.

F2.

Vehicle controls- This allows monitor and control different functions of vehicles.

F3.

Calls and messages- This helps in making and receiving calls and messages in mobile applications.

F4.

Media controls- This controls media, audio, and other entertainment options.

F5.

Remote unlock- As name suggests, it unlocks a car remotely.

F6.

Charging status- This feature provide charging update of a vehicles.

F7.

Vehicle tracking- This will track the location of vehicles using the GPS coordinates.

F8.

Car health report- This returns a report on the health and performance of the underlined vehicle.

F9.

Payments- This features let a customer pay for various services, like charging.

F10.

Amenities- The function helps a user to find hotels and other services.

F11.

Energy use tracking- It tracks and analyzes the energy used by a vehicle.

F12.

Rewards and coupons- As the name suggests, it is linked to receiving and redeeming rewards and coupons as users use certain services.

Table 1 provides a detailed comparative analysis of the functionalities offered by different EV applications. The first column categorizes the applications into two groups: Group:1 (applications developed by EV manufacturers) and Group:2 (applications developed by third-party developers). This categorization is crucial as it allows us to compare the security features and vulnerabilities between manufacturer-developed and third-party applications, which could have different development practices and security standards.

The second column lists the names of the applications, and the remaining columns detail the functionalities present in each application. This information is significant as it helps us understand the scope of each application and the potential security implications associated with each functionality.

The last column lists the total number of functions available in each application. This is an important metric as it gives us an idea of the complexity of the application. Generally, more functionalities could mean a larger attack surface and potentially more vulnerabilities.

The visual analysis of available functions is represented in Figure ??. The figure shows the count of functionality for each selected application, as well as the corresponding feature categories denoted by F1 to F12. For example, if we look at the leftmost bar, we can see that the Tesla application offers five functionalities, which are F2 (Vehicle controls), F4 (Media controls), F5 (Remote unlock), F6 (Charging status) and F7 (Vehicle tracking). The figure helps to visualize and compare the functionalities and features of the applications.

On the other hand, Figure ?? shows the widely available functionality that is present in most applications. This gives insight into the importance of the most necessary functionality for drivers, that must be considered while building new applications. For example, we can see from the graph that the three most common features that are available in almost every application are F5 (Remote unlock), F6 (Charging status), and F7 (vehicle tracking). This can be used as a fair minimum standard for new applications to survive the market dynamics and fulfill basic user needs.

4. Security Accessment Methodology

This section describes the methodology which consists of four phases: 1) the static analysis phase, 2) the dynamic analysis phase, 3) the knowledge-building phase, and 4) the security assessment phase. Figure ?? provides a broad outline of each phase.

To provide a comprehensive understanding of our methodology, it is important to describe the specific timeframe within which each phase of our cybersecurity assessment was conducted. The static analysis phase started immediately after selecting suitable applications and spanned over a period of two weeks. During this time, applications were decompiled and thoroughly examined for potential security vulnerabilities. Following this, the dynamic analysis phase was initiated, which involved running applications in a controlled virtual environment to monitor real-time operations; this phase lasted three weeks due to its complexity and depth of analysis required.

Subsequently, we allocated one week for the knowledge-building phase where data from both static and dynamic analyses were synthesized using advanced Python visualization tools to create an insightful knowledge base. Finally, in the security assessment phase which took another two weeks, we leveraged our comprehensive knowledge base to evaluate all identified security vulnerabilities critically. In total, our methodology was executed over an eight-week period ensuring meticulous attention to detail at every stage. This systematic approach allowed us to conduct an in-depth and comprehensive security assessment of each application. The details of these phases are discussed in the subsequent sections.

4.1. Static Analysis Phase

In this phase, we performed a static analysis of the selected applications. We started by decompiling the applications using Apktool [50], which allowed us to extract their resources and retrieve valuable information. After the decompilation, we extracted the Android manifest file, opened it with the text editor, and manually extracted different permissions used by applications. This gave us insights into the level of access each application requires. We identified third-party libraries used in the applications by examining the decompiled code. This helped us understand the external dependencies of the applications.

We extracted strings and XML files from the decompiled code using xmlstarlet [51], a toolkit to identify hard-coded secrets, URLs, and other potential security risks. Finally, we examined the AndroidManifest.xml file of each application to understand its configuration, including its components (activities, services, receivers, and intents) and their respective permissions. Activities, Services, Receivers, and Intents: We analyzed the inter-component communication in the applications by examining their manifest files and decompiled code. This helped us identify potential vulnerabilities related to intent spoofing, unprotected components, and more. This comprehensive approach to static analysis allowed us to gain a deep understanding of the applications’ structure, behavior, and potential security vulnerabilities. We retrieving the following information from the applications [52]:

• Application permissions.
• Third-party libraries.
• Strings and XML files.
• Improper resource handling.
• Application configuration.
• Activities, services, receivers, and intents.
• Unused Variables and Resources.

4.2. Dynamic Analysis Phase

In the dynamic analysis phase, we utilized a combination of publically available tools and custom scripts to monitor the real-time operations of the applications. We used an Android debug bridge (ADB) for communication between the host computer and the emulator [53].

To detect malicious behaviors, dynamic code loading, privilege escalation, and data exfiltration, we used MobSF [54], a mobile security framework that provides dynamic analysis and malware detection. For detecting obfuscation, encryption, and anti-debugging techniques, we used JEB Decompiler [55]. Finally, Wireshark was used to capture network traffic, allowing us to analyze network activities, protocols, traffic flow, domains, and APIs [56]. This comprehensive toolset allowed us to perform a thorough dynamic analysis of the applications, providing valuable insights into their runtime behavior and potential security vulnerabilities. The following information was obtained from the applications [57]:

• Application interactions, inputs, outputs, and interprocess communication.
• Network activities, network protocols, traffic flow, domains, and APIs.
• System calls, file operations, processes, and socket operations.
• Resource consumption, CPU usage, memory usage, and battery usage.
• Event logs, malicious behaviors, dynamic code loading, privilege escalation, and data exfiltration.
• Obfuscation and encryption, and anti-debugging.

4.3. Knowledge Building Phase

In this phase, we analyzed the data gathered from the previous two phases and built a knowledge base that contains insights about the applications using Python visualization libraries, to perform the following tasks:

• Data cleaning and transformation: This is the process of removing or correcting inaccurate, incomplete, or irrelevant data from the data set, such as missing values, outliers, and duplicates.
• Data Integration and Visualization: It is the process of combining or merging data from different sources or formats into a unified data set and then displaying graphical representations of the data.
• Data Mining and Interpretation: This is the process of discovering and extracting useful patterns, and trends from the data.

4.4. Security Assessment Phase

In this phase, we evaluated all security vulnerabilities of every application using the knowledge base created in the previous phase and performed the following tasks [58,59,60].

• Analysis of requested permissions, their necessity, legitimacy, and risk level.
• Identification of OWASP Top Ten vulnerabilities, which serves as a standard reference for identifying critical security risks.
• Identifying the severity and impact of vulnerabilities, their likelihood of occurrence, and potential consequences.
• Analysis for CWE [14].

The underlined methodology is adopted to conduct an individual assessment of each application. The results and findings of the analysis are discussed in the subsequent sections.

5. Results and Findings

This section provides details about the results obtained from the analysis of the selected mobile applications using the methodology described in the previous section. The results are based on the data gathered from the static and dynamic analysis phases and the knowledge base created from the knowledge-building phase.

5.1. Analysis of Requested Permissions

Android operating system enforces application permissions to access device functionalities. However, some permissions are considered dangerous for both the user and the system, as they may expose sensitive information, compromise security, or affect performance. Therefore, we analyze the permissions requested by the EV application and assess their necessity, legitimacy, and level of risk [61]. The permissions are classified into 10 groups, denoted by P1 to P10. This notation is consistent with the previous scheme of using a letter and a number to represent the permissions and optimize the table structures in subsequent sections.

P1

Access precise location.

P2

Access Camera.

P3

Read and Update Contacts.

P4

Manage Calendar.

P5

Read/Write External storage.

P6

Access Call logs/records.

P7

Access Accounts and Stored Credentials.

P8

Connect Bluetooth.

P9

Access network state.

P10

Search and Connect WIFI.

Table 2 provides a comparative analysis of the permissions requested by both groups of applications. The first column categorizes the applications into two groups: Group:1 (applications developed by EV manufacturers) and Group:2 (applications developed by third-party developers). This categorization is crucial as it allows us to compare the security features and vulnerabilities between manufacturer-developed and third-party applications, which could have different development practices and security standards.

The second column lists the names of the applications, and the third column shows the specific application version that was tested. We mention the version here, as some versions may request extended permissions, which could potentially introduce additional security risks. The remaining columns detail the permissions that each application requests. This information is significant as it helps us understand the level of access each application requires to function. Excessive permissions could indicate potential privacy risks or security vulnerabilities. The last column lists the total number of permissions requested by each application. This is an important metric as it gives us an idea of the scope of access each application requires. Generally, more permissions could mean a larger attack surface and potentially more vulnerabilities.

Figure ?? provides a high-level overview of the number of requested permissions in each application. The chart visualizes the distribution of permissions and resources across the applications and compares the applications based on their permission count.

5.2. Identification of OWASP top ten vulnerabilities

OWASP is a nonprofit organization dedicated to enhancing software application security [62,63]. In this subsection, we discuss vulnerabilities that were identified in the code of analyzed applications and further managed using OWASP standards.

Identification and mapping of application vulnerabilities span over two tables. Table 3 covers Group:1 and Table 4 covers Group:2. Both tables on the left provide the first column as the vulnerability name, which is represented as V1 - V10, consistent with the previous naming scheme of word and number. Column 2 maps the vulnerabilities based on their risk level, such as HIGH, MEDIUM, and WARNING. The rest of the table shows the applications that match the vulnerabilities. Finally, the last row at the bottom shows the total number of vulnerabilities present in each application.

V1

Improper Platform Usage, root functionality, hardware manipulation, or bypassing security measures that can result in unauthorized access, privilege escalation, or device compromise.

V2

Insecure Data Storage, storing data in plain text, using weak encryption, or lacking access controls.

V3

Insecure communication, unauthenticated connections, exposing data to interception, or leaking data to third parties.

V4

Insecure authentication, default or hard-coded credentials, lagging password policies, or relying on single-factor authentication.

V5

Insufficient cryptography, using outdated or broken algorithms, using weak or predictable keys, or implementing cryptography incorrectly.

V6

Insecure Authorization, lack of role-based access control, lack of checking permissions, or excessive privileges. This may result in unauthorized access, privilege escalation, or data exposure.

V7

Quality of the client code, using insecure libraries or frameworks, having vulnerabilities or bugs in the code, or lacking code review or testing.

V8

Code Tampering, adding malicious code, removing security checks, or hiding vulnerabilities.

V9

Reverse Engineering, encryption keys, API keys, or credentials.

V10

Extraneous Functionality, backdoors, debug functions, or test functions.

In addition to the OWASP Top Ten vulnerabilities, Potential zero-day vulnerabilities could exist in these applications. Zero-day vulnerabilities are previously unknown vulnerabilities that could be exploited by attackers before they are discovered and fixed by the developers. These vulnerabilities pose a significant threat as they leave the applications exposed to potential attacks until they are identified and patched.

5.3. Analysis for CWE

CWE is a list of flaws that may result in security breaches and serves as a common language for describing these weaknesses and provides a standard for measuring and mitigating them. CWE is industry-endorsed and supported by a community of information security professionals [64]. CWE is free for public use and is maintained by the MITRE Corporation. It is closely related to common attack pattern enumeration and classification (CAPEC) and common vulnerabilities and exposures (CVE) [65].

This section analyzed the EV smartphone applications for the presence of CWE. Table 5 provides a comparative analysis of CWE vulnerabilities by both groups of applications. The table is structured as follows: The first column on the left shows the application name and the group to which it belongs. The remaining columns show the identified CWE vulnerabilities that each application has. The last column lists the total number of CWEs present in each application. The details of the identified CWE are as follows:

• CWE-250: Execution with Unnecessary Privileges.
• CWE-330: Insufficiently random values are used and vulnerable to spoofing attacks.
• CWE-276: Incorrect Default Permissions.
• CWE-532: Insertion of sensitive data into the log file, passwords, tokens, or keys, into log files by mistake.
• CWE-312: Cleartext Storage of Sensitive Information.
• CWE-89: Improper neutralization of special elements used in a SQL command (’SQL injection’).
• CWE-327: Use of a Compromised or Risky Cryptographic Algorithm.
• CWE-295: Improper Certificate Validation.
• CWE-749: Exposed to dangerous methods or functions.
• CWE-919: Improper handling of sensitive data, insecure communication, or lack of authentication.

6. Discussion

After a detailed analysis of Table 1, Figure ??, and Figure ??, we concluded that some of the functionalities that are available in most third-party applications are F1 (Charging points), F9 (Payments), F10 (Amenities), F11 (Energy use tracking) and F12 (Rewards and coupons). These feature sets are possible reasons for the users to rely on third-party applications asneed is not fulfilled by the applications provided by their EV manufacturer.

From Table 2 and Figure ??, we can identify patterns, such as The applications of Group 1 (EV manufacturers) tend to request more permissions and resources than the applications from Group 2 (third-party applications). Group:1 applications have more functionalities that require access to devices and data, this may also increase the risk of exposing sensitive information or compromising security, as Group:1 applications may request extended sensitive permissions and resources, including calling the phone and obtaining accounts. The most common permissions and resources requested by all applications are P1 (access fine location), P2 (camera), and P5 (external storage). Moreover, the least common permissions and resources requested by all applications are P3 (contacts), P4 (calendar), P6 (call phone), and P7 (get accounts). These permissions and resources may also create a high risk to the user’s privacy, security, or system stability, as they can access or modify the user’s contacts, calendar, phone, or accounts.

From Figure 1, we can identify patterns and, such as the applications of Group:1 tend to have more vulnerabilities than the applications from Group:2, it has more diverse functionalities, which may introduce more security flaws and weaknesses. Also, Group:1 applications have more severe or critical vulnerabilities, such as V1 (improper platform usage), V3 (insecure communication), or V5 (insufficient cryptography).

Figure 1b,c shows that the applications from Group:2 tend to have more MEDIUM or WARNING level vulnerabilities. However, Figure 1d shows applications from Group:1 tend to have more HIGH-level vulnerabilities than the applications from Group:2. This is because Group:1 applications have more specific or unique functionalities and features, which may be subject to more novel or sophisticated vulnerabilities.

Figure 1a The most common vulnerabilities identified for all applications are V2 (insecure data storage), V3 (insecure communication), V5 (insufficient cryptography), and V9 (reverse engineering). However, these vulnerabilities can also pose a high risk to user privacy, security, or system stability, as they may allow attackers to access, modify, or decrypt sensitive data or analyze or manipulate the code.

Figure 2 provides a high-level overview of the number of CWE vulnerabilities in each application using different colors to represent the variety of CWE. This means that we can easily compare applications based on their security weaknesses and identify the most common and severe CWE vulnerabilities among them. For example, we can see from the left that the Tesla application has CWE vulnerabilities, with 8 of 10. Also, CWE-312 (Sensitive information cleartext storage) and CWE-276 (Incorrect default permissions) are the most frequent CWE vulnerabilities in all applications.

6.1. User Impact Analysis

It is also important to understand the potential real-world consequences for users if these vulnerabilities are exploited. If a malicious actor were to exploit these vulnerabilities, users could face a range of impacts. For instance, insecure data storage and transmission could lead to unauthorized access to sensitive user data, such as location history and payment details. This could result in privacy breaches and financial loss. Similarly, poor authentication mechanisms could allow unauthorized users to gain control of the vehicle’s functions, posing significant safety risks.

6.1.1. Case Study: Insecure Data Handling in “PlugShare”

From Table 5, let’s consider the “PlugShare” app for our case study. It is a widely used third-party Android app among EV owners. It provides functionalities such as locating charging stations and sharing reviews about them. However, it has a significant vulnerability - CWE-919: Improper handling of sensitive data, insecure communication, or lack of authentication.

The app collects sensitive user data, including location history and user reviews, but does not handle this data securely. This makes it susceptible to various security threats. For example, PlugShare users, use the app to find charging stations and share reviews. The app stores location history and reviews in an insecure manner. A malicious actor, if manages to breach the app’s database and gains access to users’s data, potentially misuses this information, leading to privacy breaches.

Similarly, if someone uses public Wi-Fi networks to access the app. Due to the app’s insecure communication, a malicious actor present on the same network can perform a Man-in-the-Middle attack. The attacker can intercept the communication between a user’s device and the app’s servers, gaining access to the user’s location, history, and reviews.

In both scenarios, the users face serious privacy risks due to the insecure data handling in the PlugShare app. This case study highlights the importance of secure coding practices, including secure data handling and communication, in protecting user data. It also underscores the need for robust authentication mechanisms to prevent unauthorized access to user data. These are areas where PlugShare, and similar apps, need to improve to provide a safer user experience.

6.2. Best Practices for Developers

In addition to our detailed analysis of the vulnerabilities in third-party applications, we believe it’s key for developers to understand common security practices. While developing and publishing an application to the Google Play Store, a developer should be aware of vulnerabilities and security flaws. Our research indicates that while some developers follow best practices for secure coding, others may lack the necessary knowledge or resources to implement robust security measures. This disparity in security practices can lead to significant variations in the security posture of different third-party applications.

Common security shortcomings in third-party applications often stem from a lack of secure coding practices. For instance, developers may neglect to validate input properly, leading to vulnerabilities such as SQL injection or cross-site scripting. Insecure data storage and transmission are other common issues, often resulting from the improper use of cryptographic APIs or the absence of secure communication protocols.

To address these shortcomings, we suggest several best practices for third-party developers. First, developers should adhere to secure coding guidelines, such as those provided by OWASP or CWE. Regular code reviews and security testing can also help identify and fix potential vulnerabilities. Second, developers should implement robust authentication and authorization mechanisms to protect sensitive user data. Finally, developers should stay updated on the latest security threats and mitigation strategies, ensuring their applications can withstand new and emerging cyber threats.

By following these best practices, third-party developers can significantly enhance the security of their EV mobile applications, providing a safer and more reliable experience for users.

7. Defensive Measures

This section provides defensive measures of identified vulnerabilities and weaknesses in previous sections. It provides countermeasures that can be used to secure EV mobile applications and make them resilient against cyber attacks. There are two types of defenses presented as CWE defenses and OWASP defences, details of both are as follows:

7.1. CWE Defenses

This subsection is dedicated to providing details on possible defenses that can be used to mitigate the impact of CWEs identified in the applications. These mitigations are targeted and intended to use while developing an application, and before deployment.

• CWE-250: Execution with Unnecessary Privileges It is recommended to use the principle of least privilege to limit the privileges or permissions of the application [66]. Also, use user ID and process ID in containerization to isolate the application from the rest of the system or environment, and secure coding and security by design techniques to ensure that the application is safe.
• CWE-330: Use of Insufficiently Random Values Developers can use cryptographically secure pseudorandom number generators (CSPRNGs) to generate random values for security purposes [67]. Also, it is recommended to use long, secure random values to resist brute-force or guessing attacks.
• CWE-276: Incorrect Default Permissions It can be essential to use secure file permissions and access control mechanisms and perform input sensitization for chmod, chown, and ACLs, among others.
• CWE-532: Insertion of sensitive information into log files Developers may use different data masking or data obfuscation techniques to protect sensitive information in log files and implement secure log libraries to write log files for the application, such as using Logback, SLF4J, or CocoaLumberjack [68].
• CWE-312: Storage of sensitive information in clear text It can be important to implement encryption at rest, hashing, and masking while storing sensitive information. Additionally, do not store any information in plain text on the device. Moreover, developers can use data minimization to reduce the amount or type of sensitive information that is stored.
• CWE-89: Improper Neutralization of Special Elements Used in an SQL Command (’SQL Injection’) This vulnerability can be mitigated by using parameterized queries or prepared statements to prevent SQL injection [69]. Similarly, implementation of input validation and output encoding can be used to prevent SQL injection.
• CWE-327: Use of a Compromised or Risky Cryptographic Algorithm It is recommended to use resilient and reliable cryptographic algorithms or protocols to protect data. Additionally, implement secure key management and distribution mechanisms to protect keys and use mechanisms such as FIPS 140-2, NIST SP 800-57, or PKCS [70].
• CWE-295: Improper Certificate Validation Developers are encouraged to use SSL/TLS certificates from trusted authorities and verify trusted authorities, such as VeriSign, DigiCert, and Let’s Encrypt. Similarly, they can use certificate pinning to prevent accepting expired or forged certificates.
• CWE-749: Exposed Dangerous Method or Function It is important to implement secure authentication and authorization mechanisms to protect the interface and secure communication to protect the data.
• CWE-919: Weaknesses in Mobile Applications The application can be secured using the OWASP MSTG and the OWASP MASVS to test and verify the security of mobile applications.

7.2. OWASP Defenses

This subsection provides the guidelines and mitigation strategies for building applications without security vulnerabilities. The below-provided techniques can be used to address the OWASP security vulnerabilities identified in applications.

• M1: Improper use of the platform This can be addressed by using secure coding approaches [71], limiting sticky intentions, and restricting communication to only consent-based communication. Moreover, developers can limit the use of public intents and libraries, implement access control and authorization mechanisms, and check for possible misconfigurations.
• M2: Insecure Data Storage Developers can use standard encryption algorithms such as AES 256-bit and triple DES, they can also, implement data security measures and harden the code using data masking, data obfuscation, or data minimization [72]. Finally, they can deploy multiple authorization checks that can grant or deny access to data in storage based on the user’s identity.
• M3: Insecure communication Developers can use SSL/TLS protocol to send and receive information and protect it from eavesdropping, tampering, and spoofing. They can verify the authenticity of SSL/TLS certificates before sending or receiving sensitive information. Finally, they should avoid sending sensitive information through SMS, email, and phone notifications.
• M4: Insecure authentication This vulnerability can be significantly addressed by conducting thorough tests, audits, and log data security measures with encryption, hashing, or masking. Moreover, It is required to authenticate on the server side and store data on the mobile device only after verification. Finally, encrypt client-side data when necessary, such as user preferences, session tokens, and keys.
• M5: Insufficient Cryptography It is significantly important to implement strong encryption algorithms to protect sensitive data in transit or at rest, such as AES, RSA, or SHA-256. Developers need to implement long and secure keys for encryption and not store them in device or application code. Also, they need to up-to-date encryption protocols. Encryption protocols such as SSL/TLS, HTTPS, or PGP. it is recommended to never use outdated algorithms and encryption protocols that are prone to weaknesses.
• M6: Insecure Authorization It can be significantly helpful to implement multiple authorization checks to verify user permissions or roles. Also, developers can use secure authentication protocols, such as two-factor authentication with OAuth, or OpenID Connect. In addition, they can regularly update user permissions and roles and revoke unnecessary rights.
• M7: Poor Code Quality It is beneficial to use a code review and software quality assurance testing (SQA) to fix code security weaknesses or flaws, such as broken encryption, weak hashing, or data leaks [73]. This can be fixed by updating the application regularly and performing bug fixes. Moreover, this issue can be significantly resolved if, a developer performs static and dynamic code analysis and fixes the identified issues.
• M8: Code tampering To get ahead of tempering, it is beneficial to use a code signing technique. This will increase the integrity of the code and it will also prevent code tampering and also it will stop dynamic code loading [74].
• M9: Reverse engineering is very common in Android applications, as attackers can reverse an application to see and exploit its vulnerabilities. Therefore, it is required for developers to use different code obfuscation techniques, and anti-debugging techniques that will make the code difficult to reverse engineer and to see its initial code [75,76].
• M10: Extraneous functionality Application developers can use a code-releasing mechanism when developing an application to ensure the quality and security of each interactional release. This will keep track of introduced functionalities and mitigate the impact of extraneous functionality that becomes obsolete by simply removing it. Finally, developers can use different code monitoring and runtime analytics platforms to observe and improve application crashes and fix them in the next releases.

7.3. Long-Term Security Strategies

In addition to the immediate defensive measures, long-term strategies are very important to maintain the security of EV mobile applications. These strategies focus on continuous improvement and adaptation to evolving threats.

One of the key strategies is continuous monitoring and updating. It is needed to regularly monitor the applications for any unusual activities or vulnerabilities and keep the applications updated with the latest security patches and improvements. This ensures that the applications are always equipped to handle the latest threats. Another important strategy is user education. Regularly educating users about the best practices for using the applications securely can go a long way in preventing security breaches. This includes guidance on permissions, secure communication, and data storage.

Additionally, Regular security audits are also an essential part of maintaining long-term security. These audits help identify and fix any security vulnerabilities in the applications. Similarly, adapting to new security standards and guidelines, such as the updated OWASP Mobile Top 10, is another important strategy. This ensures that the applications are protected against the latest known threats and are following the best practices in the industry. Finally, incorporating security at every stage of the application development lifecycle is important. This includes secure coding practices, thorough testing, and post-deployment monitoring. By following a Secure Development Lifecycle (SDLC), we can ensure that security is not an afterthought but a fundamental part of the development process. By implementing these long-term strategies, application developers can ensure that EV mobile applications remain secure against evolving cyber threats.

8. Conclusion and Future Work

In this research, we performed a cybersecurity assessment of 20 EV applications that are available on the Google Play Store. The chosen applications were divided into two groups one which is developed by third-party developers and one group of applications that are developed by EV manufacturers. We used a rigorous methodology based on application permission, features, OWASP, and CWE frameworks to analyze these applications. The findings of our assessment have shown a range of security weaknesses in the applications. Moreover, we mapped these vulnerabilities against the OWASP and CWE lists. Finally, we provided defensive measures and recommendations, to help developers to improve their security and prevent cyber attacks.

In light of the recent release of the OWASP Mobile Top 10 2024, our future work will focus on updating our research to align with this new standard. We anticipate that this will require us to conduct new experiments and collect fresh artifacts, thereby enriching our analysis and findings. By doing so, we aim to ensure that our research remains relevant and continues to contribute valuable insights into the cybersecurity landscape of Electric Vehicle Android applications.

To gain a deeper understanding of these risks, we plan to conduct user surveys and case studies in our future work. These surveys could help us understand users’ awareness of these vulnerabilities and their potential impacts.

Future work can also be dedicated to extending this manual analysis to a more automated approach and expanding the scale of the research using a larger sample of applications. Moreover, similar research can be conducted through the Apple app store to identify cybersecurity challenges in EV applications developed for iPhone and other Apple devices. Also, future work can be carried out to build a fully automated software toolkit that operates with less manual input uses the underlined methodology to find vulnerabilities and weaknesses, and generates an automated defense report on how to patch identified vulnerabilities.