How Senvra Protects Private Data on Your iPhone: Four Layers of Defense

Private data should not have to leave your phone before it can be protected. That principle is why we built Senvra: an offline-first private space for photos, videos, audio, PDFs, files, and notes, without an account, a hosted vault, or automatic uploads.

The Senvra vault does not require network permission. If a prompt for Network Access, Local Network, Cellular Data, or a third-party keyboard's Allow Full Access appears after the keyboard opens, you can deny it; Senvra's local vault, unlock, entry, and browsing remain available. The request may come from iOS or the selected keyboard, not the Senvra vault. For highly sensitive entry, use the Apple system keyboard with Dictation and unnecessary cloud input features disabled, or turn off Allow Full Access for third-party keyboards. Denial reduces the risk of typed content leaving the device through a keyboard component, but it does not replace careful device security, keyboard selection, and export handling.

But "stored on the phone" is not the same as "safe." A credible vault must answer harder questions:

• What if someone guesses the password?
• What can a stolen backup reveal?
• What survives a crash, interruption, or full disk?
• What happens when the app goes into the background?
• Which assumptions stop being valid on a jailbroken device?

Our answer is defense in depth. NIST describes this as combining people, technology, and operations to create barriers across multiple layers. For Senvra, that becomes four practical layers: a trusted environment, cryptographic isolation, safe recovery processes, and protection during everyday use.

flowchart TB
    A[1. Trusted environment<br/>Current iOS, device passcode, no jailbreak]
    B[2. Cryptographic isolation<br/>Independent spaces, keys, authenticated files]
    C[3. Safe processes<br/>Recovery, backups, verification, atomic commits]
    D[4. Everyday protection<br/>Privacy shield, idle lock, quick close]
    A --> B --> C --> D
    D -. limits exposure .-> A

No single layer is presented as magic. The design is useful because one control can still reduce harm when another control is imperfect.

Layer 1: begin with a trusted device

Senvra's protection model is intended for a supported, up-to-date, non-jailbroken iPhone protected by a device passcode.

This boundary matters. A jailbreak weakens the sandbox, code-signing, and process-isolation guarantees that every normal iOS app depends on. With elevated control of the operating system, an attacker may inspect files, instrument a running process, or capture secrets after they are decrypted for legitimate use. Jailbreak detection can increase an attacker's cost, but OWASP also notes that such checks can be bypassed. An app that promises absolute safety on a fully compromised operating system is making a promise it cannot keep.

The practical foundation is therefore simple:

1. Keep iOS updated.
2. Use a strong device passcode and Face ID.
3. Do not store sensitive data on a jailbroken device.
4. Treat an already-unlocked phone as a higher-risk situation.

Senvra also keeps its own trust surface small. Vault content is processed and stored on the device. There is no Senvra account, no hosted cloud vault, and no automatic upload of protected content. Production vault operations require no network client, WebView, local-network declaration, or background-network entitlement. Optional Support opens in the system browser only when the user asks for it, and an explicitly exported copy is governed by the destination the user chooses.

Local-first architecture does not make compromise impossible. It removes an entire class of routine server-side exposure: there is no central Senvra vault for an attacker, operator, or data breach to retrieve.

Layer 2: isolate spaces, keys, and files

Encryption is not a badge in Senvra. It is a hierarchy with separate responsibilities.

Each private space receives its own random 256-bit master key, password salt, and cryptographic identity. A password is processed with PBKDF2-HMAC-SHA256; the current production parameter is 600,000 iterations. The derived key unwraps the space master key rather than encrypting every file directly.

Each protected item is then stored with AES-256-GCM authenticated encryption. Authentication is important: it detects modification as well as hiding content. Media chunks, metadata, thumbnails, key envelopes, and their owning space and object identities are cryptographically bound. Moving an encrypted component into the wrong context does not make it valid there.

flowchart LR
    P[Space password] --> K[PBKDF2-HMAC-SHA256<br/>600,000 iterations + unique salt]
    R[32-byte access key] --> H[HKDF-SHA256<br/>separate recovery domain]
    K --> M[Wrapped 256-bit space master key]
    H --> M
    M --> I[Independent item key envelopes]
    I --> G[AES-256-GCM media chunks]
    I --> T[Authenticated metadata and thumbnails]

