Encrypted on-device · v0.3.6
Security model

No servers to trust. Just math and your phone's chip.

This page explains exactly how Brikwall protects your files, who it protects them from, and where that protection ends. The encryption runs in a small core written in Rust, the same code on every phone.

01

Principles

  • The pattern is the key. It's never stored, and neither is anything that could verify it.
  • Nothing readable touches storage. Imports, camera captures, thumbnails, video playback and document previews all happen in memory.
  • No accounts, no servers holding your data. There's nothing of yours on our side to leak, subpoena or hack.
  • Tell the truth about limits. Every feature page and this one say where protection stops.
02

Who we defend against

WhoWhat they can doWhat Brikwall does
Casual snoopPicks up your unlocked phoneShows only a pattern pad. Locks on leaving, blocks screenshots, limits attempts, can disguise itself and photograph them.
CoercerForces you to unlockDecoy vaults and a duress pattern. Nothing shows how many vaults exist.
Forensic examinerHas a full copy of storage, maybe the phone tooA copy alone can't test guesses (hardware key). On the phone, each guess costs a chip operation plus Argon2id. Files don't reveal vault count, sizes or ownership.
Backup holderHas your backup file (for example, Google)Backups only open with the 128-bit recovery phrase, never with the pattern alone.
Malware or root on an unlocked phoneReads memory while the vault is openOut of scope for any app. We limit exposure: keys are wiped on lock and no plaintext is written to disk.
03

From pattern to key

Your pattern goes through the phone's security chip first, then through a memory-hard function. The chip step is what stops offline guessing; the Argon2id step makes each guess expensive.

// 32 random bytes made at setup (not secret)
device_salt  = random(32)
challenge    = SHA-256("…/hw-challenge" ‖ device_salt ‖ pattern)
// HMAC with a key that can never leave StrongBox / the secure environment
hw_tag       = HMAC-SHA256(chip_key, challenge)
master       = Argon2id(pattern, secret = hw_tag, salt = device_salt,
                        memory = 128 MiB, passes = 3, lanes = 1)
slot_key     = HKDF(master, "…/slot/pattern/key")
// the pattern and anything that verifies it are never stored

Compare: many vault apps use PBKDF2 with a salt anyone can read, so a copy of the files can be attacked on a fast computer. Brikwall's chip step means a copy can't be attacked at all without the phone.

04

Key hierarchy

pattern ──► master ──► pattern slot ──┐
recovery phrase ──► recovery slot ────┴──► vault key (random, per vault)
                                              └─► index (new random key on every change)
                                                    └─► each file's own random key
                                                          └─► 64 KiB chunks, AES-256-GCM
  • Each vault has a random 256-bit key. Your pattern and phrase only unwrap it, so changing your pattern doesn't re-encrypt your files.
  • Every file gets its own random key. Chunk names are derived from that key, so chunks can't be linked to each other without it.
  • Every chunk uses a fresh random nonce. Its name, position and a "last chunk" flag are bound into the encryption, which blocks swapping, reordering or cutting chunks.
  • The index is re-encrypted under a brand-new key every time it changes, then swapped in atomically.
05

Disk layout

fl/device.bin         salt + settings          49 bytes
fl/keys/<32 hex>      slots, roots, dummies    every file exactly 1,024 bytes
fl/objects/<32 hex>   encrypted chunks         every file exactly 65,568 bytes
  • Setup creates 24 to 48 dummy key files. Each vault adds 3 real ones plus up to 3 more dummies, and saving sometimes adds a few more.
  • After every save, all key files are rewritten together, so their timestamps don't show which are in use.
  • An examiner can see the total amount stored and a rough upper bound on how many vaults there could be. They can't tell which chunks or key files belong to which vault, or whether a key file is real.
06

Wrong guesses

Five free misses, then 30 seconds, doubling with every miss up to one hour. The deadline is measured on a clock that changing the time can't move. Restarting the phone restarts a wait that's already running, but doesn't reset the count. Only a correct pattern resets failures.

Patterns need 7 to 25 dots. Passing straight over a dot includes it, the same as Android's lock screen.

07

Duress, by crypto-shredding

Drawing the duress pattern opens its decoy vault, and in the same moment:

  1. every key file except the decoy's own three is deleted and fresh dummies are added;
  2. every chunk that isn't the decoy's is deleted;
  3. the hardware key is destroyed and regenerated, and the decoy is re-sealed under the new one.

Because the hardware key is gone, old key slots that flash memory may still hold can't be opened, even by someone who later learns your pattern.

08

Recovery & backup

The 12-word phrase (128 bits) goes through Argon2id without the hardware step, on purpose, so it still works on a new phone after the old one is lost. It opens a separate recovery slot. After recovering, you set a new pattern and the old pattern slot is deleted.

A backup file is a byte-for-byte copy of the already-encrypted store, with a checksum. Restoring accepts only the expected file names and sizes, checks the whole file in a staging folder, and only then swaps it in.

09

Android hardening

  • Every screen is marked secure: screenshots, recordings and the recent-apps preview are black.
  • Leaving the app or turning off the screen locks it and wipes keys from memory.
  • Android backup and device transfer are switched off for app data.
  • Thumbnails live in memory; video streams from encrypted chunks; PDFs open from a memory-only file with no path.
  • Camera photos are captured in memory and stripped of EXIF; videos record to a memory-only file.
  • Randomness mixes the system generator with touch timing, sensor noise and the security chip. It can never be weaker than the system generator alone.
  • Release builds are shrunk and obfuscated, can't be debugged, and never log vault data.
  • The app checks its own signature in native code, so a modified, re-signed copy loses Pro.
10

Network lockdown

The only connection Brikwall makes is to RevenueCat, to verify Pro purchases from Google Play. The app's network configuration starts with an empty list of trusted certificate authorities, then trusts only RevenueCat's domains, and those must chain to pinned root certificates. Any other host fails at the handshake. Cleartext is refused, and user-installed certificates are never trusted.

RevenueCat sees an anonymous random ID, the purchase token and product, the app version, device model and language. It never sees vault contents, patterns, keys or how many vaults you have. Purchase answers are signed, and Brikwall only accepts verified ones.

11

What we can't protect against

  • A compromised, unlocked phone. Root access or malware running while your vault is open can read what you can read. No app can prevent that.
  • A weak pattern. A short, predictable pattern is easier to guess, even with the cooldowns. The strength meter tells you; the choice is yours.
  • Phones without hardware key storage. Encryption is the same, but a copy of storage can then be attacked offline, slowed only by Argon2id.
  • Flash memory remembers. Deleted data may linger. Duress destroys the hardware key to cover pattern slots, but a leftover recovery slot is protected only by your 12 words.
  • Storage totals and timing. The total stored and when chunks were written are visible, though not which vault they belong to.
  • Text in memory. Recovery words, file names and previewed document text pass through memory the system can't reliably wipe.
  • Keyboard clipboards. Some keyboards, including Samsung's, keep their own clipboard history even for content marked sensitive.
12

Report a vulnerability

Found something? Email support@brikwall.app with the steps to reproduce it. We'll reply as quickly as we can, keep you updated while we fix it, and credit you in the release notes if you'd like. Please give us a reasonable chance to ship a fix before you publish.