How Fidaro Works
Introduction
Fidaro secures your AI conversations through a multi-layered architecture that ensures your messages remain private at every stage. Unlike traditional AI services where your conversations pass through company servers in readable form, Fidaro encrypts your data before it leaves your device and maintains that encryption through every step of processing. The system combines hardware-isolated secure enclaves, cryptographic key derivation, and architectural separation to create a service where we genuinely cannot read your messages, even if we wanted to.
This approach addresses a fundamental problem with most AI services today: you have to trust that companies won't look at your data, won't be breached, and won't be compelled to hand over your information. Fidaro replaces trust with mathematics and hardware. Privacy isn't enforced by policy - it's enforced by system design.
This approach addresses a fundamental problem with most AI services today: you have to trust that companies won't look at your data, won't be breached, and won't be compelled to hand over your information. Fidaro replaces trust with mathematics and hardware. Privacy isn't enforced by policy - it's enforced by system design.
1. The Secure Enclave: Hardware-Backed Privacy
At the heart of Fidaro's security model is an AWS Nitro Enclave, a hardware-isolated computing environment that runs completely separately from the rest of our infrastructure. Think of it as a vault built into our servers, one that even we cannot open. The enclave has no network access, no persistent storage, and no debugging tools. Administrators, engineers, and even our infrastructure providers cannot access what happens inside this protected environment.
The enclave handles the most sensitive cryptographic operations in our system. When your device needs to derive encryption keys or establish secure sessions, it communicates with the enclave through a tightly controlled interface. The enclave processes these requests without storing any data and without exposing the operations to the outside world. This hardware isolation means that even if our primary infrastructure were compromised, the cryptographic operations inside the enclave would remain protected.
What makes this particularly powerful is that the enclave isn't just isolated - it's verifiable. Before your device trusts the enclave with any sensitive operation, it demands cryptographic proof that the enclave is genuine and hasn't been tampered with. This verification process, called attestation, ensures you're not just trusting our promises about security. You're trusting mathematics and hardware.
The enclave handles the most sensitive cryptographic operations in our system. When your device needs to derive encryption keys or establish secure sessions, it communicates with the enclave through a tightly controlled interface. The enclave processes these requests without storing any data and without exposing the operations to the outside world. This hardware isolation means that even if our primary infrastructure were compromised, the cryptographic operations inside the enclave would remain protected.
What makes this particularly powerful is that the enclave isn't just isolated - it's verifiable. Before your device trusts the enclave with any sensitive operation, it demands cryptographic proof that the enclave is genuine and hasn't been tampered with. This verification process, called attestation, ensures you're not just trusting our promises about security. You're trusting mathematics and hardware.
2. Attestation: Cryptographic Proof Before Trust
Attestation is how your device verifies the enclave's authenticity before sending any sensitive data. When you first connect to Fidaro, your browser requests an attestation document from the enclave. This document contains cryptographic measurements of the exact code running inside the enclave, signed by the enclave's hardware. Think of it like a passport that can't be forged - it proves not just that the enclave exists, but that it's running the specific code we published and hasn't been modified.
Your device verifies this attestation document using the hardware manufacturer's public certificates. It checks that the enclave's code matches the published version, that the hardware signature is valid, and that the measurements haven't been tampered with. If any of these checks fail - if the code has been altered, if the signature is invalid, or if something looks suspicious - your device refuses to connect. Only after successful verification does your browser proceed with establishing encrypted communications.
This verification happens automatically before every session and ensures that you're not placing blind trust in our infrastructure. The attestation document provides cryptographic proof that the enclave is genuine and running trusted code. It's a fundamental shift from "trust us" to "verify for yourself" through mathematics that can't be faked.
Your device verifies this attestation document using the hardware manufacturer's public certificates. It checks that the enclave's code matches the published version, that the hardware signature is valid, and that the measurements haven't been tampered with. If any of these checks fail - if the code has been altered, if the signature is invalid, or if something looks suspicious - your device refuses to connect. Only after successful verification does your browser proceed with establishing encrypted communications.
This verification happens automatically before every session and ensures that you're not placing blind trust in our infrastructure. The attestation document provides cryptographic proof that the enclave is genuine and running trusted code. It's a fundamental shift from "trust us" to "verify for yourself" through mathematics that can't be faked.
3. Password Security: OPRF and Local Key Derivation
Your password is the key to your encrypted data, but it never leaves your device in a form we can see. When you create an account or log in, Fidaro uses a cryptographic technique called Oblivious Pseudorandom Function, or OPRF. This protocol allows the enclave to help derive encryption keys from your password without ever learning what that password is.
Here's how it works: Your device takes your password and "blinds" it - essentially scrambling it using random data that only your device knows. This blinded password is sent to the enclave, which processes it mathematically and returns the result. Your device then "unblinds" this result using the same random data from earlier, producing encryption keys that exist only on your machine. The enclave helped with the computation but never saw your actual password at any point in the process.
This approach has several critical security properties. First, we can't recover your password because we never received it - we only saw the blinded version, which is useless without your device's random blinding factor. Second, if someone captured the blinded data in transit, they couldn't reverse-engineer your password without also capturing your device's random blinding factor. Third, the enclave won't help attackers try billions of password guesses because each guess requires your device to blind it first. The result is that your encryption keys are derived locally on your machine through a process where we genuinely cannot see your password, and your password becomes the cryptographic key to all your encrypted data.
Here's how it works: Your device takes your password and "blinds" it - essentially scrambling it using random data that only your device knows. This blinded password is sent to the enclave, which processes it mathematically and returns the result. Your device then "unblinds" this result using the same random data from earlier, producing encryption keys that exist only on your machine. The enclave helped with the computation but never saw your actual password at any point in the process.
This approach has several critical security properties. First, we can't recover your password because we never received it - we only saw the blinded version, which is useless without your device's random blinding factor. Second, if someone captured the blinded data in transit, they couldn't reverse-engineer your password without also capturing your device's random blinding factor. Third, the enclave won't help attackers try billions of password guesses because each guess requires your device to blind it first. The result is that your encryption keys are derived locally on your machine through a process where we genuinely cannot see your password, and your password becomes the cryptographic key to all your encrypted data.
4. Session Keys: Establishing an Encrypted Channel
Every time you start a conversation with Fidaro, your device and the enclave establish an encrypted channel using a cryptographic protocol called Noise NK. This protocol creates session keys that last for 15 minutes before expiring, generated fresh each time, never reused, never stored permanently. This design provides what cryptographers call "perfect forward secrecy" - even if future encryption keys are somehow compromised, past conversations remain secure.
The handshake works in two messages. First, your device generates a random key pair and combines it mathematically with the enclave's public key from the attestation document. This produces the first handshake message, which your device sends to the enclave. The enclave then generates its own random key pair, combines it with your device's public key, and sends back the second handshake message. After this two-message exchange, both sides have derived identical session keys without ever transmitting them. The keys exist only in your browser and inside the verified enclave - nowhere else in our infrastructure knows them.
What makes this particularly secure is that the session keys are cryptographically bound to the specific enclave your device verified during attestation. Before your device even begins the handshake, it has already verified the enclave's identity through attestation. The enclave's public key came from a signed attestation document, meaning you're not just establishing an encrypted channel with any server - you're establishing it with the specific, verified, hardware-isolated enclave running trusted code. After 15 minutes, both sides destroy the session keys. Even if an attacker breached our systems tomorrow and obtained future session keys, they couldn't use them to decrypt today's conversations. Each session stands alone, protected by keys that no longer exist.
The handshake works in two messages. First, your device generates a random key pair and combines it mathematically with the enclave's public key from the attestation document. This produces the first handshake message, which your device sends to the enclave. The enclave then generates its own random key pair, combines it with your device's public key, and sends back the second handshake message. After this two-message exchange, both sides have derived identical session keys without ever transmitting them. The keys exist only in your browser and inside the verified enclave - nowhere else in our infrastructure knows them.
What makes this particularly secure is that the session keys are cryptographically bound to the specific enclave your device verified during attestation. Before your device even begins the handshake, it has already verified the enclave's identity through attestation. The enclave's public key came from a signed attestation document, meaning you're not just establishing an encrypted channel with any server - you're establishing it with the specific, verified, hardware-isolated enclave running trusted code. After 15 minutes, both sides destroy the session keys. Even if an attacker breached our systems tomorrow and obtained future session keys, they couldn't use them to decrypt today's conversations. Each session stands alone, protected by keys that no longer exist.
5. In-Flight Encryption: Protecting Messages During Transit
When you send a message to Fidaro, it's encrypted on your device before it ever touches our network. Your browser uses the session keys to encrypt the message, producing an encrypted payload that's meaningless to anyone who doesn't have those keys. This encrypted message then travels through our infrastructure - through web servers, load balancers, and network equipment - all while remaining completely unreadable.
What makes this architecture distinctive is where decryption happens: inside the hardware-isolated enclave. Our gateway servers act as simple relays, passing encrypted data to the enclave without ever seeing its contents. The gateway doesn't have the session keys - only your browser and the enclave do. When your encrypted message reaches the enclave, it decrypts the message, sends it to the AI model for processing, then immediately encrypts the response before sending it back through the gateway. The gateway sees nothing but encrypted blobs passing through.
At no point in this process does your message exist in plain text outside your browser and the hardware-protected enclave. The gateway, our web servers, load balancers, and network equipment only ever see encrypted data they cannot decrypt. Even comprehensive infrastructure monitoring or logging wouldn't reveal message content - there's nothing to reveal. The session keys exist only in your browser and inside the enclave's protected memory, and the enclave has no network access, no persistent storage, and no way for administrators to extract those keys.
What makes this architecture distinctive is where decryption happens: inside the hardware-isolated enclave. Our gateway servers act as simple relays, passing encrypted data to the enclave without ever seeing its contents. The gateway doesn't have the session keys - only your browser and the enclave do. When your encrypted message reaches the enclave, it decrypts the message, sends it to the AI model for processing, then immediately encrypts the response before sending it back through the gateway. The gateway sees nothing but encrypted blobs passing through.
At no point in this process does your message exist in plain text outside your browser and the hardware-protected enclave. The gateway, our web servers, load balancers, and network equipment only ever see encrypted data they cannot decrypt. Even comprehensive infrastructure monitoring or logging wouldn't reveal message content - there's nothing to reveal. The session keys exist only in your browser and inside the enclave's protected memory, and the enclave has no network access, no persistent storage, and no way for administrators to extract those keys.
6. Separation of Concerns: Dividing Identity from Content
One of Fidaro's key architectural decisions is ensuring that no single system can connect your identity with your message content. This separation of concerns means that even if one part of our infrastructure were compromised, an attacker couldn't link what you're saying to who you are.
Our authentication system handles login credentials and account management. It knows your email address, manages your password-derived authentication credentials, and issues session tokens that prove you're logged in. However, this authentication system never sees your actual message content. It handles identity verification but remains completely isolated from the message processing pipeline.
Meanwhile, our gateway servers - the systems that relay your encrypted messages to the enclave - operate without identity information. Before your encrypted messages reach the gateway, our infrastructure strips away cookies, IP addresses, session identifiers, and any other metadata that could reveal who you are. The gateway sees only encrypted content that it cannot decrypt, and it has no way to determine which user submitted which message.
Our authentication system handles login credentials and account management. It knows your email address, manages your password-derived authentication credentials, and issues session tokens that prove you're logged in. However, this authentication system never sees your actual message content. It handles identity verification but remains completely isolated from the message processing pipeline.
Meanwhile, our gateway servers - the systems that relay your encrypted messages to the enclave - operate without identity information. Before your encrypted messages reach the gateway, our infrastructure strips away cookies, IP addresses, session identifiers, and any other metadata that could reveal who you are. The gateway sees only encrypted content that it cannot decrypt, and it has no way to determine which user submitted which message.
7. Encrypted Storage: Protecting Your Chat History
Your conversation history is encrypted before it's ever stored, whether on your device or synced to our servers for multi-device access. The critical security property isn't where the encrypted data lives, it's that the encryption keys needed to decrypt it exist only on your device and are derived from a password we never see.
Here's how this works: All your messages are encrypted using keys that your device derives locally through the OPRF process described earlier. Remember that your password never leaves your device in a form we can read. The encryption keys are generated from that password on your machine, which means we genuinely cannot decrypt your conversation history even if we have the encrypted data on our servers. Without your password, which we never receive, the encrypted messages are just meaningless binary data.
Your device manages these encryption keys using your browser's Web Crypto API, a security feature built into modern browsers that keeps cryptographic keys in hardware-protected memory. These browser-protected keys cannot be extracted through JavaScript, which means that even malicious browser extensions or cross-site scripting attacks cannot steal them. The browser acts as a hardware security module, protecting your encryption keys from software-based attacks.
To balance security with usability, your device maintains an active encryption session for 8 hours of activity. Each time you read or send a message, your device uses the protected encryption keys to decrypt or encrypt your messages, then immediately clears sensitive key material from memory. After 8 hours of inactivity, the session expires and you'll need to enter your password again - this triggers the OPRF process to re-derive your encryption keys and restore access to your encrypted history.
The architecture ensures that even if we wanted to read your conversation history, we couldn't. The encrypted data might live on our servers for sync purposes, but the keys to decrypt it are derived from your password through a process where we never learn that password. This separation is fundamental: we can store encrypted blobs, but those blobs are useless without keys that exist only on your device.
Here's how this works: All your messages are encrypted using keys that your device derives locally through the OPRF process described earlier. Remember that your password never leaves your device in a form we can read. The encryption keys are generated from that password on your machine, which means we genuinely cannot decrypt your conversation history even if we have the encrypted data on our servers. Without your password, which we never receive, the encrypted messages are just meaningless binary data.
Your device manages these encryption keys using your browser's Web Crypto API, a security feature built into modern browsers that keeps cryptographic keys in hardware-protected memory. These browser-protected keys cannot be extracted through JavaScript, which means that even malicious browser extensions or cross-site scripting attacks cannot steal them. The browser acts as a hardware security module, protecting your encryption keys from software-based attacks.
To balance security with usability, your device maintains an active encryption session for 8 hours of activity. Each time you read or send a message, your device uses the protected encryption keys to decrypt or encrypt your messages, then immediately clears sensitive key material from memory. After 8 hours of inactivity, the session expires and you'll need to enter your password again - this triggers the OPRF process to re-derive your encryption keys and restore access to your encrypted history.
The architecture ensures that even if we wanted to read your conversation history, we couldn't. The encrypted data might live on our servers for sync purposes, but the keys to decrypt it are derived from your password through a process where we never learn that password. This separation is fundamental: we can store encrypted blobs, but those blobs are useless without keys that exist only on your device.
The Result: Zero-Knowledge Architecture
Fidaro's multi-layered security architecture creates a system where privacy isn't optional - it's mathematically enforced. Your password never reaches our servers in a form we can read. Encryption keys are derived locally on your device through hardware-protected operations. Messages stay encrypted from the moment they leave your browser until they reach the verified enclave. Identity and content are deliberately separated across different systems. Chat history is encrypted locally using browser-protected keys. Session keys expire regularly and can't decrypt past conversations.
We designed this system with a simple goal: make it impossible for us to read your messages, even if we were compelled to do so. There are no master keys in our possession, no database of decrypted conversations, no logs of message content. The cryptographic architecture ensures that we genuinely don't have access to your data. An attacker who compromised our entire infrastructure would never be able to link the who to the what in any meaningful way.
Privacy in Fidaro isn't a policy decision or a promise to be careful with your data. It's a mathematical guarantee built into the architecture itself. That's what zero-knowledge means: we built a service where we know nothing about what you're saying, and we designed it that way on purpose.
We designed this system with a simple goal: make it impossible for us to read your messages, even if we were compelled to do so. There are no master keys in our possession, no database of decrypted conversations, no logs of message content. The cryptographic architecture ensures that we genuinely don't have access to your data. An attacker who compromised our entire infrastructure would never be able to link the who to the what in any meaningful way.
Privacy in Fidaro isn't a policy decision or a promise to be careful with your data. It's a mathematical guarantee built into the architecture itself. That's what zero-knowledge means: we built a service where we know nothing about what you're saying, and we designed it that way on purpose.
