Werner Hauger

Martin Olivier

DETERMINING TRIGGER INVOLVEMENT DURING FORENSIC ATTRIBUTION IN DATABASES

Keywords: Database forensics, database triggers, forensic attribution

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Database triggers are a feature of many relational databases. They were formally incorporated in the ISO/IEC 9075 SQL standard in 1999 and have since been updated [START_REF]International Standards Organization and International Electrotechnical Commission[END_REF]. However, the digital forensic community has not paid much attention to database triggers. While developing a new framework for database forensics, Khanuja and Adane [START_REF] Khanuja | A framework for database forensic analysis[END_REF] recognized that the actions performed by triggers are forensically important. Hauger and Olivier [START_REF] Hauger | The role of triggers in database forensics[END_REF] have conducted research on the exact role that triggers play in database forensics. They studied trigger implementa-tions in a number of proprietary and open-source relational databases. Among other things, Hauger and Olivier discovered that the forensic attribution process is impacted by trigger actions.

Triggers can introduce side effects during the normal flow of operations. The side effects include performing additional actions or preventing the completion of the triggering operations. Certain types of triggers can also manipulate or completely replace the original operations. This means that what an original operation intended to do and what actually happened may not necessarily be the same.

As noted above, triggers can also lead to incorrect conclusions when the attribution of database operations is performed. This is because a trigger performs its actions with the same user credentials as the original operation that caused the trigger to fire. Some databases might log additional information with an operation to indicate that it was performed by a trigger. However, it cannot be assumed that such an extended log always will be available to a forensic investigator.

It is, therefore, important that a forensic professional be aware of triggers during an investigation. The first step is to determine if any triggers are present in the database under investigation. If triggers are indeed present, the next step is to establish if any of the triggers may have influenced the data being analyzed.

A database under investigation can potentially contain hundreds or even thousands of triggers. It is not feasible for a forensic investigator to analyze every single trigger to determine if it had an impact on the data being analyzed. A more efficient technique is required to identify the triggers that must be analyzed as part of an investigation.

This chapter proposes a test to quickly and easily establish if a trigger plays a role in the data of a database table being analyzed. A generic algorithm is presented that can be applied to any SQL database that supports triggers. The algorithm generates a list of triggers that potentially influence the data in a given database table, enabling a forensic investigator to focus only on the identified triggers.

Background

This section briefly discusses forensic attribution and database triggers.

Forensic Attribution

Forensic attribution involves the use of technical means to establish the presence of a person or object at the scene of a crime after the fact [START_REF] Afanasyev | Privacy-preserving network forensics[END_REF]. In digital forensics, various techniques can be used to determine which actor, be it a person or a program, has performed specific actions in a digital system. However, determining the actual person responsible for actions in a digital system is problematic. This is because the physical person is located outside the boundaries of the digital system. Therefore, information from outside the digital system is required to positively link a specific person to the human-digital-system interface.

Attribution is performed during the digital evidence examination and analysis step. This step is part of the investigative processes as defined by the ISO/IEC 27043 draft standard [START_REF]Information Technology -Security Techniques -Incident Investigation Principles and Processes (Final Draft)[END_REF]. The standard seeks to provide an overall framework for incident investigations and processing. It encompasses various other standards, each of which define the sub-processes in more detail.

Many digital systems create and maintain audit records and metadata [START_REF] Cohen | Digital Forensic Evidence Examination[END_REF]. These include dates, timestamps and file ownership, authentication and program execution logs, output files generated by program execution, network traffic logs and numerous other traces. The artifacts are created as part of normal system operation. They allow for the confirmation and review of activities as well as debugging errors.

A forensic investigator can employ authentication and authorization information to assist with the attribution process [START_REF] Cohen | Digital Forensic Evidence Examination[END_REF]. Authentication is implemented in many digital systems to identify users and grant appropriate system access. The access available to a user depends on the authorization afforded by the user's credentials. Unauthorized users are prevented from accessing and operating the system. Authentication information describes the actors in a digital system and authorization information describes the actions that the actors can perform.

Another attribution technique is to order and connect the various traces found in a digital system to create a chain of events [START_REF] Cohen | Digital Forensic Evidence Examination[END_REF]. The sequences of these events describe how the system reached a given state. By determining the actions that lead to the events and the actors that performed the actions, the person or program responsible for the actions can potentially be identified.

However, authentication information and the various traces are not infallible. Attackers can bypass authentication or steal the credentials of an innocent user. Traces can be modified or even removed to hide malicious activity. Furthermore, attribution techniques themselves can be abused by malicious actors. Stolen user credentials can be used to create traces that falsely implicate innocent users.

It is, therefore, important for a forensic investigator to attempt to obtain multiple independent traces that portray the same event. The independent traces can then be used to correlate the actions and identify possible manipulations. By excluding the manipulated information or reconstructing the original information, a forensic investigator can move closer to identifying the real actor or actors.

Olivier [START_REF] Olivier | On metadata context in database forensics[END_REF] has investigated attribution in forensic investigations involving databases. He noted that database forensics can use the same techniques as general digital forensics to perform attribution. The traces in a database are available in various log files and are also stored in system tables. The authentication of database users and the authorization of their operations is built into many databases. The same caveats that apply to general digital forensics also apply to database forensics.

Triggers

Database triggers originated in the mid 1970s in "active databases." It was not until the 1990s that this technology gained traction and was incorporated in commercial databases. The researchers at the time referred to triggers as event-condition-action rules [START_REF] Simon | Promises and realities of active database systems[END_REF]. The action portion of a rule was executed when the condition was true after being initiated by a triggering event. The condition was an optional part and a rule without a condition was called an event-action rule. The term database trigger was adopted when the technology was incorporated in the SQL standard in 1999.

Triggers are implemented for various reasons. Ceri et al. [START_REF] Ceri | Practical applications of triggers and constraints: Success and lingering issues[END_REF] distinguish between automatically-generated and manually-crafted triggers and suggest different uses for the two types of triggers. One use for manuallycrafted triggers is the creation of internal audit trails. Developers now leverage this use case for auditing in their own external applications. When used for external auditing, the triggers normally take data from the original tables and store them in dedicated audit tables. Since the tables are part of the custom application, there is no particular layout or content. In general, the audit tables indicate which users performed operations, what operations were performed and when the operations were performed.

Independent of their usage, all the actions performed by triggers can be classified into two groups: (i) general actions; and (ii) conditionspecific actions. A general action trigger performs its actions every time the triggering operation is performed. This makes the trigger suitable for general auditing. For example, a financial institution could use general action triggers to keep track of all the transactions performed on its system. A trigger would record relevant information such as the nature of a transaction, the time it was performed and the user who performed the transaction.

In contrast, condition-specific action triggers only perform their actions under specific circumstances. The circumstances are based either on the data that is manipulated by the triggering operation or on the user who performs the triggering operation. For example, a financial institution may have a legal requirement to report a certain type of monetary transaction that exceeds a specified amount. This requirement can be implemented using a condition-specific trigger that checks all transactions as they are executed. The trigger would only fire when a transaction type matches the type that has to be reported and the associated transaction amount exceeds the legislated amount.

Consider a situation where a financial institution might for security reasons only allow supervisors to execute certain transactions. However, due to the volumes of these transactions and the ratio of supervisors to normal operators, it may not possible to have only supervisors execute the transactions. To address this problem, the financial institution can implement an override that is invoked by a normal operator to enable him to execute a restricted transaction after a supervisor has authorized the transaction with his credentials.

Naturally, the financial institution would want to keep a very close eye on override transactions to identify any irregularities as soon as possible. A condition-specific action trigger can be used in this scenario to audit the restricted transactions. The trigger is created to fire only when a user who is not a supervisor executes a restricted transaction.

At first glance, it might appear that the two types of triggers would not interfere with a forensic investigation. However, one cannot assume that the triggers have not been modified by an attacker to perform malicious actions. For example, an attacker might wish to collect all the credit card numbers entered into a database. The attacker could set up his own general action trigger on the table that stores the credit card information or he could modify an existing audit trigger on the table. The trigger is created or the existing trigger is modified to place the credit card information in a separate location internal or external to the database. Another process is then scheduled to transmit the collected information to a location outside the financial institution from where the attacker can retrieve it at his convenience.

