Okay. Thank you. So, my name is Jos van Dijk. Disclaimer, I work for a commercial company
called Ubico. So, maybe you've heard of Ubikis. Ubico produces those Ubikis. But I'm not
going to talk about Ubikis. I'm going to talk about a technology called FIDO. And many of
you will have seen the previous presentation that was about an application of FIDO. So, the
goal of this presentation is to move on to the next slide somehow. Yeah. To explain what FIDO
is. So, I give a quick introduction to FIDO. And then what you can use it for. And many people
will already have seen it. For example, authentication. But I'm going to talk about things
that are. So, authentication on the web primarily. I'm going to talk about things that are. That
FIDO can be used for that is not involving a web browser. And these things are less or
well known. So, I think it's interesting to have a look at the applications. And I'll give
examples of open source software that you can use today that are actually using FIDO to do things
that don't involve a browser. So, let me first explain about FIDO. So, FIDO is actually a set of
specifications. One is by the World Wide Web Consortium. That's about using it in a web
browser primarily. And the other one is using security keys. So, the tokens like this that are
typically in your key ring. This is called a roaming authenticator in FIDO. And the idea is
that you protect your private keys on a piece of hardware that has protection against extracting
key material. So, this protocol is called CTAP. And that's by different organizations called
FIDO Alliance. And so, this is specifically talking to authenticators like this one. So,
how does that work? So, I'm simplifying things because there's a lot of details that I don't
want to get into because that takes too much time. So, if we have some relying party. So,
let's first look at the web authentication part. So, using a web browser typically. So,
a relying party that will be typically a web server. And authentication works like many
authentication protocols. You use a challenge response mechanism where you use asymmetric
cryptography to sign a challenge. And then you do the verifier. So, the relying party can check
the signature. And if it works out, then you're authenticating. So, the idea is that these two
protocols, the web of N is basically used in a web setting. So, for example, the web server can
send a challenge to a browser. And then the browser uses the web of N API, which is simply a
JavaScript API to initiate the registration of a public key or authentication using that public
key. So, that's what web of N, that's in the web part. And then on the back end, your web browser
will communicate with a security key. So, this roaming authenticator. Just relaying that challenge,
asking the key to sign it. And then the response is passed on to the relying party and we'll
verify it. So, what's all the fuss with the pass keys and Fido and anti-fishing? Well, that's the
merit of Fido too. It has phishing protection. And that is because in this challenge, the web
browser can help you secure things by injecting the origin of the site that you are authenticating
with. So, this is included in the signature. So, if you end up at the phishing site, the
signature will match because it will have a different identifier for the better. So, this is
why Fido is phishing, protecting you against phishing. But actually, I'm not going to talk about
this use case. I'm going to talk about the right part of this image where we use CTAP to
communicate with an authenticator. So, these are all kinds of authenticators. So, yeah, I work for
a company that produces these authenticators, but it's an open standard. So, anyone can build a
security key. So, I'm using security key and roaming authenticator interchangeably, but these are
all security keys by different vendors. So, of course, my employer is there, but there's also
Feixion, for example, Google, Nitro key, Solo keys. And that's interesting because that's actually
also open source hardware. So, anyone can build a Solo key. The firmware is open source, everything.
Nitro key actually uses the same software base, a firmware base. So, these are all, anything I
talk about in this talk will work with any of these security keys. So, how does this protocol
work? So, I'm focusing on CTAP, the back end. So, talking to a authenticator. Well, the idea is
that first you have to register. So, registration is just to register your public key with this
verifier, this relying party, whoever it is. And then later you can use that public key for
authentication. So, there's two steps, registration, authentication. And so, in the registration
steps, so I'm not going to talk about all the details, but you just register your public key
with a relying party. And this is including something called the relying party ID. So, in
Web of N, this is the identifier of the web server. But in other applications, it can be
anything. But the idea is that it is included in any signature that you generate. And you set,
so you fix this relying party ID when you register. And later with authentication, this
relying party ID is included in the signature so you can, as a relying party, verify that it is
used for your application. So, you cannot use the same public key for some other application
with a different relying party ID. So, I'm not going into too much detail. Now, you might think,
well, I can do this stuff with PGP. I can do it with smart cards. So, what is different about
securities if you're not using it in a web browser? Well, actually, many of the things that I'm
talking about will also work with PGP or other technologies, although there are some specific
features that are not always included. And one of them is attestation. So, attestation means
that you can prove that some signature was generated with a security key. So, of course,
if you know that the public key is generated on a security key, then obviously that is the case.
But if you're dealing with someone that claims to have a security key but you're not sure,
you can actually verify it by this process called attestation. So, you can prove that someone uses,
let's say, a Google Titan key to generate the signature. So, this is what called attestation.
And there's a service hosted by the FIDO Alliance or the organization that actually produces those
specifications. And they host metadata. So, if you have a security key, it will have a unique
identifier. So, not unique for that particular Yubiqui but unique for the MAKA model. So,
any, let's say, any Titan key or any Facion key or any Yubiqui that is of a particular MAKA
model will have the same identifier. And in the specs, it says that at least 100,000 keys
need to use that same identifier if they are the same MAKA model. So, we can be sure that,
let's say, that the signature is generated by a Titan key. And that is also interesting. So,
attestation together with the metadata, they really add something to this process. So,
here's an example of the metadata. So, someone built a nice web view of the metadata. So,
you can look up things like, of course, who's the vendor of this Yubiqui or this security key.
But also, is it using protected hardware? And is it certified to a certain security web? So,
all these things you can actually use in, actually, yeah. So, I'm not going to do any demo. So,
I include all my demo slides for you to try yourself. So, we don't have time here. But,
I'm just leaving them in the slides so you can actually try. So, this is a way to extract
metadata. So, it's a bit technical. But, if you want to try it, please do. Then, about open source
software. So, Yubico publishes a FIDO library. And it's actually used by a lot of open source
projects. So, this is open source, although it's produced by Yubico. And, yeah, if you look at,
for example, GitHub and you look at all the projects that use this library, then there's
lots of interesting projects that do it. And that means that you can use a security key,
any security key by any vendor, using that software. And, yeah, what I'll do in this,
and the rest of the talk is give you some examples. But, because it's interesting that,
although FIDO was primarily intended to do authentication, you can actually do other
things. You can do encryption. You can do signing. And you can actually store things on the
YubiKey. So, I'll give an example of all these features. So, let's start with a very simple
example, like a pluggable authentication module. So, that's another open source library that is
included in many Linux distributions. And the idea is that you can...
...
you
Open source software, you can try it out yourself,
but let's give a practical example.
Let's say that you want to encrypt your hard disk.
You're on a Linux system, you're using a Lux,
and typically this is done using a password.
Instead of using a password, you can also use a security key,
a FIDO key, that instead of deriving some encryption key
from your password, it will derive the encryption key
from this extra key that is generated on your security key.
So this means that if you want to decrypt your hard disk,
you just need to insert your security key,
so this is what you have factor to get some extra confidence
that only you can decrypt that hard disk.
So worth looking at.
Then there's another extension called large blocks,
and this is for storing things on your security key.
So it doesn't have a lot of space,
but this is typically used for storing certificates.
So let's say you're using SSH,
and you use SSH with SSH certificates.
These are small files, and it's feasible to store them
on your security key.
So this is an extension that is not very often implemented
at the moment.
I think there are a couple of vendors
that actually implement this,
but it means that if you move to a different system
and you want to log in there,
you can actually take your security key
and extract both the public key and the certificates.
Of course, the private key stays on your key and your security key,
and then log into a remote server from there,
so everything is contained in the same security key.
Here's an example how you do this with the tools.
Do it yourself if you have a key that supports it.
Finally, last example about this attestation.
So if you generate an SSH key that is backed by a security key,
you can actually ask the security key to provide attestation.
So there's this extra parameter in SSH key gen
that will extract the attestation data, it is called,
that you can look up in the FIDO metadata service,
and this way you can prove that the signature was generated
by some security key, and you can look up exactly which one,
and you're certain that this is done with secure hardware.
Okay, you can try it out.
So, getting to a conclusion,
so I'm not saying you have to stop using PGP or anything,
but this is an alternative to doing things with secure hardware,
and the idea is now that since all the big vendors,
like Apple, Google, and Microsoft,
they've jumped on the FIDO bandwagon
so we can see a lot more support for FIDO in the future.
That means that a lot more people will own a FIDO security key.
For example, I already mentioned this morning,
if you have an Apple iOS device,
you can protect your Apple ID using a FIDO security key.
So it's built into iOS 16.3, I think.
So this means that it is a viable alternative
that's actually also a lot cheaper than many of the other hardware keys
that you can buy, like a smart card.
So I think for 20 or 30 barbs you can buy a FIDO security key,
whereas smart cards are usually,
especially if you consider all the middleware
and everything else that you need to get it working,
that can be a lot more expensive.
So, just a list of resources.
If you want to look up things, of course, you can also contact me.
I'll be here all day and happy to take questions if there are any.
Hi, I have a question about the attestation process
and open implementations of FIDO 2.
If you have an open implementation,
is it possible to get that certified with FIDO 2 Alliance?
My understanding is that in order to enable the people
to compile their own binaries to put on their own open keys,
is that possible or is it not?
Yes, so as a line party,
there's a certification process that you can use to test
if you are compatible with the FIDO standards.
So there's different certification programs.
The most heavy ones are for the actual security keys.
So there you have to actually do a lot of work to get it certified.
But there's also a self-certification toolkit, I think,
that you can use to see if you are compatible with FIDO standards.
So there's a lot of tests you can run against your own line party software.
Can you do something?
Yeah, yeah, yeah.
Any other questions?
What is publicly known about hardware tokens failure rates,
at least for popular models,
and how many identical devices would you enroll
for the most important things personally?
The question is, I think, two-fold.
First is about failure rates.
Actually, I don't know about failure rates,
but of course there's different ways to do user verification,
and I skipped over it a bit,
but to use a security key you need to either touch it
and sometimes also prove that you are using it.
And this is done typically with a pin or with a biometric.
So I don't think...
I've never seen a security key fail,
except when it's using biometrics,
because of course that is a less...
So every biometric has a false acceptance rate
and a false rejection rate.
And yeah, I don't know numbers,
but it differs with different vendors.
So I think Apple doesn't say anything
about their false acceptance rate, for example.
So I guess you just have to trust them,
and that is with many vendors.
Then this... I missed the second part of your question.
This...
Oh yeah, so already mentioned,
if you use your security key you have a problem,
so you want to have multiple public keys registered,
and how many, that depends on the relying party.
So some relying parties initially only allow you to register one,
so that's pretty useless, because if you lose that one,
then you're out of business.
So usually there are several,
and yeah, I think for example on an Apple iOS device
you can now register six,
but that's really depending on the line party.
So some have an infinite number,
so you can just register as many as you like,
but that's really depending on the relying party.
Okay, we've got time for our next question.
There is an IC hand here.
So I guess we have now a single point of failure
with the USB socket,
especially if we are travelling.
So are there any plans to have implementation
for the Bluetooth final standards?
So we don't...
We can still work if USB is broken,
maybe at the phone or whatever.
Give it a little quiet,
but I have trouble hearing the question.
Are there any plans for the Bluetooth support in the libraries?
Because when...
Especially let's see if I'm travelling,
I often have problems with USB sockets,
so I would have a single point of failure there.
So you're saying if you have problems with your USB sockets,
then you cannot use a key, so is there an alternative?
And I would prefer to have some Bluetooth fallback then.
And the FIDO standard also specifies FIDO over Bluetooth,
but I don't see it's only implemented on Windows
and Android but not on the Linux libraries.
Sorry, Bluetooth, yeah.
So Bluetooth support is not in this FIDO 2,
it only has USB and NFC.
No Bluetooth, but there may be an addition.
In the next version of CTAP,
there will be a way to...
And maybe you've seen it in Google Chrome.
You can generate a QR code so that you can use your phone.
So if you have enlisted your phone as an authenticator,
you can do it over Bluetooth Low Energy,
but the Bluetooth channel is only used for proximity.
It's not used to actually transfer anything.
For example, if you register a key,
your public key is not submitted over Bluetooth.
But that will be in the next version of CTAP.
Okay, thank you for the talk.
We are out of the time, so applause.
Thank you.