Google’s Safety Net can’t protect your network like DeviceAssure

The problem of non-standard smartphones and devices isn’t entirely new.

For many years, hobbyists and the tech-inclined have enjoyed “jailbreaking” smartphones, a process which removes many of the built-in safety checks and restrictions from a device, opening it up to further customization and usability.

Counterfeit smartphones attempt to appear as genuine. This means certain apps and features must be present, and these often create additional attack vectors. As we discussed at our MWC19 launch (video), a fake iPhone contains many hidden elements which may try to install further software or simply exfiltrate data back to an attacker’s server.

The hardware itself can cause issues too. Fingerprint readers can be used to access online banking apps on smartphones. In counterfeits, the fingerprint reader rarely provides any extra security, allowing any fingerprint to pass the test. This can leave your banking wide open to abuse.

Enter SafetyNet, Google’s attempt to restrict some of the vulnerabilities non-standard devices can introduce.

According to Google, SafetyNet provides a set of services and APIs that help protect your app against security threats, including device tampering, bad URLs, potentially harmful apps, and fake users.


What is Google SafetyNet?

Google created the Attestation API to allow developers to assess the Android device their app is running on. It examines the device’s software and hardware environment, looking for integrity issues, and comparing it with the reference data for approved Android devices. Traditionally, it was used by device manufacturers to ensure that their devices met Google’s requirements to be allowed to include Google Play Services.

How does SafetyNet work?

The API receives a call from your app. The SafetyNet Attestation service then evaluates the runtime environment and requests a signed attestation of the assessment results from Google’s servers. Google’s servers send the signed attestation to the SafetyNet Attestation service on the device. The SafetyNet Attestation service then returns this signed attestation to your app. Your app forwards the signed attestation to your server. This server validates the response and uses it for anti-abuse decisions. Your server communicates its findings to your app, and can either allow full access as normal, or restrict/disable/shut down the app where a potential compromise is discovered – eg. a dodgy fingerprint reader.

Holes in SafetyNet

While SafetyNet is a good way to prevent your own apps running on potentially compromised devices, it’s less likely to be useful where a device if fully counterfeit, as many such smartphones are deliberately created to imitate known configurations, and usually run standard Android OS (sometimes dressed up as iOS). Some of the limitations of SafetyNet:

  • SafetyNet must be implemented in the app by the developer
  • Google Play services must be installed on the user’s device
  • It only works on officially certified Android devices (it won’t work on Amazon devices etc)
  • It is not device independent – the manufacturer certification process to run Google Play services is what captures the reference device properties that SafetyNet uses to perform the tests.
  • In theory, rooted devices or custom ROMs will fail SafetyNet (However, there are methods available to pass this check with rooted devices)
  • Will do nothing to mitigate risk from compromised hardware components, or compromised apps from parallel app stores

In our own testing of counterfeit devices, Google’s own apps ran on devices on which failed SafetyNet tests. This included Chrome and Google Play, which worryingly has payment functionality.

According to Google’s own documentation, the API is not designed to:

  • Act as a stand-alone anti-abuse or app-security mechanism
  • Provide fine-grained signals about system modifications
  • Have its response interpreted directly in the calling app

Less than 1% of popular Android apps tested use the Google SafetyNet Attestation API.

How is DeviceAssure different?

A key difference between DeviceAssure and SafetyNet is that we provide a device classification, whereas Google provide a Boolean result. We explain what the issue is, permitting more fine-grained decision-making depending on the risk tolerance of the situation.

We can also identify devices with invalid TACs, or devices where the TAC does not match the other identifiers (indicating a potentially laundered or stolen device). We provide details on the hardware mismatch occurring; this kind of transparency permits validation of the results we are providing. When the device identifiers do not align, indicating a compromise at some level, we identify this. In addition, our scope is rather wider than just devices that can use the PlayStore.

  • DeviceAssure provides a determination on the authenticity of the device (real or counterfeit), SafetyNet does not
  • DeviceAssure’s deep hardware inspection identifies counterfeit devices, which have been shown to include potential attack vectors at hardware and software layers
  • DeviceAssure has no dependency on Google Play Services (installed on Google-approved Android devices)
  • Runs on all devices, rooted or not, Google-approved or not
  • Works on non-standard OS distributions (LineageOS etc)
  • Can be run on the device via a web site as well as an app – SafetyNet is app-dependent
  • Fine-grained classification of the device: genuine, counterfeit, non-standard indeterminate, etc
  • Reports what tests failed – transparent
  • Identify if a device has an invalid TAC
  • Identifies emulators, bots and proxies masquerading as a mobile device
  • Does not require Google Play Service
  • Constantly updated for new device models
  • Efficient technical architecture

Learn more about DeviceAssure’s real-time device verification solution here, or download our whitepaper – Counter a Hidden and Growing Threat.

Share on: