Hermetic End-to-End Encryption (E2EE)
Hermetic E2EE is TideCloak's approach to ensuring that sensitive data can only be decrypted by the authorized user session, and remains permanently inaccessible to everyone else, including administrators, cloud providers, Tide, and attackers who compromise servers. It means, a stolen token no longer poses a risk, as its utility is bound to the device the user successfully authenticated from.
The Data Exposure Problem
Traditional encryption strategies protect data at rest and in transit, but leave a critical gap: the moment of use.
Conventional Approach
- Encrypted at rest: Data is encrypted in the database (e.g., AES-256)
- Encrypted in transit: Data is encrypted during transmission (e.g., TLS)
- Decrypted for use: When a user requests data, the server decrypts it and sends it to the user
The vulnerability:
- Server-side decryption: The server holds the decryption key. Anyone who compromises the server (attacker, malicious admin, cloud provider) can decrypt the data.
- Admin access: Database administrators or those with root access can decrypt data at will.
- Vendor backdoors: The service provider can access plaintext data.
- Memory dumps: Even if disk encryption is perfect, data in server memory during processing can be extracted.
The result: You must trust the server, the administrators, the cloud provider, and the vendor not to abuse access. This is antithetical to Zero Trust principles.
The Hermetic E2EE Solution
Hermetic E2EE ensures that data is sealed to the user's session key, which exists only in the user's browser or application (TPM), never on any server, and never held by any other party.
Core principles:
- Ephemeral session keys: Generated on the user's device during successful authentication, exist only in memory, never transmitted
- Data sealed at the edge: Data is encrypted such that only the user's session key can decrypt it
- No server-side plaintext: Servers never hold decrypted data or the keys to decrypt it
- Hermetic seal: Even if an attacker compromises the entire infrastructure, they cannot decrypt data without the user's ephemeral session key, which no longer exists after the session ends
How Hermetic E2EE Works
End-to-End Flow
The Hermetic E2EE process integrates authentication, authorization, and data access into a single cryptographic chain:
1. Provable Authentication (BYOiD)
When: User logs in
What happens:
- The user's identity is verified through TideCloak's BYOiD protocol
- BYOiD performs zero-knowledge authentication against the Cybersecurity Fabric
- No single entity (including TideCloak) can verify the user's credentials; this requires threshold cooperation from independent Fabric nodes
Result: A cryptographic proof that the user is authenticated, without revealing credentials to any party.
2. Ephemeral Session Key Generation
When: During user authentication (BYOiD login)
What happens:
- A unique, random session key is generated in the Secure Web Enclave (SWE) in the user's browser
- This key exists only in browser memory (i.e. the user's device TPM), it is never written to disk or transmitted over the network
- The key is bound to the specific browser tab/session and is destroyed when the session ends
Security property: The session key is unknowable to anyone except the user's device at that moment.
3. Quorum-Enforced Authorization
When: The authenticated user requests access to resources
What happens:
- TideCloak consults authorization policies (roles, permissions, scopes) that have been cryptographically approved by an administrator quorum
- The Fabric verifies these policies and generates an authorization token (JWT) signed with a distributed key
- No single administrator or server can forge or tamper with these tokens
Security property: Authorization is provably correct and cannot be bypassed by rogue admins or compromised servers.
See: Quorum Enforced Governance for details.
4. Sealed Authorization Token
When: Authorization is granted
What happens:
- The authorization token (JWT) is encrypted to the user's ephemeral session key
- This token contains the user's roles, permissions, and session metadata
- The encrypted token is sent to the user's browser
Security property: Only the user's session can decrypt and use this token. Even if an attacker intercepts it, they cannot read or use it without the session key.
5. Data Decryption at the Edge
When: The user requests sensitive data (e.g., a file, a database record, a secret)
What happens:
- The data is stored encrypted with an Ineffable Key (a key split across Fabric nodes)
- The Fabric decrypts the data using threshold cryptography (no single node holds the full decryption key)
- Instead of sending plaintext to the server, each Fabric node proxy re-encrypts a payload to the user's ephemeral session key
- The encrypted data is transmitted to the user's browser
- Only the user's session key can decrypt it
Security property: The data is never exposed in plaintext on any server or network. It exists in plaintext only in the user's browser memory, on the user's device they authenticaed from.
6. Hermetic Seal
Result of the complete flow:
- Data is decrypted only at the user's edge (browser or client app)
- The decryption key (ephemeral session key) exists only on the user's device, only during the session
- After the session ends, the key is destroyed, making the data permanently inaccessible to anyone, even the user (who must re-authenticate to access another one)
Data Flow Diagram
┌─────────────────────────────────────────────────────────────────────┐│ User's Browser (Secure Web Enclave) ││ ││ 1. Generate ephemeral session key (ESK) in memory ││ 2. Authenticate via BYOiD (zero-knowledge proof to Fabric) ││ 3. Receive encrypted authorization token, decrypt with ESK ││ 4. Request data from TideCloak ││ │└──────────────────────────┬───────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────────────┐│ TideCloak Server ││ ││ • Receives data request with authorization token ││ • Forwards request to Cybersecurity Fabric for decryption ││ • Does NOT decrypt data itself (has no keys) ││ • Returns encrypted-to-ESK data to user ││ │└──────────────────────────┬───────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────────────┐│ Cybersecurity Fabric (Distributed Nodes) ││ ││ 1. Verify authorization token signature (threshold signature) ││ 2. Decrypt data using threshold decryption (Ineffable Key) ││ 3. Re-encrypt decrypted data to user's ESK ││ 4. Return encrypted-to-ESK data + zero-knowledge proof ││ │└──────────────────────────┬───────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────────────┐│ User's Browser (Secure Web Enclave) ││ ││ 5. Receive encrypted-to-ESK data ││ 6. Verify zero-knowledge proof ││ 7. Decrypt data with ESK (plaintext exists only here) ││ 8. Display data to user ││ │└─────────────────────────────────────────────────────────────────────┘
Security Properties
1. No Server-Side Plaintext
Traditional systems: Data is decrypted on the server before being sent to the user.
Hermetic E2EE: Data is decrypted by the Fabric and immediately re-encrypted to the user's session key. The plaintext never exists on any server, only on the user's device.
Implication: An attacker who compromises TideCloak or the application server gains access only to encrypted data they cannot decrypt.
2. No Admin Access
Traditional systems: Database admins, root users, or platform admins can query and decrypt data.
Hermetic E2EE: Admins can see encrypted data, but they cannot decrypt it. They don't have the user's ephemeral session key, and they cannot compel the Fabric to decrypt data (because the Fabric verifies authorization against quorum-approved policies).
Implication: Insider threats are neutralized. Rogue admins cannot exfiltrate sensitive data.
3. Breach Containment
Traditional systems: A server breach often exposes decryption keys, allowing attackers to decrypt all stored data.
Hermetic E2EE:
- The server holds no decryption keys (they're distributed across the Fabric)
- Even if an attacker steals encrypted data, they cannot decrypt it without:
- Compromising a threshold of independent Fabric nodes (difficult)
- AND stealing the user's ephemeral session key (which no longer exists after the session ends)
Implication: Breaches yield encrypted data with no feasible way to unlock it.
4. Forward Secrecy
Traditional systems: If a long-term key is compromised, all data encrypted with that key (past and future) is exposed.
Hermetic E2EE:
- Each session uses a unique ephemeral key
- Session keys are destroyed when sessions end
- Even if a Fabric key is somehow compromised in the future, past sessions remain secure (because their ephemeral keys no longer exist)
Implication: Time-limited exposure. Compromising today's session doesn't compromise yesterday's.
5. Verifiable Security
Traditional systems: You must trust the server performed encryption/decryption correctly.
Hermetic E2EE:
- Every operation includes a zero-knowledge proof
- Users (or auditors) can verify:
- Authentication was performed correctly
- Authorization policies were enforced
- Data was decrypted and re-encrypted properly
- No malicious party tampered with the process
Implication: Trust is replaced with cryptographic verification.
Use Cases
Hermetic E2EE is ideal for scenarios where data sensitivity is paramount:
- Healthcare: Patient data must be accessible only to authorized medical staff or patients care circle
- BFSI: Financial transactions, account balances, and sensitive customer info must be protected from insider threats
- Legal: Confidential legal documents must be protected from unauthorized access, including by the cloud provider
- Government and Defense: Classified information must be protected from insider threats, foreign adversaries, and infrastructure compromise
- Secrets management: Password manager ensures passwords only visible to user at time
- Corporate Secrets: Trade secrets, R&D data, and IP must be protected from exfiltration by employees or hackers
Unique advantages of Hermetic E2EE:
- No key custody: Unlike client-side E2EE (e.g., Signal, WhatsApp), users don't need to manage or back up keys. The Fabric handles key operations while keys remain inaccessible.
- Enterprise usability: Unlike consumer E2EE tools, Hermetic E2EE supports enterprise features (admin management, policy enforcement, audit logs) without sacrificing security.
- Provable security: Unlike trust-based systems, Hermetic E2EE provides cryptographic proofs of correct operation.
- Self sovereignty & Privacy Guarantees: Private data can be provably inaccessible to anyone but the owner.
Integration with TideCloak
Hermetic E2EE is automatically enabled when using TideCloak with the Cybersecurity Fabric. Developers don't need to implement additional encryption logic; it happens transparently.
For Application Developers
No changes required:
- Integrate TideCloak using standard OIDC/OAuth flows
- Request data via TideCloak's APIs
- Data is automatically sealed to the user's session
What you get:
- Data encrypted end-to-end to the user's device
- No plaintext data on your servers
- Protection against admin compromise, server breaches, and vendor backdoors
For End Users
No changes required:
- Log in as usual (BYOiD handles authentication transparently)
- Access data normally
- Data is automatically decrypted in the browser
What users get:
- Confidence that their data is protected even if the service provider is compromised
- Verifiable proof that security measures are in place (via zero-knowledge proofs)
Limitations and Considerations
Performance
-
Latency: Hermetic E2EE adds minor cryptographic overhead.
-
Network dependency: Hermetic E2EE requires Fabric connectivity. Offline access is not supported by design, since offline decryption would require storing keys locally, which defeats the security model.
Summary
Hermetic E2EE solves the fundamental problem of data exposure in traditional systems:
| Traditional Encryption | Hermetic E2EE |
|---|---|
| Data decrypted on server | Data decrypted only on user's device |
| Server holds decryption keys | Keys inaccessible to everyone |
| Admins can access data | Admins cannot decrypt data |
| Server breach exposes keys | Breach exposes only encrypted data |
| Trust the provider | Verify cryptographically |
| Long-term keys (rotation risk) | Ephemeral session keys (forward secrecy) |
The bottom line: Hermetic E2EE ensure's sensitive data is inaccessible to anyone except the authorized user's session, even if they compromise the server, the database, or the cloud provider. It's the ultimate expression of Zero Trust: don't trust anyone, verify everything, and ensure that breaches yield nothing of value.