One password. One space. No list.

Many vaults first reveal which containers exist, then ask the user to choose one and enter its password. That selection screen already discloses information: an observer may not see the contents, but can learn that private spaces exist, how many there are, and what they are called.

Senvra reverses that flow. The app begins in the ordinary Everyday space, while private spaces remain absent from any browsable list. The user sees one neutral entry point; entering a space's password routes directly to that space. Different passwords open different spaces, without first exposing their names, covers, or real count. During shoulder surfing, a casual inspection, or brief access to an unlocked phone, this reduces the visible clues that another space exists.

The protection is more than a hidden screen. The persisted catalog uses four fixed directory slots, filling unused positions with padding descriptors and files so its outward shape does not directly reveal the real space count. During unlock, Senvra checks the real password spaces and completes matching derivation and concealment work instead of returning immediately when it finds a match. Incorrect attempts receive uniform handling; after each group of three failures, the delay grows from one minute to five minutes, 30 minutes, one hour, and then 24 hours.

This design reduces interface and catalog-metadata disclosure. It must not be confused with "hidden means encrypted," and it does not promise perfect deniability on a jailbroken device or under professional forensic analysis. Independent keys, authenticated encryption, and a trusted device environment still provide the actual content protection.

The same key hierarchy also isolates items. A large video is authenticated in bounded chunks, and a damaged item does not become permission to trust unrelated files. Security Center can authenticate protected files and identify integrity problems without first exporting the library.

iOS protections remain part of this layer. Sensitive directories use Complete File Protection, and device-bound wrapping material is stored in Keychain with WhenUnlockedThisDeviceOnly accessibility. Senvra adds application-level encryption; it does not pretend the platform underneath it is irrelevant.

Layer 3: make recovery and failure safe

Confidentiality without recoverability is an incomplete form of safety. People lose passwords, devices fail, storage fills, and processes terminate at inconvenient moments. Senvra treats these as design inputs.

A user-held access key, not a server reset

Every private space can have a random 32-byte access key. It can recover access and reset the password, and it can be rotated after the current key is verified. Senvra has no server-side password-reset backdoor.

That creates a clear responsibility boundary: if both the password and access key are lost, Senvra cannot decrypt the space for the user. The access key should be stored outside the phone in a trusted location.

Backups require two independent credentials

Current V3 portable backups use two credentials:

• A private-space backup requires the space access key and a separate backup password.
• A public-space backup requires a newly generated random backup key and a separate backup password.

The backup password is processed with PBKDF2-HMAC-SHA256 at 600,000 iterations. The credential key and password-derived material are combined through domain-separated HKDF. That combined key authenticates and unwraps a random archive key. The archive itself is written as independently authenticated AES-256-GCM frames, with sequence and record type bound as authenticated data.

Possessing only the backup file, only the backup password, or only the saved key is not enough.

flowchart TB
    A[Access key or generated backup key] --> C[Domain-separated key combination]
    B[Backup password<br/>PBKDF2-HMAC-SHA256] --> C
    C --> D[Authenticate and unwrap random archive key]
    D --> E[Encrypt bounded frames with AES-256-GCM]
    E --> F[Verify tags, byte counts, item digests, manifest digest]
    F --> G[Atomically publish complete .senvrabackup]
    F -. any failure .-> X[Reject and remove pending output]

The outer V3 header avoids space names, item names, source identifiers, thumbnails, and scope details that could identify the vault. A backup is accepted only after its authenticated frames, byte counts, item digests, manifest digest, and final archive marker agree. Import also checks that the backup scope matches the destination and tracks provenance to avoid silently duplicating previously imported items.

The main vault is excluded from ordinary Apple device backup. Only complete, strongly encrypted, anonymously named recovery containers are eligible for Apple recovery. Users can also save an encrypted backup manually in Files or another location they control.

Senvra can verify a backup without importing it. We recommend doing that after important changes and as a periodic recovery drill. A backup that has never been verified is only a hope.

Recordings are committed incrementally

Recording is where privacy and reliability often conflict. Writing a long plaintext movie and encrypting it only at the end creates a dangerous window. Senvra instead writes protected recording segments as they arrive.

