It seems with every year that passes, more of our lives head onto our phones. When you think about the level of data they store, it typically matches, if not exceeds that of any other electrical device in our life. Not only does your phone contain pictures, contacts and messages; but also access tokens to other services like financial, utilities and insurance services. Having full access to someone’s phone would be enough to not only investigate their life, but also the lives their friends\family.

But what’s that you say? Your phone is locked! Maybe even encrypted too. Unfortunately for us consumers – in the world of mobile forensics, those features don’t always prevent unwanted access to our phones. With a handful of vendors specialising in data recovery from mobiles, it’s time the world learned exactly what capabilities these vendors have (and their customers). Fortunately, that work came from research performed by Maximilian Zinkus, Tushar Jois, and Matthew Green, of Johns Hopkins University and released to the public domain in November 2020. Their document, titled “Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions” is a long read, yet it’s the most thorough report to date on the current state of mobile forensics. I spent and evening reading the report, and would like to summarise some of the key points in this article for my ne readers.

Encryption at rest is only good if the device is off

It’s great we encrypt the contents of our phones these days. But encryption presents a major challenge. Where do you store the encryption keys used to access the data? In the IT world, we have solutions such as HSM’s (Hardware Security Modules) which allow for keys to be physically separated from the data, but in the mobile world – there’s no such thing. Apple come close with their Secure Enclave Processor (SEP) but its primary function is to compute, not store.

As a result, both Android and iOS are guilty of storing keys in memory while the phone is running, even when locked. However Apple have the advantage here. iOS has the ability to evict keys from memory after the phone has been locked, if the developer has taken advantage of this feature. It’s also not enabled by default, meaning the majority of the apps on an Apple phone keep the keys nearby, as does Android. From a useability perspective, it’s great. For example, if your phone is locked and a call comes in – you’d want the phone application to access your contacts and tell you who’s calling. There are many examples of this – where apps need to have constant access to their data while running, regardless of the lock status, so keys live in memory simply to make our lives easier.

But the phone is locked…

At this point, it’s not necessary to defeat the encryption. The keys are laying in memory for anyone with access to read. The main thing preventing this is the pincode (or biometric\facial recognition, it serves the same purpose – but in both cases, the decryption keys are derived from a pincode, which is why it’s required on rst boot). Both Apple and Android have ‘back off’ algorithms which prevent people from automating the attempt to break a pincode. Apple again go one step further with their USB restricted mode, effectively making it harder to connect unknown devices to the phone, but evidence of exploits specially for this feature exist too. A six digit pin can take a matter of days on high end equipment to brute force, and forensic vendors have some tricks:

• Exploit chains exist within these vendors for Apple, relying on multiple methods to deliver exploits along with common Jailbreak exploits such as checkm8/checkra1n to successfully jailbreak and then exploit the OS or the SEP directly. This has the advantage of not only jailbreaking the device to run unsigned code, but to exploit the SEP into allowing infinite tries of the pincode

• Android has an additional attack vector, namely the hardware SoCvendors (such as Qualcomm) which are vulnerable to their own exploits, effectively bypassing pincodes entirely. Additionally, rooting an Android phone would normally trigger an automatic wipe – but again, exploits in the kernel are being used to prevent this, allowing unsigned code to run with data intact.

A common approach is to then perform a backup of the phone, obtaining all critical data, while its unlocked, allowing investigators to load the backup into a software reader for easy analysis.

An often overlooked attack vector: The Cloud

The article does a great job of covering another key path to obtaining user data – simply asking the Cloud provider. They effectively store the phones data for you, making them an equally attractive target as the phone itself. When it comes to law enforcement, Apple and Google comply with court orders for data, yet the data available to them varies. One thing they have in common is that they largely lack end-to-end encryption. Strong evidence exists that both companies retain decryption keys for backups and therefore it’s possible that the cloud provider could deliver phone backups along with keys to decrypt as part of a warrant request. Some exceptions exists (e.g. iMessage content and Google Duo content), but largely the meta-data is available to Google\Apple.

Additionally, the access tokens stored to access services like iCloud, Google Drive and other third-party cloud services are also in the same memory space as decryption keys, making it trivial for investigators to login to these services without the need to obtain warrants. Whether phone searches extend into cloud services is a question for lawmakers around the globe.

So what can we do about it?

The article also points out some great remediation methods both Apple and Google could make to ensure better protection of user data, but unfortunately there isn’t a great deal the end user can do to remediate. There are however some steps you can take to reduce the chances of success that forensic software may work on your device:

If you feel your about to loose physical access to your phone, you can:

1. Switch it o to remove keys from memory - while making it harder, exploits have been known to obtain the passcode from a cold boot
2. Initiate a backup, factory reset and restore the phone from backup at a later time
3. Utilise local backups of the phone if possible

Additionally, Android phones can take advantage of ‘adopted storage’ with SD cards, eectively separating the data onto external storage. Removing the card and switching o the phone not only removes the keys from memory, but also physically removes the data.

Conclusion

It seems the exploit market for mobile platforms is alive and well, and is actively being used to assist law enforcement. It’s unknown how many of these exploit companies like Grayshift and Cellebrite have, or indeed which adversaries on the web also know about them.

Apple seem to have a better grip technically when it comes to local phone security. The addition of the SEP makes OS\rmware exploits less likely to aect the cryptographic functions of the phone, and USB restricted mode is certainly something I’d like to see on Android (or go one step better and disable data channels until a PIN is entered). The ability to evict decryptions from memory when the phone is locked is a great feature of Apple, while being under-utilised by app developers.

Android still has a way to go, but some vendors provide hardware silicon for security functions similar to Apple (Samsung and Google). Thanks to the Linux kernel community, exploits are found and xed fast. Unfortunately, the overall eco-system of Android means too many moving parts, so fixes don’t always reach the consumer. There’s also not enough transparency from the SoC vendors when it comes to potential exploits in the wild.

Google have the upper hand when it comes to cloud security, by providing at least some end-to-end encryption for backups, but again the opt in nature for app developers mean it’s rarely used.

Credit to the original authors Maximilian Zinkus, Tushar Jois, and Matthew Green, of Johns Hopkins University for their excellent documentation of mobile security, and the sources\references included in their work.

	Posted December 31, 2020
	Written by John Payne