Threat Classification and Vulnerability Analysis on 5G Firmware Over-the-Air Updates for Mobile and Automotive Platforms

Abstract

The integration of 5G technology with existing LTE architectures has facilitated the widespread adoption of firmware over-the-air (FOTA) updates across Android-based devices, including mobile and automotive infotainment systems. While 5G enhances communication speed and convenience, vulnerabilities related to firmware tampering and Man-in-the-Middle (MitM) attacks still present considerable risks. This study analyzes the security of the FOTA update process for six Android-based mobile manufacturers and one vehicle model, all of which utilize LTE architectures within 5G networks. Through comprehensive security testing, we explore the potential threats of certificate bypass, firmware tampering, and communication interception. Our proposed framework identifies critical security flaws in the FOTA implementation, recommending improvements in encryption protocols and integrity verification mechanisms to secure the firmware update process. Our findings underscore the urgent requirement for enhanced security measures in the deployment of FOTA updates to address vulnerabilities in Android-based IoT devices and automotive systems.

1. Introduction

Despite the convenience of Firmware Over-The-Air(FOTA) updates using 5G technology, they also introduce potential security threats in firmware tampering. 5G technology employs high-band frequencies necessitating User Equipment (UE) from providers such as Samsung, Motorola, and Huawei [1]. Manufacturers like KIA and BMW also employ it for external network communication in their Android-based In-vehicle Infotainment (IVI) systems [2]. Notably, 5G still predominantly uses a non-stand-alone (NSA) architecture that relies on existing LTE frameworks, requiring new base stations to transmit high-band frequencies [3]. These devices receive maintenance through FOTA, enabling firmware updates and data transfers across various Internet of Things (IoT) environments. However, this also introduces security risks, as Over-The-Air (OTA) updates are transmitted wirelessly, exposing them to various threats that could potentially compromise the security of server and client communication [4].

FOTA has been developed for the remote management of wireless devices. FOTA updates are necessitated to address security issues or incorporate new services in the device. Multiple devices execute software updates through distribution using OTA technology, which employs the Open Mobile Alliance-Device Management (OMA-DM) to update software and firmware efficiently [5]. FOTA is a technology that facilitates firmware updates, device management, user management, authentication, and SIM card programs over a wireless network, removing the requirement for a physical direct connection [6].

Device manufacturers utilize OMA-DM servers to upload update packages to cloud services. Android-based UEs can download firmware updates from these services for a variety of devices, including in-vehicle infotainment systems, IoT devices, mobile devices, and infrastructure, as illustrated in Figure 1. LTE and 5G employ the same FOTA-based firmware update strategy, and analogous security threats persist [7,8]. The FOTA download process is susceptible to Man-in-the-Middle(MitM) and bypass attacks. Despite regular updates, the firmware update process remains insecure [9]. Currently, there are no established security testing methods for firmware updates [10], which underscores the need for robust analysis methods and environments for FOTA verification testing [11]. To address this, FOTA recommends a process for testing environments that evaluate security threats.

While OMA-DM and cloud services managed by manufacturers are considered low-risk due to their closed nature, the FOTA-based download process poses greater risks because it exposes the communication between the device and the update server to external threats. Specifically, if secure communication protocols such as SSL(Secure Sockets Layer)/TLS(Transport Layer Security) are not employed during the FOTA update process, vulnerabilities to attacks like sniffing or MitM arise [12]. Moreover, the level of risk varies based on the integrity verification algorithm used to determine if the FOTA update package has been altered. Accordingly, employing encryption protocols and incorporating security measures are critical for a secure firmware update process [13]. Since implementing these measures for FOTA update verification testing is challenging, verifying the use of SSL/TLS in the communication process and the methods of firmware integrity verification through an analytical environment is imperative.

Therefore, to verify the security of Android-based FOTA updates for devices such as IoT and mobile devices, this study establishes an OMA-DM-based FOTA update security testing framework to analyze the firmware update process using the OMA-DM-based FOTA protocol in mobile devices in depth. This study introduces security testing methods to evaluate potential security threats in the OMA-DM wireless protocol during the FOTA update process [14]. Finally, based on the security threats identified through the testing methods, they propose addressing potential security threats to the wireless protocol of OMA-DM in the FOTA firmware update process of each manufacturer’s Android-based mobile devices.