Before recording begins, Senvra creates a protected journal and reserves finalization capacity. Each accepted segment is encrypted, synchronized to durable storage, and then recorded in an atomically updated journal. Final metadata is committed only after the segment structure, byte count, and SHA-256 digest agree. The pending directory is moved into its final item location only after validation.

If the app is interrupted, already committed protected segments can be discovered and recovered on the next launch. This does not promise that the last frame still in hardware or operating-system buffers can survive sudden power loss. It means a failure does not force Senvra to discard every valid segment that was already encrypted and durably recorded.

The same transaction pattern appears elsewhere: write into a pending location, verify, synchronize, and publish atomically. Incomplete work is not presented as complete data.

Important access leaves a verifiable trace

Space opens and sensitive actions enter an encrypted, append-only activity chain. Each event links to the preceding event, while an independent Keychain anchor helps detect truncation, replacement, or rollback to an older chain.

This is not real-time intrusion detection, and it cannot prove who performed an action. It gives the owner something more useful than silence: a local history of important access and a way to check whether that history is internally consistent.

Layer 4: protect the moments when people forget

Many privacy failures happen after successful authentication: the user switches apps, receives a call, leaves the phone on a desk, starts screen recording, or simply forgets to close the vault. Security must be ergonomic enough to operate in those moments.

Senvra therefore treats lifecycle transitions as security events:

• When the app becomes inactive, a privacy shield covers sensitive content and temporary plaintext is cleared.
• When Senvra enters the background, the current private space closes and in-memory unlock state is cleared.
• Device lock closes protected access and stops sensitive work.
• Screen capture activates the privacy shield and requires a safe transition before content is revealed again.
• A configurable idle lock closes a private space after 30 seconds, one minute, two minutes, five minutes, or 15 minutes.
• Quick-close controls can return immediately to the ordinary space; an optional Shake to Close gesture provides another route.
• Long-running imports, exports, backup work, integrity checks, and local indexing are canceled or covered when the app becomes inactive.

Senvra also reacts when iOS reports that a screenshot was taken, but this boundary must be explicit: an iOS app cannot reliably erase a screenshot that the operating system has already saved or synced. Senvra closes protected content and clears the unlock state; it does not claim to reverse time.

Convenience unlock with Face ID or a gesture is deliberately subordinate to the space's independent credentials. Convenience should reduce friction, not become the only recovery path.

What this model does not claim

Security language should remain testable. Senvra does not claim:

• absolute protection on a jailbroken or fully compromised operating system;
• that a person holding an already-unlocked phone can never see content;
• that screenshots already captured by iOS can always be recalled;
• protection for plaintext copies after the user exports them;
• remote wipe, automatic cloud synchronization, or server-assisted password recovery;
• an independent third-party security certification that has not occurred.

It also cannot prevent data loss when the device and every usable backup are lost together. Encryption, integrity, and recovery are related, but they are not interchangeable.

A practical setup checklist

For the strongest real-world result:

1. Keep iOS current and do not jailbreak the device.
2. Use a strong device passcode and enable Face ID.
3. Use a unique space password; Senvra requires at least 12 characters and recommends 16 or more.
4. Store the access key outside Senvra and outside the same phone.
5. Create an encrypted backup with a distinct password, then keep the backup file and both required credentials in appropriately separated trusted locations.
6. Run Verify after major library changes and periodically rehearse recovery.
7. Choose the shortest idle-lock interval that fits your use, and enable the quick-close methods you can perform reliably.
8. Remember that an exported plaintext copy is no longer governed by the vault.

Why we built Senvra this way

We did not want privacy to mean uploading private media to another company's server, paying forever for access, or trusting a single lock screen. Senvra is a one-time purchase with no ads and no subscription. Its core vault works offline because ownership and recovery should remain with the person holding the data.

The result is not a claim of invulnerability. It is a set of explicit barriers: a trusted platform, independent cryptographic domains, failure-aware recovery, and interactions that close exposure quickly. That is what "safe on your phone" should mean: fewer places to trust, clear limits, and a recovery path you can verify before you need it.

Further reading

• NIST: defense in depth
• OWASP MASVS: mobile application security verification
• OWASP MASTG: jailbreak detection and its limits
• Apple Platform Security