Threat Model

Document version

Version 1.0.0 — 2026-02-09

Executive Summary

The VardKista security model is composed of two independent layers: the Application Layer, which governs how each platform protects the runtime environment, user data, and key material on-device; and the Transport Layer, which governs how data moves between devices and how it is protected at rest on infrastructure the user does not physically control. These layers are architecturally separate. Each provides security guarantees independently of the other. Together they form a defence-in-depth composition where compromising one layer does not cascade into the other.

This document specifies both layers, their boundaries, their interactions, and the residual risks that exist at the seams between them.

---

1. Architectural Overview

1.1 Two-Layer Separation

1.2 Why Two Layers

The application layer and transport layer solve different problems against different adversaries.

The application layer defends against threats that originate on or near the device: malware, malicious dependencies, XSS, physical device theft, forensic imaging, and OS-level attacks. Its strength depends on the platform’s sandbox model, process isolation, and hardware security features. These vary significantly across desktop, Android, and iOS.

The transport layer defends against threats that target data in motion and data at rest on infrastructure: wire capture, relay compromise, hosting provider compulsion, and harvest-now-decrypt-later quantum attacks. Its strength depends on cryptographic primitives, key management, and the architectural zero-knowledge guarantee that relays cannot decrypt payloads. These are consistent across all platforms because the same Rust crates execute on every device.

A compromised application layer (device malware) cannot weaken the transport layer’s guarantees for other devices. A compromised transport layer (relay breach) cannot weaken the application layer’s sandbox on any device. The layers compose but do not depend on each other.

---

2. Application Layer — Platform Security

2.1 Shared Rust Core

All three platforms share the same compiled Rust crates for cryptography, sync protocol, and local storage. The crypto stack never crosses the platform boundary. GroupSecrets, encryption keys, HKDF derivations, and Argon2id operations execute exclusively in Rust. No platform UI layer — whether CEF’s V8, Jetpack Compose, or SwiftUI — ever holds key material.

This means the application layer’s security variations across platforms affect the blast radius of a UI-level compromise, not the cryptographic integrity of the system.

Shared crates and their roles:

Crate	Responsibility	Crypto Contact
sync-types	Wire format, message definitions	None
sync-core	State machine, cursor tracking	None
sync-client	E2E encryption, connection management, key derivation	All key material lives here
sync-content	Large blob encryption, content addressing	Per-blob key derivation

2.2 Desktop — Tauri + CEF (The Vault)

The desktop is the operational hub. It is the only device that holds all six VardKista drawer sync groups simultaneously. It serves as the primary device for provisioning new phones and, if needed, recovering from the blind replica. This makes it the highest-value application-layer target.

Runtime architecture:

CEF sandbox properties. CEF provides a consistent Chromium sandbox across Windows, macOS, and Linux. The renderer process runs with restricted privileges and cannot access the filesystem, network, or host process memory directly. All interaction with the Rust backend passes through Tauri’s IPC command system, which enforces capability-based permissions. Only explicitly declared commands are callable from the frontend.

What CEF gives us. Consistent rendering and sandbox behaviour across all desktop platforms — one Chromium engine, one security model, one QA surface. Version control: we ship a known Chromium build from CEF nightlies and control the update cadence. Full CDP support for development and agent-driven testing, disabled in production.

What CEF costs us. We own the Chromium patching burden. System WebViews (WRY) are patched by OS vendors; CEF is patched by tracking upstream nightlies. The binary includes approximately 100MB of Chromium. Attack surface is larger than a minimal WebView but contained by the sandbox. CrabNebula’s active development of cef-rs mitigates the update cadence risk — the team building the bindings is our team.

Desktop-specific risks. Key material (GroupSecrets for all six drawers) is stored in files with 0600 permissions. Any process running as the same OS user can read them. Desktop operating systems do not provide hardware-backed key storage equivalent to Android Keystore or iOS Secure Enclave. The desktop is the weakest platform for key-at-rest protection and the strongest for key-in-use functionality (always-on, all drawers, full Context Engine).