In this study, Section 2 describes the FOTA update process based on OMA-DM. Section 3 systematically organizes the security methods to mitigate security threats associated with FOTA updates, utilizing a fishbone diagram derived from related work. Section 4 presents the security testing methods developed in this research to address MitM attacks and certificate bypass attacks, which may result from developers’ errors, particularly in secure FOTA updates, using the previously constructed fishbone diagram. Section 5 explores the downgrade and MitM attack scenarios during the FOTA update process and methods for verifying their vulnerabilities. Section 6 concludes with the verification results and conclusions for each mobile and automobile manufacturer.

2. Background

2.1. FOTA Firmware Update Process Using OMA-DM

OMA-DM facilitates mutual authentication and data exchange in an IP-based server-client model, providing functionalities such as subscriber information updates, subscriber identification modification, and device firmware updates. In mobile technology, OTA updates involve downloads to the SIM card via the mobile network for application communication and management, without physical connections to the device [15]. Both mobile operators and device manufacturers have enabled firmware updates utilizing OMA-DM technology [16]. Mobile device manufacturers perform firmware updates by enhancing the OMA-DM, which is an IP-based OTA service. Figure 2 illustrates the OMA-DM configuration and environment used in a typical firmware update process.

The FOTA firmware update process using OMA-DM by manufacturers is performed as follows:

• Building Firmware Update Package: Different versions of firmware are available, and they update to the latest version. The manufacturer creates a new firmware update package for the update and registers it with the administrative system that manages the operator’s firmware by version.
• Registering Package: The update package from the deployment phase is registered with the OM Server in the User Plane.
• Testing: Test the firmware for functionality and integrity before deploying it to a lifecycle management system.
• Releasing: When it is time to deploy the firmware, release the new version to the DM(Device Management)/DL(Download) server.
• Publishing: The DM/DL server sends a message from the notification server to the device, notifying it that a new update is available.
• Notifying Update: The device receives a notification from the notification server indicating that a new update is available.
• FOTA based Firmware Download & Installation: FOTA based Firmware Download & Installation: After authenticating with the DM server, the mobile device downloads the new firmware update package using the download descriptor. Subsequently, the integrity of the firmware update package is confirmed by comparing its hash value to the hash value received [17]. During this process, MitM and certificate bypass attacks are potential risks.

Mobile manufacturers utilize this procedure to provide firmware updates to devices that have already been released. Although the manufacturer-managed firmware distribution process has a lowrisk associated, it carries a higher potential for security threats when users update their UEs in a wireless environment. Security threats may arise if devices download firmware packages from an update server, exposing wireless communication packets to the risk of being tampered with or altered by a man-in-the-middle, an attacker. Furthermore, while the integrity of the downloaded firmware package file is verified using a hash algorithm based on a server-provided certificate, it is possible for security threats to bypass this certification.

2.2. Man-in-the-Middle (MitM) Attack

When an attacker positions themselves between two communicating parties, they can intercept or manipulate the transmitted information. Although one may believe that their communication is secure and direct, the attacker might access or modify the data in transit. This type of attack commonly occurs on vulnerable networks, such as public Wi-Fi, and is more successful when encryption is weak. The failure to apply robust cryptographic algorithms can enable attackers to acquire server URLs by manipulating firmware during FOTA upgrades or by sniffing the network for vulnerabilities through man-in-the-middle (MitM) attacks [12,18,19,20].

2.3. Bypass Certification

This attack involves manipulating or disregarding a certificate used in secure communications, deceiving an untrusted connection into appearing trustworthy. For instance, introducing a fake certificate can mislead users into interacting with a malicious server, resulting in unintentional data leakage or directing them to a phishing site. Such attacks are facilitated by coercing the installation of an untrusted root certificate on a device or browser. In the absence of robust security features, attackers can exploit vulnerabilities to enable DoS or spoofing attacks using high volume traffic [13]. Moreover, weak access controls can lead to integrity issues such as authentications being bypassed, altering the firmware download link, and modifying the firmware file itself [21,22,23,24]. Hence, verifying both the download firmware server and the update package is crucial for secure FOTA updates.

