Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

backalleycoder.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#21

Post by csuwldcat »

blibble wrote: post #19
csuwldcat wrote: post #17

Earlier quoted context omitted.

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 sy…

> 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 w…

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.

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#22

Post by arjvik »

csuwldcat wrote: post #2

Passkeys 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:…

I don’t understand why you want to enforce only using the public key instead of private key - while I believe you that as of now browsers do not disclose the public key anywhere, I’d also suspect that this is far more likely to be violated and accidentally disclosed by a bug than the private key, which theoretically cannot ever leave the TPM.

Would KDF(deterministic_sign(“well-known message”)) not also provide valid entropy?

Is it just impossible to force a nonce for a deterministic signature?

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#23

Post by sandeepkd »

josephcsible wrote: post #7

How is this any better than just storing the value in a password manager, or in YubiKey's "Static Password" mode? Also, the "ECDSA Public Key Recovery" picture makes me suspect this is AI slop.

I think if you are doing it in the browser then you bind the flow to the request origin making it phishing resistant compared to a static, origin agnostic storage

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#24

Post by sandeepkd »

csuwldcat wrote: post #8
josephcsible wrote: post #7

How is this any better than just storing the value in a password manager, or in YubiKey's "Static Password" mode? Also, the "ECDSA Public Key Recovery" picture makes me suspect this is AI slop.

How it's better: automatically synced across all a user's devices, not subject to manual interactions with input fields (you can't programmatically request/regen passwords the same way you can with this). I did use AI for the ECDSA public key recovery diagram, because I wasn't about to spend hours hand rolling that in Lunacy. It's correct in broad strokes, and anyone who wants to understand it more deeply can just lo…

IMO automatic sync is a mess with the passkeys, it just muddies the whole guarantees around security based on possession, its not available unless you are signed in on the platform (eg. apple account) making the behavior inconsistent

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#25

Post by blibble »

csuwldcat wrote: post #21
blibble wrote: post #19

Earlier quoted context omitted.

> 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 w…

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

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#26

Post by [deleted] »

blibble wrote: post #19
csuwldcat wrote: post #17

Earlier quoted context omitted.

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 sy…

> 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 w…

[deleted]

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#27

Post by csuwldcat »

blibble wrote: post #25
csuwldcat wrote: post #21

Earlier quoted context omitted.

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_K…

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?

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#28

Post by blibble »

csuwldcat wrote: post #27
blibble wrote: post #25

Earlier quoted context omitted.

> 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_K…

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?

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#29

Post by csuwldcat »

blibble wrote: post #25
csuwldcat wrote: post #21

Earlier quoted context omitted.

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_K…

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.

Re: PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

#30

Post by blibble »

csuwldcat wrote: post #29
blibble wrote: post #25

Earlier quoted context omitted.

> 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_K…

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

Post reply on HN