 Hello, welcome to my talk. I'm Shanshan from TU Darmstadt. This is the work about FIDLE2 analysis. It's a joint work with Manuel Barbosa from University of Porto, Sasha Bodderiver from Georgia Tech, and Bogdan Vorensky from University of Bristol. Most of the work that I did was during my PD studies at Georgia Tech, working with Sasha. Let's first look at the motivation. Say you'd like to log into a bank account and check your balance. Let's see in practice how the security is guaranteed. Typically, authentication and channel security are guaranteed by some secure channel protocol like TLS with PKI, a public key infrastructure. With PKI, we can assume the bank has a security signing key and the client has a corresponding public verification key. Then the client can use this key to authenticate the server, and TLS just does this key exchange and build a secure channel. Then to authenticate the user, the user types in its password to the computer or client, which will send the password through the TLS channel to the bank, and the bank will check whether the password is correct or not according to its record. Sometimes we may require the user to have a second-factor device for stronger security. It could be a smartphone or could be some secure token that shows a one-time password. Passwords are very easy to use, but it's well known that it has a lot of issues. For example, according to a Verizon report, more than 80% of data breaches are because of password issues. So it's good to get rid of this. To establish passwordless authentication standards, the FIDO Alliance was launched in 2013. FIDO is really a global effort. It involves more than 200 leading companies all over the world. Their proposed protocols have been identified as standards and deployed on important platforms. The usability is also good. For a typical user FIDO protocols, we only need the user to press a button. The FIDO Alliance currently has three different kind of protocols for authentication. The first one is called U2F. It deals with second-factor authentication. The second one, UEF protocol. It does not require a typical password, but still needs the user to provide some biometric feature like his fingerprint. So this essentially is just a strong password. And finally, they have this new FIDO 2 protocol that does not involve password in any form, but use the public key credentials to do the authentication. And our work focuses on this new FIDO 2 protocol to see how it works. For a typical user FIDO 2 protocol, we need to consider four different parties. We have the human user who wants to login to the server through a client, which may be a brother, and the user owns an authenticator device, which is also called a token. We can assume the human interactions with the token's client to be secure, because this just involves physical interactions like pressing a button or browsing the internet. FIDO 2 has two components. The first one is called WebOson. It's a web API to handle public key credentials for the authentication. So with this protocol, the authenticator or the token can generate a secret signing key and register the corresponding public verification to the server. The token is authenticated with a challenge response protocol. So the server generates a random challenge and sends that to the token through the client. Then the token sends a challenge with a secret signing key and responds to the server with a signature. And the server can use the public key to verify the signature and accept this authentication if it's valid. In order to get strong authentication security, FIDO 2 also has another component called CTAP2. It's a client-to-authenticator protocol that controls client access to the token, such that only the user-authorized client can have access to it. We'll explain this later, but intuitively with this CTAP2 protocol, even if the user's token is stolen, the attacker still cannot impersonate the user because it still requires some access to the token. Now we have a basic idea of the FIDO 2 protocol. Actually, in its specification, it lists many security goals, like user authentication and incapability in our service resistance and so on. But they are all informal, so without formal proof of security analysis, we are not sure what security goals can be achieved. There exists some prior work on the FIDO protocol analysis, but they are either informal or only conducted in the symbolic model. We know that security in a symbolic model is proved on a machine by some automatic tools, and it's much weaker than the security model that we consider in cryptography. And you also notice that the CTAP2 component of FIDO 2 has no security analysis at all. So it's clear that a comprehensive cryptanalysis of FIDO 2 is highly necessary, and our work will focus on the authentication properties that we think are the most important ones. Now, before going into the details of our analysis, let's see a little bit about our strategy. We analyzed the FIDO 2 protocol in a modular way. So we first analyzed these components and then got the final overall security of FIDO 2 from a competition result. And we also discussed what security can be achieved if we have a server-to-client authenticated channel, like a TLS channel. Now, let's first start with Web Awesome, the first component. We already know that Web Awesome authenticated the token with a challenge response protocol. Actually, a Web Awesome client will first hash the challenge and then send it to the token. So this is how authentication works. Then let's see how to create and register these public key credentials used in authentication. For registration, the token has the so-called attestation key pair embedded in the device by the manufacturer. And the secret key part, AK, never leaves this device. The public key, VK, is currently in a PKI certificate, so we can just assume the server already have that VK. Then just like the authentication, the server first sends a random challenge to the token. Then the token will generate a public key credential. It's a secret and public key pair. Then it will use the secret AK to sign the hashed challenge and generated public key. And send the public key and signature to the server. Here we notice that the attestation private key AK is known by the manufacturer, but this generated S key is only known by the token. Then when the server receives the public key and signature, it will use this verification key VK to verify it. And if the signature is valid, then it will accept this registration and register the public key as a public credential. Now the secret key generated by the token and the public key registered on the server can be later used for authentication. Now we have a full picture of the Web Awesome protocol. Now the question is how to prove its security. In cryptography, we need to first define general syntax that captures this protocol and its security model. So we call this kind of protocol as possibly authentication protocol or PLA protocol. Now let's first look at the protocol syntax. Our PLA protocol captures the kind of authentication protocols that have a challenge response scheme like Web Awesome. We essentially use general functions to model different behaviors of the parties and use the so-called registration context to model the output credentials. Then the token and server will just use their corresponding registration context to do the authentication. Now we have the full picture of the PLA protocol syntax. Now let's see how to define the security for PLA protocols. To define security, we need to make a common assumption that the token device is tempo-proof. And it turns out that we can consider very strong adversary that can compromise, corrupt anything except the token. That's because the security information is only stored in the token and all the information that's known by the client and server can be made public. Formally, we see a PLA protocol is secure if for any only server session that accepts with a credential in registration authentication is uniquely partnered with a token session that completely with the same credential. Well, in practice, this security implied that only tokens with valid attestation private keys can be registered to the server, and the server only accepts authentication from the token that registered the same credential. Finally, we prove that Web Awesome is indeed PLA secure if the hash function is clearly resistant and the signature is affordable. That's all for the Web Awesome analysis. Now, let's look at the more complicated protocol, CTAP2. Before showing our analysis, let's take a look at why do we need the CTAP2, so what's missing in Web Awesome? Basically, Web Awesome guarantees a successful authentication is always bound to the registered token, but this may not be bound to the user that owns that token. This makes it possible for an attacker to exploit the user's token to log into another server on behalf of the user. So the attacker just blocks the honest challenge sent to the token and replaces it with the malicious one. It can do this using an online attack waiting for the user to do the authentication or simply steal the token. So that's why we need to establish client-to-token access channels such that only the user authorized client can have access to it. In order to build such client-to-token access channels, we also need the help of the user because we essentially want to bind the token to the user that owns it. Now, let's see how CTAP2 builds such channels. It has three phases. In the first phase setup, the token is brand new, so the user wants to set it up for his own use, so he first creates a secret user-memorizable PIN code and somehow embed a PIN code to the token through the client. So he first types in the PIN code to the client. Then the token and the client will run Diffie-Hellman-KidsChange to share some secret key. With the shared key, the client encrypts the user PIN with a deterministic encryption scheme that we call CPC0. This is the ESI4 in the CPC mode with zero IV, and the client will send the ciphertext to the token. In addition to the encrypted PIN, the client also computes the HMAC on the ciphertext and send that to the token. Here we know that encryption and MAC use the same key. This is not considered as good practice because the security is not clear, and in our proof, we have to model HMAC as a random protocol. Finally, the token gets the ciphertext decrypted to the user PIN and stored hash of it. In the second phase that we call binding phase, the goal is to build an access channel from a client that inputs the user PIN to a token that stored the hash of the PIN. So to do this, the token generates a random PIN token, PT, and somehow send that to the client in a secure way. The first part is the same setup, so they round if you have them, and the client sends the encrypted PIN to the token. But now the token will first check whether or not this PIN hash equals the stored one. So this is to guarantee that only the user that owns this token can build such channels. If the PIN check passes, the token will send that encrypted PT to the client, and the client will decrypt it and store that PT. Now in this final phase, we call it access channel phase. It specifies how to use the secret shared PT value to authorize messages sent from the client to the token. The authorization is very simple. The client just use the PT as the secret key to compute each mic of the message and send that to the token. The token will verify that before accepting this message. Now we have the full setup tool protocol to analyze the security. Again, we need to define its general protocol syntax and security model. We call this type of protocol as a PIN-based access control for authenticators protocol, or PAKA protocol. Now let's first look at the protocol syntax. In general, we still have these three phases, and for the first phase setup, in the end, the token will output some static storage that we call it access. And for the binding phase, the token takes that static storage, and in the end, the token and the client will output some binding state respectively. And finally, for the access channel, the client will use that binding state to generate some authentication tag and send that along with the message to the token for verification. So this is the syntax for our PAKA protocol, now let's see how to define security. For security, we first assume the setup phase to be trusted, because a brand new token can be set up by anyone. So that means we assume the token and the client to be communicated in an authenticated channel, which means the adversary can only read but not modify the communication. But the adversary can manipulate the communication of other phases. We also consider a weaker version of a security model to model the security guaranteed by CTAP2. In this weaker model, we do not allow the adversary to actively attack the client that improves the user pin. This is actually essentially assumed by the CTAP2 protocol, because they used an authenticated defilement case change in the binding phase. And we call this assumption trusted binding. For our PAKA security goals, we define a security notion called vulnerability or UF to guarantee that the adversary cannot forge new authorized messages to the token. So repair attacks are okay, but the adversary should not be able to create a valid tag for a new message that has never been sent on the established access channel. And we also have weaker version called UFT to capture the case with trusted binding assumption. In practice, our security implies that a user's token can only be accessed by the user-authorized clients if the client-issued commands are always different with high probability. So for FIDL2, the client-issued commands are just random web browsing challenges, so they're different with high probability. With our security model, we can prove that CTAP2 is UFT secure in the random protocol model. Here we can see that we require the CBC0 encryption to satisfy some security that we event for this analysis, but it can be reduced to the underlying ASI-first PRF security. Here we also would like to mention that the security bond we got is not negligible because the PIN space has low entropy. So the security bond is similar to the bounding password authenticated case change. We also propose several ways to improve the CTAP2 protocol without weakening its UFT security. For example, in the setup phase, because it's trusted, we don't really need the CBC and HMAC, a simple one-time pad will work. And for the binding phase, we can add some simple user confirmation like pressing a button to exclude all the malicious binding attempts. And finally, CTAP2 also involves several useless reboots that hamper the usability. In the paper, we show that this can be replaced by a simple test of user presence. Now we know that CTAP2 is secure in our UFT model, and it's easy to say that it does not achieve UF security because of the authenticated DFA helmet case change used in the binding phase. So the natural question is that whether or not we can construct a UF secure protocol, actually, we can do better. Recall that in the CTAP2 protocol, all the access channels actually share the same binding state, the PIN token PT. For security, this means if any of these access channels is compromised by an attacker, then all the rest channels are not secure anymore. So to achieve stronger security, one may expect all the binding states to be independent with each other. Then even if all the other channels are compromised, it's still possible to get security from the target channel in use. Based on this idea, we can get a stronger security notion that we call strong affordability, or SUF, that allows for some compromised channels, and we also have the corresponding notion for the trusted binding case. Now let's see how to construct strongly affordable access channels. To do this, we recall the CTAP2 protocol and see how to improve it to get the strongest SUF security. First, as we said, we can remove the HMAC from the setup. Actually, we can use the one-time pad, but here we just use the CBC. Then for the binding phase, our goal is to first remove this trusted binding assumption. To do this, we observe that actually in the beginning of the binding phase, the token and the client already share some security information, the hashed PIN, so they can use this information to authenticate each other. So here we let them run the password authenticated K exchange protocol with the hashed PIN as the shared password to authenticate each other. And another good thing about this PIN protocol is we automatically have independent random binding states. Finally, in the access channel phase, instead of using the same PIN token as the binding state, we now use independent random binding states to authorize the messages in different channels. Now, putting them together, we have our generic protocol construction that we call SecurePaka or SPaka. In the paper, we prove that SPaka is indeed strongly secure in the random oracle model if the building blocks are secure and the PIC protocol is secure with explicit authentication. And we have the same remark here. The security bound is not negligible. It's like PIC protocols. We also analyzed the performance of our SPaka with IETF standard CPIC and PIC protocol compared to the CTAP2 protocol. It turns out that our protocol has fewer communication rounds and roughly the same computation and communication complexity. So the bottom line here is our protocol is more secure and efficient than the current CTAP2 standard. To summarize our Paka security notions, we first know the simple relations between them like SUF implies UF and we know that SPaka achieved the strongest security and CTAP2 only achieved the weakest one, UFT. In our paper, we also have the separation results that show that UF and SUFT do not imply each other. Now that's all for the CTAP2 analysis. Now let's see the overall security of FIDO2 based on its components. Here we have the FIDO2 protocol with the established client-to-token access channel highlighted. In our paper, we show that the user authentication security of FIDO2 is reduced to the security of its components. So the PLA security will have also guaranteed that accepting server is uniquely partnered with registered token and Paka security of CTAP2 guarantee that the PLA partner token can be only accessed by authorized channels. In practice, this means to impersonate the user to log into the server, the attacker has to get authorized access to the registered token. However, because the CTAP2 protocol only guarantees weak security about access channels, so we have some limitations here. We have to assume the binding phase is trusted and no access channel to the target token can be compromised. But we show that if the CTAP2 protocol is replaced by our strongly secure as Paka protocol, then we can get rid of all these limitations. Here we still have some subtleties though. If the attacker compromised the channel to the user's token, we know that it cannot access the token through the channel used by the user, but it can block that channel and ensure that the token is accessed by the compromised one. So in this case, we need the user to decline such malicious authentication, so here we require some user gesture to do it. One possible way to do this is to let the user check whether the token actually uses the expected channel. For example, we can let the token and the client to display some human readable channel ID to the user to check whether they are equal. And for this, we require the token to have a display. Now for the example shown in this graph, we have that the token shows the channel ID to be 2, but the client shows it to be 1, so it does not equal. Then the user can decline this authentication. Now we are quite good with the user authentication part of FIDL2. Now let's see whether or not we can get several authentication. First, we recall that FIDL2 is often wrong after some secure channel is established. For example, with TRS, we already have several authentication for the client. The real question here is does FIDL2 provide user-side server authentication if we have TRS? In our paper, we show that the current standard FIDL2 indeed have user-side server authentication if we have TRS. Actually, this can be any server to client authentication protocol. And for this security, we do not need the token to have a display, so it can be simply pressing a button. Then as before, we can improve the security by replacing CTAP2 with our stronger SPACA protocol. To really achieve security in practice when some channels are compromised, we require the user to have a gesture to decline the malicious access like checking the channel consistency. And for this, we require the token to have a display. Now here is the summary of the FIDL2 security. The bottom line here is we have mutual authentication for the FIDL2 protocol if we have TRS, and we have stronger security when the CTAP2 protocol is replaced by our stronger SPACA protocol. Finally, we'd like to emphasize here why FIDL2 is better than using password and second factor. First, we notice that FIDL2 authentication does not have any password at all. So it does not have those password-related issues like server corruption, phishing, and so on. And low-entropy user pins are only stored in secure tokens and are only attackable in binding phases. And we know that bindings happen much less frequently than authentication sessions, so it's much easier to guarantee security. Okay, now let's summarize our work. So our work analyzes FIDL2's authentication properties. We basically clarify the security guarantees and vulnerabilities and show how to improve its security and efficiency. There are some open problems left. For example, to analyze FIDL2's other protocols or FIDL2's other properties and also construct more efficient, strongly secure password-related authentication protocols.