Exactly how would Apple unlock the the San Bernardino phone? Will the FBI be able to reuse the tool? What does this mean to me?
Introduction
There’s been lots of news about the back and forth between the Justice Department and Apple pertaining to the order issued by the Federal District Court for the District of Central California. Apple has been directed to “provide reasonable technical assistance” to the FBI to unlock the phone. The discussion here is focused on the technical issues that exist, leaving the privacy, national security and legal issues for other discussions. Also, the information detailed here is specific to versions of the iPhone that do not have fingerprint access. See the end of the article for some comments on those later versions of the phone. Most of the information here is derived from Apple’s published security document https://www.apple.com/business/docs/iOS_Security_Guide.pdf
What is the Government attempting to do?
In the case of the San Bernardino iPhone model 5c, the investigators theoretically have two ways to access the data, both using “brute force”. The first is to directly access the storage on the phone and attempt to unlock the data by repeated guesses at the phone’s encryption key. This would be a Herculean task that is essentially insurmountable given today’s technology. The second is to use the phone’s keypad to unlock access to the phone’s encryption key. The same brute force technique would be used, but this time would (or may, see miscellaneous tidbits below) require a much more manageable task. Perhaps the Government would be willing to perform this second methodology but for the fact that the phone has further preventive measures built in. Specifically, the phone’s installed operating system provides for an increasing delay between attempts and, more importantly, may direct the phone to “automatically wipe” after 10 failed attempts.
How can Apple help the Government?
It is important to realize that increasing keypad delay and the data deletion facilities are provided by the operating system, not the device itself. As such, the phone’s ability to impose a retry delay, and the ability of the phone to self destruct can be defeated by installing a version of the operating system that does not have those features. This is the first of the two requests that investigators have made. Investigators have also requested that Apple enable the use of an external device to facilitate an automated mechanism to enter the passcode guesses. It is interesting to note that the Government has specifically not asked Apple to break into the phone or to provide a so called “back door”. The Government has only asked Apple to lower the operating system’s hurdles to a brute force attack.
Technical Feasibility
It is clear that Apple can develop a version of the operating system that removes the increasing delay and the deletion functions. It is also possible for them to facilitate the use of an external device to simulate keypad entries (although this is not as helpful as it might appear at first glance). Assuming that Apple has taken these steps, what protections exist to ensure that the software isn’t used indiscriminately? How can Apple be sure that their work doesn’t fall into the wrong hands? This leads to a discussion of code signing and the process for the installation of software on the device.
Control of the Modified Software
Apple has taken steps to ensure that the iPhone only runs software that has been ‘signed’ by Apple or a developer that Apple has vetted. In addition, the System Software Authorization requires that each individual device participates independently in the validation of the specific update to be installed. Essentially, the phone generates a one-time key and a “cryptographic measurement” for each piece of software that the phone intends to install. It sends these to Apple along with an identifier (ECID) for that specific phone. Apple validates that, for instance, the phone is not requesting an earlier version of software, it then creates a signature that identifies the specific update, the phone’s ID and the phone’s generated one-time key and returns it to the phone. The phone uses this returned value to ensure that a) the one-time key is the one that it submitted and b) the signature of the pending update agrees with the signature provided by Apple in the returned value. This allows, for instance, many phones to use the same update image, but only if that image’s signature is represented in the validation information that Apple has prepared for that specific phone.
These technologies are well thought out and have helped Apple maintain tight control over their users’ experience with Apple devices. The iPhone eco-system, while certainly not without detractors, has served Apple’s customer base well. The same technologies that have driven their successful control provide Apple with highly granular control over the software that is installed on the iPhone family of devices. Based on these technologies and implied information in their security documentation, Apple can control whether any specifically developed software can be installed on the phone. From https://www.apple.com/business/docs/iOS_Security_Guide.pdf ‘Adding the ECID “personalizes” the authorization for the requesting device. By authorizing and signing only for known measurements, the server ensures that the update takes place exactly as provided by Apple’
Given their control over the installation of software, If Apple is forced to follow the Government’s directives, they would be able to exercise the same fine-grained access to the compromised update that they do to their updates in general. In theory, they could build a mechanism to register court mandated phones and install modified software on them and maintain control of the mechanism, the code signing and the modified software.
Does This Mean That iPhone Encryption is Useless?
Given the assumption that, if directed, Apple can install software on one’s phone that compromises its security, individuals can still maintain privacy through their own diligence. It appears that Apple has engineered a system in which a phone’s data cannot be compromised without the physical device and the user’s passcode. By employing an alpha-numeric passcode instead of using the simpler 4 digit or 6 digit numeric codes, one can make their device virtually uncrackable using existing technology. Passwords needn’t be cryptic to one’s own mind or difficult to remember, they merely need to exploit the mathematical basis of cryptography to foil brute force attacks (however, passwords need to defend against social engineering driven guesses as well). See https://www.grc.com/haystack.htm and explore the difference between using “password” and “passwordAlwaysPadYourPassword” to protect against brute force attacks
Conclusion
Given the current state of their technology, Apple can assist the Government in their attempts to access locked phones. Even with the combined resources of the Government and Apple, users can set up their phones in a way that makes it impossible to brute force attack. Apple is currently in a situation that they’re likely working feverishly to get themselves out of. By moving some of the software driven parts of the Secure Enclave into hardware, it appears that they will be able to make the Government’s requests technically impossible to fulfill.
Miscellaneous Related Tidbits
Apple’s algorithm to process the passcode “is calibrated” to about 80ms, indicating that it is controlled in the hardware itself. A 6 character lower alpha and numeric password would take, on average, 2.8 years to brute force crack. For 8 characters, the average time to crack would be almost 3700 years. IOW, if the San Bernardino attacker cared about security, the device is essentially uncrackable.
https://www.apple.com/business/docs/iOS_Security_Guide.pdf
The FBI has admitted that they compromised their ability to retrieve backup information from the phone by changing the password of the icloud account that was associated with the phone http://thehackernews.com/2016/03/reset-icloud-passcode.html
Apple’s newer devices (5s and later phones) employ a separate hardware system for security related tasks called the Secure Enclave. Apple is likely targeting the Secure Enclave to support their desire to remove any ability for them to assist in efforts to decrypt a phone by migrating capabilities from software to hardware
Apple has recently hired a key developer of Signal, an open source, highly secure messaging system. https://twitter.com/FredericJacobs/status/702802104960860160
About the author