The first screen of every app in 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. No signup form. No email field. No "agree to our cloud terms." You create a vault with a master password, and the app starts working. No one at our end has any record that you exist.
This isn't a design choice to seem minimal. It's the consequence of a different architectural commitment — one we made deliberately and one that turns out to matter more than we thought it would when we made it.
SecureKeep is local-first and zero-knowledge. Nothing you save ever leaves your device. We have no server that stores your data. If SecureKeep Inc. disappeared tomorrow, your vault would still work, 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. In our case, it has a specific technical meaning: we cannot read your data, even if we wanted to, even if compelled to, even if the device itself were handed to us.
The strongest way to achieve that is not cryptographic cleverness. It's simply not having your data at all. No cloud copy. No backup on our server. No telemetry that captures vault contents. No "encrypted in transit to our servers and at rest in our database." None of that, because none of it happens.
Your data never leaves your device. Anything that never leaves cannot be read by anyone who isn't on the device.
This isn't an absence of features — it's 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 just dereferenced. This prevents a memory-scraping attack from recovering it after you've walked away from the phone.
Why this specific 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 the thing that unlocks access to it. If you change your master password, only the wrapped DEK gets re-encrypted; your underlying vault data does not need to be re-encrypted. It's fast, and more importantly, the DEK itself — which actually protects the data — has the full entropy of a randomly generated 256-bit key regardless of how strong or weak your master password is. (Make it strong anyway.)
The Biometric Path
Typing a master password every time is annoying. Security features that annoy users get bypassed. So we added biometric unlock — Face ID, Touch ID, Android fingerprint — but we designed it 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 — we never see your face or fingerprint data. We just get a "yes, user authenticated" signal.
- The master password remains the fallback. If you fail biometrics (wearing a mask, bandaged finger, whatever), you can always type the master password.
Critically: the biometric flow does not 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 That Keeps Getting Noticed
One feature gets more user comments than almost any other: Face-Down Lock.
Turn it on in settings. 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 phone movements), the vault locks.
Why this exists: the moment the average user most wants to lock their vault is the moment they can't reach a button. You're showing a password to your spouse, the kids walk in. You've opened your emergency card at the ER, a stranger wanders past. You're reviewing your will at a café, someone you know walks up to say hello.
In all of these, reaching for "Close Vault" or "Lock Now" is awkward. 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, and we normalise that — 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 that has this feature. We think it should be a 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. Not "when the OS asks us to." The moment you swipe up, the moment you switch apps, the moment a call comes in — 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 immediate; the inactivity timer is the backup for the "I opened the vault, got distracted, left the phone unlocked 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. This is normally harmless — it's how you see previews when you swipe to switch apps. For a vault app showing a password, it's a disaster. Someone who later browses your task switcher 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 on the entire screen for just long enough that the task-switcher snapshot captures the shield, not 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: 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 back on doesn't reset it. Biometric failures count towards the same counter — 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 zxcvbn strength score ≥ 2, the same as the master password baseline), 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. USB stick. Your own server. A trusted family member. You control the distribution. 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 alongside your own without overwriting anything.
This means: you are never locked in by us. You can leave. You can move to any device. You can keep multiple backups in multiple places. We are not the single point of failure.
What We Give Up By Being Local-Only
This architecture comes with real tradeoffs. It would be dishonest not to name them:
- No cross-device sync. If you want your vault on both your iPhone and your iPad, you have to back up and restore. No automatic sync.
- Device loss is a real risk. If you lose your phone and haven't made a backup, that vault is gone. This is 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 have 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. This is a feature — it is the very thing that makes us zero-knowledge. It is also why we recommend strong but memorable master passwords and at least one backup.
- No web or desktop access. Only iOS and Android. For now.
We've considered each of these carefully and decided the tradeoff is worth it. Cross-device sync via a cloud is the first step on a slippery slope that ends with us holding encrypted blobs we can't technically read but can legally be compelled to hand over. Device-loss risk is solvable with backups. Password recovery requires 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 needs to withstand more than a marketing claim. It needs 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 is robust against all of those is the one where we have nothing. No user database. No encrypted backups on our infrastructure. No telemetry tying your device to an identity. No password hash we could be forced to hand over. No email we could be compelled to confirm exists.
Zero-knowledge isn't a cryptography trick we performed on top of a normal cloud app. It's the architecture of the whole thing, top to bottom. The app you install, the bits on disk, the crypto on your phone — that's the whole product.
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. Use it forever. No renewal. No "unlocked features with Pro." Every feature is every feature.
We like this model. It aligns us with your long-term interest rather than your continued willingness to renew. You're not a recurring revenue stream for us; you're someone who bought a tool once and, we hope, gets decades of use out of it.
The Simple Version
If you want the whole architecture in one sentence: your vault is encrypted with keys your device holds, stored in files your device stores, unlocked with a password your device verifies. At no point does any of it touch any server of ours. Everything else — biometric unlock, face-down lock, auto-lock, privacy shield, rate limiting, encrypted backups — follows from that central choice.
That is the quiet feature. The one we rarely talk about because there is no visible UI for it. And it is, on reflection, the reason everything else in SecureKeep has the shape it has.
Related reading:
- The Emergency Card: A One-Page Document Your Family Will Reach For First
- Leave Your Voice: Video and Audio Messages
- What Actually Happens to Your Digital Accounts When You Die
SecureKeep is a $7.99 one-time-purchase encrypted vault for iOS and Android. No accounts. No cloud. No telemetry. Zero-knowledge by architecture, not by claim. Learn more →