Introduction

In many ways, mobile devices should not be different from laptops or other computer systems. They run operating systems that are derived from those those systems (Android from Linux and iOS from macOS, which is derived from Mach & BSD), run multiple apps, and connect to the network. There are differences, however, some of which make them attractive targets to attackers.

Mobile phones, used by billions globally, present unique security challenges largely due to how users perceive and handle them.

First, the vast number of mobile users—3.6 billion on Android and approximately 1.46 billion on iOS—makes these devices attractive targets for cyber attacks. The scale alone increases the likelihood of successful breaches.

Many users, especially in mobile-first regions, do not think of their smartphones as computers capable of similar vulnerabilities, which leads to a lax attitude towards security. This oversight is exploited through social engineering tactics, which may be more effective on mobile due to the frequent use and personal nature of devices. Additionally, the small form factor of phones means security indicators, such as certificates on websites, are often overlooked or not understood by users. Mobile devices are also easily lost or stolen, increasing the risk of unauthorized access. Furthermore, most devices support PIN-based authentication as a fallback to biometric authentication but users have been shown to choose weak PINs. They are also likely to grant app permissions without considering the implications, further compromising their personal security.

Phones have lots of sensors that can be exploited

Modern smartphones are equipped with many sensors designed to enhance user experience, but these sensors also present potential security vulnerabilities. These include cellular connectivity sensors like GSM, 3G, 4G LTE, and 5G, as well as Wi-Fi , UWB, NFC, and Bluetooth for local connectivity. Phones also feature GPS and NFC for location and near-field communication, respectively. Other sensory capabilities include microphones, cameras, a 6-axis gyroscope and accelerometer, barometers, magnetometers (compass), proximity sensors, ambient light sensors, LiDAR, and biometric sensors such as fingerprint and facial recognition scanners. Each of these sensors collects specific types of data about the user and their environment, increasing the utility of the device but also potentially exposing the user to risks if not properly secured.

These sophisticated sensors can be exploited by attackers in various ways to monitor a user’s environment and activities. For example, GPS, Wi-Fi, and cellular data can be used to track a user’s location and movements, while microphones and cameras can be activated remotely to eavesdrop on conversations or capture video without the user’s consent. The gyroscope and accelerometer can even be manipulated to sense vibrations and movements, such as those from a nearby keyboard, which has been demonstrated to allow attackers to recover typed words with a high degree of accuracy. Biometric sensors, while enhancing security for device access, also pose a risk if the biometric data is intercepted or improperly stored. Overall, while these sensors are meant to serve legitimate and useful functions, they can also provide a backdoor through which attackers can invade a user’s privacy or steal sensitive information.

Lots to apps present opportunities for exploits

Mobile phones host a staggering array of applications, with 2.43 million Android apps available on Google Play and 2.29 million on the Apple App Store. A significant portion of these applications is written by potentially untrusted parties. On our PCs, we would typically be more cautious about downloading software from unknown developers, but don’t hesitate to do so with mobile apps. The process of vetting these apps is left primarily to Google and Apple. Google largely relies on automated systems for testing and approval, while Apple incorporates both automated processes and manual review. However, even with these checks, risky apps slip through the cracks.

Mobile phones are comparable to desktop systems in complexity. In some cases, they may even be more complex. This points to the fact that, like all large systems, they will have bugs and some of these bugs will be security sensitive and lead to exploitable vulnerabilities.

Because of bugs in the system, malicious apps may be able to gain root privileges. If they do, they can install rootkits, enabling long-term control while concealing their presence. Many malicious iOS apps, for instance, gained root privileges by exploiting heap overflow vulnerabilities.

Mobile operating systems employ sandboxing to isolate apps and minimize their potential to interfere with each other or the system. They also require apps to explicitly request permissions from users to access certain resources like the camera, microphone, or location data. Despite these safeguards, many apps ask for more permissions than they actually need for functionality, and unfortunately, most users tend to overlook or dismiss the permission request screens without scrutiny. A telling example from a study in September 2019 highlighted this issue, where an analysis of 937 flashlight apps revealed that the average number of permissions requested by an app was 25, with 262 of these apps asking users to grant 50 or more permissions. This excessive permission requesting raises significant security concerns. Finally, most apps do not receive regular security updates, leaving vulnerabilities unaddressed and users at risk. There is little economic incentive for a developer to support existing apps, particularly if newer ones have been deployed.

Unlike desktop systems and laptops, phones enforce a single-user environment. Although PCs are usually used as single-user systems, they support multiple user accounts and run a general-purpose timesharing operating system. Mobile devices are more carefully tuned to the single-user environment.

