strictly enforce) Hardware-based Key Attestation on devices that support it. Hopefully this gives some insight regarding what pressures may finally force Google to properly deploy (ie. Or maybe they'll just let the landslide go and force bank app users to upgrade devices. MEETS_STRONG_INTEGRITY in order to stop a landslide that would prevent all stock locked Android 7 and lower devices using bank apps etc. This would, however, be a way to swing the hammer a bit sooner, and either way, as can be seen from the above, they may be forced to do this once banks do indicate a willingness to enforce If they do this it would be a concession as modded OnePlus etc may then still be able to pass CTS Profile match / DEVICE_INTEGRITY while other modern modded devices won't. It seems likely to me that OnePlus and other devices with broken keymaster can be spared if Google do prevent on-device triggering of fallbacks to basic attestation use simply by using device info contained in the cryptographic attestation sent to Google servers instead of userspace model props etc now used, to bypass enforcement at the server end. There are exceptions, eg Asus ROG Phone 3, where broken keymaster actually results in PI MEETS_STRONG_INTEGRITY and S/N CTS Profile match with Evaluation type HARDWARE regardless of bootloader status instead of the converse. Google also, as other authorities have commented, appears to be waiting for some 'acceptable' percentile / critical mass of such devices in use to be reached also, before they swing the 'big hammer' that is Hardware-backed Key Attestation enforcement and that will definitely spell the endgame for modders' use of bank apps, and possibly for OnePlus users and others whose devices have broken keymaster* This verdict should not properly be obtained on modded devices, and it requires the same attestations as S/N as well as the same tricks to trigger fallback to BASIC attestation and bypass enforcement) The incentive to use this foolproof means is also certainly being weighed constantly against the cost / need to use their own custom means of sophisticated 'root' detection. I'm guessing the banks may well leverage this at some point if the time arrives when they feel there is a sufficient critical mass of devices w/ working hardware-backed keymaster (ie w/ hardware keystore, A8+) to trade against the number of modded (bootloader unlocked) devices in use especially if they deem Google slow to close the fallback-to-basic-attestation loophole that has allowed modders to bypass hardware based attestation to CTS Profile match enforcement (by triggering fallback to BASIC Evaluation type as well as bypassing enforcement) and also to allow its counterpart, MEETS_DEVICE_INTEGRITY verdict. Keymaster may have been fixed in OnePlus devices launched with Android 12+). Nothing has actually changed with new PI API MEETS_STRONG_INTEGRITY will exclude the same group, so it's doubtful they'll rush to require this verdict.īasically, the means to enforce Hardware key-backed Attestation has already been here w/ either of these attestations, but banks don't want to exclude all those w/Android 7 and below, or many w/ broken keymaster 3+ implementations in Android 8+ devices (CTS Profile match with HARDWARE Evaluation type / MEETS_STRONG_INTEGRITY won't pass with locked bootloader), eg most OnePlus devices (nb. You've been warned!įWIW, Play Integrity MEETS_STRONG_INTEGRITY is akin to SafetyNet Evaluation type HARDWARE with CTS Profile match.īanks could have used this before (w/ S/N API) but haven't as it would have excluded too many users/devices/customers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |