The first screen of every app on your phone looks roughly the same. Sign up. Log in. Email. Password. Maybe a social login, maybe a verification code, sometimes a phone number.
Open SecureKeep for the first time and there's nothing like that. It doesn't ask for a signup form, an email address, or agreement to any cloud terms. You create a vault with a master password, and the app starts working. Nobody at our end has any record that you exist.
That's a deliberate architectural commitment, and it turned out to matter more than we expected. SecureKeep is local-first and zero-knowledge: nothing you save ever leaves your device, and we run no server that stores your data. If SecureKeep Inc. disappeared tomorrow, your vault would keep working on your phone, as if nothing had changed.
Here's exactly what that means and how it works.
Zero-knowledge: what it actually means
"Zero-knowledge" is one of those phrases that gets used loosely. Here it has a specific technical meaning: we cannot read your data, even if we wanted to, and even if a court compelled us to hand it over.
The strongest protection here isn't clever cryptography; it's simply not holding your data at all. There's no cloud copy, no server-side backup, and no telemetry that captures vault contents, because none of that ever happens.
Your data never leaves your device. Anything that never leaves cannot be read by anyone who isn't on the device.
This is a positive architectural choice, and like any such choice it comes with tradeoffs we think are worth it (more on that later).
How the encryption works
Here is the full cryptographic chain, stripped of jargon:
- You choose a master password when you create a vault. That password never leaves your device and we never see it.
- The app generates a random salt, a string of random bytes specific to your vault.
- Your master password plus the salt are fed through PBKDF2-SHA256 with 600,000 iterations. PBKDF2 is a deliberately slow function; the iterations make brute-forcing your password computationally expensive for an attacker even if they got your encrypted vault file. 600,000 is at the upper end of current industry recommendations (OWASP, as of writing, recommends at least 600,000 for PBKDF2-HMAC-SHA256).
- The output is a 256-bit derived key.
- The app also generates a separate random Data Encryption Key (DEK), another 256-bit key, used to actually encrypt the contents of your vault.
- The derived key wraps (encrypts) the DEK using AES-256-GCM and stores the wrapped version.
- All your vault data (credentials, documents, notes, messages, emergency card) is encrypted with the DEK, using AES-256-GCM. Every encrypted value is stored as
Base64(IV || ciphertext || authTag).
When you unlock:
- You enter the master password.
- The app derives the same key from password + salt.
- The key unwraps the DEK.
- The app verifies the DEK is exactly 32 bytes (a sanity check to catch tampering).
- The DEK is used to decrypt the data you're viewing.
When you lock:
- The DEK is wiped from memory: zeroed out, not merely dereferenced. This prevents a memory-scraping attack from recovering it after you've walked away from the phone.
Why this structure matters: the master password is never the encryption key. The encryption key is the DEK, a random 256-bit value, and your master password is just what unlocks access to it. If you change your master password, only the wrapped DEK gets re-encrypted; your underlying vault data does not. That's fast, and more importantly, the DEK itself (the thing that actually protects your data) has the full entropy of a randomly generated 256-bit key, no matter how strong or weak your master password is. Make it strong anyway.
The biometric path
Typing a master password every time is annoying, and security features that annoy people get bypassed. So we added biometric unlock (Face ID, Touch ID, Android fingerprint), designed to be strictly optional and cryptographically clean.
When you enable biometrics:
- The DEK is stored in your phone's secure hardware (the iOS Keychain or the Android Keystore) with the flag
requireAuthentication: true. - That hardware enforcement means the DEK cannot be retrieved from the Keychain without a successful biometric scan.
- The biometric itself is handled by the OS, not by SecureKeep, so we never see your face or fingerprint data. We just get a "yes, this user authenticated" signal.
- The master password remains the fallback. If biometrics fail (a mask, a bandaged finger, whatever), you can always type the master password.
Critically, the biometric flow doesn't weaken the cryptography. The DEK protected by biometric hardware is still a random 256-bit key. We don't derive it from your fingerprint; the fingerprint is just the gate that lets the Keychain hand the DEK back to the app.
Each vault has its own biometric DEK storage, so multi-vault users don't end up with one biometric unlock accidentally opening the wrong vault.
Face-down lock, the feature people keep noticing
One feature draws more comments than almost any other: Face-down lock.
Turn it on in settings, then place your phone face-down on a table. The accelerometer detects the orientation, and after a brief grace period (about 1.5 seconds, enough to avoid false positives from casual movements), the vault locks.
Why it exists: the moment people most want to lock a vault is often the moment they can't reach a button. You're showing a password to your spouse and the kids walk in. You've opened your emergency card at the ER and a stranger wanders past. You're reviewing your will at a café when someone you know comes over to say hello.
In each of these, reaching for "Close Vault" or "Lock Now" is awkward, but flipping the phone over is natural. Face-down lock turns a reflex gesture into a security action.
The implementation handles platform quirks (iOS and Android report accelerometer z-axis data with opposite signs, which we normalise) and includes the grace period specifically so you can check a notification or lift the phone without triggering a lock you didn't want.
We know of no other vault app with this feature, and we think it should be standard.
Auto-lock on background
Every vault app claims an auto-lock. Ours locks immediately when the app goes to the background, not after a few seconds, and not only when the OS asks us to. The moment you swipe up, switch apps, or take a call, the vault locks.
On top of that, an inactivity timer locks the vault after 1, 5, 15, or 30 minutes of no interaction (you choose). The two work together: the background lock is instant, and the inactivity timer covers the "I opened the vault, got distracted, and left the phone on the desk" case.
The privacy shield
On iOS, when you switch apps, the OS takes a screenshot of the current screen for the task switcher. Normally that's harmless; it's how you see previews when you swipe between apps. For a vault app showing a password, it's a problem. Someone browsing your task switcher later could see the password in the preview.
The Privacy Shield solves this. When SecureKeep is about to go to the background, it overlays a brand-coloured shield across the entire screen for just long enough that the task-switcher snapshot captures the shield instead of your data.
On Android, we use the equivalent approach: the FLAG_SECURE window flag, which tells the OS not to capture screenshots or include the app in the recent-apps thumbnail.
Both protections are on by default. You don't need to enable anything.
Rate limiting on the lock screen
If an attacker gets your phone, they get to try passwords. We make that expensive:
- After 3 failed attempts: a 30-second lockout.
- After 5: 60 seconds.
- After 10: 5 minutes.
The lockout state is persisted to device storage, so turning the phone off and on doesn't reset it. Biometric failures count towards the same counter, so it doesn't matter how the attacker is trying to get in.
Realistically, combined with PBKDF2's 600,000 iterations, brute-forcing a strong password on a phone is astronomically slow. The rate limiter is the belt to go with the cryptographic suspenders.
Backup and restore, still local
We know that "everything on the device" invites the obvious question: what if the device dies?
SecureKeep supports encrypted backups. You create a backup with a separate passphrase (we require a zxcvbn strength score ≥ 2, the same baseline as the master password), and the app writes out a .securekeep file that contains your entire vault, encrypted, including credentials, documents, notes, messages, and emergency cards.
You decide where that file goes: email to yourself, iCloud Drive, Google Drive, a USB stick, your own server, a trusted family member. You control the distribution, and we never see the file.
On restore, you bring the backup file back to SecureKeep (on the same device or a new one), enter the backup passphrase, and the vault is decrypted and imported non-destructively, so it sits alongside any other vaults you already have. You can import a backup of your spouse's vault next to your own without overwriting anything.
The upshot: you are never locked in by us. You can leave, move to any device, and keep multiple backups in multiple places. We are not a single point of failure.
What we give up by being local-only
This architecture comes with real tradeoffs. Here they are, plainly:
- No cross-device sync. Want your vault on both your iPhone and iPad? You back up on one and restore on the other. There's no automatic sync.
- Device loss is a real risk. Lose your phone without a backup and that vault is gone. It's why we nudge backup setup early in onboarding.
- No "I forgot my master password" recovery. We cannot email you a reset link. We have no way to reset your password, because we hold no copy of your data to re-encrypt. If you genuinely forget your master password, and don't have biometric unlock enabled, and don't have a backup with a passphrase you remember, the vault is unrecoverable. That unrecoverability is exactly what makes us zero-knowledge, and it's why we recommend a strong but memorable master password and at least one backup.
- No web or desktop access. iOS and Android only, for now.
We've weighed each of these and decided the tradeoff is worth it. Cross-device sync through a cloud is the first step on a slippery slope that ends with us holding encrypted blobs we can't technically read but could be legally compelled to hand over. Device-loss risk is solvable with backups. Password recovery would require us to hold something about you, which we don't.
Why this matters for the use case
SecureKeep is positioned as a vault for the people you trust most: passwords, documents, final messages, medical information, assets. The value of the app is directly proportional to how much you trust it with your most sensitive information.
That trust has to withstand more than a marketing claim. It has to withstand:
- Us being acquired by a company with different priorities.
- Us being served a subpoena for your data.
- A future employee of ours going rogue.
- A breach of our servers.
The only design that survives all of those is the one where we have nothing to give up: no account database, no server-side backups, no telemetry linking your device to an identity, no password hash to be forced to hand over, no email on file to confirm.
Zero-knowledge here is the architecture of the whole product, top to bottom. The app you install, the bits on disk, the crypto on your phone: that's all there is.
One-time purchase, no subscription
A practical corollary: because we have no servers, we have no ongoing server costs to amortise with a subscription. SecureKeep is a $7.99 one-time purchase. Buy it once and use it forever. No renewal, and no features held back behind a "Pro" tier. Everything's included.
We like this model. It keeps our incentives pointed at your long-term use of the tool, since there's no renewal to chase. You bought a tool once and, we hope, get decades of use out of it.
The simple version
Here's the whole architecture in one sentence: your vault is encrypted with keys your device holds, stored in files your device keeps, and unlocked with a password your device verifies, and none of it ever touches a server of ours. Everything else (biometric unlock, face-down lock, auto-lock, the privacy shield, rate limiting, encrypted backups) follows from that one choice.
It's the part we rarely talk about, because it has no visible UI, and it's the reason everything else in SecureKeep has the shape it does.
Related reading: