Getting to Know the FIDO Specifications - Technical Tutorial
•Transferir como PPTX, PDF•
5 gostaram•8,875 visualizações
What if we could replace passwords with authentication that is stronger and simpler? Web service providers and enterprises worldwide are looking for a solution to move beyond the frustrating user experience and less-than-stellar security of single-factor password authentication systems. Today FIDO is that solution, providing a rich set of specifications and certifications for an emerging and interoperable ecosystem of hardware, mobile and biometrics-based devices. This ecosystem enables enterprises and web service providers to easily deploy strong authentication solutions that reduce password dependencies and provide a superior, simpler and trusted user experience. - Learn the ins and outs of FIDO’s specifications, including their applicability to both passwordless (UAF) and second factor (U2F) authentication use cases. - Learn how FIDO separates user verification from authentication along with other details on the FIDO registration and login process. - Learn how FIDO authentication protects user privacy and prevents phishing and man-in-the-middle attacks.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (17)
Semelhante a Getting to Know the FIDO Specifications - Technical Tutorial
Semelhante a Getting to Know the FIDO Specifications - Technical Tutorial (20)
Mais de FIDO Alliance
Mais de FIDO Alliance (20)
Último
Último (20)
Getting to Know the FIDO Specifications - Technical Tutorial
- 1. GETTING TO KNOW THE FIDO SPECIFICATIONS Rolf Lindemann, Senior Director Products & Technology, Nok Nok Labs All Rights Reserved | FIDO Alliance | Copyright 2016.
- 2. How Secure is Authentication? 2All Rights Reserved | FIDO Alliance | Copyright 2016.
- 3. Cloud Authentication 3 DeviceSomething Authentication Risk Analytics Internet All Rights Reserved | FIDO Alliance | Copyright 2016.
- 4. Password Issues 4 DeviceSomething Authentication Internet Password could be stolen from the server 1Password might be entered into untrusted App / Web- site (“phishing”) 2 Too many passwords to remember (>re-use / cart Abandonment) 3 Inconvenient to type password on phone 4 All Rights Reserved | FIDO Alliance | Copyright 2016.
- 5. Classifying Threats 5 Remotely attacking central servers steal data for impersonation Remotely attacking lots of user devices steal data for impersonation Remotely attacking lots of user devices misuse them for impersonation Remotely attacking lots of user devices misuse authenticated sessions Physically attacking user devices steal data for impersonation Physically attacking user devices misuse them for impersonation 1 2 3 4 5 6 Physical attacks possible on lost or stolen devices (3% in the US in 2013) Scalable attacks All Rights Reserved | FIDO Alliance | Copyright 2016.
- 6. How does FIDO work? 6 DeviceUser verification FIDO Authentication Authenticator All Rights Reserved | FIDO Alliance | Copyright 2016.
- 7. How does FIDO work? 7 AuthenticatorUser verification FIDO Authentication Require user gesture before private key can be used Challenge (Signed) Response Private key dedicated to one app Public key All Rights Reserved | FIDO Alliance | Copyright 2016.
- 8. How does FIDO work? 8 AuthenticatorUser verification FIDO Authentication … …SE All Rights Reserved | FIDO Alliance | Copyright 2016.
- 9. How does FIDO work? 9 AuthenticatorUser verification FIDO Authentication Same Authenticator as registered before? Same User as enrolled before? Can recognize the user (i.e. user verification), but doesn’t know its identity attributes. All Rights Reserved | FIDO Alliance | Copyright 2016.
- 10. How does FIDO work? 10 AuthenticatorUser verification FIDO Authentication Same Authenticator as registered before? Same User as enrolled before? Can recognize the user (i.e. user verification), but doesn’t know its identity attributes. Identity binding to be done outside FIDO: This this “John Doe with customer ID X”. All Rights Reserved | FIDO Alliance | Copyright 2016.
- 11. How does FIDO work? 11 AuthenticatorUser verification FIDO Authentication … …SE How is the key protected (TPM, SE, TEE, …)? Which user verification method is used? All Rights Reserved | FIDO Alliance | Copyright 2016.
- 12. Attestation & Metadata 12 Authenticator FIDO Registration Signed Attestation Object Metadata Private attestation key Verify using trust anchor included in Metadata Understand Authenticator security characteristic by looking into Metadata from mds.fidoalliance.org (or other sources) All Rights Reserved | FIDO Alliance | Copyright 2016.
- 13. FIDO Authenticator Concept FIDO Authenticator User Verification / Presence Attestation Key Authentication Key(s) Injected at manufacturing, doesn’t change Generated at runtime (on Registration) Optional Components Transaction Confirmation Display
- 14. Trusted Execution Environment (TEE) FIDO Authenticator as Trusted Application (TA) User Verification / Presence Attestation Key Authentication Key(s) Store at Enrollment Compare at Authentication Unlock after comparison Client Side Biometrics
- 15. 15 Passwordless Experience (UAF Standards) Authenticated Online 3 Biometric User Verification* 21 ? Authentication Challenge Authenticated Online 3 Second Factor Challenge Insert Dongle* / Press Button Second Factor Experience (U2F Standards) *There are other types of authenticators 21 All Rights Reserved | FIDO Alliance | Copyright 2016.
- 16. U2F Registration 16 Relying Party AppID, challenge a; challenge, origin, channel id, etc. a generate: key kpub key kpriv handle h kpub, h, attestation cert, signature(a,fc,kpub,h) fc, kpub, h, attestation cert, s cookie store: key kpub handle h s U2F Authenticator check AppID fc FIDO Client / Browser All Rights Reserved | FIDO Alliance | Copyright 2016.
- 17. U2F Authentication 17 U2F Authenticator FIDO Client / Browser Relying Party h, a; challenge, origin, channel id, etc. retrieve: key kpriv from handle h; cntr++ cntr, signature(a,fc,cntr) cntr, fc, s check signature using key kpub s f c handle, AppID, challenge h acheck AppID set cookie retrieve key kpub from handle h All Rights Reserved | FIDO Alliance | Copyright 2016.
- 18. 18 Authenticated Online 3 Biometric User Verification* 2 Passwordless Experience (UAF Standards) 1 ? Authentication Challenge Authenticated Online 3 Second Factor Challenge Insert Dongle* / Press Button Second Factor Experience (U2F Standards) 1 2 *There are other types of authenticators All Rights Reserved | FIDO Alliance | Copyright 2016.
- 19. Registration Overview 19 Perform legacy authentication first, in order to bind authenticator to an electronicidentity, then perform FIDO registration. FIDO CLIENT FIDO AUTHENTICATOR FIDO SERVER Verify user Generate key pair Sign attestation object: • Public key • AAID • Hash(FinalChallenge) • Name of relying party Signed by attestation key Send Registration Request: • Policy • Random Challenge Verify signature Check AAID against policy Store public key Start registration AAID = Authenticator Attestation ID, i.e. model ID FinalChallenge=AppID | FacetID | channelBinding | serveChallenge All Rights Reserved | FIDO Alliance | Copyright 2016.
- 20. Authentication Overview 20 FIDO CLIENT FIDO AUTHENTICATOR FIDO SERVER Verify user Opt: Display TransactionText Sign signData object: Signature alg • Hash(FinalChallenge) • Opt: Hash(TransactionText) • Signature counter Authenticator random Signature (Uauth key) Send Authentication Request: • Policy • Random Challenge • Opt: TransactionText Verify signature Check AAID against policy Start authentication FinalChallenge=AppID | FacetID | channelBinding | serveChallenge All Rights Reserved | FIDO Alliance | Copyright 2016.
- 21. Convenience & Security 21 Security Convenience Password + OTP Password All Rights Reserved | FIDO Alliance | Copyright 2016.
- 22. Convenience & Security 22 Security Convenience Password + OTP Password FIDO In FIDO • Same user verification method for all servers In FIDO: Arbitrary user verification methods are supported (+ they are interoperable) All Rights Reserved | FIDO Alliance | Copyright 2016.
- 23. Convenience & Security 23 Security Convenience Password + OTP Password FIDO In FIDO: Scalable security depending on Authenticator implementation In FIDO: • Only public keys on server • Not phishable All Rights Reserved | FIDO Alliance | Copyright 2016.
- 24. Conclusion • Different authentication use-cases lead to different authentication requirements • FIDO separates user verification from authentication and hence supports all user verification methods • FIDO supports scalable convenience & security • User verification data is known to Authenticator only • FIDO complements federation 24All Rights Reserved | FIDO Alliance | Copyright 2016.
- 25. What about rubber fingers? Protection methods in FIDO 1. Attacker needs access to the Authenticator and swipe rubber finger on it. This makes it a non-scalable attack. 2. Authenticators might implement presentation attack detection methods. Remember: Creating hundreds of millions of rubber fingers + stealing the related authenticators is expensive. Stealing hundreds of millions of passwords from a server has low cost per password.
- 26. But I can’t revoke my finger… • Protection methods in FIDO You don’t need to revoke your finger, you can simply de-register the old (=attacked) authenticator. Then, 1. Get a new authenticator 2. Enroll your finger (or iris, …) to it 3. Register the new authenticator to the service
Notas do Editor
- 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. 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…
- 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.
- 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.
- 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#).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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. Let‘s start with the second factor use-case.
- … called universal second factor, U2F: The user enters username and password (not shown here) and then the application asks the FIDO Server for the AppID and a challenge. Think of the AppID being the „MyCorp.com“ string. The FIDO Client (or Web Browser) verifies whether the app (or web page) belongs to that AppID (i.e. is loaded from mycorp.com). If it is, the FIDO Client or Web Browser determines the origin (e.g. register.mycorp.com) and the channel id from the TLS channel. It creates the final challenge (fc) as the concatenation of AppID, challenge, Origin, Channel ID etc. The Authenticator generates a fresh key pair for the AppID (i.e. mycorp.com) and signs the attestation, i.e. The signature on the concatentation of AppID, fc, public Key and the key Handle). The authenticator returns the attestation,the attestation certificate, the key handle and the public key to the caller. The caller sends it to the FIDO server. The FIDO Server verifies this attestation signature and the attestation certificate and (if verification succeeded) stores the public key along with the user record.
- Once the authenticator is registered, the user logs in with username and password and then the FIDO Server returns the key handle(s) for all authenticator of that user, the AppID (mycorp.com) and a fresh challenge. Again, the FIDO Client/Browser verifies the AppID and determines the origin and channel id from the TLS channel. It passes this information to the authenticator which waits for the user to press a button and then increments the sign counter and signs the challenge. Signature and sign counter are returned to the FIDO Client/Browser and sent to the FIDO Server. The FIDO Server verifies the signature, check that the sign counter on the user record is less than the received one and then sets the session cookie. The user is authenticated.
- Now let‘s look into the passwordless experience.
- There are some differences: The FIDO Server sends a policy of the acceptable authenticators to the FIDO Client (in addition to the challenge). The attestation piece is very similar. The FIDO Server verifies the attestation and whether the policy is satisfied by the authenticator. It finally stores the public key along with the user record.
- In the authentication scnearion there is a substantial difference to U2F: In UAF, the server doesn‘t know the user (since there was no preceding password authentication), so the server can‘t send out a list of all key handles. Instead the server sends a policy of acceptable authenticator and the challenge. The FIDO Client determines the user‘s preferred authenticator matching the policy. The authenticator (typically) verifies the user – in this case it uses either a PIN / pattern or some biometric modality in order to make sure the right user is present (and not only some user). Then the signature is created, sent to the server and verified. There is another difference: UAF support the concept of transaction confirmation. Remember the threat class #4: Misuse of the authenticated session. In the case of transaction confirmation, the FIDO Server sends an image or string of the transaction to be signed, e.g. „transfer $10000 to account 12345“. The authenticator displays the transaction image/text and asks the user for approval. The authenticator verifies the user and if the user approves, it includes the hash of the transaction text in the signature. In this case a potential man-in-the-browser cannot effectively modify the real transaction (e.g. in order to get the money).
- 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.
- 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.
- 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).
- 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.
- 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).