1 Introduction

An increase in demand for information technology (IT) resources has prompted many organizations to turn their attention to cloud computing. This technology has significant potential to reduce costs and increase efficiency in the workplace (Armbrust et al., 2009). Migrating to a cloud computing environment means an organization can replace much of its traditional IT hardware with virtualized, remote, and on-demand infrastructure services such as storage space, processing power, and network bandwidth (Grispos et al., 2012).

Storing corporate data online using cloud-based storage services such as Amazon S3, Google Docs, and Dropbox has become an effective solution for the business needs of a growing number of organizations (Mager et al., 2012). Cloud storage services can offer an organization greater flexibility and availability, with virtually unlimited storage space, as well as the ability to synchronize data between multiple devices. Typically, cloud storage providers will operate on the “freemium” financial model, offering customers free storage space with an option to purchase further unlimited storage space as they require (Mulazzani et al., 2011; Hunsinger and Corley, 2012). This business model has demonstrated to be successful, as the popularity of cloud storage services has soared in recent years. For example, Dropbox has seen its customer-base surpass 300 million users and now claim that over 1 billion files are saved every 3 days using its services (Hong, 2014; Constine, 2012). Mozy claim that more than six million individual users and 100,000 businesses are using their services, while Box has reported that implementation of its mobile device application increased 140% monthly in 2011 (MarketWire, 2012a; Mozy, 2014). Forrester Research has predicted that approximately two-thirds of adults who use the Internet in the United States are using some form of personal cloud storage service, often combining cloud services for both work and personal use (Forrester Research, 2012). Cloud storage services are also increasingly integrating into the retail, financial, legal, and healthcare enterprise markets (CRN, 2012; MarketWire, 2012b).

Although the benefits of using cloud storage services are attractive, a major concern is the security and privacy of data in these environments (Subashini and Kavitha, 2011; Ibrahim et al., 2010; Jansen and Grance, 2011; Grispos et al., 2014). For many organizations, there are several reasons to decline adoption of cloud storage services, including a necessity to protect mission-critical information, legal and regulatory obligations, and concerns regarding the confidentiality and integrity of their information (Grispos et al., 2013a; Zissis and Lekkas, 2012; Kaufman, 2009; Hay et al., 2011, 2012). These reservations are being validated as TrendMicro has reported that cloud adopters have witnessed an increase in the number of cloud security incidents as compared to traditional IT infrastructure security events (TrendMicro, 2011). Further complicating matters, researchers have demonstrated how cloud storage services, such as Dropbox, can be hijacked and exploited to gain access to an unsuspecting user’s account (Mulazzani et al., 2011; Kholia and Wegrzyn, 2013). There is no practical barrier preventing further exploitation of cloud storage services by users to access and retrieve files. Security incidents and criminal activity involving cloud storage services could require a subsequent forensic investigation to be undertaken.

There is a general consensus from both industry and academia that it may be difficult to investigate inappropriate or illegal activity involving cloud computing environments (Grispos et al., 2012; Reilly et al., 2010; Ruan et al., 2011; Taylor et al., 2010; Brodkin, 2008). One of the biggest challenges for forensic investigators examining cloud-based services is the ability to identify and recover digital evidence in a forensically sound manner (Grispos et al., 2012; Taylor et al., 2010). This problem is magnified in public cloud environments, such as those used by cloud storage providers. The remote, distributed, and virtualized nature of a public cloud environment means that the conventional, offline approach to forensic evidence acquisition is largely invalidated (Grispos et al., 2012). The tools and methods used to preserve and acquire a forensic copy of data stored on a traditional storage device are unlikely to transfer to a public cloud environment (Grispos et al., 2012). The remote and distributed nature of public cloud architectures can also make the identification of a single storage device containing relevant data impractical and even impossible. This means that an investigator cannot directly obtain a copy of the evidence required for analysis. An alternative approach is for the investigator to request the cloud storage provider to obtain a forensic copy of the storage device. However, this approach can take a significant amount of time, or be obstructed by cross-border jurisdictional disputes (Hay et al., 2011; Jansen and Ayers, 2007).

This research investigates a practical solution to problems related to investigating cloud storage environments using practitioner-accepted forensic tools. This study extends the results from an initial investigation, which examined the feasibility of an end-device, providing a proxy view of the evidence in a cloud forensics investigation (Grispos et al., 2013b). Relevant information and data from that conference publication have been included in this chapter for completeness. The contribution of this chapter is threefold. First, the findings from this research further supports the idea that end-devices which have been used to access cloud storage services can be used to provide a partial or snapshot view of the evidence stored in the cloud service. Second, the chapter provides a comparison of the files which can be recovered from different versions of cloud storage applications. The chapter also supports the idea that amalgamating the files recovered from more than one device can result in an investigator recovering a more complete “dataset” of files stored in the cloud service. Third, the chapter contributes to the documentation and evidentiary discussion of the artifacts created from specific cloud storage applications and different versions of these applications on iOS and Android smartphones.

The chapter is structured as follows: Section 2 discusses the challenges of conducting digital forensic investigations in a cloud computing environment and examines what work has been done in relation to cloud storage forensics, as well as presenting an overview of smartphone forensics. Section 3 proposes the hypotheses and research questions which guided this research and describes the experimental design undertaken to address the research questions. Section 4 reports the findings, and Section 5 is used to discuss the results and their impact on forensic investigations. Finally, Section 6 draws conclusions from the work conducted and presents future work.

2 Related work