XSS blast radius. If an attacker achieves JavaScript execution in the CEF renderer, they can see plaintext that the app displays (because the UI needs it for rendering) and invoke permitted IPC commands. They cannot extract GroupSecrets, derive keys, or access SQLite directly. The blast radius is limited to whatever the current view shows and what IPC commands permit. This is a partial compromise, not total.

2.3 Android — Native Kotlin + UniFFI (Field Agent)

Each VardKista drawer is a standalone native Android app. No WebView. No JavaScript engine. The UI is Jetpack Compose calling Rust through JNI bindings generated by UniFFI.

Runtime architecture:

What native eliminates. The entire JavaScript attack surface is absent. No XSS, no dependency poisoning via npm, no eval chains, no prototype pollution, no WebView version fragmentation across budget devices. The execution path from UI to crypto is compiled Kotlin → compiled Rust through type-safe JNI. There is no interpreter to exploit.

Android Keystore. GroupSecrets (or a key-encryption-key wrapping them) can be stored in hardware-backed secure storage. On devices with a Trusted Execution Environment or Strongbox, key extraction resists even rooted-device attacks. The key hierarchy becomes: Android Keystore holds KEK → KEK encrypts GroupSecret at rest in app-private storage → GroupSecret derives Sync Key, Auth Key, Content Key as normal. This is a fundamental upgrade over desktop file-based key storage.

App sandbox. Android assigns each app a unique Linux UID. SELinux mandatory access control prevents other apps — banking apps, social media, malware — from reading any VardKista app’s files, memory, or network connections. The sandbox protects VardKista from the outside world.

Cross-app data model. Each mobile app contains the same full database schema — all six drawer tables. An app can only write to its own table (CashTable writes to the cash table, Innermost writes to the journal table) but can read all tables. On the free tier, the other tables are empty. For sync subscribers, 0k-sync populates the read-only tables from other apps on the same device, routed through the relay using the same encrypted protocol as cross-device sync. The relay does not know or care whether two endpoints are on the same phone or different continents.

Compartmentalisation is tier-dependent. On the free tier, each app holds one GroupSecret and one populated table. Compromise of CashTable reveals cash data only — genuine compartmentalisation enforced by the OS. For sync subscribers, every app holds all six GroupSecrets and the full filing cabinet. Compromise of any single app exposes all drawer data — the same blast radius as the desktop vault. This is the explicit trade-off of the Context Engine: cross-app intelligence requires cross-app data access.

Background sync. WorkManager enables battery-efficient background sync that survives app closure, respects Doze mode, and retries with exponential backoff. This is impossible with WebView-based apps where the OS kills the WebView in background. Users get “synced while you slept” rather than “will sync next time you open the app.”

2.4 iOS — Native Swift + UniFFI (Field Agent)

Each VardKista drawer is a standalone native iOS app. No WebView. No JavaScript engine. The UI is SwiftUI calling Rust through FFI bindings generated by UniFFI.

Runtime architecture:

Secure Enclave. iOS provides the strongest hardware key isolation of any consumer platform. The Secure Enclave is a physically separate processor with its own encrypted memory. Keys stored in the Secure Enclave cannot be extracted — not by the app, not by the OS, not by Apple, not by an attacker with physical device access. Operations using the key execute inside the enclave; the key never enters main memory.

iOS app sandbox. The strictest consumer OS sandbox. Each app runs in its own container with no visibility into non-VardKista apps’ files, memory, or network activity. Inter-app communication is limited to system-defined mechanisms (URL schemes, extensions) that require explicit user consent. App Store review provides an additional layer of supply-chain verification absent from Android sideloading.

Cross-app data model. Identical to Android. Each app has the full database schema, writes only to its own table, reads all tables. Sync subscribers receive all drawers’ data via 0k-sync through the relay. Free-tier users have compartmentalisation; subscribers trade it for Context Engine cross-app intelligence.