A malicious trigger can also be condition-specific. Consider a business that supports various forms of payment for its products and services. The attacker could add or modify a trigger so that it fires only when the payment method for a transaction is a credit card. This trigger then extracts the credit card information in the same manner as before. The attacker also may wish to perform malicious actions only when a specific user performs operations on the database. This could be because this particular user's actions are less likely to be scrutinized. Alternatively, the attacker may have a desire to implicate the user in the malicious actions.

Trigger Identification

This section describes a systematic approach for identifying triggers that are potentially significant to an investigation of a database object. The approach is then formally specified as an algorithm that is database independent.

The simplest way to determine if a trigger has an effect on data contained in an object is to check if the name of the object is mentioned in the trigger. Having identified all such triggers, the next step is to manually check the kinds of SQL statements that refer to the object in question. Since SQL statements can be encapsulated in a user function or procedure, it is not enough to merely search the trigger content. The content of all called functions and procedures also have to be checked. Since additional functions and procedures can be invoked by a function or procedure, the contents of these additional functions and procedures also have to be checked. This process is repeated until the lowest level function or procedure has been reached that invokes no other function or procedure.

This top-down checking is formalized in Algorithm 1. To simplify the definition of the algorithm, procedures are assumed to be equivalent to functions. From a database perspective, there are differences between a function and a procedure. Some of the differences are general while some are database-specific.

Algorithm 1 (Top-Down): Identify all the triggers that directly or indirectly access an object of interest.

1. Assume that a trigger is an ordered pair (t, bt) where t is the name of the trigger and bt is the code (or body) of t. Assume that functions exist of the form (f, b f ) where f is the function name and b f is the body of function f . The body bx of a trigger or function x consists of primitive statements as well as calls to other functions. Let f ∈ bx indicate that f is used in the body of trigger or function x.

2. Let T be the set of all triggers and F be the set of all functions. Let ω be the name of the object that is the target of the search. Let ω ∈ bx indicate that ω is used in the body of trigger or function x. Let R1 the set of triggers that access ω directly. Then,

R1 = {t ∈ T | ω ∈ bt} 3.
Functions may be called by a trigger, where the function accesses ω, thereby providing the trigger with indirect access to ω. Therefore, the ∈ notation is extended to also indicate indirect access. The new relationship is denoted as ∈ * . Then,

f ∈ * bx ⇔ ȷ f ∈ bx direct case ∃ by ∋ f ∈ by & y ∈ * bx indirect case
ff Therefore, the complete set of functions used directly or indirectly by a trigger t is given by:

F t = {f | f ∈ * bt ∋ t ∈ T }
The subset of the functions that access ω is given by:

R2 = {t ∈ T | ∃ f ∈ F t ∋ ω ∈ b f }
The triggers that directly and indirectly access ω are then combined as:

R = R1 ∪ R2
The algorithm produces a set of triggers R that refer directly or indirectly to the object (search target). At first glance, the algorithm seems simple and straightforward. However, a major problem arises when the steps are translated into SQL statements -How does one reliably identify other procedures in the content via string matching? The exact SQL syntax for invoking procedures is database-specific. It is possible to obtain the list of all the user function and procedure names and then search for each name in the content. However, this is not necessarily more reliable. Depending on the naming convention used by the database developers, the names of different object types could overlap (e.g., a table, a view and a procedure could all have the same name).

It is, therefore, necessary to design a new technique for finding the triggers that directly or indirectly refer to the object of interest. Alternatively, it is possible to start with all the triggers, functions and procedures and then narrow them down to only those that refer to the object of interest. Algorithm 2 formalizes this bottom-up technique.

Algorithm 2 (Bottom-Up): Identify all the triggers that directly or indirectly access an object of interest.

1. Assume that a trigger is an ordered pair (t, bt) where t is the name of the trigger and bt is the code (or body) of t. Assume that functions exist of the form (f, b f ) where f is the function name and b f is the body of f . The body bx of a trigger or function x consists of primitive statements as well as calls to other functions. Let f ∈ bx indicate that f is used in the body of trigger or function x.

2. Let T be the set of all triggers and F be the set of all functions. Let ω be the name of the object that is the target of the search. Let ω ∈ bx indicate that ω is used in the body of trigger or function x. Let C be the combined set of all triggers T and functions F . Then,

C = T ∪ F 3.
Let U be the set of triggers and functions that access ω directly. Then,

U = {c ∈ C | ω ∈ bc}
Let U t be the subset of triggers in set U . Then,

U t = {t ∈ U | t ∈ T }
The subset U ′ of U without any triggers is given by:

U ′ = U -U t
Let U1 be the first iteration of a set of triggers and functions that access the functions in set U ′ directly. Then,

U1 = {d ∈ C | ∃ e ∈ b d ∋ e ∈ U ′ }
Let U t 1 be the first subset of all the triggers in the first set U1. Then,

U t 1 = {t ∈ U1 | t ∈ T }
The first subset of U1 without any triggers is given by:

U ′ 1 = U1 -U t 1
The sets U2, U t 2 and U ′ 2 can be constructed congruently. Specifically, the construction of the sets can be repeated i times (i = 1, 2, . . .). Consequently, the i th iteration of set U1 is given by:

Ui = {x ∈ C | ∃ y ∈ bx ∋ y ∈ U ′
i-1 } Furthermore, the i th subset of all the triggers in set Ui is given by:

U t i = {t ∈ Ui | t ∈ T }
Finally, the i th subset of set Ui without any triggers is given by:

U ′ i = Ui -U t i
The combined set of all identified triggers U t , U t 1 ...U t i is given by:

R = U t ∪ U t 1 ∪ ... ∪ U t i
Since C is a finite set of triggers and functions, the algorithm reaches a point where set R no longer grows. Specifically, this is when the n th set Un becomes empty, in other words Un = φ. At this point the algorithm terminates.

Algorithm 2 also produces a set of triggers R that refer directly or indirectly to the object of interest. However, it eliminates the need to search for calls to functions, which is difficult and database-specific. Instead, the algorithm repeatedly searches for known function and trigger names in the same way that it searches for the name of the object of interest.

Algorithm Implementation

This section discusses the implementation of the proposed algorithm. Implementations are considered for the same databases discussed in [START_REF] Hauger | The role of triggers in database forensics[END_REF].

The databases considered are all relational databases, so it can be assumed that data and metadata about triggers, functions and procedures are stored in relations. The most straightforward choice is to implement the algorithm using SQL. Each step of the algorithm is written as a simple SQL statement. SQL statements that are repeated are placed into functions. All the separate SQL steps and functions are then combined into a procedure.

An important point to keep in mind is that the database implementations available from vendors vary considerably. This includes the data dictionary that specifies what information is stored and how it is stored. Thus, in one implementation, retrieving all the triggers may involve just one select statement while in another it may require performing select statements on multiple differently-structured tables. Due to these differences, it is not possible to create template select statements that could be filled in with column and table names corresponding to a particular database. Instead, it is necessary to provide database-specific SQL statements for each database implementation.

A pure SQL implementation has two major drawbacks. The first drawback is that database vendors use different SQL dialects to extend the standard SQL statements. These extended features, such as variables, loops, functions and procedures, are required to implement the algorithm. Oracle uses an extension called PL/SQL that IBM DB2 version 9.7 and later support [START_REF] Chan | Oracle to DB2 Conversion Guide: Compatibility Made Easy[END_REF][START_REF] Feuerstein | Oracle PL/SQL Programming[END_REF]. Microsoft has a competing extension called Transact-SQL or T-SQL used by SQL Server and Sybase [START_REF] Jones | SQL Functions Programmer's Reference[END_REF][START_REF] Turley | Beginning T-SQL with Microsoft SQL Server 2005 and[END_REF]. Other databases such as MySQL more closely adhere to the official SQL/PSM extensions that are part of the SQL standard [START_REF]International Standards Organization and International Electrotechnical Commission[END_REF]. These differences would require a separate implementation for every database product. The second drawback is that the implementation has to be stored and executed within the database being investigated. However, this conflicts with the forensic goal of keeping the database uncontaminated.