2.4. Downgrade Attack

An attacker may compromise security by purposefully downgrading a highly secure communication protocol or cryptographic algorithm to a less robust version. This older protocol version could contain vulnerabilities that the attacker might exploit, thereby forcing the server and the client to communicate at a reduced security level. Such tactics are frequently applied to protocols such as TLS and HTTPS, potentially leading to easier exposure of sensitive information. Specifically, the most likely threats include authentication bypass attacks using forged SSL certificates and downgrade attacks employing MitM techniques. To address this, techniques are being developed to mitigate security threats associated with OTA updates in wireless network environments [25,26,27]. However, existing research on FOTA updates primarily focuses on theoretical concepts or proposals for new update schemes.

3. Related Work

We summarize and analyze previous research on man-in-the-middle attacks, certificate bypass, and downgrade attacks, which are typical vulnerabilities that can occur during the FOTA update process. Man-in-the-middle attacks occur when an attacker alters or modifies the firmware during the FOTA update radio process. Certificate bypass may result in a server failing to authenticate with a legitimate certificate. Finally, a downgrade attack involves tampering with the firmware and replacing it with an older version of the file, thereby increasing the likelihood of security threats.

Based on the relevant research analyzed earlier, we categorized errors in the FOTA implementation through a fishbone diagram, as shown in Figure 3, based on three main categories: lack of encryption, weak access control, and the deactivation of security elements. Implementation errors in the FOTA update protocol can lead to vulnerabilities and attack scenarios. Therefore, due to these vulnerabilities and potential attack scenarios, security validation is necessary. FOTA implementation errors can generally be classified into failures to apply cryptographic algorithms, failure to utilize security factors, and weak access control.

Existing research proposes new FOTA update methods, but they often overlook empirical verification of the security of these updates. Given that FOTAs used in various fields are developed independently by different manufacturers, security verification is essential. In this paper, we summarize the security techniques and limitations of FOTA updates, as proposed in the three most extensively studied fields—mobile, IoT, and automotive—in previous research.

In the mobile sector, the significance of security in OTA radio environments for mobile device updates is acknowledged, and methods to ensure authentication and secure transmission for download sequences have been proposed to safeguard OTA updates [28]. Additionally, the potential for reconfiguration and the application of standards via SDR have been suggested [29]. However, FOTA lacks security verification in its protocol. Moreover, this underscores the need for a more standardized update management system within the Android ecosystem [30,31]. FOTA services, which involve firmware in various areas, can pose security threats. Consequently, it is vital to utilize testing methods that cover most types of attacks to verify updates.

In the IoT sector, FOTA applications are crucial for updating Android devices, yet they present security vulnerabilities that could jeopardize privacy. These vulnerabilities could enable unauthorized collection of sensitive information without explicit consent and the potential installation of malicious updates on devices [32,33,34,35,36,37,38,39]. There is an absence of a standard, and there are significant risks associated with adopting new digital technologies such as the Industrial Internet of Things (IIoT) [32]. Consequently, a mechanism and framework to ensure secure FOTA are necessary to address and mitigate these security threats. However, security considerations for mobile updates, particularly insecure firmware updates for IoT devices, often receive inadequate attention. To remedy this, the study identified various mechanisms for OTA updates, developed a taxonomy to aid system designers, and designed an OTA update system specifically for cyber-physical systems (CPS) and IoT [33].