Mobile devices can be threats to personal privacy as well as at risk of traditional security violations. Personal privacy threats include identifying users and user locations, accessing the camera and microphone, and leaking personal data from the phone over the network. Additional threats include traditional phishing attacks, malware installation, malicious Android intents (messages to other apps or services), and overly-broad access to system resources and sensors. Even without exploits, organizations can track bluetooth or Wi-Fi beacons to gain information about the movement of an individual phone.

Android security

Android was conceived as an operating system for network-connected smart mobile devices. The company was acquired by Google in 2005 and the engineering effort shifted to developing it as a Linux-based operating system platform that would be provided for free to third-party phone manufacturers. Google would make money from services and apps.

Applications on Android had specific needs, some of which have not been priorities in the design of desktop operating systems. These include:

Integrity: For Android applications, maintaining integrity means ensuring that an app has not been altered from its initial creation through to its installation on a device. This is crucial for preventing malicious modifications that could compromise app functionality or user security. Android enforces integrity through application signing and app verification processes. Developers sign their apps with a private key, and the corresponding public key is used to verify the app’s integrity upon installation. The Google Play Store further reinforces this by vetting apps before they are available for download, ensuring that only those that haven’t been tampered with are accessible to users.

Isolation: Isolation in Android apps is about ensuring that each application operates in a secure environment, shielded from other apps. This isolation is crucial for protecting an app’s data and ensuring that one app cannot adversely affect another. Android achieves this through the use of sandboxing techniques where each app operates in its own virtual machine. The operating system assigns each app a unique user ID (UID) and runs them in separate processes, which isolates their data and execution from other apps. This structure helps to protect user data and maintain the overall security of the device.

Sharing: Despite strict isolation protocols, Android apps often need to share information or resources, such as network access or external storage. Android facilitates this sharing through controlled mechanisms such as intents, content providers, and shared preferences. These tools allow apps to interact with each other and the system while maintaining a level of permission-based security. For example, an app needs to declare in its manifest file if it requires access to the internet or external storage, and the user must explicitly grant these permissions.

Inter-app services: Android supports robust inter-app communication through services like intents and binders that allow apps to request services from each other. This capability is essential for creating a cohesive and functional user experience where apps can leverage capabilities offered by others. For instance, an app can use an intent to capture photos via another app that has access to the device’s camera. These interactions are regulated through permissions and intent filters that ensure apps can only perform actions that have been explicitly allowed, thereby maintaining security and privacy.

Portability: A key requirement for Android applications is the ability to run across a wide range of hardware architectures. Android apps are typically developed in Java or Kotlin, which run on the Android Runtime (ART) or before Android version 5.0, the Dalvik Virtual Machine (DVM), ensuring that they are agnostic to the underlying hardware architecture. Moreover, Android provides APIs and services that abstract the hardware details away from the app developer, allowing apps to perform consistently across devices with different configurations and capabilities. This portability is crucial for reaching a broader user base and ensuring consistent performance and user experience regardless of the device.

File and file system encryption

File and file system encryption are key components of Android security designed to protect data stored on an Android device from unauthorized access, especially if the device is lost or stolen.

Android offers file-level encryption (FBE, File-Based Encryption) which encrypts individual files with different keys, allowing finer control over data access. This method ensures that only approved processes or users can access certain files, depending on the state of the device (e.g., unlocked, locked). Introduced in Android 7.0 (Nougat), FBE enables some functionality to be available sooner after boot, even before a user has fully logged in, while keeping other more sensitive data secure until after authentication.

Before file-level encryption, Android used full-disk encryption (FDE, Full-Disk Encryption), which was introduced with Android 5.0 (Lollipop). FDE encrypts the entire user partition at the block level, which means everything was encrypted as a single unit. This approach provided strong security but lacked flexibility, especially in usability when the device needed to perform certain tasks before user authentication, such as alarm functions or receiving calls.

Both types of encryption rely on strong key management practices embedded within Android’s security architecture. Encryption keys are typically derived from the user’s device password, PIN, or pattern, combined with hardware-backed security modules (such as the Trusted Execution Environment or Secure Element) to enhance security. These keys are not accessible while the device is locked, ensuring that encrypted data remains secure even if the device hardware is compromised.

Booting

To complement encryption, Android implements a secure boot process that verifies the integrity of the operating system and prevents unauthorized modifications. This ensures that the encryption mechanisms are not tampered with and that only a verified and secure OS can decrypt the data.

<–

The Android app sandbox