Another approach is to implement the algorithm using a pure programming language. This provides the advantage of having to create only one application using a single syntax. The application is designed to read the database data from a file that conforms to a specific format. The drawback with this design is that the data first has to be extracted from the database in the correct format. This requires a separate extraction procedure for every database implementation. The extraction procedure also may have to be stored and executed on the database, which potentially contaminates the database.

The latter implementation choice involves a more involved two-step process. First, the required data is extracted from the database and transformed into the format expected by the application. Next, the standalone application is invoked with the created data file.

Thus, a hybrid approach that combines the advantages of the two choices is a better solution. A single application can be built using a conventional programming language that provides a database-independent framework for accessing and using databases. Next, database-specific formatted SQL statements in the application are used to select and retrieve data from the database under investigation. The database would remain unchanged because the algorithm logic as well as the SQL statements are external to the database.

The authors of this chapter are currently building a prototype that uses the hybrid approach to implement the bottom-up algorithm (Algorithm 2). The prototype comprises a standalone application written in Java that connects to the database being investigated via the JDBC programming interface. A JDBC database driver is required to handle database communications with each database.

The required data is selected and retrieved by executing databasespecific SQL statements. These SQL statements, together with the database and JDBC driver configuration, are externalized to a definition file. This allows the pieces to be updated or changed without the need to modify the application. The architecture of the prototype enables it to be extended to support any SQL database with triggers by simply defining the new database, adding the required database and JDBC driver configuration and providing the SQL statements for each part of the algorithm.

Implementation Challenges

This section discusses the challenges encountered when implementing the proposed algorithm. Some of the challenges are related to the general SQL syntax while others are related to database-specific implementation decisions.

Scope and Visibility

Most of the tested databases do not allow direct access to the data dictionary tables (these tables contain, among other things, lists of all the triggers, functions and procedures in a database). Instead, the databases provide access to the data in the tables via system views. The problem with the views is that they limit the results based on the permissions possessed by the user who accesses the view and on the scope of the database connection. Therefore, the user account employed to query the views must have access to all the database objects. However, even if the user account has the permissions to view all the objects, only the objects that fall within the scope of the connection would be listed. To work around this restriction, it is necessary to obtain a list of all the database scopes and iterate through them, changing the scope of the connection and repeating the query. The results obtained with each individual query are then combined.

Encryption

Some of the databases considered have the functionality to encrypt the contents of objects, including the triggers. This makes it impossible to search the content for the name of the object of interest. Due to flaws in current encryption implementations, it is possible to retrieve the decrypted content of an encrypted object [START_REF] Cherry | Securing SQL Server[END_REF][START_REF] Litchfield | The Oracle Hacker's Handbook: Hacking and Defending Oracle[END_REF]. However, such workarounds are neither efficient nor practical. In any case, the flaws may be corrected in a future version, rendering the workaround worthless for the updated implementations.

Case Sensitivity

Since SQL is mostly case insensitive, the name of the object of interest may be spelled in many different ways. Therefore, searching the content for an exact match based on a particular spelling would be a hit and miss affair. The standard way to deal with this problem is to use lower case letters for the content and the object name being searched before executing the query [START_REF] Gulutzan | SQL Performance Tuning[END_REF]. This is usually done using a built-in function. The approach is feasible for a database with few objects that are to be searched. However, it would be very inefficient and impractical for a database with thousands of objects, each with thousands of lines of content. A better solution is to change the collation of the database to enable case-insensitive comparisons.

False Positive Errors

Since basic string matching is performed, any string in a trigger, function or procedure would match the object name. This includes comments, variable names and the names of other object types. Therefore, it would be necessary to manually check all the triggers listed by the algorithm and remove all the false positives. Since the SQL parser can identify comments based on the syntax, it is possible to pre-process the triggers, functions and procedures to remove the comments before initiating the search. However, other sources of matching strings could still produce false positives.

Data Types

Some of the considered databases do not store the contents of triggers, functions and procedures in table columns with the same data type. Many databases have moved from using the simple VARCHAR data type to one that can hold more data. Microsoft SQL Server, for example, uses the CLOB data type to store content while Oracle uses the older LONG data type. The problem is that all the data types that are used cannot be handled in the same way in the code. A more generic approach is needed to prevent the writing of various code exceptions. The approach would entail querying the database table metadata first to detect the data types that are used and invoke the relevant code to handle the specific data types.

Recursion

Database functions and procedures are allowed to call themselves either directly or indirectly. The recursion produces an endless loop in Algorithms 1 and 2. In Algorithm 2, R would stop growing at some point because no new elements are added. However, U n would not become empty, which means that the termination criteria are never met. To address this problem, Algorithm 2 must keep track of all the elements seen in U ′ i previously. U ′ n should not contain any elements evaluated before and the following equality should hold:

U ′ n ∩ U ′ ∪ U ′ 1 ∪ ... ∪ U ′ n-1 = φ
To achieve this, the second last line in Algorithm 2 is modified to:

U ′ i = U i -U t i - i-1 j=1 U j
This ensures that each function and procedure is only evaluated once.

Performance

The string matching component of the step ω ∈ b x can be performed using the SQL LIKE command. The object name being searched can be located anywhere in the body of the trigger or function being searched. Thus, the SQL wildcard character "%" must be added around the object name as in "%object name%." This makes the execution of the SQL statement very slow because no index can be utilized. This does not pose much of a problem for a database with a small number of triggers, functions and procedures. However, the SQL statement can take a long time to complete if there are many such objects. This may occur in systems where auditing is performed with triggers or where the application utilizing the database performs a lot of transaction processing in functions and procedures. Depending on the time available to the forensic investigator, this could take a very long time to execute. It is also contrary to the goal of developing a quick test to establish trigger involvement.

Conclusions

A database trigger performs its actions under the credentials of the user who executed the database operation that initiated the trigger. Since the actions occur in the background without the user being aware of them, they can be abused by malicious actors. Malicious actions can be attached to legitimate operations and valid operations modified or even omitted. A forensic investigator who is tasked with analyzing these malicious actions could mistakenly attribute them to the wrong party.

Hence, it is important that a forensic investigator consider triggers very carefully when attributing actions. After suspicious data modifications have been identified, the forensic investigator must establish if a trigger interfered with the operations that lead to the data manipulation. Since a database under investigation might contain hundreds or even thousands of triggers, it is not feasible for the forensic investigator to analyze each trigger individually. An automated approach is needed to identify possibly significant triggers, which could then be analyzed in more detail.

The principal contribution of this chapter is an algorithm for identifying possible trigger involvement for a particular database object. The algorithm, which is simple and effective, is formulated in a generic manner so that it can be applied to any SQL database.

The prototype currently implements SQL statements for Microsoft SQL Server and Oracle. While the initial results are promising, more thorough tests are being conducted. Options such as moving the string comparison out of the database and into the prototype to enhance performance are being evaluated. The use of a local embedded database to temporarily store the content of all the triggers, functions and procedures is also being considered. Future research will focus on optimizing the algorithm. Currently, only one object can be checked for trigger involvement at a time. Repeating the same check for every object is inefficient. Therefore, efforts will be made to search for multiple objects simultaneously in order to improve efficiency.


Jayaprakash Govindaraj

Rashmi Mata

Robin Verma

Gaurav Gupta

FORENSIC-READY SECURE iOS APPS FOR JAILBROKEN iPHONES

Keywords: Jailbroken iPhones, enterprise environments, forensic examinations

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

According to a 2013 Pew report [START_REF] Smith | Smartphone Ownership 2013[END_REF], 40.98 % of the smartphones used by adult Americans are Apple iPhones. Apple's iOS operating system does not allow the installation of applications, extensions and themes that are not obtained from the Apple App Store. As a result, users frequently jailbreak their devices to obtain root access and defeat the installation restrictions [START_REF] Esser | Exploiting the iOS kernel[END_REF]. A jailbroken iPhone allows the retrieval of applications and their associated data, potentially compromising the security of the applications and the confidentiality of the data [START_REF] Esser | Exploiting the iOS kernel[END_REF][START_REF] Renard | Practical iOS apps hacking[END_REF].

