Hacker News new | ask | show | jobs
by crunchatized 2882 days ago
There doesn't technically have to be a way to register new sites. There is, but theoretically there never actually had to be, given keys are generated deterministically on-demand, using the website's domain name effectively as a salt. There's no system with a list of websites.

The signed challenge-response you give to the phishing site cannot be forwarded to the real site and accepted, because you used the domain name as part of your response, and as part of key generation, so it doesn't match. That's all that meant. 'Credentials' included the use of a public/private key, not just the typed password.
1 comments
tialaramex 2882 days ago
No! Registration is important. What you've described would be subject to an enumeration attack.

During Registration the Relying Party (web site) picks some random bytes, and sends those to the Client (browser). The Client takes those bytes, and it hashes them with the site's domain name, producing a bunch of bytes that are sent to the Security Key for the registration.

The Security Key mixes those bytes with random bytes of its own, and produces an entirely random private elliptic curve key, let's call this A, the Security Key won't remember what it is for very long. It uses that private key to make a public key B, and then it _encrypts_ key A with its own secret key (let's call that S, it's an unchangeable AES secret key baked inside the Security Key) to produce E

The Security Key sends back E, B to the Client, which relays them to the Relying Party, which keeps them both. Neither the Client nor the Relying Party know it, but they actually have the private key, just it's encrypted with a secret key they don't know and so it's useless to them.

When signing in, E is sent back to the Client, which gives it to the Security Key, which decrypts it to find out what A was again and then uses A to sign proof of control with yet more random bytes from the Relying Party.

This arrangement means if Sally, Rupert and Tom all use the same Security Key to sign into Facebook, Facebook have no visibility of this fact, and although Rupert could use that Key to get into Sally's account, the only practical way to "steal" the continued ability to do so would be to steal the physical Security Key, none of the data getting sent back and forth in his own browser can be used to mimic that.

link
crunchatized 2881 days ago
Right, there's a good security reason they have the registration step. Though I don't think what you described is quite how it works. The FIDO and CTAP protocols don't let the Relying Party provide any entropy to the authenticator. The only input is the domain name(+ user handle in CTAP). Authenticator has to create the key with its own entropy. It doesn't need the server's entropy to have multiple keys per domain name.

(In Yubikeys' case, E is actually a Yubikey-generated random nonce that's used to generate the private key by HMAC-ing it with S and the domain name, not an encrypted private key, but that's all opaque implementation details. E can be anything as long as it reconstructs the key.)

link
tialaramex 2881 days ago
No, the Relying Party absolutely does provide entropy here. Specifically the "challenge" field which you probably think of as just being for subsequent authentication is _also_ present in the registration and is important.

This challenge field, as well as the origin (determined by the client and thus protected from phishing) are turned into JSON in a specified way by the client. Then it calculates SHA-256(json) and it sends this to the Security Key along with a second parameter that depends on exactly what we're doing (U2F, WebAuthn, etcetera)

You can see this discussed at the low level in FIDO's protocol documentation: https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fid... and you can see the Javascript end discussed in WebAuthn: https://www.w3.org/TR/webauthn/#createCredential

The Security Key doesn't get told the origin separately, it just gets the SHA256 output, this allows a Security Key to be simpler (it needn't be able to parse JSON for example) and so the entropy from the Relying Party has been stirred in with the origin before the Security Key gets involved.

As well as values B and E, a Security Key actually also delivers a Signature, which can be verified using B, over the SHA-256 hash it was sent. The Client sends this back to the Relying Party, along with the JSON, the Relying Party can check:

That this JSON is as expected (has the challenge chosen by the Relying Party and the Relying Party's origin)

AND

That SHA256(json) gives the value indicated

AND

That public key B has indeed signed the SHA256(json)

The reason they go to this extra effort with "challenge" and confirming signatures during registration is that it lets a Relying Party confirm freshness. Without this effort the Relying Party has no assurance that the "new" Registration it just did actually happened in response to its request, I could have recorded this Registration last week, or last year, and (without the "challenge" nonce from the Relying Party) it would have no way to know that.

Thanks for correcting me on how Yubico have approached the problem of choosing E such that they don't need to remember A anywhere.

[edited: minor layout tweaks/ typos]

link