
        <h2>Why v2?</h2>
        <p>The previous architecture used <strong>two separate data keys</strong>: a local DEK derived from your PIN to encrypt the on-device database, and a sync DEK derived from your account password to encrypt cloud backups. It worked, but it had a structural problem: <strong>if you forgot your password and reset it, a new or cache-cleared device could no longer decrypt the cloud vault</strong>. Your data was effectively lost.</p>
        <p>v2 rebuilds the key system from the ground up around three principles:</p>
        <ul>
          <li><strong>One data key (DEK), never re-encrypted.</strong> Changing any password or key only rewraps the DEK — the encrypted data itself never moves.</li>
          <li><strong>The server never sees your master password.</strong> A client-side HKDF split sends only a derived <code>loginToken</code> to the server; the <code>vaultKEK</code> that actually unlocks your data never leaves your device.</li>
          <li><strong>Every "forgot password" scenario has an explicit path.</strong> A mandatory Recovery Key guarantees you can always get back in, even on a brand-new device with no local cache.</li>
        </ul>

        <h2>The Four-Slot Unified DEK</h2>
        <p>At the center of v2 is a single 32-byte <strong>DEK (Data Encryption Key)</strong>, generated once at signup and never changed for the lifetime of the account. Every piece of your data — local database, cloud sync blob, attachments — is encrypted with this one key.</p>
        <p>The DEK is then <strong>wrapped (encrypted) by four independent keys</strong>, each stored as its own slot:</p>
        <ul>
          <li><strong>Master Password slot</strong> — wrapped by <code>vaultKEK</code>, derived from your master password via Argon2id. The primary unlock method, works on any device.</li>
          <li><strong>PIN slot (optional)</strong> — wrapped by a PIN-derived key. Fast unlock on a trusted device.</li>
          <li><strong>Biometric slot (optional)</strong> — wrapped by an OS-secured key bound to Face ID / Touch ID / fingerprint. Convenience layer on top of the PIN slot.</li>
          <li><strong>Recovery Key slot (mandatory)</strong> — wrapped by a high-entropy key shown to you once at signup. Your last-resort path back to your data.</li>
        </ul>
        <p>Because all four slots wrap the <em>same</em> DEK, you can change your master password, reset your PIN, or rotate biometrics <strong>without ever re-encrypting your data</strong>. Only the affected slot gets rewritten.</p>

        <h2>How HKDF Keeps the Server Honest</h2>
        <p>When you type your master password, the client does <strong>not</strong> send it. Instead, it runs:</p>
        <ol>
          <li><code>vaultKEK = Argon2id(masterPassword, salt)</code> — used locally to unwrap the DEK. Never leaves the device.</li>
          <li><code>loginToken = HKDF(masterPassword, "login")</code> — a deterministic, separate value sent to the server purely for authentication.</li>
        </ol>
        <p>The server stores only <code>bcrypt(loginToken)</code>. Even with a full database breach, an attacker would have to brute-force the master password through bcrypt <em>and</em> Argon2id before they could touch your vault. The <code>vaultKEK</code> itself is mathematically unrecoverable from anything the server holds.</p>

        <h2>The Recovery Key: Your Insurance Policy</h2>
        <p>The Recovery Key is generated on your device during signup and shown to you <strong>once</strong>. You write it down, print it, or store it somewhere safe — we never see it. It does two things:</p>
        <ul>
          <li><strong>Forgot your master password?</strong> Enter the Recovery Key on any device. It unwraps the DEK directly, and you immediately set a new master password — your data is intact.</li>
          <li><strong>Lost your only device?</strong> The Recovery Key alone, plus your account email, is enough to restore everything on a new device.</li>
        </ul>
        <p>This is the same model used by 1Password (Secret Key) and Bitwarden (Recovery Code). It is mandatory in v2 — there is no path to enable sync without setting one.</p>

        <h2>Multi-Device, Transparent Sync</h2>
        <p>In v1, logging in on a new device after a password reset could leave you locked out of your cloud data. In v2, the flow is simple:</p>
        <ol>
          <li>Sign in with email + master password on the new device.</li>
          <li>Client downloads your encrypted vault blob from the server.</li>
          <li>Client derives <code>vaultKEK</code> locally, unwraps the master-password slot, gets the DEK.</li>
          <li>Vault decrypts. Typically under 5 seconds end-to-end.</li>
        </ol>
        <p>No cached keys required. No "this device was never sync'd, sorry" failures.</p>

        <h2>What the Server Can and Cannot Do</h2>
        <table style="width: 100%; border-collapse: collapse; margin: 1.5rem 0;">
          <thead>
            <tr style="background-color: var(--color-background-light);">
              <th style="padding: 0.75rem; text-align: left; border: 1px solid var(--color-border-light);">Capability</th>
              <th style="padding: 0.75rem; text-align: left; border: 1px solid var(--color-border-light);">Server has it?</th>
            </tr>
          </thead>
          <tbody>
            <tr><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">See your master password</td><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">❌ Never</td></tr>
            <tr><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">See your <code>vaultKEK</code> or DEK</td><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">❌ Never</td></tr>
            <tr><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">See your Recovery Key</td><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">❌ Never (only <code>bcrypt(rk_verifier)</code>)</td></tr>
            <tr><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">Decrypt your vault blob</td><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">❌ Mathematically impossible</td></tr>
            <tr><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">Authenticate you</td><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">✅ Via <code>bcrypt(loginToken)</code></td></tr>
            <tr><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">Store your encrypted vault blob</td><td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">✅ As ciphertext only</td></tr>
          </tbody>
        </table>

        <h2>Honest Limits</h2>
        <p>We hold ourselves to the same security baseline as Bitwarden, and we are honest about what that means:</p>
        <ul>
          <li>v2 is <strong>end-to-end encrypted</strong>, not a strict zero-knowledge protocol like SRP or OPAQUE. The server briefly holds the <code>loginToken</code> in memory at login time before storing only its bcrypt hash. This is the same model as Bitwarden.</li>
          <li>A <strong>weak master password is the one thing cryptography cannot fix</strong>. Use a long passphrase, and keep your Recovery Key safe.</li>
          <li>If your device is compromised by malware (keylogger, memory scraper), no password manager can save you — this is an industry-wide boundary.</li>
        </ul>

        <h2>Migrating from v1</h2>
        <p>If you used KeyMe Pass before v2, you will be guided through a one-time migration the next time you unlock the app:</p>
        <ul>
          <li>Your existing data is re-wrapped under the new unified DEK — no data leaves your device during this step.</li>
          <li>You will be asked to set a Recovery Key. This is mandatory before sync can be re-enabled.</li>
          <li>Your master password and PIN continue to work as before; only the underlying key derivation changes.</li>
        </ul>

        <h2>The Bottom Line</h2>
        <p>v2 closes the one structural flaw that kept us up at night: <strong>the chance that a routine password reset could lose your data</strong>. With a unified DEK, four independent unlock slots, client-side HKDF, and a mandatory Recovery Key, every "forgot password" scenario now has a clear, lossless path — and the server learns even less about you than before.</p>
      