Since jailbreaking is a reality [START_REF] Hoog | iPhone and iOS Forensics: Investigation, Analysis and Mobile Security for Apple iPhone, iPad and iOS Devices[END_REF][START_REF] Iphonehacks | Jailbreaking your iPhone remains legal in US, but it is illegal to jailbreak your iPad and unlock your iPhone under DMCA[END_REF], it is increasingly important to design mobile applications that can run securely on jailbroken iPhones. The requirement of having an application execute securely in an unsecure environment is critical to scenarios where a proprietary applica-tion should work without impacting enterprise security. At this time, enterprises that have a Bring Your Own Device (BYOD) policy generally detect and restrict jailbroken iPhones using mobile device management software such as Citrix's XenMobile and IBM's Endpoint Manager. Thus, employees have to un-jailbreak their iPhones or install enterprise applications on other approved devices. The solution proposed in this chapter enables enterprises to install their applications securely on jailbroken iPhones. New apps and existing apps can be secured and be made forensic-ready. The forensic readiness of the apps enables enterprises to check if the apps run securely and also ensures that forensic artifacts are available in the event of security incidents.

Related Work

D'Orazio et al. [START_REF] Orazio | iOS anti-forensics: How can we securely conceal, delete and insert data[END_REF] have proposed a concealment technique that enhances the security of unprotected (class D) data that is at rest in iOS devices, along with a deletion technique to reinforce data deletion in iOS devices. Hackers and malicious users resort to techniques such as jailbreaking, running an app in the debug mode, reverse engineering, dynamic hooking or tampering in order to access or compromise sensitive data stored by iOS apps:

Jailbreaking: Attackers use jailbreaking to obtain system-level (root) access to iOS devices, potentially compromising the security of applications and their associated data [START_REF] Morrissey | iOS Forensic Analysis for iPhone, iPad and iPod Touch[END_REF].

Debugger Mode: Attackers run targeted applications in the debug mode, obtain memory dumps and overwrite the memory with malicious code [START_REF]iPhoneDevWiki, debugserver[END_REF][START_REF] Miller | Owning the fanboys: Hacking Mac OS X, presented at Black Hat Japan[END_REF].

Reverse Engineering: Apps from the Apple Store are encrypted using Apple's Fairplay DRM, which complicates the task of reverse engineering binaries. However, an attacker can overwrite the encryption information of an application in a jailbroken device to obtain the memory dump and analyze it to create new attacks [START_REF] Ertel | Decrypting iOS apps[END_REF][START_REF] Renard | Practical iOS apps hacking[END_REF].

Dynamic Code Hooking: After a device is jailbroken, an attacker can hook malicious code to an app at runtime in order to bypass security checks, potentially compromising the security of the application and its data [START_REF] Trebitowski | Beginning Jailbroken iOS Development -Building and Deployment[END_REF].

Tampering: Attackers can modify the dates and timestamps of artifacts in order to cover their tracks. Verma et al. [START_REF] Verma | Preserving date and timestamps for incident handling in Android smartphones[END_REF] have recently proposed a mechanism for preserving dates and timestamps in support of forensic examinations of Android smartphones. This chapter presents a technique for protecting applications and data in jailbroken iOS devices. In the event of a security incident, the technique can be used to support a forensic examination of a jailbroken device.

Implementation Methodology

The solution has two modules: (i) a static library that wraps apps running on jailbroken devices with an extra layer of protection, making them difficult to crack and preventing access to their data; and (ii) a module that preserves authentic dates and timestamps of events related to the secured apps to support forensic examinations. The captured dates and timestamps are stored outside the device on a secure server or in the cloud. The modules are discussed in following subsections.

Securing Apps

The static library, which is designed to secure apps, incorporates APIs that may be used to identify and mitigate security vulnerabilities in jailbroken iPhones [START_REF] Github | Tools for securely clearing and validating iOS application memory[END_REF]. Functions in the library include: isCheck1(), which checks if an iPhone is jailbroken; isCheck2(), which checks if an application is running in the debug mode; enableDB(), which disables the gdb (debugger) for a particular application (process); isAppC(), which checks if an application binary is encrypted and also checks the integrity of application bundle files (Info.Plist); initialize(), which checks if static library functions are hooked; CheckA(), which checks if critical methods (functions) passed as arguments are hooked; CheckS(), which checks if methods (functions) related to SSL certificate validation are hooked; createCheck() and createCheckTest(), which check if an application has been tampered with; and resetZeroAll(), which wipes sensitive data from memory.

Preserving Dates and Timestamps

The dynamic library has been created using the MobileSubstrate framework. This framework provides APIs for adding runtime patches or hooks to system functions in jailbroken iOS devices [START_REF] Saurikit | Cydia Substrate, Isla Vista, California[END_REF]. The solution architecture shown in Figure 1 incorporates three components: Dynamic Library (dylib): This component hooks system open calls and captures kernel-level dates and timestamps of selected files and writes them to the log file. It is loaded into running applications. Filters are applied so that it is only loaded into specified applications. Timestamp Log File: This component is stored in the internal memory of an iPhone. It is not directly accessible to applications, which secures it from unauthorized deletion.

Log File: This component is generated by the DLL. It is uploaded at regular user-defined intervals to an external server or cloud storage based on network connectivity.

Static Library

The static library is designed to secure applications and their associated data. The library wraps apps in an additional layer of protection, which makes them more difficult to crack in a jailbroken iOS device. The static library contains several APIs (Table 1) that can be used to identify security vulnerabilities in jailbroken devices. The library implements the detection of jailbroken devices, the disabling of application debuggers, the checking of application encryption (for App Store binaries) and the detection of dynamic code hooking. Note that the function names are intentionally not very descriptive in order to enhance code obfuscation and hinder malicious reverse engineering efforts. Provides and statically stores a string of all the tracked memory addresses and object checksums createCheckTest() Checks if the current memory states of all the tracked objects match their states when checksumMem() was called

Dynamic Library

The dynamic library was created using the MobileSubstrate framework, now known as the Cydia Substrate [START_REF] Saurikit | Cydia Substrate, Isla Vista, California[END_REF]. The framework provides a platform and APIs for adding runtime patches or hooks to system functions as well as other applications on jailbroken iOS and rooted Android devices. The MobileSubstrate framework incorporates three components: (i) Mobilehooker; (ii) Mobileloader; and (iii) Safemode.

Mobilehooker: This component replaces the original function with the hooked function. Two APIs may be used for iOS devices: (i) MSHookMessage(), which is mainly used to replace Objective-C methods at runtime; and (ii) MSHookFunction(), which is used to replace system functions, mainly native code written in C, C++ or assembly.

Mobileloader: Cydia Substrate code is compiled to create the dynamic library, which is placed in the directory /Library/Mobile Substrate/DynamicLibraries/ in jailbroken iOS devices. The main task of Mobileloader is to load the dynamic library into running applications. The Mobileloader initially loads itself and then invokes dlopen on all the dynamic libraries in the directory and loads them at runtime. The dynamic libraries are configured using Property List (PList) files, which act as filters, controlling if a library should be loaded or not. The PList file should have the same name as that of dylib and should be stored in the same directory as dylib. The PList should contain a set of arrays in a dictionary with the key Filter. The other keys used are: (i) Bundles (array) -the Bundle ID of a running application is matched against the list, if a match occurs, then dylib is loaded; (ii) Classes (array) -the dylib is loaded if one of the specified Objective-C classes in the list is implemented in the running application; and (iii) Executables (array)dylib is loaded if an executable name in the list matches the executable name of the running application.

An example is:

Filter = Executables = ("mediaserverd"); Bundles = ("com.apple.MobileSlideShow"); Mode = "Any";;

In the example, the filter ensures that dylib is loaded only for the iOS built-in application Photos, whose executable name matches mediaserverd or Bundle ID is com.apple.MobileSlideShow. The Mode key is used when there are more than one filters. By specifying Mode = Any, dylib is loaded if one of the filters has a match.

Safemode:

In this mode, all third-party tweaks and extensions are disabled, preventing the iOS device from entering the crash mode. Following this, the broken dylib can be uninstalled from the device.

Compilation Procedure. The Theos [START_REF] Iphonedevwiki | [END_REF] development suite was used to edit, compile and install the dynamic library on a device. It provides a component named Logos, which is a built-in pre-processor-based library designed to simplify the development of MobileSubstrate extensions. In order to compile the dynamic library, Theos must be installed on a Mac machine. A Mac OS X has most of the tools required by Theos; however, Xcode command line tools must be installed if they are not present. Additionally, it is necessary to install the ldid tool, which is used to sign apps or tweaks so that they can be installed on jailbroken iOS devices.

