Security in Android Q: Everything Google added to make your phone safer - XDA Developers

Posted: 17 May 2019 12:00 AM PDT

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.

Encryption

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.

Adiantum

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.

TLS 1.3

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 1.3 in Google Chrome. Source: Google.

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

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.

Like CopperheadOS, stock Android Q now lets the user disable all requested dangerous permissions before running an app for the first time. This only applies to apps targeting API level 22 or below, which is before runtime permissions were introduced (in Android Marshmallow.)

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

New location permission options

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.

Roles

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

Sensors 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

: Randomized MAC address

: Randomized MAC address

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.

A constrained sandbox for software codecs. Source: Google.

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.

Authentication

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.

BiometricPrompt API implicit and explicit flow. Source: Google.

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.

Conclusion

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.

XDA » Full XDA » Security in Android Q: Everything Google added to make your phone safer

What if the FBI tried to crack an Android phone? We attacked one to find out - The Conversation US

Posted: 29 Mar 2016 12:00 AM PDT

The Justice Department has managed to unlock an iPhone 5c used by the gunman Syed Rizwan Farook, who with his wife killed 14 people in San Bernardino, California, last December. The high-profile case has pitted federal law enforcement agencies against Apple, which fought a legal order to work around its passcode security feature to give law enforcement access to the phone's data. The FBI said it relied on a third party to crack the phone's encrypted data, raising questions about iPhone security and whether federal agencies should disclose their method.

But what if the device had been running Android? Would the same technical and legal drama have played out?

We are Android users and researchers, and the first thing we did when the FBI-Apple dispute hit popular media was read Android's Full Disk Encryption documentation.

We attempted to replicate what the FBI had wanted to do on an Android phone and found some useful results. Beyond the fact the Android ecosystem involves more companies, we discovered some technical differences, including a way to remotely update and therefore unlock encryption keys, something the FBI was not able to do for the iPhone 5c on its own.

The easy ways in

Data encryption on smartphones involves a key that the phone creates by combining 1) a user's unlock code, if any (often a four- to six-digit passcode), and 2) a long, complicated number specific to the individual device being used. Attackers can try to crack either the key directly – which is very hard – or combinations of the passcode and device-specific number, which is hidden and roughly equally difficult to guess.

Decoding this strong encryption can be very difficult. But sometimes getting access to encrypted data from a phone doesn't involve any code-breaking at all. Here's how:

A custom app could be installed on a target phone to extract information. In March 2011, Google remotely installed a program that cleaned up phones infected by malicious software. It is unclear if Android still allows this.
Many applications use Android's Backup API. The information that is backed up, and thereby accessible from the backup site directly, depends on which applications are installed on the phone.
If the target data are stored on a removable SD card, it may be unencrypted. Only the most recent versions of Android allow the user to encrypt an entire removable SD card; not all apps encrypt data stored on an SD card.
Some phones have fingerprint readers, which can be unlocked with an image of the phone owner's fingerprint.
Some people have modified their phones' operating systems to give them "root" privileges – access to the device's data beyond what is allowed during normal operations – and potentially weakening security.

But if these options are not available, code-breaking is the remaining way in. In what is called a "brute force" attack, a phone can be unlocked by trying every possible encryption key (i.e., all character combinations possible) until the right one is reached and the device (or data) unlocks.

Starting the attack

A very abstract representation of the derivation of the encryption keys on Android. William Enck and Adwait Nadkarni, CC BY-ND

There are two types of brute-force attacks: offline and online. In some ways an offline attack is easier – by copying the data off the device and onto a more powerful computer, specialized software and other techniques can be used to try all different passcode combinations.

But offline attacks can also be much harder, because they require either trying every single possible encryption key, or figuring out the user's passcode and the device-specific key (the unique ID on Apple, and the hardware-bound key on newer versions of Android).

To try every potential solution to a fairly standard 128-bit AES key means trying all 100 undecillion (10³⁸) potential solutions – enough to take a supercomputer more than a billion billion years.

Guessing the passcode could be relatively quick: for a six-digit PIN with only numbers, that's just a million options. If letters and special symbols like "$" and "#" are allowed, there would be more options, but still only in the hundreds of billions. However, guessing the device-specific key would likely be just as hard as guessing the encryption key.

Considering an online attack

That leaves the online attack, which happens directly on the phone. With the device-specific key readily available to the operating system, this reduces the task to the much smaller burden of trying only all potential passcodes.

However, the phone itself can be configured to resist online attacks. For example, the phone can insert a time delay between a failed passcode guess and allowing another attempt, or even delete the data after a certain number of failed attempts.

Apple's iOS has both of these capabilities, automatically introducing increasingly long delays after each failure, and, at a user's option, wiping the device after 10 passcode failures.

