Every new Android version comes with at least some security improvements. This time, it seems the new version, Android P, has gotten a few more than usual, from allowing users to encrypt their backups locally before uploading to the cloud to encrypting all third-party app traffic with HTTPS.
Client-Side Encryption Of Cloud Backups
Android P will allow users to encrypt their backups with their own PIN, pattern, or password, before those backups are uploaded to Google’s cloud. Normally, you wouldn’t want data stored in the cloud to be protected by a PIN or pattern because those types of codes are weak and can be easily bruteforced.
On the phone, PIN codes are accompanied by other features that limit how many tries someone can attempt before unlocking the device and drastically delaying any bruteforce attempts. Google will make use of its new Key Vault Service, which stores the cryptographic keys on secure hardware that has been designed to prevent bruteforce attacks by permanently destroying the keys when there are too many failed attempts to decrypt the users’ backups.
Hardware Security Module
Back in 2015, Google promised us “Project Vault,” which aimed to turn a microSD card into a miniature Hardware Security Module (HSM) - a device that stores and processes cryptographic keys, typically used in the enterprise space or by cloud service providers. The project could have democratized strong security for Android devices. However, this project seemed to have hit a dead-end when, soon after the announcement, its project leader quit Google.
Google seems to have transformed the project into a type of “secure enclave” on steroids that will be built into the phone - at least the phones of OEMs willing to adopt it. The HSM comes with a CPU, secure storage, a true random-number generator, and other mechanisms to resist tampering and unauthorized sideloading of apps.
The HSM will support cryptographic algorithms such as:
RSA 2048AES 128 and 256ECDSA P-256HMAC-SHA256 (supports key sizes between 8 bytes and 64 bytes, inclusive)Triple DES 168
Option To Allow Decryption Only On Unlocked Devices
Android P introduces the unlockedDeviceRequired flag, which users can set so that the device cannot be decrypted unless the screen is also unlocked. Presumably Google has learned that its devices could be decrypted even when the screen is locked, which would allow malicious parties to steal data from a stolen device.
Even though this feature should probably target everyone, the fact that it’s a flag that you have to set to “true” for it to be enabled and not just enable a checkbox in the Security settings means that Google doesn’t yet believe this is a feature everyone should use. Google also said that the primary users of such a feature could be enterprise customers or those in the healthcare industry.
Secure Key Import Into Keystore
Google will also allow developers to import encrypted keys into the Keystore (a file containing encryption keys) securely, without the device’s memory being able to read the contents of that key when the key is used to decrypt data.
This new feature should secure encrypted keys used by third-party apps that use HTTPS encryption or other forms of public key cryptography where the private key needs to be stored locally.
Android Protected Confirmation
Third-party developers will be able to use the “Protected Confirmation API,” which is a secure channel through which a prompt will be sent to the user’s phone to ask them to approve or reject a sensitive transaction, such as making a payment.
If the user approves the transaction, then the app will receive a cryptographic signature that's protected by a keyed-hash message authentication code (HMAC). This signature indicates with high confidence that the user has actually seen and approved the transaction. The phone’s Trusted Execution Environment (TEE) will protect the confirmation dialog and the user input, making it difficult for malware to hijack it.
Wi-Fi Mac Randomization
Google also seems to be among the last to bring Wi-Fi MAC address randomization to its users’ phones, as iOS and Windows 10 already support it. Technically, Android 5.0 started supporting it a few years back, but it seems to be deeply flawed and also disabled on most devices.
Android P promises to change that by creating a new MAC address for each Wi-Fi network to which you connect, thus making it difficult for others to track you across different places that you’ve visited.
HTTPS For Apps Enabled By Default
In Android 8.0, Google gave developers the option to enable HTTPS and restrict HTTP traffic, but it wasn’t mandatory. In Android P, third-party developers will have to enable HTTPS by default for their apps, but they can still specify certain domains that can continue to deliver unencrypted traffic.
Other Security Features
Android P will provide a standardized “BiometricPrompt” for apps, which means users can now trust the fingerprint prompts coming from apps more, too.
Google also provided developers with a new APK Signature Scheme (v3) that allows them to rotate their signature keys.
Android P will also support DNS over TLS, which means fewer opportunities for your ISPs and carriers to collect your data when using a DNS service such as Google’s 8.8.8.8 or Cloudflare’s (more privacy-friendly) 1.1.1.1.
As we recently learned, Android P will also restrict apps from monitoring users’ network activity without using the VPNService API and without explicit consent from the users.
Another P will no longer let apps secretly use the microphone or camera and the users will be shown a notification when apps do that in the background. This is one of those features that should have probably been there from day one, or at least it should have arrived much earlier.
All in all, Android P seems to arrive with significant security enhancements, but it remains to be seen if Apple, which prides itself on its security and privacy stance, will one-up Google with its next version of iOS.
