Google Offers Physical Key Authentication to Developers
During the Day two keynotes at the Google Cloud Next conference in San Francisco earlier this month, Senior Vice President for Technical Infrastructure Urs Hölzle tossed a loose blanket of security technologies in the general direction of spectators. Some of them, when stitched together the rest of the way, could comprise a platform.
There was a technology described as a data loss prevention (DLP) library, but which was actually, technically speaking, a privacy safety net, capable of scanning digital photos and automatically redacting credit card numbers, Social Security numbers, and other common patterns of probably private data. And in the midst of that same presentation, there was a USB key — specifically, a FIDO U2F (Universal 2nd Factor) key, likely from Yubico — that authenticated a user’s access to a G Suite Enterprise application, or potentially any application, hosted on Google Cloud Platform.
“This feature lets you enforce security key use for all members of your domain,” explained Hölzle, standing in front of an animation of a finger operating a U2F key like a piccolo. “That means that access to all of your applications is now strongly phishing-resistant.”
The presentation made it appear as though the DLP library and the U2F key were all part of a cohesive new security platform, along with a new software library released into beta called Identity-Aware Proxy, plus an actual chip manufactured by Google to establish a root of trust inside servers, which it calls Titan. And also, that the leverage point for that security platform was Google Cloud Platform.
The Progenitor
The model around which Google is actually building — one whose existence was merely alluded to in the presentation — dates back to 2014. Then, an Ireland-based Google site reliability engineer named Rory Ward teamed up with technical writer Betsy Beyer, to produce a security model they called “BeyondCorp: A New Approach to Enterprise Security.” [PDF] Ward’s and Beyer’s paper is credited with having triggered Google’s move to migrate nearly all of its internal applications to a non-privileged hosting model — one that abolishes the virtual private network (VPN), so that any server, anywhere that hosts an application can reliably authenticate a client.
It’s a model that enables any server-driven system, or any public PaaS, to reliably serve applications and data to authenticated users, while denying access to all others. By shifting the security burden to clients, the BeyondCorp model would relocate the attack surface, from a single, soft-shelled organism that’s easy enough to crack, to a million or so hard-shelled nuts.
What Google now calls the Cloud Identity-Aware Proxy (Cloud IAP) was introduced by the BeyondCorp model with a similar name: the Internet-Facing Access Proxy. “The access proxy is configured for each application,” Beyer and Ward wrote in 2014, “and provides common features such as global reachability, load balancing, access control checks, application health checks, and denial-of-service protection. This proxy delegates requests as appropriate to the back-end application after the access control checks complete.”
The preface to Google’s new documentation for Cloud IAP, published a few weeks ago, attributes its existence to BeyondCorp, which it describes as “an enterprise security model that enables every employee to work from untrusted networks without the use of a VPN.”
What’s extremely important about the BeyondCorp model — more so than its principle of VPN-less, perimeter-less access control — is the wave it triggered within Google, which impacted all of us in turn. BeyondCorp heralded the transition to an application-oriented infrastructure not just for Google’s principal services, such as search, but for everything it does. Indeed, it was the urgent need to re-architect all its services that led Google to apply its Borg staging model to lower-level user applications. It was that effort which revealed to Google engineers the need to split off the container scheduler as a separate process. And that decision led directly to the creation of Kubernetes.
IAP may have been the catalyst for one of history’s most important software innovations. Yet at Google Next, it was presented quite curiously — and contrary to its origins — as a protection mechanism extended to users by GCP.
“We view every access decision to resources not as something that’s about the users’ credentials, and maybe their second factor,” said Hölzle, “but really something that should be based on the context around it — for example, the state of the user’s device, their location, and so on. We call this ‘context-aware security.’ The user’s context determines access, not just the network they’re on, or who they are. And the context that we have today with the IAP proxy is just the user identity and the security key — so, the strength of authentication. But you can expect our future versions to use a richer and richer context over time, to better secure access to your Cloud applications or your G Suite.”
Incentives
While some of the pieces of Microsoft’s once locked-tight platform have been disconnected from each other, one of the advantages that company still holds (I’ll refrain from using the phrase “trump card”) is a market share for Active Directory identity management software still measured at above 90 percent. Microsoft is clearly leveraging its leadership position in context-rich identity as a pillar for both Azure and Office 365.
As some in the identity market space have speculated, Google is feeling the pressure from Microsoft to find a way towards parity with Azure, and maybe eke out a competitive advantage. This is where Yubico comes in.
Back in 2014, just days after a Google security engineer literally told this same audience, “We don’t have a better option to offer in the community right now” than password-based authentication, a group of security engineers banded together to form the Fast Identity Online (FIDO) Alliance. Yubico produced the first consumer-grade FIDO U2F keys, with Google’s collaboration.
U2F is not an identity mechanism; The problem of representing identity is left to others. Instead, U2F seeks a standardization of the authentication process that involves identity, however, it may be tokenized, along with the language used in the exchange between the three parties involved: the server and client in the session, plus the relying party vouching for the client’s authenticity.
With the first Yubikey’s general availability, Gmail became Google’s first application to make use of these keys for second-factor authentication. Today, you can set up all of Google’s web apps to recognize your U2F key.
“From the FIDO U2F perspective, the work is to eliminate the dependency on the username and password, adding a strong second factor,” explained Jerrod Chong, Yubico’s vice president for solutions engineering, speaking with The New Stack. “So the code the developer would write, instead of building applications or websites to use passwords, they would have the option to allow a strong second factor. There are a number of second factors in the marketplace, but by far the work that we’ve done with FIDO U2F, the security key effort, is really the most advanced and most secure.”
The Curse of Choices
Chong believes that the principal problem facing authentication today is the multiplicity of options.
“We created this mess for the identity industry, to be honest,” he told us. “Every security company has contributed to the mess that we’re in today. Authentication is no different; there have been a lot of proprietary things going on in the ecosystem. So we need to move forward. There’s much greater value for the security community to work together, rather than against each other.”
Yubico’s interest in its partnership with Google, according to Chong, is not to advance the cause of a single cloud platform, but rather to help lay a further foundation for an authentication standard everyone can use.
“Generally speaking, we need to move to a model where everything works with each other,” he said. “That goes for cloud platforms as well. A cloud platform is no different than a bank. If every cloud platform requires some one-to-one relationship with whatever authenticator you have — whether it’s software, phone, or hardware — it’s a bad situation for everyone. Because a company is going to work with multiple cloud services, like it or not. These cloud companies can be evil about it, but everybody’s using AWS, everybody’s using Azure, everybody’s using Google. Three or four different products trying to get to each of these systems doesn’t work. Everybody has got to work together. And the good news is that we have actually moved the needle on this thing, where the big ISPs are saying, ‘Guys, you’ve really got to solve this for the ecosystem.’”
So it is that the company advocating fair play for workload orchestration (far outside its revenue stream) is being urged by its own partner to take the same stance for cloud platform services (well inside its revenue stream). That’s the thing about fairness: It doesn’t work well as a policy unless you distribute it evenly.
Featured photo from Yubico.
