- From: Dennis Jackson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 14 Oct 2019 21:34:51 +0000
- To: public-webauthn@w3.org
Hi @emlun, I took a quick look over the extension draft and have some feedback on the crypto design which is below. Best, Dennis **Missing Requirements** It should be specified that `S` must be kept secret, otherwise collaborating RPs can forge an otherwise valid credential id and test whether a user holds the corresponding private key, which uniquely identifies the user. This is a weak guessing attack violating unlinkability. Currently, Bob / the backup device is required to verify an alleged `E` is not invalid according to SEC 1, section 2.3.4. This procedure still allows for the `E` to be the point at infinity, which is invariant under scalar multiplication. This allows for a powerful attack on unlinkability: A malicious RP can forge a credential id with `E` equal to the point at infinity. The resulting shared secret is also the point at infinity regardless of `S` and consequently the RP can forge the MAC value and derive the credential key. The RP then prompts the user to begin the recovery procedure. Bob / the Backup token will derive `P` and transmit `P` and a signature to the RP (`P` is sent as attested credential data). The RP can then subtract `cred_key * G` from P to learn `S` which uniquely identifies the user. Consequently, devices must ensure `E` is not the point at infinity (or any low order point in a non-prime order group). **Minor Quibbles:** Why use each half of `HKDF(e * S)` as opposed to two distinct invocations of HKDF with different labels? Wouldn't the latter be cleaner? Why add `cred_key * G` to `S`? What purpose does it serve over using `cred_key * G` directly? -- GitHub Notification of comment by galadran Please view or discuss this issue at https://github.com/w3c/webauthn/issues/931#issuecomment-541935417 using your GitHub account
Received on Monday, 14 October 2019 21:34:53 UTC