foreign
[Music]
good afternoon I am here to talk to you
today about webbleathan passkeys and you
the future of Authentication
who am I my name is William Brown I'm a
senior software engineer at Souza Labs I
primarily work on identity management
systems and ldap I am based in Brisbane
Australia which means that for our
International viewers I'm often not
online so the best way to get in contact
with me is via email which is
william.brown souza.com
so you may have heard about pass Keys
now they were announced last year by
Apple and they've been promised as a
replacement for passwords they're faster
to sign when in with and better and
normally when we have announcements like
this in Tech circles they tend to stay
within technology circles they don't
tend to escape from those areas however
we've even seen in Australia that our
mainstream media with the ABC News have
actually published their own articles
about pass keys and how Tech Giants want
to kill off and remove passwords so
the question becomes what are pass keys
and this is where things start to get a
little bit confusing and difficult for
us is that there is no clear definition
of what a pass key is
there being no real definition it
started with the fact that Apple
announced pass keys but didn't say what
they were it really started to appear
like a marketing term or just a friendly
way to describe you know web authen
credentials and authenticators and over
time this definition has evolved and has
actually created multiple different
meanings or understandings of what a
pass key is
so our first definition of what is a
pass key is all possible web authen
authenticators so this could be things
like your Uber key or Touch ID on your
Mac or your fingerprint sensor on your
phone or your Android phone
but to give you a demonstration of what
it looks like to use a pass key to
authenticate to a web service or a
website let's have a look at a demo
so here I have a website which accepts
pass keys and I'm a new user so I'm
going to register myself and I'm going
to register as everything open 2023 and
today I can spell correctly which is
lovely I'm going to begin my
registration and I am prompted to create
a pass key for the website my ubikey is
blinking and I'm now going to touch it
and I'm prompted to enter my PIN
I enter that PIN
I touch the key again and I've now
registered this UB key with this website
if I want to authenticate once again
click authenticate my key is blinking so
I touch it
I type in my PIN
touch it again and I've now
authenticated now if I was to take this
UB key and throw it to one of the many
people in our audience right now they
would not be able to use that key
because they don't have my pin only I
know it so it's not just possession it's
also that pin is unique to me
now let's
try out how this looks in a different
way with a different device so I've gone
over to Safari
and I'm going to
register a new user which is
the AV team is the best thank you
now uh I will now begin my registration
in Safari and I get a slightly different
prompt this time this time I'm prompted
to save a pass key and I'm prompted for
my fingerprint now I'm using a MacBook
Pro so I'm going to touch the
fingerprint reader it's going to
register that fingerprint
and I've now registered this credential
now let's say that I've gone out and
I've decided to go see my friend at
honest Rob and his car explodium and I
left my laptop at home and so I'm using
one of his totally legitimate laptops so
I want to authenticate so what I have
here with me is I've got my phone which
is also signed in with my Apple ID
I'm going to select to authenticate
and I'm going to pick other options
and I'm going to select use my iPhone
iPad or Android device which says user
from a device with a camera
select continue I'm going to open up the
camera app on my phone
scan that QR code
and right now I'm getting a sign in
prompt on my phone
and in a moment I'll be asked for
touching that and I wish which I'll
touch now
and once that touch is complete the
authentication is now completed on the
laptop which is really quite cool that I
can use my phone to authenticate in that
way
so
what did we just say how did that work
what just came together to allow me to
use these devices and authenticate in
that way
there are three parts in a web authen uh
operation you have the relying party
which is the web server or website which
is hosting that service
you have the client which is in this
case it doesn't mean Google the client
actually means your web browser that
could be Chrome Safari or something else
that has the capability of interacting
with these devices and then you have the
authenticator and this is the hardware
secure element or cryptographic
Authenticator
which you have in your possession and
you can interact with
and these come together and there is a
whole series of interactions which we
aren't going to get into the complete
nitty-gritty of today and all the exact
details of how this works but the
general overview is that within your web
browser you initiate an authentication
to the website which sends you back a
challenge
the challenge is then processed by the
client and then sent into the
authenticator the authenticator then you
creates a signature and that signature
is then sent back to your client your
web browser where it is then passed back
to relying party who validates that the
authenticator was legitimate
so at its core what we're talking about
here is web authen being a form of
public private key cryptography or
asymmetric key cryptography and this is
similar to
past attempts at cryptographic
authentication with things like PIV or
smart cards now
what happens is that we have a private
key stored in our authenticator and we
have some data that we wish to sign
that private key can sign that data and
create a signature
and that signature can be sent to our
relying party which has the public key
it can then validate that public key and
validate that signature sorry and assure
and is assured that only that private
key could have created that signature
however knowing just the public key and
given that data you cannot falsify or
fake that signature
this is really good because it means
that if the relying party is compromised
or exploited then the uh unlike a
password which has to be stored either
in plain text which is unfortunately all
too common or a hash which can then be
exploited in various ways
knowledge of the public key and its
exploit or publication
does not weaken the security of you the
user it doesn't have personal
identifying information and someone
can't go and then start impersonating
you so this is really good because it
means that private key really is yours
it really means you are who you say you
are and you are have a much stronger
level of authentication and security as
the user
so
the next question that I'm kind of
preempting about pass keys and web
authen here is are they multi-factor
because as Security Professionals and
Technology professionals we've been
recommending people to move to
multi-factor authentication for a long
time
and multi-factor authentication until
this point
has looked like a password combined with
something like a trtp or it has been a
password combined with our security Keys
once again
and these boil down to something we know
and something that we have
so how are we now taking this device
which was previously a single factor and
turning it into both something that we
know and have we are now making it the
sole multi-factor Authenticator
and how this works comes from that
element of the demo which I showed you
where that pin was requested
the browser actually contacts the device
over USB and in that request actually
sends the pin that you typed in into the
Authenticator
the authenticator validates that pin is
correct and if that pin is not correct
it will not proceed only if that pin is
correct will it proceed and then it
waits for interaction so I have to
physically touch the device if this was
malware or someone's remotely
controlling my computer they can't fake
that interaction on my machine I have to
be physically at the device and have
been the one who put in that PIN
this interaction and pin verification
are all embedded into the signed result
and that signature is then released so
we now have a cryptographic proof that I
have not only touched the device but
I've also am the one who interacted with
it so this is how we get a very strong
Assurance with web authen and pass keys
that it is not just someone in
possession of this device but it is me
or the owner of that device who is in
possession
this this is very similar with Touch ID
on machines that have it or your phone
is that when the request is sent into
the device the fingerprint is requested
on the device and you when you put your
fingerprint on the reader
the act of putting your finger on the
reader is not only the interaction that
is required to prevent malware but it is
also validating the Biometrics of your
fingerprint at that point depending on
the type of Hardware I know that with
Apple devices the fingerprint reader
isn't actually connect to your operating
system it's actually connected into the
secure Enclave so the fingerprint can't
be falsified by the operating system or
even captured and that fingerprint data
never leaves the device
these again these um data are embedded
in the user verification uh elements and
that signature is released
so
in that demo I did what looked a little
bit like a magic trick where the phone
authenticated me
and I think that this is one of the more
interesting parts of web authenia is
that until this point we've we've
generally thought about things like uber
keys or security Keys as being a single
device and the keys are stored within
that device
and you know not all devices can work
with with web orthan and there's a lot
of things that have improved with Fido
to make these single device credentials
be able to support pins and other things
but with my phone I
um
uh what Apple has done and what other
providers will do such as Google or
Microsoft is they are creating what is
called a Multi-Device credential and
that is where the private keys are
synchronized between your devices so in
my demo when I enrolled that device the
private key that was generated for this
website that was on my Mac was then
encrypted put into the iCloud keychain
and then only other devices in my
account can download decrypt that
private key and then use it and that is
how then my phone also had access to
that private key
to then perform that authentication so
when I scan that QR code what has
occurred is that the QR code has
prompted a Bluetooth low energy
connection to my phone which has then
allowed my phone to complete the rest of
the authentication and send the
necessary data and signatures back to
the browser
so because of this Multi-Device
credential nature that we've now started
to see from vendors which is very useful
for many people
is the second definition of what is a
pass key
and this is that pass keys are a
synchronized credential so this
definition became popular soon after the
Apple announcement of what past keys
were and this is still used by many
services today there are many websites
and services which still refer to pass
Keys as these synchronized credentials
as opposed to these single device
credentials like your UB key
so we've got these great credentials
they are cryptographic they're very
secure they can be synchronized they
might be stored they're generally stored
on a secure Enclave the next question is
can they be fished and this is really
important because phishing is one of
those attacks that's very endemic and it
has been the cause of many high-profile
breaches that you are likely aware of
and
we need to you know if we are going to
improve authentication we need to get
past phishing this is a a huge problem
today things like passwords and totp can
still be fished in real time and then
replayed immediately to the Target
website
so to understand phishing resistance in
web authen we need to come back to
our workflow and understand the
interactions that are occurring here
in fact the step That Matters to prevent
fishing within web authen and pass Keys
is at this stage here between the
collected client data from the browser
and how it is sent into the
Authenticator
the data that is sent into the
authenticator is actually taken from two
sources
the first source of data is this
credential request options this includes
the relying party identifier which is a
part of the DNS or the domain name of
the website that you are visiting so
this is what the relying party is
telling you that its domain name is
but the second part is the origin and
this origin is actually not collected
from the relying party it's collected
from our web browser so this means that
we have now in our collector client data
a true and realistic view of what the
user is seeing so it doesn't matter if
it's a a homonym attack or similar just
because it can trick a person we are
embedding the exact set of bytes of that
domain name into this collected client
data that will be signed
so these data are then uh hashed and
then sent into the authenticator which
will sign these as part of its
verification data and then these are
sent back to the relying party for
validation so to put this in
uh a theoretical attack scenario let's
say that I go to totally legitimate uh
Rob's honest cars website.com
which is trying to fish me for my
corporate account and I've fallen for
the email which happens to any of us we
are all human and I've gone to this
domain and I haven't noticed that it's
totally dodgy.com
as I've performed this signature the
signature and the origin that's in this
collected client data says totally
dodgy.com and I've signed that and
that's fine because if the website
that's trying to fish me forwards this
signature to the legitimate corporate
site it will check that signature and
say yes this really is Williams
authenticator but that domain name is
wrong so I'm going to refuse to allow
this authentication to proceed because
this is clearly a phishing attack and
that can actually be signaled and uh
used to determine if if there are
further indicators or compromise that
you need to follow up
and this is so important to to really
stress this that
web authenia is not able to be phished
because of these properties the relying
party ID must be part of the effective
domain or the origin of the website that
you're accessing the origin comes from
the browser not the relying party which
means that it's much harder to actually
tamper with
the signature contains both the origin
and relying party ID so we have a
cryptographic Assurance on the uh of
what the user is actually seeing and
accessing
and you know where this comes back to
that phishing thing is that those synced
credentials still do rely on the
security of the identity provider that
backs them so the security of a Yuba key
is about physical possession the
security of your Apple credentials is
about the security of your Apple ID
account password and second Factor Apple
do require 2fa for those credentials
other providers may or may not we don't
know
so this is great we've got these
unfishable credentials they're very
secure there's cryptographic auth it's
it's very easy to use
I want to start enrolling it well what
if I run out of keys how many sites can
this work with
so
we want to empower our users to be able
to use these keys without to with
Reckless abandon
and the answer is you can use this on an
infinite number of sites
but there is an asterisk here
the asterisks is a pretty big one
the way that we allow these credentials
to work with an infinite number of sites
happens at this stage when we first have
our browser initiate the authentication
from our relying party
and so what happens at this stage to
allow this infinite set of credentials
is that when we go to the brow when we
when our client says Hey I want to log
in as William
the relying party says okay cool here's
the list of credential IDs that William
has ever logged in with and these
credential IDs are this base64 blob and
these base64 blobs are actually an
encrypted blob and these encrypted blobs
are encrypted with the internal primary
key of your device and they are
encrypted with AES and if your
Authenticator
can decrypt that it now has the real
true private key in memory and can then
use that private key for cryptographic
operations such as web authen
now if you happen to have a different
Yuba key and it's not the one that
actually created those blobs
and you try to decrypt them the blob
will fail to decrypt and it will fail
it's hmac and the private key will not
be accessible meaning that you cannot
continue or Forge that now the
frequently Asked question at this point
is is this somehow less secure because
you are exposing these credential IDs
when someone prompts for a username and
the answer is no these are encrypted
with the as128 they are hmac so if
someone is able to decrypt these then we
have very significant problems in the
security of cryptography on the internet
as a whole
this style of key where the key is
ephemeral and
decrypted out of the internal primary
key is called a non-discoverable or a
non-resident key or internally a key
wrapped key
of course
the word non-discoverable here or
non-resident key implies the existence
of discoverable keys or resident keys
a resident key or a discoverable key is
a key that's stored inside the limited
storage of the device
and when you request a user from when
you request an authentication from a
website where you have this setup a
blank credential ID list will be
provided to you so in the presence of no
credential IDs
your authenticator goes okay well I now
need to discover which Keys could be
used here I haven't been given that list
I need to work it out it then
investigates which set of private Keys
it has and it matches up the relying
party ID with the private Keys it has
and then offers them as Choice choices
for the user to use
now of course because we are now storing
these within the device and we have that
storage available we can embed little
bits of metadata such as the user's
unique ID or the user's display name so
that we can present this to the user in
an authentication selection dialog
the problem here is that with many moles
of keys Unfortunately they support this
many credentials and this is a blank
slide because they don't support any so
there are some devices which can't store
data
some devices have very limited storage
they can only store eight resident keys
yubikes are support generally about 32.
some devices have near infinite storage
such as a laptop or a phone where the
storage of private of these private keys
and being discoverable or resident is
bound by the size of the nvme drive
within that machine
so this is really cools the the key
storage you know
can be infinite for some things which
means that we can store those usernames
and have that little bit of metadata for
making some of our workflows a little
bit nicer
but we also have a lot of key stories
that is finite 0 to 32 is the common
numbers and unfortunately as a relying
party you can't probe for that storage
capability before or during that request
you either can request it or you can't
and unfortunately some devices such as
ctap2 can never delete or change a key
and this has some very uh negative
impacts on
transgender or community members or
women because they may not be able to
update or change their personal
identifying information in these devices
without a very uh very weird and ex not
obvious user workflow that I only
learned about yesterday
but of course the problem is the bigger
problem there is of course you can't
delete a key so once you fill up your
storage that's it you you can't delete a
key that you no longer use
so unfortunately we have to assume right
now that we have finite and you know
Keys can't be deleted out of storage
which means that we can't really request
resident keys at the risk of damaging
people's security keys
this leads us however to our third
definition which has become more
recently popular and that is that people
Define pass Keys as resident keys now
for the reasons I've just described I
don't like this definition because while
resident Keys have some really fun
properties with username autocomplete
and discoverability and being able to
sit in your keychain and some other
things like that the problem is is that
by requesting them or forcing them
outside of just opportunistic existence
we do have potential harms against
people and I don't think that's okay
so great okay we've now talked about
these Keys how they're stored they're
secure they've got multi-factor that's
great how can I use these in my website
you know you're I I bet everyone at home
right now is just jumping up and down
with excitement and itching to go
wanting to use and deploy these
this is my obligatory warning
writing your own cryptographic code is
great fun and it's a really wonderful
educational experience if you want to
learn the internals of how cryptography
or security systems work please write
that code
but there is a big gap between writing
that code for Education and Fun to
production once you jump into production
there are many more risks and threats
and issues that you need to consider and
while it is possible to learn these
risks and what these considerations are
it is still a big gap and it is one that
you need to be aware of before you want
to make that leap
now I don't say this lightly I say this
is someone who has probably a problem
this is just a subset of my collection
of security Keys I've spent a lot of
time with um
this standard and this library and with
the co-authors of of the web authen rust
Library working on
this on web authen and there are many
gaps in this standard and I mean this
standard is 164 pages long and I've
probably read all of it the spec for web
authen is trying to solve many use cases
it's trying to solve all of these
different problems in one spec so if you
have if you have a narrow use case like
pass keys or I just want cryptographic
auth it can be hard to navigate through
this complex spec to find how to make
that secure use case exist Within These
164 pages
very prescriptive if you go sit down and
write your own implementation you'll
probably end up with a pretty good web
authen library but there are those gaps
and we do want to give the best secure
experience to our users so you do need
to be careful
some libraries as implemented represent
the spec as it is
which means that we need to as
developers and implementers guide those
libraries to make sure that we're aware
of those gaps and we fill them over or
plug them in
some libraries are built around use
cases and can actually wrap these up and
have solved some of these gaps but of
course it can be confusing with multiple
Parts definitions of what a pass key is
to know what they actually mean
so this isn't an exhaustive list of web
authen libraries this is just the few
that I was able to find in the last uh a
couple of days unfortunately I've been
very busy and had a lot of uh personal
things so I couldn't make a longer list
but for rust there is the web authen
rust Library which is a use case driven
library and has the parsky definition as
all possible authenticators
the python library is very much a a very
good well-written implementation and
follows the specification very exactly
and of course that means that we need to
you know be aware of some of the traps
like you know the examples list are
resident key or RK is required so we
need to change that to discouraged and
there's some issues around its user
verification handling in certain
scenarios so we need to set user
verification required as well to force
that secure multi-factor authentication
and the same is true of the Ruby Library
if your language wasn't mentioned here
and there is a very good chance it's not
the general rules are can you set
residency to discouraged or false we
can't force resident keys because of the
issues around key key permanency and key
deletion that I mentioned before so we
need to be able to set that
is user verification preferred handle
correctly now I didn't go over what the
bugs are here but use verification
preferred and discouraged are
effectively equivalent unless the
library has special security hardening
in it most libraries if if they don't
indicate that they have this and they
probably don't you must set user
verification required else your
multi-factor devices are actually single
Factor
if you have strict security requirements
such such as a Regulatory Compliance or
other things you will need attestation
attestation is not I'm not going to
cover it too much in this
um
but it's basically a certificate of
authenticity as to the manufacturer or
origin of your device and it allows you
to selectively enforce Which models or
brands or devices are used in your
relying party
and finally when you're selecting your
libraries don't let fighter
certification be a barrier to whether
you do or do not select a library
fighter certification represents
conformance to an API not a
representation of security or quality
so to summarize pass keys are a
self-contained multi-factor
Authenticator they can't be fished
the Biometrics and pins can't be
exfiltrated from the device they are
contained within they require physical
presence which helps to defeat malware
key residency can unfortunately cause
problems for our users who wish to
choose which authenticators they want to
use and bring
sharp edges in the web authen
specification means probably don't go
down to Bunnings and believe it's a DIY
job
the libraries are still evolving and
options that you as an implementer
choose to use in those libraries
probably need careful review and you
will need to be empowered to assess
things yourself and I hope that this
talk has done so for you
but finally pass keys are a secure and
easy way for users to authenticate as
well as yourself
so your homework
after this session is to go and
Implement pass keys for your own
websites
from what you have learned today now I
this assignment will be due by next
everything open and I will be reviewing
each website individually and of course
if you would like to submit early please
email me these
my name is William Brown and you can
contact me here thank you very much for
listening to this and if I have time I
am going to go through some questions
from the talk session yesterday do I
have time
I need a nod hello from the back yep got
time cool so uh what's happening right
now is just that I am actually having to
re-record the talk
um because I created some technical
chaos yesterday so yesterday when we had
more audience members in front of me
there were a number of questions that
were presented by them and I think they
were really good questions and I want to
repeat them so they are not lost for the
recording
one of the questions was how can I
prevent user enumeration I have a
website where if I try to log in with a
username and I get the credential ID
list back I know that that user now
exists if I log in with the user if I
attempt to log in with a username that
does not exist I get an empty credential
ID list so I know that that user does
not exist so the individual in question
believed that that was a reason to you
know use resonant keys and that is
arguably a reason
and
user enumeration
it was uh yesterday while I was
answering the question in my head I said
our user enumeration isn't a problem and
then in within the 60 seconds of
answering the question I realized that
it actually was a problem in certain
cases depending on metadata and privacy
so to prevent user enumeration
uh we we talked about this later and uh
what we came up with was that you could
actually take the username that was
being presented and use that to false
falsely generate credential IDs that
look legitimate uh in a stable and
repeatable way just to confuse attackers
so they do not know if the credential ID
is legitimate or not
um so we I will probably write up a blog
post on this and maybe extend webworth
and rs with this as a feature in the
future
do browsers warn you before you create a
resident key since I've just sat there
and talked about how sometimes resident
keys can cause problems for our security
keys do we get a warning before one is
created and the answer is no
as I understand it browsers do not warn
you before you create a resident key
and unfortunately without you know we
don't really have access to control the
Chrome or Safari user interfaces we need
to ask them to change their uis or
change the behavior of how things like
resident key preferred handles with
security keys for this really to become
a better user experience but it's also
just one of those problems which it's
very hard to communicate what the
challenges are with resident Keys even
within a text space let alone external
to attack space and you know if giving
users a secure and accessible method of
authentication is our Focus
we need to try and make that as easy as
possible and trying to communicate these
complex do you do not create a resident
key or not is not really something
that's going to help with this I've
already seen some very bad uis I have a
really good neighbor
and she's a lovely person she's an
accountant very intelligent
and you know obviously outside of tech
and I asked her to you know test the
same websites that I demonstrated with
her Android phone and it came up with
you would like to create a security key
please enroll your cryptographic
security key would you like to log in
and shoot a step back and just went whoa
okay you know I
I think I've just been hacked and
you know if we have problems with
communicating to people how to enroll
their device their devices in the first
place we're going to have much bigger
challenges we're trying to communicate
about the risks and positive the
positives and negatives of Resident Keys
basically on those devices to help them
make informed choices so this
communication is really difficult
a question that we 've been something
that was asked is so what are resident
Keys good for if they're problematic
then why are they used it all and when
could I use them so resident keys do
have good some good properties so
uh one of the properties that is really
good is that uh the way that the
synchronized devices work so say your
Apple iCloud or Android these are all
resonant keys because of the way that
those synchronization mechanisms work
um they could in theory synchronize a
internal shared primary key just the
same way that ubiques have built in but
they've chosen to synchronize the
resident Keys instead so key residency
can prompt for key synchronization on
these platforms so Apple will always
create a resident key no matter what you
ask for so that it enforces that they
are synchronized I believe that Android
may not actually create a synchronized
key in some cases but we've got to
choose do we brick devices or do we make
it so people just have to enroll their
two phones I don't you know what's the
more lasting harm versus the the benefit
um there are some other use cases where
the one of the use cases is username
Auto completion and the thing is I do
like yes it allows username Auto
completion through a thing called
conditional UI where you send the blank
credential ID list and the user is
prompted hey here are the credentials
just for this website which one would
you like to use and yeah it's a pretty
slick UI but
I don't think that justifies again the
possible harms that can happen from
preventing people being able to choose
devices they want to use
um
and the final uh option is things like
devices that are more offline or
disconnected so one of my home projects
is I actually want to make a web authen
NFC door unlock where you hold your key
up to the door and
because of the way that these Keys work
you would need that to be a resident key
for that kind of thing so resident Keys
would could be used a lot more in say
like a corporate environment where you
control and issue keys to someone and
that can have the resident keys on them
um
but you know there are those those
problems
but with your door unlock why does it
have to be resident can't you just send
the
3743 105 different credential IDs that
have previously been registered into the
device to try and authenticate the
answer is no
there is a limit to how many credential
IDs you can provide to a device
uh during an authentication request and
if you provide too many the devices will
have a little panic attack and not work
so you can't
just send it like this huge list of all
possible credential IDs and just pick
out which one that was used you have to
limit that down to the username of the
person and just send it exactly those
ones or you need to use the resonant
Keys as as mentioned
are software keys not in TPM or enclaves
a problem
now
uh
the answer to this one is a little bit
more complicated but I wish that I had
sparkly glittery hands at the moment
because the answer is it depends
at one end of our Spectrum we have
software keys and you know they are
still better than a password they are
still not going to be fished they don't
have those breach attacks or replay
attack threats that that we have from
you know disclosure of passwords or
password hashes so just having
cryptographic auth in those software
Keys is already a huge win for user
security over
you know passwords and trtp
but at the complete opposite end of this
spectrum we have strict regulations and
compliance for individuals businesses
High Assurance environments and here we
really probably do want Keys stored in
Secure enclaves or Hardware or at least
Hardware backed in some way
and because of this
um
uh entire Spectrum there's a number
there's a spectrum of controls that you
have the major one being attestation
which is again that validation and
certificate of authenticity of devices
so we really come so I'm not really
worried about software keys but there is
a spectrum of threat models that you
have to consider here
have you heard about insert favorite or
thing here
uh no I probably haven't when I went and
looked up insert person's favorite or
thing here okay cool but it doesn't mean
it's widespread or used
um and that's really the problem is that
you know it's one thing to have your
favorite new or thing it's another thing
for it to be widely deployed and
embraced and in people's hands and right
now web authen may not be perfect but
it's in people's hands and so we should
use it
you keep saying at a station what is
that all right this is like the third
time
so let's actually explain it
it is the official Nintendo seal of
quality what it is is that when you
register your key it is sent it is
signed along with a certificate that
says this is a signature from the
manufacturer's CA signing key that says
yes this actually is a Yuba key and it
is exactly this model and it has exactly
these properties or you get something
like a fashion key and it will have the
phase and signed one that says hey this
is a fashion key is a fashion E-Pass it
does this it does this
as a relying party you can specify which
Cas you trust and which individual
device models you trust or want to use
based on your requirements
this is what attestation is there are
very few web or thin libraries that
support this so if you need attestation
you will probably have to do a fair bit
of legwork to make it happen web orthane
RS is probably the closest to having a
production viable public version of
attestation available for you to use and
what this lets you do is
you can say okay we have tested and
asserted that ubiques are really good
and Nitro keys are really bad which by
the way they actually are don't buy
Nitro Keys
um
we can assert that only these keys are
used when they when users register and
now we know they have to have at least
these security properties
the caveat without a station is that
there are some devices which if you
request attestation will not provide a
credential at all when they go to
register or will not provide an
attestation certificate so you have to
reject these
um or it could absolutely prevent um
people from registering those devices so
you also still need to be careful with
this
I do use case
I have no idea I'm I am not the font of
all auth vendor product features so
unfortunately
uh you will probably need to go and
check some of this yourself and I hope
that some of the topics of this talk
have helped you understand what some of
these settings like attestation
and user verification and key residency
actually mean
so once again
thank you for sticking with the the set
of questions that have been asked from
yesterday's users I really appreciate
you watching the talk and again I really
appreciate a big thank you to the AV
crew who have given up their lunch break
to re-record this talk with me thank you
very much for their patience as well and
big shout outs to my co-contributor
Michael Farrell who has been a wonderful
support and contributor to the web
authen space and helping me out a lot
with this so if you have any questions
please email me at william.brown
souza.com thank you