In the automotive sector, the company utilizes OTA technology for remote ECU updates and is developing new strategies for secure updates [4,40,41,42,43,44,45,46,47]. The automotive industry is increasingly adopting Software Defined Vehicles (SDV), fostering a need for robust security measures and sophisticated software management strategies for OTA updates [40]. A model-based security testing methodology has been developed to identify Uptane vulnerabilities in vehicle OTA security [4]. Additionally, FOTA is employed for updates in maintaining vehicle ECUs [41]. When conducting FOTA updates on vehicles, it is crucial to utilize a security module to securely store certificates and keys, ensuring that the upgrade package originates from a legitimate source and is securely preserved [42]. Specific requirements must be met to maintain the integrity of OTA software updates, including using secure transmission channels, notifying users of updates, and securely storing updated images in the vehicle [43]. FOTA services encompass firmware from various vehicle domains, which can introduce security risks [44,45]. Therefore, it is imperative to apply testing methods that address a wide range of attack types to ensure updates are secure.

These implementation elements must be confirmed through a secure FOTA firmware update process, and a verification framework is necessary. Thus, verifying updates with testing methods that can address a wide spectrum of attacks is crucial. In this paper, we demonstrate the validation and security of implementing FOTA updates against man-in-the-middle and certificate bypass attacks.

4. Security Testing Methods for the FOTA Update Process

This section proposes a security testing method that derives results from attack scenarios and the security testing process using a fishbone diagram. This diagram summarizes the security threats that can cause vulnerabilities in FOTA, as illustrated in Figure 4. It is based on the IP-based FOTA service firmware update process provided by the manufacturer. This study outlines a method utilizing the OMA-DM environment to test various security threats potentially occurring during the FOTA update process. Validating both the download firmware package server and the update package is crucial for secure FOTA updates. The security testing methodology based on OMA-DM includes constructing a validation environment, defining security threats, testing attack scenarios, and identifying implementation errors. The variability in scenarios during the FOTA update process is influenced by the server implementation by the manufacturer and the level to which security features are integrated. Thus, a framework to verify the FOTA update process is essential, and it is implemented in various forms by different manufacturers.

4.1. Setup Environment

The OMA-DM server and client were established to identify security threats in a real OTA update scenario and to create an experimental setup. Funambol [48], which supports building OMA-DM, is an open source platform based on OMA-DM version 1.2, utilizing JAVA and Tomcat. Although originally developed in a Windows environment, its JAVA-based architecture ensures compatibility across multiple operating systems.

For the installation of Funambol to proceed, it is necessary to install a web server infrastructure including JAVA, JBoss, MySQL, etc., as these are prerequisites for implementation. In the case of MySQL, it is required to set up a database table accessible by Funambol, configuring user information and permissions. Basic database configurations can be executed using the MySQL command line.

The “install.properties” configuration file in the best folder of Funambol details the access path to the DB, the location of the DB driver, and the server connection account. It is important to modify this configuration file according to the experimental environment setup and proceed with the installation. After configuring the file, the installation is performed by executing bin/install.cmd in the top folder of Funambol via command line. This configuration establishes a standardized FOTA update server and a test environment to verify security threats associated with manufacturer-specific update procedures.

Upon completion of the installation, it is necessary to register environment variables for each web server and JAVA. To launch the server post-configuration, execute the “bin/start.cmd” file from the primary Funambol folder using the command line. Figure 5 demonstrates that the open-source OMA-DM server is successfully implemented and functional. These OMA-DM environments serve as primary validation and testing environments for assessing security threats related to manufacturer-specific update processes using a shared update server for FOTA updates.

In the case of OMA-DM, when a push message is delivered to the client, it verifies the server using the DM server’s ID and password that were pre-stored. There are four types of authentication procedures that can be applied at this stage: None, Basic, MD5, and HMAC. Since the one-way hash function does not perform encryption, there is a risk that the server’s ID and password may be deciphered, hence OMA recommends using SSL/TLS communication over HTTP communication at the transport layer. The communication process of the OMA-DM server is as follows:

• The registered update package goes through a series of tests and then moves to the release phase.
• The tested update package is uploaded to the DL server, and subsequently, the DM server notifies the UE of the new update release via the notification server.
• The UE mutually authenticates with the DM server and retrieves a download descriptor from the DL server.
• The UE extracts the objectURI field from the download descriptor to determine the exact location of the firmware.
• The UE downloads the firmware, computes the MD5 hash value, and verifies it against the MD5 hash value in the installParam field of the download descriptor to ensure the integrity of the firmware update package.
• If the UE client successfully completes the integrity check, it sends a SUCCESS message to the entity in the installNotifyURI field and initiates the firmware update.

