Hacker News Reader

Comment by csuwldcat | Hacker News Reader

The interesting thing about Passkeys is that they are only ever output in the client create() call, and the platform does not retain them for disclosure after that, so if you don't send them out of the origin boundary, they are treated like a virtually secret value by the platform. It's ironic, because the WebAuthn/Passkey authors (who I know some of) explicitly treat the public key as a sensitive value, and built system assumptions around that, which is what makes this possible. It's a rather gross hack, can't deny it that, but there are a group of use cases for which it is a better fit than any of the far more ugly flows many non-P-256 self-custodied key use cases are accomplished with today.

View on HN

> they are treated like a virtually secret value by the platform

"virtually" is the problem

for webauthn the public key isn't revealed to everyone for privacy reasons, not cryptographic reasons

the webauthn API is also only part of the cryptosystem

the platform authenticator (yubikey, windows hello, password manager, whatever) may have an API to list stored public keys without any authentication at all

because they were never intended to be protected

It's a deliberate architectural decision that passkey authenticators not allow any retrieval or enumeration of key pairs - they don't even have internal APIs for it. This holds true for all known implementations, as it is a core principle of the system design.

> it's a deliberate architectural decision that passkey authenticators not allow any retrieval or enumeration of key pairs

there is no much thing as a "passkey authenticator"

there are "platform authenticator" and "roaming authenticators"

> they don't even have internal APIs for it.

CTAP has an enumerate credentials command, which returns, among other things:

> publicKey (0x08): public key of the credential in COSE_Key format

https://fidoalliance.org/specs/fido-v2.3-rd-20251023/fido-cl...

> This holds true for all known implementations, as it is a core principle of the system design.

oh dear

No need for the "oh dear"-ing before you provide evidence. I'm not aware of any command for fetch or enumeration of public keys in CTAP (was rather confident it doesn't provide any such thing). Care to link to what you were referring to?

> No need for the "oh dear"-ing before you provide evidence.

... there's a link in the comment

> I'm not aware of any command for fetch or enumeration of public keys in CTAP (was rather confident it doesn't provide any such thing).

how do you think the discoverable key credential management dialogs work?

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 keys are supposed to be handled as a secure, opaque bundle, disclosed to no one beyond the bound origin at create time.

> 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 of the passkeys cryptosystem that actually store the key material

and I have shown you, it is common for the layer below webauthn to support enumeration of the resident public keys

because... it's useful!

million dollar HSMs let you enumerate & see public keys, protected Java keystores let you enumerate & see the public keys, the windows certificate manager lets you enumerate & see public keys

(because surely no-one would be daft enough to try to build a secret key scheme out of the public keys of a pair?)

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.

> 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

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.

> 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

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).

Reply on news.ycombinator.com