Using a C# .NET rewrite of this U2F library I have discovered a bug which might also be present here. For more details, please check:
matsprea/AspNetIdentity_U2F#2

Google's paper:
http://fc16.ifca.ai/preproceedings/25_Lang.pdf

Specifies the following dead link:
https://github.com/google/u2fref-code/docs/SecurityKeys_TechReport.pdf

Demo website https://u2fdemo.appspot.com/ was working fine until Google Chrome Version 45 with Yubico Token. It stop working after last chrome update and that is 46.0.2490.71 m

Anybody has idea?

Thank you in advance...

void test_LeadingZero() {
U2FHID_FRAME f, r;
initFrame(&f, 0x100, U2FHID_PING, 10);

SEND(f);
RECV(r, 1.0);
CHECK_EQ(r.cid, f.cid);

CHECK_EQ(r.init.cmd, U2FHID_PING);
CHECK_EQ(MSG_LEN(f), MSG_LEN(r));

}
I have problem understanding the logic behind the test case. Why does the cid value is 0x100. The device initialized in the earlier part of the code gets some other value for the cid and how does the authenticator do any validation?

`
void test_Lock() {
U2FHID_FRAME f, r;
uint64_t t = 0; U2Fob_deltaTime(&t);
uint8_t caps = test_BasicInit();

`

Can someone explain us whats the role of test_BasicInit() in this. If the device has been already initialized in the previous test cases then why make one more call?

Lock being a optional command why should one has to go through the initialization again ?

Hi All,
I am currently in the process of fixing issues found by the hid compliance tool.

Wanted to understand the behavior expected in function call.
CHECK_EQ(-ERR_MSG_TIMEOUT, U2Fob_receiveHidFrame(device, &r, 0.6f));

All other conditions in the test cases pass except the above one, What should be done in HID to make U2Fob_receiveHidFrame() return -5 ?

I am currently ignoring such invalid requests and HID does not respond to erroneous requests.

Does that make U2Fob_receiveHidFrame() return -5?

Thanks,
-Harsha

The reference server is using an documented legacy format for sending requests to Google Authenticator on Android. Instead, it should be using requests of the format:
S.request=

A hint what a U2fSignRequest looks like, in the format of the 1.1 version of the JavaScript API:
{
type: "u2f_sign_request",
challenge: ,
registeredKeys: [{keyHandle: , version: "U2F_V2"}, ...]
}

The U2fSignRequest in the format of the 1.0 version of the JavaScript API is also supported, e.g.:
{
type: "u2f_sign_request",
signRequests: [{keyHandle: , version: "U2F_V2", challenge: }, ...]
}

The U2F Chrome Extension is not including the Le bytes in the request per the latest updates to the Raw Messages specification.

This is the complete request captured from the U2F Chrome Extension's console output using Chrome's Developer tools.

0100BC54830007000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Here is the breakdown.

CID: 0100BC54
CMD: 83
LEN: 0007
PAYLOAD: 00 03 00 00 00 00 00

The LEN should be 0009 so as to include the Le bytes ensuring that bytes 8 & 9 are 0x00.

Hello, I have downloaded this project and put ref-gae to run in localhost by using eclipse mars without modifying anything in code.

Then I have found that, the registration and authentication processes work fine when I use Fido U2F Google plugin.
But when I try to do the same thing by using chrome built-in u2f package (changing u2f.EXTENSION_ID value to u2f.EXTENSION_ID = 'kmendfapggjehodndflmmgagdbamhnfd') the screen shows a "Bad request" message.

As far I know, "Bad request" message could be received due to AppID errors or bad calling parameters, but like I have said before I haven't modified anything in the code and this is working using the u2f chrome extension and even it is working for Android by using Google Authenticator App too.

So, anybody could bring me a ray of wisdom?.

Thank you.

I'm testing out a new BLE/NFC/USB U2F device, and so far I've had no luck with BLE on macOS.

Just pairing the device seems to be tricky; macOS does not show BLE devices in their GUI.

After fiddling around with Apple's Bluetooth Explorer, I finally got the device paired with the correct passcode and it stays connected for a few seconds. (By design the device will power off after a few seconds.)

