What is SafetyNet and how does it improve Android security?

With over 3 million applications in the Google Play Store, Android is the most trusted mobile application platform in the app development landscape. A larger part of the application developers prefers Google Play Store over other popular app stores for showcasing their projects. This fame is owed to Google’s liveliness in making its services stable and trustworthy. The Google Play Store scan apps on a daily basis and often removes the obsolete ones. Not just this, but the best-designed security APIs called Android SafetyNet is also one of the major reasons to conjecture the Android platform as ideal for application users as well as developers.

SafetyNet from Google offers a complete suite of features to keep the Android ecosystem in check. The set of services and APIs from SafetyNet are incredibly focused on safety which when tied with an application opens up a new realm of opportunities to safeguard the app against security threats. This blog post explains the check mechanisms inside the SafetyNet system, the easiest way to use it with your application and share some recommendations regarding app integrity verification but note that SafetyNet is not just limited to the pointers described here. In this blog, what we focus mainly on is the most commonly used SafetyNet Attestation API.

What exactly is Android SafetyNet?

SafetyNet is a simple and scalable solution from Google to verify device compatibility and security. For app developers having concerns about their application’s security, Google trusts its Android SafetyNet will be the right answer. With a strong emphasis on security, SafetyNet essentially protects the sensitive data within an application and helps preserve user trust as well as device integrity. SafetyNet is a part of Google Play Services and is independent of the device manufacturer. Therefore, it requires Google Play Services to be enabled on the device for the API to function smoothly.

The hardware-based attestation with SafetyNet helps in determining whether the application could work as expected on the Android gadget. SafetyNet works in combination with the snet service on Android devices which collects data about the integrity of the device and constantly ping Google about the safety status of the device. However, SafetyNet is provided as an optional service for application developers. It’s ideal to integrate SafetyNet into any app but it’s particularly important to run it on apps handling confidential data and enable the option to remotely evaluate the device’s health status. The list includes apps for automation, payment gateway apps, chat clients, e-commerce, gaming apps, and apps complying with security standards like HIPAA.

Why Android SafetyNet?

As Google provides Android as an open source platform, chances are high that the hackers can easily target the data residing on an Android app. The earlier app security measures were confined to emulator detection, checks for rooting and instrumentation tools, etc. But mobile app security checks now involve more inventory collection leaving out hackers much confused about the method used for checking. SafetyNet also works on this principle.

Google offers many other options like application sandboxing, encryption, app-based permissions and so on to secularize apps but none of them are considered as an all-inclusive solution. For instance, a sandbox can be easily broken out through device rooting or using intelligent malicious codes. Using SafetyNet services it’s possible to build secure apps that refuse to run on such tampered device environments.

SafetyNet API types

• SafetyNet Attestation API – Checks whether the gadget the application is attempting to run on is tampered or potentially compromised. It compares the device’s profile with that of Google certified devices and verifies if the device or the software running on it is Android compatible.
• SafetyNet Safe Browsing API – Checks whether a URL used within an application is marked by Google as malicious. If the API is implemented with an application, Google scans the web pages running inside the application and compare them with the constantly updated blacklist of threatful websites maintained by Google. If any malware or harmful codes are found within the page, a warning page will be added by SafetyNet and the URL will be classified as a known threat.
• SafetyNet reCAPTCHA API – Checks for spam or abusive actions by detecting whether it’s an actual person who’s interacting with the application. It uses information from an advanced risk analysis engine to protect the application from malicious traffic. A captcha will be enforced if the user is suspected to be a bot instead of a real human. The application continues working only if a human solves the captcha.
• SafetyNet Verify Apps API – Checks whether the user has enabled the Verify apps feature on the device and ensures that no known potentially harmful application is running on the Android gadget. The service coordinate with the Verify apps feature to make sure that the app’s data is protected as no other apps on the device on which the app is currently running can perform any malicious actions. With this API you can further confirm that the user’s device is having Verify apps feature enabled on it and if not, you can encourage them to use it.

Being a tamper detection framework, SafetyNet Attestation API is the most popular API often used as a vital part of any mobile app security approach.

More on SafetyNet Attestation API

SafetyNet Attestation is simply device and app attestation done remotely. It is an anti-abuse API which when added with the abuse detection system of an app checks whether it is running on a genuine Android gadget. The app security mechanism checks the device’s hardware and software environment to create a cryptographically signed attestation.

The API determines the integrity issues on the device and compares the corresponding device profile against the whitelisted device models having Google-approved device profiles. The software backed and hardware-based device profile can be considered compatible only if it matches up with any of the approved profiles in the reference list. A device is considered as approved by Google if it passes the Android Compatibility Test Suite (CTS). Thus, by comparing the device profile against the CTS standards, the API verifies the following:

• Whether the device is rooted or not.
• Whether the device is monitored.
• Whether the bootloader has been unlocked.
• Whether the device has recognized hardware parameters.
• Whether the software is Android compatible.
• Whether the device is free form malicious apps.

Why checking device and client integrity is important?