A growing number of researchers have argued that cloud computing environments are inherently more difficult to investigate than conventional environments (Grispos et al., 2012; Reilly et al., 2010; Ruan et al., 2011; Taylor et al., 2010; Biggs and Vidalis, 2009). Ruan et al. (Ruan et al., 2011) defined the term “cloud forensics” as a “cross discipline of cloud computing and digital forensics” and described cloud forensics as a subset of network forensics. However, this definition does not take into consideration the virtualization aspect of the cloud (Grispos et al., 2012). Ruan et al. (Ruan et al., 2011) also noted that an investigation involving cloud computing would include technical, organizational, and legal aspects. Grispos et al. (Grispos et al., 2012) described how traditional digital forensic models and techniques used for investigating computer systems could prove to be ineffective in a cloud computing environment. Furthermore, Grispos et al. (Grispos et al., 2012) identified several challenges for forensic investigators, including creating adequate forensic images, the recovery of segregated evidence, and large data storage management. Taylor et al (Taylor et al., 2010) raised the concern that potential important evidence could be lost in a cloud environment. Registry entries in Microsoft Windows platforms, temporary files, and metadata could all be lost if the user leaves the cloud (Taylor et al., 2010). Reilly et al. (Reilly et al., 2010) speculated that one potential benefit of investigating a public cloud environment is that the data being investigated will be located in a central location, which means that incidents can, potentially, be investigated quicker. This is unlikely to be the case as the very nature of a public cloud service theoretically means that even evidence related to individuals within the same organization could be segregated in different physical locations and stored alongside data belonging to other organizations and the general public (Google, 2011).

To enable a forensic investigation to be conducted, evidence needs to be collected from cloud computing environments, thus introducing a unique set of challenges for forensic investigators (Dykstra and Sherman, 2012). Researchers have begun proposing methods of acquiring evidence from a variety of cloud providers and services (Dykstra and Sherman, 2012; Delport et al., 2011). Delport et al. (Delport et al., 2011) proposed the idea of isolating a cloud instance for further investigation; however, it is not clear how a forensic image of the instance under investigation is obtained after it has been isolated from the rest of the cloud environment. Dykstra and Sherman (Dykstra and Sherman, 2012) proposed three methods of evidence collection from Infrastructure-as-a-Service (IaaS) instances stored in the Amazon EC2 Cloud. The first method evaluated the performance of several forensic tools including FTK Imager and Encase Enterprise, which were used to extract evidence directly from the cloud instance in the Amazon Cloud. An issue with this method is that the investigator must be in possession of Amazon EC2 key pairs used to connect to the instance. The purpose of the key pairs is to ensure that only the instance’s owner has access to the instance (Amazon Web Services, 2011). These public/private keys are created by the owner when the instance is first created using the Amazon Web Services Management Console (Amazon Web Services, 2014). Unless the investigator can recover these keys, this method of acquisition cannot be used. The second proposed method involved acquiring evidence from the virtualization layer of a cloud by injecting a remote agent into the hypervisor of the cloud environment. This approach was evaluated in a private cloud environment, where the investigator had the ability to write into memory the guest virtual instance. However, this is unlikely to be the case in a public cloud environment, where the cloud provider will control access to the hypervisor and virtualization layer of a cloud (Grispos et al., 2013a). The final method proposed by Dykstra and Sherman involves requesting Amazon EC2 to collect the required evidence from the host on behalf of the investigator. Dykstra and Sherman note that the limitation of this method is that Amazon does not provide checksums to verify the integrity of the forensic image; therefore, the investigator cannot be certain that the data supplied by Amazon and the data stored in the cloud are identical (Dykstra and Sherman, 2012).

Researchers have also attempted to define investigative frameworks specifically addressing cloud storage providers (Chung et al., 2012; Lee et al., 2012; Quick and Choo, 2013a,b, 2014). Lee et al. (Lee et al., 2012) presented a framework for investigating incidents involving the Apple iCloud environment. The framework proposes the idea that the forensic investigator can examine Windows and Apple OSX-based systems, as well as Apple mobile devices to recover traces of data stored in the iCloud service. The research focused on the recovery of e-mail messages, memos, contacts, calendar information, and bookmarks. The limitation of this research is that Lee et al. (Lee et al., 2012) did not examine or discuss if the artifacts recovered from the end-devices were representative of the data stored in the cloud. There is the possibility that evidence still stored in the iCloud service was not recovered from the end-devices. Chung et al. (Chung et al., 2012) have also proposed a framework for investigating cloud storage services including Amazon S3, Google Docs, Dropbox, and Evernote.

Quick and Choo (Quick and Choo, 2013a,b, 2014) have undertaken three separate case studies to investigate the data remnants from Dropbox, Google Drive, and SkyDrive (now called OneDrive). In all three case studies, a Windows 7 personal computer and an Apple 3G iPhone were used to access and view a dataset stored in the cloud storage service. A Windows 7 personal computer was emulated using virtual machines. A variety of Web browsers were used in conjunction with the virtual machine and the specified cloud storage client application to collect data (Quick and Choo, 2013a,b, 2014). The findings from the personal computer analysis revealed that usernames, passwords, filename listings, file content, as well as dates and times that files were accessed are recoverable from a personal computer which has interacted with the above cloud storage services (Quick and Choo, 2013a,b, 2014). An iPhone device was used to access the dataset through the “on-device” Web browser in order to interact with the specified iOS cloud storage application. A logical extraction using MicroSystemation’s XRY was then performed. Their analysis of the logical extraction revealed that a number of artifacts can be recovered from various locations on the device which included the account services' username, as well as the filenames of viewed files (Quick and Choo, 2013a,b, 2014). However, it is worth noting that the content of the files stored in the cloud storage services were not recovered from the iPhone. Quick and Choo noted that future work should examine the physical acquisition of iPhone devices to determine if this method of acquisition can be used to recover the files stored in the cloud storage services (Quick and Choo, 2013a,b, 2014; Quick et al., 2013).

Separately, Quick and Choo (Quick and Choo, 2013c) investigated the modification of file content and metadata when potential evidence is downloaded and collected from a cloud storage account. Quick and Choo (Quick and Choo, 2013c) reported that the cryptographic hashes calculated from file manipulations, like uploading, storing, and downloading, using Dropbox, SkyDrive (now called OneDrive), and Google Drive reveal that no changes were made to the files’ content. Quick and Choo (Quick and Choo, 2013c) also state that after further analysing the downloaded files, notable changes were visible in the timestamp metadata. This was particularly evident in the “last accessed” and “file creation” time-stamps which indicated the last interaction with the cloud storage client software (Quick and Choo, 2013c).