If I try to use the sample server in Chrome, it never seems to attempt/connect over Bluetooth. (The U2F device was previously paired via USB.)

Any ideas @jovasco or @juanlang?

Do you think this is a u2f-ref-code or Chromium/Chrome problem?

With the current version of U2F compliance tests, it does a check on counter as CHECK_EQ(ctr2, ctr1+1)
It expects ctr2 to be exactly equal to ctr1+1.

This test fails the U2F authenticators that increase counter value but not exactly by 1 each time.

Fido spec mandates to increase the counter for Authentication, but not exactly by one.
So the test ideally should be modified to CHECK_GE(ctr2, ctr1 + 1) to be completely compatible with Fido U2F Spec: https://fidoalliance.org/specifications/download/

The FIDO U2F JavaScript API version 1.1 adds an optional per-key handle transports value:
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#u2f-transports

This is defined as:
typedef sequence Transports;

The web server outputs this value as a comma-delimited string:
https://github.com/google/u2f-ref-code/blob/master/u2f-ref-code/java/src/com/google/u2f/server/messages/RegisteredKey.java#L110

The proper way to represent a WebIDL sequence in JavaScript is as an array:
https://www.w3.org/TR/WebIDL/#es-sequence

As a result, this format confuses clients that expect only spec-compliant transports values.

Our development servers are hosted on a github.dev domain that we resolve to the correct IP address. The code in u2f-chrome-extension/etld.js doesn't recognize this TLD and ends up throwing nonsensical errors. I've found a workaround for myself, but I thought I'd raise the issue here since I don't know of a great general fix. It would also be a pain if this ends up being the case for the native Chrome implementation.

Here's that patch that is working for me:

