> run 'offline' dictionary attacks against secure enclave content.
Isn't the T2 chip the only reason they can't do that:: because it sets a minimum time-limit and cooldown period on attempts to authenticate using the device passcode?
So presumably rooting T2 and removing the artificial time limits and/or extracting KDF data would mean game-over because brute-forcing `[0-9]{4,8}`, with even the most expensive hash function - and with a salted hash - can probably be done on a desktop within a day.
...but why can't we do that today by de-capping the T2 chip and looking at its flash storage with an electron-microscope?
The Secure Enclave is just a part of the T2 chip. My understanding is that this is similar to if you jailbreak your iOS device, you won't get any special access to the Secure Enclave.
And as I understand it, it's also the Secure Enclave that enforces the attempt limits.
That’s right, but the T2 chip is based on the A10 one and has the same Secure Enclave; this enclave is vulnerable to the blackbird exploit discovered recently.
I don't think it's just that - the design intent is for the crypto operations to run only on the device and also to depend not just on a key derived from the user password but on parameters built into the device that are not accessible to the software. Just controlling the software is not necessarily enough to take the attempts off-device.
Isn't the T2 chip the only reason they can't do that:: because it sets a minimum time-limit and cooldown period on attempts to authenticate using the device passcode?
So presumably rooting T2 and removing the artificial time limits and/or extracting KDF data would mean game-over because brute-forcing `[0-9]{4,8}`, with even the most expensive hash function - and with a salted hash - can probably be done on a desktop within a day.
...but why can't we do that today by de-capping the T2 chip and looking at its flash storage with an electron-microscope?