What is SafetyNet and how does it improve Android security?

What exactly is Android SafetyNet?

Protect Android apps using Android SafetyNet

Why Android SafetyNet?

SafetyNet API types

SafetyNet APIs to protect Android
  • 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.

More on SafetyNet Attestation API

  • 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?

Checking device and client integrity for data security

Workflow

  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.

Limitations of SafetyNet Attestation API

Limitations of incorporating SafetyNet Attestation API within an app
  • 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

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store