diff --git a/u2f-chrome-extension/etld.js b/u2f-chrome-extension/etld.js
index d6cd2b2..4eee300 100644
--- a/u2f-chrome-extension/etld.js
+++ b/u2f-chrome-extension/etld.js
@@ -123,6 +123,7 @@ EffectiveTldFetcher.prototype.loadEffectiveTlds_ = function(opt_index) {
   var self = this;
   return p.then(function(text) {
     var eTlds = self.getEffectiveTldsFromText_(/** @type {string} */ (text));
+    eTlds = eTlds.concat("dev")
     if (self.cacheEtlds_) {
       self.eTlds_ = eTlds;
     }

When calling u2f.register from another extension, the callback is never called, even with a timeout. No error, just vanishes.

To be clear, I am trying to write a new extension that uses the u2f-chrome-extension to handle talking to u2f token.

On the console for my extension, on first try, I get
Extension JS API Version: 1.1

So at least the version call back is working.

When debugging on the u2f-chrome-extension, I see the following error on the console:

webrequest.js:239 sendResponse failed: TypeError: Cannot read property 'id' of undefined
sendResponseOnce @ webrequest.js:239
sendErrorResponse @ enroller.js:28
handleU2fEnrollRequest @ enroller.js:51
handleWebPageRequest @ webrequest.js:124
messageHandler @ u2fbackground.js:165
(anonymous) @ u2fbackground.js:246
EventImpl.dispatchToListener @ extensions::event_bindings:388
publicClassPrototype.(anonymous function) @ extensions::utils:149
EventImpl.dispatch_ @ extensions::event_bindings:372
EventImpl.dispatch @ extensions::event_bindings:394
publicClassPrototype.(anonymous function) @ extensions::utils:149
dispatchOnMessage @ extensions::messaging:320

Digging further, this appears to be an error in sendResponseToActiveTabOnly @ u2fbackground.js

The function tries to determine if the tab that made the registration request is still active. To do so it accesses sender.tab.id, where sender is a MessageSender. However, I am calling from an extension, not a tab, and thus sender.tab is undefined.

This code path seems to only be for Register responses.

I don't see a good workaround for this. Unfortunately, I cannot absorb the u2f-chrome-extension into mine, because the u2f-chrome-extension requires some black magic to get permissions to the usb. I also can't seem to communicate directly with the built-in chrome from my extension.

Reported by STMicro, the standalone reference server doesn't actually work at the moment. It should be fixed, or removed in favor of the GAE server.

The standalone HTTP server sends the old-style enroll_web_request and sign_web_request, rather than the U2F-documented request types.

Went through the spec and the test cases implemented in HID compliance seems to be very confusing.
The spec also does not talk about the transaction start and end clearly.
https://fidoalliance.org/specs/fido-u2f-HID-protocol-v1.0-rd-20141008.pdf

2.5.1 Transaction atomicity, idle- and busy states.

1. In the compliance test cases what triggers closing of the channel on the HID side ?
2. Can someone please clarify the expected behavior of the authenticator ?

Many of the compliance issues we have been facing are due to inconsistent state of the authenticator.

Thanks,
-Harsha

test_Enroll currently uses a random application parameter when triggering a user presence test, and a different random application parameter after the presence test is complete. Real applications use the same application parameter each time, and any implementation that attempts to verify that the user has approved the registration of a specific application parameter will fail under this test suite.

u2f-chrome-extension

Lines like
https://github.com/google/u2f-ref-code/blob/master/u2f-chrome-extension/u2f-api.js#L25
u2f.EXTENSION_ID = 'pfboblefjcgdjicmnffhdgionmgcdmne';
overwrite an existing u2f implementation.

I think that if chrome already has defined window.u2f then the extension should not redefine it.

if (!("u2f" in window)) {
var _gu2f = {
EXTENSION_ID = 'pfboblefjcgdjicmnffhdgionmgcdmne',
...
};
window.u2f = _gu2f;
}

ETLD_NAMES_LIST in etld_names_list.js does not contain 'co.za' and others. Did I miss something?

If I want to use the code in u2f extension in my own extension, I cannot get through this because of the manifest.

There were warnings when trying to install this extension:

• 'hid' is only allowed for packaged apps, but this is a extension.
• 'usb' is only allowed for packaged apps, but this is a extension.
• 'usbDevices' is only allowed for packaged apps, but this is a extension.

I cannot use it in an app though, because google is retiring Chrome Apps and will not allow new apps soon.

Found some places to modify the listening domain,
still don't work....

is this implementation able to achieve this requirement?

Hi,

I have this U2F security key:
http://www.amazon.com/Plug-up-International-U2F-SK-01-FIDO-Security/dp/B00OGPO3ZS

This one has no button on it..sow how to work with this kind of U2F keys?

Regards,
Bastiaan

u2f-api.js has moved on to the 1.1 API, but no longer supports the 1.0 API.

E.g., u2f.register() in the 1.0 format cause an error (the first parameter is interpreted as appId while it's actually an array of register requests)

Add additional logging to test harnesses to provide a better audit trail for formal certification. The logs should include:

• Version numbers of operating system(s), tools etc.
• Hardware information where available
• Time stamps for operations

Chrome 41 does not seem to support the TrustedFacets structure that is declared by the specification.

Instead it supports the old, never standardized, way of listing facets which looks like this:

[
"https://accounts.google.com",
"https://myaccount.google.com",
"https://security.google.com"
]

This causes confusion for implementors of U2F.

In U2FTest.cc, in the below mentioned portion of code
PASS(ctr1 = test_Sign(0x9000));
PASS(test_Sign(0x6985));

For the second sign call(Line No:366 in U2FTest.cc) after ctr1 which is hightlighted, the sign response is expected to fail with 6985 code.
Is there a reason why we expect a valid sign request to fail ?

In u2f_nfc_test.cc, in the below mentioned portion of code:

std::cout << "\nCheck Bad CLA Response";
CHECK_NE(0x9000, xchgAPDUShort(1 /* not U2F CLA, 0x00 */, U2F_INS_AUTHENTICATE, 0, 0, 0, "abc", &rapduLen, rapdu));
CHECK_EQ(0, rapduLen);

For some NFC authenticator, on contactless protocol (NFC), it only supports one basic logical channel. So after select the FIDO applet, when apdu class is 0x01, this authenticator will ignore the channel number in class byte and direct the command to the applet, and Authenticator replies with success (9000).

As multi logical channel on NFC in authenticator is not a requirement in FIDO spec, can we remove this bad cla response test?

When the server sends a U2F request to a U2F JavaScript API version 1.1-compatible client, it sends a request such as:

{"type":"u2f_register_request","appId":"https://u2fdemo.appspot.com","registerRequests":[{"challenge":"...","version":"U2F_V2"}],"registeredKeys":[{"appId":"https://u2fdemo.appspot.com","version":"U2F_V2","keyHandle":"..."}],"timeoutSeconds":30,"requestId":1}

Note that the outer request contains an appId value, and the registeredKeys object also contains an appId value. This is legal, but it contains the same value as the outer request--this is unnecessary, and wastes space. It should be omitted.

Once a U2F action is triggered, the chrome extension opens all the applicable HID devices on the system in an exclusive manner, preventing any other browsers or software from accessing them until the browser is completely closed.

This does not occur in other implementations; the test suite in this repo and the U2F extension for Firefox come to mind.

(It also plays havok with debugging. I have to close the whole browser to run a new set of tests.)

The HID test case test_LongEcho() checks at the time taken for the authenticater to respond.

See below.
CHECK_GE(sent, .020);
CHECK_LE(sent, .075);
CHECK_GE(received, .020);
CHECK_LE(received, .075);

Want to know any specific reason behind the time limit values.

Also don't find anything related to this in the spec.

Origin should be verified against one of the valid origins in AppModule

u2f-ref-code (enroll.html and sign.html) source u2f-api.js from the extension (which is no longer there).

appspot.com supports TLS channel IDs, as does Chrome. The U2F assertions bind the TLS channel ID state. The u2fdemo site should show whether it believes the TLS channel ID state is valid or not for each assertion it receives.

I would like to develop a server side service making use of U2F, this service, exposing its API via REST calls and via websockets, will be accessible via different means: for example a web site, via a chrome/ff extension, and maybe via a custom mobile application.

In this scenario I'm unable to understand how do I need to set the URL parameter of the U2F request.

Since the goal is to have the same service accessed via different means, it should be natural for me to use the same U2F key when I login via web (using a public http server), or for example with a cordova-packaged app on my phone that is using localhost as a source for its files.

Does this means that I've to detect (i.e.: ask to the app) how it's accessing the API, and register several times the U2F device, for every different app I'm using to access the same service?

For example, a packaged app is accessed using localhost, but it connects the the remote server (the one that needs the 2fa) via websocket using a ws://domain.ext url.

Since using a remote service (that wants to use 2fa) via its API is now quite common, as it's common to develop javascript packaged applications running on the client, I suppose that there must be the "right" way to do it, but I've not yet understood which one, or even if it's possible at all.

On u2fdemo.appspot.com demo app, new registrations should show up at the top of the list, to make it easier to use this website for regular testing of U2F clients.

Also, fix incorrect padding/animation where buttons are clipped.

In case this is useful to this project in some way -- I implemented U2F support into a personal Ruby (Sinatra) app backend, and documented the code and the workflow in great detail here:

https://github.com/konklone/konklone.com/pull/144

Hi

I see some iOS support in U2F API js, if so, which version or what kind of HW adapter does this work with?

Thanks

I am trying to run u2f-ref-code on my local environment. I ran m.google.u2f.tools.httpserver.U2fHttpServer . This started the basic http server at 8080 port.

On accessing http://localhost:8080 , I see home page. On clicking "Test Registration" it fails in javascript error:

denying load of chrome-extension pfboblefjcgdjicmnffhdgionmgcdmne/u2f-api.js . Resource must be listed in the web_accessible_resources . Here is the screenshot.

Then I tried to load the unpacked chrome extension ( u2f-chrome-extension ). I planned to add u2f-api.js in web_accessible_resources . But there is no u2f-api.js in that project. I found one u2f-comms.js instead.

I restarted chrome browser with --show-component-extension-options command line. Then in CryptoTokenExtension extension I set HTTP_ORIGINS_ALLOWED = true . In the u2f-ref-code app I replaced extension: pfboblefjcgdjicmnffhdgionmgcdmne to chrome-extension://kmendfapggjehodndflmmgagdbamhnfd . Even then I got same error.

Denying load of chrome-extension://kmendfapggjehodndflmmgagdbamhnfd/u2f-api.js. Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.

How can I run sample java u2f app? Am I missing any step?

Browser Info:
Chrome Version 48.0.2564.116 m
Latest FIDO U2F (Universal 2nd Factor) extension

Hi

Does your API supports https://developers.yubico.com/U2F/App_ID.html ?
"
Multi-facet apps

If an app has many facets the AppID should be an HTTPS URL that resolves to a JSON list of facet IDs. For example:

https://example.com/app-id.json
…which could resolve to the following JSON content:

{
"trustedFacets" : [{
"version": { "major": 1, "minor" : 0 },
"ids": [
"https://login.example.com",
"https://secure.example.com",
"android:apk-key-hash:585215fd5153209a7e246f53286035838a0be227"
]
}]
}
"
Thanks

The intended difference between the no-ext branch and the master branch is which extension id is talked to. This should be addressed by different config files for the running server instance, but otherwise contain identical running code.

At the moment, the branches differ by more than just this respect:

1. The master branch contains the source for the U2F extension.
2. The no-ext branch has been used for development of U2F support in mobile browsers. This development is limited to the Javascript library containing the U2F high-level Javascript API, implemented using the low-level API on each browser.

In my opinion, the U2F extension source should be independent from the source for any particular web server instance.

Similarly, I believe the U2F high-level API library should be its own module, and a running web server instance would depend on it. In this way, a web server could integrate with a "stable" version talking only to Chrome if it wished, or include features still under active development.

I propose the u2f-ref-code repository be structured instead into sub-modules, consisting of the followign sub-modules:
chrome-extension source for U2F Chrome extension
demo-server source for a demo web server
demo-server-config source for a running web server's config files
u2f-api source for U2F Javascript API library

The demo-server-config repository could have different configs on different branches.

The difference between the running instances https://u2fdemo.appspot.com and https://crxjs-dot-u2fdemo.appspot.com would then be:

1. Which branch of the demo-server-config module it runs.
2. Which version of the u2f-api branch it depends on.

Feedback or alternate proposals?

E.g., response objects are dereferenced without checking for null. Update the JS code to what the GAE server uses in general.

App works fine when I directly invoke it from the browser--however, there is a timeout error when invoked from an application which downloads it in iframe. There is timeout error on clicking U2F register button.

I just noticed that you use $.inArray for determing if it's an iOS device in u2f-api.js.

I suggest removing jQuery as an dependency, by replacing it with a simple if statement :-)

Hi Everyone,

I'm trying to modify the U2F ref code but I don't have enough knowledges in Java Web application development. I need a documentation, UML or description for all important classes in this project.
I've to implement this solution for a GWT Project.

Thank you,

Hello,

The abstract of http://fc16.ifca.ai/preproceedings/25_Lang.pdf says, "An updated and extended tech report is available at https://github.com/google/u2f-ref-code/docs/SecurityKeys_TechReport.pdf ." However, that URL returns 404 error. Is the updated and extended tech report available at a different location?

Thanks,
Jim

Hi gentlemen,

at this point, the U2F HID test always tests non-zero CLA with value 0x01. I don't think this is a good way to test this. 0x01 encodes a logical channel number and if you feed this directly into a secure element it will almost certainly give you an error value (unless you have configured to use logical channel 1, i think) but other values are not necessarily illegal and may be accepted (and most likely ignored). See also http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#chap5_4_1

Currently, the BLE tests use a random value but this is not necessarily a good way since it might just work by accident.

Perhaps we could just use a list of likely problems cases and a number of random values.

When the server sends the transports field to the client, using the U2F JavaScript API version 1.1, it does so using values not defined in the API. Example request:

{"type":"u2f_register_request","appId":"https://u2fdemo.appspot.com","registerRequests":[{"challenge":"...","version":"U2F_V2"}],"registeredKeys":[{"appId":"https://u2fdemo.appspot.com","version":"U2F_V2","keyHandle":"...","transports":["BLUETOOTH_LOW_ENERGY"]}],"timeoutSeconds":30,"requestId":1}

This value, "BLUETOOTH_LOW_ENERGY", is not defined in the spec. (The defined value for Bluetooth Low Energy is "ble".)

Will browsers match "www.example.com" against "example.com" AppID?

More context here:
http://stackoverflow.com/questions/27756287/u2f-application-id-facet-id-for-a-web-site