Martini and Choo (Martini and Choo, 2013) focused on client and server-side forensic investigations involving the “ownCloud” service. Martini and Choo reported that forensic artifacts found on the client machine can link a user to a particular “ownCloud” instance (Martini and Choo, 2013). Furthermore, Martini and Choo recovered authentication and file metadata from the client, which were then used to decrypt files stored on the server (Martini and Choo, 2013). Martini and Choo (Martini and Choo, 2014) have also examined XtreemFS, a distributed filesystem commonly used in cloud computing environments, and documented both client and server-side artifacts which may be relevant to forensic investigations.

As part of the “Cloud Computing and The Impact on Digital Forensic Investigations” project, Biggs and Vidalis (Biggs and Vidalis, 2010) reported that very few High Tech Crime Units in the United Kingdom were prepared to deal with crimes involving cloud computing. As a result, Biggs and Vidalis believe a “cloud storm” will create difficulties and challenges for law enforcement investigators charged with investigating such environments (Biggs and Vidalis, 2010). Taylor et al. (Taylor et al., 2010) have extensively examined the legal issues surrounding cloud computing and comment that any evidence gathered from the cloud should be conducted within local laws and legislation. Phillips (Phillips, 2011) discussed the issue of keeping a chain of custody for such an investigation and has argued that the cloud is a dynamic paradigm and physically isolating it to conduct an investigation could be a daunting task for the investigator.

When multiple devices are used to access data in the cloud, the issues with the dynamic paradigm are exacerbated. A prime example of this impediment is the increasing use of mobile devices such as smartphones to access data stored in a cloud (Forrester Research, 2012; Chung et al., 2012). A smartphone device is distinguishable from a traditional mobile phone by its superior processing capabilities, a larger storage capacity, as well as its ability to run complex operating systems and applications (Grispos et al., 2011). From an evidentiary perspective, the smartphone potentially contains a considerable amount of forensic evidence. This potential is demonstrated in a study where researchers recovered more than 11,000 data artifacts from 49 predominately low-end devices (Glisson et al., 2011). As with a traditional mobile phone, the smartphone not only stores call logs, text messages, and personal contacts, but it also has the ability to store Web-browsing artifacts, e-mail messages, GPS coordinates, as well as third-party application related data (Hoog, 2011; Levinson et al., 2011; Morrissey, 2010). There are a number of tools that can be used to perform a data acquisition from a smartphone. Examples of these tools include Cellebrite’s Universal Forensic Extraction Device (UFED) (Cellebrite, n.d.); MicroSystemation’s XRY tools (Micro Systemation, n.d.); The Mobile Internal Acquisition Tool (Distefano and Me, 2008); Paraben’s Device Seizure (Paraben, n.d.) and RAPI Tools (Hengeveld, 2003). These forensic toolkits make it possible to investigate mobile devices that have been used to access cloud storage providers and extract evidence without directly accessing the cloud storage provider’s service. However, there is currently a lack of research as to the relationship between the residual data retained on multiple mobile devices subsequent to cloud interaction. There is also a lack of research into the impact that cloud storage applications have on mobile device residual data.

3 Experiment design

The lack of research examining the gap between device residual data and existing cloud data prompted research into the following hypothesis:

H1: Smartphone devices present a partial view of the data held in cloud storage services, which can be used as a proxy for evidence held on the cloud storage service itself.

H2: The manipulation of different cloud storage applications influences the results of data collection from a smartphone device.

H3: Different versions of cloud storage applications implemented on diverse operating systems retain varying amounts of residual data.

To address the hypotheses, the following questions were proposed:

1. To what extent can data stored in a cloud storage provider be recovered from a smartphone device that has accessed the service?

2. What features of the cloud application influence the ability to recover data stored in a cloud storage service from a smartphone device?

3. Do different versions of a cloud application used on the smartphone devices affect the ability to recover data stored in a cloud storage service from a smartphone device?

4. What metadata concerning the cloud storage service can be recovered from a smartphone device and what does the metadata data, recovered from a smartphone device, reveal about further files stored in the cloud service?

5. Does the amalgamation of files recovered from two or more versions of a specific cloud storage application provide a more complete dataset of files stored in the cloud service?

An experiment was devised to support the hypotheses and research questions proposed above. The experiment was broken into six stages. The six stages included (1) preparing the smartphone device and installing the cloud application; (2) loading a dataset to a cloud storage provider; (3) connect to the data through the application on the smartphone; (4) performing various file manipulations to the dataset and smartphone device; (5) processing the device using the UFED; and (6) using a number of forensic tools to extract the files and artifacts from the resulting memory dumps.

The forensic tools used in this experiment were the Cellebrite UFED version 1.8.5.0 and its associated application the “Physical Analyzer” version 3.7.0.352; FTK Imager, and FTK Toolkit version 4.0. The smartphone devices were processed with the UFED tools. The memory card used in the HTC Desire was processed using FTK Imager. The memory dumps were examined using a combination of Physical Analyzer and the FTK toolkit. Three smartphone devices were selected for use in this experiment: an Apple iPhone 3G and two HTC Desire devices. Table 1 highlights the notable features of these devices. These devices were selected for two reasons. First, they are compatible with the choice of forensic toolkit (UFED) used to perform a physical dump of the internal memory. Second, the operating systems used on these devices represent the two most popular smartphone operating systems in use (Gartner, 2012). Although more recent devices with newer versions of both the Android and iOS operating system exist, a lack of support from the forensic tools to perform a physical acquisition meant that these newer devices could not be included in the experiment. The decision to use these specific devices and tools was a pragmatic decision based on practicality and availability to the authors.

The selection criteria for the smartphone devices limited the number of cloud storage applications available to only the applications compatible with both operating systems. The scope of the experiment was limited in the following ways:

