Overriding Built-In Chrome U2F With Plugin

[Scott Stephens]

I'm interested in writing a software U2F token. It seems to be easy enough technically, with a simple software token already existing in the Chrome plugin in the reference implementation at https://github.com/google/u2f-ref-code. Out of the box the reference plugin only works on a demo site: https://crxjs-dot-u2fdemo.appspot.com . I got it to work with the Yubico U2F demo (https://demo.yubico.com/u2f) by overwriting the value the page sets for u2f.EXTENSION_ID in a content script. However, this approach didn't work at all for logging into Google accounts, and worked for registration but not for signing on Github. Is there a reliable way to have a Chrome plugin override the built-in U2F support so it can work with all or most sites supporting U2F?

[Arshad Noor]

Scott,

Software libraries supporting U2F are generally written as experimental implementations to demonstrate the protocol, and to show software developers how it works.  From a security pov, it is not advisable to use a software authenticator for production uses for a variety of reasons:

• The cryptographic key-pair will only be protected by a password - and we all know how secure they are;
• The private key of the Attestation Certificate that must be embedded in each Authenticator will be quickly compromised leading to spurious authenticators claiming to be the original;
• As FIDO Alliance ramps up Security Certification of authenticators, Relying Parties will surely reject any registration from a software-based authenticator (because of the first 2 problems).

Could you work up mechanisms to put more controls around the software authenticator to protect it from external attack?  Yes, you could; but now you might require users to do things that cross their pain-threshold.  Especially when hardware-based authenticators with secure-elements are available for a little over the price of a coffee at Starbucks and are no-brainers to use and protect (I have mine on my key-chain with my car-keys).

On the other hand, if you're doing this as an exercise for a school project, that's a different matter - and you should probably highlight that in your posting to elicit the right answer from the forum.

Arshad Noor
StrongAuth, Inc.

[Scott Stephens]

Hi Arshad,

Thanks for the response. I'm not a student and my ultimate intention is to get something production grade. I'm aware of the limitations of a software token, and definitely not advocating their use instead of hardware tokens, but rather in addition. Let me add some detail about what I'm up to and hopefully it will seem a little more sane.

The problem I'm looking to tackle is backing up U2F tokens (or rather, arranging for backup access to U2F protected services, since backup is by design impossible). For a corporate deployment (where I think a lot of the emphasis has been so far), it doesn't really matter. If you lose your token, you go get another one from the helpdesk. For consumer adoption, I think it's going to be an issue. The advice I've seen on this is typically to either use a non-U2F backup method provided by each service with which you use U2F, or to get a backup token. Both of these leave a lot to be desired. The existence of a non-U2F backup poses all the same security concerns as using those as the primary second factor method. For the more secure methods (ie, print one time codes, delete from computer), it introduces a bit of a logistical problem. With a backup token, the problem is that you need possession of the token in order to register it as a backup (at least with the tokens and client software with which I am familiar). So the best you can probably do is keep a second token at home. That means if you register away from home, you have to remember to register a second time with your backup. And it means that a lot of the time your backup is in the same physical location as your primary, making it a pretty poor backup.

There are two backup options I'm interested in exploring. The first is a human readable backup. Basically, generate a public/private keypair, print the private key 3 times, laminate them, put one in your wallet, one in your desk drawer at home, and one at a friends house, then delete the private key from your computer. Put the public key in your Dropbox. When registering for U2F at a new site, register your hardware token and your backup paper token. If you lose/destroy your hardware token, type or scan in your paper backup to a soft token, and use that until you can get a hardware replacement.

The second is a hardware backup that can be registered without having possession of the token. The workflow looks like this: get 2 backup tokens, extract their public keys and store them in your Dropbox, keep one backup at home, and one at a friends house. When registering for U2F at a new site, register your primary token along with your two (not physically present) backups.

Backup option number one can be enabled by a software U2F token. There are certainly security issues with this approach, with the private key vulnerable to interception during generation and backup use. However, I would argue that they are similar to the risks associated with typical non-U2F backup methods. As a consumer, security is important to me, but availability is as well. I personally think the availability/security trade-off makes sense for this use case. That said, your points about the attestation key and relying party use of attestation certificates are definitely issues with this approach.

Backup option number two needs firmware support and a partial software token (supporting registration, but not signing). This setup has a stronger security profile, with no sensitive data ever unprotected by hardware. The backup tokens can protect the attestation key and the user's private key, and produce a public key signed by the attestation key that can be loaded into the software token. I don't see any fundamental security problems with this that would lead a relying party to blacklist these devices. However, I haven't dug into the attestation process enough yet to figure out whether the registration process requires some relying party provided data to be signed by the attestation key. If that's the case, then attestation keys would also be a problem with this method.

So, all that said, can anybody comment on the technical feasibility of creating alternate U2F clients?

[Marius Schilder]

On Sun, Jul 23, 2017 at 12:14 PM, Arshad Noor <arsha...@strongauth.com> wrote:

Scott,

Software libraries supporting U2F are generally written as experimental implementations to demonstrate the protocol, and to show software developers how it works.  From a security pov, it is not advisable to use a software authenticator for production uses for a variety of reasons:

• The cryptographic key-pair will only be protected by a password - and we all know how secure they are;
• The private key of the Attestation Certificate that must be embedded in each Authenticator will be quickly compromised leading to spurious authenticators claiming to be the original;
• As FIDO Alliance ramps up Security Certification of authenticators, Relying Parties will surely reject any registration from a software-based authenticator (because of the first 2 problems).

Let's not forget that phishing is the main problem U2F was designed to address.

And no amount of fob certification will help much in presence of host malware.

Why are we on a certification binge, whilst phishing is still rampant?

We should strive to get the protocol out there everywhere first.

And software implementations are a great low-threshold vehicle.

Could you work up mechanisms to put more controls around the software authenticator to protect it from external attack?  Yes, you could; but now you might require users to do things that cross their pain-threshold.  Especially when hardware-based authenticators with secure-elements are available for a little over the price of a coffee at Starbucks and are no-brainers to use and protect (I have mine on my key-chain with my car-keys).

On the other hand, if you're doing this as an exercise for a school project, that's a different matter - and you should probably highlight that in your posting to elicit the right answer from the forum.

Arshad Noor
StrongAuth, Inc.

On 07/22/2017 09:17 PM, Scott Stephens wrote:

I'm interested in writing a software U2F token. It seems to be easy enough technically, with a simple software token already existing in the Chrome plugin in the reference implementation at https://github.com/google/u2f-ref-code. Out of the box the reference plugin only works on a demo site: https://crxjs-dot-u2fdemo.appspot.com . I got it to work with the Yubico U2F demo (https://demo.yubico.com/u2f) by overwriting the value the page sets for u2f.EXTENSION_ID in a content script. However, this approach didn't work at all for logging into Google accounts, and worked for registration but not for signing on Github. Is there a reliable way to have a Chrome plugin override the built-in U2F support so it can work with all or most sites supporting U2F?

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+unsubscribe@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/49e869d1-13fb-93df-6270-f7babb19cc1a%40strongauth.com.

[Arshad Noor]

On 07/26/2017 12:22 AM, 'Marius Schilder' via FIDO Dev (fido-dev) wrote:

On Sun, Jul 23, 2017 at 12:14 PM, Arshad Noor <arsha...@strongauth.com> wrote:

Scott,

Software libraries supporting U2F are generally written as experimental implementations to demonstrate the protocol, and to show software developers how it works.  From a security pov, it is not advisable to use a software authenticator for production uses for a variety of reasons:

• The cryptographic key-pair will only be protected by a password - and we all know how secure they are;
• The private key of the Attestation Certificate that must be embedded in each Authenticator will be quickly compromised leading to spurious authenticators claiming to be the original;
• As FIDO Alliance ramps up Security Certification of authenticators, Relying Parties will surely reject any registration from a software-based authenticator (because of the first 2 problems).

Let's not forget that phishing is the main problem U2F was designed to address.

And no amount of fob certification will help much in presence of host malware.

Why are we on a certification binge, whilst phishing is still rampant?

We should strive to get the protocol out there everywhere first.

And software implementations are a great low-threshold vehicle.

FIDO protocols solve many problems: shared secrets for authentication, weak passwords, password-reuse, dictionary attacks and phishing.  If I had to classify any one as the most egregious, it would be that it is a shared secret - it makes all the other password vulnerabilities possible.  FIDO is the industry's second major attempt at trying to eliminate passwords with public-key cryptography.  We want to try to avoid the problems the first attempt (PKI) created for itself. 

While software implementations appear to be low-threshold, the worst thing we could do is something that would make FIDO appear insecure or weak to RPs.  The FIDO ecosystem has gotten off to a good start in making U2F hardware based - and making it reasonably inexpensive and easy to use.  All we need now is to establish external confirmation that they are secure.  When FIDO Authenticators are certified with security levels, they offer independent validation that they offer certain levels of protection that benefit the consumer and the RP.  At those levels, it drives costs down because risk is mitigated on both sides of the transaction; this becomes a virtuous cycle where, eventually, FIDO Authenticators become "free" and passwords are eliminated.

