FIDO Specifications Overview

Editor's Notes

• #3: We have seen several attacks on existing authentication methods in the past: Server side attack were used to steal 1.2bn passwords from various servers. 2. Phishing attacks were launched to make users reveal their passwords to the attackers. 3. Orchestrated malware attacks were launched on PCs and smartphone in order to steal money. See EuroGrabber or the MITM attack on CITI bank in 2006 (http://www.banktech.com/phishers-beat-citiandrsquos-two-factor-authentication-/d/d-id/1290948) So existing authentication schemes seem to be broken at this time. In order to understand how we can improve authentication, let’s have a closer look into it…
• #4: How does authentication work today? Since we are not born with WIFI interfaces in our heads, we cannot directly authenticate ourselves to a cloud server. We need some kind of proxy device. For example, we type our password into a computer running some application. If we believe this is the right application, we are willing to enter our password into it. The server takes some explicit authentication signal like the password as input and adds additional back-end computed signals, e.g. geolocation derived from the IP address, packet round-trip times etc. The risk engine computes a resulting risk score using all input signals. Note that the strength of a password signal depends on the characteristics of the “proxy-device” or App. If the password is entered into a malicious application, then a Phisher or man-in-the-middle might now be able to mis-use it.
• #5: The predominant Authentication method today is username+password. But it has several issues. Passwords are symmetric bearer tokens. This means that anyone who knows the password can send it to the cloud server and gets authenticated. It also means that the server needs to know either the password directly or something which is derived from the password (e.g. the hash). And even if you cannot directly reverse this hash function, you can hash millions of passwords until the hash is identical to the one found on the server. Rainbow tables are an efficient method to do that. Note that the most passwords are not as strong as they could be. By knowing the 1000 most popular passwords you could break 90% of the accounts. By knowing the 10000 most popular passwords you could break 98,5% of the accounts. But passwords might also be entered into the wrong application. This phishing application could then send the password to the attacker and let the attacker misuse it or it could itself misuse it for performing malicious transactions. For security reasons, passwords shouldn‘t be re-used on other web sites. But how could I remember different passwords for all my accounts. I counted my accounts a while ago and ended up with well above 500. There is no way for me to remember them all. And passwords are inconvenient to type on mobile phones using the touch keyboards.
• #6: These are the attack classes we see being most important for authentication: Remotely attacking servers and stealing passwords. Remember the 1.1 billion stolen passwords. This attack is really bad as users cannot protect against it – the relying parties would have to do it. But users can make it even worse: if they share passwords across multiple relying parties, the least secure relying party could be hacked affecting all others. Once threat class 1 wouldn’t work any longer, the attackers would focus on other attacks. For example trying to steal data from the device in order to impersonate the user. Or Misuse data on the user device in order to impersonate the user. Or Remotely attacking lots of user devices (e.g. using stagefreight attack, see http://www.techworm.net/2015/07/stagefright-attack-it-takes-only-a-single-text-message-to-hack-an-android-smartphone.html) in order to misuse strongly authenticated session. This is known as the man-in-the-browser (MITB) attack. It is interesting to see that smartcards alone do not protect against the misuse of credentials as the smartcard cannot know whether a PIN was entered by the user or injected by some malware which phished the PIN from the user before. All these attacks are “scalable”, that means whether 1000 or 1m targets are attacked doesn’t have an impact on the attack costs. Once we have protected against such scalable attacks, we should focus on protection against the physical attacks, i.e. attacks where physical access to the device is required. Physical attacks are not scalable as stealing (active) smartphones has significant costs per target. In the US, there are 156m people owning smartphones in 2013 (see http://www.comscore.com/Insights/Press-Releases/2014/2/comScore-Reports-December-2013-US-Smartphone-Subscriber-Market-Share). Thereof 3.1m smartphones (2%) have been stolen in 2013 and another 1.4m smartphones (0.9%) were lost in 2013 (see http://www.consumerreports.org/cro/news/2014/04/smart-phone-thefts-rose-to-3-1-million-last-year/index.htm#).
• #7: In FIDO we acknowledge the fact that we need a local or “proxy”-device in order to authenticate to a cloud server. We call this proxy device “Authenticator”. We call the “something” (see before) user verification and we have a standardize authentication protocol between the client side and the server. So we split the authentication into user verification and a standardized authenticator to server protocol.
• #8: We use private keys generated and maintained by the authenticator to sign server generated challenges. The server uses the public key from the registered authenticator to verify the signature. Each private key is dedicated to a single relying party. So we only store public keys on the server-no user private keys. So hacking the server is less attractive to hackers.
• #9: With this concept of the Authenticator, we get two dimensions of scalability. Scalability in terms of Authenticator implementation. We can leverage TPMs, embedded Secure Elements, SIM Cards and Trusted Execution Environments (TEE in short) to implement the Authenticator. And Scalability in terms of user verification methods. The Authenticator can support passcodes to verify the user or face recognition, or speaker recognition, Iris, fingerprint and even method not invented yet. We also can combine various user verification methods, e.g. fingerprint with an alternative PIN. And this is done in most existing implementations. The FIDO Server will automatically support such Authenticators if they support the standardized FIDO UAF authentication protocol. It depends on the relying party (i.e. online service provider) to decide whether to accept or reject any specific authenticator. So for supporting a newly invented user verification method, the user only needs the appropriate authenticator. Technical changes on the server side are not required.
• #10: The Authenticator verifies whether it is being used by the same user as enrolled initially. And the Authenticator proofs to the server whether it is the same Authenticator as registered before. The Authenticator doesn’t know whether the user is John Doe or Donald Duck. It just verifies whether it is still the user who enrolled.
• #11: Since the RP wants to know WHO the user is that uses the Authenticator, we need an identity binding step. This step is not standardized in FIDO. Each RP can continue following its established know your customer (KYC) procedure. So in FIDO we separated the Authentication aspect from the Identity aspect. Authentication is a global problem which needs a global solution. Identity is inherently regional as different countries have different regulations on privacy and identity verification procedures for different verticals. For example, the know-you-customer-rules for European banks are different than the ones for Nigerian banks. And people Europe have different privacy expectations than Nigerian people. FIDO provides a global solution for Authentication that can be combined with any method of Identity binding that is acceptable in each region.
• #12: FIDO provides great flexibility for Authenticator implementation. The specific implementation determines the resulting security level of the Authentication. So the FIDO Server needs to know such implementation details: The FIDO Server needs to know whether the Authenticator is implemented in a trusted execution environment or in normal software running in the rich operating system. It typically wants to know whether the user was verified using a 4 character passcode or using fingerprint verification. In FIDO we call this method Attestation.
• #13: The Authenticator provides a cryptographic proof to the FIDO Server on its model. The FIDO Server can lookup the security characteristics of an Authenticator in the Metadata. For example, the FIDO can lookup whether the Authenticator protects the key material in a Trusted Execution Environment or in a Secure Element or whether the user was verified using a fingerprint or a passcode. The Metadata also includes the trust anchor required to verify the attestation object, i.e. the cryptographic proof of the Authenticator model. Some more details regarding Attestation: Whenever two Authenticators have different security characteristics, the must use different AAIDs. Remember the AAID contains the vendor ID and a vendor specific product ID. This is similar the USB IDs. So if one Authenticator uses HW based cryptography and a FP based user verification method, it must have a different AAID than an authenticator using pure SW based implementation and face recognition based user verification. It is important that attestation CANNOT be used for identifying any specifiy authenticator instance. So when bob registers his authenticator to two different relying parties they cannot see from the FIDO protocol whether this is the same authenticator or just the same model of an authenticator.
• #14: In FIDO, the Authenticator is a concept. The Authenticator owns the Authentication keys and typically owns one attestation key injected at manufacturing time. The Authenticator can optionally support a user presence check (e.g. button) or a user verification method. Additionally the Authenticator can implement a Transaction Confirmation Display. There are various ways to implement an authenticator. Typical Authenticators are (a) embedded into a smartphone or (b) separate hardware tokens
• #18: The principles we just explained apply to all FIDO protocol families. In FIDO we support two major set of use-cases: Using the Authenticator for „passwordless experience“ and Using the Authenticator as a second factor. Let‘s look into how these use-cases are addressed in FIDO. We start with the generic cryptographic scheme
• #21: Some terminology changes
• #23: Traditionally there always was a tradeoff between convenience and security. If you could get it either more secure or more convenient – but not both at the same time. Passwords are not very secure and their convenience is – let‘s say – improvable. Requiring one-time-passwords in addition to the password doesn‘t make it more convenient. So we can increase the security slightly if we give-up even more convenience.
• #24: FIDO fundamentally changes this model. Since the user verification method (e.g. the finger swipe, or the PIN in case of PIN based authenticators) is the SAME for all relying parties it is more convenient just by using FIDO (worst case: only a single PIN to remember instead of hundred passwords). Additionally FIDO supports scalability in terms of convenience depending on the user verification method implemented by the authenticator. Just touching a fingerprint sensor is much more convenient than typing anything on touch keyboards.
• #25: Similarly for the security. Just by using FIDO, you get protection against the server-side password stealing attacks (remember only public keys are stored on the server). Additionally phishing attacks don‘t work as there are no bearer tokens known by the user anymore. So the user cannot enter something into a phishing site which would allow impersonation (remember: only the legitimate authenticator knows the private key related to the public key which was registered at the server. So knowing a PIN wouldn‘t be sufficient for the attacker. Access to the authenticator would be required in addition).
• #27: Once a new smartphone with a fingerprint sensor is launched, the Chaos-Computer-Club (CCC) typically publishes a „rubber-finger“ attack for that. But remember: while it might be possible to fool fingerprint sensors, the attacker still needs physical access to the authenticator in the FIDO case (as the private key is known to the authenticator only). Additionally: Creating rubber fingers costs time and money per authenticator. You might be able to steal 140 million passwords from a server, but creating 140 million rubber fingers is more expensive and hence not scalable.
• #28: Some people are concerned about an attacker getting access to their biometric data (e.g. lifting a fingerprint from a glass or even from a high resolution digital image). Passwords can be revoked, but fingers can‘t be. Good news: In FIDO you don‘t need to revoke a finger. You can unregister the authenticator once an attacker has physical access to it (and the related biometric data to unlock the FIDO key).