Stina Ehrensvärd - The Future of Strong Online Identities - Simple, Open and Mobile

So, hi, I'm Dina. A few years ago, I started a company with the vision of having one simple, secure key to access all internet services and to make that dream real, a part of my team. And I moved from Stockholm to Silicon valley to work closely with the internet thought leaders to develop Fido U F universal second factor. So our products are named the UBI key. I assume many of you know about them. They offer strong second factor in a simple touch with no client software or drivers needed to make them work really seamlessly with any number of, of services.

And with the leading platforms and services, we support open standards, both U 12 and P. So oath is where it started. It's stands for open authentication, and it's standardized interfaced for one time, password apps, tokens, and mobile apps. And what we did with it is that instead of having to retype a code, we had a key that you inserted in the use report. And when you touched it, it generates a passcode without having to retype it. The problem with oath is that it's based on symmetric keys. So it doesn't protect against man in the middle and fishing.

And Also you need to secure all the secrets in one database. The other protocol named P is actually better in terms of security. It's a smart card standard that comes in both in with USB and NFC, and it offers publicly crypto. And it's very good for native login to computers because it's natively integrated in windows, Mac, and, and, and Mac and Linux, but it's not designed for the web. It's very complex to scale for the web.

So what we did with this one, we invented something we call touch to sign it's you add a small touch, and then you can actually verify that it's the real user behind the key, these two standards, oath, and P sort of encourage us to think, what can we do with the best of these standards and what can we do to make something that really scales? And that's when we approach Google together with the Google security team we developed U two F fi U two F I mean, actually was developed before it was Fido. And we brought in security experts from NXP to help us with encryption part of it.

And this is the secret. It's the first time that you can have one key to any number of services without any secrets shared by the services. Every time you register a U two F key to a site, it generates a new key pair of secrets, a a key pair of public private secrets that is only stored on the special service it connects to. So I can log on to Gmail. I can log into Dropbox to GitHub, and none of these service providers share any of the secrets. It's it has fantastic security.

Not only does it secure against fishing and man in the middle, it also have this touch to verify touch sensor that allows it to know that you are a real person and not a Traian that's trying to, to hack it remotely. A few weeks ago, Google released a study where they had deployed U F for two years, and it's now mandatory by all Google staff, contractors, and interns. They don't allow the Google authenticator within the company anymore because they had too much fishing attempts in the study.

It was clear that you two have keys were four times faster to log into than a Google authenticator, because you only touch it. You don't have to open up your phone, find the app and retype the code.

Also, it was actually less costly. And this is an interesting part. It's sort of a perception that a free mobile app would be cheaper to deploy than a hardware device. But when you take into the consideration that it's about $30 for every support call and if phones, that is the becomes, the only way to log in and the phone is lost and broken, you don't really have any backup. So that was the major support issue they had with Google authenticator in Google, by giving their staff at least two or maybe three keys, they were easy and affordable. They'd eliminated this problem.

And the support cost was reduced almost in half. The security is really good. It's publicly crypto that has, I it's actually, there isn't any smart car technology out there that has any better security. So when I'm talking now about support, I wanna share with you something that was related to support, just because it's fun. It came from one of our customers.

It's a, it was ASIS admin from university that came with the email heading, and it was most bizarre support question I ever got. My dog just ate my UBI key, please advice.

So, I mean, a lot of the support is not coming from, you know, the real, the real product or the real setting, But with the UWF UBI keys support can be reduced. So U UTF keys works with NFC.

There, we have had issues with Bluetooth. There are challenges with pairing and security, but by end of this year, there will be products certified you to have products with BLE on the market. We are also working on a Bluetooth, no on a mobile client that allows this. You to have crypto to be natively supported in mobile apps and sort of push like mobile clients that will work as a compliment to the hardware software. Clients are never gonna be as secure as hardware, but it's good enough for many applications. And with this, we can also make it passwordless and token less.

The way it works is that you can open your phone, unlock your phone with your biometrics, and then you log in by touching the, the app. So where are we going? Now? It started with Chrome in a few months. We'll have support in Mozilla there's opera and Microsoft internet Explorer. Plugging that is, is, is under development. Microsoft came in later in Fido and they have proposed a new up sort of superset of our web API that we develop in U F. And we're now working to get a seamless path from the U F web API to a 5 0 2 web API. In the future.

You will see these protocols being integrated and used for internet of things for device of device authentication. And they will also be used for next generation payment, a payment in the browser.

