Duo Leverages Google’s SafetyNet to Strengthen Device Health Assessments
In this modern age of security, trusting your users is not enough -- you must also establish trust in all devices across your ecosystem. The best way to establish trust in your users’ devices is to use hardware-backed cryptographic properties, but how can you trust the devices in your ecosystem when attackers are able to obtain root access by exploiting known vulnerabilities, and root detection is becoming increasingly difficult?
Google is paving the way for software-backed and hardware-based device attestation on Android with their SafetyNet API. The API determines if a device is in a normal, functional state.
As a fast-paced security company, we’re heavily invested in Trusted Access and Trusted Devices is a crucial pillar of Trusted Access. Duo Access allows administrators to set policies to only allow trusted devices to access their company’s sensitive data. In order for a device to be trusted, it cannot be tampered. Duo’s tamper detection not only includes standard rooted/jailbroken detection, but it also utilizes Google’s SafetyNet API for identifying tampered Android devices.
We will start rolling out our enhanced tamper detection as early as later this month and would love to see more industry leaders adopt hardware-based (or even better, hardware-backed) remote attestation too. If you are already a Duo Access customer and are utilizing our existing root detection, you will start taking advantage of SafetyNet by default.
What is SafetyNet?
SafetyNet is an API for establishing certain properties about the trustworthiness of the Android device your application (Duo Mobile in our case) is running on. SafetyNet does not ensure that devices aren’t susceptible to vulnerabilities. One reason for this is that many up-to-date Android devices are still vulnerable to exploits. In short -- SafetyNet uses software-backed and hardware-based information to verify that a device is in a safe and recognized state.
The API attests that your device is recognized by Google and is in a known, approved state by creating a software-backed and hardware-based profile for said device. The API then attests that said profile is CTS compatible -- meaning the device profile matches up with a device that passed Android’s Compatibility Test Suite, or CTS.
Why Should You Use It?
Why spend endless cycles trying to stay up-to-date with tamper detection when a trusted third party, Google, has an entire security team focused on the issue at hand? The answer is simple -- don’t!
The Android security team is committed to staying on top of tamper detection, and we trust Google’s native software-backed and hardware-based testification. For example, since the initial release, the team added systemless root detection, as well as extra flags to the SafetyNet payload.
Google takes a black-box approach to SafetyNet’s implementation. While this may bother some developers who want to know about the inner workings, it makes circumventing the check painfully difficult for attackers. Another benefit of Google’s design is that they are able to update the payload on-the-fly, without putting any load on developers using the API.
Peeking Under the Hood
While Google doesn’t disclose the inner workings of SafetyNet, it is known that the API communicates with snet. Snet is Google’s always-running service on Android devices that collects data about the integrity of a device and sends it back to Google. Using snet, SafetyNet has the ability to check the following flags, amongst others:
- Is the device believed to be rooted?
- Is the hardware information recognized?
- Is the software sane?
- Is the device monitored?
- Is the device infected with malicious apps?
- Is the device’s profile recognized?
For a more in-depth breakdown of snet’s capabilities, please visit John Kozyrakis’s blog post.
Software-Backed and Hardware-Based Remote Attestation Using SafetyNet
A remote attestation is when an authorized service makes a reliable statement about a given device to another service. Google’s SafetyNet remote attestation, in conjunction with Duo’s initial root check, provides a reliable measurement of hardware-based and software-backed tamper detection for Android devices before they can access your application. This is a solid push towards stronger two-factor device security posture for both Duo and our Platform Edition customers. Stay tuned for more access control updates to Duo’s Platform Edition later this month.
Implementation
While validation and nonce creation can be implemented client-side, we strongly encourage server-side validation and nonce creation since, among other reasons, the attestation response could be trivially altered by attackers. Furthermore, a device cannot be trusted until it passes the entire workflow.
So, how did we securely implement SafetyNet?
- First, when a user opens Duo Mobile, the app calls out to Duo’s service requesting a single-use token, or nonce
- Once the application receives the nonce, Duo Mobile sends out a compatibility check request (including said nonce) to the SafetyNet API using a Google Play Services API client
- Google then responds with an AttestationResult containing the JSON Web Signature, or JWS, which houses the SafetyNet payload
- If no errors are present in the AttestationResult, Duo Mobile securely sends the JWS (amongst other useful information) to Duo’s service
- The Duo service then verifies that the response came from Google by validating the SSL certificate chain and that the leaf certificate was issued to attest.android.com
- If the certificate chain checks out, Duo’s service then verifies the signature of the JWS itself
- Now that the service confirmed the JWS came from Google, it parses the JWS payload to ensure it matches the original request
- If the payload is as expected, Duo’s service uses the "ctsProfileMatch" from the JWS payload to determine the SafetyNet result.
- Finally, if the “ctsProfileMatch” is True and the device passes Duo’s basic root detection, it can be trusted and the user can authenticate
For a more general use case diagram conveying how to implement SafetyNet validation server-side, please see the “Secure Flow with SafetyNet” illustration from Cigital’s breakdown.
If you don’t want to verify the certificate chain and JWS signature yourself, Google provides an Android Device Verification API to do the heavy lifting for you. One caveat about the verification API is that it is rate-limited, so make sure to keep tabs on the number of requests your service is sending. Lastly, it is important to keep in mind that the API does not verify the SafetyNet payload, so you still must implement it yourself.
How We Reached Our Implementation
We could say implementing SafetyNet correctly for our needs was trivial and painless, but that wouldn’t be 100% truthful. Overall, the implementation was straightforward, but there were some minor hiccups along the way.
There is a great SafetyNet Helper example on Github that demonstrates how to implement SafetyNet entirely client-side. Lastly, Google’s engineers have been immensely supportive, promptly answering any questions along the way.
While the existing open-source implementations were beneficial, we were unable to find an implementation that fit our specific use case. A few examples include implementations passing on validating pieces of the payload, client-side nonce generation, client-side validation, and not manually verifying the certificate chain and signature. While it is acceptable to use the Android Device Verification API to validate the compatibility check response, the rate-limit on API calls was a hard stop for our scalable solution. In the end, this presents an excellent opportunity to give back to the open-source community and share our findings.
What is the Benefit of Tamper Detection Over Simple Root Detection?
SafetyNet sounds great in theory, but how well does it perform in practice? Of all assessed Android devices across Duo’s population, we see over a 5 times increase in the number of devices flagged as tampered by incorporating the SafetyNet attestation. The 5x scale factor may be attributed to systemless-rooted devices, devices from unrecognized vendors, altered or infected devices, or other purposeful or malicious actions that leave devices in an unrecognized state.
While SafetyNet is a powerful tool, don’t scrap your system root detection just yet! We discovered a minute subset of devices that fail simple system-root detection but pass the SafetyNet attestation. On the flip side, as new Android beta versions and new devices roll out, they may fail the SafetyNet check until the corresponding device profile is recognized by Google. Lastly, if a device’s Google Play Services is not up to date or the SDK is not supported, you may be unable to obtain a SafetyNet result from said device.
Using hardware-based and software-backed properties to make access control decisions is becoming increasingly important and it is tremendous that the Android security team made the SafetyNet API publically accessible to developers. Since a key component of Duo’s Trusted Access vision is to establish device trust in your user’s devices before allowing them to access your applications, adding SafetyNet to our solution was a no-brainer. If you are a developer and already implemented tamper/root detection, we highly suggest adding Google’s SafetyNet remote device attestation.
If you have any questions about this post, SafetyNet in general, or would like to geek out over implementation details, please reach out to robbie@duosecurity.com.