Background sync. BGAppRefreshTask provides system-scheduled background execution windows. Less flexible than Android’s WorkManager but sufficient for periodic sync. Push notifications via APNS can trigger silent wake events for time-sensitive sync.

Argon2id memory constraint. iOS extension processes (e.g., AutoFill) have approximately 55 MiB usable memory. Argon2id configurations above 46 MiB fail intermittently in these contexts. The device-adaptive parameter system (specified in the Specification Section 4.1) caps memory at 46 MiB for high-end mobile and 19 MiB (OWASP minimum) for low-end devices.

2.5 Cross-Platform Attack Surface Comparison

Attack Vector	Desktop (CEF)	Android (Native)	iOS (Native)
XSS / JS injection	CEF sandbox limits blast radius	Does not exist	Does not exist
Malicious JS dependency	Confined to renderer, no FS	Does not exist	Does not exist
Malicious native dependency	Possible (Rust/npm)	Possible (Rust/Gradle)	Possible (Rust/SPM)
Binary tampering	Code signing mitigates	Play Store signing + Play Integrity	App Store signing + notarisation
Key extraction at rest	File permissions (0600)	Hardware Keystore	Secure Enclave
Memory inspection	Process memory readable by same-user	SELinux restricts cross-app	Hardware memory isolation
Cross-drawer leakage (free tier)	All 6 secrets in one process	OS-enforced per-app isolation	OS-enforced per-app isolation
Cross-drawer leakage (subscriber)	All 6 secrets in one process	All 6 secrets in each app	All 6 secrets in each app
Background sync	Always-on (desktop stays open)	WorkManager (survives app close)	BGAppRefreshTask (system-scheduled)
Root/jailbreak attack	Game over	Game over	Game over
OS-level malware	Game over	Game over	Game over

Key observations. Mobile platforms provide stronger security than desktop for key storage (hardware-backed), process isolation (OS-enforced), and protection from external threats (sandbox keeps other apps out). However, the cross-drawer compartmentalisation advantage only applies to free-tier users. Sync subscribers have the full filing cabinet in every app on every platform — the blast radius of a single-app compromise is equivalent across desktop and mobile. This is the deliberate trade-off of the Context Engine: cross-app intelligence requires cross-app data access. The OS sandbox still protects all VardKista apps from external threats (malware, other apps) regardless of tier.

Desktop provides stronger functionality as the always-on vault with all six drawers and full Context Engine. It sits in a physically controlled environment (the user’s home or office). Mobile devices carry the same data (for subscribers) into less controlled environments but benefit from hardware key storage and the absence of a JavaScript engine.

2.6 The IPC / FFI Boundary

The boundary between platform UI and Rust core is the critical application-layer surface across all platforms. On desktop, it is Tauri’s IPC command system. On Android, it is UniFFI-generated JNI bindings. On iOS, it is UniFFI-generated FFI bindings.

What crosses the boundary. Plaintext data for display (journal entries, receipt details, transaction amounts) crosses from Rust to UI. User input (new entries, edits, search queries) crosses from UI to Rust. Sync status, connection state, and error messages cross in both directions.

What never crosses the boundary. GroupSecrets, encryption keys, HKDF-derived material, Argon2id parameters, nonces, and authentication tags. These exist exclusively in Rust memory. No platform UI layer can request, inspect, or extract key material through any IPC/FFI path.

Minimising blast radius. The amount of plaintext crossing the boundary determines the blast radius of a UI-layer compromise. Design recommendations per app:

• Innermost (journaling): Full entry text must cross for editing. Consider rendering previews with truncated text; load full entries only on explicit user action.
• Vault Ledger (receipts): Send thumbnail and metadata across the boundary. Full receipt images load on demand.
• CashTable (finances): Aggregate summaries cross for dashboards. Individual transaction detail loads on navigation.

The principle: expose the minimum plaintext needed for the current view. A compromised UI sees only what is currently displayed, not the entire database.

---

3. Transport Layer — 0k-sync Protocol Security

