Vaultumi Threat Model

Last updated 3 November 2026

Not independently audited. This is the author’s own document. Vaultumi has not been independently reviewed, audited or certified, and its hand-written scrypt and secret-sharing code still need external review. The page repeats what the project’s source documents say, with repository-internal references removed.

Scope: Vaultumi 1.0 for iPhone and iPad (iOS 17+), as designed in the security architecture. This is the author's own analysis, not an independent assessment. Rows 26 to 34 and the matching asset, actor and residual-risk entries were added on 2026-10-31 for Vault Drop, the Intruder log, documents and OCR, similar photos, Legacy Kit and the backup safety check. Row 35 was added on 2026-11-02 for the optional backup reminders. These features were written after the project's own review in security review notes and are not covered by it.

1. Assets

Asset	Why it matters
Media content (photos, videos, Live Photos)	The whole point of the product
Media metadata (filenames, dates, albums, dimensions, hashes, thumbnails)	Reveals content and habits
Master key and per-file keys	Open everything
PIN, recovery code, backup passphrase	Open the master key
Pepper (Keychain, this device only)	Needed to test PIN guesses; never in any backup
Existence of the vault / decoy	The user may not want others to know
Inbox key pair (private half sealed in the vault, public half in the App Group container)	The private key opens everything shared through Vault Drop and every Intruder log photo
The App Group container (`VaultumiInbox`: public key, slots file, sealed pending items)	Shared with the share extension and writable by it; the only vault-related data outside the app's private storage
Waiting inbox items (shared files, intruder photos)	Hold personal files or a face photo until the next unlock
Intruder log photos	Photos of whoever typed wrong PINs; may show a third party (see row 29)
OCR text of documents (`.ocr` sidecars and the in-memory index)	The full text of IDs, contracts, letters; more sensitive per byte than the metadata
Image feature prints (`.fp` sidecars)	Describe what each photo looks like
Legacy Kit cards (Shamir shares) and their PDF	Together they equal the recovery code
The plaintext temp copy made for the share extension	An unencrypted copy of a file the person chose to protect
Entitlement state (Premium)	Business integrity, low user impact

2. Actors

Actor	Capability assumed
A. Casual snooper	Has the unlocked-or-locked phone briefly, can use the UI, guess PINs
B. Partner/colleague who knows the user's habits	A plus may know likely PINs, may watch the user enter it
C. Thief with a locked phone	Physical possession, no passcode
D. Thief/adversary who knows the device passcode	Can unlock iOS, open Settings, take backups
E. Holder of a copy of vault files (iCloud/iTunes device backup, `.vaultumibackup` file)	Offline, unlimited compute. Does not hold the pepper: it is device-only and in no backup
F. Malware / jailbreak / MDM-level adversary	Code running on the device
G. Forensic lab	Device extraction tools
H. Network attacker	Not applicable to the app itself: it makes no network requests of its own
I. App Store / Apple	Out of scope (trusted platform)
J. Developer (us)	Holds no user data, no keys, no backend
K. Holder of write access to the App Group container	Another app signed by the same team with the same App Group, malware, a jailbreak or a forensic tool. Can read the container and add, replace or delete files in it
L. A third party photographed by the Intruder log	Someone other than the owner who typed wrong PINs: a partner, a child, a colleague, a person who found the phone. Not an attacker in every case
M. Legacy Kit card holders	The trusted people who each hold one card. Assumed able to cooperate, to lose or photograph their card, and, if k of them collude, to rebuild the recovery code

3. STRIDE-style table

