Security & Cryptography Architecture
A rigorous technical specification of FINLOG's zero-knowledge encryption protocols, threat mitigation strategies, and mathematical verification guarantees.
1. Zero-Knowledge Cryptographic Model
In conventional consumer fintech software, user financial records are ingested and indexed in plaintext on remote servers. This introduces catastrophic single points of failure, exposing users to server intrusions, rogue employees, and regulatory subpoenas.
FINLOG eliminates remote financial exposure by operating as a Zero-Knowledge Local-First Architecture:
- Financial balances, transaction descriptions, Money Spaces, and physical cash counts exist exclusively on user hardware.
- When data is synchronized or backed up to remote storage (Supabase), it is transformed into an encrypted ciphertext envelope prior to transmission.
- The encryption and decryption keys never touch our servers. FINLOG engineers and cloud hosting providers cannot read your personal financial records under any circumstances.
2. Cryptographic Primitives & Parameters
FINLOG implements strictly audited, industry-standard cryptographic algorithms:
| Operation | Algorithm & Specification | Parameters |
|---|---|---|
| Symmetric Cipher | AES-256-GCM (Galois/Counter Mode) | 256-bit key length; 96-bit unique IV per snapshot; 128-bit authentication tag |
| Key Derivation | PBKDF2-HMAC-SHA256 | 100,000 iterations; 256-bit cryptographically secure random salt |
| Integrity Hashing | SHA-256 (Secure Hash Algorithm 2) | 64-character deterministic hex digest for tamper verification |
| Session Authentication | RS256 / Ed25519 signed JWT | Issued by Clerk; validated cryptographically using published JWKS endpoints |
3. Hardware Keychain Isolation
On iOS, encryption keys are generated on-device via Expo Crypto and persisted directly to the iOS Keychain via Expo SecureStore.
The storage key is protected by the native flag:
kSecAttrAccessibleWhenUnlockedThisDeviceOnly.
This guarantees:
- The key is only accessible when the user has unlocked the device with their passcode, Face ID, or Touch ID.
- The key does not migrate across devices during iTunes or iCloud unencrypted backups.
- Other mobile apps on the device cannot access FINLOG's keychain space due to iOS application sandbox isolation.
4. Threat Analysis & Mitigation Matrix
| Threat Scenario | Vulnerability Potential | FINLOG Cryptographic Mitigation |
|---|---|---|
| Cloud Database Breach | Attacker gains root access to Supabase database. | Zero Impact: Database stores only AES-256 ciphertext envelopes. Zero plaintext financial data or keys exist in the cloud. |
| Physical Phone Theft (Locked) | Attacker acquires physical phone while locked. | Protected: SecureStore hardware key is inaccessible while device is locked. Biometric / passcode required. |
| Man-in-the-Middle (MITM) | Attacker intercepts network traffic on public Wi-Fi. | Protected: Strict TLS 1.3 encryption, HSTS headers, and PII-sanitized AI payloads. |
| Tampered Backup Restoration | Attacker alters ciphertext in transit to inject transactions. | Rejected: AES-GCM authentication tag and SHA-256 checksum mismatch causes instant client-side decryption rejection. |
5. Automated Test Verification & Audit Record
FINLOG's cryptographic and balance integrity engines are subjected to continuous automated test suites:
380 automated tests across 14 test suites pass cleanly with 0 failures, verified on Node.js and compiled iOS Simulator environments.
Key verified test files include:
tests/vaultSync.test.ts: Verified AES-256-GCM roundtrip encryption, invalid secret key rejection, and tampered ciphertext detection.tests/momoImport.test.ts: Verified on-device MoMo PDF statement extraction, PII redaction, and pesewa integer precision math.tests/store.test.ts: Verified atomic stack transfers, net-zero balance variance, and isolated store hydration.tests/finlogAI.test.ts: Verified prompt guardrails, out-of-scope question rejection, and token counter increments.