KeyMe Pass v2 Key Architecture: Unified DEK, Master Password, and Recovery Key


        <div style="padding: 1rem 1.25rem; border-left: 4px solid var(--color-primary, #6366f1); background-color: var(--color-background-light, #f5f5f7); margin-bottom: 2rem; border-radius: 4px;">
          <strong>Note:</strong> This article describes the original (v1) two-key architecture (PIN-derived local DEK + password-derived sync DEK). KeyMe Pass has since upgraded to the <strong>v2 unified-DEK architecture</strong> with master password, optional PIN/biometrics, and a mandatory Recovery Key. For the current design, read <a href="/blog/keyme-v2-architecture">KeyMe Pass v2 Key Architecture</a>.
        </div>
        <h2>What is Double-Layer Encryption Architecture?</h2>
        <p>KeyMe Pass uses the industry-leading <strong>KEK/DEK double-layer encryption architecture</strong>, a proven security design pattern widely used in banking, government agencies, and major tech companies.</p>
        
        <h3>The Relationship Between KEK and DEK</h3>
        <p>In KeyMe Pass's encryption architecture:</p>
        <ul>
          <li><strong>KEK (Key Encryption Key)</strong>: The key encryption key, derived from your PIN. KEK is used to encrypt and decrypt DEK, but is never directly used to encrypt data.</li>
          <li><strong>DEK (Data Encryption Key)</strong>: The data encryption key, the actual key used to encrypt all your data. DEK is randomly generated and unique to each user.</li>
        </ul>
        
        <h3>Why Do We Need Double-Layer Encryption?</h3>
        <p>The core advantages of double-layer encryption architecture:</p>
        <ol>
          <li><strong>Key Separation</strong>: Even if an attacker obtains the encrypted DEK, they cannot decrypt it without the KEK.</li>
          <li><strong>Flexible Updates</strong>: When you change your PIN, you only need to re-encrypt the DEK with the new KEK, without re-encrypting all data.</li>
          <li><strong>Multi-Layer Protection</strong>: Supports both PIN and biometric authentication, but both are based on the same DEK.</li>
        </ol>
        
        <h2>Detailed Encryption Process</h2>
        <p>When you first use KeyMe Pass:</p>
        <ol>
          <li>The system randomly generates a 32-byte DEK</li>
          <li>The KEK is derived from your PIN through KDF (Key Derivation Function)</li>
          <li>The DEK is encrypted with the KEK and stored on your device</li>
          <li>The DEK encrypts all passwords, IDs, and other sensitive data</li>
        </ol>
        
        <h2>Security Guarantees</h2>
        <p>KeyMe Pass's double-layer encryption architecture ensures:</p>
        <ul>
          <li>✅ <strong>Zero Server Trust</strong>: Even if data is stored on a server, the server cannot decrypt it because the DEK is only stored on your device</li>
          <li>✅ <strong>PIN Protection</strong>: Without the correct PIN, you cannot derive the KEK, and thus cannot decrypt the DEK</li>
          <li>✅ <strong>Biometric Enhancement</strong>: Biometrics provide convenience, but security is still based on the PIN</li>
          <li>✅ <strong>Standard Compliant</strong>: Uses AES-256 encryption, the standard trusted by governments and banks worldwide</li>
        </ul>
        
        <h2>Conclusion</h2>
        <p>KeyMe Pass's double-layer encryption architecture is not a marketing gimmick, but a rigorously designed and verified security solution. It ensures that even the most sensitive data receives the highest level of protection. Your password is your key, and only you have it.</p>
      

