Do we know what can the software running on the secure enclave do exactly? If the software itself doesn't have access to the master key (a.i. can't read it directly), and if the slow authentication is inherent from running the algorithm on the chip, rather than a having been slowed down artificially, then even an update to the secure enclave would not compromise the security of the system.
Do we know exactly what the secure enclave software can do and what it can't do?
> if the slow authentication is inherent from running the algorithm on the chip, rather than a having been slowed down artificially
There is no known cryptographic algorithm that provides inherently increasing times. The slowdown is entirely artificial, and it is believed that an update could remove it.
I was under the impression that the algorithm (running on the secure enclave?) takes at least 200ms. Yes, obviously longer times are artificial, but my question is whether the 200ms baseline is artificial or not.
Of course this doesn't really matter at all if modified software could just read the key from the chip. That is the most interesting question. So, can it? Or can the software only provide data to the chip, to do the algorithm in hardware, but the software can't read the key burned (?) into the chip.
Their hash algorithm takes ~80ms per attempt. All crypto happens on a dedicated AES engine. Files are encrypted with a key derived from UID (device key which cannot be extracted via firmware) and passphrase.
With a sufficiently complex passphrase, it's not a problem. With a typical 6-digit PIN, disabling the artificial delay and auto-wipe (which is possible via firmware updates) is all you need for a successful brute-force attack.
Do we know exactly what the secure enclave software can do and what it can't do?