• The rise and fall of physical acquisition
• Jailbreak to the rescue
• In the shade of iCloud
• iCloud Keychain acquisition hits the scene

iOS 11 has arrived, now running on every second Apple device. There could not be a better time to reminiscent how iOS forensics has started just a few short years ago. Let’s have a look at what was possible back then, what is possible now, and what can be expected of iOS forensics in the future.

Logical Acquisition: the Backups

iOS system backups are (and always were) the fastest and easiest way to obtain most data from the iPhone.

iTunes compatible iOS backups are a fantastic feature. Nothing comes close to it in Android land, even in Android 8.0 Oreo. ADB backups? Extremely limited and cannot be restored (don’t believe us? Try backing up your phone with “adb backup” and restoring it with “adb restore” after a factory reset; you’ll be surprised). Vendor-specific backups? They are even more limited in compatibility (often working not just for the same brand/model, but only for the same version of Android).

With iOS, you get the exact copy of device data. Once restored, you will not find any differences with our old (lost, stolen or broken) phone. Everything will be there, including call logs, internet history, saved credentials to most email accounts, social networks and instant messengers and pretty much everything else like online banking (this is app-specific, and some developers of sensitive applications – such as two-factor authentication apps – choose to re-authenticate after being restored from the backup).

When you see a forensic company claiming support for “iPhone logical acquisition”, bear in mind that they simply mean they can do an iTunes backup. Yes, that’s right: some forensic tools make backups through iTunes drivers, while others use the open-source libmobiledevice library. The end result is the same. Why? Because these tools do not actually make a backup. The backup is made inside the iOS device, and simply streamed to the computer through the Lightning port.

Technically speaking, iOS has a special backup service running. The role of iTunes (or that open-source library) is simply connecting to that service and sending the “backup” command. If a backup password is set (see below), then the service returns an encrypted stream, and there is exactly nothing the app (iTunes or library) can do about it.

A Word on iTunes Backup Encryption

Starting with iOS 3, iTunes backups may have a password – just like the Office documents or ZIP archives. Yet, there are two very special things about iTunes backups.

First, the backup password is the property of the device and not of the backup file (well, the iTunes backup is normally split to multiple files, but in this context it doesn’t really matter). What does that mean for us? If you set a password on one computer (the iPhone must be connected to that computer), all future backups you make from that iPhone will be encrypted with that password regardless of the tool or computer you use to make the backup. Now, if you want to change that password, you’ll need to type the old one first.

How does it affect iPhone forensics? If you have a device to acquire and even if it is not locked with a passcode but has a backup password set, all you’ll get will be the encrypted backup. As a result, you’ll have to break that password first using brute-force or dictionary attacks. Prior to iOS 8 there were alternative ways to access most iPhone data by some other means, but that’s no longer possible for iOS 9/10/11.

Breaking the backup password is a time-consuming task. In iOS versions 4 through 10.1, Apple used 10,000 iterations of (pbkdf2) leading to recovery speeds of several thousand passwords per second on a PC, or up to 200,000 p/s on a modern video card.

We discovered a serious weakness in iOS 10.0. In addition to the standard protection method, the backup would include a different, much easier to break hash of the password. This allowed us to try several billion passwords per second even on a CPU. Apple fixed that in iOS 10.1 by removing the weak hash, and further hardened password encryption in iOS 10.2. As a result, today we can only try several passwords per minute on a CPU, and up to a hundred passwords per second using a GPU. That makes backup passwords almost unbreakable (unless one is very short or simple).

Second, backups created with and without password have a major difference in how they handle encryption of the keychain and some other critical data (such as related to Health). Keep reading to learn about keychain secrets and the difference between backups with and without a password.

Trust Relationship

Can anyone just plug the iPhone to the PC, push a button and make a backup? Of course, Apple has some measures preventing a random person from capturing information from the device. When you connect the iPhone to the computer for the first time, you’ll have to unlock the device first, before a backup can be created, and establish a trusted relationship between the phone and the computer.

