Why We Chose Envelope Encryption Over SQLCipher for a Banking App
SQLCipher is the default answer for encrypting local data on Android. Here is why we chose envelope encryption for a banking app, and the trade-offs involved.
When a mobile app stores sensitive data locally, the default advice on Android is almost automatic: use SQLCipher. It is mature, well known and encrypts the entire database.
During a security audit and remediation for a retail bank’s Android app, we chose a different approach: envelope encryption of the sensitive values themselves, with keys held in the Android Keystore. In this article, we’ll explain both options, why envelope encryption fit this app, and what we gave up to get there.
The Problem: Sensitive Data at Rest
Banking apps cache data to stay fast and usable offline: account details, recent transactions, profile information. If that data sits on the device in plain form, a rooted phone, a backup or a forensic copy can expose it. In the OWASP Mobile Top 10 (2024), this falls under M9: Insecure Data Storage and M10: Insufficient Cryptography.
Option 1: SQLCipher
SQLCipher is a fork of SQLite that encrypts the full database file.
-
Strength: everything is encrypted, including indexes and metadata.
-
Strength: encrypted data remains fully queryable.
-
Cost: native libraries for each CPU architecture, which add to app size.
-
Cost: the database key still has to be protected, usually by the Keystore anyway.
Option 2: Envelope Encryption
Envelope encryption works with two levels of keys:
-
A data encryption key (DEK) encrypts the sensitive values with an authenticated cipher such as AES-GCM.
-
A key encryption key (KEK) in the Android Keystore wraps the DEK. App code never sees the KEK, and on supported devices it is hardware-backed.
📌 Key Insight:
In both approaches, real protection comes from the Keystore. The choice is about what you encrypt with it: the whole file, or only the values that matter.
Why Envelope Encryption Fit This App
1. Most Stored Data Was Not Sensitive
Much of the local database held UI configuration and other non-sensitive data. Encrypting the specific sensitive values protected what mattered without changing how the rest of the database worked.
2. App Size Mattered
Avoiding SQLCipher saved about 6.5 MB of native code. For a banking app that many users install on mid-range phones over mobile data, that is a meaningful difference.
3. The Performance Cost Was Measurable and Small
We measured the overhead of decrypting the values each screen displays at about 1 ms per screen — well below anything a user could notice.
4. One Key Model for Everything
The same Keystore-backed key model can protect values in the database, in preferences and in files, instead of having a separate mechanism for each.
The Trade-Offs We Accepted
-
No queries over encrypted fields. Sensitive values cannot be searched, sorted or indexed, so queries had to be designed around non-sensitive fields.
-
Classification becomes a design task. Someone has to decide, and document, which values are sensitive. Get it wrong and data stays in plain form.
-
Metadata is not encrypted. Table structure and non-sensitive columns remain readable.
Side-by-Side Comparison
| Aspect | SQLCipher | Envelope Encryption |
| What is encrypted | Whole database file | Selected sensitive values |
| Queries on encrypted data | Yes | No |
| App size impact | Native libraries added | About 6.5 MB less in this app |
| Runtime cost | Encryption on every database page | About 1 ms per screen measured |
| Design effort | Low | Data classification required |
| Best for | Mostly sensitive, queryable data | Few sensitive values in a larger dataset |
How Mobian Approaches These Decisions
At Mobian, every security change in that audit came with a short written decision memo: the risk, the options, what we chose and what we rejected. That record is what lets a bank’s security team — or its auditor — understand why the app works the way it does. We would choose SQLCipher just as readily for an app where most local data is sensitive.
Conclusion
SQLCipher and envelope encryption both rely on the Android Keystore for real protection. For an app where only some local data is sensitive, encrypting those values directly saved 6.5 MB and cost about 1 ms per screen — in exchange for careful data classification and no queries over encrypted fields. The right answer depends on your data, and the decision deserves to be written down.
Frequently asked questions
What is envelope encryption?
Envelope encryption uses two levels of keys. Data is encrypted with a data encryption key (DEK), and the DEK itself is encrypted, or wrapped, by a key encryption key (KEK). On Android, the KEK can live in the Android Keystore, where it is never exposed to app code.
Is SQLCipher a bad choice?
No. SQLCipher is mature and encrypts the whole database file, including indexes and metadata. It is a good fit when most of the database is sensitive or when encrypted data must stay queryable. It does add native libraries to the app and changes how the database layer works.
What did envelope encryption save in this project?
Avoiding SQLCipher saved about 6.5 MB of native code in the app, at a measured cost of about 1 ms per screen for encrypting and decrypting the sensitive values it displays.
What is the main downside of field-level envelope encryption?
Encrypted fields cannot be searched, sorted or indexed by the database. You need to decide carefully which values are sensitive and design queries around non-sensitive fields. Whole-database encryption avoids that design work.
Does envelope encryption satisfy OWASP requirements?
It addresses the insecure data storage and insufficient cryptography categories of the OWASP Mobile Top 10 (2024) when implemented correctly, with hardware-backed keys where available and an authenticated cipher such as AES-GCM. Whether it satisfies a specific audit depends on that audit’s requirements.