When talking about the benefits of the Android platform, most users usually cite customizability, device diversity, and flexible pricing. And for some reason there is no question of safety. Apparently, most simply don't think Android is safe. The biggest reason may be that the Google Play Store is an open marketplace: it is much easier to upload malware there than in the Apple AppStore. And it did happen. Repeatedly.
This is a real problem. But it is connected with the insufficiently strict policy of Google on the platform. Although it seems to be gradually changing. In any case, you should always remember which software should be trusted and which should not. On any platform.
Recently I was looking for a new phone and at the same time decided to find out what the level of security of the Android platform is now and which phone is the most secure. It turns out that Android has a pretty good security model.
First of all, the device manufacturer must ensure that its Android OS phone complies with the Android Compatibility Definition Document (CDD). If the device does not meet the hardware requirements, it will not be able to work with this OS. If a vendor changes the Android system and thereby violates the CDD, then that system can no longer be called “Android”. Therefore, if you buy a device and it is explicitly stated that it runs Android, it means that CDD compatibility is guaranteed.
CDD guarantees security
CDD for Android 10 has a whole section dedicated to security. This document is huge and links to many other huge documents. I will try to formulate it as briefly as possible.
The permission system must comply with the Android security reference. It covers issues such as the ability to revoke permissions after they have been granted, how permission requests work, what permissions can only be granted to system applications, and more.
The sandbox must be organized correctly. Details are described in this document. Essentially, each application has a unique UNIX user ID and directories that are owned by that and only that user. Since Android does not have a root user, other applications cannot access the data stored in these directories. Therefore, introducing root into the system would violate the security model. This is why we will never see an Android phone that is rooted by default. Apart from all this, there are also SELinux policies to enforce access control.
Thus, SELinux Mandatory Access Controls (MACs) should provide an isolated environment for kernel applications. Mandatory access control policies allow you to set and enforce restrictions. They cannot be changed or overwritten by any user and therefore, it is practically beyond the power of malware.
Encryption
CDD also requires the / data and / sdcard partitions of the on-board storage to be encrypted out of the box. The / data section contains personal data for each application. The / sdcard section is a general purpose storage: there, for example, your photos and documents are stored.
Therefore, if the device is turned off, and it falls into the hands of someone in this state, it will be almost impossible to retrieve data from the built-in storage.
Verified download
First of all, this kind of loading should also work correctly:
- All executable code must come from a trusted source (usually device manufacturers) and not from an attacker. At each stage of the download, the integrity and authenticity of the component is checked before handing over execution to it.
- In addition to the fact that devices are running a secure version of Android, the correct OS version is checked. Rollback protection helps prevent a potential exploit from being saved as devices are only updated to newer versions of Android.
Many people think that such booting only ensures device security when an attacker has physical access to the machine, and thus downplay the importance of this feature. But when it comes to mobile devices, first of all, it is precisely physical access that should be considered.
Moreover, verified loading ensures that unwanted code is not executed during or immediately after loading. This makes life difficult for any type of malware. After rebooting, we automatically remove this software if it suddenly gets into the system. For example, jailbreak exploits like checkra1n do not persist across reboots. Let me remind you that iOS also uses verified download.
Data Access Control
Encryption requires keys that must be stored somewhere. Android can use Keymaster and Strongbox to protect keys, even in case of kernel or hardware exploits (e.g. Meltdown and Spectre).
Samsung KNOX, for example, goes further: Once the boot loader, kernel, or Recovery is reset to user, and if root rights are obtained on the device, an electronic protector will be activated. Once activated, the user will no longer be able to pay for purchases through the Samsung Pay mobile payment service, and the device will lose access to data from protected directories.
Stop paying for memory errors
A recent Microsoft study found that about 70% of all vulnerabilities in Microsoft products are related to memory vulnerability. Google's research showed the same for Chrome. So, of course, there are grounds to believe that this is relevant for Android as well.
And Google's specialists decided to fix this problem. In Android 11, they used a new memory allocator, several safer ways to initialize the kernel and user space, and methods to detect memory errors in real time.
Memory errors will certainly not disappear completely, but they will probably be much smaller now.
The tip of the iceberg...
All of the above is just the tip of the iceberg. There are many more interesting details that you can learn about the security of Android-based systems. For example, the same Samsung KNOX can be written in a separate large article.
So, contrary to popular opinion, modern Android devices are quite safe.