[messaging] abusing u2f

[elijah]

On 03/24/2016 04:42 PM, Trevor Perrin wrote:
> On Thu, Mar 24, 2016 at 3:58 AM, Michael Rogers
> <michael at briarproject.org> wrote:
>>
>> I'm probably missing something, but it seems to me that if you're using
>> the public key only as a (high entropy, easily disposed of) input to
>> local key derivation, an ordinary flash drive with some random data
>> would work just as well
> 
> That seems right - the protocol Elijah linked [1] just fetches a
> "secret" from the device, then does password-hashing using that
> secret.  So while the device and password are two separate factors for
> decrypting local-stored data, they don't force a device-thief to
> interact with the device for every password guess.

My primary assumption is that u2f will become popular, and it would be
nice to support the dongles that people are already carrying around.

I think you could modify the "abusing u2f" scheme to achieve the desired
result that an attacker must manually press the button on the u2f dongle
each time they wanted to make a password attempt. Lets call this "extra
abusing u2f".

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