To start the project, it is necessary to obtain all the iOS private headers of the functions intended to be hooked. The headers can be dumped DLL Loading. After the DLL is created, it can be installed on a device by the Theos suite using the command make package install. This command creates a Debian package of the DLL and installs it in the proper location on the device. Before this is done, the environment variable must be set to export THEOS DEVICE IP=iPhone Device IP. Next, the package is transferred to the device for installation via SFTP. The iOS device should be on the same network as the computer used for development [START_REF] Trebitowski | Beginning Jailbroken iOS Development -Building and Deployment[END_REF].

Preventing Attacks and Anti-Forensics

The section discusses how attacks and anti-forensic approaches can be mitigated using the static and dynamic libraries.

4.1

Using the Static Library BOOL isCheck1(): This function is used to check if an iOS device is jailbroken. It returns yes if the iOS device is jailbroken; otherwise no. This function can be called before application launch.

API for Checking Debug Mode:

The application exits when launched in the debug mode using the enableDB() function. This function can be called from main() and from elsewhere in the project to disable debugging at any stage. By calling enabledDB() in main() or before app launch, the application can be prevented from running in the debug mode. Therefore, the function should be called in the release mode.

makeZero(obj):

This function is used to zero the value of a sensitive variable after its use.

encPwd() and decPwd(): These APIs are used for encrypting sensitive data immediately after the data is created and decrypting the data only during its use. After the sensitive data has been used, it should be cleared from memory permanently.

listed() and unlisted(): These functions track several objects in order to clear them from memory simultaneously. Sensitive objects are added to the list to keep track of them; they are all cleared at one time using an API. For example, when a device is locked and/or an app is closed (hidden or terminated), it may be necessary to wipe all the sensitive data. In this case, it is necessary to add resetZeroAll() to the state-change notify functions in AppDelegate. Several tools are available for attackers to modify the values of critical data and change the behavior of an application at runtime. Such modifications can be tracked using the createCheck() and createCheckTest() APIs to create a checksum of the critical data and check it periodically to ensure that the data is not modified by an attacker.

Using the Dynamic Library

Whenever files are modified, accessed or created, the hijacked open() call is invoked and the modified, accessed, created dates and timestamps (MAC DTS) are captured and stored in the log file. The log file is stored outside the iPhone at a secure location such as a server or in the cloud. The information in the log file can be used in a forensic investigation of the smartphone in the event of a security incident.

Experimental Results

The experiments involved the creation of two apps, one without any protection and the other protected by iSecureRing. The apps were then deployed on a jailbroken iPhone 4 (iOS 7.0.6).

A series of attacks were simulated on the apps and their data to validate the proposed solution (Figure 2). At the application level, the apps were subjected to various attacks to exploit the lack of binary protection [START_REF] Orazio | iOS anti-forensics: How can we securely conceal, delete and insert data[END_REF]. The results in Table 2 demonstrate that an app with iSecureRing running on a jailbroken iPhone (Row 3) is just as secure as a normal app running on a non-jailbroken iPhone (Row 1).

Performance benchmarking was conducted for the three cases considered in the experiments. Figure 3 summarizes the results of the initial tests (five runs). The results show no significant differences in device performance. Debug Mode Attack. Figure 5 shows a screenshot of an Xcode application running in the debug mode [START_REF] Satish | Penetration Testing for iPhone Applications -Part 5[END_REF] while it was being protected by iSecureRing.

Encryption Attack. Clutch [START_REF] Satish | Penetration Testing for iPhone Applications -Part 5[END_REF] was used to simulate an encryption attack (Clutch may be downloaded from cydia.iphonecake.com). iSe-cureRing includes a check to determine if application encryption is intact by analyzing encryption information in the binary and also the cryptid flag value. If the application encryption is found to be broken, then the user is alerted and the application behavior can be changed at runtime.

Hooking. A hooking attack was simulated by hooking SSL validation methods. It is possible to launch a man-in-the-middle attack on even HTTPS requests to understand, steal and modify the requested data. iSecureRing incorporates several checks to identify the hooking of critical methods such as SSL validation and authentication. Applications that use iSecureRing are protected against the attacks because the user is alerted and the app behavior can be changed.

Code Tampering. A code tampering attack was simulated using Cycript [START_REF] Selma | Hacking iOS on the run: Using Cycript[END_REF], a JavaScript interpreter. The tool was used to modify iOS application behavior at runtime (e.g., bypassing some authentication checks and accessing critical information from memory). An application compiled with iSecureRing provides APIs for identifying code tampering of critical instance variables and class objects using CRC checksums. Also, APIs are provided for wiping sensitive data from memory.

Case Study

The iSecureRing implementation was successfully used to secure an iPhone mobile app for a leading bank in India.

Problem Statement. The bank had a security incident in which the application running on a jailbroken device revealed sensitive data.

Jailbreaking Attack. The attacker had used the latest jailbreaking tool for iOS 7.1.2 Pangu [START_REF] Benjamin | How to jailbreak iOS 7.1.x with Pangu 1.1 on Windows[END_REF]. The attacker also used certain tweaks to de-feat jailbreak detection. Some tweaks within Cydia bypass the jailbreak detection check of an application and make the application run normally even on jailbroken devices. One such tweak is xCon [START_REF]iPhone Wiki, xCon[END_REF], which hooks low-level APIs used for jailbreak detection such as file-related APIs and other system calls, thus bypassing the jailbreak detection functions used in the application. No configuration is required for xCon, a MobileSubstrate dynamic library that can be installed from Cydia.

iSecureRing Results. The bank app was secured using iSecureRing. The jailbreak detection function was robust enough to check if the device was jailbroken and if any jailbreak detection bypassing functions were present. The solution was tested with xCon 39 beta 7 on iPhone 4 devices with iOS version 7.1.2. xCon was unable to bypass the jailbreak detection techniques used by iSecureRing. The iSecureRing solution checks for the existence of file-related system function hooking, rendering xCon-like tweaks useless. The solution also mitigates the jailbreak detection bypassing mechanism provided by the xCon dynamic library.

Conclusions

The iSecureRing solution secures apps on jailbroken iOS devices. The static library helps detect security vulnerabilities and alerts users to take appropriate actions. The dynamic library helps detect malicious tampering of data by storing authentic copies of MAC DTS values on a local server or in the cloud; this also supports offline digital forensic investigations after security incidents. Thus, iSecureRing enables existing and new apps to be secured and made forensic-ready even if the iOS device has been jailbroken. With enterprises implementing BYOD policies and jailbroken devices making their way into enterprises, the iSecureRing solution helps enterprises mitigate the security risks while enabling employees to use one device for official and personal activities.

Future research will focus on analyzing anomalous interactions with secured apps, blocking attacks and raising alerts. Efforts will also be made to create similar solutions for Android and Windows smartphones.

Figure 1 .

 1 Figure 1. Solution architecture for preserving date and timestamps.

Figure 2 .

 2 Figure 2. Simulating attacks on devices.

Figure 5 .

 5 Figure 5. Preventing a debug mode attack.