• This experiment was conducted in the United Kingdom, where Global System of Mobile (GSM) is the predominant mobile phone type, therefore non-GSM mobile devices were not considered;

• a number of smartphone devices which run either iOS or Android were not considered due to compatibility issues with the toolkit; and

• various cloud storage applications were not considered because they do not support either or both of the chosen operating system platforms.

The original implementation of this experiment used an iPhone 3G running iOS version 3.0 and an HTC Desire running Android version 2.1. The cloud storage applications for iOS included Dropbox v. 1.4.7, Box v. 2.7.1, SugarSync v. 3.0, and Syncplicity v. 1.6. The cloud storage applications for the Android device included Dropbox v. 2.1.3, Box v. 1.6.7, SugarSync v. 3.6, and Syncplicity v. 1.7. The experiment was then extended and repeated using an HTC Desire running Android version 2.3. Newer versions of the Android cloud storage applications implemented in this portion of the experiment included Dropbox v. 2.2.2, Box v. 2.0.2, SugarSync v. 3.6.2, and Syncplicity v. 2.1.1. Extending the experiment provides the opportunity to compare the results obtained between different versions of specific cloud storage applications. Updating the operating system and applications used on the iPhone device was considered. However, based on discontinued application support for iPhone 3G, a lack of support, at the time of the experiment, from the forensic tools for newer versions of the iPhone, as well as device availability, a pragmatic decision was made not to include an iOS device in the extended experiment.

A predefined dataset was created, which comprised 20 files, made up of image (JPEG), audio (MP3), video (MP4), and document (DOCX and PDF) file types. Table 2 defines the files used in this dataset. The same dataset was used in both the original and extended experiments. The following steps were used in both the original and extended experiments. These steps were repeated every time the experiment was reset for a different cloud storage application.

1. The smartphone was “hard reset,” which involved restoring the default factory settings on the device. In the case of the HTC Desire, the Secure Digital (SD) memory card was forensically wiped using The Department of Defence Computer Forensics Lab tool—dcfldd (Department of Defense Computer Forensics Lab, 2006). These steps were done to remove any previous data stored on the devices and the memory card.

2. The device was then connected to a wireless network which was used to gain access to the Internet. The cloud storage application was downloaded and installed either via the Android or Apple “app market,” depending on the device used. The default installation and security parameters were used during the installation of the application.

3. The cloud storage application was executed, and a new user account was created using a predefined e-mail address and a common password for that cloud storage application.

4. After the test account was created, the application was “connected” to the cloud storage provider’s services, which meant the device was now ready to receive the dataset.

5. A personal computer running Windows 7 was used to access the test account created in Step 4 and the dataset was then uploaded to the cloud storage provider using a Web browser. The date and time the files were uploaded to the cloud storage provider was noted. The smartphone was synchronized with the cloud storage provider to ensure the dataset was visible via the smartphone application.

6. When the entire dataset was visible on the smartphone, a number of manipulations were made to files in the dataset. Table 2 summarizes these manipulations. These included:

• a file being viewed or played;

• a file viewed or played then saved for offline access;

• a file viewed or played then deleted from the cloud storage provider; and

• some files were neither opened/played nor deleted (no manipulation).

7. The smartphone and cloud storage application were also manipulated in one of the following ways:

• Active power state—the smartphone was not powered down and the application's cache was not cleared;

• Cache cleared—the applications cache was cleared;

• Powered off—the smartphone was powered down; and

• Cache cleared and powered off—the applications’ cache was cleared and the smartphone was powered off.
These manipulations were done to mimic various scenarios a forensic investigator could encounter during an investigation. The smartphone was then removed from the wireless network to prevent any accidental modification to the dataset.

8. After the above manipulations, the smartphone device was processed to create a forensic dump of its internal memory. In the case of the HTC Desire, the SD memory card was processed separately from the smartphone. The HTC Desire was processed directly using the UFED, while a binary image of the SD card was created using FTK Imager. Before the HTC Desire was processed, the USB debugging option was enabled on the smartphone. This is required by the UFED to create the binary images from the device. The default parameters for a Physical Extraction on the UFED were selected, and the make and model of the device were provided. In the case of the SD card, the default parameters were used to create a binary image of the storage card. The resulting binary images were saved to a forensically wiped 16 GB USB flash drive. The extraction process for the iPhone differed from that of the HTC Desire as the device was processed using the Physical Analyzer “add-on,” which is designed to extract binary images from the iPhone. A step-by-step wizard provided instructions on how to prepare the device for the extraction. From the selection menu, the User partition was selected for extraction from the device, and the resulting memory dump was saved to a 16 GB USB flash drive.

9. The images extracted from the smartphone device were then loaded into Physical Analyzer, where the iOS and Android file systems were reconstructed. FTK 4 was used as the primary tool for analysis. This involved extracting the partitions from the dumps in Physical Analyzer and then examining them using FTK. Analysis techniques used included: string searching for the password, filtering by file types and browsing the iOS and Android file systems.

4 Findings

A summary of files recovered from the devices is shown in Tables 3-6. Several observations can be drawn from these results. Smartphone devices can be used to recover artifacts related to cloud storage services. These artifacts can include the files stored in the cloud storage service which have been accessed using the smartphone device and metadata associated to user and service activity. The exception to this was the recovery of a thumbnail of the JPEG image file not viewed on the device (03.jpg), which was recovered from 10 of the 12 applications examined.

The chances of recovering a file increase if the file has been saved for offline viewing. Files which were marked for offline viewing were recovered from all the applications except from version 2.0.2 of the Box Android application. The results also indicate that different versions of the Android applications can result in different files being recovered from a smartphone device. This finding was particularly evident for the Box and Syncplicity applications. The two different versions of these applications resulted in different files from the dataset being recovered. The metadata recovered from the devices included SQLite databases, text-based transaction logs, JavaScript Object Notation (JSON), and XML files. These metadata artifacts contained information related to user activity, account-specific information such as e-mail addresses, and described which files are stored in the cloud storage service.

