Yuri Akkermann: “One of the fundamental principles of the FIDO Alliance is ensuring privacy”
Interview with senior certification engineer FIDO Alliance about passwordless authentication
Our users asked us to implement two-factor authentication through the Google app. And recently we have provided this opportunity . At about the same time, the FIDO Alliance consortium published standards for passwordless authentication on websites, in mobile applications and web services - WebAuthn and CTAP.
We are interested in this topic and prepared a material on Habré in which we talked about the methods underlying the new protocols.
Then, in order to clarify some points concerning the subtleties of the work of the standard, we spoke with Yuri Akkermann ( herrjemand), FIDO Alliance senior certification engineer. He answered some of our questions about the past, present, and future of FIDO authentication. We present to your attention the text of the interview.
/ Flickr / zhrefch / PD
Please tell us about your background and experience in the IT-sphere as a whole. How did you start your work in the industry?
I have been programming since I was fifteen. After school I entered the university where I studied computer science and mathematics. In the second year I became interested in cryptography, information security issues and “stumbled” on FIDO. I really liked their protocols, and in the end I wrote the U2F library for Python Flask and made a presentation.
My work was rated in FIDO. At the same time they were just looking for a certification engineer. In the end, I became responsible for technical certification.
How long have you been involved in topics related to authentication within FIDO? What tasks did you solve in the process of developing a new standard?
I have been working with FIDO protocols for three years now - two of them in the FIDO Alliance. My main role is technical certification and automatic tools for testing implementation for compliance with specifications. My responsibilities include developing and maintaining the tools themselves, as well as writing test plans - test lists for checking servers, clients and authenticators. I think that writing a test plan is the most time-consuming process, since it requires an understanding of all the intricacies of the protocols and the standards used in them.
I also advise working groups on possible improvements to specifications, make presentations and write articles from time to time.
How was the idea of creating a new standard for authentication born? Why did you decide that the world and the community need a new solution in this area? What are the disadvantages of existing formats is intended to close WebAuthn?
FIDO Alliance founded Agnitio, Infineon Technologies, Lenovo, Nok Nok Labs, PayPal and Validity in 2013, which developed the UAF. A little later, they were joined by Google, Yubico and NXP - these were working on the predecessor of U2F and thought it would be beneficial to combine forces, since their ideas coincided with the ideas of the Alliance. They sought to protect Internet users from phishing, to solve the problems of ease of use of passwords, as well as to develop the availability and security of biometric technologies.
Have any preliminary studies been carried out that either reinforced the intention to create a standard, or pushed for its creation? If so, what kind of data did you analyze?
Members of the alliance, such as Google, Microsoft, Samsung, Yubico and others, are actively working to create and promote standards. They explore markets, trying to understand how FIDO can fit into different ecosystems. At Google, for example, they conducted a study on the migration of the second factor from one-time passwords to U2F.
How was CTAP born? How is it related to WebAuthn?
FIDO consists of three parts: the server, the client (browser) and the authenticator. The server sends the call to the client, the client transfers the call to the authenticator, who signs it and returns it to the client, and that call is already sent to the server.
In order for the server to use FIDO authentication, the clients have WebAuthn JS API. The client communicates with authenticators using the low-level protocol CTAP2 (Client-to-Authenticator Protocol 2). CTAP2 describes CBOR request structures and transports, such as USB, NFC, and BLE, to communicate with the authenticator. The combination of these two standards is called FIDO2.
One of the goals of creating a format is to protect against phishing. What advantages should be distinguished in comparison with other solutions?
If we talk about existing solutions, then the only thing with which FIDO can be compared is client certificates or TLS CCA (Client Certificate Authentication). FIDO and CCA are phishing-secure call-response protocols on public keys. But they have significant differences.
CCAs are not protected against replay attacks. They reuse one certificate on multiple sites, which can lead to de-anonymization of the user. In FIDO, we generate a new, unique key pair for each registration to keep it private.
CCA also has a problem with storing keys, since in most cases the private key is either encrypted in PKCS12 or simply lies in cleartext. Thus, even an unprivileged application can steal it without problems. In FIDO, all keys are stored securely, for example, in one-way SecureEnclave storage. Recovering keys from repositories of this type is very difficult.
The CCA has difficulties with proper implementation on the server side, since the full support of the CCA leaves much to be desired. And because of the complexity of working with TLS, developers make many mistakes. FIDO only needs support for the most basic cryptography. CCA can be implemented via HTTP, which cannot be done in WebAuthn. CCA also has portability and ease of use issues.
I do not think that the Alliance has invented something new. We just developed a good protocol that includes existing security mechanisms.
/ Flickr / Markus Spiske / PD
Will the use of the standard not reveal additional attack vectors associated with the need to store a large amount of biometric information?
One of our fundamental principles is privacy. Biometric information is stored on secure chips and never leaves them. Our companies work with FIDO or FIPS certified readers.
We also do not use biometric information for anything except to confirm the presence of the user. And we have a biometric certification program for testing authenticators.
You once said that SMS code authentication is a bad option to 2FA. How can you comment on this?
SMS codes or SMS OTP is two-factor authentication on one-time passwords delivered via SMS. Therefore, it turns out that this solution is vulnerable to phishing. If your user has fallen for phishing and has given his username and password, what will stop him from sending an SMS code to attackers?
We should not forget about the problems of using SMS as a transport. Three years ago, 400 thousand accounts were hacked in a German bank because of a vulnerability in the SS7 protocol, which is used to route telecommunication information between different telecom operators. The attackers, who received unauthorized access to the SS7 network, which does not have any authentication, were able to register the victims' numbers on themselves and get their codes.
Also today, everyone can buy a GSM base station for $ 500–600 and intercept SMS with it using an MITM attack. And finally, there are dangers associated with social engineering. I think many are familiar with the story , when the attackers stole a substantial amount of money from bank accounts, issuing the issuance of a duplicate of the victim's SIM card. This happens in Russia and other countries with enviable regularity.
What if you need to enter the service on several devices or several people use the same service at once? Does the standard support this mode of operation?
Unlike a password, authenticators can be many. The user can register his phone, laptop, token and use any of them for authentication. Also, a single token can be “tied” to several accounts without losing privacy.
What to do if the token was lost? Will it be possible to return access to services?
Authentication FIDO should be thought of as keys to the house. If you have lost your keys, you can always pick up your spares from your wife, children, mother, grandmother, or, in the worst case, get them from under the door mat. Therefore, we recommend that you always have a spare identifier and store it, for example, in a safe.
If we talk about restoring access to services, this is a really difficult problem. Recovery is not part of the standard, because different resources restore access to accounts in different ways. Classic approaches are one-time codes that are not protected against phishing. Facebook allows you to restore access through friends.
The most promising solution today is Delegated Recovery- this is a recovery protocol based on the storage of encrypted secrets in other services. It, by the way, was written by one of the creators of U2F Bratt Hill (Bratt Hill). Recovery is a rather difficult and interesting problem, the solution of which we still have to find.
The private key in the authenticator must be copy-protected. In what form and where are the identifiers stored? How are they exchanged?
At each registration, the authenticator generates a new unique key pair and assigns it a random identifier, which is called a credential ID or credID. Private keys are stored in a secure storage, such as SecureEnclave, TPM or TEE.
The private key never leaves the authenticator, as this is not required. If the user wants to add another authenticator, then he simply registers it, generating a new key pair and identifier, and sends the public key with the identifier to the site. During authentication, the site transmits the identifier to the authenticator, and with its help it finds a pair of keys and signs the call.
How will the new standard relate to the requirements of data protection laws (for example, GDPR)?
Our principles are in very good agreement with the GDPR. Even in two-factor mode, we make authentication phishing-safe. If we talk about password-free authentication, then there are no passwords transmitted at all. Additionally, unlike client certificates, our protocol cannot be used as a super-cookie. Therefore, many companies are already working on the implementation of our protocols.
And who is already implementing the standard?
Google, Facebook, Dropbox, Salesforce, Bank of America, NTT Docomo ... We have hundreds of companies and half a billion daily users. We are growing every day. But still, the transition to full password-free authentication will take some time.
How quickly does a standard allow a transition from another authentication method?
The transition from existing two-factor authentication solutions (for example, from OTP) to FIDO is quite simple. You just need to connect the library and implement a couple of changes on the client side. In FIDO2, the option for passwordless authentication is just an additional flag during registration. Translating the entire ecosystem to full passwordless authentication will take some time. We predict that in 10 years, this transition will make 80% of all services.
What are your plans for FIDO to develop the standard? What improvements are planned in the near future? And in the long run?
So far, we have focused on promoting standards. There are millions of sites in the world - it means that we have a million cases. In the long term, we plan to work on the implementation of standards in the field of Internet of things, in order to increase the security of IoT gadgets. Also in the plans are work on state authentication systems, eID, passports and decentralized identification systems.
How do you plan to continue working on WebAuthn? How can IT community members help you?
I, as before, continue my work as an ambassador in the developer community: I publish articles, work on the open source, make presentations, conduct trainings. As for the help of the community, I can only say: “We need more gold from the open source.”
PS Yuri Akkermann also prepared an article on Habré, in which he described the basic security mechanisms of FIDO2 and considered the JS API for working with it.