#	Threat	STRIDE	Actor	Mitigation in design	Residual risk
1	Guess PIN through the UI	Spoofing	A, B, C	6 digits; weak PINs rejected; escalating delay 30 s to 1 h after 5 failures, measured on the monotonic clock (`CLOCK_MONOTONIC_RAW`) tagged with the boot session, so changing the date or time does not shorten a wait and a reboot restarts the current delay in full; a decoy-vault login does not reset the failure counter; the PIN re-check before sensitive actions (change PIN, new recovery code, decoy creation, creating a backup, delete all data) uses the same limiter (`verifyCounted`); never wipes	10^6 space; a patient actor with days of access and the limiter intact can succeed; an observed PIN defeats it
2	Offline PIN brute force from copied vault files	Spoofing / Info disclosure	E	The pepper is not in the files and not in any backup (`kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly`); scrypt 32 MiB; the PIN KEK needs the pepper. An iCloud/iTunes backup holder gets ciphertext plus a header they cannot attack offline without the pepper	If an attacker also obtains the pepper from the device itself (compromised or extracted Keychain, jailbreak, forensic extraction while the device is unlocked or after first unlock) the PIN falls in hours to days; recovery code and passphrase are not affected
3	Offline guess of backup passphrase	Info disclosure	E	scrypt 64 MiB + random salt; AEAD; no plaintext metadata; passphrase normalised to NFC; a generated 160-bit secret is preferred; an own passphrase needs at least 12 characters and must pass `PassphrasePolicy` (no heavy repetition, nothing trivially common)	Only as strong as the passphrase the user chooses; the policy is a floor, not a guarantee
4	Read media from app storage	Info disclosure	C, D, E	AES-256-GCM per file, per-file keys, file protection `completeUnlessOpen`	Leaks counts, sizes, timestamps (see the architecture section 4)
5	Tamper with a stored file (flip bits, truncate, swap between items, reorder chunks, append)	Tampering	E, F	GCM tags; AAD binds item id, role and final-chunk flag	Detected, not prevented: an attacker can still delete or corrupt files (denial of service)
6	Roll back to an older vault copy	Tampering	E	none	Out of scope: no freshness guarantee
7	Crash or power loss during import/restore	Tampering / DoS	n/a	`.meta` written last; staging wiped at launch; orphans removed; import verified by full decrypt + SHA-256 before originals may be deleted; restore is idempotent	Low; physical-device testing required (see the internal test plan)
8	Decrypted temp file left behind	Info disclosure	C, D, F	`tmp/VaultumiTemp`, protected, deleted after use, on lock and at launch; `TempSpace.clearAll()` also removes `tmp/VaultumiBackups`, `tmp/VaultumiRestore-*` and `Documents/Inbox`	App killed while viewing leaves a file until next launch; the file is readable on an unlocked device by F
9	App-switcher snapshot shows content	Info disclosure	A, B	Lock on background (or after the chosen delay, timed on the monotonic clock) and an opaque privacy cover; implemented	Must still be verified on a physical device
10	Screenshot or screen recording by the user or by someone mirroring	Info disclosure	A, B, F	iOS cannot block screenshots; a cover appears while the screen is being recorded or mirrored (implemented)	Cannot be prevented; the user is told. AirPlay output of video is not covered by the screen-capture cover
11	Shoulder surfing PIN	Info disclosure	A, B	none beyond Face ID as alternative	Not mitigated
12	Face ID bypass (twin, coercion, enrolling a new face)	Spoofing	B, D	`.biometryCurrentSet`: enrolment change or passcode removal invalidates; PIN still works; decoy never opens by Face ID	An actor with the device passcode who enrols a face invalidates Face ID rather than gaining it; coercion is not addressed
13	Recovery code theft	Spoofing	A, B	Shown once, not stored; user told to keep it offline	If written next to the phone it defeats the PIN; if lost and PIN lost, no recovery
14	Decoy vault discovery	Info disclosure / Repudiation	B, G	Separate keys and files; generic directory names; both KDFs run when a decoy exists	Not forensic-proof: `alt` directory and header exist, storage use differs. Acknowledged limitation: a wrong PIN costs two scrypt runs only when a decoy exists (one otherwise), so timing can reveal that a decoy exists. Do not rely on it against a technical adversary
15	Malware / jailbreak reads memory or Keychain	Info disclosure / EoP	F	Platform sandbox, Keychain, file protection	Out of scope
16	Backup file shared by mistake	Info disclosure	E	Backup is useless without passphrase	Weak passphrase
17	Third-party SDK exfiltration	Info disclosure	H	No third-party SDKs; no network code in the app	Re-audit each release
18	Purchase/entitlement spoofing (editing UserDefaults cache, StoreKit tampering)	Spoofing / Elevation	F	Entitlement from verified StoreKit transactions; cache is a UI hint	Low impact; Premium features only; vault data never gated
19	Premium lapse locks the user out of their data	DoS	n/a	Design rule: existing media is never locked; export, backup, restore and recovery are never gated	Must be verified in UI
20	Source photos remain after import	Info disclosure	A, D	Originals are deleted only after verified import and system confirmation	Deleted photos stay in Recently Deleted ~30 days and may live in iCloud Photos or other synced copies; no secure erasure claim
21	Metadata leaks through the iOS Photos album or share sheet during export	Info disclosure	n/a	Export writes only on user action	The exported copy is outside our protection
22	Custom crypto code bug (scrypt, VMF1, VMBK)	Tampering / Info disclosure	any	Test vectors, mutation tests, only Apple primitives for AES/HKDF/SHA	Needs external review, in particular the hand-written scrypt
23	Developer compromise or coerced disclosure	n/a	J	No server, no keys, no accounts: nothing to hand over	n/a
24	Hostile `.vaultumibackup` (memory exhaustion, path traversal, oversized records, duplicate ids)	DoS / Tampering	E	`Scrypt` refuses parameters above 128 MiB; backup headers are bounded to logN <= 17, r <= 8, p <= 2 (at most 128 MiB) and are rejected before any derivation otherwise; thumbnails <= 2 MiB, album/manifest JSON <= 4 MiB, item JSON <= 1 MiB; duplicate item or album ids are rejected in validation; file names and type identifiers are sanitised on restore (single path component, no `..`, no control characters, at most 120 bytes; type ids restricted to dotted ASCII words)	Low; the file must still authenticate under the passphrase, so only someone who knows it can craft such a file
25	Phone restored from an iCloud/iTunes device backup	Availability	n/a	Vault files travel in the backup, the pepper does not, so the PIN cannot open the restored vault; the recovery code (or a manual `.vaultumibackup`) does	The decoy vault has no recovery code, so it cannot be reopened after a device migration; this is a stated limitation
26	Writable App Group container: forged, flooded or deleted inbox items	Tampering / DoS	K	Items must be valid VMIB (authenticated under keys derived for this vault) to be imported; only photos, videos and PDFs are ingested, through the normal verified ingest; the free-plan slot count and the 256-file / 2 GiB caps bound what can be added; unreadable files are counted and never executed; the drain never runs for the decoy vault	Items are confidential but not authenticated: anyone with the public key can make a valid item, so a forged photo can appear in the vault after unlock. A full inbox also blocks Intruder photos and shares. Deleting files loses pending shares. Residual risk accepted: the same actors can already attack the app's other storage
27	Public-key substitution: `vault.pub` replaced by the attacker's key	Spoofing / Info disclosure	K	The app rewrites the correct `vault.pub` at every unlock; items sealed to a foreign key cannot be opened by the vault and show as unreadable	Nothing detects the substitution when a share is made. Anything shared or photographed between the substitution and the next unlock is readable by the attacker who holds that private key. The key file has no signature or pinning
28	Sealed-metadata leaks: what a holder of the container learns without a key	Info disclosure	K, E, G	Filename, type, time and attempt count are inside the sealed metadata; payload is AES-GCM; ephemeral keys per item	Visible: the number of waiting items, their payload sizes, file times, whether each is a shared file or an intruder photo (a plaintext kind byte), the item UUIDs, the rough length of the filename (the sealed-metadata length is plaintext), the `slots` value (Premium or not, and on the free plan how many items remain), the public key (a stable identifier of the vault) and that Vault Drop is installed. An intruder photo waiting in the inbox reveals that the Intruder log fired
29	Intruder log photographs a third party; photo exposed or misused	Info disclosure	L, A, B	Off by default; Premium only; consent sheet before the camera permission, stating that it may capture someone other than the owner and that the iOS camera indicator will be on; one photo per streak; sealed at capture with the public key only; viewable only after unlock; never taken for the decoy vault; not in gallery or backups; viewable, exportable and deletable by the owner; no network	The owner is responsible for lawful use: some places restrict photographing people without consent. A wrong PIN typed by the owner or a family member also triggers it. Exporting a photo creates an unprotected copy. The photo is unprotected by Vaultumi while a person looks at it. This is not legal advice
30	Legacy Kit: k holders collude, or cards are lost, photographed or stored in the cloud	Spoofing / Info disclosure / DoS	M	Any k of n cards are needed; fewer reveal nothing about the secret beyond a 32-bit tag; per-card checksum; set id so cards of different kits are not mixed; creating a kit requires a PIN re-check; the old recovery code is replaced; the cards are not stored by the app; the cards and the PDF warn the holder	k colluding holders, with a copy of the vault files from any source (a device backup, for example), can open the vault: the recovery wrap does not need the device pepper. A photographed or cloud-synced card counts as a card in the wrong hands. If more than n-k cards are lost, the recovery path is gone. There is no time-lock and no release after death: Vaultumi has no server. The Shamir code is hand-written and unreviewed. The PDF shows the cards in the clear
31	OCR text recovered from the vault	Info disclosure	C, D, E, F	Text recognized on the device by Vision; sealed in a sidecar under its own HKDF key (`vaultumi.v1.ocr`) with the item id bound in as AAD; not in backups; in-memory index emptied on lock	While unlocked, the full text is in memory and in search snippets on screen. A holder of the vault files can see which items have a `.ocr` file (they are documents) and roughly how much text each holds. A compromised device reads memory (row 15). The OCR itself is Apple's component
32	Feature prints reveal visual similarity	Info disclosure	C, D, E	Sealed under `vaultumi.v1.fp` with the item id bound in as AAD; derived from the stored thumbnail in memory; removed on purge; not in backups	Without the key, only the presence of a `.fp` file is visible. With the key the attacker already has the thumbnails. Low
33	Plaintext copy made for the share extension	Info disclosure	C, D, F	The extension streams the file chunk by chunk into the sealed inbox and keeps no other copy of its own	iOS gives the extension a temporary unencrypted copy of the shared file; it stays until the system removes it. Vaultumi cannot encrypt, wipe or shorten it, cannot control its file protection class, and cannot clean it up if the extension is killed first. The original also stays where it was (Photos keeps shared originals). Needs checking on a device
34	A reassuring but wrong result from the backup safety check; hostile file	Repudiation / DoS	E	The check does the same full validation as restore, with the same caps, and writes nothing to the vault; the secret and the optional recovery code are used and then cleared	"Passed" means this file opens with this secret and matches the vault today. It does not prove a restore on another device or later iOS, or that the secret is stored safely. The check copies the encrypted backup to `tmp` while it runs
35	Optional backup reminders: a notification on the lock screen, or its tap, reveals the vault or opens something	Info disclosure	A, B, C	Opt-in and off by default; the iOS prompt appears only after an explicit tap. Local notifications only: no push service, no server, no network. The text is fixed and generic ("Time to check your backup"): no count, size, date, file name or other vault data, and no mention of photos or privacy; `userInfo` is empty and the tap handler reads nothing from the notification. The planner reads only three values `AppSettings` already holds (last backup date, last check date, items added since the last backup); the stored reminder state holds dates and counters, never content, and is erased by Delete all data. A tap only opens the app: while locked it shows the lock screen, and there is no deep link past it, so the unlock rules are unchanged. The invitation is never shown for the decoy vault or while locked. Banners only: no sound, no badge	The wording still shows that a backup habit exists, and that Vaultumi is installed, to anyone who sees the lock screen with previews on; the app icon already shows the second. A holder of the device or its files can read the on/off choices, the weekly day and time, and the dates reminders were due or tapped. Hiding previews is an iOS setting (Settings > Notifications). The weekly reminder fires whether or not a backup is due

