Skip to main content

​
FNP - Security - End-to-End Encryption & Zero Trust Architecture

​
Summary (Explain Like I’m 5)

Imagine you send a secret love letter through the postal service:
  • Without encryption: Mailman reads it ✗ (privacy violation)
  • With encryption: Mailman sees only gibberish 🔒 (privacy preserved)
  • FNP way: Mailman is NEVER trusted. Letter encrypted before mailman sees it. Even if mailman gets hacked, letter stays secret ✓
Zero Trust principle: “Never trust, always verify.” Every request is authenticated, every message is encrypted, every proof is verified - regardless of source.

​
Technical Deep Dive

End-to-End Encryption (E2EE) in FNP: 
Layer 1: Transport Security (TLS 1.3)
  - All traffic encrypted in transit (client → server)
  - Mutual TLS (mTLS): client verifies server certificate
  - Server verifies client certificate (mutual authentication)
  - Prevents man-in-the-middle attacks

Layer 2: Application Encryption (Kyber-1024)
  - Each user has unique Kyber keypair
  - Document content encrypted under Kyber
  - Server NEVER holds Kyber secret keys
  - Even if server is compromised, content remains encrypted

Layer 3: Position Encryption (M²-ORE)
  - Character positions encrypted under M²-ORE
  - Server can determine ordering without decryption
  - Position keys rotated monthly
  - No position leakage to untrusted parties

Layer 4: Proof Verification (Halo2)
  - Operations proven correct via zero-knowledge
  - Server verifies without accessing secrets
  - Forged operations rejected mathematically
  - Replay attacks detected via operation IDs

Layer 5: Authentication (Dilithium)
  - Each operation signed with user's Dilithium key
  - Server verifies signature (non-repudiation)
  - Users can't deny sending operation
  - Invalid signatures rejected immediately
Zero Trust Security Model: 
Traditional Trust Model:
  User --(trust)--> Firewall --(trust)--> Server
  ✗ Problem: Breach inside firewall compromises everything

FNP Zero Trust Model:
  User --(verify TLS + Dilithium)--> Firewall
  Firewall --(verify Halo2 proof)--> Server
  Server --(verify mTLS + Lamport clock)--> Client

  ✓ Every connection verified
  ✓ Every message authenticated
  ✓ Cryptographic proofs required
  ✓ No implicit trust ever granted
Secret Key Management: 
Client-Side Key Storage:
  - Kyber_sk: Stored in device secure enclave (iOS/Android)
  - M2ORE_sk: Stored in encrypted local storage
  - Dilithium_sk: Never exported; only signs on device
  - All keys: AES-256 encrypted at rest with biometric protection

Server-Side Key Storage:
  - Kyber_pk[user_i]: Stored unencrypted (public key)
  - M2ORE_pk[user_i]: Stored unencrypted (public key)
  - Dilithium_pk[user_i]: Stored unencrypted (public key)
  - ✓ Server holds ONLY public keys; no secrets!

Key Rotation Policy:
  - Kyber keypair: 1 year rotation (post-quantum slow rotation)
  - M²-ORE key: 1 month rotation (ephemeral ordering)
  - Dilithium key: 6 month rotation (signatures)
  - Forward secrecy: old rotated keys archived separately

Key Compromise Response:
  - User revokes compromised key (marked invalid)
  - New operations signed with new key
  - Historical document state remains encrypted
  - New key can decrypt new operations only
