Google publishes crypto mandate for Android 6.0

Ad giant tries again ... on devices with enough memory and AES acceleration, anyhow

Google's put the issue of mandatory Android encryption back on the table, publishing a compatibility document that mandates it (with caveats) in Android 6.0 Marshmallow.

First noticed by Android Police, the Android Compatibility Definition seeks to mandate that devices with enough memory and processor power encrypt both private and shared storage – the /data and /sdcard partitions.

The Chocolate Factory first tried this in Android 5.0, but earlier this year had to backtrack and put the idea in the too-hard basket.

The problem then was that Android lacked the AES drivers to access on-chip encryption acceleration, which meant its mandate could only be met with slow software-only encryption.

Now, it seems, there's enough silicon support for Google to try the mandate again, as this bit of Google reasoning explains:

If the device implementation supports a secure lock screen reporting "true" for KeyguardManager.isDeviceSecure() [Resources, 131], and is not a device with restricted memory as reported through the ActivityManager.isLowRamDevice() method, then the device MUST support fulldisk encryption [Resources, 132] of the application private data (/data partition), as well as the application shared storage partition (/sdcard partition) if it is a permanent, non-removable part of the device.

There's a bit more wriggle-room here than there was in last year's encryption mandate.

The old rule was that a device with a lock screen “MUST support full-disk encryption” of /datapartition and /sdcard. Now, devices with limited memory are allowed to skip encryption, and the mandate only extends to kit where hardware acceleration is available:

“For device implementations supporting full-disk encryption and with Advanced Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk encryption MUST be enabled by default at the time the user has completed the out-of-box setup experience” (emphasis added).

If the user doesn't set a lock-screen, the encryption will be secured with a default passcode, so that if you change your mind and create a lock-screen later, the data will already be encrypted and only the key will change. ®

Similar topics

Other stories you might like

Biting the hand that feeds IT © 1998–2021