4. In scope

Confidentiality and integrity of vault data at rest in app storage and in .vaultumibackup files against actors A to E.
Resilience to crashes, low storage and corrupted files (no silent loss, clear errors).
Not leaking data to the network or to third parties.

5. Out of scope (no protection claimed)

Fully compromised, jailbroken or malware-infected device; MDM/supervised device with hostile profile.
Someone watching the screen or the PIN entry; coercion.
Weak backup passphrase or a PIN chosen by the user that is still guessable.
Forensic analysis of the device, of free space or of flash remnants; secure erasure.
Attacks on Apple's platform (Secure Enclave, Keychain, Face ID implementation, iCloud).
Screenshots and screen recordings (cannot be blocked on iOS).
Availability: a user who loses every secret loses the data by design.

6. Screenshot and screen capture limitations

iOS offers no API to forbid screenshots. Hiding content in the system screenshot is not reliable. The app therefore does not claim to prevent them.
UIScreen.isCaptured (and the capture-change notification) lets the app detect screen recording and mirroring; the app covers the content while the screen is captured.
AirPlay output of video is not covered by the screen-capture cover.
The app switcher snapshot is covered by an opaque view when the app is not active.
Screenshots of vault content taken by the user go to the Photos library, outside the vault. The UI should tell the user this.