Android relies on process sandboxing for most of its security. Android is based on Linux, which is a multi-user operating system. Under Linux, each user has a distinct user ID and all apps run by that user run with the privileges of the user (ignoring setUID apps). This allows any one app full access to all user data.

User IDs

Android supports only a single user and uses Linux user IDs for isolating app privileges. Under Android, each app normally runs under a different user ID. Hence, apps are isolated and can only access their resources. Access requests to other objects involve messages that pass through a gatekeeper, which validates access requests.

Core Android services also run in a similar manner, with each service running under its own unique user ID. For example:

Related apps may share the same Linux user ID if a sharedUserID attribute is set to the same domain for two or more applications as long as those apps are also signed by the same certificate. This would allow these related apps to share files and they can be configured to even share the same Dalvik virtual machine.

File permissions

Two mechanisms are used to enforce file access permissions:

1. Linux file permissions These provide discretionary access control, allowing the owner (and root) to change permissions to allow others access to the files. With this mechanism, an app can decide to share a data file.

2. SELinux mandatory access control Certain data and cache directories in Android are protected with the SELinux (Security-Enhanced Linux) mandatory access control (MAC) kernel extension. This ensures that even the owner cannot change access permissions for the files.

Internal storage provides a per-app private directory for files used by each application. External storage (e.g., attached microSD cards or USB devices) is shared among all apps and, of course, may be moved to other computers.

–>

Exploit prevention

Android applications benefit from several built-in security mechanisms designed to protect against common exploits such as buffer overflows and unauthorized code execution. Here are some of the key protections:

Stack Canaries

Stack canaries are used to detect and prevent stack buffer overflow attacks. A canary is a known value placed in memory right before the stack return pointer. The idea is that most buffer overflows will alter this canary before reaching the return pointer, altering the flow of execution. If, upon function return, the canary’s value has changed, the system recognizes this as an attack and can take appropriate action, such as terminating the app.

Heap Overflow Protections

Android uses several mechanisms to prevent heap overflow, a common exploit where attackers corrupt memory to manipulate the application’s execution. One method is checking backward and forward pointers in the heap’s data structures. If these pointers are found to be corrupted, indicating a possible heap overflow, the system can halt the operation to prevent further damage.

ASLR (Address Space Layout Randomization)

ASLR is used in Android to randomly arrange the address space positions of key data areas of a process, including the base of the executable and the positions of the stack, heap, and libraries. This randomness makes it significantly more difficult for attackers to predict the memory address locations needed for exploits such as buffer overflows.

NX (No-Execute) Hardware Protection

The NX bit is a hardware-based security feature that marks certain areas of memory as non-executable. This means that any code residing in these areas cannot be executed, regardless of the application’s intent. In Android, the NX bit is used to prevent execution of code from areas traditionally used for data, such as the stack and heap. This protection is crucial for mitigating the risk of executable code injections, a tactic often used in various exploits.

iOS security

iOS Secure Boot Process

The iOS secure boot process is a fundamental aspect of the operating system’s security architecture. It ensures that each stage of the boot up is secure and verified, protecting the device from unauthorized modifications. Here’s a step-by-step overview:

Boot ROM

This is the first significant step in the iOS secure boot chain. The Boot ROM is permanently ingrained into the device during manufacturing. It contains Apple’s Root CA certificate, used to verify the entire boot chain. The integrity of the Boot ROM is crucial as it begins the trusted boot process.

Low-Level Bootloader (LLB)

The Boot ROM loads and verifies the Low-Level Bootloader using the public key in the Boot ROM. LLB is primarily responsible for initializing hardware and loading the next stage in the boot process. It performs a signature check on the firmware’s next stage before executing it.

iBoot

After LLB, the iBoot bootloader is loaded. iBoot functions as the second stage bootloader, handling the recovery mode and ensuring that the kernel and main firmware are correctly signed by Apple before allowing them to be loaded. It checks for the authenticity and integrity of the firmware and provides the command interface for recovery and diagnostics.

Operating System Kernel

Once iBoot verifies the kernel’s signature, it loads the iOS kernel. This is where the operating system begins to load, and higher-level functions are initialized. The kernel ensures that all further applications and processes that are loaded are properly signed and validated.

Encrypted file system

The encrypted file system in iOS is a cornerstone of Apple’s approach to securing user data stored on devices. Here’s a breakdown of how it works:

Data Protection Classes
iOS uses several data protection classes to control when data can be accessed:

