 Okay. So welcome everyone. My name is Norbert Orch and I am an Internet Red Hat since last year. And please welcome Daiki UNO2. Yeah. So I'm Daiki. I'm just a PR of Kim. So it's his project. Please welcome. So today I'm going to talk about FIDO, what it is, what is it good for, what problems does it solve, a little bit about the password authentication and afterwards about our project, what problems we are trying to solve and in what way. So FIDO is an alliance with like 200 members of their companies like Google, PayPal and such on. They are trying to bring more secure, so stronger authentication to the online. We are talking here about two-factor authorization, which means when the user is authenticating into a service, he needs something he know. That means like a password being of something and something he has. This can be a token, some hardware. When we are talking about multi-factor authentication, then it's the same too as at the two-factor authorization, something you have, something you know, and something you are, which are mostly biometrics like fingerprint, retina scan or face scan. And later on I will talk about the passwordless authentication. So when we are authenticating to a service, for example, we want to login into our Facebook account or Google account or something, we mostly have to use username and the password. But the password has to be something long and something which makes it strong like using multiple characters and it should be random. But does it actually mean that it's unbreakable? Well, not. To enhance strength of the security, FIDO tries to make it possible with a second-factor, multi-factor. So why is it good for the server admins? And someone logs into a service site that his data is saved to the database. So there is a username and a hashed password. But if the database got leaks, it's hard to prevent any breaks into the account. But if you use multi-factor authentication, there is not possible to break into the account when they got the password from the hash, because they still need something hardware, something it's in your belongings. So how does it work? So FIDO uses public cryptography and let me talk about it with an example. So FIDO 2 works with two operations, the Macredential, which is used to sign into a service. I will use the word relying party, which means like the other end, which can be like Google Facebook or something. So signing into the relying party and get a session, which is used to log in to this service. When we are signing in, we provide a username and password as regular, but after then the service asks the authenticator to make a credential. That means the authenticator device creates a public key and the private key pair, then sends out the public key to the relying party. When we are trying to log in, the relying party asks for the username, the password, and after this, he sends out a challenge. This challenge can be any data, which the authenticator should sign with the key it has. So this is how the authenticator authenticates your key. The FIDO 2 standard comes with two protocols. The first one is WebAuthon, which is used for communication between the application, so the client and the relying party. It mostly is used with JavaScript and the rest API. The second one is Seatup. It's client to authenticate them protocol, which is a low-level transport protocol which communicates with the authenticator. So let's mention here the user verification. So that means that the authenticator verifies if the person uses the key is actually the person who it belongs to. The verification can happen with a P in a password or biometrics. So now let's talk a bit about password authentication, because beforehand I was talking about the two-factor and multi-factor authentication. Now let's move a bit about the passwordless. The benefits of the passwordless authentication is that the authenticating data, so the verification data remains at the client side. Passwordless authentication doesn't really mean it don't use passwords. It means that the password doesn't get sent out to the relying party through the internet. So as you can see at the diagram, you just pick your username and the relying party asks for the challenge. So there is actually, so there is the password at the client side here when the person authenticates with the authenticator. This process requires user presence to, which means mostly pushing a button at the authenticator, which like cannot be hacked because it's coded hardwarely. The passwordless authentication for now is not possible because the authenticated devices like USB token has no hardware support for that. So for now, there is no authenticator with fingerprint reader, for example, on the market. So let's move to the problems. Fido is working good. There is a problem we are trying to solve, which is that the client who tries to communicate with the authenticator needs full access to the device. A second one is that I was talking about later, user verification is not capable. We have no capable devices for user verification. How does it look like? Let's say we want to use a sandbox, for example, a flatback and want to log in with, for example, Firefox into some service on the internet with two factor authentication. The problem is that the flatback is running not actually at the, like the sandbox cannot access the hardware of the host without permission. So if you want to authenticate yourself with a Mozilla in a flatback, we need to allow the flatback, the permission of working with USB. And this is not what we want to because it can cause like security problems. So our approach to solve this problem is to create a user service on the host and to solve the second problem that there are no capable user authenticated devices on the market to enable virtual passwords authentication with TPM. So the implementation comes with DBAs. It means the service is running at DBAs. It's waiting for the challenges or just operations to come in. And it can be actually activated through system D. That means the service is not running all the time. The first challenge is activating the service on the host to make better permission control inside the flatback. We are using X-DGD bus proxy. So there is a need to allow some permission to flatback. But actually it is just to communicate with the service through DBAs. There was one problem we needed to solve. Let me go back to this diagram. When there is user verification, so the user is prompted to give a PIN password or something, it should be provided to the authenticator. But the process is happening inside the flatback. So we need to get the password to the authenticator from inside the flatback. For this problem, we are using an unnamed pipe. So the service creates five descriptors from through they are communicating with. Here I would like to ask Daiki to tell us something about the demo. Yeah, so we have two demos. The first one is to use Firefox authentication from the flatback. So here is the demo video. As you see, there is only DRI devices and some DBA services are allowed inside flatback. So if you start this flatback and try to log in to GitHub, so the service asks to access the authenticator and it is properly propagated through the DBAs. So I can now log in with this device. Okay, can move on. The second example is that emulating passwordless authentication with TPM. So in this example, we don't use the authenticator device, but we emulate it. So the server program has several options and it has backend selectable. We have currently two backend device people to and the other is TPM. So this is actually passwordless authentication demo. So actually the device is not inserted, but it can be used without the device, but with TPM. So the login is same. I don't need to insert the device. Okay, so a bit about the status. So we have a working DBAs proxy service using libfeedow2 and TPM2. There is a client library which can communicate with the service through DBAs. And there is already a Firefox integration waiting for review. The future plan is to make configuration files so we can actually define beforehand default library we want to use. So libfeedow2 or TPM, then bring it to other distributions like the VM Federer and more client adaptations.