Skip to main content

An Introduction to FIDO And Why it Matters — Video Text Version

Below is the text version for the video An Introduction to FIDO And Why it Matters.

>>Erfan Ibrahim: Good morning. This is Erfan 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- ____ and also a member of the, how do you say this, Arshad? Is it FIDO or F-I-D-O?

>>Arshad Noor: FIDO.

>>Erfan: 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: 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 ______ 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 ____ 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 ____ 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 ____ 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 ___, 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 ___ which is likely to be your user ID password or shared secret based authentication at least in the short to medium ____. 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 ____ 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 ___.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 ___ 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: 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: Absolutely.

>>Erfan: 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: 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: 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: 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: 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: 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: 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: 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: 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: That's a very good question Erfan. Unfortunately I have not studied the SQRL scheme so I must confess ignorance to that protocol.

>>Erfan: Okay, so Arshad's email is there. You can hound him later.

>>Arshad: I will promise to study that up and have it answered.

>>Erfan: 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: 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: Yeah, Arshad, I was just going to ask, what if that's cached on the browser?

>>Arshad: 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: All right, Michael Shea asks, "How much effort would be required to report the legacy applications to migrate them to use FIDO scheme?"

>>Arshad: 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: 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: 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: Then the next question from Bill Cox is, "Is there a language for the relying part authentication, example XSCML?"

>>Arshad: 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: 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: 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: Next question from Michael Shea is, "How would FIDO authentication scheme work with the feature like ‘Remember me on this computer?'"

>>Arshad: 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: Right, so the next question is from Danielle is, "Why even keep the passwords?" and I think you just addressed that.

>>Arshad: Exactly.

>>Erfan: 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: 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: 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 ____ who says, "What do you think about FIDO BLE specifications. Can authentication over Bluetooth protocol be considered safe?"

>>Arshad: So I'm not-

>>Erfan: 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: 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 ______ 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 ______ 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: Thank you very much, Erfan. Thanks to everybody who sat through this.

>>Erfan: One last thing I would ask you to do is how old is FIDO now? About two-three years.

>>Arshad: Three to four years to the best of my knowledge. ____ for less than three years.

>>Erfan: 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: 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: 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: I'll do that. Thank you, Erfan.

>>Erfan: 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.

[End of Audio]