>>Erfan Ibrahim: Good morning.
This is Erfan Ibrahim Ibrahim of the National
Renewable Energy Lab
live here in Golden, Colorado.
I'd like to welcome all of you to this new
webinar for the
Smart Grid Educational Series.
Today we have the privilege of having Arshad
Noor
who's the founder and the chief technolo-
[inaudible] and also a member of the, how
do you
say this, Arshad?
Is it FIDO or F-I-D-O?
>>Arshad Noor: FIDO.
>>Erfan Ibrahim: FIDO, okay.
The FIDO Alliance where we are going to see
an alternative
approach to securing data with encryption
but a different way than the method of PKI.
And, this is going to be very interesting.
Let me give you a little background on why
this
is so timely.
So there is a paradigm shift happening in
our world with the digital economy.
We started
out with highly concentrated IT systems.
When I say "concentrated," I mean physically
confined like in data centers, and then relatively
dumb connections to other places where
there was a lot of intelligence.
So in those kinds of situations the security
was much
easier to do.
Now that we are moving into an environment
with distributed intelligence
where assets are becoming smarter and smarter,
farther and farther out of these data
center-like places, key management for encryption
is becoming very difficult.
And why
do we need encryption?
Because there are certain pieces of data that
are deemed
confidential because of privacy issues, or
other issues that involve national security
for
instance.
So we're moving away from this highly centralized
paradigm to this distributed model.
Key management is becoming very difficult,
yet the need for encryption is there.
So there
has to be some disruptive methods of key management.
So, with that background I'm
going to give it to Arshad who's going to
tell us about the alliance and what the value
add
is of the work they have done, as well as
some examples of what StrongAuth is doing
this
in space.
Arshad, the floor is yours.
>>Arshad Noor: Thank you very much, Erfan.
Good morning everybody.
Good morning, good
afternoon, good evening.
Wherever you are, thank you very much for
having joined us
today.
I hope to give you some very useful information
over the next 50 minutes.
And
then I believe we have at least a half hour
for question and answer.
So I will make sure
that we have adequate time.
And if we don't, then you have my contact
information to
send me additional questions, which I will
eventually forward to Erfan.
What I'm going to talk about today, so before
we get started, let me introduce myself.
So,
as Erfan mentioned I am the founder and CTO
of StrongAuth.
I have been working at
StrongAuth for more than 15 years.
But if you look at my background, I have been
in the
information technology arena for more than
30 years in various roles as a software
developer, systems administrator, operations
person, architect, project manager managing
very large projects.
And for the last 17 years I have been spending
my time focused on
public key cartography and photographic key
management.
It started off in the arena of public key
infrastructure, PKI.
But it also got me into
symmetry key management, but coming back full
circle, public key cartography has
come back as the main stream technology through
FIDO Alliance which is what I'm
going to be focused on for the next 45-50
minutes.
I've been a member for FIDO Alliance for the
last three years, but as you will gather,
the
background and experience that I have goes
significantly further behind much older than
FID Alliance.
And I hope to bring that knowledge and expertise
to this webinar today.
So, what is the FIDO Alliance and who is the
FIDO Alliance?
It's a nonprofit standard
group.
It was started about three or four years ago
by a few companies in the Bay Area,
Silicon Valley Bay Area, but today it has
more than 250 members worldwide with more
joining every week, every month as they recognize
the value proposition of what FIDO
Alliance is doing.
There are companies that manufacture platforms.
There are financial
companies, government agencies, technology
companies.
There are insurance companies,
healthcare related companies.
There are so many different representatives
from the
industry, government and different sectors,
and I don't know if any energy companies
personally, but I'm pretty sure there are
representatives of the energy industry who
are
participating in the FIDO Alliance.
The links at the bottom actually will take
you to the
membership roster where you can learn for
yourself who they are.
Today, so the focus of FIDO Alliance is primarily
to standardize protocols for
authentication, strong authentication.
Erfan touched on encryption which is a functional
key management, but another capability of
cartographic key management is strong
authentication through the use of public and
private keys, and that is what I'm going to
focus on today.
So FIDO Alliance began life with the notion
of standardizing protocols for strong
authentication to develop simpler stronger
authentication than what we have today.
And
today in less than three or four years of
being in existence there are more than 250
certified products on the market, which you'll
find at the second link over there.
So, why was it necessary for FIDO to come
into creation?
I think every single one of us
who is on this webinar probably recognizes
the problems that we have with
authentication with systems.
The whole notion of password based authentication
or
shared secrets has been so outdated, and it
was invented back in the middle of the 20th
century and that it exists even today well
into the second decade of the 21st century.
In
my personal opinion a shame, a blemish on
the professionals who work in this industry.
There have been much better technologies in
existence over the last two or three decades,
but the right blend of capabilities and features
have not made them ubiquitous enough to
displace user ID passwords or shared secrets.
The business models of social networking companies
today also enable use ID passwords
to continue to live long past their useful
life and that is something that is slowly
changing.
And we will talk about that.
The weakness of shared secrets, I mean almost
every technology that we use today, whether
it's user ID passwords, LDAP based
authentication, whether it's one time passcodes
passcodes that are generated out of little
devices that look like calculators or on your
smart phone, all of those are based on shared
secrets, and they have a fundamental weakness,
which is the serve or the website that
you're trying to authenticate to has those
secrets and you do.
But the fact that these
remote sites have those secrets creates a
huge target, which attracts attackers.
The failure of network based security- so
over the last 20-25 years I watched how many,
many applications that should have been secured
were not adequately secured simply
because people generally fall back on the
notion that yes, they have firewalls.
They have
malware detectors.
They have intrusion detectors.
All of these tools are designed to find
attackers that are on your network or deter
them from entering your network.
But what
they don't do is they don't protect the actual
sensitive data and they don't strongly
authenticate who's trying to get into your
network or you application system.
And in my
personal opinion that is a failure of many
of the technologies that exist out there today
in
the security industry.
Another big failure is client authentication
and PKI.
PKI is very, very powerful
technology, and I should know this because
I've architected them, designed them, built
them, programmed them for nearly two decades.
And as much as I've tried to enable and
make client authentication using PKI simpler,
faster, cheaper, it just has not established
efficient traction to become ubiquitous enough
that consumers can use it for very simple
use cases.
PKI federally is very necessary for server
site authentication and in small
segments of the economy we definitely use
PKI for client authentication, but it's not
ubiquitous enough.
Multi-factor authentication and two factor
authentication has been around for many years,
but unfortunately because of the plethora
of proprietary algorithms, protocols, devices
and capabilities and APIs, we've seen MFA
and 2FA balkanized, making it very difficult
for people who need to make decisions on which
particular MFA or 2FA technology they
should implement.
And, in the event the company or technology
that you choose to
implement federally gets bought or disappears,
it creates a problem because now you not
only have a technology that is defunct, but
you have a migration issue.
So, all of these problems have been festering
on the internet for many years, but it doesn't
stop there.
You also have failure of federated identity
models.
We have many federated
identity service providers, but most of them
are still based on shared secret based
authentication.
So even though the federation does add some
value to the process, the fact
that they still rely on shared secrets doesn't
eliminate the fundamental insecurity of the
technology.
One of the other issues that the industry
has also had to grapple with even if there
are
secure technologies available to authenticate
users, who bears this cost?
Is it the user?
Is
it the company that deploys this technology?
There are countries that have issued identity
cards, not in the United States of course,
but there are European countries, Asian
countries that have issued national ID cards
with digital certificates on them to enable
client authentication with, but that was funded
by tax payers.
And my personal, I don't
have any data on this, but anecdotal evidence
seems to suggest that they are not utilized
as effectively as they should be.
And this was through enormous tax payer funding.
So the economic cost of funding strong authentication
has also been a barrier to solving
the problem.
There is also a need for privacy and authentication
protocols because PKI as
strong as it is, it does not deliver the privacy
that one may hope for.
In a closed PKI that
is used primarily internally within the government
agency or an enterprise or an
ecosystem, yes, one might find some degree
of privacy there, but one cannot guarantee
that.
It is possible for an attacker to set up a
website and find a public digital certificate
of
a certification authority that issued the
certificate for the ecosystem and prop it
up on
their attack site and you're a user to their
site, so they will divulge their identity
to their
site simply because it will attempt a client
authentication protocol with the certificate
you
have.
Last but not least there is a need for solving
all these problems but to keep it simple.
And
as strong as some of the technologies are
today in the marketplace they are not as simple
or easy to use as user ID passwords and that's
what's holding all of them back.
So FIDO came on three or four years ago and
created a value proposition.
And the value
proposition is that with the protocols that
they have standardized there are no shared
secrets between the user and the site or the
resource that they are trying to access.
And in
my personal opinion this is probably the single
biggest benefit that you will get out of
public key cryptography.
This is not necessarily a unique benefit to
FIDO, but the fact
that FIDO has so many other benefits which
I will go through just adds icing to the cake.
But the most significant benefit of FIDO is
that there are no shared secrets and as a
result
it eliminates the target that attackers have.
Many attackers, I mean there are lots of reasons
why they attack sites and resources on
the internet, but one of the targets usually
is the password database of credentials because
it allows them to hopefully find passwords
that get them into other more valuable sites.
And that has always been a problem.
With FIDO technology there are no secrets
on the
server side or the website.
There is only a public key, and the public
key does not carry
any identification of which user this belongs
to.
I mean there may be a user name or an
identifier associated with it, but it doesn't
necessarily pinpoint which particular individual
that key belongs to, unlike a digital certificate.
FIDO was designed for the World Wide
Web environment.
I mean easy to see today that the web is so
engrained in our day to day
life.
Everything we do requires access to a browser
or to we protocols.
And the fact that
FIDO was designed to integrate with it and
work with it and even deter some of the
attacks that have spawned from the web is
an indication that FIDO is not just a
technology that following yesterday's problem,
but it is solving today's problems and
hopefully it will solve some of the future's
problems that are likely to appear.
It was designed with privacy.
As a principle the protocols do not carry
any information in
them that divulge any other key that you might
have or any other site that you might visit.
One of the interesting things about FIDO protocols
are that you can have a single
authenticator and generate unique key pairs
for each site that you register with.
Each site
has its own public key that it goes off, but
another site cannot discover any other public
key other than its own.
And as a result this is a very forward looking
benefit in my
opinion, another interesting quality to the
privacy benefit is that when FIDO
authenticators are married to biometric technology
whether the FIDO authenticator has a
fingerprint, iris scan, audio, anything at
all, the authenticators do not need to send
the
biometric template across the network to the
FIDO server.
The FIDO server has nothing
in the protocol that requires biometric information
to be transmitted from the user to the
website.
The site may specify that it requires a fingerprint
authentication or an iris recognition or
some form of biometric authentication in the
protocol, but even if the device has the
capability it is not required to send any
of that information.
So in my opinion, this is the
only standardized protocol that I know of
that can work with biometrics but not actually
transmit any biometric information to the
remote site.
It has two protocols that are currently standard
today, and there is a third one in the
works.
So depending on the economics and the business
use cases that you may have,
you have a choice of protocols to choose from.
And of course I already mentioned that
there are hundreds of certified implementations
available.
So depending on what type of
features that you're looking for and the capability
that you desire, the market already has
produced many options to choose from.
There is no need for a trusted third party.
Unlike PKI you can choose to store all of
the
public keys on your own site and manage them
internally for all of the applications that
you choose to enable within the enterprise
or agency or for the internet community.
However, FIDO does not preclude the possibility
of using a third party service provider
for managing those public keys and enabling
that capability.
So in my opinion it is going
to become one of the most pervasive authentication
technologies in the mobile world
simply because one of the founders of one
of the FIDO protocols which is Google also
happens to be the owner of the Android operating
system and when I last looked at some
industry estimates, IDC, one of the analysts
estimated that by 2019 1.53, one and a half
billion android phones are going to be out
there.
Now, Google has not, at least I haven't
found anything explicitly from Google that
indicates that they are going to embed FIDO
technology into the Android operating system,
but if you see the development of some of
these technologies that are coming out of
Google and if you watch some of the APIs that
are being made visible in the Android operating
system, it's very easy to recognize that
this is all moving towards FIDO technology.
So at some point the number one authentication
technology is going to be on your
android phone.
The barrier to enabling FIDO is very, very
low unlike other- I mean it's
never going to be as low as user ID password.
That's a given.
But, we all recognize the
user ID passwords are not a solution to a
problem.
In fact, they are the biggest problem
today.
And if we accept that strong authentication
is the minimum required barrier that
you need protect your information technology
infrastructure then FIDO is probably one
of the lowest cost solutions that you are
likely to find out there as an industry standard.
We have built a few FIDO applications already
in the last year, year and a half and in our
experience we believe a web develop who is
reasonably knowledgeable about FIDO can
enable a web application to be FIDO aware
in less than a week.
The first application is
always going to take a little bit of time.
But once the first and the second are done,
it's
almost certain that web applications can be
FIDO enabled in less than a week.
The interesting thing about FIDO is it is
not an either/or situation.
You don't have to
throw away anything you already have to enable
FIDO.
They can live right next to your
password based authentication, OTP, they can
even coexist with TLC ClientAuth.
And
you can choose a date and time and a place
when you want to turn off all of the legacy
authentication technologies and switch over
to FIDO.
The advantage is that you can
introduce FIDO immediately without breaking
any of the current authentication
technologies and slowly get user experience.
You can get feedback from the ecosystem
and you yourself can learn how it's helping
you.
So it's entirely possible to integrate
FIDO today without throwing out anything you
already have.
So, I've spoken about FIDO benefits so far.
Are there problems with FIDO?
As they say,
you can't make an omelet without breaking
eggs.
And similarly there are some issues
with FIDO in my opinion.
Three protocols is very confusing.
The standard organizations
generally like to have a single standard that
falls all business use cases and problems,
but
the ecosystem recognized there were some really
unique use cases that required two
separate protocols that FIDO Alliance will
form.
And there is a third protocol that is
being worked on right now but with the hope
that they will merge the capabilities of the
prior two protocols into the third one.
Unfortunately, the third protocol does not
yet show that it is going to be backwardly
compatible with the currently two standardized
protocols.
The single biggest question
that comes up in every FIDO conversation is,
is Apple fight off the FIDO alliance.
And
you will notice they are not.
If you look at the roster today on FIDO Alliance's
website
Apple is not part of the FIDO Alliance today.
But this does not necessarily mean that
they're ignoring it.
In my opinion I believe Apple, as innovative
as they are, as big as
they are, I do not believe Apple has sufficient
resources to out invent the collective
wisdom of the people who are participating
in FIDO ecosystem.
So, as good as Apple
technology is, my bet is that they are going
to eventually get onboard.
It's not likely to be
visible to the user because Apple has already
done a very good job of hiding user ID
passwords behind the fingerprint authenticator
that they enabled on the iPhone.
And
FIDO is most likely going to get enabled just
as easily and users are not going to see
anything different.
So even though Apple is not at the FIDO table
today, I don't think it's
a problem that will remain at the table for
too long.
Some of the other problems that I see with
FIDO is there's no current standard
mechanism for educating consumers.
There are so many different FIDO authenticators,
so many different ways to interact with FIDO
technology that there is no common thread
for how to educate users that they're using
one of the strongest protocols the industry
has
managed to cobble together to protect their
identity and authentication to a remote site.
And that in my opinion is going to slow things
down.
Another big problem is that FIDO Alliance
has not standardized on any particular way
to
identify that FIDO is being used on a device
or on your mobile device or computer.
If
you remember, SSL/TLS became very popular
because the ecosystem created a symbol
in the browser, the lock symbol that clearly
identified when you were going from an
insecure website to a secure session with
the remote site.
And that lock symbol is very
recognized by everybody in the industry.
Unfortunately FIDO does not have anything
similar.
There is a FIDO logo as you see at the top
of the screen, and that's handed out to
companies that have created FIDO certified
products but that's purely for marketing
material.
There is nothing in the protocol there is
nothing in the standard that actually
identifies to a human being that yes, I have
actually FIDO to authenticate myself.
And
that in my opinion is going to slow things
down a little bit.
Another big gap that I perceive is that there
is no standard for server site security.
FIDO
Alliance is very heavily invested in creating
security standard for authenticators.
They are
defining a certification program.
They are working with other industry associations
like
Global Platform.
They are working with organizations like the
underwriter lab to certify
authenticators and the technology that's being
used by human begins to protect the
cryptographic keys.
But, there is nothing in the standards that
mandate specific security
for servers.
So the ecosystem believes that these are features
that vendors must
implement and that will differentiate different
vendors.
While that's a good thing I think
there ought to be a minimum bar that every
server vendor should be required to meet.
So
hopefully that will happen.
But right now it does not exist.
So, let's talk a little bit about FIDO versus
PKI.
Now, I'm not going to compare FIDO
technology to any shared secret based authentication
system like user ID passwords or
LDAP authentication or one time passwords
because they're just not comparable.
The
closest technology that's in use today in
the industry that's comparable to FIDO is
PKI.
Here are the differences: FIDO protocols as
they are standardized they use [inaudible]
signature algorithm cryptographic keys.
These are relatively newer algorithms that
are
smaller and definitely very strong security
comparable to very large legacy keys which
are RSA keys.
And ECDSA keys also conform to some of these
recommendations that
are mandated by missed for federal agencies
as part of Suite B.
PKI on the other hand they can work with digital
signature algorithm, RSA as well as
ECDSA keys, so in that sense they are more
flexible.
FIDO technology can only be used
for client authentication.
Simply for client authentication.
There are use cases where the
digital signature the ClientAuth enables can
be used for more than just authentication.
But PKI digital certificates as people are
aware can be used not only for ClientAuth,
but
also to authenticate servers.
There are no digital certificates in FIDO,
just raw public
keys.
There is identification information in any
of those keys that identify a particular key
to a particular user.
Server vendors have to manage the relationship
between that public
key and its specific user on the server side.
And the protocols allow a specific user to
be
identified and all their public keys to be
identified by the server.
But PKI as we know,
they rely upon digital certificates and all
of the technologies that are associated with
digital certificates, certification authorities,
chains, and all of the complexity that goes
with PKI.
In FIDO technology every key player is completely
independent of the other and every
relying party.
So, a website in FIDO [inaudible] is also
known as a line party.
So line parties
can manage all of their public keys by themselves
or they can delegate the responsibility
to a third service provide.
But there is no need to trust a third party
in a FIDO protocol.
FIDO was specifically designed for web applications,
but PKI had a life even before the
World Wide Web was invented.
They are heavily used in the World Wide Web
today
obviously.
But FIDO was specifically designed for protocols
that work over http.
FIDO
has privacy as a mandatory requirement it
the protocol so when you study the protocols
you will recognize that there is no information
about the user that is divulged that might
leak who they're associated with or what type
of website they are visiting or things like
that.
But digital certificates, anyone that finds
them, one knows that you can identify a
whole lot of things about the digital certificates
and depending on the makeup of the
certificate you may be able to identify many
business capabilities also as part of the
digital certificate.
So in FIDO technology the trust between the
user and the FIDO server or the remote site
is established at individual keys, but in
PKI, the model is a little different.
The trust is
established and enabled at the certification
authority level.
The issuer of the digital
certificate.
And through that certification authority the
trust in [inaudible] client certificate is
established.
But, what is not possible in PKI is the ability
to determine what a user is
authorized just by looking at the user's digital
certificate.
You have to being with the
chain and only when you trust the chains you
can determine whether you trust the user
and once you've identified the user you can
establish what they are authorized to do.
It's
a very complex process.
Whereas with FIDO the unique key of the user
immediately identifies whether you trust
them or not and the authorization and then
they determine or granted at that level.
FIDO has something called a metadata service
that is analogues to using the server
certification revocation list that identifies
certificates that are revoked.
In the case of the
metadata service there is a possibility that
a specific key may be compromised or a
particular authenticator model may have a
weakness or a vulnerability that has been
compromised and now the manufacturer may want
to notify all users of that particular
key or website that rely upon the particular
authenticator that this particular model is
not
as secure as they thought.
So the metadata service does allow line parties
to disable the use of certain types of
authenticators or keys in the protocol.
PKI uses certificate levication lists for
individual
users as well as certification authorities
to prevent them from being used.
OCSP is the
online certificate status protocol that does
the same thing that CRLs do but are more
dynamic.
FIDO authenticators have been built that work
over USB ports, Bluetooth, low energy,
NFC protocols, and they're even embedded tokens
in mobile devices and laptops that are
starting to show up.
PKI technology, we are familiar with digital
certificates are available
as software certificates and files that are
generally imported into browsers but you can
also use digital certificates and keys in
smart cars and USB tokens.
There are embedded
tokens in certain devices that use digital
certificates too.
But in my personal opinion
FIDO hands down has a huge advantage over
PKI in this on respect because one of the
biggest challenges that I had seen my 17 years
of using digital certificates with smart card
is the complexity of the technologies stack
in making them work and keeping it stable.
Support for a specific platforms is limited
whereas FIDO already works on the three
major platforms out there today which is Windows
OSX and Lenox as a matter of fact,
across a variety of protocols.
So, there are three protocols in FIDO, universal,
second
factor, universal authentication framework
and what is called FIDO 2.0.
We will talk
about that in a little more detail in the
next few slides.
In PKI you use protocols like
transport layer security, public key [inaudible]
sender, XML signature which is short form
known as DSig in the industry, and EML Encryption
which are standardized by the world
wide web consortium.
So these are some of the different types of
protocols that are in
use.
Although the use cases for DSig and XMLEncryption
are not necessarily for
authentication.
U2F, UAF, and FIDO 2.0 are designed primarily
for authenticating
human beings to sites but they also enable
the possibility of confirming business
transactions through the use of cryptography.
Whereas, DSig and XML Encryption are
capabilities that are unique to digital certificates,
the ability to create digital signatures
and documents that live long past the availability
of the digital certificate as well as to
encrypt content using industry standards.
So, both FIDO and PKI enabled client authentication.
Whether client authentication in
the FIDO world is a success is yet to be determined.
There are websites out there that are
already using FIDO technology.
Gmail, Github, Box.net� There are some companies
that are already using FIDO technology.
And the United Kingdom just last week
announced a national cyber security strategy
for their next five years where they have
specifically identified FIDO as one of the
enablers for their security strategy.
I believe
you'll find it on page 36 of their very large
document if you're interested.
PKI ClientAuth in my personal opinion except
for small use cases in some segments has
been a failure.
There was great promise for ClientAuth in
the industry 20 years ago.
And
this is the reason why StrongAuth as a company
was created which was to be able to
provide faster, cheaper, better ClientAuth
through digital certificates and smart cards,
but
that didn't work out.
But you stand around in the industry long
enough to see Strong
Authentication come back as FIDO and we believe
that FIDO is today the industry's best
hope of trying to replace shared secret authentication
with something strong
authentication.
So the big picture, how does FIDO work?
I'm not going to go into too much detail over
here, but users, human users may have one
of many FIDO authenticators.
The good thing
about FIDO is that you're not limited to how
many authenticators you need to have.
You
can have multiple authenticators that or just
start with particular application site, or
you
can have a single authenticator that are registered
to multiple applications at multiple
sites.
But as I already indicated, the privacy requirements
in FIDO ensure that one site
does not learn of any of the other sites that
you visit or any of the other public keys
you
have.
I'm specifically highlighting the indicators
for a specific protocol here U2F, but mobile
devices can also serve as authenticators and
laptops that have embedded authenticators
are also FIDO enabled devices.
Applications have to be FIDO enabled.
You cannot take a
web application out of the box and expect
to use FIDO technology with it.
Unless the
web application has been written to specifically
use FIDO technology.
Once the
application understands FIDO then yes, the
human being can use their FIDO
authenticator to work with the application
and almost always you're going to need a
FIDO data store in your infrastructure.
Whether that data store is embedded into your
application or whether it lives as a separate
component in your network as indicated on
the slide by our appliance, that is a choice
for implementers, for line parties and what
they want to do.
Overall this is the high level picture of
how FIDO works.
There's a slightly more
complex picture.
This is an example of a web application that
we created that primarily
use cases to encrypt files and documents and
escrow the encryption keys on our appliance
while being able to store the encrypted documents
in a cloud.
What is interesting about
this application is that we FIDO enabled it
and today you can use this application with
either user ID password, onetime passcodes
or with a FIDO authenticator.
This is just a screen that shows the FIDO
keys that a specific user has registered.
You'll
notice that there are three keys registered
to this one particular account here.
So the three
keys are most- they're not most likely, they
are most definitely on three separate
authenticators.
So it's entirely possible for a user to have
multiple authenticators with a
cryptographic key that is registered to a
particular application and use any one of
those
keys to authenticate to the application.
This is one of our most recent creations,
something that we call PKI to FIDO.
We
recognize that PKI as strong and powerful
as it is, it's an extraordinarily expensive
technology, very complex to build and maintain
and very expensive to build applications
to use PKI.
We believe that PKI is not going to disappear
anytime soon, but companies
are likely to find the security benefits and
the economic benefits of FIDO are going to
far
outweigh their sum cost in PKI and they are
likely to want to consider the possibility
of
using FIDO for strong authentication to web
applications.
PKI to FIDO allows such companies and government
agencies to use their existing smart
card or digital certificate credentials to
strongly authenticate them with CLS [inaudible],
validate
their certificate chain, identify them from
the internal PKI LDAP directory and one
strongly authenticated they can then register
a FIDO key in their enterprise or agency.
And once registered they can use it with any
FIDO enabled web application.
This is in the open force community.
We just released it last month.
More features on this
are coming down the road.
So let's talk a little bit about the protocols.
I'm not going to go into technical details,
just
very high level differentiators between the
protocols.
Universal second factor U2F is the
simplest of the three protocols.
One of the presumptions of U2F is that it's
intended to be
a second factor of authentication.
That is most likely going to supplement your
first [inaudible]
which is likely to be your user ID password
or shared secret based authentication at least
in the short to medium [inaudible].
But in the demonstration I'm going to show
you that you
can still use U2F as a passwordless authentication
scheme in specific use cases.
It was originally targeted for desktops and
web applications and it's currently supported
in at least three browsers today, but Microsoft
has clearly indicated that U2F is not going
to be available in internet explorer [inaudible]
of course has been silent on FIDO itself.
So, U2f
today will only work with three browsers.
But it can be programmed to work in a rich
client application too.
There is nothing in the protocol that says
that you cannot use it in a
rich client application.
You can, but you have to do a little more
work, the kind of work
that the browser manufacturers have already
done for you.
The actors in the U2f ecosystem is there is
the authenticator device.
This is a device that
actually, it's also for the token by the way.
The device is responsible for generating and
managing the key pairs on the device and it's
responsible for the digital signature.
One of
the requirements of FIDO is that there must
be a test of human presence.
If the device
cannot detect a human being being physically
in possession of the device and in front of
the computer that is attempting to authenticate
the human being to the remote website,
the authenticator will not work.
And this is a guarantee that it's buried in
the protocols
itself.
All three protocols that a test of human presence
must be proven by the
authenticator.
The transport for the protocol today for U2F
are the HID on USB, Bluetooth low energy
and NFC protocol.
So another actor in the authentication transaction
is the FIDO client.
This is software that interacts with the device.
And for most practical use cases it's going
to be the browser.
But there's nothing that prevents people from
writing rich client
applications as I've said that interact with
the device as well as the line party web
application, which is the third component
of the transaction.
So there has to be a web
application that's responsible for carrying
the messages back and forth between the
authenticator as well as the remote site.
And last but not least is the FIDO server.
Now this is responsible for the interaction
with
the device through the browser and the web
application.
It can be standalone or as I've
indicated it can be part of the web application
itself.
So, a picture that highlights the
different actors in the U2F transaction.
It's not very different from what I showed
earlier.
The actions that you can perform with a U2F
protocol you can register a new key pair
with a particular site, and you can authenticate
yourself by digitally signing a challenge
supplied by the web application.
As long as you're using the same top level
domain plus
one as the specification calls it, so for
example, StrongAuth.com may have many
applications that say CRM.StrongAuth.com or
[inaudible].StrongAuth.com, as long as it's
the
same top level domain plus one, the demographic
key can be used to do a single sign on
across multiple applications in the top level
domain using this protocol.
I've highlighted two capabilities that are
enabled in our server, but are not part of
the
standard specification, which is the ability
to delete a key pair which the FIDO Alliance
called Deregistration.
And the ability to authorize a particular
business transaction
through a digital signature from a derived
challenge, and a challenge is derived from
information in the business transaction.
Now, the specification does not talk about
these at all, but there is nothing that says
you
cannot use the capability of U2F to enable
this.
Universal authentication framework on
the other hand was designed to replace user
ID password.
It presumes it might presume
that you are authenticated with some shared
secret, but it doesn't have to be.
And the
intent is to essentially replace all shared
secrets in 1FA's a UF authenticator.
Two unique
features that are unique to UAF is that there
has to be a secured display.
This is optional
of course, but the protocol supports it.
U2F does not require a secure display on the
device and for transaction confirmation.
So this is part of the protocol too.
It was originally targeted for native mobile
applications, but just like any protocol if
you're willing to invest time and energy you
can certainly build rich client applications
on the desktop with it, although I don't know
of any personally.
It's not currently
supported by any browsers that I know of,
but there are third party licenses and venders
who support UAF on many different platforms,
including Apple's IOS.
So the market is
certainly delivering the capability.
One interesting feature of UAF is that relying
parties may be able to specific policies
about when they are willing to accept authentication
from a human user.
Some examples
are that the human user must be in a specific
location that maybe transmitted through
GPS coordinates that they must authenticate
between specific time window or that they
must have certain biometric capabilities on
the authenticator.
So in that respect there is a
richer set of capabilities in UAF than in
U2F but in the end it comes back to the same
challenge response with a digital signature
capability.
When we talk about the third
protocol you will find out that U2F, the third,
we'll talk about it in a minute.
So, the actors in the UAF authentication transaction
are the authenticator itself and
something called an authenticator specific
module, because authenticators are built on
different types of devices and embedded in
the devices is necessarily for the device
to
expose an API that can be used by library
vendors or application developers who can
communicate with the unique device through
a standardized API.
And FIDO calls this an
ASM, and this is available as a standard.
There is a FIDO client which is usually an
application on the device and it is usually
a
library that abstracts all of the FIDO operations
so that application developers don't
necessarily have to go down to that level.
The relying party web application is another
component as well as the FIDO server.
So
those components remain the same in UAF too.
FIDO metadata is necessary.
It's defined
for UAF.
It's not currently defined for U2F, although
the technical working group is
working on it.
But today the FIDO metadata service is available
and well-defined in the
UAF protocol.
There is only a single provider that I know
of today that provides the
metadata service, which is the FIDO Alliance
itself.
But there is nothing to prevent third
parties from offering the capability should
they need it.
Relying parties may choose to ignore the metadata
service if they decide that they are
willing to work with a manufacturer and trust
only that manufacturer and no other device,
then in which they don't need to integrate
with the metadata service if they decide not
to.
The capabilities that UAF enables are similar.
You can register with the website with a
key pair, a new key pair.
You can authenticate yourself to the site.
And deregistration is
well-defined in UAF as is secured transaction
confirmation through the secured display.
So these are unique capabilities of UAF that
are well-defined.
The third protocol is still a work in progress,
FIDO 2.0.
The link gives you or takes you
to a website that identifies the vast version
of the protocol as it is today.
FIDO Alliance
decided that they will hand it over to the
W3C Worldwide Web Consortium for the next
stage of standardization so that it could
be adopted by browser manufacturers.
I have read
of three announcements from Mozilla, Google
and Microsoft where they have publically
announced support for this new protocol.
It's called Web Authentication in the W3C
world, not FIDO 2.0 So the fact that I'm calling
it FIDO 2.0 is only unique to FIDO
Alliance.
In the W3C it's known as web authentication.
They are starting work on
implementing the capability.
I believe Microsoft has even blogged some
demonstrations
of this capability using the Microsoft edge
browser.
Mozilla and Google have just recently announced
their intent to start developing the
capability.
When are they going to finalize this?
I have no idea, but 2017 is a good bet.
What are the capabilities of FIDO 2.0?
The conceptual goal is to merge the capabilities
of
U2F and UAF into FIDO 2.0 or web authentication.
So you will see elements of both the
U2F and UAF in web authentication but what
you will not see is backward capability in
the protocol, at least I haven't seen it yet.
Whether it will get standardized at some point
in the future is just a guess on my part.
So, if you are thinking of deploying FIDO
whether it's for a pilot or it's for full
scale
implementation, some of the choices, deployment
decisions you have to make are what
protocol you want to use, what type of authenticators,
which platform do you wish to
support?
For example, if you are only using internet
explorer today and there is no way
you can get off of internet explorer, then
that limits your ability to start using FIDO.
That's what I mean by platform and operating
systems, which FIDO server and do you
choose to build your own or buy a third party
FIDO server?
All of these decisions are
something you have to think about.
FIDO security.
So one of the things you have to think about
is the security of FIDO
authenticators and servers itself.
The protocol itself as far as I can tell is
secure and I
haven't read anything anywhere on the internet
yet that seems to declare that there are
vulnerabilities in the protocol but there
are implementation things that one has to
worry
about.
Key handle is something that a FIDO authenticator
sends to the FIDO server
during registration.
It is an object and a fake object.
It may contain a private key that is
encrypted by the authenticator manufacturer.
If it does contain a private key, in the key
handle, then you have to worry about the security
of the key encrypting key on the
authenticator.
Other implementers may choose not to send
the private key at all, keeping them in the
authenticator then it may not matter, but
that is something you have to understand.
Now
the security certification that FIDO Alliance
is working on is likely to identify this in
one
of the levels that they assigned to authenticators.
But for now you are going to have to
think about that.
Another security feature you have to think
about is the protection of the private key
for an
attestation certificate.
So, even though this is a PKI artifact, it
is an object that is on every
authenticator key pair and a digital certificate
ingested by the manufacturer of the device
that attests to the authenticity of the keys
generated on the device as well as the
manufacturer of the device.
So you have to- FIDO has a mandate that every
100,000 authenticators must have the
same key pair and certificate.
This is for the privacy protection so that
no single user can
be identified based on the attestation certificate.
There are at least 100,000 possibilities.
But the security of that private key is important
because if that private key on the device
is compromised, then an attacker can certainly
use the private key to create a [inaudible]
token
and then masquerade it as anyone they want
indicating that they are coming from an
authentic device.
Then there is a potential attack on the server
site that I call a substitution of keys attack.
So imagine if on the server in the database
you have two users, Jack and Jill.
They're
registered their keys and one of them has
their unique public keys as you can tell from
the
image there as well unique key handles.
But now imagine that an insider has substituted
Jill's key handle and public key with Jack's
key handle and public key.
What this allows,
enables is that the attacker can now use Jack's
authenticator and log in as Jill because the
protocol doesn't identify the user inside
the actual message.
It identifies the user based on
what the browser tells the web application,
but the message that is sent by the
authenticator has no identification about
the user.
As a result the key handle is the
identifier to the authenticator.
So if the database can substitute key handles,
then it is
possible for Jack through and insider attack
on the database of FIDO's keys to use his
public key and his key handle to take over
somebody's account.
Now, there is a mitigator to this particular
attack which is a digital signature on this
record.
Obviously a digital signature on Jack and
Jill's record would be broken if any
object was modified outside of the application
that created the digital signature.
But that
is not a mandate from FIDO Alliance.
These are capabilities that when there is
must
choose to support in their server if they
want to protect you from something like this.
So, what are the things that you need to do
about enabling FIDO in your ecosystem?
Well, you have to pick an application.
It can be any web application of your choice,
something simple is obviously ideal.
You need an account recovery mechanism.
What
this means is it's possible for users to lose
their FIDO authenticators.
It's possible for
them to forget it at home and then the question
is how did they get back into the
application without the authenticator?
Pick a few authenticators, pick a server,
get the
capability, documentation from the manufacturer
of the server and start recording work.
The first application is going to take the
web developer a few weeks, but that's it.
Once
it's done it's just a question of testing
the user flow and the account recovery process.
And then that's all there is to it.
Now, why does FIDO matter?
That was the tagline of the webinar.
StrongAuth's belief is
that while we have lots of security controls
out there that are two security controls that
are probably the most effective in any application
infrastructure.
One is application level
encryption that encrypts data and stores the
encrypted data in its database.
And the
second strong authentication, strongly identifying
a user.
The obvious advantages of
these two capabilities are that as long as
you're strongly authenticating a user before
they
can get into the application attackers outside,
inside your network and even inside the
computer that's running the application are
unlikely to be able to get to the data because
the application is expecting a digital signature
from the authentic user before it will
encrypt the data.
So it's entirely feasible for attackers to
be in your network and on the computer that's
hosting the application and yet be denied
access to the application or to the sensitive
data
in it.
It's a principle that we call ALESA.
It stands for application level encryption
plus
strong authentication.
You can learn a little more about it at that
URL.
And this is why we believe that FIDO is one
of the best technologies that has come out
of
the industry that delivers simpler but stronger
authentication capabilities as a standard
that's available today.
You don't have to wait for FIDO 2.0.
You can get started today
and start getting the benefits of this capability.
Lots of resources on the internet.
All of these are links and this presentation
is going to be
available to Erfan immediately after this
webinar is finished.
I'm going to take just two
minutes to demonstrate very quickly a FIDO
demo.
So there is an application that we have hosted
on the internet and going to create.
Now
I'm going to use the standard user ID password
to authenticate to this application.
Not
very strong authentication but this is a FIDO
enabled web application that does, that I
spoke about.
So the account recovery mechanism is two step
verification that we have enabled in the
application.
So I'm just going to use my email address
and send a onetime passcode that
will�688698.
And now that I have turned on my account recovery
mechanism I can add
a security key.
I register what you cannot see that I have
a U2F authenticator in my
computer and it has prompted me for my desktop
human presence.
As soon as I complied
with the request from the authenticator it
generated a unique key pair, and there it
is.
As
you can tell it hasn't been used yet.
If I now log out and log back in as NREL
ABCD1234, you'll notice that the login is
now completely different.
At this point it is
mandatory that I have a FIDO authenticator
before I get in.
And if I do not supply the test
of human presence in the next 20 seconds it
will time out and I will be logged out.
However, if I have forgotten my token at home
or I've lost it, there is this user
verification code link that will allow me
to still get into the application as long
as I can
gain access to an account an email or my mobile
phone where it's likely 
to have come.
There I am.
I can also authenticate with a second key.
So I'm going to change the FIDO
authenticator on my laptop and add a second
key to my account.
Now that I've provided
my test of human presence you'll see that
I have two cryptographic keys there.
I also
promised you that I would show you 
a passwordless authentication� actually�
This one
just requires a user name and FIDO authentication.
That was an example of passwordless authentication
using a FIDO authenticator.
I would
recommend that this type of capability be
used on internets where it's passwordless
but
maintain the second factor capability with
user ID password and FIDO on the internet
site.
So at this point I'm going to stop and hand
it back to Erfan to continue with the webinar.
Erfan?
Hello?
>>Erfan Ibrahim: Yes.
I'm back.
I had you on mute so that our background won't
come in your
presentation.
So I appreciate this very informative presentation.
We have a set of
questions that have been coming in while you
were speaking.
So at this time I'm going to
bring up those questions and we can have a
little bit of a Q&A. let's see here.
I'm just bringing up the questions now.
Here we go.
So let's start the first question is
from Bill Cox and Bill is talking about this
proprietary label on your slide.
So he was
asking if it is possible to get this when
you send me the PDF version to remove that.
Is
that possible to do that?
>>Arshad Noor: Absolutely.
>>Erfan Ibrahim: Okay, very good.
And then second is Michael Shea asked what
kind of half-life
has it been for the respected authentication
mechanisms known today?
What kind of half-
life would be expected out of the scheme proposed
by FIDO?
>>Arshad Noor: That's a very good question.
I don't believe I have seen any research on
this
particular topic.
But if we take a look at the life of certain
technologies that have been in
existence, I mean we're still using user ID
passwords, 50 60 years after they've been
around.
Obviously they were compromised way before
this and various technologies
have shown up in between that were also compromised
very, very quickly.
But there was
a paper that I wrote almost a decade ago and
I'm happy to send you the URL to that
paper Erfan.
It was called Identity Protection Factor.
While it did not discuss half-lives as
the questioner asked, what I did was I tried
to collapse different types of authentication
technologies based on their one letter ability
to attack and came up with an arbitrary scale
from zero to ten on their ability to deter
attacks.
The paper is published in the ACM Journal.
I forget the year in which it was published,
2007 or 2008.
And, all shared secret authentication is,
I identify it as a level two.
That's
how weak they are.
PKI with smart cards, I identified it as level
six in that scale.
FIDO is
similarly at that same level simply because
they are using public cryptography.
They are
using authenticators.
However, they are not necessarily impervious
to attack.
The
vulnerable key points which I've identified
are the key handles, the attestation certificate
private key, and of course larger scale attacks
such as on the elliptic curve itself.
Authenticator manufacturer facilities, so
there are all kinds of potential vulnerabilities
even in this ecosystem.
But FIDO Alliance in my opinion is trying
to address all of them through a security
certification program.
And the security certification levels will
identify all of the different
types of vulnerabilities that they have addressed
and tested.
And manufacturers may
choose to submit their technology for such
certification.
All it can do is give you a certain
level of assurance as you all know, but I
cannot predict how long this technology will
remain impervious to attack.
>>Erfan Ibrahim: So one thing that impressed
me about the FIDO approach is the light footprint
and the ease of management, especially when
you're dealing with a lot of people with
different profiles and different needs to
access data.
So I think that is really good,
especially I'm thinking in the energy sector
when we're increasingly moving to a
workforce that is relying on smart phones
to access information especially around
substations and when they go out on fieldtrips.
And it's very good if they are web based
applications that they can use for their day
to day stuff where they can be authenticated
and quickly get to only the information that
they need and not just freely roam around.
So
I think that this is a very good step forward
in that direction.
>>Arshad Noor: I completely agree Erfan.
But there are lots of other very interesting
use cases
that we have already started thinking about.
Simply just getting transaction signatures
for
every business transaction out there, it's
as simple just touching a token or speaking
a
voice command or swiping a finger on your
phone or device without having to pull out
a
smart card and insert into it a smart card
reader or remember a pin number.
So I
anticipate that applications are going to
get far richer in terms of the security capabilities
that they will start offering.
FIDO makes it easy, definitely makes it easier.
>>Erfan Ibrahim: So Bill Cox asks another
question.
He says, "I see many draft specifications
that claim that identification and authentication
can be combined into one special card.
How does that fit into the lack of ubiquitous
client site PKI?
The issue is authentication
and identification of individual users to
provider relatively inexpensive services."
>>Arshad Noor: So identification is something
that I do not believe any technology protocol
can address.
This is something that human processes have
to address through whatever
business mechanisms that are acceptable to
them because every business has its own
degree of risks that it needs to manage.
But once you've identified a human being it
is
possible to give them an authenticator and
create a credential that you can trust on
the
internet.
There are authenticators that are available
for as little as $10 on Amazon and
eBay and they will not identify the human
being.
All they will tell you is that there was a
human being in front of the device and the
computer when they were authenticating to
the website.
And they will carry that proof in the protocol.
But there are authenticators that are available
for $150 that will actually do a 3D
ultrasound scan of your finger, not just your
finger print, but even your bones, your blood
vessels and the tissue material in your finger
before they will eliminate a key pair or
work.
So it's entirely possible to have authenticators
that can range from zero
identification to very, very strong identification
before you use the authentication
protocol.
And this is what I meant when I said companies
are going to have to pick
whatever authenticators that are necessary
for their businesses.
And every business is
likely to have different use cases where in
many cases a simple $10-$15 authenticator
may be good enough.
But there are certain transactions where you
may be willing to
spend $100 for an authenticator because it
is critical enough, important enough and a
user
base that is small enough that it is well
worth the money to address that risk.
>>Erfan Ibrahim: Okay, so we just have eight
or nine minutes and we have a few questions.
So
we'll try to go through them more quickly.
The next question is from Bill Cox who asks,
"Does FIDO act as an additional factor in
an existing multifactor authentication or
should
FIDO be primary?"
>>Arshad Noor: So, depending on the protocol
you can do anything you want.
U2F was
designed to be an additional factor, but as
I demonstrated you can also use it as your
primary authenticator as long as you're willing
to do it only for internal applications.
UAF was designed to replace all other forms
of shared secret authentication as being a
primary authentication scheme.
FIDO 2.0 web authentication is also being
designed to be
the primary authentication scheme.
Now, the only thing you can compare FIDO to
if you're trying to use multiple
authentication protocols is PLS ClientAuth.
Everything else that I know of is based off
shared secrets and they are weaker than PLS
ClientAuth or FIDO.
So you would not
necessarily want to combine them a shared
secret mechanism with a strong authentication
mechanism.
But you can choose to do anything you want.
The PKI to FIDO capability that I described
in this picture 
actually combines PLS
ClientAuth and FIDO in the same application
and these are two strong authentication
protocols.
So it's entirely technically feasible.
>>Erfan Ibrahim: Okay, next just a reminder
to everyone that all the slides in PDF form
will be
shared with all the people who registered
as well as the webinar recording.
So not to
worry about that.
Next one is from Michael Richmond who says,
"Where do you see it
compared to the SQR authentication protocol?"
>>Arshad Noor: That's a very good question
Erfan.
Unfortunately I have not studied the SQRL
scheme so I must confess ignorance to that
protocol.
>>Erfan Ibrahim: Okay, so Arshad's email is
there.
You can hound him later.
>>Arshad Noor: I will promise to study that
up and have it answered.
>>Erfan Ibrahim: All right.
The next one I don't know why, I just see
Lance Bass, I don't know
what that means.
Okay, Judith Short asks, "What happens if
someone steals a person's
device?
Can a thief get access by virtue of possession?"
>>Arshad Noor: It depends.
If the authenticator does not have an authentic,
human
authentication capability on it, so for example
if it does not have any biometric capability
or pin protecting access to the private key,
then the possession the authenticator will
grant
you access to the private key.
But there are still two additional deterrents
to the attacker.
One, you don't know where the authenticator
was used.
There is absolutely nothing on
the authenticator that will divulge which
website has keys registered with a key from
this
authenticator.
Even if you knew the website you need to know
what user name was used
by that user to register a key.
So there are two additional barriers, even
if there's no
biometric authentication locally on the device.
So, losing a key is not- I'm sorry do you
have�?
>>Erfan Ibrahim: Yeah, Arshad, I was just
going to ask, what if that's cached on the
browser?
>>Arshad Noor: No, that will not be cached
on the browser because the way the protocol
is
written, the username yes, it can be cached
on the browser, but then you're now making
the assumption that the attacker has access
to the user's browser, user's authenticator
as
well as knowledge of which website they are
using.
So here is where you have to decide
what is the risk.
If it's to an application that has very sensitive
information, corporate
information, then you are likely to want to
choose authenticators that have some local
authentication capability, whether it's a
biometric capability or whether it's a user
pin to
protect access.
So that becomes and additional deterrent.
But, remember once a user notices that they've
lost their authenticator they can always go
back through they account recovery mechanism
they can go and delete the public key in
the application and that permanently renders
the authenticator useless for that particular
website, even though the attacker has the
private key, they will not be able to use
it
against a website that has no knowledge the
public key from that authenticator.
>>Erfan Ibrahim: All right, Michael Shea asks,
"How much effort would be required to report
the
legacy applications to migrate them to use
FIDO scheme?"
>>Arshad Noor: That will depend a lot on the
legacy application, Michael, because there
are so
many different web technologies, frameworks
and ways in which web application has
been written.
It would be impossible for me to have sort
of guess the one week
guestimate that I came up with was based on
a GSC or angular two type of web
application or JSF, Java Shop, so we tend
to be more on the Java side.
But I imagine
similar capabilities exist on other frameworks.
But the Java Script is not very
complicated.
The specifications identify the entire Java
Script specifications are just a
few pages long.
And a good web developer will be able to figure
this out very quickly.
And of course if you're working with a specific
implementer of a technology whether it's
a FIDO authenticator or a server manufacturer,
they have access to many examples and
many programming languages that very quickly
show you how to integrate FIDO into
your web application.
>>Erfan Ibrahim: And Dan Sterling was asking
if the presentation is downloadable.
As I
mentioned earlier it will be emailed to you.
Next it Ravi Setapotty who asks, "Once a test
of human presence is established, how does
it ensure periodically that the connection
has
not been hijacked by a machine process?"
>>Arshad Noor: So, the authentication capability
is completely� it is the browser is only
acting as a conduit between the authenticator
and the remote site.
The browser itself may
try to look at the contents that it's relaying
but the protocol has designed it to be such
that
even if the browser knows what the message
layout is, it cannot manipulate that.
So the
authentication protocol has been designed
to be secure between the authenticator device
and the relying party application.
Now, once the human user is authenticated
to the application, then of course you have
to
still rely on all the other controls that
you build into the application as well as
the controls
around the browser to protect the user's session
from getting hijacked.
So those things
FIDO is not responsible for.
All FIDO is doing is making sure that the
human presence is
verified, making sure that a cryptographic
key exists for that human user against that
particular website, and making sure that messages
between the authenticator and the
remote website are protected through digital
signatures and ensuring that man in the
middle attacks are not possible.
>>Erfan Ibrahim: Then the next question from
Bill Cox is, "Is there a language for the
relying
part authentication, example XSCML?"
>>Arshad Noor: So, XSCML is more often authorization
language.
It's not an authentication
language to the best of my knowledge.
The last time I looked at XSCML was many years
ago.
And at that time there was nothing about authentication.
Now, yes it does allow you
to specify lots of rules about what resources
a user may access and whether it should be
granted.
But all of that, the XSCML rules come into
play after you identified an
authenticated the user.
FIDO stops at the authentication phase.
You can still continue to apply XSCML after
the
user is authenticated to ensure that business
rules are being followed for whatever task
the user is trying to do.
FIDO does not co-opt XSCML.
It does not overlap with XSCML.
It is completely different.
But it does allow the capability of getting
transaction
confirmation or digital signatures for transactions
if you choose to use that capability in
FIDO.
>>Erfan Ibrahim: So we're going to go for
another five minutes so we can accommodate
these
remaining questions because people have made
an effort to ask them.
Next question is
from Judith Schwartz who asks, "What if the
user's traveling and wants to sign on from
another computer or uses the computer at the
library?"
>>Arshad Noor: So, as long as you have your
FIDO authenticator the, depending on the
authenticator manufacturer you are given certain
guarantees that your private key is safe
on the authenticator.
So as long as you have your authenticator
with you, you should be
able to use even a public kiosk to log in
securely into a web application.
If you don't have
access to your authenticator then if the application
developers have built a mechanism for
you get in using a onetime password code,
then you can still get into your account with
a
FIDO authenticator.
So remember, FIDO doesn't speak to any of
the security controls of
the operating system or the computer that
you're using, or even the browser.
All it's
trying to do is protect the messages between
the authenticator device and the remote web
application.
To that extent that protocol is doing its
job.
Everything around that protocol those risks
you have to assess separately.
>>Erfan Ibrahim: Next question from Michael
Shea is, "How would FIDO authentication scheme
work with the feature like �Remember me
on this computer?'"
>>Arshad Noor: You would only choose to remember
the user name.
So in the example that
identified here earlier, so remember there
was this part of the web application.
So we
have not enabled the remember me capability
over here.
But if we had, the only thing it
would remember is the user name.
The FIDO capability is completely unknown
to the
browser until it actually receives the message
from the remote application that has Java
Script in it that communicates with the authenticator.
Until then FIDO doesn't even enter
the picture.
So at this point for example, I could have
had NREL remembered over here, and now it
sends the message to the remote server.
The remote server sends back a page with Java
Script in it and that Java Script brings up
this particular popup and prompts me for my
test of human presence.
This is where the FIDO authenticator comes
into play.
Once I've
proven this by touching my FIDO authenticator
unlocking the private key that digitally
signs the challenge and sends it back through
the Java Script directly to the server, only
then I'm authenticated.
So yes, you can use remember me, but you don't
even need a
password if you design the application the
way I've displayed it over here.
>>Erfan Ibrahim: Right, so the next question
is from Danielle is, "Why even keep the
passwords?" and I think you just addressed
that.
>>Arshad Noor: Exactly.
>>Erfan Ibrahim: Okay, next question is from
Abed Hasmi who says, "Honestly, I have no
clue
technically about network security and privacy,
but my question is what is the
applications of FIDO in smart grid, in particular
smart meters and privacy matter that
challenged the implementation of smart meters
everywhere?
>>Arshad Noor: So, regardless of what types
of devices you are interacting with, at some
point
there are web applications that interact with
these devices.
And those web applications
can well use FIDO technology.
They can use digital signatures from FIDO
authenticators
before they send commands down to grids or
meters or transformers.
So it's entirely
possible to even collect a group of digital
signatures before you take on some really
risky
activities.
So lots of interesting business capabilities
can now be done much more simply.
Interacting with FIDO directly on a smart
meter or a thermostat or a refrigerator, that
takes a little bit more work because the manufacturer
of the device must not only
implement the server site of the protocol
but they must also manage a small data store
that stores multiple FIDO keys.
It's not impossible.
It all depends on the size of the
device and how much capacity it has to add
the FIDO protocol at a small data store.
Only
the smallest of devices are likely to be challenged
in implementing FIDO today, who
knows.
Twelve, 18, 24 months from now all of this
could get miniaturized, that maybe
Asics that do FIDO's protocols on the server
side with a built in data store, and they
will
work over NSC or Bluetooth and now you can
use an NSC enabled, Google enabled,
FIDO key or your smart phone, and authenticate
to your thermostat or smart meter and
engage with it.
>>Erfan Ibrahim: Yeah, so one thing I would
recommend regarding smart meters having worked
on these things for the last seven, eight
years is to keep it as simple as possible.
Use the
NCC 1219 tables over your mesh protocol to
do remote connect/disconnect and meter
reads and don't use it as a gateway.
Today will be penetration of broadband into
the
homes.
That is not the ideal gateway.
And it's the fastest way for obsolescence
for smart
meters to start putting too many applications
on its system.
It's much better to just
consider it a note in the home area network,
let it communicate with the home area
network, but it should not trust any information
coming through.
If you maintain such
national firewall, the smart meter stays protected.
It's useful life grows and you're more
flexible to deploy smart energy applications
over the broadband through the router and
the house.
Okay, next question is from Samira [inaudible]
who says, "What do you think about FIDO
BLE specifications.
Can authentication over Bluetooth protocol
be considered safe?"
>>Arshad Noor: So I'm not-
>>Erfan Ibrahim: That's a loaded� you know,
I have never used Bluetooth and security in
one
sentence because it's not grammatical.
So let's see how you get out of this one,
Arshad.
>>Arshad Noor: I'm not a network security
protocol specialist.
So I'm going to punt on this
one.
But I will tell you that very, very smart
people from some of the largest companies
in the world are working on this right now.
If you are a FIDO member I do believe you
can gain access to the specifications that
they have created.
And if you are not a FIDO
member, I mean I will encourage you to talk
to a vendor who is likely to be a FIDO
member and ask them to get you a copy of the
specifications.
You can certainly find the
names of the chair persons of the technical
working [inaudible] You can email them and
ask
them this very specific question.
Now, since I will profess ignorance of network
protocols at that level of detail,
unfortunately I cannot respond to that question
with a satisfactory answer.
>>Erfan Ibrahim: Maybe I'm a little bias,
but having traveled in third world countries
where I've
seen the Bluetooth network being used by people
to communicate with each other in
public places where they were socially not
allowed to talk to each other tells me about
the
level of security of that protocol.
All right.
And I'm being really nice.
Okay, next we just have two more things left.
One is Judith Schwartz says, "Will the new
design Apple computers allow you to use these
authenticators?
It sounds like it is a
separate device."
I think you made your point about Apple observing
but not participating
yet in this?
>>Arshad Noor: That is correct and there is
nothing to prevent Apple from using an embedded
security element in any of their devices to
be the FIDO key store and implement the
FIDO capability within their operating system
or in firmware in the secure element.
There are manufacturers of chip sets today
that provide FIDO protocol already built into
secure elements and it's quite conceivable
that Apple may have such technology in their
devices.
In which case all that remains for them to
do is enable it in their browser and you
now have a FIDO authenticator in your device
that can communicate with website
underlying parties.
But from a human user point of view it's still
the same behavior.
You
swipe something.
You look at something or you tell the computer
some command and
you are authenticated.
>>Erfan Ibrahim: So, we have two final questions.
One is from Armando and Armando says,
"You mentioned that it depends on the manufacturer
that guarantees the security of the
key included in the FIDO device can change.
Could you explain a little more about this?"
>>Arshad Noor: So, today the FIDO Alliance
is still working on putting together all of
the
touches, finishing touches on a security certification
program.
The security certification
program is intended to test FIDO authenticators
that manufacturers choose to submit.
So
it's completely optional.
Manufacturers can choose not to submit it.
But those who do,
they will go through a rigorous test based
on published specifications and depending
on
what type of security capabilities they built
into the device, they will probably pass at
some level within that security classification
that FIDO Alliance has come up with.
Once they have passed successfully they will
be assigned a certain security classification
that will translate into certain capabilities.
This is no different from the type of
classification that you hear about with 6140-2
level 1234 and so on.
So FIDO Alliance is
working on that.
I believe they have identified a company that
will be there, one more
companies to do the testing.
I don't participate in that particular working
group directly.
So, I have no direct knowledge of at what
stage their program is, but I do know that
they
are actively working on this and it's likely
that some of these manufacturers will put
their
devices through the security testing process.
And at some point in the near future you will
have devices that will be FIDO certified to
a certain security classification which will
guarantee certain capabilities as attributed
by the testing laboratory.
>>Erfan Ibrahim: Then the last question from
our audience is, "Does the same authenticator,
can
it work for many FIDO applications and parties,
or do you have to carry man of them?"
>>Arshad Noor: No.
This is the beauty of FIDO.
You can have a single authenticator and of
course it depends on the protocol that it's
supported by the authenticator.
But that is
nothing to prevent the manufacturer from supporting
multiple protocols on the same
device if they so choose to.
Then in which case the same authenticator
can register keys
with multiple websites and you can use the
same authenticator across all of these
websites.
In my personal opinion the phone, mobile phone
is likely to become the most
ubiquitous authenticator at some point in
the near future.
But it's not inconceivable to
think of an identification card in your wallet,
whether it's a driver's license, your ID card,
or your credit card and it's not even inconceivable
that your car keys or house keys could
all have built-in FIDO authenticators in them.
So more than likely you will end up with
multiple authenticators on your body in the
near future.
>>Erfan Ibrahim: Okay, so one last question
that I had is we are migrating to the cloud
in a big
way.
And there was very little if any mention about
that in your presentation.
Does FIDO
help accelerate that and still give people
the confidence that when they're putting their
stuff up in the cloud it can be secure?
Or does it have no impact?
Tell us a little bit about
FIDO and cloud.
>>Arshad Noor: That is believe it or not,
Erfan, that is a whole one hour presentation
in and of
itself.
And I was actually planning to talk to you
about doing a future presentation about
cryptographic keys and security in the cloud.
It's not a 30 second answer.
It's not a one
minute answer.
It's not even a 10-15 minute answer.
I need to explain lots of things about
the potential vulnerabilities in clouds and
how cryptographic key management in the
public cloud presents many, many risks that
people need to be aware of before they
decide to do very sensitive things in the
cloud.
>>Erfan Ibrahim: Thank you very much.
Okay, so a couple of logistical things for
the audience.
I'm going to be sending the slides once Arshad
sends the one without the proprietary
label on it and you will also get the webinar
recording link.
Our next presentation is
going to be by [inaudible] of the open ADR
Alliance who's going to talk about how the
open
ADR protocol can be used for controlling distributed
energy resources.
So I think that
will be very informative.
As soon as the data is finalized I will be
sending an update to all
of you.
Arshad, thank you very much.
It really helped having a person of your deep
expertise and long work experience, having
worked with PKI, seen its strengths and
weaknesses and then being an instrumental
part of FIDO Alliance, and then seeing its
strengths and weaknesses I think your presentation
had a lot of credibility and a lot of
information.
Our audience really appreciates that.
>>Arshad Noor: Thank you very much, Erfan.
Thanks to everybody who sat through this.
>>Erfan Ibrahim: One last thing I would ask
you to do is how old is FIDO now?
About two-three
years.
>>Arshad Noor: Three to four years to the
best of my knowledge.
[inaudible] for less than three
years.
>>Erfan Ibrahim: I would ask you to create
one very simple graphic and that is starting
from the
first year of FIDO add up all the revenues
of the companies that are members of FIDO
for each of those years and draw a graph.
I want to see how that hockey stick.
>>Arshad Noor: Okay, now I don't obviously
have access to FIDO specific revenues.
But for
the public companies and their general revenue
companies I believe that should be
possible.
>>Erfan Ibrahim: Yeah.
Yeah, that's exactly.
Whatever is publically available of the members
of
the FIDO Alliance, draw a very simple graph
and I'll share it with our audience.
>>Arshad Noor: I'll do that.
Thank you, Erfan.
>>Erfan Ibrahim: Wonderful.
Thank you.
So at this time I'm going to end the recording.
For
those of who you stuck around, I appreciate
your patience as we went through these
questions.
They were very important.
That's why I didn't want to cut the questions
off.
Enjoy your weekend and we'll be in touch.
Thank you.