An analysis of the memory dumps revealed that forensic artifacts can be recovered from the smartphone devices and in the case of the Android devices, the SD memory card. The Android operating system allows files to be stored in either the device’s internal storage memory or on an external memory card (Hoog, 2011). The iPhone does not have an external storage device and all artifacts recovered from the device were from the internal storage memory. The SD memory card used with the Android devices contained files which were either deleted by the user or deleted as a result of the cache being cleared. Clearing the application’s cache has an adverse effect on the recovery of files. This is more evident on the iPhone, which does not contain an SD card. Powering down the smartphone devices did not have an effect on the recovery of data. As a result, the files recovered were identical to that of the active power state scenario.

Artifacts stored in the internal memory of the Android devices can be recovered from a subfolder named after the application name. This subfolder can be recovered from the path /data/data (Hoog, 2011). Unlike the internal storage device, applications can store data in any location on the SD memory card (Lessard and Kessler, 2010). Therefore, the location of evidence on the SD card varies, depending on the application being investigated. The iOS file system creates a subfolder for each installed application under the directory /private/var/mobile/Applications in the User partition (Levinson et al., 2011). The name of the application directory installed under this location is assigned a unique 32-character alphanumeric folder name (Zdziarski, 2008). The folder name is different for each application installed on the device. Artifacts related to the iOS applications were stored under this folder location.

4.1 Detailed dropbox findings

On the HTC Desire, the forensic toolkits recovered nine files from both Android versions of Dropbox. Depending on application and device manipulation, either five or seven files were recovered from the iOS version of Dropbox. The results of which files were recovered from the Dropbox application are shown in Table 3.

4.1.1 Android applications

Files stored in the Dropbox service can be recovered from two locations on the SD card. These locations and their contents are valid for both versions of the Android Dropbox application. First, thumbnails of the JPEG images were recovered from the path /Android/data/ com.dropbox.android/cache/thumbs/. Second, files which were saved for offline viewing and the document files which were viewed and not deleted on the device were recovered from the path /Android/data/com.dropbox.android/files/scratch. Analyses of the “unallocated space” for both Android applications revealed that the two document files which were deleted (16.pdf and 20.docx) were still physically stored on the SD card. These two document files were recovered by FTK.

Metadata related to both versions of the Dropbox application were recovered from the internal memory of the smartphone. The metadata recovered were valid for both versions of the Android application. This metadata consisted of two SQLite databases and a transaction log. The two databases were recovered from the path /data/data/com.dropbox.android/databases/. The first database, db.db, has a table called dropbox, which contains metadata related to the files currently stored in the service, i.e., files which have not been deleted from the Dropbox service. Fields identified from this table are shown in Appendix A.

The second database, prefs.db, has a table called DropboxAccountPrefs which contains metadata related to the end-user. Information which can be recovered includes the user’s name and e-mail address used to register for the Dropbox service. A transactional log called log.txt is created by the Dropbox application to record service and user-related events including the creation of a new user account; successful and unsuccessful login attempts; as well as which files are synchronized to the Dropbox service. A UNIX epoch timestamp accompanies the documented event. This log can be recovered from the path data/data/com.dropbox.android/files.

Clearing the cache of both versions of the Dropbox Android application, removes the documents viewed and not deleted using the smartphone device (13.pdf and 17.docx), which are stored in the com.dropbox.android/files/scratch directory. These files were still physically stored on the SD card and are recovered by FTK. The files saved for offline access, JPEG thumbnails, and metadata remain unaltered.

4.1.2 iOS application

On the iOS device, a number of files stored in the Dropbox service were recovered from a subfolder called Dropbox, which can be found in the path /Library/Caches. The following files were recovered from this location: thumbnails of three JPEG images (01.jpg, 02.jpg, and 03.jpg); five files saved for offline access; and PDF and DOCX files, viewed but not deleted from the device (13.pdf and 17.docx). No other files stored in the Dropbox service were recovered from the iOS device.

The metadata artifacts recovered include an SQLite database, property list (plist) files, and text-based logs. These metadata artifacts described user activity and the files stored in the service. The main metadata repository is an SQLite database called Dropbox.sqlite which contains metadata about the files stored in the Dropbox service. This database can be recovered from a subfolder called /Documents from the application’s root directory. The ZCACHEDFILE table within this database contains metadata related to the files recovered from the directory located at /Library/Caches/Dropbox. Fields identified from the ZCACHEDFILE are shown in Appendix A.

Additional metadata related to the files which were saved as “favorite” and user-specific information can be recovered from two property list (plist) files. The first plist file located from the path /Library/Preferences/com.getdropbox.Dropbox.plist contains the e-mail address used for the Dropbox account and information related to files which were saved as “favorite.” The second plist file called FavoriteFiles.plist located from the path /Library/Caches/ contains further information about files which were downloaded and saved as “favorite.” Metadata which can be recovered from the FavoriteFiles.plist file includes the size of the file in bytes, the last modified time, the filename, and if the file has been deleted.

Two transaction logs were also recovered from the iOS device. The first log called Analytics.log records user-related activity and can be recovered from the path /Library/Caches. Each entry in the log is accompanied by a UNIX epoch timestamp. Figure 1 shows an example record from the Analytics.log file, which describes a PDF file which was viewed and then saved for offline access. The second log, run.log, which can be recovered from the path /tmp/ contains additional information about service-related transactions performed by Dropbox. When the Dropbox iOS application cache is cleared on the device, the only files which remain are those five files saved for offline access. This action also affects the Dropbox.sqlite database. When the application’s cache is cleared, the database only contains metadata for the five files which remain on the device. All other metadata artifacts remain unchanged.

4.4 Detailed syncplicity findings

From the Android Syncplicity applications, the forensic toolkits recovered 9 files from version 1.7 and 15 from version 2.1.1. Depending on application and device manipulation, either 0 or 14 were recovered from the iOS version of the application. The results of which files were recovered from the Syncplicity application are shown in Table 6.

