Apple's Crypto Battle

On the 16th of February 2016, Apple published a letter to its customers by their CEO Tim Cook. In the much publicised letter, Apple stated that it had taken the decision to oppose an "order" to produce an alternative 'law enforcement' version of the iPhone iOS software which can be used to circumnavigate encryption in the iPhone or facilitate the cracking of encryption within the iPhone (this remains unclear).

This 'order' or possibly a court writ (this is unclear) has stemmed from an investigation by the Federal Bureau of Investigation into the the San Bernardino terrorist attack of the 2nd of December 2015. In this attack 14 people were murdered and 22 seriously injured from a mass shooting and attempted bombing at a local government training event/Christmas party at a San Bernardino conference centre.

Since the release of the first iPhone, Apple has included to varying degrees, some form of encryption in its devices. Since the launch of the A7 processor (iPhone 5s) the iPhone has featured a co-processor known as the "secure enclave". This co-processor is a hardware implementation of various cryptographic functions that the iPhone uses to secure a significant amount (if not all) the user data on the device.

The secure enclave features a dedicated hardware implemented AES 256bit crypto engine with a dedicated path to the NAND mass storage. Each iPhone has a Unique ID (UID) which is "fused" into the co-processor at the time of manufacture. The UID is an AES 256-bit key that is not linked to any other identifier on the device. Apple states that it, nor any third party, stores the UID. Apple also states that it is impossible to retrieve the UID from the co-processor (however it is unclear exactly how this is the case).

The UID is used within the secure enclave to encrypt and decrypt the entire file system of the iPhone on the fly. Implementing this key in hardware means that if the NAND chips are stripped from the logic board it would be impossible to crack the file system encryption (due to the necessity of the co-processor to decrypt it, and its UID). Meaning all decryption must be done on the original device itself.

The actual act of encryption and decryption is achieved through the use of a passcode created on the device. In iOS 9, when the device is first activated, a 6 digit passcode must be created by the user to progress through the set up and to use the device.
The passcode is used in conjunction with the UID and put through a PBKDF2-AES function in the secure enclave which produces a passcode key. This passcode/UID key is actually what is passed when unlocking (decrypting) the device. Also, a time limitation is implemented in the co-processor to prevent rapid brute forcing of the passcode (a user can also activate an option for the file system keys to be wiped if the passcode it entered incorrectly 10 times, making the encrypted data irretrievable).

There appears to be at least 3 points of potential failure trust in relation to Apple's implementation of encryption in iOS devices:

• Trusting Apple and Samsung (the manufacturer) that they are not recording the UIDs of the processors.

• Trusting Apple to adequately verify and sign the firmware of its devices.

• Trusting Apple to produce firmware which does not provide a method of exfiltrating the UID from the co-processor or in some way circumnavigating the passcode/UID key or facilitate brute forcing of the passcode.

Clearly the FBI is pursuing the last of these points to gain access to the iPhone in question. It would appear that either Apple is being 'ordered' to produce firmware which they adequately sign and will run on the co-processor which could reveal the UID of the device (they have stated this is impossible) or in some way could remove the requirement to provide a passcode to decrypt the device (which seems unlikely due to the blending of the passcode and the UID). Therefore it would seem (at least to me) that the only logical option is that the FBI wants Apple to produce firmware which enables brute forcing the passcode (fairly trivial 10^6 maximum possibilities) in a reasonable amount of time.

This should be of concern to every user of an iOS device. The FBI needs Apple to produce this firmware due to the signing of the firmware and co-processor verification of that signature at boot. Apple's argument appears to be that it does not trust the FBI (probably more accurately the American Government and its intelligence services as a whole) with this capability if it were to produce it, as this hypothetical firmware, or a close derivative of it, would likely work on many iOS devices (if not all).

I believe that Apple's resistance to this "order" is not without merit. It is easy to imagine that the FBI could quickly hand over this firmware to other intelligence services.
This could cause many concerns for Apple, one of which could be that multiple governments from around the world could demand similar capability, possibly even some disagreeable governments, with less than a clean track record when it comes to the protection of Human Rights and the freedom of the press.

The result of this on-going dispute will have implications for many iPhone and iOS device users, not to mention the debate over the use of encryption as a whole.


Sources and Further Reading:

David Schuetz, "A (not so) quick primer on iOS encryption". darthnull.org: http://www.darthnull.org/2014/10/06/ios-encryption

Andrey Belenko, Dmitry Sklyarov, "Evolution of iOS Data Protection and iPhone Forensics". BlackHat Abu Dhabi 2011 presentation: 
https://media.blackhat.com/bh-ad-11/Belenko/bh-ad-11-Belenko-iOS_Data_Protection.pdf

Matthew Green, "Why can't Apple decrypt your iPhone?". blog.cryptographyengineering.com:
http://blog.cryptographyengineering.com/2014/10/why-cant-apple-decrypt-your-iphone.html

Apple, "iOS Security". apple.com: 
https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Apple, "A Message to Our Customers". apple.com: 
https://www.apple.com/customer-letter/