If a compromised browser extension intercepts the public key, there's an attack vector.
PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
31–40 of 45 posts
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#32Earlier quoted context omitted.
The underlying CTAP implementations are only used by the platform to facilitate core activities, they are not used to expose key pairs to external parties. Please link to where any API offers up public keys to external userland actors, and any use of said APIs beyond core credential management. If this is assumed insecure/exposed, it would mean the system and its guarantees cannot be trusted as advertised, given both…
> Given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time. yes, there is no way to enumerate the public key in the webauthn api, but this is a property of the webauthn api only the passkey cryptosystem consists of more than the webauthn api there's the platform and roaming authenticators too and you can't ignore them because they are the part o…
It's not just about the WebAuthn API, you're talking about passkeys as if their key bundles are freely accessible to random userland actors, which is absurd. If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't just offer up to random callers. If you think any of those components/actors are not adhering to fundamental boundaries/limitations, like exposure of sensitive credential material to random callers on the device, it's a more far reaching indictment of passkeys in general.
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#33Ultimately what he is suggesting to do is to bind a string of entropy to a website through facilitation of the browser and a Passkey.
A cryptographic seed is one of the most sensitive things. And here you choose to expose it to a website (even though it was specifically generated for that website). This is not something you do for authentication. The only reason to do this is to have javascript/wasm on a website perform sensitive cryptographic operations for you. You should never be doing this.
Applications such as password managers can already integrate entropy from a passkey to encrypt their databases using the Challenge-Response protocol: https://docs.yubico.com/yesdk/users-manual/application-otp/c...
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#34Earlier quoted context omitted.
> Given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time. yes, there is no way to enumerate the public key in the webauthn api, but this is a property of the webauthn api only the passkey cryptosystem consists of more than the webauthn api there's the platform and roaming authenticators too and you can't ignore them because they are the part o…
It's not just about the WebAuthn API, you're talking about passkeys as if their key bundles are freely accessible to random userland actors, which is absurd. If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't ju…
> If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't just offer up to random callers.
the point of the authenticator is that you don't need need to trust the platform, the operating system the browser or anything other than the authenticator
the authenticators job is to secure the private key, but it will happily serve up the public key to "random callers"
the browser/webauthn are not special, it's just another untrusted "random caller" from the authenticator's perspective
webauthn will not allow the public key out, but the authenticator will
> If you think any of those components/actors are not adhering to fundamental boundaries/limitations, like exposure of sensitive credential material to random callers on the device, it's a more far reaching indictment of passkeys in general.
there's nothing cryptographically sensitive about the public key
hence the name: PUBLIC key
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#35Earlier quoted context omitted.
The underlying CTAP implementations are only used by the platform to facilitate core activities, they are not used to expose key pairs to external parties. Please link to where any API offers up public keys to external userland actors, and any use of said APIs beyond core credential management. If this is assumed insecure/exposed, it would mean the system and its guarantees cannot be trusted as advertised, given both…
> Given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time. yes, there is no way to enumerate the public key in the webauthn api, but this is a property of the webauthn api only the passkey cryptosystem consists of more than the webauthn api there's the platform and roaming authenticators too and you can't ignore them because they are the part o…
There's also the specific case of synced passkeys, which aren't exposed to CTAP management APIs for external parties, only to the OS/platform itself. You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device, but no such permissions/APIs exist for apps, and providing them would be in explicit violation of the fundamental security model. In reality, only the platform/OS and highly trusted actors/components that are already within the existing trust model have such access for internal purposes, and if that's not a safe assumption, it would have broader implications beyond this concern.
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#36Earlier quoted context omitted.
> Given both keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time. yes, there is no way to enumerate the public key in the webauthn api, but this is a property of the webauthn api only the passkey cryptosystem consists of more than the webauthn api there's the platform and roaming authenticators too and you can't ignore them because they are the part o…
There's also the specific case of synced passkeys, which aren't exposed to CTAP management APIs for external parties, only to the OS/platform itself. You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device, but no such permissions/APIs exist for apps, and providing them would be in explicit…
> You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device
yes? one of the main points of passkeys is that if your device is compromised: all your accounts aren't.
with your system, they are
> In reality, only the platform/OS and highly trusted actors/components that are already within the existing trust model
no, they aren't, if they were, the HSM/secure enclave wouldn't be needed at all
I've entertained this nonsense for almost 2 hours now, I'm done
the fact is, if the public key gets out, then your system is compromised
and I have shown you most (df not all) roaming authenticators have a way to enumerate public keys
as does every software HSM I've ever interacted with
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#37Passkeys 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, even if webauth does.
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#38Earlier quoted context omitted.
There's also the specific case of synced passkeys, which aren't exposed to CTAP management APIs for external parties, only to the OS/platform itself. You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device, but no such permissions/APIs exist for apps, and providing them would be in explicit…
> You seem tied to a narrative where a user can install a native app that gets permission to call core OS/platform APIs that let the app get all the public keys of passkeys on the device yes? one of the main points of passkeys is that if your device is compromised: all your accounts aren't. with your system, they are > In reality, only the platform/OS and highly trusted actors/components that are already within the e…
A roaming authenticator does not have access to a CTAP mechanism to query the platform’s credential store. CTAP defines how the platform queries a roaming authenticator, in that direction. There is no CTAP command whereby an authenticator queries the platform for 'all passkeys you have' because the platform is the client in its protocol model. Platform / synced passkeys managed by the OS are not present on the roaming authenticator, so credential management APIs invoked from the roaming authenticator cannot enumerate them (it can only enumerate what it stores).
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#39Ultimately what he is suggesting to do is to bind a string of entropy to a website through facilitation of the browser and a Passkey. A cryptographic seed is one of the most sensitive things. And here you choose to expose it to a website (even though it was specifically generated for that website). This is not something you do for authentication. The only reason to do this is to have javascript/wasm on a website perf…
You can run the PassSeed code/mechanism on your own domain or localhost to ensure it's not subject to malicious host exfiltratuon. I agree that one should only trust a foreign host with low-security uses under this scheme.
Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases
#40It's interesting to see another use case for passkeys. The demo doesn't work with Bitwarden though :(