- Jun 23, 2016
AFAIK keystore/keymaster/keymint isn't broken in ROG Phone 3... Seems it has working keymaster implementation but the droidguard attestation is flawed...Do we know why in ASUS ROG Phone 3 the keystore is broken? I'm interested on it and why exactly it can pass the STRONG hardware verification.
FWIW, since DroidGuard itself is implemented as a custom virtual machine running dynamically loaded proprietary Google bytecode (unique for each attestation request) and when DroidGuardService is triggered it also checks latest DroidGuard version has been loaded as well, I believe that the Bootloader Verification it sources for Hardware Attestation as KeyStore.getCertificateChain is really the issue, so it comes back to the OEM's implementation of AVB and bootloader... Duplicating this in other devices, it seems, would depend on finding a boot chain or low-level vulnerability.
Some of the signals that ROG Phone 3's boot chain may be sending in error are outlined in this Google doc:
I put something (w/ help from @shoey63) about Rog Phone 3 here:
Regarding the common failure of OEM's to test that keymaster, driodguard, AVB chain of trust, etc, responses are accurate and implementations comply with Google requirements/specs, Google seems to be tightening up at least w/ respect to broken keymaster implementations:
Guess they may need to start revoking device certifications to force OEM's to take due care with bootloader / AVB implementations however......
Nb. Google have clearly been steadily increasing the number of prop values used to flag devices for hardware based evaluation type enforcement in their whitelist implementation for newer devices/OSs... Notably, the last addition exempts no API level 33+ LV devices!
This means that no stock (un-modded) 33+ devices will pass deviceIntegrity w/o HKA, so it seems that Google expect OnePlus and other OEM's to have fixed bad keymaster implementations in all devices launched w/ Android 13+...
If manufacturers mess this up again, their stock/locked devices can now never pass even deviceIntegrity verdict (unless Google revert the
first_api_levelflag that effectively whitelists all A13+ devices for HKA evaluation type enforcement), so these are effectively being forced to 'up their game' at this time...