Okay, now, okay, I think changes, let me know.
My name is Alfie Frester, it's great to be here, it's my first time at Fostem, I'm here
to talk about credentials for Linux and the Air Force to bring passkeys and other credentials
to the Linux desktop.
Sorry, sorry, sorry to show off, and we here as I very used the passkeys, most people
as they expect here, we here feel that they have a good grasp of what happens from the
moment to capture the key or use your passkeys onwards, like what happens behind the scenes.
Yeah, the passkeys are quite complex, I'll soon do the spasher, I'll briefly talk about them
before we start.
So, passkeys are public key credentials, they are designed to replace passwords and multi-factor
authentication.
In fact, the passkey is in itself two factors, you need both your device and either biometrics
or append normally to use a passkey.
Passkeys are built on two main specifications, W3C's web often, which I guess is short for
web authentication, defining the API for apps and websites to use, and find those
set-up, which stands for client to authenticate or protocol, for all that happens behind
the scenes all the way to the actual hardware.
A bit of history, passkeys are a subset of FIDO2, which is a successor of U2F or ONF's
universal second factor, this is a lot of funnms.
This was a protocol originally intended for legacy or older security keys, massive collection
of them.
So, there's like USB keys, you can use NFC cards, you can see Bluetooth connected buttons
as we can decaders.
We're able to introduce passwordless credentials, meaning that you no longer need a first
factor, but passkeys actually raise the bar or FIDO2 one step further.
There's specifically a so-called discoverable credentials, which generally means that the
credential itself resides at rest on the authenticator hardware, and crucially this means
they can be used in user name, let's fashion.
Meaning that the passkey is your user name, your password, and your second factor, all
in one, so yeah, this is like USB type, so yeah, it's a biometrics that you need to use.
So by touching it, you prove possession of your security key, and as well as UR.
There's a flows of UX flows, FIDO2 adds two important ones.
This hybrid, which enables using your phone as a roaming authenticator, is what the
spec calls it, but if, so it's using a passkey on your phone on another device, like
normally it's intended for the first use scenario when you activate a new device for the
first time, as well as synced credentials, so this is effectively storing passkey in your
Google account or your password manager, which syncs them across devices.
Usually there's a link in the slides, a great talk which is from a few days ago, the
thing podcast on why the things are as complicated as they are now, it's a great watch.
I want to highlight that security keys matter, but for mass adoption, it's phones and
password manager that will define the passkey landscape, in my opinion, there's why
passkeys became so mainstream, and virtually everyone nowadays owns a phone that's capable
of being an authenticator, so Linux needs to treat the mass one flows and password manager
as first class citizens.
I've already stressed that their passacointos providers are very important for the ecosystem,
but it's even clearer if I say that they're now actually the default.
On most Android and iOS devices with Google Password Manager, and I cloud keychain,
I think it's a passwords app, it's what it's called, they're owned by default, and both
platforms still allow you to your own password manager as an alternative, as both as source
of passkeys and to manage thinking those passkeys to other devices, this is important because
it requires that the platform provides secure APIs that interface between the platform,
sorry, interface the platform with the password managers as well.
So where are we here on our problems that we've tried to solve with credentials for Linux?
First, the Linux desktop needs platform APIs, so these are what the browser or the app interacts with
when accessing passkeys. On Windows, iOS, Mac OS, and Android browsers and apps do this, they call it
to the OS to use a passkey. This kind of what it looks like on latest platforms.
Second, we don't have platform APIs on Linux, but browser is an apps still need access,
so which means that what they do is apps that use passkeys currently must implement every bit of
the setup for other golden cells, and generally directly access hardware themselves.
This could be directly accessing the USB stack or the BLE stack, the Bluetooth stack.
And so as you expect, the UX is also quite inconsistent between apps. On the left you can see
five hooks, it's falling back to its own client implementation. This only supports USB on Linux
right now, so there's no Bluetooth or can you use your phone as a passkey. On the right, you can
take home your hand on the other hand, which in itself I believe is one of the best implementations
of the UX, but it looks very different from five hooks, and they've also recently removed
functionality, you no longer can use for some reason, a Bluetooth keys, a standard Bluetooth keys,
they've removed them after they were previously supported, and also if you use a QR code
from your phone, remember this device is no longer an option. I also want to call out
containerized apps. So without any passkeys said, yeah, these apps can use. They have no access
to authenticate or hardware by default. So if you're using a browser as a, as a, as a flashback,
for example, unless you have an extension for your password manager in that browser, your only option
is to provide the browser with direct access to hardware, which can be much wider than what you
actually want, effectively breaking the sandboxing, and it will in all cases create a risk for
origin bypass. And let me give you an example, let's imagine a hypothetical malicious force
them app. It will tell you, like I wanted to log, I want to log you in on force them.org,
please tap to use your passkey. But secretly, what is telling you that is authenticating
you on force them.org, it's sending a request to your security key for Google.com. And so this has no
display, there's a blinking light, you tap it, and you just, you know, then you get on your
behalf to Google and it starts reading your email, covering up IDL. I'll talk about the IDNL and
what we've built so far. So what we want is, for example, a browser or some other flatback app
here on the left, we want them to be able to access credentials. Right now we'll talk about
passkeys or whatever, yeah, on whatever device and they're on the right. And so they need to be
able to do that, just by calling this new credentials API, we want the service to handle everything,
talking to devices, to see that protocols, asking the user for permission, showing that UI,
and also choosing which passkey or which device. So here's what we've built, we have this new
two components, two power this new credential API, and together this work currently makes up
credentials for Linux. Link web often is a platform library and this is implement the
phyto protocols and the transport to authenticators and credentials D for the interfaces with applications
and credentials providers. I'll talk about credentials D first because this is the component
that most of you will be interested in as Linux developers and this includes the Linux credentials
API, which will be available over debuffs used by containerized apps and browser browsers alike
and the credentials provide the API so you can plug in your own password manager.
I'll demo this at the end of the video, but I also invite you to try it out for yourself,
check out the read me as instructions, keeping in mind the UI right now that you see,
it's currently a reference implementation, it's only meant to be an inspiration for
desktop environment developers who actually actually noted doing the UI not like us,
so this wink wink if there's any normal key developers in the room, I love to chat.
I'll turn this off this bit into two, it has the prompt end, which processes requests
talks to apps, devices and credentials providers and it has the backend which is native to each
desktop environment and shows the user prompts. This naming and this pattern is the portal pattern.
Yes, to me I have questions like we here is familiar with XDG desktop portals.
Okay, there's a few, so I'll be brief like portals or XDG desktop portals there,
APIs for sandbox apps such as flatbacks so they can safely access functionality outside of their
sandbox, there's a lot of them and they provide different functionality and they've also become
increasingly platform APIs and that for desktop apps not necessarily the sandbox ones
to access functionality because it's more convenient at times and it expels via VAB bus and as for where
we are right now, XDG desktop portals, developers they are more to the plan and we're working
alongside them will make credentials the de facto implementation of a new credentials portal
that we'll be able to it. We have a prototype portal with a specification you can check out
we're discussing the finer details and they work in progress via that linked if you're interested
if you get the slides. On the other side of the project we have LibreBuffin so this is Linux native
it's a rough implementation of the file specifications it's a possible file to and the older
new 2F for second factor yes a playable transport interface which just means that it's easier to
add new transport like Bluetooth or NFC without them into the implement the protocol it's taken a
while I personally started working on this in 2020 before pass keys because I was frustrated
a five-fog set of time only supported USB keys however thanks to a lot of work from a few key
contributors it's now quite fully fully featured so there's two dimensions one is transport
which is shown here and I'm proud to say we've put all the transports now to 8.10
old indicators this is USB Bluetooth low energy if you have a Bluetooth indicator the one
cool and longer supports NFC if you want to tap your security key you can use the there's some
keys that you tap to your phone and you can actually use cards with cards reader as well
and hybrid which is the flow where you use your phone it's kind of QR code and you can
remember the pairing as well we support that I'll go through like an example in this diagram
to like kind of try and explain all these things together so let's say you have the force
them up and it's going to be at the top and this this is our request to use a pass key for
for them to come for a similar work so you know the you know this the same way they do
access any other portal you make a request via the bus to SDG desktop portal for the
credentials portal API the portal proxy then roots this to credentials D specifically the
front end which checks the requests validates it and identifies any possible credentials sources
for this request you may talk to password managers at the stage and understand if they have
occurred initial and and also identify which devices are available on this system you will then
call in to the UI backend say norms portal implementation in this case and we'll show a prompt
native to norm which is not our one that's one that one is our reference UI but it will identify the
app saying this request comes from the false them binary I will say this is for false them
of org and it will then allow the users to choose their advice and if my app multiple paths
he's gonna be able to select that and I say the user in this case chooses to use their phone
the request and controls the roots there's to link web often which generates a QR code
your laptop will actually start listening for Bluetooth others there's a proximity check
built into pesky like this a little web often will then listen for that signal the
Bluetooth and it will detect the QR codes scan and will negotiate an encrypted tunnel
directly through the internet from your laptop to the device and we'll retrieve the credential
and finally discuss back to the browser at the top I want to mention a few up in challenges
because we've not solved all the problems origin scoping is the first one this is a guarantee
offer by web often it can be worth an as follows credentials for your origin so in this case
say false them to talk should only be accessed by your origin on your website or authorized
related origin if you have a website that uses multiple domains or authorized native apps
only looks if we get a request from the false them library for the false from the false them binary
how do we determine which origins should have access to it challenge two is an extension of the one
before we can even think of associating allowed origins to an app how do I verify for certain
that the app is with says it is on Android and yes this is achieved cryptographically by using the
same keys of the app or the developer certificates only in a cello we achieved this and if you have any
ideas please can contribute come come to the debate join the metrics room I'll share the end
so the goal is to do this to the same as other platforms there are two types of apps one is mainly
browsers these are special they have a genuine need to access credentials for any origin
and these are privileged clients and then all other apps going back to our example the false them
only needs access to false them but not cool or come on other platforms you have this two different
app and two different APIs and specific access control for example in Android if you want to
get access to the privilege the PI you have to declare your app as a browser and get some special
permission I believe from Google through Google Play so the current state right now in the
implementation there's a single API but every request is mediated by the user so if the user is using
Firefox they will get a from the says Firefox the Firefox binary wants to access a credential for
this specific origin so right now we're delegating the problem where the user also sold the problem
the user also decide whether the application should be accessing that credential
what's next what is doing right now if it feels we're generally close we do a few gaps to bridge
the IS priority is probably absolutely integration we need patches and collaboration from browsers
we are a patch for Firefox which I'll demo but we do need help from other browsers so if you're
browser developer also let's chat and then storage for remembering devices so if you're
kind of QR code you don't have to kind of QR code every time type of the providers
passwords and all the pieces so other types of credentials this may include verifiable credentials in
the future so that will see API that can be used for digital IDs or provide proof of age
there's I said that because there is a lot of common infrastructure in the specifications in
the technical implementation so the QR code flow is also shared with without digital ID flow
finally five respects are evolving and we're going to make sure to keep up
you have demo now if it works I'll show first the QR code flow so this is one of the latest
Firefox builds although it's not the latest credentials in the build so the UI has changed slightly
so I'm going to try and do is just signing it and beat up I'm going to use signing with the
pass key and this is now calling into the portal API I've selected one to use my phone
whether you use my phone to scan a QR code if I were to do this my phone will ask me
you want to use a pass key I tap on it and say yes and then I select the pass key and use my
bone metrics and that's it device connected I think you know at this point I'm doing my bone
very good on my phone and I'm logged in so I use my phone without having ever previously
connected to my connected it to my laptop this is the USB flow which is very similar
again I connect security key I'm using a biometric one in this example so I just can't my fingerprint
and I'm logged in so we're here fast
please get involved there's a lot to do if any of these is interesting to you
if you like any you'd like to help we'd love to chat you can find us all on maithrex
on address we're a friendly bunch don't be shy and that's our get up as well
I wanted to call out some projects that have been helpful
it will be helpful for future expansions but in the interest of time I think I'll leave them here
I just before we want to question so I want to thank two core contributors
those of time over the past few years in the project I say you know
you started a while back leading the portals and provided integration
is now funded by bit warden which saw some and Martin telling us
he's not been here with me today unfortunately it was not able to make it from Suze
he's put in a massive amount of work recently and contribute his expertise
expertise from working on multilas not integration library in the past
so thank you very much and
thank you questions
okay
yes so that's we sorry to be the question yes so the question is on credentials
did we currently already support enrolling and assuming it's unrolling the biometrics
for a pesky so if it's the first time you use for example a USB key which has biometrics
they use it actually has to register their their fingerprint and this is part of the
seat of protocol implemented in actually a lib web often and the UI and the flow is provided
that's already supported so that's both for setting your pin the first time you
could set up a security key as well as enrolling biometrics which means scanning your finger
a few times until the security key is happy that you're fingerprinter
I believe so the question is do we plan to include in this in setting
I do believe so I will encourage you to ask that question in the medical channel because I think
Isaiah will be the best person to answer that question
I also know that I think it's most common for users to go through that flow as they use their
pesky as well as they try and create a pesky or try and use a pesky the UI will prompt you to do that
on the first use but there should be some some management and the setting stage also to add
in the removal of password managers so you can set them up from there
this is a great question so for the question is timeline this is a timeline for this to be
upstream to five folks so we have a patch up for review by five folks I'm not sure there's a specific
timeline if you know any Mozilla developers maybe we can ask them I think that Isaiah's goal I believe
I don't know if I'm supposed to mention this but it's for that to hopefully go in the next
tutorial it is if we can but I think it's also up to upstream whether we can get those patches up
and whether we can get that chrome in patches as well which we don't have right now
so my question is this whole work so after you have a new procession so you'll log in
into the system one about the free login yeah so the question is this whole works once you have
us user session what about pre login I think that's a great question I think different systems take
different approaches I believe Windows at low is kind of a single system which is able to do both
sign in as well as application management credentials for applications right now we're starting
applications I believe there's actually an other talk about GDM and Pascal is in yes to listen to
I think if you what might prevent that if we want to integrate this work in pre login I think
a few challenges is for example when you when you're using a pesky we have store devices for
example we might already use your phone and we might link to your phone so if you're not logged in
for example you might not be able to use that link because that's presumably we can only access
that information after we we identify the user but other than that I don't know there's much
there's the problem of which origin the use but which app is making the requests web off when
we work at the main so I may have to make that make one up so it's an interesting question right
I think other people in the in the major channels in my our better answer than me
so one more time anyone yeah if you play for something you're all you're going to
in the truth in past the screen you're related to different levels of information
for perhaps or another. So the question is if I really if I present the fool you're
all or the origin of the requesting of the application of the of the pesky in the user prompt
and displaying to the user do I really need different permissions for applications so for
browsers and normal applications so do I really need a privilege and an unprivileged API that's a
good question and I think the answer we're going for is not strictly because we're not going
to be able to do that for long for our fest release we don't currently have a solution to
the questions that we need so that we can create an unprivileged API. I believe we will be
the first platform to launch without an unprivileged API and so I do suspect this had some
risk in that a lot of platforms they know about android macOS Windows 2 after access as far
as you know. I do believe there's a security trade off because users may the request may be
intercepted users may not necessarily know I think it's yeah I don't believe it's strictly
necessary yes but there's some trade off.