Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Zero Server Data Security

Zero Server Data Security

How can local-first apps handle identity and client data security, with zero servers?

(presented at LoFi/18 meetup)

Video of the talk runs from ~16:15 - 42:50.

Kyle Simpson

August 27, 2024
Tweet

Video


Resources

Github: WebAuthn-Local-Client

https://github.com/mylofi/webauthn-local-client

Browser-only utils for locally managing WebAuthn (passkey) API

Github: Client-Storage

https://github.com/mylofi/client-storage

Simple key-value storage API backed by various client storage mechanisms

Github: Local-Data-Lock

https://github.com/mylofi/local-data-lock

Protect local-first app data with encryption/decryption key secured in Webauthn (biometric) passkey

Github: Local-Vault

https://github.com/mylofi/local-vault

Store key-value data encrypted (biometric passkey protected), locally in the client

More Decks by Kyle Simpson

Other Decks in Programming

Transcript

  1. Zero Server also doesn’t mean one “client” device… but all

    users’ devices are equal, synchronized peers.
  2. Problem: In Detail In a pre-quantum world, standard elliptic-curve cryptography

    (Ed25519/x25519), with a reasonable source of entropy (pseudo/randomness), not only can protect data through encryption, but serve as a sufficiently strong source of global identity uniqueness (“your public-key is your ID”); chances of independent random generations of the same keypair are extraordinarily low. The random IV/seed for keypair generation is all that must be preserved, which is 32 bytes (256 bits) long. But no user will remember or preserve such a long/opaque value. This master IV/seed could be protected through symmetric encryption, with a separate key that’s derived from a user provided “master password”. But these are weak/forgettable. Crypto/Blockchain solutions “solve this” with BIP-39, giving users a 12-word or 24-word list of common words (computed from the IV/seed), which is a little easier to preserve. But there’s still a chicken-and-the-egg problem: since it’s too long/hard to remember, where does a “master password” get stored, and how is it protected?
  3. Problem: More Detail Typical “password manager” / “wallet” apps protect

    user credentials in a centralized-cloud store, or expect users to setup their own off-device (usually cloud) backups and synchronization. These designs violate local-first principles, and are still subject to the chicken-and-the-egg problem: “Which key protects the master key?” or “Where do you store/protect your cloud credentials?” The master key must be protected somewhere that’s more secure than the userland applications that rely on the key; further, access to this master key must be gated by something the user can never lose or forget. Moreover, we must contend with the UX design of such systems, to balance the inherent tradeoff between convenience (long-lived logins) and security (authorize every operation). Biometric passkeys (FaceID, TouchID) have emerged in recent years as a better solution to these various concerns, relying on device OS “secure enclave” / keychain mechanisms. Virtually all passkey systems/libraries currently rely on centralized servers.
  4. Some Use Cases Store all (or just important!) data of

    a local-first app securely on the device, encrypted with passkey-protected keypair Store more traditional web app data more securely, such as storing a completely encrypted JWT (even in the “Cookie” storage adapter) Allow user to lock any of their app data, but then app transmits that encrypted data up to a cloud server, for E2E encrypted synchronization/backup Generate and verify digital signatures, for ensuring integrity of data as it’s transmitted between devices Allow “serverless” apps to still take advantage of passkeys (on top of existing identity/auth approaches), without needing a FIDO server