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.

Transcript

1. Zero Server Data Security Kyle Simpson
2. Local-First Zero Server doesn’t necessarily mean no servers… it just means no required servers.
3. Zero Server also doesn’t mean one “client” device… but all users’ devices are equal, synchronized peers.
4. In the digital space… you are what you do.
5. Either you own that data… or others own the data that defines you.
6. If you don’t have custody over your data… you don’t own your data.
7. If you can’t protect your own data… you don’t own your data.
8. We need to own our data AND protect it… without requiring servers.
9. Owning your data is one central pillar… of digital identity.
10. Digital identity without servers is… among the hardest problems in Local-First.
11. 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?
12. 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.
13. So, let’s chip away at that problem.
15. WebAuthn Local Client
16. Native WebAuthn API
17. WebAuthn-Local-Client API
18. Local Data Lock
23. Client Storage
25. Local Vault
29. Demo
30. 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