Fails with
Error: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration....
On Android
PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
41–45 of 45 posts
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#42Passkeys can be hijacked to serve as cryptographic seed material that is securely synced across all of a user’s devices, enabling the generation of a wide range of cryptographic keys. This allows Passkeys to power use cases far beyond what they have traditionally been constrained to. I’ve been calling this mechanism PassSeeds. I’ll leave the details to the blog post, but here’s a short list of what PassSeeds enable:…
What stops anyone else doing the ECDSA public key recovery hack by signing two identical messages and getting the public key, i.e. the thing you are using as a cryptographic seed? In general, using a key for a purpose it was not designed for gets you into trouble. Treating a public key as private key seed material is almost certainly going to be a problem. Systems are just not designed to keep public keys secret, eve…
That would either mean you have arbitrary, malicious code executing in the bound origin (the origin was hacked and shipped malicious code), or you allowed random callers externally to take signatures out of the boundary - don't do either of these things, they are verboten. The whole point is that for the passkey you use as a PassSeed, you never do any signing other than locally for ECDSA recovery.
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#43Fails with Error: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration... . On Android
Hmm, can you provide further details? I'm using it on Android in Chrome and Brave, and it works fine.
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#44If a compromised browser extension intercepts the public key, there's an attack vector.
Yes, this is true, however, that means an external actor is able to execute arbitrary code in your origin, so they could also trick the user into signing malicious payloads with even the native passkey itself. There's more downside to exfiltration here, but having arbitrary code from an external party executing in your page is a more general cause for concern you'd need to mitigate regardless.
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#45Earlier quoted context omitted.
What stops anyone else doing the ECDSA public key recovery hack by signing two identical messages and getting the public key, i.e. the thing you are using as a cryptographic seed? In general, using a key for a purpose it was not designed for gets you into trouble. Treating a public key as private key seed material is almost certainly going to be a problem. Systems are just not designed to keep public keys secret, eve…
That would either mean you have arbitrary, malicious code executing in the bound origin (the origin was hacked and shipped malicious code), or you allowed random callers externally to take signatures out of the boundary - don't do either of these things, they are verboten. The whole point is that for the passkey you use as a PassSeed, you never do any signing other than locally for ECDSA recovery.
It seems malicious code on the phone can get the public key and thus derive the secret keys. This is weaker protection than PassKeys provide (would have to crack the hardware, not just software).