7. Residual risks the user must understand

A 6-digit PIN (10^6 possibilities) protects against casual access. Its strength rests on scrypt, the device-only pepper and rate limiting; it does not protect against a determined offline attacker who has both the files and the pepper.
Lose the PIN and the recovery code and you lose the vault, unless you hold a .vaultumibackup and its passphrase.
The decoy vault is a convenience against casual inspection, not a hidden-volume system.
Originals deleted from Photos may still exist for about 30 days and in synchronised copies.
Vault files are in iCloud/iTunes device backups if the user has them on. This is intended. Those backups contain ciphertext and the header only; the pepper is device-only and in no backup, so a holder of such a backup cannot attack the PIN offline. The flip side: a phone restored from a device backup cannot be opened with the PIN and needs the recovery code (or a manual .vaultumibackup).
The decoy vault has no recovery code. After a device migration it cannot be reopened; recreate it on the new device.
Vault Drop makes a temporary unencrypted copy of the shared file, and leaves the original where it was (Photos keeps it). Until the next unlock, the waiting items' number, sizes, times and kind are visible to someone with the container's files; their content is not.
Items in the inbox are not authenticated as coming from the owner, and the public key in the shared container can be replaced by anything that can write there.
The Intruder log can photograph someone who is not the owner. It is opt-in and Premium, and the photo is unreadable until the owner unlocks, but it exists, and the owner decides what to do with it.
OCR text and feature prints are extra sealed copies of information derived from your files. They are not in backups and are regenerated after a restore, but while the vault is unlocked the text is in memory.
Legacy Kit does not release anything on its own. If you give cards to people, those people (k of them) can open your vault. If you lose more than n-k cards, you cannot use the kit. The kit replaces your recovery code; the old printed code stops working.
Older versions of the app cannot open documents or restore a backup that contains them.
Backup reminders are local, generic and carry no vault data, but the banner can still be read on a lock screen that shows previews, and it shows that a backup habit exists. Turn previews off in iOS Settings > Notifications, or leave reminders off (the default).

