Nostr Web Client

I’m excited to work with Praveen of Cove Wallet on a new open standard for Bitcoin wallet cloud backup using Passkeys - no passwords, no key server trust.

Today wallets like BitKey provide a seedless UX with good redundancy but they require hardware. For spending wallets or users that want to start without hardware our proposal provides a compelling UX - Just do FaceID/TouchID to sync a Passkey to your password manager and done.

It’s an improvement over Photon since there is no key server to run for the wallet vendor and no PIN to remember for users (and no email/phone for PIN reset). The wallet just needs to regularly do a health check to verify the Passkey in your password manager can decrypt the cloud backup.

Let us know what you think. The goal is to develop this into an open standard that any mobile signer can adopt. Link below 👇

https://praveenperera.com/blog/passkey-prf-bitcoin-wallet-backup

Reply to this note

Please Login to reply.

Discussion

Anita 3w ago

Is the faceID/fingerprint only needed for setup or every time?

I can „forget“ a PIN in case someone tries to force me to send funds, don’t have that way out with biometrics.

tank 3w ago

Good point. Users can disable biometrics for their password manager and it will prompt for the device passcode instead.

tank 3w ago

The passkey authentication flow is only needed during setup (backup/restore) and health checks.

During daily use, the seed is stored on the mobile wallet though. So standard security features like a PIN can still be set by the wallet ofc.

idsera 2d ago

What do you think about this model of nostr:npub1mu7nv2jkaq4xausnn098xc8tp3gzgf2w5r2cj68x8dnns0rktmysnsj5cl? https://github.com/breez/seedless-restore/blob/main/spec.md

tank 2d ago

Breez’ spec is interesting if the user trusts his nostr relays to store the salt for prf. Without the salt the user loses his nsec. This is why I would propose to backup the salt along with the encrypted key material in iCloud/GDrive (see CSPP spec). This way the nostr user’s nsec could also be re-encrypted if the passkey needs to be rotated due to device compromise etc.

idsera 2d ago

cc nostr:npub1ey6qdmvzcgcsr883m9nspzz0mm037l26xtardzcskfsvc6gc7jssm9szvp

Roy 2d ago

That's not how it works. The primary nostr salt is fixed. Then it can store additional salts.

tank 2d ago

Where is the primary salt stored?

Yaacov Akiba Slama 1d ago

The primary salt is an hard coded string defined in the protocol. Using it the list of the salts used by the same passkey can be obtained from the relays.

If by "the user trusts his nostr relays to store the salt", you mean to trust the relays to not delete them, trusting iCloud/GDrive is not better.

Also, Breez intent is to mitigate the trust by handling a relay dedicated to store the salts.

tank 1d ago

We’ve seen relays nuke their databases regularly which means users would ultimately rely on the breez relay to store their salt. As a user I personally prefer icloud to store my data longterm independent of a wallet vendor. But it is a matter of taste.

CSPP derives a master encryption key independent of the passkey to encrypt the nsec and stores the ciphertext besides the salt in icloud. Without it users would need to rotate their nsec when they rotate their passkey. I believe this is an important feature for the management of longterm user keys.

But PRF will be used in many different ways by different vendors. So I don’t expect convergence on one standard.

tank 1d ago

Oh and users get 2FA for free as an additional security layer when using iCloud/GDrive. Apple even makes users enable 2FA when storing passkeys https://support.apple.com/guide/iphone/use-passkeys-to-sign-in-to-websites-and-apps-iphf538ea8d0/ios

Yaacov Akiba Slama 1d ago

1. The client can regularly check the relays and republish the list of salts if they are deleted.

2. Every vendor can setup their own relay.

3. The list of salts is backup-ed automatically by ios/android because its in the app data and is not "secret".

4. The same list can be exported by the client to a simple text file if the user wants a wallet independent backup and doesn't want to run any app using this protocol for a long time.

5. Passkey rotation is generally not needed because the secret part of the passkey is not supposed to leave the TEE except when migrating from one vendor to another (using a secure protocol like CXP). In the exceptional case of a passkey compromise, the user can always move its funds to another wallet using a new passkey.

6. The UX cost of using iCloud/GDrive is very high (login, vendor auth)

tank 1d ago

Thanks for clarifying.

1-4: makes sense. The downside of relays is IP address (location) leakage to multiple untrusted server if users are not using a VPN.

5: I agree for a wallet use case. But for nostr the user loses his social graph.

6: the UX cost is zero for icloud-key-value-store (users are generally logged into their Apple ID on iOS). On Android there is a UX cost. The main upside I see is 2FA though. Compromise of a passkey is not unlikely on a desktop computer due to higher malware risk. Users could recover their wallet only on mobile devices. A user using yubikeys to secure their Apple/Google account would be resistent to an adversary that has compromised their laptop.

Yaacov Akiba Slama 13h ago

Re 5. The passkey is used explicitly for the wallet.

Re 6. A regular user doesn't store his passkeys in his desktop, and the passkey stays in his phone or physical key and only the prf result is sent to the desktop.

tank 12h ago

How does a user prevent sync of the passkey to his desktop? iCloud Keychain items are synced to all devices. Same with 1Password.