Replies

The AES encrypt/decrypt system accesses those keys.

Apple says “Every iOS device has a dedicated AES 256 crypto engine built into the DMA path between the flash storage and main system memory”

They keys are in ROM. Without those keys the AES engine would be useless.

Apple also says “No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed using them.” And “Integrating these keys into the silicon helps prevent them from being tampered with or bypassed, or accessed outside the AES engine. The UID and GID are also not available via JTAG or other debugging interfaces.”

This is a half-truth. Obviously the AES firmware is reading the keys directly. And do note “Integrating these keys into the silicon” - as I’ve said: the keys are in ROM. Just because you, me, Joe down the street, can’t access the key doesn’t mean Apple can’t.

It doesn't mean Apple can, either. If Apple built it right, they can't. At least not without a lot of work.

What is needed is a way to spy on the operations of a chip in the absence of any sort of debugging API, relying solely on the laws of physics to interpret what the chip is doing, what hidden keys it is reading, etc.

Maybe the NSA could pull it off. But that would involve physically grinding away at the chips and observing the chips' operations using electron microscopy, with catastrophic failure a screw-driver slip away.

There is no need to disable encryption. Simply disabling the passcode retry counter and the timer between retries will allow the FBI to brute force the passcode. I’m not the only one to think of the method I outlined in 98, since that post I’ve come upon this article http://blog.trailofbits.com/2016/02/17/apple-can-comply-with-the-fbi-court-order/

Apple also says "No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed using them." And "Integrating these keys into the silicon helps prevent them from being tampered with or bypassed, or accessed outside the AES engine. The UID and GID are also not available via JTAG or other debugging interfaces."

This is a half-truth. Obviously the AES firmware is reading the keys directly. And do note "Integrating these keys into the silicon" - as I've said: the keys are in ROM. Just because you, me, Joe down the street, can't access the key doesn't mean Apple can't.

Here you go again. YOU turn you ignorance and assumptions into a what you term a LIE! You claim something obvious when you've built it out of your misreading, mischaracterizations, and downright IGNORANCE of how the system works to ASSUME you've got the right answer, when people like me, who DO know how it all works, have been telling you, YOU have it WRONG, that you are misapplying terminology, misapplying half-comprehended concepts, or completely misunderstood concepts, to jump to totally wrong conclusion, AND then you lecture us about YOUR rightness, and Apple's either outright lying, telling half-truths, and how we are wrong and YOU are right because only YOU can interpret things correctly! That's why we are disgusted with you.

You are entitled to your opinion, you ARE NOT ENTITLED TO YOUR OWN FACTURDS.

"Integrating these keys into the silicon" does not necessarily mean they are in a ROM as you so simplistically believe, Ray. It is, Ray, entirely possible to burn them into the encryption engine chip and the varying key algorithms into each separate encryption engine processor, which is what Apple has said they've done in their security paper. The reason the cannot be accessed outside the encryption engine is they are INSiDE the encryption engine processor. These are not accessible. Do you get it now?

Do you even have a clue what "The UID and GID are also not available via JTAG or other debugging interfaces" is or means and why it is so important in this context?

I thought not, or you wouldn't be blithering about "reading keys" from the devices. It means these UID and GID which are only PARTS of the final 256 bit AES KEY, which I told you how the device internally builds its own unique final KEY from these key parts among others, cannot even be found or read by very sophisticated external debugging tools used by system design and testing equipment!

"JTAG" is an acronym for Joint Test Action Group:

"an electronics industry association formed in 1985 for developing a method of verifying designs and testing printed circuit boards after manufacture. In 1990 the Institute of Electrical and Electronics Engineers codified the results of the effort in IEEE Standard 1149.1-1990, entitled Standard Test Access Port and Boundary-Scan Architecture.

JTAG implements standards for on-chip instrumentation in electronic design automation (EDA) as a complementary tool to digital simulation. It specifies the use of a dedicated debug port implementing a serial communications interface for low-overhead access without requiring direct external access to the system address and data buses. The interface connects to an on-chip test access port (TAP) that implements a stateful protocol to access a set of test registers that present chip logic levels and device capabilities of various parts.

The only things that can be read in system memory are the one-way HASHes which are used to check validity of the input passcode and re-calculated final AES KEY. The stored HASH of either, being the answer to a one-way algorithm, cannot be used to derive the original passcodes or actual encryption KEY which were merely the seeds input into the algorithm that generated that HASH. Therefore, HASHes are useless for either unlocking the iPhone or decrypting the data.

I've been explaining this system for years. I'm not new to it.

As I've told you numerous times, the keys to do either of those things are simply NOT stored anywhere on the iOS devices. What is stored is the means to generate the correct key IF the correct passcode is input by the user, and the HASH created by the hidden algorithm matches the stored HASH. If that condition is met, the AES crypto engine will, using another hidden algorithm, RE-CONSTRUCT the correct AES 256 bit encryption KEY from the various stored PARTS, adding the input passcode the user just input, check IT against a stored HASH, and if that checks OK, decrypt data as needed. There is no need to store the passcode or the actual AES KEY.