Android security: Features provided by AOSP

Now that over 3 billion Android devices exist in the world, any severe Android OS security flaw would prove catastrophic. Naturally, Android security has been front-of-mind for developers of the Android Open Source Project (AOSP) since Day One. 

Similar to any other operating system, Android device security hasn’t been perfect from the beginning, yet it continues to improve with each new release. For example, one of the biggest security issues in Android OS existed in versions below Android 4.4, which reportedly affected 99% of Android devices. It was called the “Master Key Vulnerability” and allowed hackers to alter an Android APK’s code without invalidating the APK’s cryptographic signature. 

Another example is that one of the security features of Android OS added in version 5.1.1 addresses a bug called the “Stagefright vulnerability,” where specially crafted MMSes would allow remote code execution to bypass the inbuilt Android security. 

Similarly, other Android OS security enhancements have been added to each subsequent release. 

It’s relatively safe to say that the latest version of Android provides the most Android security features of any earlier version. However, that doesn’t guarantee that new flaws won’t be discovered. Even though Android security is now arguably better than ever, it’s important to continue to follow basic security best practices, especially for custom devices that use modified versions of Android. 

Source: neotam / Pixabay

How do I manage security on Android?

Android implements sophisticated security features at the hardware, operating system, user, and network level. Additionally, you can help keep your device secure by following security best practices, such as ensuring your device has a screen lock and that you only install apps from trusted sources. 

Hardware-backed Android security features

Android leverages underlying hardware features to bolster Android security. These Android security features are incredibly extensive, and it would be impossible to cover them all in-depth here. However, we’ll summarize key implementations to give you an idea of how Android device security occurs at the hardware level. 

Trusted Execution Environment (TEE)

The TEE is a segregated area of the CPU that runs code in a “virtualized,” isolated environment. 

Android security leverages the TEE by running many confidential operations inside it, such as device unlocking procedures, digital rights management (DRM), and encryption/decryption tasks. 

A TEE actually runs a mini operating system (TEE OS) with mini-apps that communicate with Android to provide sensitive Android security functionality. The architecture itself isolates the Android Linux Kernel from apps that run on the TEE. For encryption tasks, the Android OS only sees the encrypted or decrypted data, whereas the encryption/decryption itself occurs inside the TEE. 

The default Android TEE OS is called Trusty. 

The crucial point to understand here is that not even Android has access to any private keys stored at this hardware level. In most cases, not even Trusty has access to extract them. It all happens at the hardware level.

Verified boot

Android’s verified boot (AVB) feature—added in Android 4.4—ensures that only verified, trusted code runs during the boot procedure. Verified means “signed with the vendor’s private key.”

Verified boot establishes a chain of trust, beginning from a hardware-protected root of trust up through the bootloader and partitions, ensuring that system files and partitions haven’t been tampered with. The system verifies each earlier point of the chain and only proceeds to the next point when the verification succeeds. 

This Android security measure ensures that, when your Android version runs, it’s the same Android version you installed and not one that has been tampered with.

Anti-rollback protection (version binding)

Anti-rollback protection is an Android security feature that prevents devices from installing older, more vulnerable versions of Android. Even if a hacker obtains physical access to a device, the hardware prevents that hacker from installing an older version of Android once it’s been upgraded to a newer one. 

If this rollback protection wasn’t in place, hackers would be able to install earlier versions that are still signed by the manufacturer, thereby allowing the modified system to pass AVB checks. However, with rollback protection, this is impossible.

Key decryption on unlocked devices

As of Android 9, the hardware-assisted unlockedDeviceRequired flag sets whether the screen must be unlocked to access the Keystore before allowing a specified key to be used. 

These keys can be used to encrypt sensitive on-disk data. Ensuring the device must be unlocked to access the data means that Android security remains strong even for lost devices. 

Gatekeeper

Gatekeeper is a subsystem in Android security that performs authentication of patterns and passwords in the TEE. Gatekeeper enrolls and verifies hashed passwords using a hardware-backed security key. 

Gatekeeper also enforces rate-limiting to prevent password-guessing.

Protected confirmation

