An excerpt from an Apple document:
Ray76, this is outdated BS for what we are discussing. This Apple document you so fully and accurately quoted from is DATED May 2012, Ray. Did you not notice that came from an archive? That means it is no longer valid data< Ray. It has been superseded by more up-to-date information. Or did you notice and choose to publish on FR anyway to confuse the issues? The technology which had "keys stored on device" has been long since been outdated by much more modern means of doing security.
The iOS your document is referring to is iOS 5.0, introduced with the iPhone 4S, released in September of 2011, THREE YEARS before the iPhone 5C involved in the San Bernardino Terrorism Case! The iPhone 4S would have been one of those in which the Contact list, notes, and many of the other data would NOT have been encrypted and been easily accessed with a mere search warrant akin to the "70 others" from which Apple extracted data. However, The iPhone 4S is one which can be updated to the higher level iOS versions, including iOS 9 which was running on the terrorist's iPhone 5C.
Do you DELIBERATELY LOOK for data that obfuscates the case we are talking about, or is it ignorance that leads you astray? I sincerely hope it's the latter. I think you are desperate to denigrate the truths all of us have been telling you. The KEY is NOT stored on the iPhone 5C. The A7 processor and its chip set on the iPhone 5C is far beyond what was available for the iPhone 4S.
One good thing to learn from this is how secure even these older iPhones were to break-ins, so thanks for that.
Now, try THIS instead:
Current iOS 9.0 Security Map
September 2015
"The device's unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor and Secure Enclave during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed by dedicated AES engines implemented in silicon using the UID or GID as a key. Additionally, the Secure Enclave's UID and GID can only be used by the AES engine dedicated to the Secure Enclave. The UIDs are unique to each device and are not recorded by Apple or any of its suppliers. The GIDs are common to all processors in a class of devices (for example, all devices using the Apple A8 processor), and are used for non security-critical tasks such as when delivering system software during installation and restore. Integrating these keys into the silicon helps prevent them from being tampered with or bypassed, or accessed outside the AES engine. The UIDs and GIDs are also not available via JTAG or other debugging interfaces.The UID allows data to be cryptographically tied to a particular device. For example, the key hierarchy protecting the file system includes the UID, so if the memory chips are physically moved from one device to another, the files are inaccessible. The UID is not related to any other identifier on the device. Apart from the UID and GID, all other cryptographic keys are created by the system's random number generator (RNG) using an algorithm based on CTR_DRBG. System entropy is generated from timing variations during boot, and additionally from interrupt timing once the device has booted. Keys generated inside the Secure Enclave use its true hardware random number generator based on multiple ring oscillators post processed with CTR_DRBG.
Securely erasing saved keys is just as important as generating them. It's especially challenging to do so on Flash storage, where wear-leveling might mean multiple copies of data need to be erased. To address this issue, iOS devices include a feature dedicated to secure data erasure called Effaceable Storage. This feature accesses the underlying storage technology (for example, NAND) to directly address and erase a small number of blocks at a very low level.
iOS Security White Paper, September 2015
The Passcodes are entangled with the UID, which, again, is hidden in the Secure Enclave:
"PasscodesBy setting up a device passcode, the user automatically enables Data Protection. iOS supports six-digit, four-digit, and arbitrary-length alphanumeric passcodes. In addition to unlocking the device, a passcode provides entropy for certain encryption keys. This means an attacker in possession of a device can't get access to data in specs c protection classes without the passcode.
The passcode is entangled with the device's UID, so brute-force attempts must be performed on the device under attack. A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds. This means it would take more than 5 1â„2 years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers.