Android Enthusiasts Asked by auspicious99 on December 7, 2020
As widely reported on different sites, and also discussed on this site (here and here), earlier this year, Google made changes to SafetyNet so that it could detect bootloader/verified boot status even with MagiskHide enabled. The developer of Magisk, John Wu, at that time tweeted that because Google was using the Trusted Execution Environment (TEE), its check on bootloader status could not be defeated. For example, he wrote:
this new update utilizes hardware-based key attestation. It will send an unmodified keystore certificate to SafetyNet servers, verify its legitimacy, and check certificate extension data to know whether your device have verified boot enabled (bootloader status)
Unless there is serious implementation bugs in your ARM TrustZone (or security co-processor like Google’s Titan M), you cannot break the cryptography.
He basically concluded:
Let’s face it. Fun is over guys.
Yet, on March 14, John Wu tweeted:
So apparently CTS is just passing again out of nowhere? Maybe Google is still testing things out?
I’m over it anyways. Google is apparently willing to use key attestation for detection. Since MagiskHide is still there, people can still always use it as usual.
And another tweet from him on April 3 that I didn’t quite understand:
THE BIG GOOGLE HAMMER IS BACK!
Say bye bye to SafetyNet, we’ll (not) miss you…
Did that mean Google would somehow be removing SafetyNet, or at least not utilizing its capabilities to detect bootloader status?
So there was some doubt beginning to surface in mid March. In my own test in late May 2020, with MagiskHide not enabled, SafetyNet failed, but with MagiskHide enabled and targetting my test app, SafetyNet passed, meaning that MagishHide could still defeat SafetyNet. The test was run on a Pixel 3 with android 10.
So, Google may have the capability to detect MagiskHide, and it was working out in the field with real devices, but they have somehow stopped doing that? Does anyone know what is going on with SafetyNet? Was the feature temporarily reverted? Will it be coming back to SafetyNet, and if so, when?
(29 June 2020) It looks like Google is just being cautious, and preparing a new field in the SafetyNet response.
According to the SafetyNet API Clients Team
We have started rolling out a new feature that will provide developers with insight into the types of signals/measurements that have contributed to each individual SafetyNet Attestation API response.
Our JWS responses now have a new optional field named evaluationType. The value of this field will be a list of comma-separated string tokens, where each token represents an enum-like value.
Currently, the following string tokens may be indicated::
- BASIC - When we use typical signals and measurements along with reference data during our evaluation.
- HARDWARE_BACKED - When we use the available hardware-backed security features of the remote device (e.g. hardware-backed key attestation) to influence our evaluation.
Examples of field values that you may expect:
- {“evaluationType”: “BASIC”}
- {“evaluationType”: “BASIC,HARDWARE_BACKED”}
We’re currently evaluating and adjusting the eligibility criteria for devices where we will rely on hardware-backed security features. So please do not use the presence or value of this field as a signal by itself (for now).
Note that this feature has not been officially documented yet. Presently, we’re only communicating it to this announcement-list to collect feedback.
We encourage you to use our feedback form based on your experience with this new feature as well as the overall service.
Thanks & Regards, SafetyNet API Clients team
So once testing for this new feature is completed, it looks like hardware-backed key attestation will be put in place. Which means, from then on, SafetyNet would be able to detect bootloader/verified boot status even with MagiskHide enabled.
(updated on 29 June 2020)
John Wu is trying to persuade Google to not blindly apply SafetyNet hardware-backed attestation across the board. He tweeted:
I advocate @AndroidDev to restrict hardware-backed SafetyNet evaluation to "real" security sensitive apps. Developers should go through an application process to qualify this level of API access. It is ridiculous for McDonalds to refuse to run on a bootloader unlocked device.
Meanwhile, it appears that the SafetyNet checks will still fail even if the bootloader is re-locked, as we see here, tweeted 3 July 2020
Bad news: it is confirmed that for those who wants to re-lock their bootloader with self signed images (possible on Pixel devices), SafetyNet with HARDWARE-BACKED evaluation will still NOT pass CTS check.
Correct answer by auspicious99 on December 7, 2020
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP