12 min read

The latest iteration of Google’s Android operating system brings a host of great features designed to make your phone more capable, more secure, and easier to use. Features like multi-window support, Daydream virtual reality, seamless system updates, and 3D Touch-like application shortcuts on the home screen have received well-deserved media coverage. My favorite bit of Nougaty goodness, however, seems to have only been mentioned in passing.

I’m talking (of course!) about File-Based Encryption (FBE). Like seamless system updates, this feature will only be enabled by default on devices which ship with Android 7.x pre-installed — unlike the seamless updates, though, it can also be enabled on other Nougat-upgraded devices, like my Nexus 6P. To understand why this is so cool, we’ll first need a quick recap of the state of encryption on previous Android releases. What follows is a simplified explanation to make the concepts easy to digest; you can find a more technical description here.

Encryption on Marshmallow

Google first introduced Full Disk Encryption (FDE) to protect the data stored on your phone by encrypting the entire /data partition (where all of your apps, pictures, text messages, and other personal data get stored) for Android 3.0 Honeycomb. It was improved for Android 4.4 Kitkat and then strongly recommended on Android 5.0 Lollipop, but it wasn’t fully implemented on most devices until Android 6.0 Marshmallow made it mandatory for new devices. The key used for this encryption is randomly-generated and unique to your device. This key is then encrypted by your lock screen PIN/pattern/password before being securely stored in a trusted location. This is similar to putting your house key in a lockbox hanging on the front door: you can’t get the key you need to gain entry unless you know the code for the lockbox. That means that you can change (or even remove) your password without having to re-encrypt all of your data — you’re just changing the code on the lockbox.

On a related note, if you have ever wondered why your Nexus device requires you to manually unlock rather than just scanning your fingerprint after a reboot, this is why. Your phone’s fingerprint scanner can identify you with relative surety, but each scan actually captures a slightly different piece of your fingerprint. The scan then compares the present data points against the stored profile and looks for most of the points to match. Most of an encryption key isn’t sufficient to decrypt the data, so our lockbox can’t be protected by biometric data alone. Only an exactly-matching code will be able to extract our house key and then unlock the doors.

Encrypting the partition as a whole is great from a security standpoint, but it does introduce a problem: Android can’t boot without a /data partition; it can’t decrypt and mount the /data partition until you enter your password (remember, Android doesn’t know the code to your lockbox); and it can’t prompt you for your password until the operating system has booted and presented the lock screen. See the problem?

The solution is for an encrypted device to mount a temporary filesystem to /data , which is then able to prompt for your code before the rest of the OS has had a chance to load. Once you successfully authenticate yourself, the phone unmounts the temporary filesystem, uses your code to open the lockbox and get the key to decrypt the real filesystem storage, mounts it to /data where it belongs, and continues with the boot as usual. This is quite secure — but since the OS and apps don’t actually start until you’ve entered your password, you won’t be notified of any calls or alarms until you manually unlock your device. That’s probably an acceptable aggravation when you are able to plan for it, but if your device reboots itself you will miss out on important notifications for hours until you notice it (in my experience, that’s usually about the time I begin to wonder why my phone has been so quiet lately).

Android does offer an option to avoid that inconvenience, as one of the steps for configuring the lock screen includes a Secure start-up prompt to ask whether or not you would like to require your password before booting the device. Answer in the affirmative (as you should), and your device will jump through the hurdles I just described. Decline, and the need for your password at boot time will be removed. The /data partition is still encrypted, but Android uses a default password (literally, “default_password”) in place of yours to encrypt the encryption key (this is setting the lockbox code to 1-2-3-4-5: the sort of code an idiot would have on his luggage). Manufacturers may implement this default encryption differently by deriving a hardware key straight from the SoC, but the effect is the same: Android can then use this default password (wholly known to itself) in order to seamlessly decrypt and mount /data at boot time without any user interaction. Your device will be able to receive calls, sound alarms, and generate notifications from apps as soon as it boots, though the standard lock screen security will still prevent you from accessing anything else until you authenticate yourself. This approach does still protect your data at rest from being compromised outside of Android (such as from the bootloader or recovery), but you wind up relying upon software lock screen security to keep your data secure once Android is up and running.

Even if you select the Require password to start device option, you’ll find that enabling any accessibility services will generate a warning that by continuing “your device won’t use your screen lock to enhance data protection.” The wording is rather vague, but the point is that your phone automatically switches back to the “default_password” approach to encryption. While many use apps with accessibility services for things like automation (Tasker) or password input (Dashlane), the feature is primarily intended for apps which assist users in using their device. A user might rely on one of these apps to be able to interact with the phone at all, which means such a tool must be able to help out with the lock screen. As such, enabling an accessibility service will cause your device to boot straight to the lock screen.

The result of all this is that users must choose whether they prefer the security of the pre-boot encryption prompt or the convenience afforded by various apps which seek to automate certain inputs (like password managers).

Encryption on Nougat

The encryption model for Android 7.x Nougat shifted from Full Disk Encryption to File-Based Encryption. By encrypting different files with different keys, those files can be unlocked independently without requiring an entire partition to be decrypted at once. This means that the system can now decrypt and use files needed to boot the system and process critical notifications while your personal apps and data remain securely encrypted behind your lock screen password.

Devices with FBE enabled present two abstracted storage schemes for applications. Credential Encrypted (CE) storage is the default storage location with a key protected by your password, and thus is only available after initially unlocking the device. Device Encrypted (DE) storage is protected by a device-generated encryption key (similar to the default_password method mentioned earlier) which means it is available to the system at any time. To continue with the analogy: CE puts your house key in a lockbox with a code known only to you, while DE is an exterior utility closet with a cipher lock combination known by you and the groundskeeper. Individual CE and DE keys are created for every user on the device, so Dad unlocking a shared family tablet wouldn’t decrypt Mom’s apps and data. (The first/owning user must still be the first to unlock the device following a reboot, as that user’s DE storage is treated as primary — but not protecting everyone’s data behind the same pre-boot key is a big step forward.)

When you power on an FBE-configured device, it starts up in a secured Direct Boot mode with access to only the DE storage (the utility closet). Direct Boot allows many of Android’s core processes to start up, enables apps to handle critical notifications or to provide important accessibility services, and displays a secure lock screen with the prompt to “Unlock for all features and data.” Developers can register components of their apps to be able to run during Direct Boot and access DE storage. In this way, you can continue to be notified of alarms, calls, or SMS messages even before unlocking the device. Note that the functionality is intentionally limited for your privacy and security — incoming calls will display the phone number but no contact details, and you’ll receive a notification that SMS messages have been received but will not see any information about those messages until you unlock the device.

Direct Boot does away with the “Require password to start device” option entirely, so users no longer have to choose between full security or convenience. And since the Direct Boot system specifically supports accessibility services, enabling apps like Tasker or Dashlane (or Talkback) will no longer have any impact on the encryption implementation. Nougat’s File-Based Encryption and Direct Boot make it possible to keep your data truly secure while still allowing for critical notifications and services to be used before you log in.

FBE is not enabled by default for devices upgraded to Android 7.x, for the same reason that you can’t remove encryption after it has been applied. Encryption changes have to be made from an unencrypted state, so turning on FBE during the upgrade would forcibly erase all of a user’s data without any advance notice — not likely to be a popular move for obvious reasons. FBE can be configured after the fact (at least on Nexus devices, I can’t guarantee that other manufacturers won’t tamper with this feature), though it does entail performing a factory reset and erasing all of your installed apps and data.

Important notes before proceeding

If you intend to keep reading, it would be a good idea to first make sure your apps and data are safely backed up. I personally use a combination of the Android Backup Service for most installed apps and their data, exporting configurations/data from apps like my launcher and saving them to Google Drive, and Helium to fill in the gaps. It doesn’t matter to me what approach works best for you — just make sure you’ve got a backup before you move forward.

The usual disclaimers apply: you proceed at your own risk. The ability to enable FBE is an experimental developer option — it could could have unseen side effects. Everything has gone smoothly in the several times I’ve enabled FBE on my Nexus 6P (including across a few different OTAs), but that doesn’t necessarily guarantee that you won’t encounter problems. I won’t be held responsible for anything that goes wrong resulting in loss of data, missing an important call from your mother (call her back, please!), broken flash storage, smartphone battery explosion, or tearing a hole in the fabric of space-time. That’s all on you.

Okay, onward to the fun stuff.

Enabling FBE on a device upgraded to Nougat

Once you’ve backed up your data (seriously, do it), you’ll need to enable the Android Developer Options if you haven’t already. Do this by navigating to Settings > About phone, scrolling to the bottom of the screen, and tapping the Build number entry seven times. You’ll be presented with a congratulatory message — “You are now a developer!” — and you didn’t have to learn a single line of code!

You can now find a new menu full of hidden wonders at Settings > Developer options. There are a lot of fun options to play with here, and a lot of ways to break things. In general, I don’t recommend just randomly flipping toggles unless you actually understand what they do — or, as in this case, Some Guy On The Internet tells you that it’s okay. We’re interested in the entry titled Convert to file encryption. Go ahead and tap it.

Since this operation will result in a factory data reset, you’ll be prompted to confirm your lock screen password to remove the factory reset protection. You will also be prompted to confirm that you want to go through with this and really want to wipe your user data and convert to file-based encryption.

Your phone will then reboot, erase all of your apps and data (you did remember to back that up, right?), and eventually boot back up to the initial Android setup screen. Go ahead and connect to WiFi, log in with your Google account, and start automatically restoring the apps and settings supported by the Android Backup Service.

Once everything is reinstalled and set back up it will be pretty much business as usual — except now you won’t see any options for enabling or disabling Secure Start-up. You can enable accessibility services for any apps you like, and subsequent reboots will go straight to your lock screen where calls, alarms, and text messages will still come through.

As you can see, the introduction of Direct Boot and File-Based Encryption is a fantastic feature of Android 7.x Nougat which hasn’t really gotten the attention it deserves. This constitutes a huge improvement over the clunky full-device encryption to truly balance security and convenience, and I hope that you’ll now be able to reap its benefits on your Nougat device.

Thanks to Reddit user mec287 for correcting a few errors!