But, you see, the user’s private key is simply not stored on the device. That was a glaring flaw in Samsung’s vaunted Knox encryption system; the user key was stored in an easily locatable, unencrypted library in clear text! Apple instead uses a one-way mathematical representation of that private key stored instead in a randomized location in the Secure Enclave EPROM which is accessible only by the dedicated Encryption Engine Processor. This stored mathematical key representation, which even if you could find it, and had it in hand, being one-way, it cannot be used to reverse engineer the user’s private key.
When the user enters his private key, the Encryption Engine processor, using the same algorithm, regenerates that mathematical representation and compares its new version with the original version stored in the Secure Enclave EPROM. If they match, all is well, the device gets unlocked and the full 256bit AES key is constructed. If they don’t, the user is given another chance to enter his private key, a counter is incremented, and the process is repeated.
Perhaps if Apple were to design its devices so they did have an assymetric unlock system based as you describe, then they could have a system where authorities could provide a device serial number and Apple could provide the unlocking asymmetric unlocking key, different from the user’s key. However, every single time such access has been available, especially when humans are in the mix, corruption allows the system to be compromised. Such back doors are not secure.
How secure is such a system when the holder of those keys is susceptible to blackmail, extortion, kidnapping, or bribery? How about the computer system that contains those data? Secure? Hackable? You bet that they’d be trying and likely succeeding. As one who lost money due to the Equifax breech, I won’t hold my breath. Sorry, Security is not binary. It either is or it isn’t.
The Knox implementation sounds ridiculously JV. The use of salted hashes has been around for quite some time. Nonetheless, having physical access to the phone gives the ability to programmatically drive the authentication process including the hashing stage. But as you mentioned, there are additional constraints...
Thanks for the heads-up on the Enclave chip and its self-destruct mechanism — I suppose the only deterrent to a brute force attack on the user’s password.
Also agree regarding the human factors related to a factory backdoor. But there’s really no way for us to know whether or not one exists.