Access Control & Sharing: 
Document Access Model:
    document_id: "doc-12345"
    owner: alice@example.com
    access_list:
        - user: alice@example.com
          permissions: [read, write, delete, share]
          kyber_sk: [has alice's key]
          encrypted_keys: null # owner holds all keys

        - user: bob@example.com
          permissions: [read, write]
          kyber_sk: [doesn't have alice's key for past edits]
          encrypted_keys:
              - {
                    key_id: "kyber_pk_alice_2025",
                    encrypted_sk: "AES.Enc(bob_kyber_pk, alice_kyber_sk_encrypted_by_share_secret)",
                }
          # Bob gets encrypted version of Alice's key (via DHKE)

        - user: charlie@example.com
          permissions: [read-only]
          can_decrypt: false # Charlie sees only encrypted content

Share Operation (Alice → Bob): 1. Alice generates ephemeral ECDH keypair
    2. Alice computes shared_secret = ECDH(alice_ephemeral_sk, bob_kyber_pk)
    3. Alice encrypts her Kyber_sk under shared_secret
    4. Alice sends encrypted key to Bob via server
    5. Bob uses ECDH to recover shared_secret
    6. Bob decrypts Alice's Kyber_sk
    7. Bob can now decrypt Alice's content
Attack Surface Analysis: 
Threat Model:

1. Server Compromise
   - Attacker gains admin access to FNP server
   - Attacker can: read operation logs, modify proofs, steal public keys
   - Attacker CANNOT: decrypt document content (no Kyber_sk)
   - Impact: Operation history compromised, content remains safe
   - Mitigation: immutable audit logs, cryptographic proof verification

2. Network Eavesdropping
   - Attacker intercepts traffic (e.g., ISP, WiFi hacker)
   - Attacker can: see encrypted operations, observe timing
   - Attacker CANNOT: decrypt content or derive keys
   - Impact: operation existence leaked, content confidential
   - Mitigation: TLS 1.3 + padding to hide operation size

3. Client Device Compromise
   - Attacker gains access to Alice's phone (stolen)
   - Attacker can: access Kyber_sk, M2ORE_sk from secure enclave
   - Attacker CANNOT: attack other users' keys
   - Impact: Alice's document content and position compromised
   - Mitigation: device biometric lock, key destruction on failed unlock

4. Quantum Threat (Harvest Now, Decrypt Later)
   - Adversary records encrypted traffic today
   - Adversary waits for quantum computer (2030-2040)
   - Adversary can: break Kyber encryption? (No!)
   - Kyber is post-quantum: quantum computer won't break it
   - Impact: mitigated by choice of Kyber-1024
   - Mitigation: already deployed post-quantum crypto

​
Mermaid Diagrams

​
Key Terms

  • E2EE → End-to-End Encryption; only endpoints (users) can decrypt content
  • Zero Trust → Never trust, always verify; every request authenticated, proven, verified
  • Mutual mTLS → Both client and server authenticate each other via certificates
  • Forward Secrecy → Compromise of long-term key doesn’t compromise past sessions
  • Non-repudiation → Signer can’t deny signing operation (Dilithium signature)
  • Replay Attack → Attacker resends old valid operation; prevented by Lamport clock + operation ID
  • Key Rotation → Periodic regeneration of cryptographic keys (Kyber: 1yr, M²-ORE: 1mo)
  • Secure Enclave → Tamper-resistant hardware on phone stores keys

​
Q/A

Q: If the server gets hacked, isn’t my document exposed? A: No. Server has only public keys and encrypted operations. Attacker can’t decrypt content (needs Kyber_sk which is on your device only). Operation history might be leaked, but content remains encrypted permanently. Q: What if someone steals my phone? A: Phone is locked with biometric (Face ID/fingerprint). Keys are in secure enclave, which wipes keys after ~10 failed unlock attempts. Thief sees encrypted document. If they somehow bypass security, they only access your content, not other users’. Q: Can the server replay an old operation I sent? A: No. Lamport clock + timestamp + operation ID prevent replays. If server retransmits operation 1, clients detect duplicate (same Lamport clock) and reject. Even forging a new timestamp would require new Dilithium signature (cryptographically hard). Q: What about quantum computers breaking Kyber? A: Kyber is specifically designed to resist quantum attacks. Built on lattice problems (LWE) that don’t have known polynomial-time quantum algorithms. Even hypothetical quantum computer can’t break it faster than classically. Q: Is TLS 1.3 sufficient encryption? A: TLS 1.3 is strong but server can read plaintext if compromised. FNP adds application-layer encryption (Kyber) on top, so even TLS compromise doesn’t leak content. Defense in depth. Q: How are shared documents secured? A: Sharer and sharee perform ECDH key exchange. Sharer encrypts their Kyber_sk under shared_secret. Sharee uses ECDH to recover shared_secret and decrypt the key. Only intended sharee can decrypt.

​
Example / Analogy

Bank Vault Analogy: Traditional E-mail (No E2EE):
  • Send secret message via mail
  • Post office (server) reads it
  • Anyone at post office sees content ✗
With TLS Only:
  • Message in sealed envelope
  • Post office can’t read in transit
  • But post office opens envelope at destination ✗
With FNP (E2EE + Zero Trust):
  • Message in locked box
  • Box key only on sender and recipient’s devices
  • Post office has box but can’t open it ✓
  • Post office must verify your signature before accepting ✓
  • Post office can’t fake your signature (Dilithium) ✓
  • Even if post office is robbed, box remains locked ✓
Cross-References: Kyber-1024, M²-ORE Encryption, Halo2 Circuits, LSEQ CRDT Category: Security | Cryptography | Privacy | Trust Difficulty: Advanced ⭐⭐⭐⭐ Updated: 2025-11-28