8. Known open items

These are known and not fixed in 1.0:

The master key is not rotated when the PIN changes. Someone who holds an old copy of the header, the old PIN and the same device pepper can still open the vault.
Purge is unlink-only: there is no secure erase of flash storage.
"Delete originals" removes the original .photo resource, so for an edited photo the edit is not what was imported.
AirPlay output of video is not covered by the screen-capture cover.
The PIN space is 10^6.
The decoy vault has no recovery code and cannot be reopened after a device migration.
Timing reveals that a decoy exists (two scrypt runs only when a decoy exists).
Added with the newer features: the share-extension temp copy is outside Vaultumi's control; the inbox is writable by anything with access to the App Group container and items in it are not authenticated; the public key is not pinned; the inbox exposes count, sizes, times, kind and the slots value; the Intruder log may capture a third party; Legacy Kit has no time-lock, relies on unreviewed Shamir code and leaks up to 32 bits of the secret through its tag (harmless for a random 160-bit secret); the similar-photos threshold (0.4) has not been tuned on real libraries and the comparison is windowed above 1500 photos, so a pair can be missed; OCR text exists in memory while unlocked.

9. What requires external review

Before making stronger public claims than "encrypted with standard Apple primitives":

Independent cryptographic review of: the hand-written scrypt implementation (required), the VMF1 chunk format (nonce construction, AAD, final-chunk semantics), key wrapping and AAD choices, the backup format and restore algorithm.
Also required for the newer features: the hand-written Shamir secret sharing and the Legacy Kit card format (field arithmetic, share tag and checksum, the 32-bit leak); the VMIB inbox format (ephemeral ECDH, HKDF labels and salt, AAD, key reuse across the stream and metadata keys); the App Group trust model (public-key replacement, forged items, file protection class of the shared container); and the extension's temporary-file exposure.
Independent review of Keychain and biometric usage (access control flags, behaviour across restore/migration).
Penetration test of the running app on a physical device: temp-file residue, app-switcher snapshot, pasteboard, logs, crash reports, screenshot/recording handling, memory after lock.
Legal review: export-control classification (the internal export-compliance notes), privacy policy, terms.
Reproduction of key hierarchy by an independent decoder (see the internal backup-format notes, test vectors).

10. Assumptions

iOS and its Keychain, Secure Enclave, file protection and CryptoKit behave as documented.
The device has a passcode set (the biometric Keychain item requires it).
The user keeps iOS updated.

Sources

Primary sources behind the statements about iOS and cryptography on this page. The linked pages are in English.