On 24 March 2016 at 19:41, elijah <[email protected]> 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
