How Google turned 1.5 billion Android phones into 2FA keys

The evolution of two-factor authentication, or 2FA, has seen a move away from methods susceptible to man-in-the-middle attacks, like one-time passcodes or SMS verification, and toward physical security keys. Christiaan Brand, product manager at Google, discusses the journey to the latest step in which 1.5 billion Android devices can be used as 2FA keys.

Brand works in the identity and security product areas at Google and is specifically responsible for developing strong authentication via security keys using the WebAuthn or FIDO protocols. Brand has been part of the FIDO community since its inception in 2013 and helped develop the Titan security keys, which were credited for stopping all successful phishing attacks internally at Google. A pairing vulnerability was recently discovered in early versions of the Bluetooth Titan key, and Google has offered free replacements to all those affected.

But Brand and the team at Google didn't want to only stop phishing internally at Google and for the select customers who purchased the Titan keys. The aim was to help stop phishing attacks for everyone through championing the new WebAuthn FIDO protocol and making security key capabilities available through Android devices.

At the Google I/O 2019 developer conference, Google released the feature, which allows 1.5 billion Android devices to be used as 2FA keys when signing into Google accounts. But the plans don't end there.

Editor's note: This interview has been edited for length and clarity.

How did the idea of making Android devices into 2FA keys come to be?

Christiaan Brand: We came in with a very specific goal: How can we stop phishing of account credentials? And then, how do we not only do that for internal Google accounts, but how cool would it be if we could actually take that antiphishing technology and deploy it for all of our customers? But not only that, for all of the world?

For a long time, the technology manifested itself as a physical key. It makes sure that the right user is in front of the machine when they're trying to sign in. But, secondly, it also makes sure that the user is interacting with the correct websites. That's basically the crutch of this technology. It's making sure that I'm interacting with the legitimate Google.com or the legitimate Twitter or whatever other service it may be and not interacting with some spoofed website in order to steal my credentials.

However, it's the protocol that makes these keys work. It's not to say that this key is the thing that I have to have in my hand. The key was an easy way for us to get those protocols implemented as a low-cost consumer device, but the idea was always, 'Can we turn the thing that the user already has in their pocket into this security key, giving the user the exact same guarantees that a security key gives you?'

Essentially, what we've done is we've implemented the exact same FIDO protocols that we put in the security key. We've implemented those protocols directly into the mobile phone.

What separates this Android 2FA implementation from others?

Brand: One of the key differentiators from other technologies is that connectivity in the FIDO mindset has to be local. In other words, when I'm trying to sign in on my laptop and I use my security key, I'm plugging it into my USB port, or this Bluetooth key has to be within physical range of the machine I'm trying to log in on. That's very critical to the value proposition of this protocol. Having that physical proximity means that we can tell when a user is interacting with a legitimate website versus a fake website, because both of these two things need to be in the same physical location. And that's what we've done with the phone, as well.

The mobile phone has Bluetooth radios. Most consumer laptops and desktops these days have Bluetooth, as well. So, with this announcement, we've enabled the Bluetooth capabilities on these two devices in a new and novel way. These two devices just need to be close enough to one another, within 30 feet -- Bluetooth range. And when you try and sign in on your laptop, a message will be sent via Bluetooth to your mobile phone, which is hopefully in the vicinity. You get a prompt, you approve the prompt, it sends the message back via Bluetooth to the laptop you're trying to sign in on. And, at that point, your login is granted. But, at the same time, we're using the phishing resistance of the FIDO protocol, because we still have this physical proximity, which other protocols to date can't give you.

We've had similar multifactor authentication technologies out in the world. We have push authentication, and we have [one-time passcode] type stuff and SMS and all of these. All great technologies, but at the end of the day, because you're not sure which website you're authenticating against, they're all technically susceptible to man-in-the-middle or relay attacks. That's really the one thing that we try to do differently with FIDO and WebAuthn is making sure that these relay attacks can't happen, because the protocol is validating that the user is actually interacting with the correct website.

That's the novelty. That's the thing that FIDO adds. And if there's some way for us to kind of impart that message to the general reader, I think that would be, from my perspective at least, a job well done.

