Google released Android version 4.4 (a.k.a. KitKat) at the end of October. The many changes include some nice security improvements.
In Learning Tree’s Cloud Security Essentials course we talk about the need for mobile device security. With Saas (or Software as a Service) offerings, you have no control over what happens with your data on the cloud provider’s server. You don’t even get to see any details of what they’re doing. But don’t forget that you access that cloud service through a platform that is under your control.
Symantec’s “2012 State of Information Report” found that 14% of data is stored on smartphones and tablets, and 28% is accessed from mobile platforms. That’s the world-wide average, these percentages are much higher in some countries and they will continue to climb.
So, mobile device security improvements will always be welcome! What new security features are in Android 4.4?
Digital certificate handling is one area. The user will be warned if something tries to add a Certificate Authority or CA, providing clear warnings of some man-in-the-middle attacks attempted within trusted networks. Also, Certificate Pinning for Google certificates will make what is a sophisticated attack even harder when attempting to intercept communication with Google-based cloud services.
SELinux features provide other security improvements. The previous release of Android tested a set of SELinux policies. Android 4.4 runs in enforcing mode, meaning that the kernel absolutely enforces a security policy that can take privileges away even from processes owned by root.
With all the furor caused by the Snowden revelations, I’m sure that some people will worry that SELinux could include back doors. It was developed by the NSA, after all. But to worry about that is to miss the point of SELinux.
SELinux provides a second and more rigorous line of defense. The traditional UNIX features of process credentials, object ownership, and file system permissions are considered first. If that can deny an action, it does — the process is unable to open the object in the desired mode and that’s that. If the traditional permission scheme would have allowed it, then the much more complicated SELinux mechanisms are used. It gives the kernel a second opportunity to deny things.
Dm-verity is another kernel feature that could provide some security. It uses a read-only public key burned into the device by the OEM to verify the digital signatures of the bootloader and the kernel. This will hinder your ability to replace your device’s OS with an alternative like Cyanogenmod, and I suspect it will be favored by the OEMs mainly for providing vendor lock-in.
These operating system features can be nice tools, but they must be used correctly. SELinux policy construction is notoriously difficult. Additionally, providers prefer that their customers upgrade their hardware frequently. It is not in their economic interest to support operating system upgrades for older but still functional and adequately capable hardware.
It will be interesting to see if any mobile providers work to get a reputation as supporting security provided by OS tools!