Table 1 .

 1 Static library APIs.

	API	Description
	isCheck1()	Checks if a device has been jailbroken
	isAppC()	Checks if the application encryption provided by the App
		Store is intact
	enableDB()	Disables the application debugger
	isCheck2()	Checks if an app is running in the debug mode
	Initialize()	Checks if library APIs are hooked by method swizzling tech-
		niques
	checkA()	Checks if a function is hooked by a method swizzling tech-
		nique
	checkS()	Checks if the SSL validation methods provided by the iOS
		SDK are hooked
	makeZero()	Finds the data portion of object memory and zeroes it out
	encPwd()	Encrypts object data in memory using a secret
	decPwd()	Decrypts object data in memory using a secret
	listed()	Adds an object to the pointer list used by the APIs
	unlisted()	Removes an object from the pointer list
	resetAllZero()	Wipes all tracked objects
	createCheck()

  This function checks if the application has been hacked. The parameter inBundlePath can be any character pointer; it is only added for obfuscation and is not used inside the function. It includes an app encryption check (if the App Store encryption is broken), signer identity checks, etc. If the app is cracked, the function returns yes; otherwise no. The function is primarily used to check if App Store binaries are cracked. This function checks if the APIs in the static library are themselves hooked. The function has to be called initially, preferably during app launch, to check if the library APIs are hooked by method swizzling, after which the appropriate actions must be taken. If the functions are hooked, then it makes no sense to use the APIs to protect applications. This function checks if any hooking is done for a critical method within an application passed as an argument to the function. The function returns one if no hooking is discovered and zero if a function is hooked. It requires the method name, method class and the path of the framework (for a framework method) or app bundle path (for an application method).int checkS(): This function checks if SSL certificate validation methods provided by the iOS SDK are hooked. This function is invoked within an application before calling SSL validation methods so that the proper actions can be taken. The function returns one if there is no hooking and zero if a function is hooked.

	int Initialize(): int checkA(const char* MCl, const char* MFr, const char* MFn, void *funcPTR):

isCheck2(): This function gives information about how the application is running. If the application was started in the debug mode, then a value of one is returned; otherwise zero is returned.

BOOL isAppC(char* inBundlePath):

using the Class-Dump-Z command line tool [START_REF] Gianchandani | iOS Application Security Part 2 -Getting Class Information of iOS Apps[END_REF]. This reverse engineering tool provides complete header information of the Objective-C code of an iOS application. Dumping the headers can take some time because headers from all the frameworks, including private frameworks, are also collected. The dumped headers are saved in a folder with the corresponding framework name. Instead of dumping the headers, headers collected by other researchers can be used (e.g., headers from GitHub). All the headers are saved at /opt/theos/include. The next step is to create the Theos project. This involves executing the file /opt/theos/bin/nic.pl from the command line and choosing the project template, name, etc. The project type should be library because the goal is to hook a system function. After the project has been created, a new file named tweak.xm is found in the project directory; this file is used to store the hooking code.

The following pseudocode for hooking an open() system call is added in the tweak.xm file: iSecureRing also helps detect attempts to exploit known or unknown vulnerabilities by capturing the timestamps of activities associated with a secured app. One experiment involved timestamp tampering attempts on images from Apple's Photo app. iSecureRing successfully captured all the events in the log. An analysis of the log clearly revealed the tampering attempts. Figure 4 shows the MAC DTS logs for one of the images.


Philip Trenwith

Hein Venter

LOCATING AND TRACKING DIGITAL OBJECTS IN THE CLOUD

Keywords: Cloud computing, cloud forensics, data provenance, central logging

établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

This chapter explores how data provenance can be stored in a forensically-ready manner and how provenance data can be used in cloud forensic investigations to trace where an object is located in the cloud and where the object has been. In a traditional digital forensic investigation, it is customary to seize a device suspected to be involved in illegal activities in order to examine it. However, this approach does not scale to the cloud for several reasons, the most important being that the physical locations of "devices" are often unknown due to the virtual nature of cloud environments. Data in the cloud is also spread across a range of hosts and data centers, which renders the task of identifying the physical location of an object even more challenging. It is, therefore, necessary to investigate how digital forensic readiness and data provenance can provide a technique for acquiring potential evidence that is better suited to the architecture and operation of cloud computing environments.

The primary challenge in cloud forensic investigations is determining the locations of relevant data [START_REF] Reilly | Cloud computing: Forensic challenges for law enforcement[END_REF]. The ability to trace a digital object in the cloud is made possible by Locard's principle of exchange (as stated in [START_REF] Guan | Digital forensics: Research challenges and open problems[END_REF]): "Whenever two objects come into contact with each other, each object is left with a trace of the other object."

An example of such a trace is seen in the registry of a machine running the Windows 7 operating system. When a flash drive is connected to the Windows 7 machine, a record is written to the registry. This record contains the hardware ID of the flash drive and the time it was inserted [START_REF] Alghafli | Forensic analysis of the Windows 7 registry[END_REF]. The record remains in the registry even after the flash drive has been removed.

The principle of exchange provides a means, in theory, of tracing an object in the cloud. However, collecting potential evidence from the cloud is a challenge because the approach is reactive. The challenge can potentially be addressed by establishing a proactive approach based on digital forensic readiness, in which an organization prepares in advance for the possibility that an event might occur that requires an investigation to be conducted.

The primary research question discussed in the chapter is: How can a digital object be tracked in the cloud and its history be recorded in order to obtain accurate location information during a cloud forensic investigation?

Background

This section discusses cloud computing, digital forensics and data provenance.

Cloud Computing

Cloud computing is a scaled-up, virtual environment for distributed computing that has become immensely popular in recent years. The U.S. National Institute of Standards and Technology (NIST) defines cloud computing as "a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction" [START_REF] Mell | The NIST Definition of Cloud Computing[END_REF]. The cloud provides three common service models. Infrastructure as a service (IaaS) offers computing and storage services to cloud users. Platform as a service (PaaS) offers platform support for software development. Software as a service (SaaS) offers fully functional applications to cloud users. These service models can be deployed in one of four modes: (i) private cloud; (ii) public cloud; (iii) hybrid cloud; and (iv) community cloud [START_REF] Mell | The NIST Definition of Cloud Computing[END_REF]. The primary difference between cloud computing and traditional computing is that storage is distributed throughout the cloud and the stored data is not necessarily in the same location as the device being used to access the data. The picture seen by an end user is much the same as in traditional computing, but the picture for a digital forensic investigator is very different.

Virtualization makes it difficult to tell the physical location of a data object in the cloud. The locations of objects in the cloud are important because the objects have to be found and retrieved in order to present them (and their constituent data) as evidence. Therefore, it is very important to maintain the locations and histories of cloud objects.

Consider, for example, the European Union's Data Protection Directive [START_REF] Cate | The EU data protection directive, information privacy and the public interest[END_REF], which stipulates that no sensitive data may leave the European Union. Implementing this directive makes it necessary to always know the locations of cloud objects containing sensitive data. Cloud service providers also duplicate and distribute data between multiple data centers to enhance availability, but this makes it difficult to assure that the data is (or is not) stored in a specific jurisdiction and that all copies of the data are removed if a deletion request is made. Pearson and Benameur [START_REF] Pearson | Privacy, security and trust issues arising from cloud computing[END_REF] discuss many of the challenges associated with cloud services and securing the data that is generated and used by the services. Some of these challenges are considered later in this chapter in developing a solution for locating and tracking digital objects in the cloud.

Digital Forensics

Digital forensics is a formal process involving several steps that are executed on computing devices to answer questions related to investigations of computer crime and other incidents. Traditionally, if it is found that a device is needed for an investigation, the device is seized in order to examine it for evidence. This approach does not scale to cloud computing environments primarily because of their virtual nature. Indeed, seizing and examining a single device would almost certainly be insufficient to produce all the evidence related to an incident in a cloud computing environment. Reilly et al. [START_REF] Reilly | Cloud computing: Forensic challenges for law enforcement[END_REF] emphasize that obtaining access to physical devices in the cloud is one of the main stumbling blocks in cloud investigations. Gaining physical access to devices in the cloud may not always be possible but, if adequate logs are maintained and if the information is made available to investigators when required, then the stumbling block could be overcome.

Traditional digital forensic investigations follow a reactive approach. An investigation is only initiated after an incident has occurred and the incident has been identified as one that requires further investigation. The reactive approach must be adapted to a proactive approach in order to perform successful cloud investigations. The proactive approach is better known as digital forensic readiness, which is defined by Rowlingson [START_REF] Rowlingson | A ten step process for forensic readiness[END_REF] as "the ability of an organization to maximize its potential to use digital evidence whilst minimizing the costs of an investigation." Digital forensic readiness requires an organization to take proactive measures to continuously collect and store data for a period of time to ensure that it is adequately prepared to conduct future investigations.