Rooting grants escalated privileges to users and allows them to circumvent certain security features built into the Android OS. Root privileges allow users to modify the OS and install unsafe software which is not granted by the device manufacturer. This results in malware attacks and effective breaching of sensitive data from the gadget. Devices running custom ROMs are also vulnerable to similar attacks. The data on such devices may not back up securely. Moreover, such unsecured devices may not get Android system updates or run Android features as expected. So, it is critical to check the device integrity before allowing an app to run on an Android gadget.

It’s difficult to build a reliable root/tamper detection system as some checks can be easily bypassed but with Android SafetyNet Attestation API the process is absolutely simple. The hackers cannot simply fake the data if the tamper detection method used is Android SafetyNet attestation API as Google leaves no trace of how the checks are being implemented. By identifying devices which are currently in the non-tampered state the API provides an assurance that the device on which the app is running is neither rooted nor using a custom ROM.

Software protection controls are also vital to protect an app’s data. Client-side protection has its own benefits when employed in the right manner. It checks the app’s integrity and makes sure that the data within the app is never compromised.

Workflow

The SafetyNet Attestation API uses the following steps to prevent an app from running on devices which are altered, infected, rooted, or unrecognized:

1. The SafetyNet attestation API receives a call from the app which includes a nonce (a number used once).
2. The API checks the runtime environment and requests the signed attestation of assessment results from Google’s servers.
3. Google’s servers evaluate the information and send the signed attestation to the SafetyNet attestation service.
4. The signed attestation is sent to the app.
5. The signed attestation is forwarded to your server by the app for validation.
6. The server evaluates the response and takes the anti-abuse decision.
7. The server communicates the findings to the app.
8. The app determines whether it should trust the gadget and run on it.

The SafetyNet attestation API returns two parameters: One for basic integrity and the other for the CTS profile match. The basicIntegrity parameter provides information on the integrity of the device whereas the ctsProfileMatch parameter gives you a signal about the compatibility of the device. Rooted devices, virtual devices, and emulators generally fail basic integrity while uncertified devices, devices with custom ROM and unlocked bootloader fails the CTS profile match. The value of both these parameters varies according to the health status of the device.

Limitations of SafetyNet Attestation API

• It can be bypassed using a suite of open source tools like Magisk or SU Hide.
• It has limitations on the number of checks per day/minute but most of the apps will be having additional requirements for which the service has to be extended with extra payment.
• It is computationally expensive and leads to an increased usage of network and device battery.
• It works only if Google Play Services and a proper internet connection are available. If the internet connection is not strong it returns an error.
• It cannot be a replacement for solid app attestation techniques and DRM checks.
• It doesn’t allow devices running newer or modified version of Android to run apps as such devices may not be included in Google’s whitelist.
• It is a spot check and may not work in actually knowing the user intent. The attestation can fail due to network and quota issues.
• It doesn’t involve application specific checks.

Recommendations:

• Implement the SafetyNet attestation API properly and be sure to take into consideration the ways for potential bypasses during the implementation process itself.
• Use SafetyNet attestation as an additional security measure along with other anti-abuse check mechanisms.
• Google recommends the products relying on SafetyNet Attestation API to plan for emergency workarounds if in any case the API fails to work temporarily.
• Ensure a strong internet connection.
• Full app attestations are recommended along with SafetyNet attestation for added protection against dynamic exploits.
• To accurately detect abusive users consider including behavioral patterns and access logs.
• Consider implementing a retry mechanism from the server side as well as the client side.
• Plan for a sensible strategy on when the attestation request is to be made – whether the attestation is required after a device reboot, after an app relaunch, while making in-app purchases or after a specific number of days past a successful attestation.
• Google recommends setting up quota monitoring and alerting to avoid errors due to additional attestation requests.

EMM support for SafetyNet Attestation API

SafetyNet Attestation API can be incorporated into an EMMs DPC to check the integrity of the devices to be managed. The attestation helps EMMs to confirm whether an already enrolled device or a device to be enrolled is tamper-free. It’s highly imperative to opt for an EMM solution supporting SafetyNet Attestation to validate the genuinely of managed devices. SafetyNet Attestation API is an important management tool Hexnode will be enabling soon for its customers.

The EMM console implements the SafetyNet attestation API, checks for the device’s health status and if a gadget is found compromised necessary actions will be taken for further protection. A tampered device will be marked as non-compliant by the EMM and will be reported as same in the EMM portal. Admins will be notified via email that the particular device is found as incompatible. Further, there are measures to choose the level of attestation needed for the device and the compliance action to be taken when the attestation is failed. That is, for an employee-owned device, admin can choose between a basic level attestation or an advanced check according to the use case and decide the compliance actions as required so as to protect employee privacy.

When is the attestation implemented?

• Prior to device provisioning before the corporate data is being transferred to the device.
• Every time a device checks in with the EMM’s server.

What all responses can be configured?

• Can prevent a tampered device from enrolling with the EMM.
• Can mark the device as non-compliant.
• Can notify the admin via email.
• Can push a corporate data wipe thereby blocking the access to business-critical data.

Android SafetyNet empowers developers to fabricate apps with inbuilt application integrity security control to deal with hazardous working environments. When integrated with an EMM solution SafetyNet empowers Android management services to deliver delightful experiences, rocketing the overall device management to the next level.