The FIDO U2F protocol enables relying parties to offer a strong cryptographic 2nd factor option for end user security. The relying party's dependence on passwords is reduced. The password can even be simplified to a 4 digit PIN. End users carry a single U2F device which works with any relying party supporting the protocol. The user gets the convenience of a single 'keychain' device and convenient security. This document is an overview of the U2F protocol and is a recommended first-read before reading detailed protocol documents.
What Is This Document?
This document provides an overview of the FIDO Universal 2nd Factor (U2F). It is intended to be read before the reader reads the detailed protocol documents listed below. It is intended to give the reader context for reading the detailed documents. This document is intended as an interpretive aid -- it is not normative.
After reading this overview, it is recommended that the reader go through the detailed protocol documents listed below in the order they are listed. That order starts the reader at the top layer which is the U2F API and progresses down to lower layers such as the transport framing to the U2F device.
FIDO U2F Javascript API
FIDO U2F Raw Message Formats
FIDO U2F USB Framing of APDUs
FIDO U2F Application Isolation through Facet Identification
FIDO U2F Implementation Considerations
FIDO Security Reference
FIDO Glossary
A glossary of terms used in the FIDO specifications is alsoavailable:
These documents may all be found on the FIDO Alliance website at http://fidoalliance.org/specifications/download/
Background
The FIDO Alliance mission is to change the nature of onlinestrong authentication by:
Developing technical specifications defining open, scalable, interoperable mechanisms that supplant reliance on passwords to securely authenticate users of online services.
Operating industry programs to help ensure successful worldwide adoption of the specifications.
Submitting mature technical specifications to recognized standards development organization(s) for formal standardization.
The core ideas driving the FIDO Alliance's efforts are 1) easeof use, 2) privacy and security, and 3) standardization. Theprimary objective is to enable online services and websites,whether on the open Internet or within enterprises, to leveragenative security features of end-user computing devices forstrong user authentication and to reduce the problemsassociated with creating and remembering many onlinecredentials.
There are two key protocols included in the FIDO architecturethat cater to two basic options for user experience whendealing with Internet services. The two protocols share many ofunderpinnings but are tuned to the specific intended use cases.
Universal 2nd Factor (U2F) Protocol
The U2F protocol allows online services to augment the securityof their existing password infrastructure by adding a strongsecond factor to user login. The user logs in with a usernameand password as before. The service can also prompt the user topresent a second factor device at any time it chooses. Thestrong second factor allows the service to simplify itspasswords (e.g. 4--digit PIN) without compromising security.
During registration and authentication, the user presents thesecond factor by simply pressing a button on a USB device ortapping over NFC. The user can use their FIDO U2F device acrossall online services that support the protocol leveragingbuilt-in support in web browsers.
This document that you are reading gives an overview of the U2Fprotocol.
Universal Authentication Framework (UAF) Protocol
The UAF protocol allows online services to offer password-lessand multi-factor security. The user registers their device tothe online service by selecting a local authenticationmechanism such as swiping a finger, looking at the camera,speaking into the mic, entering a PIN, etc. The UAF protocolallows the service to select which mechanisms are presented tothe user.
Once registered, the user simply repeats the localauthentication action whenever they need to authenticate to theservice. The user no longer needs to enter their password whenauthenticating from that device. UAF also allows experiencesthat combine multiple authentication mechanisms such asfingerprint + PIN.
Please refer to the FIDO website for an overview anddocumentation set focused on the UAF protocol.
Goal: Strong Authentication and Privacy for the Web
The U2F eco-system is designed to provide strong authenticationfor users on the web while preserving the user's privacy. Theuser carries a 'U2F device' as a second factor.
When the user registers the U2F device at an account at aparticular origin (such as http://www.company.com) the device createsa new key pair usable only at that origin and gives the originthe public key to associate with the account. When the userauthenticates (i.e., logs in) to the origin, in addition tousername and password, the origin (in this case,http://www.company.com) can check whether the user has the U2F deviceby verifying a signature created by the device.
The user is able to use the same device across multiple sites onthe web -- it thus serves as the user's physical web keychainwith multiple (virtual) keys to various sites provisioned fromone physical device. Using the open U2F standard, any originwill be able to use any browser (or OS) which has U2F supportto talk to any U2F compliant device presented by the user toenable strong authentication.
The U2F device registration and authentication operations areexposed through Javascript APIs built into the browser and, infollowing phases, native APIs in mobile OSes.
The U2F device can be embodied in various form factors, such asstand alone USB devices, stand alone Near Field Communication(NFC) device, stand alone BlueTooth LE devices, built-on-boardthe user's client machine/mobile device as pure software orutilizing secured crypto capabilities. It is stronglypreferable to have hardware backed security, but it is not arequirement. However, as we shall see the protocol provides anattestation mechanism which allows the accepting online serviceor website to identify the class of device and either accept itor not depending on the particular site's policy.
The specs for U2F are in two layers. The upper layer specifiesthe cryptographic core of the protocol. The lower layerspecifies how the user's client will communicate U2Fcryptographic requests to the U2F device over a particulartransport protocol (e.g., USB, NFC, BlueTooth LE, built-in on aparticular OS, etc).
The current spec set from the U2F group specifies the upperlayer (which is unchanged regardless of transport) and thelower layer for the USB transport. Later phases of the protocolspec will specify transports for U2F over NFC, BlueTooth andwhen built-in (i.e, where the U2F capability is built into thedevice and accessed locally via the OS).
As one of the founders of the U2F working group in FIDO, Googleis working to build U2F support into the Chrome browser andwill offer U2F as a 2nd factor option on Google accounts tohelp the start-up of the open ecosystem.
A critical factor for success will be that a U2F device 'justworks' with any modern client device owned by the user withoutneeding additional driver or middleware setup. In this spirit,the USB U2F device is designed to work out of box with existingconsumer operating systems with no driver installs or softwarechanges. A U2F device-aware browser is able to discover andcommunicate with U2F devices using standard built-in OS APIs.To this end, in the first USB based deliverable, we areleveraging the built-in driverless libUSB device support in allmodern OSes.
Site-Specific Public/Private Key Pairs
The U2F device and protocol need to guarantee user privacy andsecurity. At the core of the protocol, the U2F device has acapability (ideally, embodied in a secure element) which mintsan origin-specific public/private key pair. The U2F devicegives the public key and a Key Handle to the origin onlineservice or website during the user registration step.
Later, when the user performs an authentication, the originonline service or website sends the Key Handle back to the U2Fdevice via the browser. The U2F device uses the Key Handle toidentify the user's private key, and creates a signature whichis sent back to the origin to verify the presence of the U2Fdevice. Thus, the Key Handle is simply an identifier of aparticular key on the U2F device.
The key pair created by the U2F device during registration isorigin specific. During registration, the browser sends the U2Fdevice a hash of the origin (combination of protocol, hostnameand port). The U2F device returns a public key and a KeyHandle. Very importantly, the U2F device encodes the requestingorigin into the Key Handle.
Later, when the user attempts to authenticate, the server sendsthe user's Key Handle back to the browser. The browser sendsthis Key Handle and the hash of the origin which is requestingthe authentication. The U2F device ensures that it had issuedthis Key Handle to that particular origin hash beforeperforming any signing operation. If there is a mismatch nosignature is returned.
This origin check ensures that the public keys and Key Handlesissued by a U2F device to a particular online service orwebsite cannot be exercised by a different online service orwebsite (i.e., a site with a different name on a valid SSLcertificate). This is a critical privacy property -- assumingthe browser is working as it should, a site can verify identitystrongly with a user's U2F device only with a key which has beenissued to that particular site by that particular U2F device. Ifthis origin check was not present, a public key and Key Handleissued by a U2F device could be used as a 'supercookie' whichallows multiple colluding sites to strongly verify andcorrelate a particular user's identity.
Alerting the User: U2F Device 'activation' & Browser Infobars
The U2F device device has a physical 'test of user presence'.The user touches a button (or sensor of some kind) to'activate' the U2F device and this feeds into the device'soperation as follows:
Registration: The U2F device responds to a request to generate a key pair only if it has been 'activated'. Separately, the browser implementation might ensure that the javascript 'ask the U2F device to issue a key pair' call always results in the user seeing an infobar dialog which asks if he/she indeed wants to allow the current site to register the U2F device.
-
Authentication: During authentication, the browser sends some data down to the U2F device that it needs to sign (more about this later). The U2F device needs to see a 'test of user presence' before it will sign -- i.e, the user has to press a button on the device for example. This ensures that a signature happens only with the user's permission. It also ensures that that malware cannot exercise the signature when the user is not present.
When the user attempts to authenticate for the first time to a particular origin (i.e. the javascript call for 'Get me a signature from the U2F device' is exercised), the browser may put up an infobar which asks if the user would like to allow the site to talk to the U2F device. In this case, the browser should also present a 'Remember this' option with the infobar so that the browser can remember the permission and not ask every time. This setting can be reset (as with other browser settings).
In summary, the user will have to touch a button to register,and may also be warned by the browser. The relying party canput up screens which will walk the user through these steps.Registration is a very high value operation -- it gives anorigin a capability to very strongly verify a user and it needsto be taken very seriously. During authentication (or moregenerally, whenever the online service or website needs tostrongly verify the user by requesting a signature), the userneeds to activate the device to demonstrate user presencebefore the signature can happen.
Man-In-The-Middle Protections During Authentication
If a man-in-the-middle (MITM) tries to intermediate between theuser and the origin during the authentication process, the U2Fdevice protocol can detect it in most situations.
Say a user has correctly registered a U2F device with an originand later, a MITM on a different origin tries to intermediatethe authentication. In this case, the user's U2F device won'teven respond, since the MITM's (different) origin name will notmatch the Key Handle that the MITM is relaying from the actualorigin. U2F can also be leveraged to detect more sophisticatedMITM situations as we shall see below.
As one of the return values of the U2F 'sign' call, the browserreturns an object which contains information about what thebrowser sees about the origin (we will call this the 'clientdata' object). This 'client data' includes:
- the random challenge sent by the origin,
- The origin host name seen by the browser for the web page making the javascript call, and
- [optionally] if the ChannelID extension to TLS is used, the connection's channelID public key.
The browser sends a hash of this 'client data' to the U2Fdevice. In addition to the hash of the 'client data', asdiscussed earlier, the browser sends the hash of the origin andthe Key Handle as additional inputs to the U2F device.
When the U2F device receives the client data hash, the originhash and the Key Handle it proceeds as follows: If it hadindeed issued that Key Handle for that origin the U2F deviceproceeds to issue a signature across the hashed 'client data'which were sent to it. This signature is returned back asanother return value of the U2F 'sign' call.
The site's web page which made the U2F 'sign' call sends thereturn values -- both the 'client data' the signature back tothe origin site (or equivalently, relying party). On receivingthe 'client data' and the signature, the relying party's firststep, of course, is to verify that the signature matches thedata as verified by the user's origin-specific public key.Assuming this matches, the relying party can examine the'client data' further to see if any MITM is present asfollows:
-
If 'client data' shows that an incorrect origin name was seen by the user
- an MITM is present
- (albeit a sophisticated MITM which had also intermediated the registration and thus got the Key Handle issued by the U2F device to match the MITM's own origin name, and the MITM is now trying to intermediate an authentication. As noted earlier, an MITM intermediating only at authentication time and not at registration would fail since the U2F device would refuse to sign due to origin mismatch with the Key Handle relayed from the original origin by the MITM).
- else if 'client data' shows a ChannelID OR origin used a ChannelID for the SSL connection:
- If ChannelID in 'client data' does not match the ChannelID the origin used, an MITM is present
- (albeit a very sophisticated MITM which possesses an actual valid SSL cert for the origin and is thus indistinguishable from an 'origin name' perspective)
It is still possible to MITM a user's authentication to a siteif the MITM is
- able to get a server cert for the actual origin name issued by a valid CA, and
- ChannelIDs are NOT supported by the browser.
But this is quite a high bar.
An MITM case which the U2F device does NOT protect against is asfollows: Consider an online service or website which acceptsplain password but allows users to self-register and step up toU2F 2nd factor. An MITM with a different origin which is presentbetween the user and the actual site from the time ofregistration can register the U2F device on to itself and notpass this registration to the actual origin, which would stillsee the user as just needing a password. Later, forauthentications, the MITM can accept the U2F device and just doan authentication with password to the actual origin.
Assuming the user does not notice the wrong (different) originin the URL, the user would think they are logging in to theactual origin with strong authentication and are thus verysecure but in reality, they are actually being MITMed.
Allowing for Inexpensive U2F Devices
A key goal of this program is to enable extremely inexpensiveyet secure devices. To enable new secure element chips to be asinexpensive as possible it is important to allow them to haveminimal or no onboard memory.
A U2F device allows for this. The Key Handle issued by the U2Fdevice does not have to be an index to the private key storedon board the U2F device secure element chip. Instead, the KeyHandle can 'store' (i.e., contain) the private key for theorigin and the hash of the origin encrypted with a 'wrapping'key known only to the U2F device secure element. When the KeyHandle goes back to the secure element it 'unwraps' it to'retrieve' the private key and the origin that it wasgenerated for.
As another alternative, the U2F device could store this'wrapped' information in a table in off-chip memory outsidethe secure element (which is presumably cheaper). This memory isstill on board the U2F device. In this case, the Key Handle sentto the origin would be an index into this table in off-chipmemory. As another possibility in the design spectrum, the KeyHandle might only encode the origin and an index number, whilethe private key might still be kept on board -- this would, ofcourse, imply the number of keys is limited by the amount ofmemory.
Verifying That a U2F Device Is 'genuine'
The U2F device protocol is open. However, for effectivesecurity, a U2F device has to be built to certain standards --for example, if the Key Handle contains private keys encryptedwith some manufacturer specific method, this has to becertified as well implemented, ideally by some 'certificationbody' such as FIDO. In addition, the actual cryptographicengine (secure element) should ideally have some strongsecurity properties.
With these considerations in mind, a relying party needs to ableto identify the type of device it is speaking to in a strong wayso that it can check against a database to see if that devicetype has the certification characteristics that particularrelying party cares about. So, for example, a financialservices site may choose to only accept hardware-backed U2Fdevices, while some other site may allow U2F devicesimplemented in software.
Every U2F device device has a shared 'Attestation' key pairwhich is present on it -- this key is shared across a largenumber of U2F device units made by the same vendor (this is toprevent individual identifiability of the U2F device). Everypublic key output by the U2F device during the registrationstep is signed with the attestation private key.
The intention is that the public keys of all the 'Attestation'key pairs used by each vendor will be available in the publicdomain -- this could be implemented by certificates chaining toa root public key or literally as a list. We will work withinFIDO to decide the details on how certified vendors can publishtheir attestation public keys.
When such an infrastructure is available, a particular relyingparty -- say, a bank -- might choose to accept only U2F devicesfrom certain vendors which have the appropriate publishedcertifications. To enforce this policy, it can verify that thepublic key from a U2F device presented by the user is from avendor it trusts.
In practice, for high quality U2F devices we expect that theattestation key would be burnt into the on-board secure element-- the actual key to be burnt in would be provided by thevendor to the secure element manufacturer for every batch ofchips, say about 100,000 units.
Note that the attestation key's presence only guarantees who thevendor is for a well built U2F device -- it is one part of thestory, albeit a very crucial part. As to whether the U2F deviceis indeed secure, that guarantee comes from certifications wherethird parties inspect the implementation by the vendor. Insummary, attestation is a strong identifier of thecertifications.
In this context, it's worth noting that a U2F device whichstores keys on board rather than exporting them in the KeyHandle are, in principle, most secure, since it is notvulnerable to any potential vendor specific vulnerabilities inthe design of the encryption of the data in the Key Handle.However, a good design with an encrypted Key Handle will bewell above the bar in security while also being cheaper.
At this time, the encryption used to embed private keys in theKey Handle are technically not part of the specified protocol.However, strong best practice guidelines are specified in thesample client side javacard applet available in U2F workinggroup materials. It may be appropriate to include a review ofparticular implementations as part of a U2F certificationwithin FIDO.
Note that it is still possible for a vendor to build a U2Fcompliant device which is not certified and whose attestationkeys are not published in a 'certification database'. A relyingparty could still choose to accept such devices -- but it will doso with the full knowledge that that particular device type isnot in the certification database.
Counters as a Signal for Detecting Cloned U2F Devices
The vendor attestation is one method by which an origin can assess a U2F device. In practice, we do not want to prevent other protocol compliant vendors, perhaps even those without any formal secure element, perhaps even completely software implementations. The problem with these non-secure-element based devices, of course, is that they could potentially be compromised and cloned.
The U2F device protocol incorporates a usage counter to allow the origin to detect problems in some circ*mstances. The U2F device remembers a count of the number of signature operations it has performed -- either per key pair (if it has sufficient memory) or globally (if it has a memory constraint, this leaks some privacy across keys) or even something in between (e.g., buckets of keys sharing a counter, with a bit less privacy leakage). The U2F device sends the actual counter value back to the browser which relays it to the origin after every signing operation. The U2F device also concatenates the counter value on to the hash of the client data before signing so that the origin can strongly verify that the counter value was not tampered with (by the browser).
The server can compare the counter value that the U2F device sent it and compare it against the counter value it saw in earlier interactions with the same U2F device. If the counter value has moved backward, it signals that there is more than one U2F device with the same key pair for the origin (i.e., a clone of the U2F device has been created at some point).
The counter is a strong signal of cloning but cannot detect cloning in every case -- for example, if the clone is only one which is used after the cloning operation and the original is never used, this case cannot be detected.
Client Malware Interactions with U2F Devices
As long as U2F devices can be accessed directly from user spaceon the client OS, it is possible for malware to create akeypair using a fake origin and exercise the U2F device. TheU2F device will not be able to distinguish 'good' clientsoftware from 'bad' client software. On a similar note, it ispossible for malware to relay requests from Client machine #1to a U2F device attached to client machine #2 if the malware isrunning on both machines. This is conceptually no different froma shared communication channel between the Client machine (inthis case #1) and the U2F device (which happens to be onmachine #2). It is not in scope to protect against thissituation.
Protection against malware becomes more possible if the U2Fclient is built into the OS system layer as opposed to runningin user space. The OS can obtain exclusive access to U2Fdevices and enforce methods to ensure origin matches.
U2F Device User Experience
As described earlier access to the U2F device is manifested intwo javascript functions available in the browser -- one forcreating a key pair and one for generating a signature. Theseare used by an origin online service or website to create auser flow.
Registration: Creating a Key Pair
The to-be-registered user is verified by the origin site (with username and password or whatever other means). The registration page rendered by the origin in the browser calls the javascript function for creating a key pair. When the javascript function is called, the user may see a browser infobar warning which he/she has to approve. After user approval, the key pair generation request is sent to every U2F device attached to the computer.
The first U2F device attached to the computer which has a positive 'test of user presence' (i.e., the first attached U2F device on which the user presses the button) responds to this request. The browser packages the response from the U2F device (key handle, public key etc) and returns it to the web page as return results of the javascript function call. The registration web page sends these to the origin site and the origin sites stores this information indexed by the user's account to complete the registration process.
Authentication: Generating a Signature
The user starts the authenticaion process typically with username and password (or with just the username, if the site only wants a U2F device verification). The origin site renders an intermediate authentication page into which it sends the user's Key Handle and a nonce. It then calls the javascript function to create a signature. The parameters for the function call are the Key Handle and the nonce.
When the signature function is called, the browser may show an infobar asking for the user's approval (the user may choose to ask the browser to skip this in future). After the user's approval, the browser talks to all the U2F devices attached to the computer as described earlier and assembles their responses.
The javascript function call returns the 'client data' object and the first signature response from a U2F device that replied. The intermediate authentication web page sends the 'client data' and the U2F device responses on to the relying party, which determines if any of the signatures matches what it expects.
Note that depending on the U2F implementation multiple devices could reply for a particular Key Handle. For example, consider the case where the Key Handle is implemented purely as an index into memory on board the U2F device (and thus was just, say, a small integer). The user may have registered multiple U2F devices to a particular account on a particular origin and some of those devices could have used the same index integer as Key Handle for that particular account on that particular origin.
Note that though the user does not necessarily have to see the intermediate page described above. If the correct U2F device is present, then the signatures can be obtained and sent back to the origin and the authentication is completed. The user needs to see intermediate screens only for error conditions ('Please insert your U2F device', 'We require you to activate your U2F device' etc).
U2F Device Usage Scenarios
Though the description so far has been in context of aparticular user using a single device across multiple accounts,the usage scenarios enabled are broader.
Sharing a U2F Device Among Multiple Users
Note that a U2F device has no concept of a user -- it only knows about issuing keys to origins. So a person and their spouse could share a U2F device and use it for their individual accounts on the same origin. Indeed, as far as the U2F device is concerned the case of two users having accounts on the same origin is indistinguishable from the case of the same user having two accounts on that origin.
Needless to say, the general case where multiple persons share a single U2F device and each person has accounts on whatever origins they choose is similarly supported in U2F.
Registering Multiple U2F Devices to the Same Account
U2F does not limit the user to have a single device registered on a particular account on a particular site. So for example, a user might have a U2F device mounted permanently on two different computers, where each U2F device is registered to the same account on a particular origin -- thus allowing both computers to login securely to that particular origin.
If a user has registered multiple U2F devices to a particular account, then during authentication all the Key Handles are sent by the origin to the intermediate page. The intermediate page call the signature javascript function with the array of Key Handles and sends the aggregated response back to the origin. Each attached activated U2F device signs for those Key Handles in the array that it recognizes. The user authentication experience is unchanged.
As an optimization, note that when a origin detects a particular Key Handle is used successfully to authenticate from a particular browser, it can remember that Key Handle for future reference by setting a cookie on that browser and trying that Key Handle first before attempting other Key Handles.
U2F Privacy Considerations: A Recap
As the reader would have noticed, user privacy is a fundamentaldesign consideration for the U2F protocol. The various privacyrelated design points are reiterated here:
- A U2F device does not have a global identifier visible acrossonline services or websites.
- A U2F device does not have a global identifier within aparticular online service or website
- Example 1: If a person loses their U2F device, the finder cannot'point it at a website' to see if some accounts get listed.The device simply does not know.
- Example 2: If person A and B share a U2F device and they haveeach registered their accounts on site X with this device,there isn't any way for the site X to guess that the twoaccounts share a device based on the U2F protocol alone.
- Since a key is essentially a strong identifier this means U2F does not give any signal which allows online services or websites to strongly cross-identify shared users.
- An infobar could appear whenever the 'issue a key' javascript call is made.
- An infobar (with a once-only option) could appear when the 'sign with this key' javascript call is made for a particular origin
The infobar approach puts a decision burden on the users - thisis a downside and the infobar UX design has to be done withcare.
Other Privacy Related Issues
An Origin Can Discover that Two Accounts Share a U2F Device
The origin specific key issuance still leaves one possible privacy leak -- which is the case where a person with a single U2F device uses it to generate keys to two separate accounts with the same origin. Say the two different accounts are associated with usernames u_1 and u_2 in the site's name space. Now when u_1 is attempting to authenticate, the origin can send down KeyHandle_2 to the U2F device. If it returns a valid signature, it can infer that u_1 and u_2 belong to the same person or two persons who share the same computer who happen to have their U2F devices plugged in simultaneously. This is true even if the users have taken precautions to hide their client identity from the origin server (using an anonymizing proxy, incognito mode etc).
It is possible to enhance the U2F device specification to catch this case but it complicates the user experience and we chose not to do so. Users who are concerned about this line of attack would need to use different U2F devices for different accounts on the same site and plug in only the relevant U2F device and no other when initiating a session for a particular account.
Revoking a Key From an Origin
Say a user registers their U2F device on an online service or website which has unsavory practices without the user realizing that the online service or website is unsavory. Later the user wants to cut off association with that site. It should ideally be possible for the user to 'delink' the key such that the U2F device starts behaving as if it no longer owns the key. Thus the site cannot strongly verify the user even if it can do social engineering to make the user click past warnings.
It is possible for a vendor to design a U2F device which can be 'reset' -- in that it stops honoring any key it has issued before the reset. This might mean the earlier Key Handles need to have a generation count and a reset makes the U2F device reject all keys older than the current generation count. Alternatively, if the U2F device uses a key wrapping mechanism, a 'reset' could throw away the old wrapping key and replace it. This renders all earlier keys issued by the device useless, since the device can no longer make any sense of them.
However, if the secure element is stateless and has no hard reset ability, all this 'revocation' logic has to be implemented as blacklists in firmware outside the secure element (for eg, code on the USB intermediator). In such a case it is possible for a dedicated attacker (e.g., a spy service) to extract the secure element and verify if it indeed does work against keys it has issued in the past. One revocation safeguard available to the user is physical destruction of the U2F device -- this could be useful in sensitive high value situations (e.g., a political dissident).
Non-USB Transports
As discussed earlier, USB based devices will be followedimmediately by other transports which are becoming availablewidely for local communication -- in specific, NFC and BluetoothLE and built-in U2F devices. The implementation drafts of these specifications are available now in this release.
Expanding U2F to Non-browser Apps
The discussion above has been focused on the browser as theclient side vehicle, with a Javascript API to talk to U2Fdevices. However, it is perfectly sensible to have app on amobile OS such as Android talk to U2F devices over a systemAPI.
When building a native system API, we still need a notion of'origin'. For example, if foo.com's app mints a key on aparticular U2F device, then bar.com's app should not be able toexercise that key. Even more importantly, if the user uses thefoo.com web app on a computer and foo.com's app on a mobiledevice, the user needs to be able to use the same U2F devicewith both. This means that there has to be mechanism where theorigin sent down to the U2F device by the browser for thefoo.com web page matches the origin sent down to the U2F deviceby the mobile OS for the foo.com app.
This is achieved by specifying a level of indirection using thenotion of an 'application id', which is a generalization of theorigin concept. The 'application id' is a publicly fetchablehttps URL where a particular origin (such as foo.com) lists itsvarious 'facets' -- for example, it may list the hostname'www.foo.com' and the identifier for the signatures offoo.com's android app. The application id https URL is assumedto be under the control of the origin -- in other words, only itcan change the list of 'facets'.
The origin website or online service sends its 'application id'down as a parameter to the U2F API on the web page. The browserfetches the content of the 'application id' URL and ensures thatthe actual origin it sees for the web page calling the U2F APIis indeed listed in the 'facets' in the 'application id' URL.For example, if a page served off www.foo.com makes a U2F APIcall, then this host name needs to be listed as a facet in the'application id which is passed down. Similarly when aparticular mobile app passes a 'application id' to a U2F API ona mobile OS, the OS checks if the code signing signature of thatparticular app is listed as a facet in the 'application id'.After these check if the 'facet' is indeed in the 'applicationid' as expected, the hash of the 'application id' is sent downto the U2F device, rather than the hash of the 'origin'. Thisensures that foo.com's web page and foo.com's mobile app bothare seen as the same site by the U2F device. As mentionedearlier, the 'application id' is a generalized notion of anorigin.
