Motivated by events ranging from Apple v. FBI in 2016 to the EARN IT Act currently in Congress, and the general disposition of many governments against end-to-end encryption and user privacy in favor of law enforcement access, we set out to answer three major questions:

Which concrete security measures in mobile devices meaningfully prevent unauthorized access to user data?

In what ways are modern mobile devices accessed by unauthorized parties?

How can we improve modern mobile devices to prevent unauthorized access?

We organized our search to answer these questions by platform, with Apple iOS and Google Android as they represent the bulk of the market share of the most advanced devices. For each, we provide an overview of security features (including histories for each), and then deep dives into techniques to bypass these controls, analyzing technical measures and forensic software. We conclude each section with improvements and research directions based on our analysis.

In Apple iOS we found a powerful and compelling set of security and privacy controls, backed and empowered by strong encryption. However, we also found a critical lack in coverage due to under-utilization of these tools. More concretely:

• Limited benefit of encryption for powered-on devices. We observed that a surprising amount of sensitive data maintained by built-in applications is protected using a weak “available after first unlock” (AFU) protection class, which does not evict decryption keys from memory when the phone is locked. The impact is that the vast majority of sensitive user data from Apple’s built-in applications can be accessed from a phone that is captured and logically exploited while it is in a powered-on (but locked) state.
• Weaknesses of cloud backup and services. Use of Apple iCloud (unsurprisingly) transmits an abundance of user data to Apple’s servers, in a form that can be accessed remotely by criminals who gain unauthorized access to a user’s cloud account, as well as authorized law enforcement agencies with subpoena power. More surprisingly, we identify several counter-intuitive features of iCloud that increase the vulnerability of this system.
• Evidence of past hardware (SEP) compromise. iOS devices place strict limits on passcode guessing attacks through the assistance of a dedicated processor known as the Secure Enclave processor (SEP). We examined the public investigative record to review evidence that strongly indicates that as of 2018, passcode guessing attacks were feasible on SEP-enabled iPhones using a tool called GrayKey. To our knowledge, this most likely indicates that a software bypass of the SEP was available in-the-wild during this timeframe.
• Limitations of “end-to-end encrypted” cloud services. Several Apple cloud services advertise “end-to-end” encryption in which only the user (with knowledge of a password or passcode) can access cloud-stored data. We find that the end-to-end confidentiality of some encrypted services is undermined when used in tandem with the iCloud backup service. More critically, we observe that Apple’s documentation and user settings blur the distinction between “encrypted” (such that Apple has access) and “end-to-end encrypted” in a manner that makes it difficult to understand which data is available to Apple. Finally, we observe a fundamental weakness in the system: Apple can easily cause user data to be re-provisioned to a new (and possibly compromised) HSM simply by presenting a single dialog on a user’s phone. We discuss techniques for mitigating this vulnerability.

In Android we found strong protections emerging in the very latest flagship devices, but simultaneously fragmented and inconsistent security and privacy controls, not least due to disconnects between Google and Android phone manufacturers, the deeply lagging rate of Android updates reaching devices, and various software architectural considerations. More specifically:

• Limited benefit of encryption for powered-on devices. Like Apple iOS, Google Android provides encryption for files and data stored on disk. However, Android’s encryption mechanisms provide fewer gradations of protection. In particular, Android provides no equivalent of Apple’s Complete Protection (CP) encryption class, which evicts decryption keys from memory shortly after the phone is locked. As a consequence, Android decryption keys remain in memory at all times after “first unlock,” and user data is potentially vulnerable to forensic capture.
• De-prioritization of end-to-end encrypted backup. Android incorporates an end-to-end encrypted backup service based on physical hardware devices stored on Google’s datacenters. Unfortunately, the end-to-end encrypted backup service must be opted-in to by app developers, and is paralleled by the opt-out Android Auto-Backup, which provides encryption keys to Google servers.
• Large attack surface. Android is the composition of systems developed by various organizations and companies. Because the development of these components is not centralized, cohesively integrating security for all of Android would require significant coordination, and in many cases such efforts are lacking or nonexistent.
• Limited use of end-to-end encryption. End-to-end encryption for messages in Android is only provided by default in third-party messaging applications. Many native Android applications do not provide end-to-end encryption: the exceptions being Google Duo and more recently, the Android Messages application.
• Availability of data in services. Android has deep integration with Google services, such as Drive, Gmail, and Photos. Android phones that utilize these services (the large majority of them ) send data to Google, which stores the data under keys it controls - effectively an extension of the lack of end-to-end encryption beyond just messaging services. These services accumulate rich sets of information on users that can be exfiltrated either by knowledgeable criminals (via system compromise) or by law enforcement (via subpoena power).

We also found, in both iOS and Android, exacerbating factors due to increased synchronization of data with cloud services.

We analyzed troves of publicly-available documents including over a decade of DHS forensic software tests, published Apple and Google documentation, research papers, news articles, blogs, and hardware tear-downs to fully understand the technical landscape of mobile devices. Our report serializes and summarizes much of this information, and we archived the documents we read just in case.

Finally, for both iOS and Android we propose concrete improvements which mitigate or entirely address many concerns we raise. We also propose research directions to take these mitigations even further, with the central theme of these improvements and proposals being increasing the coverage of user data with strong encryption - not a trivial task, for many reasons.

It is our hope that this work stimulates mobile device development and research towards increased security and privacy, promotes understanding as a unique reference of information, and acts as an evidence-based argument for the importance of reliable encryption to privacy, which we believe is both a human right and integral to a functioning democracy.

Changelog

• Update website to point to arXiv

• Edit Executive Summary

• Edit full report CSS, remove draft notice

• Update for Google Messages RCS E2E encryption, update CSS and move text

• Add Appendix C; add clarifying footnotes for iCloud, SEP, and iOS code signing; minor typo and clarification edits

• Minor copy edits, added GitHub archive link

• Initial upload