I'm sure what I'm about to ask has obvious answers, because this protocol has been developed by smart people with probably decades of experience. But, I don't get the two questions in bold (or more likely, i don't get at least, the two questions in bold...):
- What ties the user (i.e. the carbon based life form with some sort of uniquely 'you' property) to the key used in the registration attempt?
For instance, if the key is generated from an HSM, where is the step of providing something that only 'you know', rather than 'you physically possess but couldn't potentially be in the possession of others,' to verify that is your carbon life form submitting the key from the HSM for this registration attempt? I.e. where is the passphrase, and how does needing to have that to tie 'you' to 'the key' in the whole registration process (and future login attempts) in anyway circumvent the use of passwords and all the management that goes along with them anyway? All this boils down to needing to present something that clearly ties your carbon based existence, to the presentation of a strong key....I presume this is why Yubikey and co are going for bio-metric HSM's....(based on the security of many bio-metric implementations in the past and their relatively 'spoofable' nature, that prospect doesn't really fill me with certainty that it's fixing anything).... And even then, why not just present the biometric data directly and do away with the middle ware of the WebAuthn crypto key in the process?... (presumably because there is too much data in the actual biometrics, to punch it directly over slow networks, and/or proving that it hasn't been modified in transit requires key signing of the data anyway, so the keys are back on the table...?)
- What prevents a Man-In-The-Middle from hijacking the registration process with their own credentials and key material?...and then just monitoring the transactions and relaying information, or even just sitting in the middle and being an 'evil proxy webauthn' server, or just taking ownership of the 'user representation' that you tried to register?
Obviously the user would become aware when they attempted to use the given service over a network that 'evil mitm proxy' hasn't managed to intercept, as the service that 'they registered for' with 'their key' will be reject the login attempt (since now the users actual key is being presented rather than 'evil mitm key')....but it's all a bit late by then isn't it? I mean someone else at that point would own (in a cryptographic-ally verifiable manner) the service account. So, you'd know you've been screwed, but what are you going to do about it, particularly if that service is a publicly attributable front-end to your carbon life form (think Twitter, email, social networks or some sort of social security style registration of nation state recognised credential like a drivers licence or passport etc).
I'm thinking these problems are presumed to be solved by layering external technologies outside of the WebAuthn protocol. For instance the HSM requires bio/passphrases, and the registration happens over HTTPS.
So, is the presumption that these external mechanisms (arguably) prevent the above two scenario's, rather than the WebAuthn protocol itself? How much of a stack is being relied upon, to achieve the goal of binding 'your carbon life form' to 'the registration for a service' such that is apparently 'your registration'?