deadhacker.com

Update2: Apple responded to a request for clarification in a rather noncommittal manner. Until they clarify or until I have a chance to test the attack I would assume it effects the current iPhone 6 hardware and possibly the to-be-released iPhone 7 hardware as well.

Update: This was published only a few days before the news that the FBI cracked the iPhone. So it is highly unlikely that the information disclosed here was used by the FBI or their hackers. But based on recent information I think the attack described here, in my obviously biased opinion, seems increasingly probable. Note: This method should not be confused with NAND Mirroring discussed elsewhere. Also, this attack may apply to the latest iPhones as well.

Summary

Encryption of the iPhone file system involves 3 secrets. Think of it like a box that has 3 padlocks on it. You need to control all 3 to access the device. To wipe the device Apple only has to change one of them. The padlocks are: 1. A [passcode] which is stored in your own mind. This is exactly what the FBI wants to know. 2. A [device specific secret] that is stored deep within the processor and cannot be extracted. 3. A [file-system key] which is stored on a memory chip sitting near the iPhone’s processor.

To wipe an iPhone the last key, [file system key], is modified but because it is stored on a separate memory chip we can prevent the wipe by sitting between the processor and the memory chip. Whenever the processor starts a wipe we can detect this and drop that specific write request to the external memory chip. This prevents a wipe but to unlock the phone and access files we still need to guess the [passcode]. Because the [device specific secret] is difficult to extract all [passcode] guessing has to take place directly on the phone we wish to attack. To complicate matters the phone increases the time required between [passcode] attempts after 5+ attempts. So to speed things up we will instigate a fake phantom wipe to reset the delay/counter. Thereby we have prevented a wipe and made guessing the [passcode] as fast as possible. Provided the [passcode] isn’t too complex, unlocking the phone should be definite.

Preventing this attack would require storing the [file system key] and passcode attempt counter+delay internally in the processor. If the current iPhone processor does not support this then a solution may not arrive before iPhone 7. If current hardware does support this Apple need to update their iOS Security documentation. If the solution described is not already implemented Apple may need to release a new iOS version.

Technical Detail

Various experts have looked at the iPhone 5c security and considered how the FBI would go about trying to break into the device to obtain the contents of the phone. A few in particular I enjoyed reading, such as Olivier Thomas on chip reverse engineering attacks and Mike Ash’s review of the iOS security architecture.  I have not seen much discussion of embedded attacks and after going over Apple iOS Security documentation (archive) I suspect there may be one worth considering.

The embedded attack that comes to mind involves preventing a wipe of memory and file system contents at the hardware level and then using a well timed wipe to reset the passcode attempt counter and delay. Mitigation of such an attack may hinge on how the [file system key], the passcode attempt counter and delay are stored. Apple’s iOS Security document does not provide enough detail to rule out this attack.

The iPhone encrypts files using a series of keys with one of particular interest: the [file system key]. This key is generated on installation and on every wipe by the [Secure Enclave] internal co-processor. The key is stored in [Effaceable Storage] on NAND flash. Reading out the contents of a flash chip is a rather trivial process ^{(desolder, reball, breakout, arduino code).} To prevent one from reading the [file system key] and decrypting files another part of the encryption scheme uses a [class key] which is derived in part from the user [passcode] and the device unique [UID] that is stored internally in the processor. This prevents decryption without physical possession of device but does not prevent the attack discussed here.

Preventing a wipe of the file system contents is the strait forward part. A wipe works by deleting the [file system key] and writing a new one in its place, effectively making all files inaccessible. When the [Secure Enclave] generates the new key it will eventually send a write command to the NAND chip to store the new key and delete the old. A wipe can be prevented by building a hardware NAND proxy that allows read commands through but drops write commands. If for some reason there are essential elements in the boot process prior to user [passcode] entry that require writing to NAND, the proxy could be timed to allow certain write commands through and others not.

The last part of the puzzle is preventing the passcode attempt counter from hitting a threshold that causes a wipe. Based on the assumption that this counter is stored in [Effaceable Storage] on the NAND chip the ACLU proposed overcoming the attempt threshold by manually removing, re-flashing a backup copy and re-socking the flash chip after each breach of attempt threshold. Brute forcing the passcode with the handy work required would be infeasible. However, with a NAND proxy in place the hand work can be removed by automating the re-flashing process. One would still need to account for the time added with each re-flash. So I propose a different method to handle the attempt threshold.

The documentation does not specify how the passcode attempt counter is stored. If the counter is stored internally in the processor then instigating a wipe should/could reset the counter. If the counter is stored on NAND as the ACLU assumes then the proxy could be timed to drop all writes except the one that resets the attempt counter. In this manner an attacker causes a phantom wipe that may reset the counter, and the attempt delay, without deleting the [file system key] in the process.

So in theory, and with some testable assumptions, a wipe can be prevented and [passcode] brute forced.

Mitigation

The clearest mitigation is to move the [file system key] into internal memory of the processor. I do not know if current iPhone hardware supports this. If it does not then iPhone users should set longer passcodes until iPhone 7 which may not arrive for a year or more.

Perhaps a simpler mitigation would be for the [Secure Enclave] to re-encrypt (wrap) the [file system key] + attempt counter + delay together on every user [passcode] attempt. Actually, now that I said it out loud that makes no sense. Preventing NAND write via proxy would prevent attempt counter or delay increase as well. I suppose a mitigation would be to write the counter on every attempt but retain it also in memory, then on next attempt read counter from NAND and confirm it matches what was last written. Of course at this point we are using the counter just to detect the existence of a NAND proxy. There are probably more integral parts of the system that can be used to detect a proxy but they may all turn into a cat & mouse game with the proxy’s selective blocking timer.

Another mitigation that would not prevent an attack entirely but may increase the effort required would be to detect latency between flash operations to force operation to happen at the maximum read/write speed. This is similar to methods used in anti-fraud schemes to detect the use of network proxies on the internet. This would force an attacker build a high-speed proxy making the attack slightly less trivial.

Finally, though I have dealt with a lot of NAND in my life perhaps I missed one out there that provides a secure paired protocol? I would be happy to hear about it. Even better to find it detailed in manufacturer documentation such as Apple’s.