The Challenge of Mobile Forensics


Posted on by John Linkous

At RSA Conference 2014 in San Francisco, Andrew Hoog and the viaForensics, Inc., team presented "Mobile Analysis Kung Fu, Santoku Style." A highly informative presentation, Andrew and a viaForensics engineer, Sebastian Selma, gave a thorough overview of the mobile device security black art of forensics. While the practice of data forensics is difficult enough on a desktop or laptop computer, mobile devices make forensics a much more difficult task for several reasons:

  • Form Factor: Mobile devices tend to hold the kind of data that is needed for, say, court discovery, in multiple locations, including (at a minimum) the universal integrated circuit card (UICC), usually referred to as the "SIM card," which holds the unique international mobile subscriber identity (IMSI) and call log data; RAM, which typically holds apps and the data associated with them; and removable storage, such as microSD cards, which can be used to store both apps and data, as well as media such as photos and videos. This whole process is made more difficult by the few standards that define where data is stored and how it is formatted.
  • Hardware Fragmentation: As any Android OS device owner will tell you, there is no one "Android device." Hundreds of different hardware architectures, processors, and peripherals are supported on the Android platform. Even single-platform vendors like Apple have the same problem: lots of different versions of essentially the same device. And unlike a standard desktop or laptop computer where hardware is relatively standardized—think SATA interface hard drives and SDRAM—the types of hardware used in mobile devices can vary wildly. From a data extraction perspective, this makes physical "on die" extraction—the most forensically sound method—very difficult because proprietary physical extraction tools and interfaces increase exponentially with the number and type of hardware.
  • OS Fragmentation: Just as with hardware, there are multiple versions of device operating systems. In addition to many different versions of Android, there are many minor revisions of Apple iOS, Blackberry, Symbian, and Microsoft—and all have a substantial footprint in the mobile OS arena. Moreover, just because an OS vendor upgrades their software, it doesn't necessarily mean it will be available for a specific handset. Carriers such as Verizon, AT&T, and T-Mobile are generally responsible for packaging and deploying OS upgrades because they often include proprietary management components that are tied closely to the OS.
  • App (Non-)Standards: Application developers have a plethora of options when determining where to store their data, and from a forensics perspective, this is not necessarily a good thing. App developers can create content that is stored on virtually any component of a mobile device, and since there are no real standards or patterns to follow, the forensic engineer's life is substantially more complicated than it should be.

So what can be done, and who is to blame? According to Hoog and Selma, everyone has some accountability. For hardware manufacturers, minimizing customization of the OS and ensuring frequent, consistent, and timely patching is critical. For wireless carriers, controlling the primary data network is key to ensuring mobile-device security on their network. OS and application developers need to better control code distribution and develop more consistent methods of sandboxing not only code, but where apps store themselves and their data. Finally, corporations and end users bear the responsibility of developing sound mobile-device management policies and following those policies, respectively. When everyone works together mobile forensics becomes a much easier task.

Contributors
John Linkous

, Technology Advisor

forensics & e-discovery mobile security

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community

Related Blogs