The intersection of digital forensics and cloud computing has created the new discipline of cloud forensics, which is defined by Ruan et al. [START_REF] Ruan | Cloud forensics[END_REF] as "a cross discipline of cloud computing and digital forensics." Cloud forensics offers many challenges to investigators, including the inability to perform independent investigations because cloud service providers maintain full control of their computing environments and, thus, the sources of evidence. Barbara [START_REF] Barbara | Cloud computing: Another digital forensic challenge[END_REF] states that the biggest challenges in cloud forensics are to determine the who, what, when, where, how and why of cloud-based activity. These challenges can potentially be addressed by the provision of data provenance -as Birk and Wegener [START_REF] Birk | Technical issues of forensic investigations in cloud computing environments[END_REF] state, the history of a digital object, combined with a suitable authentication scheme, are crucial to cloud forensic investigations.

Data Provenance

Muniswamy-Reddy and Seltzer [START_REF] Muniswamy-Reddy | Provenance as first class cloud data[END_REF] define data provenance as the history of a digital object. Data provenance is valuable data in a digital forensic investigation because it reveals information such as when a digital object was modified and who accessed it. Some researchers [START_REF] Lu | Secure provenance: The essential of bread and butter of data forensics in cloud computing[END_REF][START_REF] Muniswamy-Reddy | Provenance as first class cloud data[END_REF][START_REF] Trenwith | A digital forensic model for providing better data provenance in the cloud[END_REF] have investigated the use of data provenance in the cloud as a tool for supporting digital forensic investigations.

Lu et al. [START_REF] Lu | Secure provenance: The essential of bread and butter of data forensics in cloud computing[END_REF] discuss one of the challenges of cloud forensics known as anonymous authentication. Cloud computing offers anonymous authentication, which enables a user to log into a service using group authentication. In other words, a group of users may be granted access to specific objects and services in the cloud with the same access rights. While each user has unique credentials to access the service, there is no way to identify a specific user. This is because the credentials of the users in the group are related through mathematical inverses. Therefore, the credentials are not stored by the system, only the inverse function is stored. The authentication scheme calculates the mathematical inverse of the provided credentials and compares it with the function value. Therefore, the credentials cannot be used to uniquely identify one individual from the other members of the group. This is advantageous to users but a challenge to forensic investigators. Lu et al. [START_REF] Lu | Secure provenance: The essential of bread and butter of data forensics in cloud computing[END_REF] argue that this is the reason why provenance is required in the cloud. They further state that the addition of provenance data that can be used to report on the history of a digital object would contribute to the wider acceptance of cloud computing by the general public. However, when implementing data provenance in a cloud computing environment, care must be taken not to infringe on the confidentiality and privacy of data owners.

Related Work

Muniswamy-Reddy et al. [START_REF] Muniswamy-Reddy | Layering in provenance systems[END_REF] have proposed a system that creates and maintains provenance-aware network storage. However, this system does not scale well to the cloud because it requires the network to be set up in a specific way to provide provenance data. The system is, thus, not compatible with all cloud environments.

Trenwith and Venter [START_REF] Trenwith | A digital forensic model for providing better data provenance in the cloud[END_REF] have proposed a system that obtains provenance data from cloud service provider logs in network infrastructures (e.g., TCP/IP networks) to identify the physical locations of objects in the cloud. The underlying approach is leveraged in this work to provide data provenance for cloud objects while also addressing the challenges related to cloud forensics. One of the challenges, involving the provision of cryptographic proofs to verifying cloud data integrity, has been listed as a requirement for cloud forensics in [START_REF] Juels | PORs: Proofs of retrievability for large files[END_REF][START_REF] Shi | A new data integrity verification mechanism for SaaS[END_REF].

Trenwith and Venter [START_REF] Trenwith | Digital forensic readiness in the cloud[END_REF] have developed a technique for proving the integrity of log files stored at a central log server. This is accomplished by computing a hash value when the logs are captured, encrypting the hash value with a secret key and storing the encrypted hash value along with the log. The integrity of the log file may be verified at any time by recomputing the hash value and then encrypting the hash value with a validation application that holds the secret key. The application then compares the newly encrypted value with the original encrypted value that was saved with the log file.

Storing Provenance Data

The provenance of a digital object can be stored in one of two ways. One is to embed provenance data in the digital object. The other is to store the provenance data separately in a second digital object [START_REF] Simmhan | A Survey of Data Provenance Techniques[END_REF].

Embedded Provenance Storage: This technique modifies a digital object to incorporate provenance data within the object. The provenance data is typically stored in the file header. The main advantage of this technique is that it helps maintain the integrity of the provenance data because the data is stored with the object and can easily be verified. A disadvantage is that it is difficult to search the provenance data [START_REF] Simmhan | A Survey of Data Provenance Techniques[END_REF]. This technique is used by NASA's Flexible Image Transport System [START_REF] Hanisch | Definition of the flexible image transport system[END_REF] and by the Spatial Data Transfer Standard [START_REF] Altheide | Spatial Data Transfer Standard[END_REF] used by GIS systems to reference spatial data.

Separate Provenance Storage:

This technique stores provenance data separately from the object. The need to maintain a separate data object can be viewed as a disadvantage. However, Tan [START_REF] Tan | Forensic readiness: Strategic thinking on incident response[END_REF] suggests that centralized logging is vital to an efficient digital forensic strategy. Thus, with proper maintenance, the disadvantage of separate provenance storage can be turned into an advantage. Trenwith and Venter [START_REF] Trenwith | A digital forensic model for providing better data provenance in the cloud[END_REF] have suggested the use of this technique with a central log server to store provenance data. The implementation is discussed later in this chapter.

Data Provenance Requirements

Lu et al. [START_REF] Lu | Secure provenance: The essential of bread and butter of data forensics in cloud computing[END_REF] identify three requirements for a provenance record:

R1: A provenance record must be unforgeable.

R2:

A provenance record must be kept confidential.

R3:

The integrity of a provenance record must be maintained by the system.

Trenwith and Venter [START_REF] Trenwith | A digital forensic model for providing better data provenance in the cloud[END_REF] suggest an additional requirement that addresses the cloud forensics challenges faced by investigators. In particular, a provenance data should produce sufficient information to answer most of the questions asked by investigators during cloud forensic investigations. The new requirement is: R4: A provenance record must answer the who, what, when, where and how of an event. These terms are defined as [START_REF] Trenwith | A digital forensic model for providing better data provenance in the cloud[END_REF]:

R4.1: Who: The identity of the process or user account associated with the modification.

R4.2:

What: The object that was modified.

R4.3:

When: The time of the modification.

R4.4:

Where: The location of the object at the time of the modification.

R4.5: How: The hash values of the object before and after the modification.

Cloud-Based Provenance Model

The primary research question discussed in the chapter is: How can a digital object be tracked in the cloud and its history be recorded in order to obtain accurate location information during a cloud forensic investigation? Trenwith and Venter [START_REF] Trenwith | A digital forensic model for providing better data provenance in the cloud[END_REF] have proposed the use of a central log server for storing the provenance data of digital objects. Although central logging provides advantages with regard to digital forensics, this approach is not without challenges. The principal challenge is the bandwidth required to ensure that the central server can continuously receive the provenance data of every object maintained by a cloud service provider. Therefore, this work investigates if a technique can be developed that provides the advantages of central storage while reducing the bandwidth requirements. This is accomplished by revisiting the embedding techniques used to store provenance data.

Trenwith and Venter [START_REF] Trenwith | A digital forensic model for providing better data provenance in the cloud[END_REF] have made good arguments for storing provenance data separately from digital objects. Their goal was to use provenance data to identify and track object locations in the cloud. An examination of the requirements set for provenance data reveals that some of the requirements are easily met if provenance data is embedded within digital objects.

R1: A provenance record must be unforgeable: Lu et al. [START_REF] Lu | Secure provenance: The essential of bread and butter of data forensics in cloud computing[END_REF] stipulate that it should not be possible to forge a provenance record. Because provenance records are produced by the system, it may be possible for a malicious attacker to forge a record that looks like a valid record. Therefore, instead of addressing the procedure that creates provenance records, it is necessary to see how provenance data is validated to prove its integrity. The approach is similar to that proposed in [START_REF] Trenwith | Digital forensic readiness in the cloud[END_REF] and discussed above with regard to validating log files. If provenance data is embedded in a data object, the most recent provenance record can easily be validated against the data object. Taking this one step further, the system should store a second hash value to validate historical provenance data. Having the system encrypt the provenance data ensures that the non-forgeability requirement is met.