3.1 The Zero-Knowledge Guarantee

The foundational security property of 0k-sync, verified at HIGH confidence across both security audits: the relay cannot decrypt user data.

This is not a policy. It is an architectural constraint. The sync-relay crate has zero cryptographic dependencies. Its Cargo.toml contains no encryption libraries. There is no decrypt function, no key derivation function, no key type in the relay’s source code. The relay stores opaque Vec<u8> payloads with routing metadata (group_id, device_id, cursor, timestamp, size). It cannot distinguish encrypted data from random noise.

Verified properties (audit v2, HIGH confidence):

Property	Evidence
Encrypt-before-I/O on all push paths	CL-003: sync-client encrypts then sends
AEAD authentication verified on decrypt	sync-client, sync-content
192-bit random nonces via CSPRNG	getrandom in sync-client, sync-content
HKDF domain separation per derived key	Distinct info strings per key type
Relay has zero crypto dependencies	sync-relay Cargo.toml audited
No payload content in any relay log statement	All tracing statements audited
SQLite stores only ciphertext + routing metadata	Schema review confirmed
All SQL queries use parameterised bindings	12 queries audited

3.2 Key Hierarchy

Each sync group has its own GroupSecret, its own salt, and its own derived keys. Compromise of one group’s key material does not affect any other group. On mobile free tier, OS-level app isolation reinforces this — each app holds only its own group’s secret. For sync subscribers, each mobile app holds all six groups’ secrets to enable cross-app data access; the OS sandbox still protects VardKista apps from external threats but does not compartmentalise between drawers.

3.3 Encryption Layers

Ring 1 — Application-layer E2E. Every blob is encrypted with XChaCha20-Poly1305 (256-bit key, 192-bit random nonce) before leaving the client. AEAD authentication prevents tampering. XChaCha20’s 192-bit nonce space makes random nonce generation safe without cross-device coordination (collision probability negligible below 2^80 messages). The key derives from GroupSecret via HKDF. The GroupSecret never exists on any relay or blind replica.

Ring 2 — Hybrid post-quantum transport. Noise XX handshake via clatter combining ML-KEM-768 (NIST PQC standard, lattice-based) with X25519 (classical ECDH). Both key exchanges must be broken to derive the session key. Provides mutual authentication, forward secrecy, and quantum resistance on the wire. Implementation status: dependency declared (clatter v2.2), integration pending (F-002). Interim protection: iroh QUIC with TLS 1.3 (classical, not quantum-resistant).

Ring 3 — Blind replica volume encryption. The blind replica’s SQLite database is encrypted at rest with a hybrid PQ-derived volume key (ML-KEM-768 + X25519). Protects against physical disk seizure, hosting provider compulsion, and offline forensic imaging. Independent key, independent algorithm instance, no relationship to Ring 1 or Ring 2 key material. Applies only to the blind replica, not ephemeral relays. See the Blind Replica Defence-in-Depth page for full specification.

3.4 Infrastructure Components

Ephemeral relay. Routes encrypted blobs between devices with TTL-based expiry. Blobs are stored temporarily to bridge offline devices, then deleted. Zero-knowledge by architecture. The relay is a dumb pipe: it accepts connections, stores opaque payloads, assigns monotonic cursors, notifies online devices, and cleans up expired data. It makes no decisions about content.

Blind replica. Architecturally identical to the ephemeral relay but with long-term retention. The disaster recovery root. Holds the complete encrypted history for all sync groups. Protected by three independent cryptographic rings. See the Blind Replica Defence-in-Depth page.

iroh transport. QUIC-based networking providing authenticated encrypted connections, NAT hole punching, and relay fallback for devices that cannot establish direct connections. Provides transport-level encryption independent of 0k-sync’s application-level encryption. Connection migration handles network changes (WiFi → cellular) transparently.

3.5 What the Transport Layer Sees

