Google is making a few tweaks to its tools for Android mobile developers to boost the security of their wares – an apropos announcement against the backdrop of recent security issues stemming from poor development practices.
Cryptographical changes this week for Android Keystore give developers more ways to prevent inadvertent exposure of sensitive data to other applications or to the OS, and helps keep data exfiltration at bay.
Keystore provides app developers with a set of hardware-rooted crypto-tools designed to secure user data with a key-based system. Developers can use the Keystore to define which application “secrets” are encrypted, and in what context they can be unlocked.
With the release of Android Pie, Google’s latest mobile OS, developers now have the ability to better protect sensitive information by preventing applications from decrypting keys if the user isn’t using the device.
This is done by the implementation of “keyguard-bound” cryptographic keys, which can be done for any algorithm the developer chooses. The availability of this type of key to perform data decryption is tied directly to the screen-lock state; so, the keys become unavailable as soon as the device is locked, and are only made available again when the user unlocks the device.
“There are times when a mobile application receives data but doesn’t need to immediately access it if the user is not currently using the device,” Google Play researchers said in a posting on Wednesday. “[Now] when the screen is locked, these keys can be used in encryption or verification operations, but are unavailable for decryption or signing. If the device is currently locked with a PIN, pattern or password, any attempt to use these keys will result in an invalid operation.”
This keyguard binding is enforced by the operating system, (since secure hardware has no way to know when the screen is locked), and works as an additional layer to existing hardware-enforced Android Keystore protection features.
Another new feature dubbed Secure Key Import protects sensitive data from being seen by the application or operating system – a timely change given the system broadcast vulnerabilities reported earlier this fall.
From a technical standpoint, when a remote server encrypts a secure key using a public wrapping key from the user’s device, Secure Key Import allows it to also contain a description of the ways the imported key is allowed to be used, and it ensures that a key can only be decrypted in the Keystore hardware belonging to the specific device that generated the wrapping key.
Because the keys are encrypted in transit and remain opaque to the application and operating system, this prevents them from intercepted or extracted from memory and then used to steal data.
Android Developers in the Hot Seat
Making additional measures available to developers to help them lock down their applications to prevent data leaking or the possibility of data exfiltration is timely; Android developers have been in the hot seat over sloppy data sequestration practices of late.
More specifically, in the last few months, several possibilities for taking advantage of cross-process information leakage came to light.
One main problem area for developers has to do with inter-process communication. While applications on Android are usually segregated by the OS from each other and from the OS itself, there are still mechanisms for sharing information between them when needed. One of those mechanisms is the use of what Android calls “intents.”
An application or the OS itself can send an “intent” message out, which is broadcast system-wide and can be listened to by other applications. Without proper access restrictions and permissions put in place around these intents, it’s possible for malicious applications to intercept information that it shouldn’t have access to. This “API-breaking” issue was shown to open the door to a range of nefarious activity, including rogue location tracking and local WiFi network attacks.
Another cross-process problem was revealed at DEFCON, where researchers demonstrated that sloppy Android developers not following security guidelines for external storage could allow an attacker to corrupt data, steal sensitive information or even take control of a mobile phone.
Android’s external storage mechanism is shared across the OS, because it’s designed to enable apps to transfer data from one app to another. So, if a user takes a picture and then wants to send it to someone using a messaging app, the external storage is the platform that allows this to happen.
If developers don’t lock down the type of data that goes to external storage, a bad actor could hijack the communications between privileged apps and the device disk, bypassing sandbox protections to gain access to app functions and potentially wreak havoc. This was dubbed the “man in the disk” issue and was quickly found to affect a range of apps, including Fortnite’s Android app.