Android 9 beefed up hardware-driven Android security by leveraging a hardware-protected user interface (Trusted UI) for critical transactions, such as when confirming a payment. 

When an app invokes Protected Confirmation, it passes control to the Trusted UI, which displays the transaction information and obtains the confirmation. When the user confirms the action, the intent is authenticated cryptographically and conveyed in a tamper-proof manner to the relying party. 

Memory safety

Android security features have taken into account the risks associated with C and C++. For example, Android uses the Hardware-assisted AddressSanitizer error-detection tool to help spot memory bugs before they make it onto live Android releases. 

One of the major Android 12 security features is that Android 12 introduced Android’s preference for Rust instead of C/C++ for platform development. Rust provides similar performance levels to C and C++ while maintaining memory and thread safety—which is a massive step forward in Android security. 

Android security settings for the operating system

Android security at the operating system level is incredibly extensive. This level of Android security sits underneath network, data, and application security, making it fundamental to the overall security of the device. 

According to the latest Android security paper, Android security at the OS level falls under three major categories:

Sandboxing

Android uses various sophisticated OS-level sandboxing techniques to ensure that processes run in their own userspace and don’t have access to core internals. Some of these sandboxing features include:

• SELinux (Security-Enhanced Linux): Enforces mandatory access control (MAC) on all processes, even root processes. MAC differs from discretionary control in that it’s the OS itself that enforces access, not the user. 

• Seccomp (Secure Computing) Berkeley Packet Filter: This Android security technology applies at the kernel level and allows for creating sandboxes that define in which context a process is allowed to make system calls. 

• Unix-style permissions: Finally, Android security implements Unix/Linux permissions to isolate the resources of applications. Each application has a UID that runs in its own process. Apps can’t access files and resources belonging to other apps. 

Anti-exploitation

Eighty-six percent of Android vulnerabilities since 2016 have been memory-related. Most of those vulnerabilities get exploited by hackers changing a binary’s control flow. 

Android implements a mechanism called Control Flow Integrity to help prevent these kinds of abuses. 

Android security for anti-exploitation also includes compiler optimizations to check for integer overflows, which can lead to memory corruption. Additionally, other compiler-based mitigations reduce potentially exploitable bugs. In many cases, the Android compiler directs the runtime to abort a process if it detects anomalous behavior. 

Since Android 11, Android security has included Scudo, a memory allocator that helps prevent commonly exploitable memory bugs, such as mistakenly accessing memory once it’s been freed, or freeing the same memory twice. When Scudo detects heap corruption or suspicious behavior, it aborts the process. 

User data and privacy

Android security includes extensive support for user-level privacy and data protection. 

Android limits access to device sensors when an app is running in the background, and devices running Android 9 and above implement more permissions related to phone calls and the phone state. 

Android Work Profile allows users to create separate profiles for work-related data so that any personal data can’t be accessed by corporate IT teams. 

When an Android device isn’t connected to a network, it sends random MAC addresses when probing for new networks. Starting from Android 10, the device uses a randomized MAC address for both probed and connected networks. Android security in Android 10 also blocked access to device identifiers and serial numbers except for system apps. 

Other user privacy controls include:

• App permissions: Android security implements runtime permission checks, alerting the user when an app needs a specific permission, which the user can approve or deny. 

• Location control: Users have control over how often an app can access location data. One of the Android 12 security features includes the ability of users to grant only approximate location access instead of precision access. 

• Device logs only accessible “per-use”: One of the Android 13 security features is to deny persistent access to log data. As of Android 13, users must approve any time an app requests access to a log. 

• Mic and video recording: Users must explicitly allow an app to record through the mic or camera. Users can also toggle this permission off completely in the Android security settings. 

Android security updates

The matter of Android security is even more important when dealing with custom Android ROMs developed by third parties. Unlike emteria’s custom Android ROMs, many custom ROMs don’t provide Over-the-Air software updates or FOTA updates, meaning that any newly discovered vulnerabilities don’t get patched easily. 

Android security updates are crucial for maintaining device security and mobile security on Android. 

To learn more about emteria’s custom Android solutions, contact us to book a live demo.