Slide 1

Slide 1 text

Zero Server Data Security Kyle Simpson

Slide 2

Slide 2 text

Local-First Zero Server doesn’t necessarily mean no servers… it just means no required servers.

Slide 3

Slide 3 text

Zero Server also doesn’t mean one “client” device… but all users’ devices are equal, synchronized peers.

Slide 4

Slide 4 text

In the digital space… you are what you do.

Slide 5

Slide 5 text

Either you own that data… or others own the data that defines you.

Slide 6

Slide 6 text

If you don’t have custody over your data… you don’t own your data.

Slide 7

Slide 7 text

If you can’t protect your own data… you don’t own your data.

Slide 8

Slide 8 text

We need to own our data AND protect it… without requiring servers.

Slide 9

Slide 9 text

Owning your data is one central pillar… of digital identity.

Slide 10

Slide 10 text

Digital identity without servers is… among the hardest problems in Local-First.

Slide 11

Slide 11 text

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?

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

So, let’s chip away at that problem.

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

WebAuthn Local Client

Slide 16

Slide 16 text

Native WebAuthn API

Slide 17

Slide 17 text

WebAuthn-Local-Client API

Slide 18

Slide 18 text

Local Data Lock

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

Client Storage

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Local Vault

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Demo

Slide 30

Slide 30 text

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