4.4.1 Android applications

On the Android devices, Syncplicity-related artifacts varied between the two versions of the application. For version 1.7 of the application, files were recovered from three locations on the SD card. Thumbnails of all four JPEG images can be recovered in the path Android/data/ com.syncplicity.android/cache/cachefu/image_cache. The files which were saved for offline viewing (02.jpg, 06.mp3, 10.mp4, 14.pdf, and 18.docx) can be recovered from a folder called /Syncplicity, which is stored in the root directory of the application. Version 1.7 of the application encrypts the cache folder used by the application. This folder can be recovered from the path /Android/data/com.syncplicity.android/cache/private_syncp_file_cache _v3/encrypted/XYZ, where XYZ is the unique ID assigned to the user. No files from the dataset were recovered from this location.

Further, files and metadata related to version 1.7 were recovered from four locations on the smartphone device. Files from the dataset can be recovered from the device in a directory located at the path /data/data/com.syncplicity.android/files. The files recovered from this location have been deleted; however, FTK was used to recover specific files from the dataset. The files recovered were the three JPEG files (01.jpg, 02.jpg, and 04.jpg) and the three DOCX files (17.docx, 18.docx, and 20.docx) viewed and not deleted on the smartphone device. No other files were recovered from this location.

Metadata artifacts related to version 1.7 which were recovered from the device included a text-based log, XML files, and an SQLite database. These artifacts contained metadata related to both user activity and the files stored in the service. A text-based transaction log called 0000000000000000000.log.gz.tmp contains metadata about the application and its interaction with the cloud service. This log can be recovered from the path /data/data/com.syncplicity.android/app_log_syncplicity. An SQLite database called CacheDatabase can be recovered from the path /data/data/com.syncplicity.android/databases. This database contains a table called Files, which can be used to recover property metadata for all 20 files stored in the Syncplicity service. The information which can be recovered from the Files table can be seen in Appendix C.

A final source of metadata related to version 1.7 can be recovered from the path /data/data/com.syncplicity/shared_prefs. This folder contains the following XML files created by the application:

• auth_prefs.xml—this file contains the e-mail address used to register for the Syncplicity service;

• file_cache_preferences(XYZ).deleted.xml—XYZ is a number and 25 different files can be found with such a naming convention. The format of the file is shown in Figure 2 below. These XML files can be used as a mapping for the encrypted directory found on the SD memory card.

When the cache is cleared on version 1.7 of the application, the contents of the cache/cachefu/image_cache and encrypted folders are both deleted and recovered by FTK. No other files or artifacts are affected by the cache being cleared.

For version 2.1.1 of the application, files from the dataset were again recovered from both the SD card. Thumbnails of all four JPEG images can be recovered from the directory /Android/data/ com.syncplicity.android/cache/cachefu/image_cache. As with the previous version, version 2.1.1 of the application also encrypts the cache folder used by the Syncplicity service. This folder can be recovered from the path /Android/data/com.syncplicity.android/encrypted_storage. No files from the dataset were recovered from this location. This version of the Syncplicity application also contains a “decrypted” cache folder where 15 files from the dataset which were viewed on the device can be found. This folder can be recovered from the path /Android/data/com.syncplicity.android/temporary_decrypted_storage.

The metadata artifacts recovered from version 2.1.1 of the application included an SQLite database, a text-based transaction log and XML files. These artifacts were recovered from the internal memory of the device. A text transaction log called 0000000000000000000.log.gz.tmp contains metadata about the application and its interaction with the cloud service. This log can be recovered from the path /data/data/com.syncplicity.android/app_log_syncplicity. An SQLite database called VIRTUAL_FILE_SYSTEM.db was recovered from the path /data/data/com. syncplicity.android/databases. This database contains two tables of interest. The first table is called Files and contains metadata about all 20 files stored in the Syncplicity service. Appendix C shows the metadata which can be extracted from this table. The second table of interest is called Files_and_Folders_to_Synchronize which contains the names of the files saved for offline viewing. The XML files recovered from version 2.1.1 of the application can be found in the same location as the files in version 1.7: /data/data/com.syncplicity/shared_prefs. The contents of the XML files recovered from this location are the same for those recovered from version 1.7.

When the cache is cleared on version 2.1.1 of the application, the contents of the /cache/cachefu/image_cache and encrypted folders are both deleted and recovered by FTK. The files recovered from the temporary_decrypted_storage folder are also affected when the cache is cleared. This folder now contains only the files which were saved for offline access. All other files have been deleted and recovered by FTK. The VIRTUAL_FILE_SYSTEM database is also affected when the cache is cleared. No other files and artifacts are affected by the cache being cleared.

4.4.2 iOS application

Files and metadata related to the iOS version of the Syncplicity application can be recovered from four locations on the device under the application’s root directory. The only location where files from the dataset can be recovered from the iOS device is a cache folder created by the application under the path /Documents. Fourteen out of the fifteen files viewed on the device can be recovered from this folder. The MP4 file viewed and then deleted (12.mp4) was the only file viewed on the device and not recovered from this location.

Metadata related to the iOS application consists of an SQLite database, a plist file, and a text-based log. The SQLite database is called syncplicity.sqlite and can be recovered from the path /Documents/. This database contains a table called ZFILES which contains metadata about 18 files from the dataset; the entries which are missing from this table are related to files 04.jpg and 08.mp3. The property metadata, which can be recovered from this table, is shown in Appendix C. Metadata related to the user account can be recovered from a plist file called syncplicity.plist, which can be found in the path /library/preferences/com.syncplicity.ios. This plist file can be used to recover information such as the type of account used in the service (free or paid) along with the first and last name of the user who registered for the account. The final location of metadata related to the iOS Syncplicity application is a transaction log called syncplicity_0.log, which can be found in the location /library/caches. This log contains user and service-related transactions including files that were downloaded to the device and authentication token synchronization between the device and the Syncplicity service.

