Apple vs. Law Enforcement – iOS 4 through 13.5

May 14th, 2020 by Oleg Afonin
Category: «Mobile»

Today’s smartphones are a forensic goldmine. Your smartphone learns and knows about your daily life more than everything and everyone else. It tracks your location and counts your footsteps, AI’s your pictures and takes care of your payments. With that much data concentrated in a single device, it is reasonable to expect the highest level of protection. In this article, we’ll review the timeline of Apple’s measures to protect their users’ data and the countermeasures used by the law enforcement. This time no cloud, just pure device forensics.

“Now, we have a deep respect for law enforcement, and we work together with them in many areas, but on this issue we disagree. So let me be crystal clear — weakening encryption, or taking it away, harms good people that are using it for the right reasons. And ultimately, I believe it has a chilling effect on our First Amendment rights and undermines our country’s founding principles.” (Tim Cook, 2015)

So let us see in retrospect what Apple was doing over the years to protect their users’ privacy and security. This article is part of the “Apple vs. Law Enforcement” series. In case you missed it, check out Cloud Forensics and Cloudy Times.

iPhone OS 1 through 3: easy-going

In these initial versions of iOS Apple didn’t care about security. No encryption, easy passcode bypass, little security. Truth to be said, there wasn’t much going on in the first iPhones, so there wasn’t much to protect in the first place. Jonathan Zdziarski discovered the way to extract full file system even from locked devices, see iOS Forensic Investigative Methods for details.

Devices released:

  • iPhone OS 1.0 – iPhone
  • iPhone OS 2.0 – iPhone 3G
  • iPhone OS 3.0 – iPhone 3GS

iOS 4: file system encryption

Prior to iOS 4, the data in the iPhone was stored unprotected. A simple removal of the storage chip would give access to the entire set of user data. Note that the file system encryption was based on a hardware key; the user’s passcode was not required to decrypt the data. As a result, Apple was still able to access the content of such devices when serving legal requests.

We at ElcomSoft were the first to break in to devices running iOS 4.

Devices released:

  • iOS 4.0 – iPhone 4
  • iOS 5.0 – iPhone 4s
  • iOS 6.0 – iPhone 5

iOS 7: pairing with notifications

Little had changed in the security department between iOS 4 and iOS 7. The only notable change introduced in iOS 7 was the new pairing process with a notification pop-up on the iPhone. The user had to tap on the notification box to confirm pairing. Apple was preparing for a big update in iOS 8.

iOS 7 was also the first iOS release empowering the first 64-bit iPhone equipped with a fingerprint scanner and Secure Enclave.

Devices released:

  • iOS 7.0 – iPhone 5s, the first 64-bit iPhone equipped with Secure Enclave

At the same time, Zdziarski discovered a kind of backdoor on iOS devices, see Apple Confirms “Backdoors”; Downplays Their Severity for further information. We are still using some of these services in Elcomsoft iOS Forensic Toolkit.

iOS 8: encryption using passcode; passcode cracking does not work anymore

iOS 8 was a landmark in security. In this version of iOS, Apple had changed almost everything about the iPhone security model.

Devices released:

  • iOS 8.0 – iPhone 6 and 6 Plus

Let’s start with logical acquisition.

Prior to iOS 8, Apple used to create a static pairing (lockdown) record for every iPhone it sold. The pairing record was retained by Apple. The static pairing record would remain the same even between factory resets. Once paired, the device could not be “unpaired| from the computer. Obviously, such lockdown records had never expired. This enabled Apple to cooperate with the law enforcement. Once Apple received a (locked) device, the company was able to extract it and to provide the image to the requesting agency.

This behavior had changed with the release of iOS 8. Pairing records were made unique. When processing a pairing request, iOS would now generate a fresh pair of keys, storing one key in its internal storage and another on the target computer. Destroying either key would render the pairing invalid, thus disallowing the connection.

This change alone was severe enough, but Apple was not stopping there. Instead of the file system encryption backed by static hardware credentials, iOS 8 now used an encryption scheme based on the user’s screen lock passcode. The key encryption key was now dynamically generated the first time the user unlocked their device with a passcode after a cold boot or when powering on. Changing the passcode would re-create and re-save the key encryption key. As a result, no one, Apple included, could decrypt the full file system of a ‘cold’ (Before First Unlock in today’s terms) device without knowing the user’s passcode. Note that some parts of the file system were still accessible to allow the iPhone to fully boot; this included some logs and system databases. Those bits and pieces could still be extracted without the passcode.