The OMA-DM simulation environment established allows for the uploading of real firmware and the testing of the process for updating device firmware. Based on this, we can evaluate the potential for attacks on the mobile device’s OTA update process.

4.2. Define Security Threats

In this section, we examine various security threats that could emerge during the OTA update process using the OMA-DM simulation environment, developed based on the manufacturer’s IP-based OTA service firmware update protocol. We analyze two potential attacks and vulnerabilities associated with the server verification method during OTA communication and the OTA firmware update package verification method.

The legitimacy of OTA firmware files must be verified before performing an update. In the OMA-DM protocol, users can confirm the legitimacy of MD5 and MD5 descriptor values received during communication with a certifier to check for file tampering. However, if an attacker modifies the firmware file and recalculates the MD5 hash, then distributes the altered firmware and its new MD5 value via their authentication server, a user updating their firmware might inadvertently download and verify the compromised file.

Some manufacturers employ HMAC instead of MD5 to enhance security. HMAC utilizes a secret key to generate a hash value that is not easily forged by attackers. Although this approach offers a more secure verification method, it is still feasible for an attacker to distribute modified firmware if they manage to verify the accompanying key as well.

The below

Table 1. Security threats during the FOTA update process and the ability to verify firmware with security algorithms (A—applicable/NA—not applicable).

Risk of Threats	Attack Methods	MD5	HMAC
Jamming	Blocking or distorting the original communication signal by generating signals or noise from outside with malicious intent.	NA	NA
Sniffing	Attacks that spy on communication channels for firmware transmission.	NA	NA
Modification	Attacks through update firmware tampering during the update process.	A	NA
Hijacking	Attack that intercepts firmware files in the middle.	A	NA
Fabrication	Technology to launch attacks by counterfeiting firmware.	A	A
Spoofing	An attack utilizing disguised URL to download firmware.	A	NA
AP Camouflage	By deceiving the victim into using a standard AP, the victim is urged to connect to the UE.	A	A
Masquerading	Download the firmware by cloning it to a standard UE.	A	A

illustrates more than 8 potential security vulnerabilities in OMA-DM and indicates whether firmware verification techniques using MD5 and HMAC could mitigate these vulnerabilities. The security of OTA updates depends on the extent of security measures implemented by individual device manufacturers. Consequently, using the OMA-DM simulation environment, we experimented to assess the feasibility of substituting a compromised firmware update file during the OTA update procedure.

4.3. Testing Attack Scenarios

Based on the defined security threats, the test verifies the likelihood of attacks in the deployed environment. The attack scenarios include security threats that attackers can leverage to conduct real-world attacks. MitM and certificate verification bypasses are among the most critical threats in the FOTA-based firmware update process, leading to a variety of security issues. This study will analyze each attack vector and identify components that could be exploited during the firmware update process. It will further evaluate attack scenarios using common elements that can precipitate an attack.

When the mobile manufacturer downloads the OTA update package to the device via the DM service, the device conducts an integrity check on the OTA update package to confirm that it complies with standard firmware specifications. Additionally, the OTA update package performs a signature check within the Android system, and a secondary signature check is executed using the recovery binary during the update in Recovery mode. In total, three levels of verification confirm the integrity of the OTA update package. However, some manufacturers utilize the less secure MD5 verification method even though the manufacturer conducts a separate integrity verification from the Android system after sending the OTA package. Consequently, the OTA update package is vulnerable to tampering if a MitM attack is feasible.

4.4. Discovering Implementation Error

Manufacturers can leverage vulnerabilities in FOTA to validate the FOTA update process and identify implementation errors. Common implementation errors include the deactivation of security components, inadequate access control, and the absence of encryption.

The OMA-DM protocol is required to ensure that the server connected for download is authenticated accurately. However, the protocol depends on SSL communications to establish server trust. Furthermore, a manufacturer employs SSL communication between the DM/DL server and the client. It is noted, however, that SSL certificate verification only confirms the issuance by a trusted organization without verifying the domain. In such instances, a MitM attack could be executed using an SSL certificate from a different domain, even if it is issued by a trusted organization.

