4 ms·

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 fo

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.

blibble 9mo ago
> 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-client-to-authenticator-protocol-v2.3-rd-20251023.html#enumeratingCredentials 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
- csuwldcat 9mo ago
  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?
  - blibble 9mo ago
    > 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?
- csuwldcat 9mo ago
  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.
  - blibble 9mo ago
    > 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?)
    - csuwldcat 9mo ago
      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.

blibble 9mo ago

> 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-client-to-authenticator-protocol-v2.3-rd-20251023.html#enumeratingCredentials 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

csuwldcat 9mo ago
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?
- blibble 9mo ago
  > 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?
csuwldcat 9mo ago
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.
- blibble 9mo ago
  > 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?)
  - csuwldcat 9mo ago
    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.