When the Syncplicity iOS application cache is cleared, the contents of the /Documents folder are deleted and no files are recovered from this location. No other files and artifacts are affected when the cache is cleared.

5 Discussion

The results described in the previous section can be used to provide answers to the research questions proposed in Section 1. Forensic toolkits, including the Cellebrite UFED, can be used to recover data from a smartphone device that has accessed a cloud storage service. The proposed use of forensic and analysis toolkits currently available to the forensic community provides a practical solution for investigating cloud computing environments. The lack of forensic tools is commonly cited as a mainstream challenge for investigating cloud environments (Grispos et al., 2012; Taylor et al., 2010; Dykstra and Sherman, 2012). The results from this research suggest that end-devices, such as a smartphone, may contain evidence in relation to cloud storage services which may be important in an investigation, and that this resource should be considered and examined. Furthermore, the tools and methods used in the experiment to recover data from the smartphone device are widely used and accepted by the forensic community. It must be acknowledged that the files recovered from the smartphone devices present a “snapshot in time” of the dataset stored in the cloud storage service. A file which is recovered from a smartphone does not mean that the file still exists in the cloud storage service, but provides an indication that at a point in time this file was stored in the service.

The results indicate that it is possible to recover files, providing a snapshot in time, that indicates the existence of potential data that is stored in cloud services like Dropbox, Box, SugarSync, and Syncplicity. On the HTC Desire, both deleted and available files were recovered. No deleted files were recovered from the iPhone. Certain file types were recovered more than other types. For example, the results show that JPEG thumbnail images were produced on all the devices running the Android applications. Thumbnail images were also recovered from the Dropbox and Box applications on the iOS device. In general, very few MP3 and MP4 files were recovered from all three devices. It is also interesting to note that more deleted files were recovered from the Box and Syncplicity applications than Dropbox or SugarSync applications on the HTC Desire.

The recovery of files from a smartphone device is affected by the user’s manipulation of the device and the cloud storage application. The Box iOS application and version 1.7 of the Android Syncplicity application were the only applications where there was no difference in the number of files recovered from the “active power state” and the “cache cleared state.” The results also show that when the cache was cleared in all other instances, fewer files were recovered than from the “active power state.” In the case of the iOS Syncplicity application, no files were recovered when the application’s cache was cleared. User actions on specific files have shown to influence the recovery of these files. For example, if a file has been viewed using the smartphone there is the opportunity for it to be recovered using forensic toolkits. This is provided that the user has not deleted the file or cleared the application’s cache. Files saved for offline access by the user can be recovered from the Android and iOS applications. There were two exceptions to recovering these files. The first is when the cache was cleared for the Syncplicity iOS application, none of the files saved for offline viewing were recovered. The second is when the cache was cleared for version 2.0.2 of the Android Box application, none of the files for offline viewing were recovered from any of the states. Deleted files were recovered from the Android devices. The recovery of these files is dependent upon them not being overwritten by new data on the SD memory card. No deleted files were recovered from the iOS device.

It is interesting to note that there are discrepancies in the number of files recovered depending on the version of the cloud storage service implemented on different mobile platforms and operating systems. While the versions of Dropbox produced the same number of files, there were vast differences between specific versions of Box, SugarSync, and Syncplicity. A summary of the total number of active power state files recovered from the Android and iOS devices by cloud application is shown in Figure 3. This table presents the files recovered from the active power state excluding thumbnails and deleted files.

Metadata was recovered from all the applications on all three devices. The metadata recovered included text-based transaction logs containing user and service activity, SQLite databases, and JSON files containing property metadata data related to the files in the service, as well as XML files containing user-specific metadata such as login credentials. The metadata recovered from the devices can also present the investigator with a greater representation of the dataset stored in the cloud. For example, depending on the operating system platform, device and application manipulation, between 4 and 15 files were recovered from the iOS and Android Box applications. However, the metadata artifacts recovered from these applications run on the Android and iOS devices revealed information about files stored in the Box service which were not recovered from the device. The JSON files and SQLite databases recovered from the internal memory of these devices contained records for all 20 files stored in the Box service. The information which can be recovered includes the filenames and unique identification number assigned to each file as well as user-specific identification numbers and e-mail addresses used to register for the storage services. This metadata could help an investigator justify requesting a court order or warrant for a cloud storage provider to recover further files from the account being investigated (Chung et al., 2012).

Furthermore, using metadata artifacts recovered from the Box application, it is possible to download further files from the Box service. This can include files which were not recovered from the smartphone device itself. This information can be recovered from all three versions of the Box application which were included in this experiment. This is possible by constructing a direct link to the file stored in the Box service using the Box API (Box Platform Developer Documentation, n.d.). This direct link requires three pieces of information from the smartphone device, for example, from an Android device:

1. The authentication token, which can be recovered from the myPreference.xml file found in the path /data/data/com.box.android/shared_prefs. For example, in Figure 4, the authentication token is shown as < string name = “authToken” > u5es7xli4xejrh89kr6xu14tks6grjn3 </string >;

2. The unique file ID number called mId, which is the ID number assigned to each file stored in the service. This information can be recovered from the json_static_model_ emailaddress_0 file stored in the directory /data/data/com.box.android/ files/. The investigator requires the ID number for each file they wish to download from the Box service (Figure 5); and

3. A URL from the Box API (Box Platform Developer Documentation, n.d.): https://www.box.net/api/1.0/download/auth_token/file_id, where auth_token is the authentication token for the account and file_id is the mId number of the file to be downloaded.

This information can be combined to reconstruct a direct link, which will result in the file associated with the mId being downloaded. For example, the URL: https://mobile-api.box.com/api/1.0/download/u5es7xli4xejrh89kr6xu14tks6grjn3/2072716499 can be used to recover the JPEG image 03.jpg from the dataset. This information is not unique to the Android, and the data needed to reconstruct the URL can also be recovered from the iPhone device. Relevant artifacts can be found in the BoxCoreDataStore.sqlite database in the directory /Documents/. The privacy and legal implications associated with this practice are out of scope for this chapter.