It may sound simple, but what is behind the “Trust this computer?” prompt? While establishing a trusted relationship between the phone and the computer, a pair of encryption keys is created: one on the iPhone, and the other one on the computer. If both keys are there, there will be no prompt and no need to unlock the iPhone for all further backups; the “trust relationship” has been established.

Prior to iOS 7, there was no prompt on the device, and the trust relationship was established automatically once the device was connected to a computer. That created a huge security risk. Have you ever heard of “malicious charges”? One might think to connect an iPhone to a charger (in a public place like an airport, restaurant etc.), but in fact there was a computer behind that could silently pull all the data from that iPhone, and even install malicious software to the device. Scary.

In iOS 7, a serious improvement has been made: from now on, the system detects whether the phone connected to a simple charger or a computer. For USB power, it simply starts charging without pairing. If a computer is detected, the system prompts “Do you trust this computer”? Still, many people do not pay attention to that and simply tap “Yes” all the time. Welcome to the world of new and improved malicious charges that have a sign: “Press [Trust this computer] for faster charging”. I’m sure a lot of folks will just tap “Trust”.

Starting with iOS 11, establishing trust relationship requires a passcode: Touch ID alone is no longer sufficient. We covered Apple’s new policy here.

There are some other issues related to trust relationship; we covered them in our recent Can You Unlock That iPhone? article.

iPhone/iOS 4: The Good Old Times

Let’s start with history (you can skip that part if you are familiar with physical acquisition).

We’re not going to talk about iPhones prior to the 4^th gen, and we’ll skip iOS 1 to 3 simply because there was no encryption there, and passcode protection was also not an issue.

Starting with iOS 4, iPhone acquisition became a headache for forensic investigators. The old ‘Zdziarski’ method no longer worked.

We were the first to develop a method of breaking into the iPhone 4. Exploiting vulnerabilities in the bootrom code, this method of ours would load our own system image into device memory, obtain the encryption keys, image the disk and decrypt the image. As a result, we could obtain the complete dump of the device in a form of DMG image that could be easily mounted in macOS or analyzed with any third-party software.

The best thing about bootrom is that it is read-only. This means that there could be no software (iOS) update to block this acquisition method.

Our method worked even for passcode-locked devices. At that time, the keys needed to decrypt most (though not all) files on the device did not rely on the passcode. Instead, the encryption was based on a device-specific hardware key we have found the way to extract. This method was completely forensically sound, i.e. did not change anything on the device, resulting in a clean, easy acquisition.

It was also possible to actually crack the passcode. As opposed to the usual password encryption where we can run an offline attack on fast hardware, iOS used a smarter password protection approach without workarounds. The password verification function is built in into the device hardware, and works as a “black box”. Passcode attacks were really slow, in the range of about 5 passcodes per second. That would allow breaking a 4-digit (default) passcode less than half an hour. Cracking a longer (and/or more complex) passcode would take significantly longer, if at all possible.

Why the passcode is ever needed if we can image the device regardless the passcode existence?

It is hard to say why, but Apple decided to use stronger protection for exactly two things. In order to get access to them, you would need to use the passcode in addition to the hardware key mentioned above. So what are those two things? First, the downloaded email messages. Second, the keychain. This situation has only changed in iOS 8.

Keychain

The keychain is system-wide storage (available also in macOS) designed to keep the most sensitive data such as passwords, encryption keys, authentication tokens, and credit card numbers.

iOS offers no UI to view the keychain contents, and making one is not possible for a third-party developer. The reason is simple: each application can only access its own data in the keychain and not system records or any other app’s data, for obvious security reasons (otherwise, malicious app could steal your credentials).

Keychain records may have different security classes (attributes), here are the options:

• kSecAttrAccessibleWhenUnlocked
• kSecAttrAccessibleAfterFirstUnlock
• kSecAttrAccessibleAlways
• kSecAttrAccessibleWhenUnlockedThisDeviceOnly
• kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
• kSecAttrAccessibleAlwaysThisDeviceOnly
• kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly

The names are self-explanatory, but if you need more details, please refer to Apple’s developers manuals. In a nutshell, the protection class specifies at which point a certain keychain item should be unlocked and at which point it becomes available to the system.

