Posted on 03/12/2016 8:38:30 PM PST by Swordmaker
Thanks for your explanation, which shows you are not just some BSer. . . sp apology accepted. However, even trying the shaving routine is unlikely to get you anywhere. First of all, the AES key is not stored on the chip. It is calculated anew each time the iPhone is opened. Also the chip is a multilevel technology, so finding what you need would be quite difficult before you destroy what you are seeking. Secondly there are some volatile information stored in there you MUST have to do the decryption that will most likely not survive the process, obviating continuing the process.
Among those volatile data are the random number calculated from the combined randomized input from camera, microphone, accelerometer, and other sensors of the iPhone when the user first enters his passcode, and also the one-way HASH used to compare whether the input passcode of whatever size matches a recalculated one-way HASH to allow the startup to continue and the passcode itself to be included in re-calculating the entangled 256 bit AES key.
That key is made up of the user's passcode, which is entangled with an-recorded anywhere unique device ID, a group ID that is identical on every similar iOS device, and the above described random number stored in a dedicated EEPROM unreadable from outside the Secure Enclave or Encryption Engine by anything running in RAM, the Data Processor, or even external hardware or software probes.
As you pointed out, the only thing that might have a chance of doing what is required to learn what is needed is to reverse engineering either the Secure Enclave chip or the A6 processor with the Encryption Engine. However, Apple has designed both systems to require the decryption/encryption process be done on the iPhone due to hardware incorporation of much of the software. Without all of the hardware being present and working, it simply can't happen.
That's where you ran into your wall. Apple has not emulated the Encryption Engine or the Secure Enclave, the chips necessary, for the development community.
My hat is off to you, sir. You are an honest poster. You admitted when you were wrong. That is rare. We've had blowhards on these threads who claim they could do it and just keep claiming it. You are the first who actually made the effort and then explained and admitted his failure with an explanation that matches our knowledge. Thanks.
No, Tech guy, I wouldn't call you a fool. You have learned something. The fools are those who refuse to learn and admit their failures. You are wise. I learned to avoid this years ago. Don't be surprised if you get attacked by the fools now.
I've been trying to tell the "fools" this for several weeks now. If they study the theory behind this, they'd see it. But some of them even refuse to read the articles on how it works, preferring to stay arrogantly assured of their superiority in their ignorance, claiming that anything published contrary to their opinion had to be paid propaganda from Apple.
From my understanding, that algorithm is inside either the Encryption Engine sub-processor of the A6, or inside the Secure Enclave with its own dedicated Encryption processor. Either may or may not be hard-coded in the silicon. Apple ain't saying.
When iOS 8 first came out, there was a hack that could allow you unlimited tries. It was exactly that: powering down the system just after the passcode attempt popped up the try again screen, but before the guess counter was incremented. Slow, but it would not ever reach the tenth try. It took about two minutes between tries, so on a four digit passcode, you'd be looking at 20,000 minutes to try every possible passcode. Tedious, but do-able. However, Apple fixed that with iOS 8.2 and later.
You are right about erasing the data. It would take too long to securely erase 13 plus gigabytes or more on larger iOS devices of data even on a Flash drives, but eliminating the passcode HASH is just as effective for all practical purposes.
However, an iPhone can be reset to factory clear, with zero data, in about five minutes. Android devices have been found to be not so capable of being securely erased.
I hope you have a means of passing that key on to some other official in your company if something were to happen to you. You could be hit by a truck on the way to work, God forbid. I have the passwords only I know in a sealed envelope in the company safe deposit box, just in case.
Heh, yeah, you get it.
The password to the HIPAA key currently lives in a safety deposit box at a bank here in SF.
Thanks for the clarification. I’ve been following this as it unfolds and was curious how your hack would turn out.
Tim Cook should give him a call and say “Hey sherrif...wouldn’t you agree it would be a terrible thing if every computer in every police station in the state suddenly turned into a paperweight at the same time that the names and addresses of every officer in the state, active and retired, was published on a half dozen different deepnet sites?”
Holy sh!t. You really, REALLY gave it your all attempting to back up your claim, complete with easily understandable technical explanations of every step. I give you massive props for putting your money where your mouth is.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.