Archive for February, 2020

Elcomsoft iOS Forensic Toolkit can perform full file system acquisition and decrypt the keychain from non-jailbroken iPhone and iPad devices. The caveat: the device must be running iOS 11 or 12 (except iOS 12.3, 12.3.1 and 12.4.1), and you must use an Apple ID registered in Apple’s Developer Program. In this article, I’ll explain the pros and contras of the new extraction method compared to traditional acquisition based on the jailbreak.

Why jailbreak?

Before I start talking about the new extraction method that does not require a jailbreak, let me cover the jailbreak first. In many cases, jailbreaking the device is the only way to obtain the file system and decrypt the keychain from iOS devices. Jailbreaking the device provides the required low-level access to the files and security keys inside the device, which is what we need to perform the extraction.

Jailbreaks have their negative points; lots of them in fact. Jailbreaking may be dangerous if not done properly. Jailbreaking the device can modify the file system (especially if you don’t pay close attention during the installation). A jailbreak installs lots of unnecessary stuff, which will be difficult to remove once you are done with extraction. Finally, jailbreaks are obtained from third-party sources; obtaining a jailbreak from the wrong source may expose the device to malware. For these and other reasons, jailbreaking may not be an option for some experts.

This is exactly what the new acquisition method is designed to overcome.

Agent-based extraction

The new extraction method is based on direct access to the file system, and does not require jailbreaking the device. Using agent-based extraction, you can can perform the full file system extraction and decrypt the keychain without the risks and footprint associated with third-party jailbreaks.

Agent-based extraction is new. In previous versions, iOS Forensic Toolkit offered the choice of advanced logical extraction (all devices) and full file system extraction with keychain decryption (jailbroken devices only). The second acquisition method required installing a jailbreak.

EIFT 5.30 introduced the third extraction method based on direct access to the file system. The new acquisition method utilizes an extraction agent we developed in-house. Once installed, the agent will talk to your computer, delivering significantly better speed and reliability compared to jailbreak-based extraction. In addition, agent-based extraction is completely safe as it neither modifies the system partition nor remounts the file system while performing automatic on-the-fly hashing of information being extracted. Agent-based extraction does not make any changes to user data, offering forensically sound extraction. Both the file system image and all keychain records are extracted and decrypted. Once you are done, you can remove the agent with a single command.

Compatibility of agent-based extraction

Jailbreak-free extraction is only available for a limited range of iOS devices. Supported devices range from the iPhone 5s all the way up to the iPhone Xr, Xs and Xs Max if they run any version of iOS from iOS 11 through iOS 12.4 (except iOS 12.3 and 12.3.1). Apple iPad devices running on the corresponding SoC are also supported. Here’s where agent-based extraction stands compared to other acquisition methods:

The differences between the four acquisition methods are as follows.

  1. Logical acquisition: works on all devices and versions of iOS and. Extracts backups, a few logs, can decrypt keychain items (not all of them). Extracts media files and app shared data.
  2. Extraction with a jailbreak: full file system extraction and keychain decryption. Only possible if a jailbreak is available for a given combination of iOS version and hardware.
  3. Extraction with checkra1n/checkm8: full file system extraction and keychain decryption. Utilizes a hardware exploit. Works on iOS 12.3-13.3.1. Compatibility is limited to A7..A11 devices (up to and including the iPhone X). Limited BFU extraction available if passcode unknown.
  4. Agent-based extraction: full file system extraction and keychain decryption. Does not require jailbreaking. Only possible for a limited range of iOS versions (iOS 11-12 except 12.3.1, 12.3.2, 12.4.1).

Prerequisites

Before you begin, you must have an Apple ID enrolled in Apple’s Developer Program in order to install the agent onto the iOS device being acquired. The Apple ID connected to that account must have two-factor authentication enabled. In addition, you will need to set up an Application-specific password in your Apple account, and use that app-specific password instead of the regular Apple ID password during the Agent installation.

Important: you can use your Developer Account for up to 100 devices of every type (e.g. 100 iPhones and 100 iPads). You can remove previously enrolled devices to make room for additional devices.

