The Verified Access API uses the Trusted Platform Module to cryptographically identify and assess the security posture of Chrome OS devices
Google is making it possible for enterprises to cryptographically validate Chrome OS devices before letting them connect to secure networks with its new Verified Access for Chrome OS.
With Verified Access, network services -- VPN gateways, sensitive servers, an enterprise certificate authority, enterprise Wi-Fi access points -- can get a hardware-backed cryptographic guarantee from the client machine that it has not been compromised and the user is who he or she claims to be.
Verified Access uses the Trusted Platform Module chip present on all Chrome OS devices to confirm the device is unmodified and complies with existing security policies. The network service uses that information to determine what level of access the device gets to sensitive corporate systems and applications.
The combination of a cryptographic attestment of the device's untampered state, anchored to a chip on the device, has long been used in Apple's iOS devices, BlackBerrys, and Samsung's higher-end Android devices. The Trusted Platform Module chip used in Chrome OS devices has been available on higher-end Windows PCs for several years as well, though its use there is typically tied to validating the encryption key in a tamperproof manner.
"For years, Google has been using Verified Access to enhance security by ensuring the veracity and policy compliance of Chrome devices before allowing access to resources, and now we are making it available externally," Saswat Panigrahi, senior product manager for Chrome for Work, wrote on the Google for Work blog.
The Chrome OS Verified Access API is now publicly available and configurable in the Google Apps Admin Panel. Administrators get started by enabling Verified Access and granting access to use the enterprise.platformKeys API. A Chrome extension also needs to be installed on the devices to interact with the enterprise.platformKeys API.
ID, please
Enterprises typically have policies in place to restrict network and data access only to corporate-issued and verified devices, but they rely on client-side methods to verify the devices. A malicious actor who has compromised the operating system can conceivably fake the signals and bypass the client-side checks.
Verified Access obtains the cryptographic guarantee from the Trusted Platform Module chip present on the device and uses the Google server-side API to confirm the identity and status of the device. It confirms the device is a real Chrome OS device and not some other hardware with the Chrome OS image installed, and the request was recently initiated and not an older, cached request. Verified Access is managed by the corporate domain, so it can check the device against security settings and policies, as well as its compliance with internal policies. It can also verify the user is a valid domain user.
One potential scenario is to integrate Verified Access with an enterprise certificate authority. In this case, hardware-protected device certificates can be distributed to only devices that IT manages and has verified. A VPN gateway can be configured to authenticate the user with a certificate and issue that certificate if the user and device passes the Verified Access check, Panigrahi said. This way, enterprises get a hardware-backed cryptographic guarantee of the identity of the device, the user, and its policy compliant state before granting them access to the protected resources behind the VPN.
This setup would work many of the popular commercial VPN gateways, including Pulse Secure VPN, Dell SonicWALL Mobile Connect, Cisco AnyConnect, F5 Access, GlobalProtect, OpenVPN, and L2TP over IPSec. VPN vendors can build direct integrations with Verified Access, but it won't be necessary to get the benefits of the attestation protocol.
As long as the VPN is set up to accept certificate-based authentication, a common arrangement among enterprises, certificate issuance can be conditioned on Verified Access without making additional changes on the gateway, Panigrahi said.
The Chromebook security advantage
Many organizations are giving Chromebooks to their employees because of their security advantages, such as the automatic operating system updates, sandboxing and isolation technologies, whitelists for trusted Chrome extensions, and built-in encryption. Chrome OS also makes it easy to enforce policies, such as isolating the device to the Google Apps domain and using Verified Boot to complicate persistence across reboots. For organizations relying heavily on cloud applications and email-based attachments, Chromebooks make a lot of sense.
This is why cloud-based trusted access provider Duo Security has decided to issue Chromebooks to more than a quarter of its employees, across different job functions and departments. Over the past few months, Duo Security has been using Verified Access internally to assess Chromebooks before granting access to corporate resources, Michael Hanley, director of security at Duo Security, wrote in a blog post.
In Duo's case, Verified Access passed the cryptographic guarantees to the company's trusted access service to make decisions about the level of access to grant to the device. A login attempt passes a challenge from the Verified Access API to the Chrome extension (via the Chrome Message Passing API), which uses the enterprise.platformKeys API to get a response. The challenge response is sent to Duo's service, which verifies it by sending it to the Verified Access API and receiving the response. The service makes an access control decision based on that outcome. If the device fails the protocol, then access is denied.
"We use this to reliably assess the security posture of Chromebooks at Duo before they are allowed to access particularly sensitive resources," Hanley wrote.
Duo Security and Ruckus Wireless has already integrated the Verified Access API with their offerings. Duo plans to have general availability of Verified Access in Duo's Platform Edition later this year. Administrators would be able to use Duo's service to make access control decisions based on information from Verified Access, much in the same way Duo currently uses the feature internally.
"Part of the reason we like this feature is it's a very strong property based on how the protocol works and what it attests to and because it was very easy for us to deploy and manage," Hanley said.
Ruckus has integrated its Cloudpath ES security management platform with the API to securely differentiate between IT-owned and user-owned Chromebooks. Cloudpath uses the API to ensure only IT-owned Chromebooks are allowed to join the wireless network or receive the certificate to access sensitive resources.
Other identity, network, and security providers can follow Ruckus and Duo's example, but integrating their services with the Verified Access API. Duo's Hanley said Verified Access required "very minimal adjustments" to deploy the API internally.
"For customers that are heavy on Chromebooks and google Apps, the lift is surprisingly low considering what customers gain from this," Hanley said.
Google has also been working on other ways to strengthen endpoint security on Chrome devices, such as adding Smartcard Authentication support. The newly launched Citrix Receiver for Chrome 2.1 lets users authenticate to virtualized Citrix applications using smartcards. If single sign-on is enabled, they can login to their Chromebook and automatically be authenticated across Citrix and virtualized Windows applications.
At the moment, Verified Access is only available for Chrome devices, and there's no word on whether Google plans to expand the security feature for other TPM-enabled platforms. Verified Access makes Chrome OS even more attractive in the enterprise endpoint security space.
EmoticonEmoticon