There is also the kSecAttrSynchronizable attribute that specifies whether the given key should be synced with iCloud or not.

To Password or Not To Password?

There is a note about iTunes backups in Apple Knowledge Base (https://support.apple.com/en-us/HT205220) saying: “Encrypted iTunes backups can include information that unencrypted iTunes backups don’t: Your saved passwords; Wi-Fi settings; Website history; Health data)”.

The above statement is not technically correct. In fact, the contents of iOS system backups with and without a password is the same. There is only one difference: how the abovementioned data is encrypted. In iTunes backups that do not have a password, the encryption is based on a hardware-specific key that is unique to every iPhone. That hardware-specific key is permanent, and remains the same even after a complete factory reset. By the way, we have a similar situation for iCloud backups (there are, however, some other differences as well).

For password-protected backups, most of the data is encrypted using a user-specified backup password only. As a side effect, backups that don’t have a password can be only fully restored onto the same device they were made from, as some information will not be decryptable. However, if you are planning to restore the backup onto a new device, it is to your benefit to make a backup encrypted with your own password. This way, all data such as saved passwords etc. will be restored as well.

This is how it works from the “consumer” point of view; but it is also very important for forensics. If the device does not have a backup password, it is highly recommended to specify one before you perform logical acquisition. That way you will get the full set of data after the acquisition, and will be able to decrypt everything (or almost everything) using the password that you know.

If the password is already set by the user and you don’t know it, there is no way to remove or reset it without typing the old password first. This means you will inevitably have to go through time-consuming brute-force and dictionary attacks in order to recover the password (see above on password strength and recovery speeds).

Physical Acquisition: What’s The Deal?

Physical acquisition is the only method that could create an exact copy of the iPhone storage. It’s similar to ‘dd’ for traditional hard drives. There is in fact quite a lot of data that is not included into iTunes backup.

First, there’s location data. iOS tracks your every move. Check out [Settings] | [Privacy] | [Location Services] | [System Services] | [Significant Locations] (or [Frequent Locations] if you are running iOS 8 to 10). We have no idea how these locations are selected among others; it looks like iOS keeps tracking where you spend more time than just a few minutes (traffic jams don’t seem to be included). Home and office are always there, with exact times for each day you spend there. This history goes back up to 50 days (older records are apparently deleted).

Second, all connections to 2G/3G/4G networks are logged. This information is not about your location, but about the location of cell network points around you.

Apart from locations, downloaded mail is also available exclusively through physical acquisition.

There is much more. For example, there’s the third-party app data: developers can opt-out (and usually do) from including app working sets into local and iCloud backups. A good example is conversations in messengers such as Skype and Telegram.

Last but not least, there are logs. They might be used to recover the complete information about device usage: application start and shut down events, all kind of internet connections, switching between apps, processor/data/network usage, crashes and more. There is unfortunately no software on the market for log analysis, but they are reasonably easy to parse.

You may wonder about deleted data. For iOS, no carving across unallocated space can be performed starting with iOS 4. While the actual data is still there, it is encrypted. Once a file is deleted, its encryption keys are being wiped, and there is absolutely no way to decrypt that file. It’s the same way once the devices has been reset. What you can recover is not the files (like photos), but some deleted records from SQLite databases (the most common format in iOS). It’s troublesome and not always possible, but quite often gives a good result – for example, with SMS messages.

Things Are Getting Worse: iPhone 4S through iPhone 5c

In iPhone 4S, Apple fixed the bootrom vulnerability. Since then (and up to the latest iPhone 8 and iPhone X), no new public discoveries have been made. There are of course rumors that some three-letter agencies may still have a few.

For mere folks and humble law enforcement professionals, this means that once the device is passcode-locked, there is nothing we can do anymore (unless the device is already jailbroken).

End of the game? Not exactly. If the passcode is not set or known (I’m not the one to ask how exactly it was obtained), we still need physical acquisition in order to obtain additional information from the device.

From now on, this is the way to go is:

• Make a (password-protected) backup
• Install a jailbreak yourself
• Perform physical acquisition as you’ve always done

Jailbreak is not the only requirement. You will also need to install OpenSSH in order to be able to connect to the device (some jailbreaks already include an SSH client, in which case you won’t have to do this extra step). What we do next is upload our software (in fact, two small utilities) into the device and run them to do what we did to iPhone 4: making device image, extracting encryption keys, decrypting the keychain (fully and completely, including hardware-encrypted records with ThisDeviceOnly attribute) and decrypting device image.

This method is not forensically sound because it makes quite a lot of changes to the device. Still, this is the way to go to extract as much data (read: evidence) as possible.

Passcode Cracking: The Hardware

What if the device (iPhone 4S or newer) is protected with a passcode and you cannot install a jailbreak? There are some devices on the market that might be able to break the passcode. The best known device is IP-BOX; there are others as well. Unfortunately, all of them rely on iOS bugs and known vulnerabilities, and the latest version of iOS they work for is iOS 8.2. There is no guarantee of any kind: some of these device cannot deal with “Erase data” (after 10 unsuccessful attempts), and you risk losing the data forever. Since password verification is still done on the device, passwords longer than 4 characters cannot be cracked in a reasonable time.

In short, these devices might work. Sometimes. For older devices, especially those running iOS 7, you have a real chance, but think twice if you can afford the risk to have all the data completely wiped if something goes wrong. Use these boxes as a last resort.

There is a different kind of boxes that might even work for iOS 8 to 10 (but not iOS 11). For these boxes to work, you’ll have to put the iPhone in DFU mode first, and then initiate a software update process. This process usually deletes user data, but there is a way to update system partition only. At some point, the iPhone asks for a passcode, and at this time the Erase Data (after 10 failed attempts) option is not active; neither the pause between attempts is being increased. However, password verification speed is dreadful: 5 minutes or so per password. Just over a month for a 4-digit password. There is no reliable data on the speed though, as some users claim they’re getting the speed of 5 seconds (not minutes) per password, which means about 14 hours for the same task. Just remember that iOS 10 sets default passcode length to 6 digits, which would take about two month at 5 seconds per password. While this may appear reasonable, just mind the risks; it is quite easy to get the iPhone bricked.

64-bit Devices with Secure Enclave

In 2013, Apple released the iPhone 5S. This was the first model equipped with a fingerprint reader (TouchID), but that by itself was not as innovative as it may seem. Similar but inferior scanners were available in Android devices years earlier. The true innovation was Secure Enclave, a special chip intended to make the iPhone even more secure.

You can read the technical details somewhere else, but in short, Secure Enclave has severe effect on physical acquisition. Even with jailbreak and OpenSSH, the encryption keys required to decrypt the device image and keychain cannot be extracted from the device as they are well protected by Secure Enclave.

What we can do now? Still a lot. Instead of imaging the device, we can acquire the complete copy of the file system. The only thing that remains encrypted is the keychain. This means no keys, no passwords, and no credit card numbers. The rest is there, including location data, application files, internet cache, logs and more.

What about the keychain? You can still extract (and decrypt) it by performing logical acquisition (backup with password) before you do physical acquisition.

One more thing about iOS data encryption. Starting with iOS 8, most data on the device is encrypted the same way as keychain records, i.e. based on a combination of a hardware-specific key and the passcode. Even if we could somehow gain access to the firmware signing key from Apple themselves in order load our own code into the device, and even if there is a tethered jailbreak for all iOS versions, we could still get almost nothing without the passcode. Even Apple themselves cannot do anything. Considering the fact that the passcode is protected with Secure Enclave, it’s a dead end.

A Word on Apple Touch ID

I’m often asked if Touch ID (and now Face ID) is more secure or less secure than a good old passcode.

The only purpose of Touch ID is convenience. It does not make the device more secure. Instead, it makes your device security a little weaker.

First, it is theoretically possible to create an artificial fingerprint. While this is not a commonly-used technology, a usable proof-of-concept exists.

Second, you may be forced to unlock your device with your fingerprint. In some jurisdictions, it might be easier for the law enforcement to fingerprint a person as opposed to making them confess their passcode.

However, a passcode is always required after a reboot. You will be also prompted for a passcode if you did not unlock the device in 48 hours or after three unsuccessful attempts of unlocking with a fingerprint. Some other restrictions apply. Moreover, in iOS 11 Apple further hardened security, you can read about our findings here.

Cloud Acquisition: A New Hope?

If you get a device without a passcode and can install a jailbreak, you are in luck. This, however, is not what we usually get. The common situation is an iPhone that is locked with an unknown password; more often than not, in a powered off state (meaning that even a lockdown record won’t help much).

Everyone is familiar with iCloud backups. Many iPhone customers don’t even care about local backups nowadays, and rely solely on iCloud backups. With cloud backups, there is no need to connect the device to the computer. You just need a Wi-Fi network nearby, and a backup is created automatically. It happens once a day, usually at night, when the device is connected to a power source and the screen is locked. You can also force creating a backup manually by pressing a single button.

Cloud backups are incremental to save time and space, and three last backups are stored in iCloud (sometimes more; I’ve seen as many as 17 backups at one time). Cloud backups are similar to local backups created with iTunes without a password. The keychain is always encrypted the same way as in local (iTunes) backups, i.e. with a hardware key. That key, if you remember, can be obtained from 32-bit devices without Secure Enclave, and only with physical acquisition.

Soon after iCloud backups were introduced, we had an idea to develop software to download them. Apple did not (and still does not) provide any software or method to work with iCloud backups; all you can do is restore a new device from a backup, of course supplying valid credentials (Apple ID and password).

Developing a software like that was not as easy as it sounds. iCloud backups can be created only directly from the device, over Wi-Fi; same for the restore process. The traffic is of course encrypted.

What we did in the end was a kind of MitM (man-in-the-middle) attack, capturing the traffic during the restore process, analyzing the protocol, and reversing the encryption. iCloud data is encrypted, though encryption keys are stored alongside with the data. As a result, our software worked just like an iPhone during a restore process. It authenticates into iCloud, gets the list of devices that have backups, downloads all the data, and decrypts it. The last stage was converting iCloud backups into the iTunes format to make them compatible with existing forensic tools.

That’s it! Even without the device itself, we can now acquire the data! Even more, we can do it for all devices connected to the account. All you need to have is the user’s Apple ID credentials. They are not always easy to obtain (methods vary from court orders to rubber-hose cryptanalysis), but if the device is lost, stolen, broken or not physically available; if it is passcode-locked, or has a strong backup password set, that’s yet another possibility to obtain its content. As a bonus, you get not only the last snapshot of the device, but usually the previous two as well, which may contain data already deleted in later backups.

Celebgate and 2FA

As always, nearly any tool can be used for legitimate and shady purposes.

In 2014, hackers used a stolen (carded) copy of our software to download iCloud backups of over a hundred celebrities. The stolen pictures were published. I have no idea how they obtained celebrities’ iCloud credentials; most probably phishing.

At that time, Apple already had a two-step verification process for iCloud accounts, but iCloud backups were NOT protected with it. A login and password were enough to access backups – no SMS to a trusted number, and no push notification with the security code were needed even if 2SV was enabled.

Apple learned the lesson, and soon protected iCloud backups with 2SV. Good move. After a while, they introduced stronger and more convenient two-factor authentication: once enabled, the account owner immediately gets a pop-up push notification on all trusted devices if someone is trying to access their iCloud account from the new device.

In the recently released iOS 11, customers are being more aggressively pushed towards enabling two-factor authentication, and that’s really a very good idea. Apple’s 2FA implementation is still not perfect (e.g. if the device is passcode-locked but you know the passcode, and 2FA is used on iCloud account, that you can change the iCloud password without entering the old one, and even change the trusted phone number; more details here), but it is still a must-have.

Tokens, Tokens

iCloud is used not only by iPhones, but by desktops as well, both Windows and Mac. The purpose of iCloud is easy access to documents in iCloud Drive, syncing contacts and calendars, and more. While you must also authenticate on desktop computers, you only do it once; after all, who wants to pass two-factor authentication after every reboot?

Once you passed the authentication process (with or without 2FA), the system saves a so-called authentication token (small binary data) obtained from the server. That token is used for all further requests to iCloud for data syncing.

What we have done: we found the location where that token is stored and the way it is encrypted, and learned how to use it to authenticate into iCloud – without a password, and without the secondary authentication factor.

For synced data (such as contacts, notes, Web history, photos), these tokens work indefinitely (at least it definitely does not expire for at least several months). The same was true for backups. At one point, Apple decided to cut tokens’ lifetime to just one hour for accessing backups only (iOS 8, right after Celebrate), but in iOS 9 iCloud backups were moved to iCloud Drive. The data in iCloud Drive should be always accessible, and token lifetime (for backups) returned to indefinite. Things changed again recently. Today, tokens seem to work for 12 hours only (and after that, you can still use them to access everything except backups). Apple may increase or decrease tokens’ lifetime at any time.

Backups vs. Data Sync

If you are familiar with Android, you may know that its backup system does not come close to Apple’s. Android has no local backups (if you don’t count the inherently broken ADB backup tool); some vendors may have their own backup systems, which have flaws of their own. What about the cloud? Simply forget about it. The amount of information backed up by Android devices into the user’s Google Account is borderline joke, and is a subject to device vendor, OS version and multiple other factors nobody can really understand.

However, Android’s strong side is syncing. You don’t actually need to restore an Android phone from the backup; instead, you simply link it to your Google account, and voilà, your data is back! At least in theory; in fact, many things are not restored (or synced back to the device).

Apple’s backups are very complete, but the company also offers real-time data syncing for where it’s needed. There aren’t as many categories synced by Apple as Google has, but everything of significance is synced. This includes contacts, notes, calendars, Web browsing history, bookmarks, wallet data (bookings, discount cards, boarding passes), mail (only Apple’s icloud.com), HomeKit-enabled devices, gaming data, health data (starting with iOS 11), and media files (if you enable iCloud Media Library, which contains photos and videos).

Of course we can download all those data too. The easies way would be web-based (about the same that happens once you log in into icloud.com), but we preferred to work at a lower level, through iCloud Drive (which is actually the main storage for all that data, even if it is not visible in Explorer or Finder). This also allowed us to reach application-specific data used by iOS and macOS applications (and even the system itself), from WhatsApp backups to user-defined dictionaries.

The other benefit of such a low-level access is the ability to get some ‘deleted’ data. Media files first, then browsing history, then notes. Yes, they are not gone forever; the data was still accessible (we managed to get 3-years old records). It has been already fixed by Apple (after our discoveries); today, deleted data remains available for a much shorter period of time, normally from 2 to 4 weeks (we never know for sure; maybe it is not deleted but moved to different servers, the ones we cannot reach).

Apple Strikes Back

Every other discovery we made led to Apple making some improvements to iCloud security. We should be proud of that 🙂 To our surprise, the other vendors on the mobile/cloud forensic market seem to dislike what we are doing, frequently asking about our motivation to disclose as many details as we do instead of using them internally for profit. Even worse; why the hell we are we discussing our discoveries on security conferences?

That’s a tight question.

On the one hand, we want to provide the best tools and technologies to the forensic and LE people. Speaking of iCloud (and Google services as well), there is nothing comparable to our software on the market. Our tools work faster and better, and can extract more data than anybody else.

On the other hand, we really care about privacy and security. Yes, we really do. After all, we are using the very same Apple devices and services as you do.

Last but not least, we always describe in every detail, what can and what cannot be extracted and decrypted, what are the pre-requisites, what problems you may encounter, and so on. And while it may not be the best business model, I am still convinced that what we do is much more fair than saying “we can crack XX now” or “send us your device and we can probably unlock it, but if not, you’ll pay the fee nevertheless”.

Anyway, the amount of information we publicly release allows Apple to improve the security of their products and services. We got a couple of acknowledgements in iOS release notes (HT207271 and HT207482), but more importantly, Apple products became better, and we love them more than ever.

Speaking of iCloud, Apple definitely does not like the fact that iCloud backups can be downloaded (it’s a double-edged sword). They recently implemented several countermeasures placing a temporary lock on iCloud accounts (and forcing the user to change the password) if different accounts are being accessed from the same IP address. I personally do not think this is a very good idea: the account lock can sometimes happen even after a legitimate device restore. Let the users decide how they want to protect themselves. 2FA works pretty well, and it’s enough to secure our accounts.

iCloud Keychain

iCloud Keychain is a fantastic feature if you have more than one Apple device. No need for password managers. Can you really trust those password managers, especially those keeping your data on their own servers? Are you sure their encryption is bullet-proof? Is there a chance that they cooperate with the government? There are no such questions for iCloud Keychain.

This is how iCloud keychain works. It keeps a highly secure storage in iCloud where some of the items from the system keychain are being stored and synced across the devices. About the same mechanism as used for syncing contacts and notes, but only for specific devices (not every device on the account), the “trusted circle”. And it is not easy to get in.

Technical details would be too long, so I will talk about what can be done.

First, there is a huge difference between iCloud keychain implementations with and without two-factor authentication. If you set up iCloud keychain without 2FA, you will be prompted to set a security code (iCloud Security Code), but this is optional, and Apple’s explanation is a bit confusing.

The funny thing is that if you do not have 2FA and do not set a security code, things are the most secure. In this configuration, there is absolutely no chance for anyone to access your iCloud keychain. It is being synced directly across your devices using peer-to-peer exchange. There is a price for that though: if you lose access to the last one of your trusted devices, there is no way to get the keychain back, it is gone forever.

The second most-secure configuration is also without 2FA, surprisingly. But this time, with security code. To access iCloud keychain, the following is required: authentication credentials (obviously), the security code you’ve set, and finally the other code that is being sent to a trusted phone number. Looks a lot like 3FA, right?

Finally, if you have 2FA, then you also need authentication credentials, but also the passcode of any one of the devices that are already in the trusted circle. That sounds a bit crazy, right? By the way, a passcode of old devices (the ones that were signed into iCloud Keychain a while ago, but currently not connected to the account at all) may also work, according to our tests.

Is there a security risk to that? Well, I would not say so, the implementation is highly secure. If you were thinking of brute-forcing the security code or the passcode, forget it; iCloud Keychain may be temporary locked, or even completely wiped if you do.

So what is the deal? This time our approach works for forensics only, and only in a specific scenario.

If you have an iPhone manufactured during the last 3-4 years (from 5S to iPhone X) that runs iOS 8 or later, with a strong backup password (iTunes will now also warn about an empty backup password), and the device passcode is known, there is simply no way to obtain (and decrypt) the backup and the keychain. The best you can do is go through all device screens and get only the information that is visible. This is not very effective.

What’s the trick? Most probably, the device is connected to some iCloud account. If its password is already known, just go to iCloud and grab everything from both the iCloud and the keychain. If not, you can change the user’s iCloud password right from the device, add a new trusted number if necessary, and do the same afterwards. If iCloud backups and iCloud keychain were disabled, just enable them. That easy.

So in short, it seems to be the only way to break into the keychain on modern iPhones. Sounds a bit tricky, bit in fact it is fast and simple. Just note that keychain syncing takes a lot of time (several hours), and there is no visible progress.

Do I need to tell you once again what you can get from the keychain? Most user’s passwords to web sites, social networks and even other iCloud accounts (accessed from the same device). As well as tokens, which are even better than passwords if you need to access accounts that have two-factor authentication enabled.

Conclusion

This is all about security, privacy and convenience – as always, one can pick any two out of three. Some may blame Apple that they do not protect their user’s data well enough. The others may say that in the era of cyber-terrorism, LE should get access to all smartphones and data floating around, but still that data must be protected from the hackers. And everyone wants everything to be very easy to use (the new emoji’s are apparently major features of new iOS builds).