However, this will only happen if consumers believe - and RPs can affirm - they can trust FIDO.  The functional certification is assurance they're not buying a dud; the security certification is assurance they're being reasonably protected from harm.  Software-based Authenticators make it very much more difficult to do this.  If RPs have to build in controls to filter out software Authenticators (because it increases the RP's business risk), and consumers experience unpredictable behavior - with some sites accepting their software Authenticators and others not - then FIDO becomes a non-starter.  And, we will walk down the PKI path again. 

Arshad Noor
StrongAuth, Inc.

[Fred Le Tamanoir]

Hi Scott,

thanx for your question and input, "backup" is a real issue and many people and integrators will have their own view on this point.

I will disregard your first backup option for obvious reasons, the need of backup shouldn't lower the security of the solution.

Your second way with a register-capable-only hardware token... I understand your point regarding registration but I don't understand how the authentication part would work.

May I suggest another way to have a backup solution :

- You can use a U2F hardware token that wraps keys with a secret that you can backup (and choose, ideally) and restore. 

In fact, there is already an existing (but not cheap) solution doing this : Ledger Nano S.

I will investigate this idea as an option for our own future U2F product series.

Regards

--

Frederic MARTIN
Security Architect
NEOWAVE

[Scott Stephens]

Thanks for the tip on the Ledger Nano S. I don't think it will meet my needs, but it's good to know it exists. Right now I consider U2F to be a good solution for a small number of very important accounts, where dealing with site-specific recovery is a reasonable amount of overhead. I think the technology gets more interesting if it can get to the point where it's usable for every site. Backup is one aspect of that, but form factor is another, and needing a cable for the LNS pushes it past reasonable form factor for me personally.

> Your second way with a register-capable-only hardware token... I understand your point regarding registration but I don't understand how the authentication part would work.

Yeah, since writing that comment I've come to realize the method I had in mind won't work, at least not without getting RPs to accept an attestation key unprotected by hardware. I've got another idea that I think will achieve the same goal though. The idea is you'll have several tokens which function together as a group. Any token in the group can register itself and authenticate as itself, but also register the other tokens in the group (but not authenticate as those tokens). All tokens would have the same attestation key, and would have a base key pair specific to each token. The private keys of the attestation and base keypairs would never leave the hardware. The base public key of each token would be loaded into the other tokens in the group. A token would register a remote group token by generating a new site keypair, setting the keyhandle as the site private key encrypted with the remote base public key, and signing the registration challenge, app id, keyhandle, and site public key with the attestation private key. Ideally the registering token would also put a signature of the site private key with its base private key in the keyhandle, but I'm not sure if the keyhandle is allowed to be big enough to support that. 

> I will investigate this idea as an option for our own future U2F product series.

That'd be great, I'd probably rather buy this than build it.

--
You received this message because you are subscribed to a topic in the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this topic, visit https://groups.google.com/a/fidoalliance.org/d/topic/fido-dev/Wbcgjs-8UvY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fido-dev+unsubscribe@fidoalliance.org.

To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/bae37cd5-a658-47f4-940b-23b136de4a94%40fidoalliance.org.

[Arshad Noor]

Hi Scott,

Apologies for the slow response; so much to do and so little time...

If I followed your logic correctly, I presume you expect to generate a single key-pair for backup, store the private-key offline and use the public-key to keep registering yourself as a secondary key when you use your primary hardware Authenticator to generate a new key-pair for a specific site.

Unfortunately, this will not work with both the options you defined.  The U2F protocol requires that the Attestation Certificate's (AC) private-key sign a dynamic challenge sent by the server to register a key.  You will not only have to carry the User public-key, but the AC and its private-key around with you.  And, Relying Parties can still reject your registration because they may have configured policies to restrict which ACs (or AC chains) they will accept.

IMO, people will wind up having multiple Authenticators on them in the not-too-distant future:

1. In their mobile phone as a built-in Authenticator (UAF has it today, U2F will have it soon - based on Google's announcement at their I/O conference - and WebAuthentication will undoubtedly have it too);
   
2. On their physical key-chain - either as a USB-based Authenticator or as an NFC/BLE one embedded in their key fob;
3. In their wallet as a smartcard from a government agency or financial institution.

So, if you have at least 3 hardware-based Authenticators on you at all times, is there a problem that needs to be solved?  If you're looking for a backup solution for the immediate future - its as little as USD 10.00 on the internet.  A solution not as stimulating intellectually, but certainly allows us to go onto solving bigger problems (hopefully).

Arshad :-)

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/621c1d0f-9173-4d87-be8e-e2e3da98ac75%40fidoalliance.org.

[Scott Stephens]

> You will not only have to carry the User public-key, but the AC and its private-key around with you.

Yeah, I eventually realized this. It kills my second scenario of software registering a non-present hardware token to a RP that is picky about authentication. It doesn't really change anything for RPs that don't care about authentication though. I am less convinced than you are that universal lock down on authentication is imminent. Github for example recently released a software token with a publicly released authentication private key, suggesting to me they are unlikely to be picky.

> So, if you have at least 3 hardware-based Authenticators on you at all times, is there a problem that needs to be solved?

A good question. It solves the hardware failure problem. It doesn't solve making multiple token registration convenient, or enable recovery scenarios where physical isolation is important. House fires and robberies are the big two that come to mind: there were ~500K structure fires in the US in 2015, and ~325K robberies in the US in 2014. Phone and bank cards are quite likely to be stolen in a robbery. IMO those events are common enough that if you can't have a physically isolated backup you definitely need an accessible account recovery mechanism or an alternate 2nd factor. Those are both inconvenient and introduce many of the same security concerns as software tokens and non-U2F second factor methods.

After I realized my original 2nd method had the authentication problem, I came up with another idea, which I think is currently most promising: a group of hardware tokens that share the same (hardware protected) authentication key, and can register each other. (I provided more details in a response earlier in the thread.) Do you see any issues with this approach?

To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+unsubscribe@fidoalliance.org.

To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/621c1d0f-9173-4d87-be8e-e2e3da98ac75%40fidoalliance.org.

--

You received this message because you are subscribed to a topic in the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this topic, visit https://groups.google.com/a/fidoalliance.org/d/topic/fido-dev/Wbcgjs-8UvY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fido-dev+unsubscribe@fidoalliance.org.

To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/db906fc2-a704-02c4-3e5a-ab56b5231937%40strongauth.com.

[Fred Le Tamanoir]

"I came up with another idea, which I think is currently most promising: a group of hardware tokens that share the same (hardware protected) authentication key, and can register each other. (I provided more details in a response earlier in the thread.) Do you see any issues with this approach?"

Confused?
If this is the same "authentication key" (isolated private key directly or indirectly through a same shared secret for wrapping), you don't need to register "each other" (or I did not understand your point)... and I don't see the real difference with having a backup token (with different key pair(s) but registered with the same services as the original token).

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CABppgTd8XWH-sEOq5gnSYayC4PV%2BmfgBi3Z1md8Cfx6p88-CfQ%40mail.gmail.com.

[Scott Stephens]

I misspoke... I meant the same attestation key, but different authentication keys. Thanks for the catch.

[Arshad Noor]

Scott,

I imagine, if you spent enough time on the mechanics, you might be able to come up with something that might work.  But, once again, is this really a problem?

U2F allows you to connect multiple Authenticators at the same time to the desktop/laptop.  A Registration challenge sent by a FIDO Server will be sent to all visible U2F Authenticators simultaneously; any Authenticator may respond and register a key at that point.  But, if you had - let's say - three Authenticators connected simultaneously, if the RP did a good job with their Registration flow, after the first key is registered, you should be able to register the remaining 2 Authenticators by just clicking the Register button again.  The challenge goes to all 3 Authenticators again - but this time you verify human-presence on one of the 2 unregistered Authenticators.  This Authenticator is now registered.  Click the Register button again and finally, verify human presence on the 3rd Authenticator.

In less than a minute, you've registered all 3 tokens sequentially - without having to deal with any convoluted cryptographic gymnastics.  Is that so hard for an end-user to do that they need to be saved 10-15 seconds per Authenticator?

There are so many other FIDO-related problems that need to be addressed right now:

• Getting consumers educated about FIDO so they ask for it;
  
• Getting consumers educated so they don't just blindly follow this technology without understanding its implications/consequences;
• Verifying Authenticator security to ensure you can trust the Authenticators;
• Getting the millions of web-applications FIDO-enabled and to make FIDO visible to users;
• Getting industry analysts to set an example to their customer-base;
• ....

While I'm not disparaging your desire to make it convenient for people to have backups, Scott, just getting consumers to know and ask for, and use FIDO is priority #1, IMO.  And, getting RPs to FIDO-enable their sites and make FIDO visible on their landing page is #2.  We haven't achieved the "network effect" for FIDO yet, so there's quite a lot of work to do, still, for adoption.

Arshad Noor
StrongAuth, Inc.

On 08/04/2017 08:38 AM, Scott Stephens wrote:

After I realized my original 2nd method had the authentication problem, I came up with another idea, which I think is currently most promising: a group of hardware tokens that share the same (hardware protected) authentication [attestation] key, and can register each other. (I provided more details in a response earlier in the thread.) Do you see any issues with this approach?

[Fred Le Tamanoir]

Arshad speaks the truth again. Amen.