Pixel phones have a specific chip inside them -- the Titan M -- that helps with this. What is the functional difference between having a phone, like a Pixel, that has that and having other Android devices that can also be used as 2FA keys?

Brand: Functionally, there's no difference. It's analogous to the Titan security key versus a security key from any other vendor. The security key is an open standard, and any vendor can build security keys to that standard.

The value proposition last year when we announced Titan was, 'Hey, Google has a cryptography chip inside the Titan security key where we wrote the firmware.' We were responsible to work with that manufacturer for sealing all of the firmware together inside that chip, shipping it over and getting it encased in plastic. But the cryptography, which we call the Root of Trust, all sits with Google. And that's kind of the same analogy if you look at the Pixel phone security key option versus another Android phone security option. They both work equally well, they both prevent phishing in the sense that they have to be local, and if the user is on the wrong website, the key just wouldn't work.

But we have to remember FIDO and security keys are trying to solve remote phishing. That's by far the largest-scale, lowest-hanging fruit attack that attackers are perpetrating. It's so easy for them to do it. It's so low-cost. Phishing software is available everywhere. That's the thing that we're trying to protect against. And if you look at just that particular attack, then whether you're putting your cryptographic keys in a generic Android phone versus the specific Titan M, then it really makes no difference at that level.

It's when you go one level deeper, when it's about, 'What if a hacker or somebody gets a hold of my physical phone and they're able to try and grab keys off that device?' That's where you have additional assurances with something like the Pixel 3. But, as I said, that's not the primary attack vector here.

Are you working with other device makers to help them with Android 2FA either by making their own chips like the Titan M or licensing the Titan M itself?

Brand: We've made the FIDO security technology on Android available all the way back to Android N [version 7.x]. If an OEM wants to produce an Android phone, and they want to run Google applications on that phone, they have to meet certain criteria, which we normally call out in the Android CDD -- the compatibility definitions document. That document is open; anyone can go read it on Android's website.

One of the things that we started specifically spelling out since Android N was that the devices that OEMs produce have to have the capability of running what we call a trusted execution environment. In other words, when dealing with cryptographic key material and other things, you have to switch the process over to a mode where it's hardened against external attacks. Although we have [this as] a minimum bar, there is no bar right now for OEMs to have to put something like a Titan M in their phone. But, of course, it definitely is possible. Something like Titan M is definitely something that we don't want to keep only for Google, and we would be interested if other OEMs would partake in the program.

Would it have been possible add Android 2FA functionality to versions earlier than Android 7?

Brand: There's always this tradeoff that you have to make. Either you don't go back far enough in Android versions and you don't get the penetration that you want, or, if you go back too far, some of the newer security features that came with later mobile phone releases aren't available to you. For us, Android 7 was that tipping point.

If you look at Android 7 right now, there are more than 50% [57.9%] of active Android devices that run Android 7 and above, so we're able to cover more than half of the Android population. That's certainly a good number for us. Android 7 is also the release, if you look at the compatibility definition document, where Android started mandating things like trusted execution environments and other things for security storage.

Right now, using Android devices as 2FA keys, does that work just for Google account logins in Chrome, or is it WebAuthn-compatible across browsers and services?

Brand: The message that's sent from the browser, from your laptop, to your phone over this Bluetooth channel is a standard WebAuthn message. The one piece that's not yet fully standardized is the ability to make these two devices communicate to one another without having to pair them. There is a little additional novel piece in there that makes these two devices communicate securely without pairing.

Early on, user studies showed that if we subject users to varying processes, then that's not going work. So, we looked at what else we can do in order to still have a secure channel, but not require this pairing. We actually took those ideas to the FIDO organization. WebAuthn allows the capability for extending the protocol. So, we took the standardized extension mechanism, and we added this little piece, which handles this Bluetooth communication.

This is already in the FIDO organization; we've submitted this as an extension. The organization right now is kind of looking at it and asking questions and tweaking it a little bit, but we fully expect this extension to also be standardized at some point in the future and hopefully not too far in the distant future. Once that is standardized, then we'll see other websites and other browsers can implement this same thing and also allow that for their website.

Right now, I'd say Google is almost like an early adopter of this technology that we've brought into the FIDO alliance, but we certainly expect and hope that this would be standardized pretty soon so that other websites can make use of the technology, as well.