This is almost certainly a way to brute-force passwords without the rate limit which is enforced by default. The only reason passwords can be brute-forced is that they're numeric and have few digits. If you use an alphanumeric passcode with at least 8-10 digits, you're fine.
Apple can't patch it. It's a fundamental limitation that, somewhere on the device, is stored a key; if you can extract that key, then you can run brute-force on it as much as you want from a supercomputer. And it has to be extractable because the phone itself has to use it.
It's supposed to. We don't even know for sure that there's a flaw in it; they might have just bypassed it, found a way to read the flash memory directly.
I'm not saying extraction is technically impossible, just that you can't simply bypass the SEP and read its flash the way hardware reversers do with other embedded systems.
Is it certain that they encrypt the symmetric key with a hash derived from the alphanumeric one? It is not inconceivable that they assume the secure enclave is secure and just store the symmetric key verbatim. This seems like the only sensible option for PIN, so if you're already doing that, it is very possible they just use the same scheme for the alphanumeric passwords.
#1 it's the most plausible given that it's impossible to be patched upstream and apple aren't slouches regarding crypto. #2 I saw a demo a while back of such a mechanism, and it was obviously brute-forcing. Rest assured, I'm not working for cellebrite selling fake assurances; it's obvious alphanumerics aren't less secure than numeric PINs, and you shouldn't store anything actually sensitive on a biometric-enabled phone anyway.
Because (ideally) without your input the locked device is as hard to break as some blob encrypted with a random and sizable key. So it's more likely someone's found a way to brute force your input than a way to brute force a big random key or break cryptography.
Comments
This is almost certainly a way to brute-force passwords without the rate limit which is enforced by default. The only reason passwords can be brute-forced is that they're numeric and have few digits. If you use an alphanumeric passcode with at least 8-10 digits, you're fine.
I don't think it's so obvious what the vulnerability is... or apple would want to patch it
Apple can't patch it. It's a fundamental limitation that, somewhere on the device, is stored a key; if you can extract that key, then you can run brute-force on it as much as you want from a supercomputer. And it has to be extractable because the phone itself has to use it.
The Secure Enclave prevents this
It's supposed to. We don't even know for sure that there's a flaw in it; they might have just bypassed it, found a way to read the flash memory directly.
The memory used by the SEP is encrypted.
With a key. Which is stored in SEP hardware. Which could, in theory, be extracted.
I'm not saying extraction is technically impossible, just that you can't simply bypass the SEP and read its flash the way hardware reversers do with other embedded systems.
The secure enclave SHOULD prevent this! The cellebrite people found some vulnerability, but we dont know in which component.
Is it certain that they encrypt the symmetric key with a hash derived from the alphanumeric one? It is not inconceivable that they assume the secure enclave is secure and just store the symmetric key verbatim. This seems like the only sensible option for PIN, so if you're already doing that, it is very possible they just use the same scheme for the alphanumeric passwords.
It's documented to be PBKDF2; Google "ios key tangle".
What makes you so certain of that?
#1 it's the most plausible given that it's impossible to be patched upstream and apple aren't slouches regarding crypto. #2 I saw a demo a while back of such a mechanism, and it was obviously brute-forcing. Rest assured, I'm not working for cellebrite selling fake assurances; it's obvious alphanumerics aren't less secure than numeric PINs, and you shouldn't store anything actually sensitive on a biometric-enabled phone anyway.
Because (ideally) without your input the locked device is as hard to break as some blob encrypted with a random and sizable key. So it's more likely someone's found a way to brute force your input than a way to brute force a big random key or break cryptography.
Math.