Android™ 13 Security Overview: Direct Boot, FBE and more...

Direct boot mode

HEADS-UP!

One of the changes Google has made in Android 13™ to improve security is the removal of support for Full Disk Encryption (FDE), which means OEMs must now implement a File Base Encryption (FBE) filesystem. For developers, this translates into a few more limitations on what applications can do after a reboot and before a pin or password is entered. Google refers to this as making applications Direct Boot aware. The main difference is that after a reboot only a portion of the filesystem and system resources are available until the device is unlocked - if you need to access certain files before the device is unlocked, you'll need to make sure this is stored in the portion of the filesystem which is available in direct boot mode. Note that this only occurs after a reboot if a pin (or password) is enabled on the device's lock screen and it does not occur if the device times out after normal operation. Google’s reference for direct boot is found here.

History of the Direct Boot Mode

A bit of history on this mode makes it clearer how things evolved. Starting with Android 7 and up to Android 11 OEMs like Zebra had the option to implement a file-based encrypted (FBE) filesystem. Introduced as a security upgrade, FBE adoption however pulls in the implications described above. It requires any apps running before the user unlocks the device for the first time to be specifically crafted to deal with all the limitations implied by this operating mode if a pin or password is enabled. In the already-secured enterprise environments where shared devices are used, many administrators have so far preferred to skip this security option to simplify the management of their fleet and the software lifecycle. That could be achieved by choosing devices with full-disk encrypted filesystem (FDE) and preventing the Secure Start-up to be enabled because no apps run until the user unlocks the device. Zebra supported such an approach by providing administrators with a special MX feature called DevAdmin / Secure Start-up Dialog / Disable the YES button.  The following table offers a quick summary for Android versions 7-11:

To know what type of filesystem a device is implementing, run the command adb shell getprop ro.crypto.type  -  It returns “file” when the filesystem is of FBE type, and “block” when it’s FDE.

For Android 13 the landscape drastically changed, just one configuration is available, and the direct boot mode is no longer an option: when pattern/PIN/password is enabled, it’s always set. That’s because Google made FBE filesystem mandatory and the Secure Start-up always on. The previous table looks like this, for Android 13:

Direct boot-aware apps

The link provided above at the beginning of this section includes a sample boot-aware app from Google. You can also reference this code. The basic steps are:

• Register for the LOCKED_BOOT_COMPLETED event (it’s a manifest-declared intent filter)
• Get a special context for the direct boot mode, derived from the onReceive context through createDeviceProtectedStorageContext(). This provides access to the Device Protected Storage (DPS) and specific APIs are provided to work with files in this area. As an example, on a Zebra TC58 running Android 13, the DPS root path is /data/user_de/0/<package name>/files, while the standard Credential Encrypted Storage (CES) is /data/user/0/<package name>/files.

Keep in mind that DPS is less secure than CES and it’s up to you to decide how to segregate data between the two locations. Google’s recommendations sound like “Don't migrate private user information, such as passwords or authorization tokens, from credential encrypted storage to device encrypted storage. Use your best judgment when deciding what other data to migrate to device-encrypted storage. In some scenarios, you might need to manage separate sets of data in the two encrypted stores.”

Zebra Secure Storage Manager can be a great option to protect sensitive data in DPS, the next paragraph covers that.

• Run the app once before rebooting

What apps should do in direct boot mode is, according to Google, mainly related to setting up alarms, and notifications and activating special services for users. GMS appears reduced in functionality, though this is not thoroughly documented: one GMS service that works for sure is firebase-messaging-directboot. I’m also exploring the use of Foreground Services FGS in direct boot mode which is your best option for having a component of your app running before the user unlocks the device; more on that can be found at “What’s New in Android™ 13 and the Impact on Zebra developers”

At Zebra we are actively looking at enterprise use cases where direct boot is a requirement, let us know yours by replying to this blog post or contacting us at developer@zebra.com

Secure Storage Manager in direct boot mode

Secure Storage Manager (SSM) is an OS component introduced by Zebra as a solution to Android scoped storage. It can be a valid option in Direct Boot mode too.

When coding your app to run in direct boot mode during secure startup, you need to move whatever data you need from CE to DE, which makes it less secure. But putting the data into SSM makes it more secure than regular data stored in CE while still making it available in direct boot mode.  This means you can safely use even sensitive data in direct boot mode, which wouldn't be the case when not using SSM.

More on how SSM securely stores, securely shares, and securely persists data can be found here.

Debugging in direct boot mode

Being able to debug and having all the Android Studio tools handy is a great advantage. If you’ve never debugged an app blocked by the keyguard, here is how to do it.

Navigate to the Settings menu, then System / Developers Options / scroll down to the Debugging section and tap the “Select debug app” menu and choose the app you need to debug (needs to be installed of course). Then move to the next menu entry, “Wait for debugger” and turn it on. More info from Google here.

 Finally, from Android Studio, select “Attach to process…”. Your app won’t start until you complete this final step.

Special thanks to my fellows Allan Herrod, Prashanth Kadur, Malvika Rajp, James Swinton-Bland

Android is a trademark of Google LLC.