• Class A: This class protects user data until the device is unlocked. Once unlocked, the data becomes accessible.
• Class B: This protects user data with a key that gets wiped from memory when the device is locked, making it accessible only when it is unlocked.
• Class C: This class protects data with a key that is always accessible, regardless of whether the device is locked or unlocked.
• Class D: No encryption keys are used, and the data is accessible whenever the device is powered on.

Encryption Keys Each file stored on an iOS device is encrypted with its own unique key, which is then encrypted with a class key and stored in the file’s metadata. The class keys are tied to the user’s passcode and are entangled with the device’s unique ID (UID), enhancing security by ensuring that data cannot be decrypted without the device-specific information.

File System Encryption The entire file system is encrypted using AES encryption, with keys managed by the Secure Enclave (a secure coprocessor, which we’ll discuss soon). This means that even at the hardware level, the data remains secure, providing a significant barrier against unauthorized access, even if an attacker gains physical access to the device.

iOS app sandbox

iOS and Android both offer robust security models designed to protect apps and their data, but they approach this with different methodologies and structures.

The iOS app sandbox is a strict and mandatory security environment for all apps on the platform. Here’s how it secures apps:

• Isolation: Each app is confined to its own kernel-level sandbox, an isolated data and code execution environment. This prevents apps from accessing data from other apps unless explicitly allowed via entitlements and specific APIs.
• Limited Permissions: iOS apps are granted limited system resources and have to declare any additional permissions in the app’s property list file (Info.plist). The system enforces these permissions at runtime.
• Data Protection: The sandbox uses encryption to protect all data written by the app by default, tied to the user’s passcode for enhanced security.

Android’s security model shares some similarities with iOS but also has distinct features:

• Permissions System: Android apps must request permissions which are presented to the user at runtime.
• App Isolation: Android also isolates apps by running them each in a separate Linux user account. Each app is given its own VM and runtime environment, which limits direct app-to-app interactions unless specifically permitted through user-granted permissions.

Web apps

Both iOS and Android have full web browsers that can be used to access web applications. They also permit web apps to appear as a regular app icon. The risks here are the same as those for web browsers in general: loading untrusted content and leaking cookies and URLs to foreign apps.

Mobile-focused web-based attacks can take advantage of the sensors on phones. The HTML5 Geolocation API allows JavaScript to find your location. A Use Current Location permission dialog appears, so the attacker has to hope the user will approve but there the attacker can provide incentives via a Trojan horse approach: provide a service that may legitimately need your location.

Recently, a proof of concept web attack showed how JavaScript could access the phone’s accelerometers to detect movements of the phone as a user enters a PIN. The team that implemented this achieved a 100% success rate of recognizing a four-digit PIN within five attempts of a user entering it. Apple patched this specific vulnerability but there may be more undiscovered ones.

Trusted Execution Environment (TEE) and Apple’s Secure Enclave

A Trusted Execution Environment (TEE) is a secure area within a main processor that ensures sensitive data is stored, processed, and protected in an environment isolated from the operating system. TEE provides a higher level of security than typical mobile operating environments can offer, guarding against software attacks and providing a controlled execution space for sensitive operations like cryptographic key management, authentication, and secure payments.

ARM TrustZone

ARM TrustZone technology an implementation of a TEE on ARM processors, providing hardware isolation between secure and non-secure worlds:

• Secure World: Operates highly sensitive code and data that must be kept isolated from the rest of the device.
• Normal World: Handles the regular operating system and apps.

This architecture allows devices to perform critical security functions isolated from the main operating system, which can be vulnerable to attacks.

In Android devices, the TEE is used for a variety of purposes, including:

• Device Encryption: Managing the keys and processes involved in device encryption and decryption.
• User Authentication: Handling fingerprint and facial recognition data processing.
• Secure Payments: Facilitating secure transactions for mobile payment applications.

Android leverages TrustZone to protect these operations by ensuring they are executed in a secure environment, inaccessible to potentially malicious apps or breaches.

Apple’s Secure Enclave and Its Differences from TrustZone

Apple’s implementation, known as the Secure Enclave Processor (SEP), is similar to TrustZone but with some key differences:

• Custom Silicon: While TrustZone is a set technology available to many ARM licensees, SEP is a proprietary technology developed specifically by Apple.
• Increased Isolation: SEP operates independently of the application processor, providing an additional layer of security.

Apple uses the Secure Enclave for several critical functions:

• Data Protection: Keys for Data Encryption at rest and securing sensitive user information.
• Touch ID and Face ID: Processing and protecting fingerprint and facial recognition data.
• Apple Pay: Ensuring that payment processing is secure and isolated from other OS operations.

The Secure Enclave is central to maintaining the integrity and security of user data across various applications on Apple devices.