Component	Sees	Does Not See
Ephemeral relay	group_id, device_id, blob_id, cursor, timestamp, payload size, encrypted bytes	Plaintext, keys, passphrases, file types, item counts
Blind replica	Same as ephemeral relay	Same as ephemeral relay
iroh relay (packet forwarding)	Source/destination NodeIds, packet sizes	Anything above QUIC — payloads are already encrypted
Cloudflare edge	IP addresses, connection timing, TLS metadata	Anything inside the QUIC tunnel

No component in the transport layer can determine what type of data a blob contains, how many items it represents, or which VardKista drawer produced it. All blobs are opaque ciphertext of varying sizes.

---

4. Layer Interaction — Where They Meet

4.1 The Composition Model

The application layer and transport layer interact at exactly one point: the Rust sync-client inside the shared core. This is where plaintext is encrypted before entering the transport layer and where ciphertext is decrypted after leaving it.

Above the sync-client: plaintext exists, protected by platform sandboxing. Below the sync-client: only ciphertext exists, protected by the three-ring model. The sync-client is the only component that sees both.

4.2 Cross-Layer Attack Scenarios

Scenario: Compromised desktop UI (XSS in CEF). Application layer breached. Transport layer unaffected. The attacker sees plaintext currently displayed in the WebView and can invoke IPC commands (push/pull). They cannot extract GroupSecrets (Rust memory, not accessible via IPC). They can read data that syncs while they maintain access. Other devices are unaffected. The blind replica remains secure. Mitigation: CEF sandbox limits, IPC capability gating, Content Security Policy.

Scenario: Compromised Android app (malicious Gradle dependency). Application layer breached for one app. Transport layer unaffected. On the free tier, the attacker sees only that drawer’s plaintext — other drawers are empty in this app’s database. For sync subscribers, the attacker sees the full filing cabinet (all six drawers populated via cross-app sync). The attacker could push malicious blobs to the writable sync group, but cannot write to other drawers’ tables (write restriction is application-enforced, not OS-enforced — a code-execution attacker could bypass it). The blind replica remains secure. Mitigation: dependency auditing, Play Integrity, device revocation for the compromised device, key rotation for affected sync groups.

Scenario: Compromised ephemeral relay. Transport layer breached (Ring 1 holds). Application layer unaffected on all devices. The attacker sees encrypted blobs, routing metadata, connection patterns, and IP addresses (if not behind Cloudflare). They cannot decrypt any payload. They could delete blobs (denial of service) or inject spurious encrypted blobs (which will fail AEAD authentication on the client and be rejected). Mitigation: relay monitoring, Cloudflare edge protection, multi-relay redundancy.

Scenario: Compromised blind replica server. Transport layer Rings 2 and 3 potentially breached (if attacker has running process access, Ring 3’s volume is mounted). Ring 1 holds. The attacker obtains the complete encrypted blob archive for all sync groups. To read plaintext, they must brute-force the user’s passphrase through Argon2id. Application layer unaffected on all devices. Mitigation: the three-ring model, strong passphrase guidance, OPRF for enterprise tier.

Scenario: Lost/stolen phone. Application layer compromise scope depends on subscription tier. If the phone is locked and key material is in Android Keystore / iOS Secure Enclave, the attacker cannot extract GroupSecrets without biometric or PIN. If they bypass the lock screen: free-tier users lose one drawer’s data; sync subscribers lose the full filing cabinet (all six drawers populated in every app). They cannot access the blind replica or other devices. Mitigation: device revocation to rotate affected groups’ keys, remote wipe via MDM for enterprise.

Scenario: Nation-state harvest-now-decrypt-later. Attacker captures all wire traffic and obtains disk images from the hosting provider. Transport layer Ring 2 (hybrid PQ transport) blocks decryption of captured traffic. Ring 3 (hybrid PQ volume) blocks decryption of disk images. Ring 1 (symmetric E2E) blocks decryption of individual blobs even if Rings 2 and 3 are broken by a future quantum computer (Grover’s reduces XChaCha20 to 128-bit effective — still infeasible). Application layer is not relevant to this scenario.

