On 03/24/2016 04:42 PM, Trevor Perrin wrote: > On Thu, Mar 24, 2016 at 3:58 AM, Michael Rogers > <[email protected]> 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