Using agent-based extraction

Once you have your Apple ID enrolled in Apple’s Developer Program, and have an app-specific password created, you can start with the agent.

 

  1. Connect the iOS device being acquired to your computer. Approve pairing request (you may have to enter the passcode on the device to do that).
  2. Launch Elcomsoft iOS Forensic Toolkit 5.30 or newer. The main menu will appear.
  3. We strongly recommend performing logical acquisition first (by creating the backup, extracting media files etc.)
  4. For agent-based extraction, you’ll be using numeric commands.
  5. Install the agent by using the ‘1’ (Install agent) command. You will have to enter your credentials (Apple ID and the app-specific password you’ve generated). Then type the ‘Team ID’ related to your developer account. Note that a non-developer Apple ID account is not sufficient to install the Agent. After the installation, start the Agent on the device and go back to the desktop to continue.
  6. Acquisition steps are similar to jailbreak-based acquisition, except that there is no need to use the ‘D’ (Disable lock) command. Leave the Agent (the iOS app) working in the foreground.
  7. Obtain the keychain by entering the ‘2’ command. A copy of the keychain will be saved.
  8. Extract the file system with the ‘3’ command. A file system image in the TAR format will be created.
  9. After you have finished the extraction, use the ‘4’ command to remove the agent from the device.

To analyse the file system image, use Elcomsoft Phone Viewer or an alternative forensic tool that supports .tar images. For analysing the keychain, use Elcomsoft Phone Breaker. For manual analysis, mount or unpack the image (we recommend using a UNIX or macOS system).

Conclusion

If you have unprocessed Apple devices with iOS 11 – 12.2 or 12.4, and if you cannot jailbreak for one or another reason, give the new extraction mode a try. iOS Forensic Toolkit 5.30 can pull the file system and decrypt the keychain, leaves no apparent traces, does not remount and does not modify the file system while offering safe, fast and reliable extraction.

The popular unc0ver jailbreak has been updated to v4, and this is quite a big deal. The newest update advertises support for the latest A12 and A13 devices running iOS 13 through 13.3. The current version of iOS is 13.3.1. None of the older versions (including iOS 13.3) are signed, but still there are a lot of A12/A12X/A13 devices floating around. Until now, file system and keychain extraction was a big problem. The newest unc0ver jailbreak makes it possible.

The new build is based on an exploit that is quite reliable by itself. However, jailbreaking is more than just a single exploit; a lot of things (that are outside the scope of this article) have to be done. So the new version of a jailbreak is not a silver bullet, and may still fail on many devices; we have tested a few and received mixed results. Still, if the given device can be jailbroken with unc0ver, it means that we can pull all the data from it, down to the last bit.

ICYMI: iPhones and iPads based on A12/A12X/A13 SoC are not vulnerable to checkm8 exploit, and there is no room for BFU acquisition (if the passcode is not known). That means that jailbreaking them using iOS (not bootrom) exploits is the only way to get all the data, at least for now.

Installing the jailbreak

