At Duo, we’re heavy users of Chromebooks. In fact, over a quarter of our employees use Chromebooks daily for their jobs. Chromebooks are excellent choices for many of our internal needs and are relatively easy to administer. People in all different roles across the company are using Chromebooks, and we’re steadily increasing our adoption where it makes sense - yes, even members of our DevOps team are using Chromebooks.
At Duo, we’ve selected Chromebooks to be one of the dominant user platforms partly due to the security properties that Chrome OS delivers out of the box. The platform is designed to provide:
- Easy automatic operating system updates
- Sandboxing and isolation capabilities
- A mechanism to whitelist trusted Chrome extensions
- Built-in encryption and user data storage in the cloud
- Easy, enforceable policies, such as isolation to our Google Apps domain
- Verified Boot to make persistence across reboots extraordinarily difficult
It also aligns well with our heavy internal usage of cloud applications and provides vehicles for accessing other development resources.
Further, if we acknowledge where many attacks on our own security will originate from, we assume we’re no different than any other adversary target in that they will attempt to steal credentials and infect devices with persistent malware. We handle the former issue well via our service and by requiring strong authenticators like U2F tokens, and address the latter with a platform and browser choice that we feel effectively mitigates this second-best option for attackers.
In essence, when you’ve reached the point that attackers are faced with the choice to burn $100K Chrome OS exploits to attack your firm, you’ve set yourself up into a reasonably good endpoint security posture. Put another way, if you’re opening a lot of attachments and are heavy on cloud applications, this is a fantastic way to go.
Ensuring Trusted Access with Google’s Verified Access API
For the past few months, we’ve worked with Google on testing early versions of the Chrome OS Verified Access API, which is now publicly available and configurable in the Google Apps Admin Panel.
Verified Access is a new API that allows Chromebooks to cryptographically attest to the state of certain security properties of the device to a third party - in our case, that third party is actually Duo’s service - for the purposes of making decisions around activities like access control.
We use this to reliably assess the security posture of Chromebooks at Duo before they are allowed to access particularly sensitive resources.
What does the attestation protocol actually tell us? According to the source code:
- The device is actually a legit Chrome OS device, and not rogue hardware that’s had a Chrome OS image shoehorned onto it
- Verifies the freshness of the request to make sure it’s recently initiated
- It is managed by our corporate domain, thereby receiving our security settings and policies
- The signed-in user is also part of our corporate domain
- The device is actually compliant with our internal policies - for example, we disallow developer mode internally to make sure the devices have actually passed Verified Boot, etc.
How does it work?
- We configure in the Google Apps administrator panel that we want to enable Verified Access on our Chromebooks and grant access to use the enterprise.platformKeys API
- We deploy an extension internally designed to interact with the enterprise.platformKeys API
- During login, we request a challenge from the Verified Access API
- We pass the challenge to the extension using the Chrome Message Passing API
- The extension uses the enterprise.platformKeys API to get a challenge-response
- The challenge-response is sent to Duo’s service, which verifies it by sending it to the Verified Access API and getting back the response
- We make an access control decision based on that outcome - if the client fails the protocol, we warn them and deny access.
Given the many other security properties that are essentially native to the security model and architecture of Chrome OS, this gives us a reliable way of measuring foundational, hardware-backed security properties of Chromebooks before they access our services. It’s a high-assurance way for us to clear Chromebooks for access internally and be certain that only our users and our devices are passed through to sensitive services and data. It’s a great step toward even stronger endpoint security posture for our company and our customers.
During initial testing, calls to this API were whitelisted only in Chrome’s developer channel (not to be confused with developer mode), so we isolated testers to just our R&D team. However, we’ve been running this reliably internally since Chrome major version 50 reached stable branch earlier this summer on all Chromebooks at Duo.
Later this year, we plan to GA support for Verified Access in Duo Beyond and provide support for making access control decisions based on remote attestation information gleaned from this protocol.
We think this is the right direction for our customers, particularly given the continual acceleration of cloud adoption and the security properties already native to Chrome OS. We are seeing more of our customers choosing Chrome OS, so this is a great extra option for them.
Choosing to make security and access control decisions based primarily on the strongest-possible sets of properties and device security is increasingly important, and we’re glad that Chrome OS is making this so accessible for our customers.
We’re happy to share notes around our development work for our implementation of Verified Access internally. Reach out to firstname.lastname@example.org with any questions. Once we GA support for Verified Access, we’ll be back with a detailed technical post on our own internal implementation to provide a model for customers who want to take advantage of this capability.