Device manufacturers offer two primary methods for users to ascertain the legitimacy of a firmware file before updating. In OMA-DM, the MD5 and MD5 descriptor values received during communication with the authenticator are checked to determine if the file has been forged. However, if the compromised firmware file and the MD5 of the tampered file are calculated and distributed through the attacker’s authentication server, a user intending to update the firmware might inadvertently download modified firmware verified as legitimate. As an alternative to MD5, some manufacturers employ the more robust HMAC [49] to authenticate the firmware before download. HMAC uses a key to generate a hash value, making it difficult for an attacker to falsify it. Nonetheless, the key can be compromised, allowing an attacker to disseminate altered firmware.

5. Verification of Security Threats and Attack Scenarios for the FOTA Update Process

This section examines the security threats that may emerge when manufacturers use OMA-DM-based FOTA updates to upgrade mobile devices. A case study provided by a manufacturer depicts an attack scenario occurring during FOTA updates, including communication via OMA-DM and firmware verification. It is suggested that MitM attacks through firmware interception or modified firmware updates by an attacker, as well as the risk of message exposure from bypassing certificate verification in the communication process, be considered.

5.1. Bypassing Certificate Verification During the FOTA Update Process

The OMA-DM protocol is vulnerable because it does not ensure the legitimacy of the server during connection attempts. While the standard uses SSL to establish server trust, SSL certificate verification only confirms if the certificate is issued by a trusted organization, and not the domain. As shown in Figure 6, a MitM attack could exploit an SSL certificate from a different domain issued by a trusted organization. Additionally, man-in-the-middle attacks can intercept communication packets between the device and the manufacturer’s system server, potentially exposing sensitive data in the FOTA update process.

When the device and the server connect to update the firmware, if the firmware is requested using a test certificate, an error message indicating a network problem appears. Conversely, if the update is requested with a certificate from a trusted organization, the firmware file is typically downloaded smoothly. Thus, an attacker could facilitate unauthorized access using a fraudulent certificate and quickly inspect the packets transmitted and received during the firmware update, including the manufacturer’s system server address, through a man-in-the-middle attack.

The primary issue with the OMA-DM protocol is its failure to verify the server’s legitimacy. While the standard employs SSL communication for security, trust in the server is exclusively based on this SSL connection. In the instance of Company A, SSL communication was established between the DM/DL server and the client, as demonstrated in Figure 7. However, experiments revealed that SSL certificate verification only confirms that a certificate is issued by a trusted organization; it does not verify the domain. Consequently, a man-in-the-middle attack is feasible if a certificate from a different domain, issued by a trusted organization, is employed. Such attacks allow unauthorized users to intercept communications between the device and the manufacturer’s server for analysis, leading to potential secondary security threats.

5.2. Inducing a Tampered Firmware Update During the FOTA Update Process

Certificates can verify the connectivity to the correct server for firmware downloads, but MitM attacks can still occur between the device management/download server (DM/DL) and the client by circumventing certificate verification. The absence of download address validation in the FOTA update process can be exploited by attackers. They could deceive a device into connecting to a malicious Wi-Fi network and downloading tampered firmware through DNS spoofing during the upgrade.

For example, a manufacturer’s update process checks the integrity of firmware downloaded through OMA-DM by comparing the MD5 hash value of the download descriptor with the MD5 hash value of the downloaded firmware. However, an attacker could manipulate these values with the MD5 hash of tampered firmware, thus tricking the system into downloading the corrupted update as shown in Figure 8. An analysis of the packets sent from the DL server during a MitM attack could reveal the URL for downloading the firmware update and the communication protocol, such as Hypertext Transfer Protocol (HTTP).