The jailbreak (curren version: 4.0.2) is available as an IPA file (iOS/iPadOS package). There are several methods of installing it, but they usually require signing the IPA using a third-party certificate, which is not very safe and requires approving the certificate on the device, which in turn means that you have allow the device make an Internet connection. This in turn means that the device can be remotely locked or wiped (and even if Find My is disabled, it may sync and modify the data. The only workaround is to set up the network so that that it can only access the Apple’s servers that take care of certificate approval, but this is not not as easy as it sounds.

The better and safer way is to sign the jailbreak IPA with a developer’s certificate using Cydia Impactor. You will need a developer’s account to do that. If you have one, create an Application-specific password first as Cydia Impactor does not natively support 2FA.

Once the IPA is installed, just run it and press [Jailbreak]. That simple.

Well, not quite. First, you have to press [Settings] in the top-right corner and enable the following options:

  • Re(Install) OpenSSH
  • SSH Only
  • Read-Only SSH

What is it all about? Install OpenSSH (which is not installed by default); do not install Cydia (not only you won’t need it for the purpose of file system extraction, but removing Cydia after you’re done is a separate headache); do not remount the system partition, making the jailbreak rootless, safer, and with a minimum impact. I would not say “forensically sound”. But very close to that.

Note that the new build of unc0ver is not very reliable yet. If it fails, here is what the jailbreak developers recommend:

To everyone having reliability issues. You must follow those conditions carefully to have the best success:
– reboot
– airplane mode
– lock device
– wait 30 seconds (don’t do anything)
– jailbreak

A better exploitation method is required to avoid this. We’ll try our best.

Data acquisition

iOS Forensic Toolkit is all you need. First, do not miss some basic usage tips:

Ready to go? Extract the keychain and the file system first. Just note that with the keychain extraction, you may get error/warning messages like the following:

[+] memory_size: 3962028032
[-] no offsets for iPad8,1 17C54
[e] error reading kernel @0x0
[-] no kernel_call addresses for iPad8,1 17C54 [e] error reading kernel @0x0 Injecting to trust cache...
Actually injecting 1 keys
1 new hashes to inject
Successfully injected [1/1] to trust cache.
[e] error writing kernel @0x0

Just ignore them for now, we will take care on them later; they don’t seem to affect the keychain acquisition.

As for the file system, please note that if you forget to set the appropriate unc0ver options and install OpenSSH later from Cydia, acquisition will probably fail. The OpenSSH client installed alongside with the jailbreak works fine.

Anything else? Almost everything matters. Including whether you connect the iPhone directly or through a USB hub; the type of the cable (USB-A or USB-C to Lightning); and even the brand of the cable (original or not). Do not ask us why, ask Apple. To our experience, you get the best results when using an original Apple USB-A to Lightning cable connected directly (with no hubs); also, it works better on Macs. Yes, even that matters.

Data analysis

For “quick and dirty” analysis, use Elcomsoft Phone Viewer to browse the data acquired by iOS Forensic Toolkit. Do not underestimate this little tool; it does not parse all the data categories, but you will be surprised by the amount of data it can extract from media files (including deleted ones), locations, Apple Pay, Wallet etc. All the most-critical evidence is there.

Need more, including system databases, building the complete Timeline, defining social links between device contacts and extractions in Social Graph, getting comprehensive data analysis with facial recognition and image categorization, advanced data search and detailed reports? Get Oxygen Forensic Detective.

Did you extract the keychain? That’s a gold mine. Not just all the passwords and tokens (for dozens web sites, social networks, mail accounts and more), but also the encryption keys that will allow you to decrypt WhatsApp and Signal conversations. Use Elcomsoft Phone Breaker to browse it in a very convenient way (well, three ways); there you will be also able to export passwords to a wordlist, allowing you to break other files, documents and systems almost instantly.

We have updated Elcomsoft Cloud Explorer, our Google Account extraction tool, with Google Fit support. Google Fit is a relatively little known Google service aimed at tracking the user’s health and physical activities. In line with pretty much every other Google service, Google Fit synchronizes massive amounts of data with the user’s Google Account, storing activity-related information collected by all of the user’s devices in a single place. When extracting these data, we discovered massive amounts of location points stored alongside with information related to the user’s physical activities. Learn what is stored in Google Fit and how to extract it from the cloud!

What’s it all about

Google Fit extraction is about the massive amounts of data related to the user’s health and physical activities stored in the Google’s cloud. The detailed, high-frequency location data collected by Google’s fitness app accompanied with information about the user’s physical condition can be truly invaluable during an investigation.

Google Fit is not the only type of information collected by Google. The search giant collects massive amounts of information. The types of data range from many years worth of the user’s location history to all of the user’s password saved in the Chrome browser or used with Android apps. Google Photos, Gmail, contacts and calendars, search requests and Web history, voice snippets, call logs and text messages and a lot more can make for some invaluable evidence. While Google readily returns most of that data when serving legal requests, Elcomsoft Cloud Explorer offers a much easier and near-instant extraction solution that requires far less paperwork. Considering the number of fully encrypted Android smartphones that may or may not be physically unlocked, Elcomsoft Cloud Explorer becomes truly irreplaceable, discovering more evidence than ever by revealing the hidden data one would never imagine existed, browsing deep inside into the user’s online activities going many years back. Elcomsoft Cloud Explorer does what Google itself does not do, offering a single point for downloading, discovering and analyzing evidence collected by Google.

How Google Fit collects information

Google Fit is both an app and a service. The Google Fit app is available for Android and iOS platforms; it can be used on both Android phones and Apple iPhones. The Google Fit service processes and stores information collected from all supported devices where it’s installed in the user’s Google Account.

While many users associate Google Fit with WearOS smartwatches, in reality the app does not require a smartwatch or a fitness tracker. A connected activity tracking device can provide information such as the number of steps walked, the number of stairs climbed, the user’s hear rate or periodic location points obtained from the tracker’s GPS sensor. When used without a compatible fitness tracker, the Google Fit app can source activity data from a smart combination of the phone’s built-in low-energy sensors, frequently obtained location points and a lot of artificial intelligence.

Google Fit data extracted from the user’s Google Account returns massive amounts of precise location points, allowing to pinpoint the user’s location with ultimate precision and granularity. Access to comprehensive location history and other critical real-time evidence can be vital for investigating crime.

Obtaining Google Account credentials

In order to sign in to the user’s Google Account, one requires the full set of Google credentials. The login and password can be often extracted from the user’s computer (with Elcomsoft Internet Password Breaker), from the cloud (with Elcomsoft Phone Breaker) or iOS keychain (with Elcomsoft iOS Forensic Toolkit).

In addition, some data from the Google Account (Google Fit being a notable exception) can be accessed with a token. The token is literally a cookie in Chrome, and can be extracted from the user’s computer. Elcomsoft Cloud Explorer includes a utility that automatically locates and extracts the authentication token from the Chrome browser installed on the user’s Mac or Windows PC. Using the extracted token, Elcomsoft Cloud Explorer authenticates into the user’s Google Account and displays the list of categories available for extraction.

Accessing Google Fit data

In order to extract Google Fit data from the user’s Google Account, you will need Elcomsoft Cloud Explorer 2.30 or newer.

  1. Launch Elcomsoft Cloud Explorer and create a new snapshot. Authenticate with the user’s login and password (Google Account). If required, pass two-factor authentication.
  2. Select the “Google Fit” check box.
  3. The data will be downloaded in several seconds to several minutes.
  4. After the processing, you can access Google Fit data from the main window.

Analyzing Google Fit data

You will be able to sort or group activities. The “Sessions” tab displays activity sessions detected by the Google Fit app. Activity sessions may include sleeping, walking, jogging and other types of activities.

Note that the sessions are detected automatically by the various apps and devices. Have a look at the “Package name” tab to discover which package has detected which session.

“Steps” can be either raw data from the connected smartwatch or fitness tracker, or information generated by the Google Fit app based on a combination of the smartphone’s step counter, the user’s height, and a lot of location data. If no external smartwatch or activity tracker is connected, the Google Fit app uses artificial intelligence to calculate the number of steps based on the abovementioned data. The app only polls the smartphone’s built-in step sensor at large intervals, relying more on location data than on the step counter.

Walking and running activities are automatically detected by the app based on the user’s heart rate, step count and location data.

One of the most interesting reports is “Locations”. By design, Google Fit collects massive amounts or location data. The test account reports 13,788 location points in 9 month. Considering that our test device was used on few rare occasions, the number of location reports is truly excessive. Clicking on a location point opens Google Maps.

Conclusion

Google Fit data may contain detailed information about the user’s location and physical conditions including the number of steps, types of activity, heart rate, elevation, and a lot more. Additional information provided by compatible health tracking devices may include blood pressure, elevation, precise step count, and additional location data collected from the GPS sensor built into the smartwatch or tracker. Analyzing the massive amounts of Google Fit data can become invaluable help when searching for evidence and investigating crime. The detailed, high-frequency location data collected by Google’s fitness app accompanied with information about the user’s physical condition can shed light on the user’s activities in a given timeframe.

Just days ago, we have reviewed the data stored in iCloud, and studied its encryption mechanisms. We also discussed the discrepancies between the data that is stored in the cloud and the data that’s provided to the law enforcement. In case you missed it, make sure to check out Apple vs. Law Enforcement: Cloud Forensics. Today, the differences are great; Apple is using point-to-point encryption to protect certain types of data. However, it has not always been that way. Apple security model changed year after year. This article reviews the timeline of Apple security changes over time.

We’ll list the security measures and discuss whether the real purpose of these changes were the customers’ security and privacy, or throwing a monkey wrench into the work of the law enforcement. We will also try to understand where iCloud security stands today, and how safe your data is against hackers and the law enforcement. Are you a forensic professional? I think you’ll find this article handy.

Apple iCloud: the beginning

Apple has introduced iCloud in October 2011, replacing the aging MobileMe service. At that time, Apple iCloud services were based solely on Amazon and Microsoft Azure servers (new platforms have been added a few years later). Using iCloud on the iPhone required installing iOS 5.

Apple iCloud today provides a range of services including synchronization of data across devices connected to the account, iCloud backups for iOS and iPadOS devices, iCloud Drive (just the storage), as well as the Find My service.

iCloud security

While you can always refer to the source in iCloud security overview, I can give you a shorter and simpler description.

First, all iCloud data (including backups) is stored on third-party servers. These servers are owned by Amazon, Google, Microsoft, or the Chinese government in the case of Chinese users. We also witnessed some mysterious AT&T data centers in the past.

Second, all that data is always encrypted.

Third, the encryption keys for most of that data are also retained by Apple. However, the keys are not stored on the same physical servers; instead, Apple keeps them in Apple-owned data centers under the company’s full control. Interestingly, this seems to be the case even for data stored in China (where iCloud data itself is located on Chinese servers only).

Careful readers noticed the “most” part. The “most” part does not mean that the data is not encrypted; it’s rather the opposite. More on that in “end to end encryption” below.

Do the same rules apply to iCloud backups? Yes, they do. A couple years ago, Apple war rumored to have plans to encrypt iCloud backups in a more secure way (potentially with end-to-end encryption). Those plans have been but finally rejected it, probably under FBI pressure, but only Apple knows the actual reasons.

Two-factor authentication: 2SV, 2FA and iCloud backups

Today, it is hard to believe that an online account that holds your personal data may not support two-factor authentication. Online threats and phishing are the main risks, and if you re-use your passwords, the situation is even worse.

In the first two years, iCloud did not have any kind of two-factor authentication. One was only added in 2013, but the half-baked solution only protected access to the account itself, and not to iCloud backups. We wrote about that in Apple Two-Factor Authentication and iCloud.

You probably remember what happened next. Celebgate. Only after that, Apple applied second-factor protection to backups.

It is important to note that Apple’s initial implementation (called Two-Step Verification, 2SV) was not perfect. It was a rushed afterthought. The current implementation of two-factor authentication (2FA) was introduced with iOS 9 in 2015, and it offers good protection.

We covered this subject many times:

It’s all about the tokens

In 2014 (the year when Apple added 2SV to iCloud backups), we got a bright idea. If you set up your computer to access iCloud account*, you won’t be prompted for your password or prompted for a one-time code every time you access the cloud. This means that the authentication token could be saved somewhere. Could we use that token to bypass password-based authentication?

* iCloud access is a built-in feature on a Mac, while “iCloud Control Panel” is required on Windows; its current name is iCloud for WIndows.

It worked; see Breaking Into iCloud: No Password Required. Having the token obtained, we were able to download iCloud backups (and later implemented the same technique to download other/synced data from iCloud).

Did our work introduce a new security risk for iCloud account owners? Probably not (or just a little), as extraction and decryption of the tokens requires physical access to the computer, as well as administrative privileges (and if you have both, there are much more serious risks involved).

However, Apple took it seriously, and since then, implemented additional security measures related to tokens, in particular:

  • Limited lifetime. The token worked perfectly for synced data. When accessing iCloud backups, its lifetime was limited first to 24 hours, and then to just one hour.
  • Limited use. Currently, the token stored on the device is only good for a limited number of categories including iCloud Photo Library and most synced data and excluding end-to-end encrypted data. Tokens cannot be used for accessing iCloud backups.
  • Pin to device. That was the biggest surprise. After some changes Apple did last year, the token could be used (even for accessing a limited set of data) on the same computer only. On macOS, we have recently found a way to obtain an “unpinned” token that can be used on other computers, but there is no way to do that for Windows.

Still, it is theoretically possible to obtain full-featured “unpinned” tokens that allow obtaining almost everything from iCloud from a trusted macOS computer. We are working hard in this direction; watch our blog for updates. Still no access to backups though. Apple did everything to get iCloud backups extremely hard, even if you know the password and have the second authentication factor.

End-to-end encryption (they call it so)

C’mon, Apple, please do not call it “end-to-end”, that term is reserved for the case when some data can be only decrypted at the end point, because it is the only place that holds the decryption key. Yes, trusted iPhones do have the key, but we can get one even from the outside and without access to the device. This isn’t exactly end-to-end, is it?

What does Apple protect with this “end-to-end” encryption? This encryption covers data that belongs to the following categories: iCloud keychain, Health data, messages in iCloud, Home data, and (surprisingly!) some Apple Maps data, even though Apple does not mention that.

All that data is stored in iCloud and synchronized across “trusted devices”. In case if you did not know, the key to decrypt that data is also stored in iCloud (even if Apple wants you – and the law enforcement – to believe otherwise). That key, however, has stronger protection than the general iCloud encryption keys (that could be probably called “snake oil”) and can only be accessed by devices that are part of the “trusted circle”.

Can someone enter into the trusted circle? Of course, but not easily so.

Notifications, account locks, GSA and other changes

There are a couple extra security measures related to iCloud backups we have not mentioned.

First, you probably noticed that once the backup restoration process is completed, the notification is being sent to the account owner (by email).

Second, Apple does its best to detect whether download process is initiated by the actual device or by third-part software like ours.

We did our best to ‘mimic’ the device, but suppress the ‘restore’ notification. Currently, it works, but it looks like Apple has a dedicated team of security specialists working against our software.

On a regular basis, Apple changes everything they can: protocols, encryption, and data storage formats. Some of these changes are reasonable, while the other (solid!) part of these changes is intended only as a countermeasure against forensic tools, while adding little to no extra security to iCloud.

Have I mentioned GSA (Grand Slam Authentication) and “anisette data”? I was not going to dive deep into technical details, but you can search for my presentations on this subject; they are publically available.

The dark side of the cloud

Are you sure that you know all of the following?

  • What information is synced between your device and iCloud (or just uploaded to iCloud)
  • If Apple really deletes your data from iCloud when you delete it from the device
  • What information Apple provides to the law enforcement once they are served with a legal request

Nobody knows, and I have some surprises for you.

First, Apple syncs more data with iCloud than it publically admits. A good example is the call log (the list of incoming and outgoing calls); there is no option on the iPhone that disables syncing.

Second, there is some extra data in iCloud such as iCloud access logs, stored for 28 days. It includes your IP address (it can be used to get physical location) and the time stamp.

Next, it is not clear what really happens when you delete the data. In the past, we found some of the data to remain on Apple’s server past the advertised retention time, including media files (photos and videos), Web history and notes. Moreover, we have found a way to extract it. At this time, our method does not work anymore, but we never know whether it is still saved somewhere, and if it is, whether it is provided to law enforcement agencies (maybe just the select few).

Bonus track: Google and Microsoft

This is definitely outside the scope of this article, but you might be curious how Apple iCloud security compares to Google and Microsoft, the other two major cloud vendors.

Neither of these companies offer detailed descriptions on how they store and encrypt the user’s data. Still, it is not too hard to guess, based on what we know.

Google saves enormous amounts of data. It sources the data from all the devices running their software or using their services, and not just from Android. As opposed to Apple, even though Google provides granular control to what data is stored or synced, it is not easy to disable or enable data syncing from the device(s). The data stored by Google usually includes detailed location history, a comprehensive history of the user’s search queries, all of the user’s purchases (not just with Google), and a lot more.

Microsoft syncs or may sync less data than Apple and Google, but the company still has some. This includes Web history and Bing searches, contacts, Cortana commands, Skype conversations and more, including BitLocker recovery keys. Microsoft does not make it very clear what data is saved in the account.

Cloud acquisition

If you want to get the maximum amount of data from Apple iCloud, you have no choice but use Elcomsoft Phone Breaker. iCloud backups, files from iCloud Drive, iCloud Photos, FileVailt2 recovery token, iCloud keychain and all end-to-end encrypted data such as messages, Health, Screen Time and more, you can obtain all of that. This product can also extract the data from Microsoft accounts, from contacts to Skype conversations.

For Google accounts, use Elcomsoft Cloud eXplorer. The only thing we cannot get is Android device backups as they are securely encrypted (we continue our research).

When it comes to other cloud data, Oxygen Forensic Suite leaves no place for competitors. The number of cloud sources it supports is impressive (close to one hundred), including Telegram, Samsung cloud, Xiaomi Mi Cloud, Huawei Cloud and dozens others, including third-party apps that sync enormous amount of data (and so the evidence). All that stuff is continuously improved and perfectly supported according to the vendors’ changes, contrary to similar products from other vendors, even those that are more expensive and pretend to be “number one”. Seriously, do not waste your time trying the others: you will get a result that is not even close. Do not trust vendors’ claims, but verify yourself.

Protecting your data

Do you want to make your iCloud account secure? Don’t use it this way! Just kidding; the iPhone without iCloud is quite a Samsung.

The very first thing I would recommend is requesting a copy of your data from Apple’s Data & Pricacy Portal and analyzing it carefully. About the same amount of data (plus backups) will be provided to the law enforcement if requested.

A more effective way is using Elcomsoft Phone Breaker to get everything including “end-to-end encrypted data”.

If you decide to keep using iCloud, here is what we can recommend (simple and probably well-known, but still often overlooked):

  • Use a secure iCloud password, long and complex enough.
  • Make sure that password does not look similar to any other passwords you use. Of course, it must not be identical to any other password you have.
  • Don’t cache that password in your Web browser, ever.
  • Don’t ever store that password in your Google Account.
  • Don’t store that password in the keychain (iOS, iPadOS or macOS).
  • Use two-factor authentication (I know some people who don’t).
  • Use strong passcode/password on your iOS device(s) and desktop(s).
  • Physically secure all your devices and never leave them unattended (even locked).
  • Did I mention you should never re-use your passwords and passcodes?
  • Keep all your devices updated to the latest system (iOS/iPadOS/Windows/macOS), and do not forget about your Apple TV and Apple Watch.
  • If you are using an old Android (more than one year old), don’t count on updates to arrive. Just buy the current flagship.
  • For Windows, follow our recommendations listed here; the macOS guide will follow.
  • Be aware of checkm8 exploit if you are using an old device. Make sure you know that some data can be extracted even from locked and disabled devices.
  • Remember how to enable the SOS mode.
  • Know how to use Find My

If you work for law enforcement

Speaking of iCloud, you have several options. First, read our recent Apple vs. Law Enforcement: Cloud Forensics for better understanding what is stored in iCloud, how it is encrypted and protected, and what your options are. In general, you need to analyze all devices the suspect regularly used, and probably even those that’ve been used at least once. You might be able to get lockdown records, leading you to locked device access; or extract passwords saved in the browser. Better yet, attend one of the ElcomSoft trainings to understand how to obtain as much data as possible from every available source. We don’t just tell you how to use our software. Instead, we’re offering the complete workflow, talk about the typical mistakes and share our knowledge and expertise.

Conclusion

So what about iCloud security today? I would say, it is generally OK. More information here:

Still, we have two conflicting thoughts. First, Apple saves a lot of data in iCloud, and we don’t know all the details. The fact that others are (much) worse in this respect doesn’t change much. Second, Apple makes the work of forensic experts unnecessarily more complicated without making any real security improvements, all the time. Apple, it’s hard to wear two hats.