Laying aside your mild ad hominem, which I will choose to ignore, let's look at your very good comment.
First of all the iPhone 5C does not have a fingerprint reader, so that was not a method that could have worked. . . and even if it had one, the iPhone had been turned off when they found it. Any time an iPhone with a fingerprint reader has been turned off, the system's passcode is required to be input before the fingerprint reader will again be useable. Other lockouts are the passage of 48 hours between fingerprint or passcode access or any upgrade to the OS or change in anything in the Secure Boot chain.
My guess is that they identified where the decryption key resides on the die of the CPU ... they can figure out the zeros and ones they need using a focused ion beam setup that’s used for integrated circuit debugging and decrypt storage that way.
You are correct, except for one thing. There is no Encryption Key kept on the iPhone. Apple does not make it so simple.
Several weeks ago on FreeRepublic I described a technique that could possibly work to hack into an A6 iOS device.
This was an Apple iPhone 5C, which uses an A6 processor which is nowhere as secure as the later A7, A8, and A9 series of processor which use a Secure Element sub-processor system for securing the devices. Instead, the A6 has a location located inside the processor chip which also has a sub-processor in it called the Encryption Engine. This area of the processor is inaccessible by the A6's data processor or RAM. Inside the Encryption Engine there are several algorithms dedicated to the security of the iOS device and to encryption/Decryption of the data. Also there is a EEPROM area which can only be written to or read by the limited function sub-processor inside the Encryption Engine.
This area of the A6 was designed to be unreadable by anything running in RAM or by an external hardware probe to make it as opaque as possible to any hacker.
Stored inside the Encryption Engine from the time of manufacture of the A6 chip are a Unique Device ID (UDID) which is not recorded anywhere and a Group Device ID (GID) which is the same for all devices of that model.
One of the algorithms kept inside the Encryption Engine uses the User's passcode, of what ever number of digits or alphanumeric characters, to create a unique one-way hash which is then stored on the EEPROM. Another, algorithm creates a truly entropic random number by reading the camera, microphone, and accelerometer (and perhaps a fourth sensor), at the moment the user inputs his/her passcode for the first time, using those data as a seed, and stores that result on the EEPROM.
This results in four discrete pieces of data being stored inside the Encryption Engine:
The way the system works is that the one-way hash is calculated anew every time a user inputs his/her passcode. That newly created one-way hash is compared to the one inside the Encryption Engine by the sub-processor. If the match is made, then another algorithm in the Encryption Engine reconstructs the Encryption Key by entangling the user's passcode with items 2, 3, and 4 stored in the Encryption Engine to make a large, complex 256 bit AES encryption KEY which will allow the data on the FLASH storage to be encrypted/decrypted as needed. Thus, the
For the purposes of breaking into the subject iPhone, we need to learn just two things:
The rest of the data inside the Encryption Engine is irrelevant for our purposes, but we have to be extremely careful to not damage ANY of the data because without all of it, the iPhone is just a brick.
Focussed Ion beam and Electron Microscopy techniques have been used to read data from ICs in the past. However, their accuracy is suspect and at the small scale of these more modern chips, problematic. The other problem is that these techniques are a one shot deal. They are destructive of volatile memory. Bathing volatile memory with an electron beam or ionic stream of energetic charged particles WILL effect the charged nature of the target, altering that target's data.
That cannot be allowed happen when you have to use that target to unlock the device.
I suggested that a reflective optical laser method of some kind of could work to non-destructively read the EEPROM and trace the silicon of the Encryption Engine inside the A6. This would allow them to reverse engineer the one-way hash algorithm and also read the specific one-way hash that exists on this particular iPhone 5C.
Since they know that the iPhone requests a four digit passcode, there are only 10,000 possible combinations from 0,0,0,0, to 9,9,9,9, running the algorithm it is a easy task to construct a data base of all possible passcodes and their matching one-way hashes. Compare the database to the one found in the subject iPhone 5C from the Terrorists, and you have the passcode. Violá!
Input that four digit passcode, and Farouk's iPhone 5C Work phone is unlocked. Done.
I have no doubt that this, or a slight modification of this, was the way that Cellebrite hardware hacked into the iPhone. It is neither easy, nor cheap to do, and requires a specialized set of equipment and skills.
I was kidding ... It wasn’t meant to be an attack :-).
Thanks for posting that. I wasn’t working on anything that had to be secure when I was playing around with the FIB (I was probing an embedded EEPROM ironically) .... I am familiar with techniques to cover such embedded devices with metal layers as well as introduce traps so that if someone wanted to dig down through the metal with a FIB, they risk cutting power rails and the like. Similar techniques are implemented at the PCB level to prevent sniffing of DRAM busses hidden on inner layers of the PCB (I suspect Apple and other vendors have embedded encryption in front of the DRAM’s physical layer since they develop their own ASICs).
Anyway, I simply got sick of seeing people imply that the iPhone was hacked due to a security issue ... I highly doubted that was the case. Plus there were many people calling you out as if you were wrong about Apple’s security.