[messaging] abusing u2f

[Tom Ritter]

On 24 March 2016 at 19:41, elijah <elijah at riseup.net> wrote:
> In order to authenticate with the u2f dongle, the code must present the
> u2f API with three pieces of information: key handle, app id, and a
> challenge. If successful, you get back a signed challenge. The key
> handle is entirely determined by the u2f dongle, and is implementation
> specific. But the app id can be anything you want, although it is
> supposed to be a hash of the origin domain (or an arbitrary domain in
> the case of non-webapps).
>
> If the app id is wrong, the u2f dongle will fail the authentication
> attempt. So... maybe the app id could be derived from kdf(username,
> password).
>
> There are, however, potentially a few problems with this:
>
> (0) Although private keys are supposed to be difficult to extract from a
> u2f dongle, I am not sure about app ids. I don't understand how those
> implementations work that have no memory, I guess they re-generate the
> keys each time, using the key handle as a seed?
>
> (1) I am not sure if the spec requires user interaction before failing
> authentication if the app id is wrong. I assume so.
>
> (2) the notes [1] say that the key handle should encode the app id (hash
> of origin domain) in the key handle, but does not specify how. this is
> so that the u2f dongle, without storing app id, can confirm that app id
> matches key handle. depending on the implementation, this could render
> "extra abuse" strategy useless.
>
> -elijah
>
> [1]
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html#site-specific-public-private-key-pairs

In the web browser context, I'm pretty sure you don't control the app
id - it's determined from the origin in the web browser and passed to
the dongle.  If you could control it, it would be trivial to do
cooperative cross-origin tracking.

-tom