The ultimate goal of a forensic investigator should be to recover as much evidence as possible from a cloud storage service. An analysis of the files recovered from two of the Android applications (Box and Syncplicity) has revealed that different files were recovered from different versions of these cloud storage applications. Forensic toolkits recovered 15 files from version 1.6.7 of the Box application and only 6 from version 2.0.2, while 5 files were recovered from version 1.7 of Syncplicity application and 15 from version 2.1.1. These results suggest that there is an opportunity to recover a more complete dataset from the cloud service if multiple devices are examined as part of an investigation. The results from the experiment propose the idea that an investigator who analyzes multiple devices with different versions of an application could recover a more complete dataset than that from just a single device. The proportion of artifacts which can be recovered from two or more devices are calculated as |m₁ $\cup$ m₂ $\cup$ m₃|, where m_n, are the devices which are being analyzed as part of a forensic investigation of cloud storage services. Preliminary data demonstrated in Table 7 supports the idea that multiple devices can produce a more complete dataset for a forensic investigator. In three out of the four applications examined, a bigger dataset was recovered by combining the number of files recovered from each device to create a more complete dataset.

Table 7

Total Files Recovered from Multiple Devices

Cloud Storage Service	m1	m2	m3	|m1 $\cup$ m2 $\cup$ m3|
	{files recovered}	{files recovered}	{files recovered}	{total files recovered}
Dropbox	{2,6,10,13,14,16,17,18,20}	{2,6,10,13,14,16,17,18,20}	{2,6,10,13,14,17,18}	{2,6,10,13,14,16,17,18,20} = 9
Box	{1,2,4,5,6,8,9,10,12,13,14,16,17,18,20}	{5,6,8,9,10,12}	{2,6,10,14,18}	{1,2,4,5,6,8,9,10,12,13,14,16,17,18,20} = 15
SugarSync	{1,2,4,6,10,13,14,16,17,18,20}	{1,2,4,6,10,13,14,16,17,18,20}	{1,2,4,5,6,8,9,10,12,13,14,16,17,18,20}	{1,2,4,5,6,8,9,10,12,13,14,16,17,18,20} = 15
Syncplicity	{2,6,10,14,17,18,20}	{1,2,4,5,6,8,9,10,12,13,14,16,17,18}	{1,2,4,5,6,8,9,10,13,14,16,17,18,20}	{1,2,4,5,6,8,9,10,12,13,14, 16, 17,18,20} = 15

Finally, the results from the experiment can also be used to support the hypotheses proposed in Section 1. H1, the smartphone devices in this experiment contain a partial view of the data held in the cloud storage service. This statement continues to hold when the device is powered down. Therefore, a smartphone device potentially presents a forensic investigator with a proxy view of the evidence held in the cloud storage service. In support of H2, clearing the application’s cache has an adverse effect on evidence collection. The data indicates partial support for H3 in that different files are recovered from the same cloud application on different mobile device platforms and operating systems for some cloud applications.

6 Conclusions and future work

The attractiveness of cloud computing is impacting where individuals and organizations store their data. The growing popularity of cloud storage services means that such environments will become an attractive proposition for cybercrime. This could result in an increase in demand for investigations of cloud storage services. However, the issue of conducting digital forensic investigations of cloud computing environments is an increasingly challenging and complex task. One of the biggest challenges facing investigators is the ability to identify and recover digital evidence from the cloud in a forensically sound manner. The remote and distributed nature of cloud computing environments means that the traditional offline approach to forensic evidence acquisition is invalidated. As a result, both industry and academia are beginning to examine different methods and techniques to investigate cloud computing environments.

This work presents the examination of end-devices such as smartphones, which have been used to access cloud storage services. The data recovered from these devices can be used by investigators as a proxy for potential evidence stored in cloud storage services. The effectiveness of this method is dependent on the operating system, specific cloud storage application implementation, and usage patterns. In other words, the potential recovery of data increases if a device has been used to view the files through a cloud storage application and the user has not attempted to clear the cache of recently viewed files.

Two advantages become apparent to using this investigative approach. First, the investigator can begin the chain of custody process when the device is seized and does not need to rely on the cloud provider to begin this process. Second, the tools and methods which have been used to recover data stored in cloud storage services are widely used by the forensic community. The recovery of metadata artifacts from the smartphone device can, in some scenarios, provide the investigator with insight into further data stored in a cloud service. The information recovered can also help justify a court order requesting assistance from the cloud storage provider to recover further files from the specific account.

Future research needs to be conducted to extend the analysis of smartphone hardware and operating systems, to increase the size and file types of the dataset and conduct research into other cloud storage services. The methodology proposed in this chapter can be extended to other smartphone devices and operating systems such as Windows Mobile and Blackberry devices. In addition, research can also be conducted to investigate other cloud storage services such as Google Drive, OneDrive, and CloudMe. The dataset used in future experiments can also be extended to include additional data types as well increasing the overall number of files and files of varied sizes.

The analytical findings from this research indicated that examining multiple devices and multiple versions of cloud storage applications can result in a more complete dataset being recovered. This experiment can be extended to examine a number of mobile devices such as tablets, iPads, iPods, and eBook readers. Other research questions that warrant investigating include the examination of usage patterns along with the construction of relevant timelines across multiple devices and cloud applications.

From a corporate security perspective, future work needs to examine the risk of data leakage that cloud storage applications can introduce to an organization. This research identifies the implications from a corporate policy perspective and determines if cloud applications introduce opportunities for data leakage in organizations. If so, what is the most effective way to minimize risk and maximize employee productivity? The results from this research provide the foundation for further development of security measures and policies for both cloud providers and smartphone users that mitigate the potential risk of data leakage.

Appendix A Metadata artifacts recovered dropbox service

Appendix B Metadata artifacts recovered box service

Appendix C Metadata artifacts recovered syncplicity service