Oh, actually in this picture, there's a picture from login screen from UK government that just made support for U 12 the other day. And this is the first time a U 12 key is used for high identity assurance. The beauty with a U 12 key is that is not tied to any means of identity. So it can be secure yet anonymous, the same key you can tie to an identity provider. And when you tie it to identity provider, that identity provider can offer an identity proofing service that tie it to your real identity. And now you've got an identity that you can use for logging into go government services.

This is disruptive. Traditional government issued ID cards are always owned and controlled by the government or a bank with this system, users, citizens can buy their own identities on Amazon, eventually seven 11, just like the, the, the keys you find just like the, the, the, the keys or the, the prepaid key, the phone cards you buy, and you'll take them down. You go home and you sign it up for any number of services and you can have multiple identities. You can tie it to your real identity.

You can tie it to your whatever identity and there's no linkable see no linkable between the identities or the service providers. So a lot of people have question, why is Yubico driving this? Eventually this technology will be integrated directly into computers, into smartphones, and there will be mobile apps. And we drive it because we know that it's needed secure. Online identities is the most critical thing to solve right now. We also know that hardware authentication keys, like our products will stay. And we have that proven just like the SIM card.

We need a simple, secure, and affordable way to distribute user credentials. It is not necessarily easy to do it without the hardware.

We also, we know that separate than the key storage from the computing device is the best practice in security. We need something that is not always tied to your computing device. Your identity may not. You may not want it to be in your, your phone or in your computer. You may want to be able to move it between computers and phone, just like you have your passport, not tied to your bag or your credit card, not tied to your wallet. You also need backup, and you wanna have something that preserves privacy.

So this is my last slide service providers can make easily support for U two F with free open source components, both Google, and Yubico offers this at GitHub, and it takes about a day or two to make support. Enterprises can choose to use this food to secure staff by choosing an IMM vendor, the, an authentication vendor that have made support for it, hardware manufacturers, or authentication software manufacturers. They can also get the code for free, and they're welcome to innovate and compete.

And for the rest of you who are interested to learn more, we have a booth around the corner where we give away free keys that you can try today with Gmail and Dropbox and in the future, it'll work for your bank, your government and the range of services. Okay. Thank you. Thank you very much. Interesting product. I like it for a number of years, and it has a number of challenges. Can we see the questions please? And obviously some people will also be shown there. Obviously some people have thought about that. Still waiting for the questions. There you go.

How can you have strong authentication when there's no level of immutable binding between the person and the device, So that strong authentication doesn't necess necessarily need strong identity. A strong authentication is a key that you set up for a service and you are the legitimate owner, The same person that comes back again, strong authentication also means that it's second factor. It combines a pin with a hardware device that is, you know, is using public key crypto, changing the path code every time you log in.

So you strong authentication should not be necessarily be, you know, combined with identity. They're two separate things we do for the UK government. It's when it's tied to an identity provider that has the identity binding or the IB proofing, that's where you tie them together. And it's when you register a key at the service and that service check your driver license, or, you know, they're all kind of interesting ways to, to, to, to check your real identity. That's when that key becomes you.

I mean, literally we can have a key, we can put a, a serial number on the key. So had, is a unique number, but we can actually choose not to, because we don't want the keys to be tracked. It's when you sign it up to a service, that's when that's, when it gets an identity. So this connects to the next question, which raised now to the top, in the meantime, what happens if I lose the hardware token? So I just told you what Google did. They gave two or three keys to their staff.

And in that way, they were able to minimize support significantly compare to a phone authentication technology they had in the past. I have one key in my pocket, one ki little UBI nano in my use report. I have one in my drawer, Google have set up U 12, so you can have 10 keys. It's sort of the same metaphor as the car key or house key. And if you have multiple, the risk of being locked out is gonna be less than if you're tied to your phone. And then you always combine it with a simple pin or a password.

So if you lose it, no one is gonna easily, you know, come and, and, and, and start using it for you. But of course, if it's a, a company that is deployed, it's easy to revoke, just like any other authentication method.

And let, let me then connect to the, to one question is also related. How do you reset the key if it is compromised, which is the other risk, so to say, right? So how can you assuming you lose your key and can you detach it from the authentication service?

So, So the way Google has set it up and G and Dropbox and GitHub, it's in the two step verification tab, you can register any number of keys, but you can also go in and revoke them after if you lose them. So we know, oh, I lost my key. I don't want that anymore. And then I revoke it. So that's done by the person itself. Okay. Thank you very much.

Just, just go ahead. Okay. Should I continue The question?

No, no. Just wanted to say something. So just wanted to, didn't want to interrupt you, but we, over time, I think then thank you so much. Okay. Thank You. Thank you again. Very interesting.