Ultimately, an attacker would alter the MD5 value of the download descriptor, and upon dispatch, the user would connect to the manipulated URI to download the firmware file. The MD5 hash value of the downloaded firmware is compared with the MD5 value of the download server to confirm its integrity. During security testing, alteration of the MD5 hash value of the download descriptor occurred after 1 byte of the standard firmware update file was tampered with to facilitate the download of the tampered firmware update file, confirming that the corrupted firmware could be downloaded routinely. Moreover, the device downloads the altered firmware through packet sniffing, following which a successful download notification is sent to the server.

In the OMA-DM firmware update environment, requesting a firmware update with a test certificate results in an error message about a problem, whereas employing a certificate issued by a trusted authority permits a normal firmware download. This process is susceptible to man-in-the-middle attacks, which allow interception of packets and accessing the manufacturer’s system server address. We observed a packet containing a download descriptor from the DL server during such an attack. The descriptor included elements such as Type, description, objectURI, size, installnotifyURI, and installparam, as depicted in Figure 9. Subsequently, by analyzing the download descriptor, we identified that the objectURI element address, which directs to the firmware update file download, utilized http communication.

5.3. Firmware Downgrade Attack During the FOTA Update Process

Typical firmware updates for mobile devices incorporate rollback protection to forestall updates to older firmware versions for security enforcement. Nonetheless, if an attacker successfully installs a prior firmware version, the security vulnerabilities of that version may persist. As illustrated in Figure 10, an attacker can execute a downgrade attack by deploying a counterfeit server to distribute an older firmware version and deceive users into downloading it. The FOTA update protocol allows for integrity verification of the firmware package and enables packet tampering through surveillance of the communication. This vulnerability permits the attacker to divert traffic to a fraudulent server URL. Subsequently, the attacker may embed malicious code into the firmware package and target the updated user’s UE, emphasizing the importance for users to verify the legitimacy of the server from which they are downloading and the necessity for innovative countermeasures.

The normal FOTA update process involves upgrading from an earlier to a more recent firmware version. However, without adequate validation by the manufacturer, a downgrade attack could revert the firmware to an earlier version containing malware. Figure 11 illustrates the inadvertent downgrade of firmware by the user, a change which often goes unnoticed due to the lack of attention to the update process. This compromised firmware permits the attacker to inject malicious code into the firmware package, endangering the user’s device by enabling actions such as theft of personal information, installation of spyware, or rendering the device inoperable. Consequently, it is imperative for manufacturers to ensure that firmware updates are exclusively downloaded from reliable and legitimate servers.

6. Results of Security Assessment for FOTA Update Process

Using the proposed framework, we examine the status of FOTA implementation, assessing security strength and robustness based on manufacturers’ evaluations of FOTA update security. We analyse the OMA-DM-based OTA firmware update methods utilized by six widely used Android-based mobile device manufacturers and one vehicle manufacturer, as detailed in

Table 2. Potential security threats during the FOTA update process for each manufacturer analyzed by security testing methods (P—possible; NP—not possible).

			Mobile				Vehicle
Manufacturer	A	B	C	D	E	F	G
FOTA Type	OMA-DM	OMA-DM	SSL/TLS	SSL/TLS	JSON	JSON	SSL/TLS
Protocol	SSL/TLS	HTTP	SSL/TLS	SSL/TLS	HTTP	HTTP	SSL/TLS
Algorithm	MD5	Digital Signature	MD5	Digital Signature	MD5	MD5	Digital Signature
Risk of MitM	P	P	NP	NP	P	P	NP

. We verified each firmware update approach, including the protocols used, the verification methods for OTA packages, and resilience to MitM security threats. The verification method proposed and its implications for future industrial applications are also discussed.

6.1. Comparison of Security Strength by Security Algorithm Used in the FOTA Update Process

Based on the results of the FOTA security assessment, three main communication protocols are used in the FOTA update method: OMA-DM, SSL/TLS, and HTTP-based JSON message type. The basic OMA-DM update method has almost no security features, and the security strength is slightly higher in SSL/TLS, a slightly more secure algorithm based on the results of existing security strength comparison studies. In addition, in the protocol communication process, the cipher strength of SSL/TLS is higher than that of HTTP, which does not have a security device between the server and the client, because security is applied [50,51]. Finally, as a method for verifying the integrity of firmware, electronic signatures are more secure than MD5, which is a simple hash method [52,53,54].

