W3C home > Mailing lists > Public > public-webauthn@w3.org > March 2021

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

From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
Date: Mon, 15 Mar 2021 18:20:03 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-799643388-1615832402-sysbot+gh@w3.org>
>We have implemented the signing of camera data in TEE environment on an Android device. The camera data is **sent directly to the secure enclaves**.

(Emphasis added)

The point I'd like to make is: are you also _collecting_ the camera data within the TEE boundary? Because the above sounds to me like the camera data is collected outside the TEE, and then sent into the TEE to be signed. But my understanding of the problem here is that you don't trust that the user is honest about where the image comes from. For example, a cryptocurrency exchange might want to prevent users from submitting a passport photo purchased on the dark web.

Assuming that is the case:

- If you (the server) trust the end-user and the client, then you do not need this extension. You can just collect the data to be signed, mix it into the `challenge` and get a normal WebAuthn assertion for that `challenge`.
- If you (the server) _do not_ trust both the end-user and the client, then you cannot trust any code running outside the TEE or your server. By extension, you cannot trust any data originating outside of the TEE or your server. Therefore you must run the whole camera stack - trusted hardware running trusted code - inside the TEE, otherwise your TEE will be signing untrusted data.

If you rely on an untrusted camera application (as opposed to one code-signed and trusted by the TEE) to provide the image data, then the signature will not provide the assurances you seem to want it to.

Please correct me if I misunderstand what problem you want to solve.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 15 March 2021 18:20:05 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:43 UTC