Attacking an Android phone

What happens when one tries to crack into a locked Android phone? Different manufacturers set up their Android devices differently; Nexus phones run Google's standard Android configuration. We used a Nexus 4 device running stock Android 5.1.1 and full disk encryption enabled.

Android adds 30-second delays after every five failed attempts; snapshot of the 40th attempt. William Enck and Adwait Nadkarni, CC BY-ND

We started with a phone that was already running but had a locked screen. Android allows PINs, passwords and pattern-based locking, in which a user must connect a series of dots in the correct sequence to unlock the phone; we conducted this test with each type. We had manually assigned the actual passcode on the phone, but our unlocking attempts were randomly generated.

After five failed passcode attempts, Android imposed a 30-second delay before allowing another try. Unlike the iPhone, the delays did not get longer with subsequent failures; over 40 attempts, we encountered only a 30-second delay after every five failures. The phone kept count of how many successive attempts had failed, but did not wipe the data. (Android phones from other manufacturers may insert increasing delays similar to iOS.)

These delays impose a significant time penalty on an attacker. Brute-forcing a six-digit PIN (one million combinations) could incur a worst-case delay of just more than 69 days. If the passcode were six characters, even using only lowercase letters, the worst-case delay would be more than 58 years.

When we repeated the attack on a phone that had been turned off and was just starting up, we were asked to reboot the device after 10 failed attempts. After 20 failed attempts and two reboots, Android started a countdown of the failed attempts that would trigger a device wipe. We continued our attack, and at the 30th attempt – as warned on the screen and in the Android documentation – the device performed a "factory reset," wiping all user data.

Just one attempt remaining before the device wipes its data. William Enck and Adwait Nadkarni, CC BY-ND

In contrast to offline attacks, there is a difference between Android and iOS for online brute force attacks. In iOS, both the lock screen and boot process can wipe the user data after a fixed number of failed attempts, but only if the user explicitly enables this. In Android, the boot process always wipes the user data after a fixed number of failed attempts. However, our Nexus 4 device did not allow us to set a limit for lock screen failures. That said, both Android and iOS have options for remote management, which, if enabled, can wipe data after a certain number of failed attempts.

Using special tools

The iPhone 5c in the San Bernardino case is owned by the employer of one of the shooters, and has mobile device management (MDM) software installed that lets the company track it and perform other functions on the phone by remote control. Such an MDM app is usually installed as a "Device Administrator" application on an Android phone, and set up using the "Apple Configurator" tool for iOS.

Our test MDM successfully resets the password. Then, the scrypt key derivation function (KDF) is used to generate the new key encryption key (KEK). William Enck and Adwait Nadkarni, CC BY-ND

We built our own MDM application for our Android phone, and verified that the passcode can be reset without the user's explicit consent; this also updated the phone's encryption keys. We could then use the new passcode to unlock the phone from the lock screen and at boot time. (For this attack to work remotely, the phone must be on and have Internet connectivity, and the MDM application must already be programmed to reset the passcode on command from a remote MDM server.)

Figuring out where to get additional help

If an attacker needed help from a phone manufacturer or software company, Android presents a more diverse landscape.

Generally, operating system software is signed with a digital code that proves it is genuine, and which the phone requires before actually installing it. Only the company with the correct digital code can create an update to the operating system software – which might include a "back door" or other entry point for an attacker who had secured the company's assistance. For any iPhone, that's Apple. But many companies build and sell Android phones.

Google, the primary developer of the Android operating system, signs the updates for its flagship Nexus devices. Samsung signs for its devices. Cellular carriers (such as AT&T or Verizon) may also sign. And many users install a custom version of Android (such as Cyanogenmod). The company or companies that sign the software would be the ones the FBI needed to persuade – or compel – to write software allowing a way in.

Comparing iOS and Android

Overall, devices running the most recent versions of iOS and Android are comparably protected against offline attacks, when configured correctly by both the phone manufacturer and the end user. Older versions may be more vulnerable; one system could be cracked in less than 10 seconds. Additionally, configuration and software flaws by phone manufacturers may also compromise security of both Android and iOS devices.

But we found differences for online attacks, based on user and remote management configuration: Android has a more secure default for online attacks at start-up, but our Nexus 4 did not allow the user to set a maximum number of failed attempts from the lock screen (other devices may vary). Devices running iOS have both of these capabilities, but a user must enable them manually in advance.

Android security may also be weakened by remote control software, depending on the software used. Though the FBI was unable to gain access to the iPhone 5c by resetting the password this way, we were successful with a similar attack on our Android device.

This article was updated April 8, 2016, to add a missing word "not" in the sentence beginning "The phone kept count…"

Search This Blog

Android Full Encryption