However, certain manufacturers employ low-security authentication schemes in OMA-DM and opt for HTTP communication instead of the more secure SSL/TLS, rendering the system susceptible to MitM attacks. Exploiting these vulnerabilities allows an attacker to impersonate a DM server that lacks mutual authentication and potentially transmit OTA messages to the actual device using a DM tree list extracted from the application. Moreover, the download descriptor utilized for firmware updates is not authenticated, presenting a substantial risk. If the download URL is altered or if the MD5 value of the downloaded file is compromised, an unintended firmware update could severely threaten mobile devices.

Additionally, manufacturers that do not deploy OMA-DM for updates and substitute SSL with the less secure HTTP protocol are also prone to MitM attacks. If a lightweight MD5 hash verification method is used to verify OTA update packages, it significantly increases the risk of firmware tampering. Consequently, robust security features are vital for the update methods used by device manufacturers, who must implement rigorous security mechanisms.

6.2. Limitations of Security Assessment of FOTA Update Process

The security verification of the FOTA update process through the proposed framework can ascertain the safety of the firmware update process for Android-based devices against MitM attacks, as well as the integrity of the firmware verification process. However, the FOTA process for iOS-based devices is more complex and similarly requires security verification. The same security threats, such as MitM attacks, can also arise in the wireless environments of iOS devices [55]. Given the impracticality of validating every mobile device from each manufacturer currently on the market, we can select a small sample of six mobile devices from Android platforms and one automobile manufacturer to gauge the security integrated into the existing FOTA update process. Although it is not feasible to validate against all possible security threats, preparation for the three most common threats—downgrade attacks, bypass certification, and firmware tampering—is achievable.

6.3. Industry-Level Discussion of FOTA Update Process Verification Results

FOTA is essential for firmware updates in embedded devices, such as IoT devices, mobile devices, and automotive IVI systems. Manufacturers should utilize basic protocols like OMA-DM, HTTP, and TLS1.2, which provide greater security than SSL/TLS. They are advised to implement asymmetric key algorithms and secure chip suites in accordance with NIST guidelines for secure FOTA updates. Additionally, they should address potential man-in-the-middle attack threats through careful key management and the use of certificates, focusing on key length management and the restrictions on self-signed certificates [56]. Utilizing MD5-type hash verification for OTA update packages downloaded via secure channels is problematic, as it substantially increases the potential for firmware tampering. Instead, HMAC or digital signatures, as recommended by NIST, should be used to securely verify the integrity of the updates [57,58,59]. Ultimately, integrating security features into the update mechanisms of device manufacturers and future-proofing these methods are crucial.

7. Conclusions

As FOTA technology advances, new firmware versions, bug patches, and similar features continue to provide rapid response services to users. This paper discusses the security risks associated with OMA-DM-based FOTA updates and suggests a framework for their verification. A new simulation environment for mobile UE FOTA updates, based on the OMA-DM protocol and Funambol cloud service, was developed and tested for vulnerabilities, particularly against likely man-in-the-middle and certificate bypass attacks. Observations indicate that some manufacturers fail to implement the more secure SSL/TLS protocols and often use simple, easily compromised hash functions to validate firmware updates. Manufacturers could adopt this proposed framework to enhance the security of wireless FOTA updates, and future research could focus on creating automated tools for efficient verification.

It is essential to prevent MitM attacks and design a security-enhanced update process. Mobile device manufacturers should establish a secure communication environment and a verification process for secure OTA package updates using OMA-DM, complemented by additional security measures. Furthermore, the vulnerabilities identified in this study can be mitigated through the application of secure coding practices, the implementation of security protocols such as SSL/TLS, and the establishment of mutual authentication systems. It is necessary for the academic community to collaboratively address these security issues so that user equipment and baseband manufacturers can patch vulnerabilities effectively and respond proactively to potential attacks. The vulnerability verification framework and practical security threats identified in this study can proactively contribute to future vulnerability analyses, and they are critical for identifying undiscovered vulnerabilities.