WebAuthn - What am I missing?

Question

I'm trying to learn a bit about authentication and security protocols at a 10,000 foot level. I was reading about WebAuthn here: https://webauthn.guide/ and here: https://webauthn.io/

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

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

2. 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'?

Answer 1

I'm not an expert on this but here is how I understand it:

A) The short answer, "something you know" does not have to be present for WebAuthn to work. That falls into securing HSM-Harware Security Module (or any other Authenticator that supports WebAuthn). WebAuthn is not about that, at least in this stage. HSM vendors can incorporate security features to protect their devices in case of physical access (biometric spoofing, copying etc) or phishing. That will be dependent on the need of the users on how much security they need (corporate IT admin vs. average home user). I'm sure FIDO will certify different level of devices for different needs, and maybe some companies will require HSM with certain feature-set, and maybe in the future the industry will move to a more secure option. After 20+ years, we're now seeing HTTPS replacing HTTP at a rapid pace for example. It's a start and work in-progress in my opinion.

Also, biometric data only unlocks access to HSM / Authenticator (i.e Windows, iOS) and it doesn't give anything else about the private keys stored. Spoofing biometric can only be done when having access to HSM and that falls into securing the device. This is versus someone hacking a company and dumping everyone's passwords. With WebAuthn, the credentials obtained are useless. (But they can replace your public key there with theirs and can have access to your account depending on how the web app' security is designed - still much less damaging than passwords being traded in dark-web). If you replace the public-private key method with just sending the biometric data to web apps, it is the same as having a very strong passwords but unfortunately, the same password and irreplaceable ( you can't change your own biometric like a password) in every web app you use. This brings a privacy issue (web app knows your biometric and they can abuse it), second you give it to everywhere (it makes it a single-password for all - once compromised it's over). Also, similar to passwords, if they can dump these biometrics, they can sell / access your account just like passwords, just harder to crack (like a very strong password)

The way WebAuthn securely do this is through asymmetric key pairs (similar to how SSL works today - only generated by user's device instead of a CA like GoDaddy): The keys are generated per web app on the HSM, the private key stays at the user's HSM and the public key is passed to the web service and the web service stores & uses it in the future to decrypt the requests coming for your account. What is signed/encrypted by private key can only be opened by the public key so the web app knows that the request is signed/encrypted by the same private key originally registered. Since the keys are per web app, phishing through spoofing another web app's login screen is not possible.

This takes away the burden of managing / remembering passwords from the end user. It, also, eliminates weak passwords, case of re-using across multiple sites, passwords on post-it, passwords being phished, etc. What's left is securing the authenticator (HSM or laptop, iphone, yubikey, etc.)

Here is how the W3C specs describes this. As you can see, "something you know" is not required at this point:

"Authenticators are responsible for ensuring that no operation is performed without user consent"

"User consent means the user agrees with what they are being asked, i.e., it encompasses reading and understanding prompts. An authorization gesture is a ceremony component often employed to indicate user consent."

"An authorization gesture is a physical interaction performed by a user with an authenticator as part of a ceremony, such as registration or authentication. By making such an authorization gesture, a user provides consent for (i.e., authorizes) a ceremony to proceed. This MAY involve user verification if the employed authenticator is capable, or it MAY involve a simple test of user presence."

"A test of user presence is a simple form of authorization gesture and technical process where a user interacts with an authenticator by (typically) simply touching it (other modalities may also exist), yielding a Boolean result. Note that this does not constitute user verification because a user presence test, by definition, is not capable of biometric recognition, nor does it involve the presentation of a shared secret such as a password or PIN."

You can read more here. Start from the abstract and follow from there

https://www.w3.org/TR/webauthn/

B) If there is a Min-In-The-Middle (MITM) actor present before you register to a service and they are able see / modify your communication with a web-site, they can already own your account and after WebAuthn registration, they can continue to own your account by replacing your public key with their public key at the time of registration. But this is only possible if MITM can read clear text communication between the parties (i.e. already spoofing SSL between the parties). At this level, no solution through the same channel (i.e. web) will help. I don't think this is a problem or a shortcoming of WebAuthn itself as it's not its job to overcome a well-established MITM. A second factor authentication could help with this but if the same MITM has compromised that too, the result is the same. There is no perfect solution to this problem, even if the web app requires on-site in-person registration (i.e. con man, fake ids, etc.)