Re: [webauthn] <new proposal> Extending WebAuthn Protocol for Remote Authentication (#1580)

I agree with Shane that the image capture and signing would both need to happen within the "authenticator boundary" in order for this to be meaningful. It seems like the proposal could be construed like that, but I think the whole "image attest service" would have to be implemented in a secure enclave - otherwise it's likely that a rooted/jailbroken phone, for example, could easily spoof the attestation and use it to sign arbitrary data. And if it's possible to jailbreak even one phone in this way, that means you could connect that one jailbroken phone to a web service allowing anyone to circumvent any system relying on ImageAttest. I'm personally not familiar enough with secure enclaves to say whether that is feasible.

If we assume that can be solved, though, I think the proposed API could be simplified to fit within the existing [extensions framework](https://w3c.github.io/webauthn/#sctn-extensions). I think this could be an authenticator extension something like this:

```
$$extensionInput //= (
  imageAttest: true
)
$$extensionOutput //= (
  imageAttest: { img: bytes }
)
```

and the signature is just the ordinary assertion signature, which includes the above extension data in the signed data. This would make it even more clear that the image capture and signing all happens within the authenticator boundary.

The registration procedure probably doesn't need to change at all, other than adding the extension input. This would however mean there is no difference between an ordinary authenticator and an "ImageAttest authenticator" - an "ImageAttest authenticator" would simply be an ordinary authenticator that also supports the `imageAttest` extension (most likely a platform authenticator integrated in the operating system).

---

> It may be better to frame the proposal as signing arbitrary data than using the camera example. It makes it clearer that the proposal can have many more applications.

I disagree - this would successfully defend against malicious RPs, but the purpose of the solution proposed here (as I understand it) is to defend against malicious _users_. The distinguishing feature is that the client is the source of the data to be signed, so making it an arbitrary data signing service would make it useless for this purpose.

In fact it is already possible to (ab)use the WebAuthn API for arbitrary data signing: just set `challenge = sha256(nonce, documentToSign)` for example.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1580#issuecomment-794080367 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 9 March 2021 15:54:47 UTC