KeyMe Pass Double-Layer Encryption Architecture: Why Your Data is So Secure


        <div style="padding: 1rem 1.25rem; border-left: 4px solid var(--color-primary, #6366f1); background-color: var(--color-background-light, #f5f5f7); margin-bottom: 2rem; border-radius: 4px;">
          <strong>Note:</strong> The encryption details below reflect the v1 architecture (single sync DEK derived from your account password). Under the current <strong>v2 architecture</strong> there is one unified DEK shared between local storage and cloud sync, wrapped by master password / PIN / biometrics / Recovery Key. The end-to-end and zero-trust properties described here still hold — see <a href="/blog/keyme-v2-architecture">KeyMe Pass v2 Key Architecture</a> for the current design.
        </div>
        <h2>WebDAV Backup: The Perfect Combination of Security and Convenience</h2>
        <p>KeyMe Pass's WebDAV backup feature lets you safely sync data across multiple devices while maintaining the highest level of security. This article explains in depth why this feature is secure enough.</p>
        
        <h2>End-to-End Encryption (E2EE)</h2>
        <p>KeyMe Pass's WebDAV backup uses <strong>end-to-end encryption</strong>, which means:</p>
        <ul>
          <li>Data is encrypted <strong>before</strong> it leaves your device</li>
          <li>The server can only see encrypted data, with no access to any plaintext</li>
          <li>Only your device holds the decryption key and can decrypt the data</li>
        </ul>
        
        <h3>Encryption Process</h3>
        <p>When you enable WebDAV backup:</p>
        <ol>
          <li>Data is encrypted on-device using the DEK (Data Encryption Key)</li>
          <li>Encrypted data is transmitted to the WebDAV server via HTTPS</li>
          <li>The server only stores encrypted data and cannot decrypt it</li>
          <li>Other devices download data and decrypt it using the same DEK</li>
        </ol>
        
        <h2>Server Zero-Trust Architecture</h2>
        <p>KeyMe Pass follows the <strong>server zero-trust</strong> design principle:</p>
        <blockquote>
          <p>We assume the server is completely untrustworthy. Even if the server is compromised, attackers cannot obtain any of your plaintext data.</p>
        </blockquote>
        
        <h3>Why Can't the Server Decrypt?</h3>
        <ul>
          <li><strong>DEK Not Stored on Server</strong>: The Data Encryption Key (DEK) is only stored on your device</li>
          <li><strong>KEK Derived from PIN</strong>: The Key Encryption Key (KEK) is derived from your PIN, which the server cannot obtain</li>
          <li><strong>Double Protection</strong>: Even if attackers obtain encrypted data, they cannot decrypt it without the DEK</li>
        </ul>
        
        <h2>Compatibility and Flexibility</h2>
        <p>KeyMe Pass's WebDAV backup supports multiple storage solutions:</p>
        <ul>
          <li>✅ <strong>KeyMe Pass Hosting</strong>: We provide professional WebDAV server</li>
          <li>✅ <strong>iCloud</strong>: Compatible with Apple's iCloud Drive</li>
          <li>✅ <strong>Nextcloud</strong>: Supports self-hosted Nextcloud servers</li>
          <li>✅ <strong>Other WebDAV Services</strong>: Compatible with any standard WebDAV server</li>
        </ul>
        
        <h2>Transmission Security</h2>
        <p>In addition to data encryption, KeyMe Pass ensures transmission security:</p>
        <ul>
          <li>✅ <strong>Forced HTTPS</strong>: All data transmission uses encrypted HTTPS connections</li>
          <li>✅ <strong>Certificate Verification</strong>: Validates server certificates to prevent man-in-the-middle attacks</li>
          <li>✅ <strong>Authentication Protection</strong>: Uses secure authentication mechanisms to protect access</li>
        </ul>
        
        <h2>Conclusion</h2>
        <p>KeyMe Pass's WebDAV backup feature ensures absolute security for your data during backup and sync through end-to-end encryption, server zero-trust architecture, and multiple security measures. You can safely use this feature to sync data across devices without worrying about data leakage risks.</p>
      

