Phone Storage Encryption and Forensics: BFU, AFU and Database Security

Encryption at rest, or Data-at-Rest encryption, protects stored data; end-to-end encryption protects message content between authorized devices. Evaluating a messaging app's security requires examining both. The name of an algorithm or the label “post-quantum” alone does not show how the database, media cache and exported files on a phone are protected.

In mobile forensics, “obtaining a file” is likewise not the same as “reading its encrypted contents.” The result depends on the device model, operating system version, lock state, data type, usable keys and examination method. The name of a tool alone cannot predict extraction success or failure for every phone.

Three layers that should not be confused

Layer	What does it protect?	Key question
End-to-end message encryption	Content exchanged between authorized devices	Who holds the keys, and how is the contact verified?
Device storage encryption	Files kept in storage	When, and with what authorization, can the relevant keys be used?
In-app and backup protection	Databases, exports or separate copies	Which data is covered, and where is the key for each copy?

For example, an image saved from a chat to the gallery is no longer governed solely by that messaging app's retention policy. Cloud backups and manual exports also need separate examination. The chat backup security guide explains this distinction.

What do BFU and AFU mean?

These terms usually describe the device's state in relation to the first unlock after startup:

• BFU, or Before First Unlock: Since the device was switched on or restarted, the user has not yet unlocked it for the first time.
• AFU, or After First Unlock: The first unlock has taken place; the device may now be showing the lock screen again.

These two labels are not security scores or definitive forensic outcomes. AFU does not mean “all keys can be extracted”; BFU does not mean “no data is accessible.”

In Android file-based encryption, Credential Encrypted storage, or CE, becomes available after the user unlocks the device. Device Encrypted storage, or DE, can also be used for necessary Direct Boot operations. Each item's storage location and key policy matter; not all files share the same access state.

Why does key management matter more than naming AES?

Database encryption is useful when its key is properly protected too. Keeping an encrypted file next to an unprotected key does not create the same boundary as a key bound to authentication and secure hardware. The handling of temporary files, attachments and application logs must also be clear.

Android Keystore enables the use of nonexportable keys, and some keys can be backed by secure hardware. But a key being nonexportable does not mean an attacker cannot use it: according to Android's documentation, an attacker who compromises the app's process may be able to use the key even without being able to extract the key itself.

A visible app lock does not necessarily prove that the database is encrypted with an independent key either. Such a claim requires examining the storage design, authentication conditions and implementation in that particular version.

What can be concluded about Livara?

The Livara security and threat model documentation describes the provider's account of the product's design and boundaries; it does not replace independent forensic testing.

In particular, identity recovery in the v7 format should not be treated as a chat history backup or evidence of local database encryption. A description of a messaging protocol such as LVR1 does not, by itself, establish which key protects each file on the phone or in which states that protection applies.

This article has not tested commercial forensic tools or the database of any particular Livara version. Claims such as “no forensic tool can read Livara” or “ML-KEM encrypts every file in storage” are therefore not defensible conclusions.

What evidence should you ask for when evaluating a messaging app?

Instead of an untested ranking table, pursue these specific questions:

1. Which app version, device model and operating system version were examined?
2. Where are message text, files, thumbnails, cache and manual exports each stored?
3. How is the database key generated and stored? Does using it depend on authentication?
4. What changes when the device is locked, after it is unlocked and while the app is running?
5. What exactly does the backup include, and who holds its password or recovery key?
6. Has an independent report been published with the test method, limitations and examination date?

Without answers to these questions, the label “encrypted” is insufficient for comparing products. Publishing technical documentation is valuable, but it should not be presented as equivalent to independent validation of every claim.

Practical steps for everyday protection

Use a suitable device passcode, install operating system and app updates, and restrict sensitive text previews on the lock screen. Manage additional copies in the gallery, downloads folder and backups consciously; a copy outside the messaging app may have a different protection policy.

For sensitive conversations, the health of the contact's device matters too. If malware can read text after the app is opened, the issue goes beyond extracting an encrypted file. The Android session security guide explores this boundary.

Frequently asked questions

Does a switched-off phone mean data extraction is impossible?

No. Device state is one factor, not a guarantee of the outcome. The hardware, software, data and examination method need to be specified.

Does post-quantum message encryption guarantee storage security?

No. Protecting key exchange and messages does not replace the design and examination of local storage.

Does account recovery mean all messages come back?

Not necessarily. Recovering an identity, reconnecting to an account and restoring history are three different capabilities. Before changing phones, check the backup scope of that specific product and version.