Each new version of the Android OS brings improvements to almost every aspect from the design, features, APIs, and more. At Google I/O earlier this month we learned about all the improvements that Android Q is going to bring, and of course, new privacy and security announcements were not left out from the conference. The platform security is one of the most important aspects of an OS, particularly for an OS that we bring everywhere with us in our pockets. If Android wasn’t secure, we wouldn’t trust it with half as many functions as we do. NFC payments would be out of the question, file sharing would be dubious at best, and connecting to other devices would be downright madness. In spite of the long-standing issue of version fragmentation, Google has done extremely well to keep the number of security issues to a minimum.
Android has matured into an OS that is both feature-rich and highly secure. But there is, of course, always room for improvement. There are many contributing factors to this security, and a few of them are being improved in some way with Android Q.
Being one of the most basic security methods, it’s important that every device supports strong encryption. Many OEMs these days ship their devices with dedicated encryption hardware. While this is beneficial, it’s also expensive. As such, dedicated hardware has typically been restricted for mid to high tier devices. This is not to say that low-end devices cannot support encryption, but without hardware accelerated encryption the overall user experience is degraded because of slow read/write times. That’s where Adiantum comes in.
In February, Google announced Adiantum as an alternative encryption algorithm for lower-end phones that don’t support regular AES instruction sets. Adiantum is specifically designed to run without any dedicated hardware. It serves as a lighter alternative to Android’s regular AES encryption. Google’s benchmarks tell us that it’s actually 5x faster than AES, with the downside being that it slightly compromises on security. This makes it the ideal candidate for lower-end phones, such as those powered by Android Go Edition. Adiantum is also for products like smartwatches and a variety of Internet of Things devices.
Up until now, Adiantum was optional; manufacturers could enable it on devices launching with Android Pie, but it was not the default encryption algorithm. Now, Adiantum is included natively as part of Android Q. This means that all devices launching with Q will be required to encrypt user data, with no exceptions. As a result, devices launching with Android Q are guaranteed to have storage encryption, be it via Adiantum or not.
Jetpack Security Library
Jetpack is a set of Android support libraries, and one of the newest additions is in alpha: the Jetpack Security Library. The library simplifies the process of securing your application by handling things like the management of hardware-backed keystores and generating and validating keys.
Storage is not the only area encryption has been improved in, however. Communicating with other devices has been much improved, with the introduction of TLS 1.3 support by default. TLS 1.3 is the latest network cryptographic standard, finalized by the IETF in August of 2018. TLS 1.3 provides more privacy for data exchanges by encrypting more of the negotiation handshakes. On top of this, it’s faster than TLS 1.2 due to an entire round trip being shaved off from the connection establishment handshake. Coupled with more efficient modern algorithms this makes for an up to 40% increase in speed.
TLS is now updatable directly from Google Play because it’s part of the “Conscrypt” component. You can read more about that and Project Mainline here.
Given that we trust so many sensitive transactions on our devices daily, the upgraded TLS is more important than ever. Storing the likes of boarding passes – and even digital drivers licenses at some point in the future – on Android means that all devices should encrypt user data as best they possibly can. Adiantum and forced encryption will pave the way for even the most sensitive of data to be stored on the cheapest of devices. But encryption is not the only way Google is increasing the security of Android in the Q release.
Permissions and Privacy changes in Android Q
Scoped Storage is a new safeguard being employed to restrict apps from reading/writing files in external storage that are not contained within their own sandboxed app-specific directory. Google’s goal is three-fold: better attribution of which apps have control over which files, the protection of app data, and the protection of user data.
Google is doubling down on the MediaStore API for shared audio, video, and picture content. By default, all apps can insert, modify, or delete their own files to the MediaStore.Images, MediaStore.Video, and MediaStore.Audio collections without needing any permissions. Android Q also adds a new MediaStore.Downloads collection to store user-downloaded content, which all apps using the MediaStore API can contribute to. While files stored in sandboxed app-specific directories are deleted upon uninstallation, all files contributed to the MediaStore collections persist beyond uninstallation.
To access any files created by another app—whether the file is in one of the MediaStore collections or outside of them—the app must use the Storage Access Framework. Furthermore, EXIF metadata of images is redacted unless your app has the new ACCESS_MEDIA_LOCATION permission granted. In Android Q, apps can also control which storage device to land media on by querying its volume name using getExternalVolume().
Google initially imposed Scoped Storage restrictions on all apps in Android Q regardless of their target API levels, but after feedback, the company is giving developers more time to make adjustments. The full details on the Scoped Storage changes can be found on this page, and you can find out more about Google’s recommendations on the best practices for shared storage by watching this Google I/O talk.
Warnings for apps targeting API level < 23
Permission restrictions don’t end there, however. Installing an app which targets an API level lower than 23 (Android Lollipop or older) will cause the OS to display a warning to the user if said app requests sensitive permissions upon installation. Before installation, users will have the opportunity to manually specify which permissions they want to grant the app before proceeding. Thus, Android Q no longer allows apps to get around runtime permissions.
Eventual SYSTEM_ALERT_DEPRECATION in favor of the Bubbles API
Bubbles API in action. Source: Google.
The overlay permission (SYSTEM_ALERT_WINDOW) can no longer be granted for apps running on Android Q (Go Edition). For non-Go Edition devices, Google is pushing developers towards the new Bubbles API. Bubbles API is a feature introduced in Android Q Beta 2 which allows for functionality that’s like Facebook Messenger’s chat heads. Notifications from apps appear as little bubbles at the edges of the screen, which expand when tapped by the user. Within the bubble, an app can display an Activity.
This change was necessary because allowing apps to freely draw overlays over other apps poses obvious security risks. The infamous “Cloak and Dagger” exploit used this weakness extensively. The functionality of the overlay API has been restricted as early as Android Oreo, but now the Go edition of Android Q has fully removed access to the API with a future release to fully deprecate it.
Background Activity Launch Restrictions
Apps in the background can no longer automatically launch an Activity while the phone is unlocked, regardless of their target API level. There is a whole list of conditions under which apps can now launch activities, which you can read here. Background apps which do not meet these conditions and wish to urgently launch an activity will now have to tell the user via a notification. If the notification is created with a pending full-screen intent, then the intent is launched immediately if the screen is off—useful for alarms or incoming calls.
Background Clipboard Access Restriction
Background clipboard access is no longer possible. Any application that is not in the foreground or set as the default input method will not be able to read your clipboard in any way. This hits apps like clipboard managers especially hard. Google says that this change only affects apps that exclusively target Android Q, but our testing indicates that the restriction doesn’t discriminate; any app we tried couldn’t see the clipboard.
This change, of course, does make sense. We often copy sensitive information to the clipboard—things like passwords and credit card details—but it’s still a shame to see clipboard managers go down the drain.
Location access only while an app is in use
A new user-enabled setting only allows apps to reach your location while the app is in use. The latest Android Q beta has also added a notification reminding you if you have granted an app permanent access to the location.
A new “Roles” API has been added. Roles are essentially groups with preset permissions access. For example, apps with the gallery role might have access to your media folders, while apps with the dialer role might be able to handle calls. Apps that are granted a certain role by the user must also have the required components. Apps with the gallery role, for example, must have the action intent filter android.intent.action.MAIN and the category intent filter android.intent.category.APP_GALLERY to show up as a gallery app in settings.
Sensors Off Quick Settings tile
There is a new “Sensors off” quick settings tile which turns off readings from all sensors (accelerometer, gyroscope, etc.) on your device for true privacy. This Quick Settings tile is hidden by default but can be enabled by going to the “quick settings developer tiles” in Developer options.
Restrictions to /proc/net
Apps can no longer access proc/net, making services like netstat no longer viable. This protects users from malicious apps monitoring what websites and services they connect to. Apps that need continued access, such as VPNs, need use the NetworkStatsManager and ConnectivityManager classes.
Randomized MAC Addresses
Your MAC address is a unique identifier that networks use to remember which device is which. In Android Q, every time you connect to a new network, your device will use a new, randomized MAC address. As a result, networks can’t track your location by matching what WiFi networks you connect to with the MAC address of your phone. The device’s actual, factory MAC address can still be obtained by apps via the getWifiMacAddress() command.
Platform Hardening in Android Q
A single bug within Android does not mean that attackers now have full access to the OS or that they can bypass any security systems. This is in part due to a number of safeguards such as process isolation, attack surface reduction, architectural decomposition, and exploit mitigations. These safeguards render vulnerabilities more difficult or even impossible to exploit. As a result, attackers typically need a multitude of vulnerabilities before they can achieve their goals. In the past, we have seen attacks such as DRAMMER that work by chaining multiple exploits together.
Android Q takes safeguards such as these and applies them to more sensitive areas such as the media and Bluetooth components along with the kernel too. This brings some marked improvements.
- A constrained sandbox for software codecs.
- Increased production use of sanitizers to mitigate entire classes of vulnerabilities in components that process untrusted content.
- Shadow Call Stack, which provides backward-edge Control Flow Integrity (CFI) and complements the forward-edge protection provided by LLVM’s CFI.
- Protecting Address Space Layout Randomization (ASLR) against leaks using eXecute-Only Memory (XOM).
- Introduction of Scudo hardened allocator which makes a number of heap related vulnerabilities more difficult to exploit.
This is a lot of software jargon. The bones of it is that first, software codecs now run in sandboxes which have fewer privileges, meaning it’s less likely that malicious software will be able to run commands that could harm your device, such as in the case of StageFright way back in 2015.
Secondly, Android now checks for out-of-bounds array access in more places, as well as overflows. Preventing overflows and instructing processes to fail safely significantly decreases the percentage of userspace vulnerabilities. What this means is that if a malicious program tries to cause something to crash by deliberately attempting to get access to data that doesn’t exist, Android will now recognize this and exit the program, instead of crashing.
Thirdly, Shadow Call Stack protects return addresses by storing them in a separate shadow stack, making them inaccessible to regular programs. Return addresses are typically pointers to functions, so protecting these addresses are important to make sure that attackers cannot access functions they shouldn’t be able to.
Fourthly, ASLR is a protection method that randomizes where programs are stored in memory, making it harder to figure out where programs are being stored in memory based on the location of other programs. eXecute-only memory strengthens this by making code unreadable.
Finally, Scudo is a dynamic heap allocator which proactively manages memory in a way that makes heap-based vulnerabilities a lot harder to exploit. You can read more about it here.
Updates to BiometricPrompt in Android Q
Google introduced the new BiometricPrompt API over a year ago, in Android P Developer Preview 2. It was intended to be a generic Android prompt for biometric unlock methods. The idea is that devices which support more than just fingerprint scanning, e.g. iris scanning on Samsung’s Galaxy S line, will be able to use these methods when apps ask for verification.
Android Q adds robust support for face and fingerprint verification, as well as expanding the API to support implicit authentication. Explicit authentication requires that the user authenticates in some way before proceeding, while implicit does not need any more user interaction.
On top of that, apps can now check if a device supports biometric authentication via a simple function call, allowing them to not waste time invoking a BiometricPrompt on devices that don’t support it. An ideal use for this would be if apps want to give an “Enable biometric sign-in” setting based on whether or not a device supports biometric authentication.
The building blocks for Electronic ID support
Earlier this year, we discovered evidence that Google is working on support for electronic IDs in Android. At I/O, Google updated us on the progress of the feature. Google says they’re working with the ISO to standardize the implementation of mobile driver’s licenses, with electronic passports in the works. For developers, Google will provide a Jetpack library so identity apps can start being made.
Project Mainline in Android Q
Project Mainline is a major undertaking by Google to reduce the fragmentation of certain system modules and apps. Google will control updates for about 12 system components via the Play Store. We’ve talked about Project Mainline in-depth in a previous article if you’re interested in reading more.
Security has always been a core part of Android’s development. Google has done an impressive job of keeping Android up-to-date with the latest security features, as well as making some innovations of its own. They’re continuing this development process with Android Q, packing it full of security features which are made to make sure your data is safer than ever before.
Source 1: What’s New in Android Q Security [Google]
Source 2: Security on Android: What’s Next [Google]
Source 3: Queue the Hardening Enhancements [Google]
With input from Mishaal Rahman and Adam Conway.
Want more posts like this delivered to your inbox? Enter your email to be subscribed to our newsletter.