As you can see, the passcode started becoming the hallmark of Apple’s security model. In iOS 8, the company targeted the many passcode cracking boxes that were available on the market at the time. A single update momentarily disabled the ability to break passcodes in all of the boxes that existed at the time. It took several years for computer forensic companies to develop new, brutally more complex solutions.

Note that prior to iOS 8, Apple was able to perform iOS data extractions. But Apple’s guidelines for law enforcement requests now clearly states:

For all devices running iOS 8.0 and later versions, Apple is unable to perform an iOS device data extraction as the data typically sought by law enforcement is encrypted, and Apple does not possess the encryption key. All iPhone 6 and later device models are manufactured running iOS 8.0 or a later version of iOS.

One more thing introduced with iOS 8 was Restrictions. A separate, user-configurable Restrictions PIN (always 4 digits) could be used to restrict certain device activities.

iOS 9: default 6 digits

iOS 9 had one notable change, now using 6-digit passcodes as default when setting up new devices. It was still possible switching back to the old 4-digit PIN, but the process of doing so was gradually made less obvious with each new iOS release.

Devices released:

  • iOS 9.0.1 – iPhone 6s and 6s Plus

iOS 10: shortened lockdown lifetime

Before iOS 10, pairing records (lockdown files) had almost never expired. We were able to use lockdown records created some 6 months ago. With many forensic vendors (including us) relying on existing lockdown records for logical extraction, Apple started viewing lockdown records as a threat. iOS 10 had severely cut the lifespan of the lockdown files. No official statement was made at the time, but later on it became known that iOS 10 and up were invalidating pairing records after 30 days they’ve been used last.

iOS 10 was also a huge step back in one regard. Starting with iOS 5 (or iOS 4 even), Apple had used the same algorithm for verifying backup passwords. Some 20,000 hash iterations were used to produce the encryption key from the user’s password. This was slow, but acceptably slow. However, in iOS 10, some intern had accidentally created a backdoor. This backdoor used a single hash iteration, which allowed us to create an attack with a speed of tens of millions of passwords per second.

Devices released:

  • iOS 10.0.1 – iPhone 7 and 7 Plus

iOS 10.1: backup password security: Apple fixes the backdoor

The backup password backdoor introduced in iOS 10.0 was patched in iOS 10.1; we’ve received the corresponding acknowledgement in the release notes for discovering the issue.

iOS 10.2: backup password security goes overboard

After careful consideration, Apple decided that slow was not slow enough, and severely increased the number of hash iterations required to produce the backup encryption key out of a password. Since then, CPU-based attacks result in about a dozen passwords per minute, while GPU-assisted attacks demonstrate recovery speeds of about 100 to 200 passwords per second (single GPU). Essentially, this is the end of brute-force for anything but the simplest passwords.

iOS 10.3: APFS transition

With the release if iOS 10.3, Apple converted all devices to the new, solid-state storage optimized file system called APFS. The new file system required forensic vendors to update their forensic packages.

iOS 11: pairing requires passcode

iOS 11 brought two notable changes to the device security model. First, Apple introduced a way to reset the backup password from the Settings app on the iOS device. Resetting the backup password requires the user to enter their screen lock passcode; the role of the screen lock passcode is thus increased significantly. We believe this is a huge step back, going from multi-layered security model to one based solely on the user’s passcode. We wrote an article about the issue: iOS 11 Makes Logical Acquisition Trivial, Allows Resetting iTunes Backup Password (if you know the passcode).

Devices released:

  • iOS 11.0 – iPhone 8 and 8 Plus
  • iOS 11.0.1 – iPhone X

One more step towards establishing the total domination of the screen lock passcode over all other security measures was the new requirement to type in the passcode when pairing with new computers.

There is one more thing related to pairing records. Apple has officially confirmed the expiry rules for the lockdown/pairing records.

The pairing process requires the user to unlock the device and accept the pairing request from the host. In iOS 11 or later, the user is also required to enter their passcode. After the user has done this, the host and device exchange and save 2048-bit RSA public keys. The host is then given a 256-bit key that can unlock an escrow keybag stored on the device (refer to “Escrow keybag” within the Keybags section of this paper). The exchanged keys are used to start an encrypted SSL session, which the device requires before it will send protected data to the host or start a service (iTunes syncing, file transfers, Xcode development, etc.). The device requires connections from a host over Wi-Fi to use this encrypted session for all communication, so it must have been previously paired over USB. Pairing also enables several diagnostic capabilities. In iOS 9, if a pairing record hasn’t been used for more than six months, it expires. This timeframe is shortened to 30 days in iOS 11 or later. (Source: iOS Security Guide May 2019 edition, iOS 12.3).