Why KeyMe Pass's WebDAV Backup is Secure Enough


        <div style="padding: 1rem 1.25rem; border-left: 4px solid var(--color-primary, #6366f1); background-color: var(--color-background-light, #f5f5f7); margin-bottom: 2rem; border-radius: 4px;">
          <strong>Note:</strong> This article was written under the v1 architecture. Under the current <strong>v2 architecture</strong>, we are more precise: KeyMe Pass provides <strong>end-to-end encryption with server-side ignorance of the master password</strong> (Bitwarden-class), rather than a strict zero-knowledge protocol such as SRP or OPAQUE. The practical guarantees described here — server cannot decrypt your data, master password is never sent — still hold. See <a href="/blog/keyme-v2-architecture">KeyMe Pass v2 Key Architecture</a> for the current design and honest limits.
        </div>
        <h2>What is Zero-Knowledge Architecture?</h2>
        <p><strong>Zero-Knowledge Architecture</strong> is a security design principle that ensures the service provider (us) cannot access or view any user data, even if the data is stored on our servers.</p>
        
        <h2>KeyMe Pass's Zero-Knowledge Promise</h2>
        <p>We promise you:</p>
        <ul>
          <li>✅ We can <strong>never access</strong> your master password (PIN)</li>
          <li>✅ We can <strong>never decrypt</strong> your stored data</li>
          <li>✅ Even with sync enabled, we can <strong>never view</strong> any plaintext</li>
          <li>✅ Your data is <strong>completely under your control</strong></li>
        </ul>
        
        <h2>Technical Implementation</h2>
        <h3>1. Encryption Completed Locally on Device</h3>
        <p>All data is encrypted before it leaves your device. This means:</p>
        <ul>
          <li>The encryption key (DEK) is only stored on your device</li>
          <li>The server can only see encrypted data</li>
          <li>Even if we wanted to view it, we couldn't decrypt it</li>
        </ul>
        
        <h3>2. Key Derivation is Irreversible</h3>
        <p>Your PIN is used to derive the encryption key through a Key Derivation Function (KDF):</p>
        <ul>
          <li>We cannot reverse-engineer your PIN from the encryption key</li>
          <li>Even if we obtained the encryption key, we couldn't know the original PIN</li>
          <li>This is a one-way function, mathematically irreversible</li>
        </ul>
        
        <h3>3. Server Only Acts as Storage</h3>
        <p>Our servers are only responsible for:</p>
        <ul>
          <li>Storing encrypted data</li>
          <li>Providing data transmission services</li>
          <li>Not participating in any encryption/decryption process</li>
        </ul>
        
        <h2>Why Does This Matter?</h2>
        <p>Zero-knowledge architecture protects you from multiple threats:</p>
        <ol>
          <li><strong>Server Attacks</strong>: Even if attackers gain access to server data, they cannot decrypt it</li>
          <li><strong>Insider Access</strong>: Our employees cannot view your data</li>
          <li><strong>Legal Requests</strong>: Even if law enforcement requires it, we cannot provide plaintext data</li>
          <li><strong>Data Breaches</strong>: Even if a data breach occurs, your data remains encrypted</li>
        </ol>
        
        <h2>Your Privacy, Your Control</h2>
        <p>At KeyMe Pass, we believe:</p>
        <blockquote>
          <p>Your data belongs to you, and only you should be able to access it. We simply provide a secure storage and sync service, but we should never, and can never, see your data.</p>
        </blockquote>
        
        <h2>Conclusion</h2>
        <p>Zero-knowledge architecture is not a marketing slogan, but a core design principle of KeyMe Pass. We ensure through technical means that we can never access your data—this is our highest commitment to your privacy.</p>
      