R2: A provenance record must be kept confidential: This requirement can also be met using encryption. Encrypting provenance records and user data prevents cloud service provider employees as well as other parties from accessing the data, thus maintaining confidentiality. This concept is leveraged by Venters et al. [START_REF] Venters | Provenance: Current directions and future challenges for service oriented computing[END_REF] in their implementation of a secure provenance service.

R3:

The integrity of a provenance record must be maintained by the system: The integrity of a provenance record is more easily maintained if the record is embedded within the object. The integrity can easily be verified by checking the record against the data object. The integrity of historical provenance data can also be maintained by including historical data when computing the hash value of an object.

R4.1: Who (Identity of the process or user account associated with the modification): This requirement can be met by recording the user account that was used to edit the object. If this is not possible, the identity of the process that modified the object should be recorded.

R4.2: What (Object that was modified): When data provenance is embedded with the object, the issue of what was modified is irrelevant because provenance data is stored in the object that was modified.

R4.3: When (Time of the modification):

The time of the modification should be saved with the provenance data. To avoid confusion regarding timestamps, a cloud service provider should synchronize the time on all its servers [START_REF] Trenwith | Digital forensic readiness in the cloud[END_REF].

R4.4: Where (Location of the object at the time of the modification): A process running on a machine can easily record the machine name and the IP address assigned to the machine. However, this information is not enough to identify the location of a machine in the cloud. If the IP address is recorded along with the modification time, a cloud service provider can identify the location of an object by examining a log that stores the identity of the machine that was associated with the IP address at the time of interest. This approach assumes the worst case scenario where IP addresses are assigned dynamically. This is often not the case in the cloud, but adopting this approach ensures that dynamic IP address allocation is not a concern at a later stage. This work leverages digital forensic readiness principles to help locate objects in the cloud. However, the difficulty is to identify the location of an object of interest when the data that identifies the object is stored within the object. One way to solve this problem is to maintain a central logging service for all objects being monitored.

Embedding provenance data within an object has the advantage that it is not necessary to transmit all the provenance data to a central server. This addresses the bandwidth issue identified in [START_REF] Trenwith | A digital forensic model for providing better data provenance in the cloud[END_REF]. The approach only requires an identification tag to be transmitted to the central server along with the current location of the object. Hence, if additional provenance data has to be retrieved from the object, the current location of the object can be looked up at the central server after which the object can be retrieved from the cloud for further investigation. This is only possible if the user has not deleted the object from the cloud. If the object has been deleted, its provenance data is no longer available.

The problem posed by a deleted object can be addressed by a data deletion policy implemented by a cloud provider. For example, the provider could mark an object as deleted, but retain the object for a certain period of time, in case the object or its provenance data may constitute evidence in a future investigation. R4.5: How (Hash values of the object before and after the modification): Hash values are used to verify object integrity and to indicate when the object was modified. This work uses the SHA-256 hash algorithm. According to NIST [START_REF] Burr | NIST Hash Function Standards: Status and Plans[END_REF], any hash algorithm stronger than 112-bits should be adequate until the year 2030.

Using a Central Logging Server

As discussed in the previous section, embedding provenance data in objects overcomes some of the disadvantages of current systems and helps meet most of the data provenance requirements. However, one problem that remains to be addressed is that only a few file types allow user-defined metadata to be appended to the file header. Therefore, the successful implementation of an embedded provenance system requires the creation of a file type that can be used to wrap a digital object and its provenance data in a single object. The next section discusses the design of a file wrapper that can embed provenance data with any digital object.

File Wrapper

This section describes the design of the wrapper used to embed a file and its provenance data in a single digital object. Figure 1 presents a schematic diagram of the file wrapper. The file wrapper has three components:

Object Identifier: This component consists of the wrapper ID and a hash value. The wrapper ID is a unique key that is assigned to the object when it is constructed. The key, which is stored at the central server, is used to uniquely identify the object. This is necessary because there may be thousands of file objects wrapped with provenance data and it is necessary to know which wrapper contains a specific object. The hash value stored in the object identifier is computed by taking the hash value of the file object concatenated with its historical provenance data.

Historical Provenance Data: This component is the provenance data of the object, which is covered by the requirements R4.1 through R4.5. The historical provenance data identifies when the object was constructed and includes information about subsequent modifications along with the time of each modification and the process or user account responsible for the modification. It also contains the hash value of the file object. Note that the historical provenance data includes not only the most recent modification, but also the provenance data associated with each modification and the file object hash value after each modification.

File Object: This component is the user file; by design, it can be any type of file. A cloud service provider can decide what data is to be wrapped and how it is used. A cloud service provider may maintain provenance data for all the objects associated with its client accounts or it may maintain provenance data for a subset of objects associated with critical user data.

Tracking Wrapper Locations

Figure 2 shows a wrapper implementation by a cloud service provider such as Google Drive that could be used to track files uploaded by users. The cloud service provider implements the model by wrapping a file uploaded by a user before it is stored in the cloud. Before the wrapped file is stored in the cloud, the system registers the file and calculates a unique ID to identify and keep track of the wrapper. The hash value of the object is also computed and stored at the central server along with its location. The distribution server in Figure 2 distributes the object among its storage servers.

When a user logs in to access and modify the file, the object is unwrapped. When the user saves the file, the new provenance data is created and stored, and the file is wrapped. The wrapped object is required to connect to the central server to update its record: When the object is modified and the new hash value has been calculated, the central server records must be updated to reflect the latest hash value of the wrapped object.

When the object is moved from one location to another, the location of the wrapped object that is stored at the central server must be updated.

If the cloud service provider maintains multiple copies of its data for backup purposes or to provide better data availability, all the locations of a wrapped object should be stored at the central server. The cloud service provider should ensure that changes made to an object are made concurrently to all copies of the object.

Discussion

Reilly et al. [START_REF] Reilly | Cloud computing: Forensic challenges for law enforcement[END_REF] note that the lack of knowledge of the physical locations of objects in the cloud is one of the main stumbling blocks in cloud forensics. The primary goal of this research has been to identify the physical locations of data in the cloud and, thereby, enhance cloud forensic investigations. The design helps preserve the integrity of provenance data and meets many of the requirements set for data provenance. In particular, the embedded data provenance system and the use of a central server enables digital forensic investigators to track the histories of digital objects and to easily identify their locations in the cloud if and when this becomes necessary.

Takabi et al. [START_REF] Takabi | Security and privacy challenges in cloud computing environments[END_REF] emphasize that the owner of a data object should have full control over who accesses the data and what is done with the data. Encryption is the obvious solution to maintain data confidentiality, but this may introduce a performance penalty. However, the encryption technique is not intended to be employed by end users to encrypt their data. For this reason, it is suggested that user data be encrypted when it is uploaded to the cloud.

The technique also benefits the cloud service provider that controls the data. Since the data remains encrypted and is only decrypted when it is actually in use by the end user, there is no way for a malicious cloud provider employee to view, let alone compromise, the data. Thus, the user maintains full control over who can view or modify the data because only individuals who are granted access to the data by the user may view or modify the data.

A potential problem is that provenance data can grow to become larger than the digital object it describes [START_REF] Simmhan | A Survey of Data Provenance Techniques[END_REF]. Data compression can be used to reduce the storage requirements. However, since there is no maximum limit on the size of the provenance data or the wrapper, the cloud service provider may wish to consider time and storage limits on the provenance data maintained with digital objects.

Conclusions

The proposed approach for locating and tracking digital objects in the cloud uses wrappers to encapsulate digital objects and their provenance data. The design helps preserve the integrity of provenance data and meets many of the requirements set for data provenance, including the support of cloud forensic investigations Also, it combines the advantages of embedded provenance storage with the strategic advantage of central logging.

Future research will address issues related to keeping user data inside specific jurisdictions and preventing data from crossing jurisdictional boundaries. Also, efforts will focus on developing a prototype and evaluating its performance.

8.

Figure 1 .

 1 Figure 1. Wrapper design.

Figure 2 .

 2 Figure 2. Wrapper implementation.

Acknowledgement

This work was partially supported by the National Research Foundation of South Africa under Grant Nos. 88211, 89143 and TP13081227420.