4.3 Residual Risks at the Seam

The sync-client is the single component that bridges both layers. Risks at this seam:

Memory residue. After decryption, plaintext exists in Rust heap memory until explicitly zeroed or deallocated. Audit finding XC-001 notes that Zeroize is not yet applied to all key types in sync-core and sync-content. Plaintext in memory is accessible to a same-process attacker (desktop) or an attacker who achieves code execution in the Rust process (all platforms).

IPC/FFI serialisation. Plaintext crossing the IPC/FFI boundary is briefly held in the serialisation buffer. On desktop (Tauri IPC), this is a JSON-serialised string in the WebView’s process memory. On mobile (UniFFI JNI/FFI), this is a native type in Kotlin/Swift heap. In both cases, the plaintext exists outside Rust’s control for the duration of the UI’s use of it.

Timing side channels. Sync operations (push/pull) reveal timing information: when the user is active, how frequently they sync, how much data they generate. This is inherent to any sync system and is visible to the relay, the network path, and the blind replica. PADME padding (specified in the protocol) can mitigate size-based analysis but not timing-based analysis.

---

5. Device Hierarchy and Recovery

5.1 The Filing Cabinet Model

Recovery flows downward. Each layer can be rebuilt from the one above it. The blind replica is the root of trust for data availability. The user’s passphrase is the root of trust for data confidentiality.

5.2 Recovery Scenarios

Scenario	Recovery Path	Blind Replica Involved?
Lost phone	Pair new phone from desktop (QR)	No
Lost desktop, phones intact	Pair new desktop from blind replica, re-pair phones	Yes
All devices lost	Pair new desktop from blind replica, then pair phones	Yes
Forgotten passphrase	Irrecoverable by design	N/A

The passphrase is the single point of recovery and the single point of irrecoverable failure. This is deliberate: any recovery mechanism that bypasses the passphrase would also bypass the encryption, creating a backdoor. Users are informed of this during onboarding. OPRF (optional, enterprise tier) adds relay-cooperative brute-force resistance but does not enable passphrase-less recovery.

---

6. Adversary Model

6.1 Adversary Classes

Class 1 — Opportunistic. Script kiddie, automated scanner. Targets exposed services. Stopped by standard hardening: Cloudflare edge, rate limiting, SSH key auth, non-default ports. Neither layer is at meaningful risk.

Class 2 — Targeted. Motivated individual targeting a specific user. May attempt device theft, phishing, targeted malware, or social engineering for the passphrase. Application layer defences (platform sandbox, hardware key storage, biometrics) are the primary barriers. Transport layer Ring 1 is the secondary barrier if device secrets are extracted.

Class 3 — Institutional. Corporation, law enforcement, intelligence agency. Can compel hosting providers, seize devices, and conduct forensic analysis. Transport layer three-ring model is the primary defence. Application layer hardware key storage (mobile) resists forensic extraction. Desktop file-based keys are vulnerable to device seizure with same-user process execution.

Class 4 — Nation-state / Quantum. State actor with current or future quantum capability. Harvest-now-decrypt-later is the primary threat model. Transport layer Rings 2 and 3 (hybrid PQ) are designed specifically for this adversary. Ring 1 (symmetric, 128-bit effective under Grover’s) holds independently. The blind replica’s long-term retention makes this adversary class operationally relevant rather than theoretical.

6.2 What Each Adversary Gets on Full Success

Adversary	Compromises	Gets	Does Not Get
Class 1	Nothing (stopped at perimeter)	Nothing	Everything
Class 2	One device	One drawer’s plaintext (mobile free tier) or all drawers (mobile subscriber / desktop)	Other devices’ data, blind replica data, other users
Class 3	Device + hosting provider	Encrypted blob archive + one device’s plaintext (if seized running)	Plaintext of uncompromised devices, passphrase (if strong)
Class 4	Everything captured today	Nothing today; Ring 1 plaintext in 10-30 years IF quantum breaks AND Grover’s halving is sufficient AND Argon2id passphrase is brute-forced	Ring 1 holds independently — 128-bit symmetric is beyond projected quantum capability

