[webkit-dev] Implementing Universal Second Factor (U2F)

[Jacob Greenfield]

Michael,

Thanks for the info. After looking into things a bit more - let me know if this does not make sense - it looks like it may be better to reimplement for WebKit.

Specifically, it looks like hidapi does some opaque stuff with threading that may leave idle threads around, to expose a consistent API across platforms. 

The other reason (and an area I haven't explored much yet) is that much of the code in libu2f-host doesn't seem to be concerned with the protocol itself, but with other details of the protocol - stuff that WebKit already has; the biggest two I see are (and it looks like another dependency on JSON-C here) formatting browser responses and base64 encoding.

On a cursory glance at their code for reading a response from the device, it looks like 2 threads will have to be spawned: one to allow libu2f-host to block (it calls sleep if the device isn't ready) on a response from hidapi, and one for hidapi to monitor the device.

It looks like doing a clean implementation for Linux should also not be too hard; I think it would be okay to only enable it if hidraw is available, which should be the case now on most shipping kernels for desktop distros.

The Windows API also seems to have some HID stuff; I can look into this if any ports which would enable this feature want Windows support.

- Jacob Greenfield

> On Feb 22, 2017, at 10:17, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
> 
>> On Wed, 2017-02-22 at 08:52 -0500, Jacob Greenfield wrote:
>> The (USB) protocol itself works by sending USB HID reports (packets)
>> to the key and getting USB HID reports back. There is a reference
>> implementation by one of the members of the specification group -
>> libu2f-host (by Yubico); however, it is licensed under GPL and
>> LGPLv2.1.
> 
> Hi,
> 
> According to the documentation:
> 
> "The library and command-ine tool is licensed under the LGPLv2+
> license. Some other files are licensed under the GPLv3+ license."
> 
> Sounds like a perfectly acceptable dependency for WebKit. The only
> trick is that if you need to import the source code under
> Source/ThirdParty (hopefully not), then you'd need to remove all the
> GPLv3+ files from the repository.
> 
>> - What to do about other platforms - no implementation, use libu2f-
>> host for them, or use libu2f-host everywhere
> 
> Ideally we would use the same code on all platforms unless there is a
> strong reason not to do so, to reduce the amount of platform-specific
> bugs. I'm not sure if there exists such a situation here, so using
> libu2f-host on all platforms seems to make the most sense. Possible
> examples of strong reasons to diverge:
> 
> * If removing the GPLv3+ files would be somehow problematic. GTK+ port
> doesn't care so long as none of the GPL files are used by the library
> itself. Apple is much stricter; I guess they might not allow the files
> to be imported into internal build systems. That could create a
> maintenance headache.
> * If the extra dependencies are problematic for some platform. You'd
> be hard-pressed to find a Linux system without libusb, and hidapi and
> libu2f-host both look unproblematic. But adding your implementation
> directly to WebKit might be easier for Mac ports.
> 
>> - UI for key access permission - malicious sites could (eventually)
>> lock up a key, as well as possibly identifying a user; the
>> specification suggests displaying an info bar for user to allow
>> access - but, I’m not familiar with the process of designing/adding
>> browser chromes
> 
> Sounds like WebKit should request a policy decision from the client on
> whether to allow a website to use the U2F API? Then making that
> decision in a secure manner is the responsibility of the client to
> figure out. In Epiphany we display info bars the first time a
> particular security origin requests a permission, and remember the
> user's choice in the future.
> 
>> - What process should communicate with the token - the protocol is
>> robust and designed for many simultaneous accesses and appropriate
>> isolation of them, so this can (should?) be per-page; IOKit needs a
>> CFRunLoop to schedule the report receive callback on: should this be
>> on the main runloop or on another thread just for U2F?
> 
> I don't know which process, but you should use the main runloop. Let's
> avoid creating a new always-running thread for a feature that will
> rarely be used.
> 
>> - Presumably, this should be gated behind a macro; does a suitable
>> one exist, or add a new one?
> 
> You'll have to add a new one, ENABLE_U2F. It's better not to gate
> features when possible, but in this case one will be required due to
> the new dependencies as we want to allow distributions that do not have
> the new dependencies to continue to build without them (with reduced
> feature set) for the next few years.
> 
> Michael