Zero-Knowledge Architecture: We Can Never See Your Data


        <h2>Two Storage Solutions</h2>
        <p>KeyMe Pass provides two data management solutions, and you can choose based on your needs:</p>
        <ul>
          <li><strong>Fully Local Storage</strong>: All data is stored only on your device</li>
          <li><strong>Cloud Sync</strong>: Use WebDAV backup to sync data across multiple devices</li>
        </ul>
        
        <h2>Fully Local Storage</h2>
        <h3>Advantages</h3>
        <ul>
          <li>✅ <strong>Maximum Privacy</strong>: Data is completely offline, never passes through any server</li>
          <li>✅ <strong>Complete Control</strong>: You have full control over where data is stored</li>
          <li>✅ <strong>No Internet Required</strong>: Can be used in completely offline environments</li>
          <li>✅ <strong>No Dependencies</strong>: Does not rely on any third-party services</li>
        </ul>
        
        <h3>Best For</h3>
        <ul>
          <li>Single-device use, no need for multi-device sync</li>
          <li>Extremely high privacy requirements, data must not leave the device</li>
          <li>Unstable or restricted network environments</li>
          <li>Regular manual backup habits</li>
        </ul>
        
        <h2>Cloud Sync (WebDAV Backup)</h2>
        <h3>Advantages</h3>
        <ul>
          <li>✅ <strong>Multi-Device Sync</strong>: Seamless sync across phone, tablet, and computer</li>
          <li>✅ <strong>Automatic Backup</strong>: Data automatically backs up to the cloud, protecting against device loss</li>
          <li>✅ <strong>End-to-End Encryption</strong>: Even with cloud storage, data remains encrypted</li>
          <li>✅ <strong>Flexible Choices</strong>: Can choose KeyMe Pass hosting or self-hosted servers</li>
        </ul>
        
        <h3>Best For</h3>
        <ul>
          <li>Need to use across multiple devices</li>
          <li>Want automatic backup protection</li>
          <li>Need data recovery capabilities</li>
          <li>Trust in end-to-end encryption security</li>
        </ul>
        
        <h2>Security Comparison</h2>
        <table style="width: 100%; border-collapse: collapse; margin: 1.5rem 0;">
          <thead>
            <tr style="background-color: var(--color-background-light);">
              <th style="padding: 0.75rem; text-align: left; border: 1px solid var(--color-border-light);">Feature</th>
              <th style="padding: 0.75rem; text-align: left; border: 1px solid var(--color-border-light);">Local Storage</th>
              <th style="padding: 0.75rem; text-align: left; border: 1px solid var(--color-border-light);">Cloud Sync</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">Data Encryption</td>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">✅ AES-256</td>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">✅ AES-256 E2E</td>
            </tr>
            <tr>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">Server Access</td>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">❌ Never touches server</td>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">✅ But cannot decrypt (zero-knowledge)</td>
            </tr>
            <tr>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">Multi-Device Sync</td>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">❌ Not supported</td>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">✅ Supported</td>
            </tr>
            <tr>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">Auto Backup</td>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">❌ Manual backup only</td>
              <td style="padding: 0.75rem; border: 1px solid var(--color-border-light);">✅ Automatic backup</td>
            </tr>
          </tbody>
        </table>
        
        <h2>How to Choose?</h2>
        <h3>Choose Local Storage if you:</h3>
        <ul>
          <li>Use on only one device</li>
          <li>Have extremely high privacy requirements</li>
          <li>Have regular manual backup habits</li>
          <li>Don't trust any cloud services</li>
        </ul>
        
        <h3>Choose Cloud Sync if you:</h3>
        <ul>
          <li>Need to use across multiple devices</li>
          <li>Want automatic backup protection</li>
          <li>Trust in end-to-end encryption security</li>
          <li>Need data recovery capabilities</li>
        </ul>
        
        <h2>Hybrid Approach</h2>
        <p>You can also adopt a hybrid approach:</p>
        <ul>
          <li>Primary use of local storage</li>
          <li>Regular manual export of encrypted backups</li>
          <li>Enable cloud sync when needed</li>
          <li>Switch flexibly based on circumstances</li>
        </ul>
        
        <h2>Conclusion</h2>
        <p>No matter which solution you choose, KeyMe Pass ensures your data is secure. Local storage provides maximum privacy, while cloud sync provides convenience and backup. The choice is entirely yours.</p>
      

KeyMe Pass v2 Key Architecture: Unified DEK, Master Password, and Recovery Key

KeyMe Pass Double-Layer Encryption Architecture: Why Your Data is So Secure

Why KeyMe Pass's WebDAV Backup is Secure Enough

Zero-Knowledge Architecture: We Can Never See Your Data

Local Storage vs Cloud Sync: How to Choose the Best Option for You