Hello, I would like to bring to the Polkadot community the amazing benefits of using WebAuthn passkeys with the PRF extension, and how it will make stateless private keys the future of crypto wallets.
What Exactly is a Passkey?
Passkeys are the next evolution in authentication – think passwordless logins powered by your device’s biometrics (like Face ID or fingerprint) or hardware security keys. Built on the WebAuthn standard, they’re super secure, phishing-resistant, and synced across your devices (thanks to services like iCloud or Google).
Unlike traditional passwords, passkeys use public-key cryptography: Your device generates a unique key pair for each site or app, keeping the private key locked away safely.
What is PRF + HKDF?
PRF (Pseudo-Random Function) Extension: This is a shiny new add-on to WebAuthn that lets your passkey derive secret keys during authentication. It outputs high-entropy (super random) data that can be used for cryptography.
HKDF (HMAC-based Key Derivation Function): This takes that PRF output and deterministically generates private keys or other secrets. It’s like a secure recipe that always produces the same key from the same inputs – perfect for wallets!
Together, they enable stateless private keys: Instead of storing your keys (risky!), they’re recreated every time you authenticate. This makes wallets lightweight, recovery-proof, and hack-resistant.
Important Note: This might not work with every authenticator yet. I’ve only tested it on Chrome with a hardware key. Check if your setup supports the WebAuthn PRF extension – iOS 18/Safari 18 and recent Android/Chrome versions are good bets.
Head over to the demo: Passkey Wallet Proof-of-Concept. Create a passkey, sign in, and watch those stateless keys work their magic! It’s a simple POC, but the potential for Polkadot integrations is huge.
Hey I’m not sure if you’re aware of this, but the extension is still not widely supported on all FIDO authenticators. Also, the security model is relative to which passkey the user chooses. For example, if they use a Yubico external key it’s similar to how a hardware wallet would work. On the other hand if they choose to store it in the browser it’s just a software backed implementation.
also, you may find the ability to reuse a passkey doesn’t work across different dapps. This is because the passkey is origin bound which means you’d need to centralize around a well known smart wallet and then that gets iframed into every dapp and post message is used to communicate between the wallet and DApp.
I am fully aware that the prf extension is not supported, as stated in the important note. I am also aware of the security limitations. This is just a concept right now, and I am still researching all possible security issues that could arise.
Yes, it is locked to the dapp you sign up for, but that’s not the worst thing. It prevents you from signing into a publishing site.
The biggest challenge right now is the time the private key is in memory to sign or get the public key for the first time but there are ways to migrate that problem just pos right now
Speaking broadly, this is definably a gate of entry to be solved! If I am projecting 5 years from now, this is a tool to get people to transition into the space more securely with ease of use. I do believe exploring this and building out something is value to a WEB3 world.
Hey Lachlan,
Your project looks very interesting, and after taking a quick look at your code, it seems we share a similar mindset on this. Although I’m stepping back from crypto as a whole, this could be amazing if widely adopted. I’ll dive deeper when I have time and see if there’s anything valuable I can contribute.
I have some questions if you have time, as we’re doing things quite differently. Can you explain why you are creating and encrypting a private key and storing it in local storage? What are the advantages of this approach compared to pure derivation? Also, wouldn’t this lock the wallet to the device it was created on?
I’ve not gone fully though your code fully so I might be missing something also we could just be going for different use cases but I would love to hear your perspective
Thanks man, You can store it wherever you want. The only secret is the passkey, everything else can go in a db, on chain, on ipfs. It’s just stored in local storage for the demo. There’s a lot of security things done in my repo, I’d recommend building on top of it if you want to add polkadot signatures. I can assist you in doing that.
Hey I understand what you’re doing, I just don’t get why you’re using the PRF as an encryption key. Why not use it as IKM? Is there a stability issue with deriving the private key at signing? The way you’re doing it, you still need to manage the encrypted private key.
Yeah - the main difference is: you generate a random private key, encrypt it, and store it locally (or anywhere). My approach is to use the PRF’s deterministic nature to derive the private key on demand, so the key isn’t stored long-term and is recreated when needed.
Cool, i think i understand your approach to getting the encryption key.
But in a practical sense, I need a ETH priv key, a SOL priv key, how does one get these without creating them then securely encrypting them?
I don’t see any logic on the actual signing of Txns, so thats my missing link to understanding your approach. Maybe Dot is different? Im not a Dot guy.