---

7. Remaining Security Work

Ordered by impact on the overall system security posture.

7.1 Critical — Before GA

Item	Layer	Impact	Status
Integrate clatter (Ring 2)	Transport	Enables hybrid PQ transport. Without this, blind replica wire traffic is quantum-vulnerable.	✅ Implemented (F-002 resolved)
Implement Ring 3 volume encryption	Transport	Protects blind replica at rest against physical seizure and provider compulsion.	Not yet implemented
Wire global rate limiter (SR-001)	Transport	Prevents aggregate DDoS from many clients. Implemented and tested but not connected to request path.	Code complete, wiring needed

7.2 High — Before Production Scale

Item	Layer	Impact	Status
Device revocation (CL-001)	Both	Compromised device continues pulling data until manually removed. Policy gap.	Not yet implemented
Android Keystore integration	Application	Hardware-backed key storage for GroupSecrets on Android.	Architecture specified, implementation pending
iOS Secure Enclave integration	Application	Hardware-backed key storage for GroupSecrets on iOS.	Architecture specified, implementation pending
Zeroize on key types (XC-001)	Application	Key material may linger in memory after use on all platforms.	Root types implemented (GroupSecret, GroupKey, NoiseKeypair). Derived copies and FFI boundaries have remaining gaps.

7.3 Medium — Before Enterprise Tier

Item	Layer	Impact	Status
OPRF passphrase hardening	Transport	Eliminates offline dictionary attacks on passphrase-derived keys. Adds relay trust dependency.	Research complete, opaque-ke crate identified
IPC plaintext minimisation	Application	Reduces blast radius of UI-layer compromise across all platforms.	Design principle specified, per-app implementation needed
TEE deployment (Ring 4)	Transport	Hardware memory encryption for blind replica runtime.	Architecturally ready, waiting on hardware maturity

---

8. Compliance Implications

The two-layer model simplifies regulatory compliance because the transport layer’s zero-knowledge property reduces the scope of what constitutes “personal data processing” on infrastructure.

GDPR. The blind replica stores encrypted blobs it cannot decrypt. Under the GDPR’s definition of personal data (information relating to an identifiable natural person), encrypted data where the controller does not hold the decryption key has a reduced compliance burden. The relay operator is a processor of encrypted data, not a controller of personal data. Data subject access requests and right-to-erasure requests are fulfilled by the client application, not the relay.

EU AI Act. The Context Engine (cross-drawer AI insights) operates locally on the desktop vault. No personal data is sent to external AI services. The AI processes plaintext that exists only in the application layer, on the user’s device, under their control. The transport layer never carries AI-processed outputs in plaintext.

HIPAA (potential). For health-related data (potential Regime Tracker integration), the three-ring model on the blind replica may satisfy encryption-at-rest and encryption-in-transit requirements. The zero-knowledge relay model means the hosting provider does not have access to protected health information, simplifying Business Associate Agreement requirements.

---

9. Summary

The VardKista security model is two independent layers that compose without dependency.

The application layer provides platform-appropriate protection for the runtime environment: CEF sandbox on desktop, OS-level app sandbox with hardware key storage on mobile. Mobile is inherently stronger (no JS engine, hardware keys, per-app isolation). Desktop is the operational hub with a larger trust surface but operates in a physically controlled environment.

The transport layer provides three independent cryptographic rings protecting data in transit and at rest on infrastructure: E2E encryption (Ring 1, implemented and audited), hybrid PQ transport (Ring 2, integration pending), and hybrid PQ volume encryption for the blind replica (Ring 3, specified). Two rings are hybrid quantum-resistant. One is inherently quantum-resistant by the properties of symmetric cryptography.

No single compromise — of any device, any relay, any hosting provider, or any single cryptographic primitive — exposes plaintext to an attacker. The layers are designed so that each one must be defeated independently, and each one alone is sufficient to protect the user’s data.