WEBVTT 00:00.000 --> 00:08.800 Okay, now, okay, I think changes, let me know. 00:08.800 --> 00:14.520 My name is Alfie Frester, it's great to be here, it's my first time at Fostem, I'm here 00:14.520 --> 00:19.960 to talk about credentials for Linux and the Air Force to bring passkeys and other credentials 00:19.960 --> 00:23.240 to the Linux desktop. 00:24.160 --> 00:30.320 Sorry, sorry, sorry to show off, and we here as I very used the passkeys, most people 00:30.320 --> 00:35.320 as they expect here, we here feel that they have a good grasp of what happens from the 00:35.320 --> 00:42.160 moment to capture the key or use your passkeys onwards, like what happens behind the scenes. 00:44.160 --> 00:50.720 Yeah, the passkeys are quite complex, I'll soon do the spasher, I'll briefly talk about them 00:50.720 --> 00:52.640 before we start. 00:52.640 --> 00:58.520 So, passkeys are public key credentials, they are designed to replace passwords and multi-factor 00:58.520 --> 00:59.520 authentication. 00:59.520 --> 01:06.520 In fact, the passkey is in itself two factors, you need both your device and either biometrics 01:06.520 --> 01:11.840 or append normally to use a passkey. 01:11.840 --> 01:18.600 Passkeys are built on two main specifications, W3C's web often, which I guess is short for 01:18.600 --> 01:25.080 web authentication, defining the API for apps and websites to use, and find those 01:25.080 --> 01:31.080 set-up, which stands for client to authenticate or protocol, for all that happens behind 01:31.080 --> 01:36.560 the scenes all the way to the actual hardware. 01:36.560 --> 01:44.960 A bit of history, passkeys are a subset of FIDO2, which is a successor of U2F or ONF's 01:45.040 --> 01:48.960 universal second factor, this is a lot of funnms. 01:48.960 --> 01:56.560 This was a protocol originally intended for legacy or older security keys, massive collection 01:56.560 --> 01:57.560 of them. 01:57.560 --> 02:06.600 So, there's like USB keys, you can use NFC cards, you can see Bluetooth connected buttons 02:06.600 --> 02:09.200 as we can decaders. 02:09.240 --> 02:15.000 We're able to introduce passwordless credentials, meaning that you no longer need a first 02:15.000 --> 02:22.840 factor, but passkeys actually raise the bar or FIDO2 one step further. 02:22.840 --> 02:27.280 There's specifically a so-called discoverable credentials, which generally means that the 02:27.280 --> 02:34.520 credential itself resides at rest on the authenticator hardware, and crucially this means 02:34.560 --> 02:37.560 they can be used in user name, let's fashion. 02:37.560 --> 02:43.160 Meaning that the passkey is your user name, your password, and your second factor, all 02:43.160 --> 02:50.680 in one, so yeah, this is like USB type, so yeah, it's a biometrics that you need to use. 02:50.680 --> 02:57.480 So by touching it, you prove possession of your security key, and as well as UR. 02:57.480 --> 03:01.960 There's a flows of UX flows, FIDO2 adds two important ones. 03:01.960 --> 03:07.400 This hybrid, which enables using your phone as a roaming authenticator, is what the 03:07.400 --> 03:12.840 spec calls it, but if, so it's using a passkey on your phone on another device, like 03:12.840 --> 03:17.040 normally it's intended for the first use scenario when you activate a new device for the 03:17.040 --> 03:23.120 first time, as well as synced credentials, so this is effectively storing passkey in your 03:23.120 --> 03:28.600 Google account or your password manager, which syncs them across devices. 03:28.600 --> 03:35.640 Usually there's a link in the slides, a great talk which is from a few days ago, the 03:35.640 --> 03:41.560 thing podcast on why the things are as complicated as they are now, it's a great watch. 03:41.560 --> 03:49.000 I want to highlight that security keys matter, but for mass adoption, it's phones and 03:49.000 --> 03:54.840 password manager that will define the passkey landscape, in my opinion, there's why 03:54.920 --> 04:00.200 passkeys became so mainstream, and virtually everyone nowadays owns a phone that's capable 04:00.200 --> 04:07.560 of being an authenticator, so Linux needs to treat the mass one flows and password manager 04:07.560 --> 04:11.240 as first class citizens. 04:11.240 --> 04:17.240 I've already stressed that their passacointos providers are very important for the ecosystem, 04:17.240 --> 04:20.680 but it's even clearer if I say that they're now actually the default. 04:20.680 --> 04:27.480 On most Android and iOS devices with Google Password Manager, and I cloud keychain, 04:27.480 --> 04:33.000 I think it's a passwords app, it's what it's called, they're owned by default, and both 04:33.000 --> 04:41.160 platforms still allow you to your own password manager as an alternative, as both as source 04:41.160 --> 04:46.520 of passkeys and to manage thinking those passkeys to other devices, this is important because 04:46.520 --> 04:51.800 it requires that the platform provides secure APIs that interface between the platform, 04:51.800 --> 04:55.320 sorry, interface the platform with the password managers as well. 04:57.160 --> 05:00.760 So where are we here on our problems that we've tried to solve with credentials for Linux? 05:00.760 --> 05:07.480 First, the Linux desktop needs platform APIs, so these are what the browser or the app interacts with 05:07.480 --> 05:16.280 when accessing passkeys. On Windows, iOS, Mac OS, and Android browsers and apps do this, they call it 05:16.360 --> 05:20.760 to the OS to use a passkey. This kind of what it looks like on latest platforms. 05:22.520 --> 05:29.160 Second, we don't have platform APIs on Linux, but browser is an apps still need access, 05:29.160 --> 05:34.920 so which means that what they do is apps that use passkeys currently must implement every bit of 05:34.920 --> 05:39.320 the setup for other golden cells, and generally directly access hardware themselves. 05:40.120 --> 05:44.600 This could be directly accessing the USB stack or the BLE stack, the Bluetooth stack. 05:45.240 --> 05:51.240 And so as you expect, the UX is also quite inconsistent between apps. On the left you can see 05:51.240 --> 05:58.280 five hooks, it's falling back to its own client implementation. This only supports USB on Linux 05:58.280 --> 06:04.440 right now, so there's no Bluetooth or can you use your phone as a passkey. On the right, you can 06:04.440 --> 06:08.600 take home your hand on the other hand, which in itself I believe is one of the best implementations 06:08.600 --> 06:15.320 of the UX, but it looks very different from five hooks, and they've also recently removed 06:15.320 --> 06:21.160 functionality, you no longer can use for some reason, a Bluetooth keys, a standard Bluetooth keys, 06:22.280 --> 06:27.080 they've removed them after they were previously supported, and also if you use a QR code 06:27.080 --> 06:33.960 from your phone, remember this device is no longer an option. I also want to call out 06:33.960 --> 06:39.880 containerized apps. So without any passkeys said, yeah, these apps can use. They have no access 06:39.880 --> 06:45.480 to authenticate or hardware by default. So if you're using a browser as a, as a, as a flashback, 06:45.480 --> 06:51.320 for example, unless you have an extension for your password manager in that browser, your only option 06:51.320 --> 06:57.880 is to provide the browser with direct access to hardware, which can be much wider than what you 06:57.960 --> 07:04.840 actually want, effectively breaking the sandboxing, and it will in all cases create a risk for 07:05.480 --> 07:13.080 origin bypass. And let me give you an example, let's imagine a hypothetical malicious force 07:13.080 --> 07:19.960 them app. It will tell you, like I wanted to log, I want to log you in on force them.org, 07:19.960 --> 07:25.320 please tap to use your passkey. But secretly, what is telling you that is authenticating 07:25.320 --> 07:32.200 you on force them.org, it's sending a request to your security key for Google.com. And so this has no 07:32.200 --> 07:36.760 display, there's a blinking light, you tap it, and you just, you know, then you get on your 07:36.760 --> 07:46.920 behalf to Google and it starts reading your email, covering up IDL. I'll talk about the IDNL and 07:46.920 --> 07:53.480 what we've built so far. So what we want is, for example, a browser or some other flatback app 07:53.640 --> 07:58.520 here on the left, we want them to be able to access credentials. Right now we'll talk about 07:58.520 --> 08:08.200 passkeys or whatever, yeah, on whatever device and they're on the right. And so they need to be 08:08.200 --> 08:12.200 able to do that, just by calling this new credentials API, we want the service to handle everything, 08:12.840 --> 08:18.920 talking to devices, to see that protocols, asking the user for permission, showing that UI, 08:18.920 --> 08:25.640 and also choosing which passkey or which device. So here's what we've built, we have this new 08:26.360 --> 08:31.560 two components, two power this new credential API, and together this work currently makes up 08:31.560 --> 08:37.640 credentials for Linux. Link web often is a platform library and this is implement the 08:37.640 --> 08:46.120 phyto protocols and the transport to authenticators and credentials D for the interfaces with applications 08:46.120 --> 08:52.440 and credentials providers. I'll talk about credentials D first because this is the component 08:52.440 --> 09:00.920 that most of you will be interested in as Linux developers and this includes the Linux credentials 09:00.920 --> 09:08.440 API, which will be available over debuffs used by containerized apps and browser browsers alike 09:11.160 --> 09:14.680 and the credentials provide the API so you can plug in your own password manager. 09:14.760 --> 09:19.400 I'll demo this at the end of the video, but I also invite you to try it out for yourself, 09:20.120 --> 09:24.200 check out the read me as instructions, keeping in mind the UI right now that you see, 09:24.200 --> 09:28.680 it's currently a reference implementation, it's only meant to be an inspiration for 09:29.400 --> 09:34.840 desktop environment developers who actually actually noted doing the UI not like us, 09:35.640 --> 09:41.480 so this wink wink if there's any normal key developers in the room, I love to chat. 09:42.280 --> 09:48.520 I'll turn this off this bit into two, it has the prompt end, which processes requests 09:49.400 --> 09:56.600 talks to apps, devices and credentials providers and it has the backend which is native to each 09:56.600 --> 10:04.520 desktop environment and shows the user prompts. This naming and this pattern is the portal pattern. 10:04.600 --> 10:11.240 Yes, to me I have questions like we here is familiar with XDG desktop portals. 10:13.400 --> 10:18.840 Okay, there's a few, so I'll be brief like portals or XDG desktop portals there, 10:18.840 --> 10:26.760 APIs for sandbox apps such as flatbacks so they can safely access functionality outside of their 10:26.760 --> 10:31.720 sandbox, there's a lot of them and they provide different functionality and they've also become 10:31.720 --> 10:36.840 increasingly platform APIs and that for desktop apps not necessarily the sandbox ones 10:37.960 --> 10:43.960 to access functionality because it's more convenient at times and it expels via VAB bus and as for where 10:43.960 --> 10:52.840 we are right now, XDG desktop portals, developers they are more to the plan and we're working 10:52.840 --> 10:58.680 alongside them will make credentials the de facto implementation of a new credentials portal 10:58.760 --> 11:04.120 that we'll be able to it. We have a prototype portal with a specification you can check out 11:05.400 --> 11:11.320 we're discussing the finer details and they work in progress via that linked if you're interested 11:11.320 --> 11:18.600 if you get the slides. On the other side of the project we have LibreBuffin so this is Linux native 11:19.160 --> 11:25.400 it's a rough implementation of the file specifications it's a possible file to and the older 11:25.400 --> 11:32.200 new 2F for second factor yes a playable transport interface which just means that it's easier to 11:32.200 --> 11:37.800 add new transport like Bluetooth or NFC without them into the implement the protocol it's taken a 11:37.800 --> 11:44.520 while I personally started working on this in 2020 before pass keys because I was frustrated 11:44.520 --> 11:50.600 a five-fog set of time only supported USB keys however thanks to a lot of work from a few key 11:50.600 --> 11:59.240 contributors it's now quite fully fully featured so there's two dimensions one is transport 11:59.240 --> 12:04.680 which is shown here and I'm proud to say we've put all the transports now to 8.10 12:04.680 --> 12:12.120 old indicators this is USB Bluetooth low energy if you have a Bluetooth indicator the one 12:12.120 --> 12:18.440 cool and longer supports NFC if you want to tap your security key you can use the there's some 12:18.440 --> 12:23.080 keys that you tap to your phone and you can actually use cards with cards reader as well 12:24.520 --> 12:28.360 and hybrid which is the flow where you use your phone it's kind of QR code and you can 12:28.360 --> 12:38.520 remember the pairing as well we support that I'll go through like an example in this diagram 12:39.240 --> 12:44.200 to like kind of try and explain all these things together so let's say you have the force 12:44.200 --> 12:49.560 them up and it's going to be at the top and this this is our request to use a pass key for 12:49.560 --> 12:55.080 for them to come for a similar work so you know the you know this the same way they do 12:55.080 --> 12:59.480 access any other portal you make a request via the bus to SDG desktop portal for the 13:00.120 --> 13:07.320 credentials portal API the portal proxy then roots this to credentials D specifically the 13:07.320 --> 13:13.560 front end which checks the requests validates it and identifies any possible credentials sources 13:13.560 --> 13:18.600 for this request you may talk to password managers at the stage and understand if they have 13:18.600 --> 13:27.880 occurred initial and and also identify which devices are available on this system you will then 13:27.880 --> 13:34.920 call in to the UI backend say norms portal implementation in this case and we'll show a prompt 13:34.920 --> 13:41.640 native to norm which is not our one that's one that one is our reference UI but it will identify the 13:41.640 --> 13:47.320 app saying this request comes from the false them binary I will say this is for false them 13:47.320 --> 13:53.640 of org and it will then allow the users to choose their advice and if my app multiple paths 13:53.640 --> 13:58.440 he's gonna be able to select that and I say the user in this case chooses to use their phone 13:59.320 --> 14:06.840 the request and controls the roots there's to link web often which generates a QR code 14:06.840 --> 14:11.480 your laptop will actually start listening for Bluetooth others there's a proximity check 14:11.480 --> 14:17.560 built into pesky like this a little web often will then listen for that signal the 14:17.560 --> 14:22.600 Bluetooth and it will detect the QR codes scan and will negotiate an encrypted tunnel 14:22.600 --> 14:29.720 directly through the internet from your laptop to the device and we'll retrieve the credential 14:29.720 --> 14:34.680 and finally discuss back to the browser at the top I want to mention a few up in challenges 14:35.240 --> 14:41.000 because we've not solved all the problems origin scoping is the first one this is a guarantee 14:41.000 --> 14:46.760 offer by web often it can be worth an as follows credentials for your origin so in this case 14:46.760 --> 14:54.120 say false them to talk should only be accessed by your origin on your website or authorized 14:54.120 --> 15:01.640 related origin if you have a website that uses multiple domains or authorized native apps 15:02.280 --> 15:08.040 only looks if we get a request from the false them library for the false from the false them binary 15:08.040 --> 15:14.360 how do we determine which origins should have access to it challenge two is an extension of the one 15:15.480 --> 15:20.600 before we can even think of associating allowed origins to an app how do I verify for certain 15:20.600 --> 15:27.160 that the app is with says it is on Android and yes this is achieved cryptographically by using the 15:27.160 --> 15:34.600 same keys of the app or the developer certificates only in a cello we achieved this and if you have any 15:34.920 --> 15:42.120 ideas please can contribute come come to the debate join the metrics room I'll share the end 15:43.240 --> 15:48.440 so the goal is to do this to the same as other platforms there are two types of apps one is mainly 15:48.440 --> 15:53.080 browsers these are special they have a genuine need to access credentials for any origin 15:54.120 --> 15:59.720 and these are privileged clients and then all other apps going back to our example the false them 16:00.360 --> 16:07.080 only needs access to false them but not cool or come on other platforms you have this two different 16:07.080 --> 16:13.480 app and two different APIs and specific access control for example in Android if you want to 16:13.480 --> 16:18.600 get access to the privilege the PI you have to declare your app as a browser and get some special 16:18.600 --> 16:25.080 permission I believe from Google through Google Play so the current state right now in the 16:25.080 --> 16:31.000 implementation there's a single API but every request is mediated by the user so if the user is using 16:31.000 --> 16:37.800 Firefox they will get a from the says Firefox the Firefox binary wants to access a credential for 16:37.800 --> 16:42.440 this specific origin so right now we're delegating the problem where the user also sold the problem 16:42.440 --> 16:46.280 the user also decide whether the application should be accessing that credential 16:48.200 --> 16:54.680 what's next what is doing right now if it feels we're generally close we do a few gaps to bridge 16:54.760 --> 16:59.880 the IS priority is probably absolutely integration we need patches and collaboration from browsers 16:59.880 --> 17:05.240 we are a patch for Firefox which I'll demo but we do need help from other browsers so if you're 17:05.240 --> 17:12.120 browser developer also let's chat and then storage for remembering devices so if you're 17:12.120 --> 17:17.320 kind of QR code you don't have to kind of QR code every time type of the providers 17:18.360 --> 17:23.960 passwords and all the pieces so other types of credentials this may include verifiable credentials in 17:23.960 --> 17:30.440 the future so that will see API that can be used for digital IDs or provide proof of age 17:31.160 --> 17:35.160 there's I said that because there is a lot of common infrastructure in the specifications in 17:35.160 --> 17:44.520 the technical implementation so the QR code flow is also shared with without digital ID flow 17:45.080 --> 17:48.680 finally five respects are evolving and we're going to make sure to keep up 17:48.840 --> 17:57.880 you have demo now if it works I'll show first the QR code flow so this is one of the latest 17:57.880 --> 18:02.600 Firefox builds although it's not the latest credentials in the build so the UI has changed slightly 18:03.320 --> 18:08.600 so I'm going to try and do is just signing it and beat up I'm going to use signing with the 18:08.600 --> 18:14.360 pass key and this is now calling into the portal API I've selected one to use my phone 18:14.920 --> 18:20.040 whether you use my phone to scan a QR code if I were to do this my phone will ask me 18:20.040 --> 18:27.640 you want to use a pass key I tap on it and say yes and then I select the pass key and use my 18:27.640 --> 18:32.440 bone metrics and that's it device connected I think you know at this point I'm doing my bone 18:32.440 --> 18:38.200 very good on my phone and I'm logged in so I use my phone without having ever previously 18:38.200 --> 18:43.800 connected to my connected it to my laptop this is the USB flow which is very similar 18:44.520 --> 18:51.080 again I connect security key I'm using a biometric one in this example so I just can't my fingerprint 18:51.880 --> 18:54.040 and I'm logged in so we're here fast 18:58.040 --> 19:03.240 please get involved there's a lot to do if any of these is interesting to you 19:03.880 --> 19:09.400 if you like any you'd like to help we'd love to chat you can find us all on maithrex 19:09.400 --> 19:14.440 on address we're a friendly bunch don't be shy and that's our get up as well 19:15.880 --> 19:18.600 I wanted to call out some projects that have been helpful 19:18.600 --> 19:23.640 it will be helpful for future expansions but in the interest of time I think I'll leave them here 19:25.000 --> 19:29.400 I just before we want to question so I want to thank two core contributors 19:30.360 --> 19:35.800 those of time over the past few years in the project I say you know 19:35.800 --> 19:39.480 you started a while back leading the portals and provided integration 19:41.400 --> 19:46.360 is now funded by bit warden which saw some and Martin telling us 19:46.360 --> 19:50.200 he's not been here with me today unfortunately it was not able to make it from Suze 19:51.080 --> 19:56.040 he's put in a massive amount of work recently and contribute his expertise 19:57.000 --> 20:01.160 expertise from working on multilas not integration library in the past 20:03.160 --> 20:05.160 so thank you very much and 20:07.880 --> 20:09.880 thank you questions 20:17.320 --> 20:19.320 okay 20:26.840 --> 20:32.440 yes so that's we sorry to be the question yes so the question is on credentials 20:32.440 --> 20:36.840 did we currently already support enrolling and assuming it's unrolling the biometrics 20:36.840 --> 20:42.040 for a pesky so if it's the first time you use for example a USB key which has biometrics 20:42.040 --> 20:46.920 they use it actually has to register their their fingerprint and this is part of the 20:47.800 --> 20:52.680 seat of protocol implemented in actually a lib web often and the UI and the flow is provided 20:53.640 --> 20:57.000 that's already supported so that's both for setting your pin the first time you 20:57.000 --> 21:01.720 could set up a security key as well as enrolling biometrics which means scanning your finger 21:01.720 --> 21:05.480 a few times until the security key is happy that you're fingerprinter 21:11.480 --> 21:18.280 I believe so the question is do we plan to include in this in setting 21:19.240 --> 21:23.400 I do believe so I will encourage you to ask that question in the medical channel because I think 21:23.400 --> 21:25.720 Isaiah will be the best person to answer that question 21:27.080 --> 21:32.120 I also know that I think it's most common for users to go through that flow as they use their 21:32.120 --> 21:37.800 pesky as well as they try and create a pesky or try and use a pesky the UI will prompt you to do that 21:37.800 --> 21:44.280 on the first use but there should be some some management and the setting stage also to add 21:44.280 --> 21:48.280 in the removal of password managers so you can set them up from there 21:57.240 --> 22:03.320 this is a great question so for the question is timeline this is a timeline for this to be 22:03.320 --> 22:09.640 upstream to five folks so we have a patch up for review by five folks I'm not sure there's a specific 22:09.720 --> 22:21.720 timeline if you know any Mozilla developers maybe we can ask them I think that Isaiah's goal I believe 22:22.440 --> 22:25.960 I don't know if I'm supposed to mention this but it's for that to hopefully go in the next 22:25.960 --> 22:32.520 tutorial it is if we can but I think it's also up to upstream whether we can get those patches up 22:32.520 --> 22:35.480 and whether we can get that chrome in patches as well which we don't have right now 22:39.640 --> 22:47.080 so my question is this whole work so after you have a new procession so you'll log in 22:47.080 --> 22:56.040 into the system one about the free login yeah so the question is this whole works once you have 22:56.040 --> 23:03.480 us user session what about pre login I think that's a great question I think different systems take 23:03.480 --> 23:07.560 different approaches I believe Windows at low is kind of a single system which is able to do both 23:07.560 --> 23:13.160 sign in as well as application management credentials for applications right now we're starting 23:13.160 --> 23:19.400 applications I believe there's actually an other talk about GDM and Pascal is in yes to listen to 23:27.400 --> 23:31.960 I think if you what might prevent that if we want to integrate this work in pre login I think 23:31.960 --> 23:39.960 a few challenges is for example when you when you're using a pesky we have store devices for 23:39.960 --> 23:44.520 example we might already use your phone and we might link to your phone so if you're not logged in 23:44.520 --> 23:49.400 for example you might not be able to use that link because that's presumably we can only access 23:49.400 --> 23:57.880 that information after we we identify the user but other than that I don't know there's much 23:58.280 --> 24:03.800 there's the problem of which origin the use but which app is making the requests web off when 24:03.800 --> 24:10.680 we work at the main so I may have to make that make one up so it's an interesting question right 24:10.680 --> 24:15.640 I think other people in the in the major channels in my our better answer than me 24:15.640 --> 24:25.720 so one more time anyone yeah if you play for something you're all you're going to 24:25.720 --> 24:31.160 in the truth in past the screen you're related to different levels of information 24:31.160 --> 24:36.680 for perhaps or another. So the question is if I really if I present the fool you're 24:36.680 --> 24:43.720 all or the origin of the requesting of the application of the of the pesky in the user prompt 24:43.720 --> 24:50.440 and displaying to the user do I really need different permissions for applications so for 24:50.440 --> 24:56.440 browsers and normal applications so do I really need a privilege and an unprivileged API that's a 24:56.440 --> 25:01.400 good question and I think the answer we're going for is not strictly because we're not going 25:01.400 --> 25:06.760 to be able to do that for long for our fest release we don't currently have a solution to 25:06.760 --> 25:14.440 the questions that we need so that we can create an unprivileged API. I believe we will be 25:14.440 --> 25:19.800 the first platform to launch without an unprivileged API and so I do suspect this had some 25:19.800 --> 25:27.080 risk in that a lot of platforms they know about android macOS Windows 2 after access as far 25:27.080 --> 25:34.920 as you know. I do believe there's a security trade off because users may the request may be 25:35.000 --> 25:44.280 intercepted users may not necessarily know I think it's yeah I don't believe it's strictly 25:44.280 --> 25:48.280 necessary yes but there's some trade off.