iOS 11 also brought us the new S.O.S. mode, which, once activated, disabled biometric unlock. In addition, notifications were no longer stored in backups (this fixes the loophole allowing to peek in the user’s secure communications by analyzing old notifications – which, by the way, would not appear on the device itself). Other minor changes in iOS 11 security model are covered in the New Security Measures in iOS 11 and Their Forensic Implications.

iOS 11.4.1: USB Restricted mode introduced

The release of iOS 11.4.1 introduced USB Restricted mode, a feature designed to defer passcode cracking tools such as those developed by Cellerbrite and Grayshift. iOS 11.4.1 automatically switches off USB data connectivity of the Lightning port after one hour since the device was last unlocked, or one hour since the device has been disconnected from a USB accessory or computer. In addition, users can manually disable the USB port at any time by engaging the S.O.S. mode.

iOS 12: USB Restricted mode enhanced, Restrictions now Screen Time

iOS 12 takes USB restrictions one step further. According to the new iOS Security guide published by Apple after the release of iOS 12, USB connections are disabled immediately after the device locks if more than three days have passed since the last USB connection, or if the device is in a state when it requires a passcode. In addition, the USB port is also disabled if the user engages the S.O.S. mode.

“In addition, on iOS 12 if it’s been more than three days since a USB connection has been established, the device will disallow new USB connections immediately after it locks. This is to increase protection for users that don’t often make use of such connections. USB connections are also disabled whenever the device is in a state where it requires a passcode to re-enable biometric authentication.”

In addition, iOS 12 introduces Screen Time, a new system based on iOS Restrictions that existed in iOS 9 through 11. Some time later, Screen Time could be synchronized through iCloud.

Devices released:

  • iOS 12.0 – iPhone Xs and Xs Max
  • iOS 12.0 – iPhone Xr

iOS 13: changing backup password requires passcode; USB Restricted mode improved again

With the release of iOS 13, Apple announced a major overhaul to iTunes, the only ‘official’ app to make local backups of iOS devices. In macOS Catalina and newer, local backups are created in the Finder app instead of iTunes. No more iTunes on the Mac.

Devices released:

  • iOS 13.0 – iPhone 11 Pro and 11 Pro Max
  • iOS 13.0 – iPhone 11

When you set or change a password protecting a local backup, you will now be prompted to enter the screen lock passcode on the iPhone. Similar to new pairing requests (since iOS 11), you’ll need to enter the passcode on the device itself.

What about USB restrictions? iOS 13 brings a sort of “pairing” of accessories to the iPhone. In order to “pair” a computer, you would need to enter the PIN code on the iPhone; the devices would then exchange cryptographic keys to enable the transfer of data (including pictures). “Pairing” an accessory is a single-sided process that does not require the PIN code and does not involve cryptographic keys. An accessory is “paired” to the iPhone when the user first connects it to the iPhone while the device is unlocked (or by unlocking the iPhone after connecting the accessory). The iPhone will then store information about the “paired” accessory and assign that accessory a “trusted” status.

USB restrictions in iOS 13 are different for “paired” and “new” accessories. In iOS 13, data communications over the USB port (Lightning connection) are restricted after one hour since the device has been locked or since the user disconnects a previously used accessory.

What’s new here is how iOS treats “paired” and “new” USB accessories. If the user attempts to connect a previously paired USB accessory, the connection will be established during the one-hour period.

If, however, the user attempts to connect a new accessory that was not previously “paired” with the iPhone, the USB port will be locked down immediately even if the connection attempt is made within that one-hour period.

In addition, unencrypted local backups no longer contain the call history and Safari browsing history.

Hardware Exploits

A large-scale hardware exploit was discovered in all 64-bit Apple devices ranging from the iPhone 5s all the way to the iPhone 8, 8 Plus and iPhone X generation of devices (including the iPad and Apple TV models equipped with similar processors). The checkm8 exploit and the checkra1n jailbreak can be installed on locked devices via DFU even if the passcode is unknown. The exploit allows performing a limited file system and keychain acquisition from locked devices and extracting the full file system and keychain from any vulnerable device regardless of the version of iOS if one knows the passcode. Note that neither the exploit nor the jailbreak can help cracking the lock screen password.


In conclusion, I want to quote Dan Scalco from Digitalux. “One of the biggest challenges businesses find themselves in is balancing consumer privacy, security, and convenience. More convenience often leads to lower levels of security and thus privacy. A good illustration of this would be two-factor authentication versus a weak password. Obviously two-factor authentication is a more time-intensive user experience but it provides much more security and privacy over the opposite, a weak password. Privacy, security, and convenience each need to be prioritized. However, at the end of the day, one reigns supreme…. Security.”