Shuzhe Yang
email: shuzhe.yang@m-chair.net

Gökhan Bal
email: goekhan.bal@m-chair.net

Balancing Security and Usability of Local Security Mechanisms for Mobile Devices

Keywords: Privacy, Biometrics, Usable Security, Mobile Platform Security, Trustworthy User Devices

The loss of control over a new-generation mobile device (e.g. loss of device or short time of inattention) can have negative impacts on the owner's privacy due to the increasing number of privacy-sensitive data stored on such devices. Current mobile platforms either lack the required protection mechanisms or the implementations lack a balance between the level of security and usability. In order to fill this gap, we propose a design for a local security mechanism for mobile devices by using an reasonable combination of existing technologies.

Introduction

Recent developments in the domain of mobile technology caused a significant change in the prominence of mobile devices in peoples' daily lives. Users not only trust their devices to provide them with classical communication capabilities such as phone calls or short messaging. Instead, they trust new-generation devices to store and managed a significant amount of privacy-sensitive data such as photos, location information, browser credentials, or the media library. Furthermore, one property of these platforms is their openness for third-party applications. In order to enable innovative personalized services, these applications are provided with access to those data. The success of application stores for mobile platforms substantiate the perceived usefulness of these applications by users. Thus, mobile devices have turned into personal assistants in daily life and are capable of revealing a lot about the habits and activities of their users.

The downside of this development is the increased risk for misuse. A loss of a mobile device would not only cause financial losses (e.g. through unauthorized phone calls), it could furthermore lead to a critical invasion into users' privacy since an attacker would have access to a significant amount of privacy-sensitive information. Thus, two relevant attack scenarios to protect users from are [START_REF] Morrissey | IOS forensic analysis[END_REF] the loss of the device (e.g. through theft) and (2) short period of inattention that could be exploited by an attacker. As countermeasures for these attack scenarios, device and platform manufacturers introduced a series of mechanisms such as PIN-protected access to the device user interface. But with the increasing functionality of mobile devices grows the complexity of their usage. This necessitates the consideration of user's capabilities to use such a device. Current mobile platforms either lack the required protection mechanisms or the implementations lack a balance between the level of security and usability. Moreover, there are still deficits in existing approaches concerning the integration of technologies to achieve a balance between usability and security. In this paper, we bridge this gap by presenting a conceptual design of a local security mechanism. As a first step, we establish a set of evaluation criteria based on the global goals of security and usability. These criteria lead to a set of design decisions that will serve as the basis for the design.

The structure of the paper is as follows. Chapter 2 will provide an overview on related work in practice and research. Chapter 3 first defines the two relevant attack scenarios in more detail and classifies them according to existing classification schemes for mobile security attacks. Furthermore, frameworks for security and usability evaluation will be established. Chapter 4 first presents the set of design decisions and then introduces our proposed design for a local security mechanism. Chapter 5 summarizes this work and concludes with limitations of this research and gives hints for potential future work directions.

Related Work

Research in the field of mobile security experienced a significant growth in the last years. This is due to new manifold challenges that new-generation mobile technology poses to research and development. In order to expedite advancements in this field, several efforts to substantiate this research domain have been performed. In a survey paper, [START_REF] Becher | Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices[END_REF] provide a classification framework for the different aspects of mobile security vulnerabilities [START_REF] Becher | Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices[END_REF]. This framework comprises of the categories of hardware-centric attacks, device-independent attacks, software-centric attacks, and user layer attacks. One prominent attack scenario related to hardware-centric attacks they present is Forensics Analysis. In this attack scenario the attacker's target is to break the confidentiality of the stored data. As countermeasures the authors propose encryption of the nonvolatile memory of the device and to use a secure store for secure keys (e.g. using a Trusted Platform Module (TPM)). Another taxonomy for security threats to mobile computing is presented by [START_REF] Friedman | Protecting Data on Mobile Devices: A Taxonomy of security threats to mobile computing and review of applicable defences[END_REF] [START_REF] Friedman | Protecting Data on Mobile Devices: A Taxonomy of security threats to mobile computing and review of applicable defences[END_REF]. Security threats are grouped into the categories 1. Malware, 2. Phishing and Social Engineering, 3. Direct Attack by hackers, 4. Data communications interception and spoofing, 5. Loss and theft of devices, 6. malicious insider actions, and 7. user policy violations. As countermeasure, the authors propose data encryption, backup and recovery mechanisms, and device control.

Several countermeasures have been developed in research and practice to cover different aspects of mobile security and especially for the considered attack scenarios. In [START_REF] Nicholson | Mobile Device Security Using Transient Authentication[END_REF], the authors propose a solution for the device loss scenario by introducing the concept of Transient Authentication.

Transient authentication lifts the burden of authentication from the user by using a wearable token that constantly attests to the user's presence [START_REF] Nicholson | Mobile Device Security Using Transient Authentication[END_REF]. When the user departs, the token and device lose contact and the device secures itself. The main drawback of this multi-factor authentication approach is the dependence on a second device. If the user loses or forgets that token, access to his data cannot be granted or can only be granted with additional efforts. Another feature that is included in some of the new-generation mobile platforms is Remote Wipe which allows users to delete data remotely. This solution depends on the ability to locate the device via the Global Positioning System (GPS) or the mobile cellular network. Thus, an attacker could simply disconnect positioning features. Further approaches use implicit authentication mechanisms to enhance the usability of security. In this approach, different behavioural patterns of humans are exploited to identify the user [START_REF] Shi | Implicit authentication through learning user behavior[END_REF]. Other approaches use biometric data or the combination of different biometric data to authorize the user [START_REF] Tao | Biometric Authentication for a Mobile Personal Device[END_REF].

Requirements and Evaluation Framework

This section first describes the attack scenarios that are in focus of this research. Furthermore, it derives relevant requirements to protection mechanisms that will serve as the basis for the development of our proposed design. Based on these requirements, we set-up an evaluation framework, considering both usability and security aspects.

Attack Scenarios and Impact

The two relevant attack scenarios that we tackle are: loss of mobile device and short time of inattention. The common ground of these two attack scenarios is the mobile device owner's loss of physical control over the device. Thus, these attack scenarios can be categorized under the class of hardware-centric attacks according to the classification scheme of [START_REF] Becher | Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices[END_REF] [START_REF] Becher | Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices[END_REF]. Regarding the taxonomy of Friedman and Hoffmann (2008), the threat category covering our attack scenarios is loss and theft of device [START_REF] Friedman | Protecting Data on Mobile Devices: A Taxonomy of security threats to mobile computing and review of applicable defences[END_REF]. The relevance of these two scenarios is strongly related to the unique property of mobility. In consequence of the small size of mobile devices, the risk of device theft or loss is high. Without proper protection mechanisms, an attacker can easily communicate in the name of the device owner or manipulate data on the mobile device. The main distinction point between the two scenarios is the available time for an attack. If the mobile device is stolen, the attacker has an unlimited amount of time to break the security mechanism. In the case of inattention, the attacker has a limited time frame to break the system. The main goal of a security system that protects the user in these two scenarios is to keep the confidentiality of the user. Thus, unauthorized access to the data and manipulation of data must be prevented. Another important protection goal is related to accountability. The attacker must not be able to transmit data or to use the communication capabilities of the device.

Evaluation Criteria

Based on our primary goal to achieve a balance between security and usability, we developed a set of evaluation criteria. This evaluation framework comprises of the two parts security and usability. Each of those parts is further divided into several aspects. This evaluation framework can be used to evaluate existing and future security mechanisms to protect against the two attack scenarios. In the following, the evaluation criteria are presented in detail. Table 1

Usability Evaluation

-Simplicity of Setup. If the setup is too complex or the purchase price is too high, it might deter users from using it or leads to misconfiguration.

-Efforts for Maintenance. The aspect maintenance contains for example additional infrastructure, which needs administration effort. -Frequency & Effort of Credential Request. Evaluates how often the user has to enter credentials and how many resources -physical or mental load, time, monetary or material costs [START_REF]Ergonomic requirements for office work with visual display terminals (VDTs) -Part 11: Guidance on usability 35[END_REF] -are required to perform this task (e.g. entering a complex but secure password vs. entering a PIN). -Frequency of Decision Request. Some security applications let the user decide which data should be stored securely. This decreases the usability. -User comfort after an attack. Evaluates the complexity and number of steps to activate the security mechanism after an attack. -One-time costs. E.g. price for purchasing software.

-Running costs. E.g. monthly fee for software usage.

-Transaction-based costs. E.g. fees for activating the security mechanism.

According to the International Organization for Standardization (ISO) Norm 9241-11 [START_REF]Ergonomic requirements for office work with visual display terminals (VDTs) -Part 11: Guidance on usability 35[END_REF] a security mechanism is usable, if it fulfils the aspects of efficiency, effectiveness and satisfaction. Table 2 maps each evaluation criteria to these aspects of usability.

Design of a Security Mechanism

This chapter presents the proposed design for a security and usability-balanced protection mechanism for mobile devices. Based on the evaluation criteria presented in Section 3 we first make a set of design decisions that will affect the shaping of our design.

Design Decisions

Design Decision 1: One level of protection for both types of privacysensitive data.

Two protection levels decreases the usability because either the user would have to categorize each data item or a policy-based mechanism would have to be introduced to automate the categorization of the data items on the device. A level of protection that is appropriate for direct identifiable data will also be suitable for indirect identifiable data.

Design Decision 2: Fingerprint recognition as authentication method

Due to the common limitations of mobile devices (small size, etc.), biometric authentication will provide the highest usability on mobile devices. Fingerprint, iris and face recognition are appropriate mobile authentication methods (cf. [START_REF] Park | A study on iris localization and recognition on mobile phones[END_REF][START_REF] Tao | Biometric Authentication for a Mobile Personal Device[END_REF][START_REF] Furnell | Beyond the PIN -Enhancing user authentication for mobile devices[END_REF][START_REF] Abileah | Optical sensors embedded within AMLCD panel: design and applications[END_REF][START_REF] Marcialis | Fingerprint verification by fusion of optical and capacitive sensors[END_REF]). Fingerprint recognition has the best efficiency/price ratio and is therefore the best candidate for mobile devices. Token-based authentication as proposed in [START_REF] Furnell | Beyond the PIN -Enhancing user authentication for mobile devices[END_REF] is possible but unsuitable since the user must carry the token and that involves the risk of losing it.

Design Decision 3: Hardware-based full disk encryption

Encryption technologies are used to prevent the possibility of installing thirdparty applications and extracting data with direct storage access attacks. A solution should implement a hardware-based full disk encryption because of several reasons. A hardware-based encryption enables higher performance than software solutions, which increases the usability and user's workflow is not affect and stronger encryption algorithm can be used to enhance security.

Design Decision 4: Separate hardware storage for credentials A separate and secure credential storage is needed because credentials stored in the local memory can be attacked by malware using bugs in the operating system or in applications. Using a hardware credential storage enhances the protection of credentials and increases the trustworthiness.

Design Decision 5: Secure boot process

Another attack possibility is compromising the Master Boot Record by installing malware [START_REF] Schmidt | Krypto für Jedermann. Richtig verschlüsseln mit Linux. Verschlüsselung unter Linux[END_REF]. Thus, the proposed design should implement countermeasures to prevent this attack.

Entities and Used Technologies

Considering the design guidelines and the design decisions presented in the previous sections, this section presents the entities of our proposed design. Furthermore, in order to support implementations, we present existing technologies and mechanisms that can be adopted to implement the respective entities.

MTM. The Mobile Trusted Module (MTM) is a aligned version of the TPM for mobile devices [START_REF]TCG Mobile Trusted Module Specification[END_REF]. In our design the MTM serves as secure credential storage and is used for platform integrity verification (e.g. for a secure boot process).

The MTM could also be used as encryption module, but for performance reasons we do not make use of this capability [START_REF] Cesena | Anonymous authentication with TLS and DAA[END_REF][START_REF] Kursawe | Analyzing trusted platform communication[END_REF].

Encryption Module. For encryption purposes, an encryption module such as implemented in Apple's iPhone 3GS, is required [START_REF] Morrissey | IOS forensic analysis[END_REF]. Today's mobile devices' processors usually do not have encryption accelerating instruction sets. As mentioned earlier, using an MTM would not meet our performance requirements.

Fuzzy Cryptography. Fingerprint-based authentication requires the creation and storage of a fingerprint template on the device, more specifically on the MTM. We recommend to use fuzzy cryptography which introduces a biometric cryptographic system, which verifies the fingerprint with error-redundant functions and corrects potential disturbances [START_REF] Merkle | Biometrie-Daten-Schutz. Funktionsprinzip und Chancen biometrischer Kryptosysteme[END_REF]. Fuzzy cryptography makes bruteforce attacks [START_REF] Buhan | A Survey of the Security and Privacy Measures for Anonymous Biometric Authentication Systems[END_REF][START_REF] Merkle | Biometrie-Daten-Schutz. Funktionsprinzip und Chancen biometrischer Kryptosysteme[END_REF][START_REF] Cavoukian | Biometric Encryption. Positive-Sum Technology that Achieves Strong Authentication, Security and Privacy[END_REF] and duplication of credentials difficult. [START_REF] Trivedi | Efficient Cryptographic Key Generation using Biometrics[END_REF] present a method to generate and derive the encryption key from biometric data (e.g. fingerprint) [START_REF] Trivedi | Efficient Cryptographic Key Generation using Biometrics[END_REF].

Capacitive Touch Screen and Optical Sensors for Fingerprint Recognition. Capacitive touch screens, which are mostly built in mobile devices, can be used for scanning fingerprints in combination with optical sensors [START_REF] Marcialis | Fingerprint verification by fusion of optical and capacitive sensors[END_REF]. It uses fourier enhancement algorithms and rank-order transformation to increase the quality of the scanned fingerprint.

RIM Certificates . As countermeasure for attacks that compromize the Master Boot Record, [START_REF] Dietrich | Secure Boot Revisited[END_REF] present a solution that uses Reference-Integrity-Metric (RIM) certificates to measure the integrity of the boot software [START_REF] Dietrich | Secure Boot Revisited[END_REF]. RIM certificates store reference integrity values of boot-relevant services in an uncompromised state (e.g. delivery state). During the boot process, software integrity is measured and compared to the RIM certificates. The boot process will be stopped, if the integrity is compromised. By using RIM certificates and integrity verification of all unencrypted components within a mobile device, the trustworthiness can be ensured.

Process description

In this section we describe how the used technologies and entities can be combined in order to provide the user with an effective local security mechanism. Figure 1 depicts a component diagram with the used components. The essential processes are described in the following.

Setup. The setup process is depicted in Figure 2. The process begins with the user putting his finger on the touch screen for the initial fingerprint scan. Two credentials will be derived from the scanned data. First, a hash value will be created using fuzzy cryptography, second an encryption key will be generated that will be encrypted with the Storage Root Key (SRK) and stored in the key storage of the MTM. The hash value will then be stored in the Platform Configuration Register (PCR) of the MTM. Encryption. After the hash value and encryption key have been created, the encryption process starts (Figure 3). The first step is decrypting the encryption key with SRK. After that, two encryption processes are needed. First, data that is already on the device (e.g. mobile operating system) will be encrypted in-place in the background. Second, the empty space on the storage must be encrypted in order to prepare it for future usage and to prevent unauthorized installation of third-party applications. In both processes the file system is also encrypted, which means that the encryption layer is between file system and the physical storage. In consequence, if the storage is connected to another device, the file system will not be visible to the platform. Boot and Authentication. As stated before, the mobile device contains the required hardware hash values and RIM certificates for the secure boot process.

When the user starts the mobile device, the biometric encryption system immediately verifies the integrity of the hardware and boot-relevant services with the hash values and RIM certificates stored in MTM. Only in case of a mismatch between the measured values and the stored values, the operating system stops the boot process. Otherwise, the boot process will continue. After the boot process, the user interface to the mobile operating system is locked. To unlock the device, the user needs to put his finger on the touch screen for fingerprint-based identity verification. The touch screen scans the fingerprint and transfers the data to the biometric encryption system which then generates a hash value of the scan. In the next step, this hash value is compared with the stored hash value template in the PCR of the MTM. If the hash value does not match, the access is denied. If they match, the mobile device will be unlocked and the user has access to the interface and data. This process is depicted in Figure 4.

Evaluation

This section provides a security and usability evaluation of the proposed system based on the evaluation framework presented Chapter 3.

Security

-User Interface Access Control. Based on the low EER, the acceptance of an unauthorized person's fingerprint is unlikely [START_REF] Marcialis | Fingerprint verification by fusion of optical and capacitive sensors[END_REF]. A fake of the fingerprint is difficult because capacitive touch screens recognize the electronic charge of the finger which avoids attacks based on fingerprint imitations. -Access over API. These attacks are prevented by the RIM certificate-based integrity checks. Hardware modification and/or installing malware in bootrelevant software is difficult with this system. -Direct Storage Access. This class of attacks is prevented by the full disk encryption. -Self-Security. A deactivation of the security mechanism is difficult due to the components being implemented as hardware. -Recovery. Our proposed system does not support recovery. Thus, other solutions must be used in parallel for supporting recovery.

These evaluation results hold for the device loss scenario as well as for the inattention scenario.

Usability

-Simplicity of Setup. Compared to current implementations, our setup process requires a little bit more effort. But since this task has to be performed only once, it still is in an acceptable level. -Maintenance. The design does not require any significant maintenance efforts after setup. -Freqency & Effort of Credential Request. Compared to current unlock mechanisms based on passwords or gestures, our approach is more comfortable in daily usage. On the one hand, the user does not need to remember passwords and on the other hand today's fingerprint-based identity verification technologies are fast and reliable. -Frequency of Decision Request. After setup, the user does not need to make any decisions. The services run in the background. -User Comfort after an Attack. The comfort is on a high level because all data stored on the mobile device is safe and do not need the user to interfere. -Costs. We propose to implement the security mechanism into the mobile operating system and the mobile device, which means it is cost neutral for the user.

Conclusion

The growing privacy-sensitivity of smartphones pose high requirements to protection mechanisms. To this day, several concepts and technologies have been developed to enhance users' trust into these devices. Nevertheless, they failed to provide appropriate concepts that on the one hand provides protection and on the other hand considers users' habits for using new-generation devices. In this paper, by exploiting the capabilities of existing security technologies, we presented a new design for a holistic security mechanism to protect the user from two prominent security attacks on mobile devices: device loss and inattention. The goal was to provide a design that explicitly can be implemented with today's existing technology and to consider users' usability experiences with newgeneration smartphone. The novelty lies in the combination of those technologies to a holistic design. Our design is based on a requirements analysis regarding the aspects of security and usability. We derived a set of design decisions that we considered essential to achieve the expected level of security and usability.

The main limitation of our work is that we do not provide an practical evaluation of the proposed design. An evaluation of an implementation of the system in terms of performance and usability should be the next steps to prove the effectivity of the system. Another limitation is that it partly builds on technology which is not widespread (e.g. only a little number of devices with an MTM exists). Thus, even if we build only on existing technology, due to the limited diffusion of MTMs an implementation of our system may not be possible yet. Still, the proposed solution shows the direction to which mobile security research and development should go. It is essential for mobile security technologies to keep up with the developments in the usability of new-generation smartphones. Thus, research has to figure out how to provide existing technologies to the users in a way that does not disturb the user experience.

Fig. 1 .

 1 Fig. 1. Component Diagram of the Design

Fig. 2 .Fig. 3 .

 23 Fig. 2. Setup Process

Fig. 4 .

 4 Fig. 4. Boot and Authentication Process

Table 1 .

 1 further maps each criterion to the IT security protection goals that are affected. User Interface Access Control. A simple security mechanism that authenticates the user to unlock the user interface. -Access over Application Programming Interface (API). The security mechanism must consider the possibility that an attacker can install third-party applications, which use bugs to access data stored on the mobile device. -Self-Security. The security mechanism itself must be protected, which means that an unauthorized deactivation should not be possible. Evaluation Framework for Security

	Security Evaluation
	-

-Direct Storage Access. This attack requires to open the mobile device. If another device mounts the storage of the mobile device, security mechanisms are not loaded. In consequence, the attacker can extract stored data (only relevant to loss of device scenario, because this attack requires much time).

-Recovery. The possibility to find the mobile device after a loss to cut the financial loss (only relevant to loss of device scenario).

Table 2 .

 2 Evaluation Framework for Usability

		Usability	Aspects of Usability
	Comfort	Simplicity of Setup Maintenance Frequency & Effort of Credential Request Frequency of Decision Request User Comfort after an attack	Efficiency Efficiency, Satisfaction Efficiency, Effectiveness
	Cost	One-time costs Running costs Transaction-based costs	Efficiency Efficiency, Satisfaction Efficiency, Effectiveness


Alexios Mylonas
email: amylonas@aueb.gr

Vasilis Meletiadis
email: meletiadisv@aueb.gr

Bill Tsoumas

Lilian Mitrou
email: l.mitrou@aegean.gr

Dimitris Gritzalis

Smartphone Forensics: A Proactive Investigation Scheme for Evidence Acquisition

Keywords: Smartphones, Forensics, Digital Evidence

Smartphones constantly interweave into everyday life, as they accompany individuals in different contexts. Smartphones include a combination of heterogeneous data sources, which can prove essential when combating crime. In this paper we examine potential evidence that may be collected from smartphones. We also examine the available connection channels for evidence transfer during a forensic investigation. We propose a Proactive Smartphone Investigation Scheme that focuses on ad hoc acquisition of smartphone evidence. We also, take into consideration the legal implications of the proposed scheme, as it is essential that the scheme includes prevention mechanisms, so as to protect individuals from misuse by investigators or malicious entities.

Introduction

Smartphones, as ubiquitous devices, merge with a person's everyday life. As a recent report 1 points out, smartphone sales outnumbered these of feature phones, thus, acquiring a significant user base. Smartphones are characterized by mobility, contextawareness, and diversity on the data sources that they integrate. In a crime investigation context, the aforementioned characteristics can be used for forensic purposes, not only after a crime, but even proactively. For instance, in some crimes, which the in place legal and regulatory context regards as 'severe' (e.g. crimes against public or the state, pedophilia, etc.), proactive acquisition of smartphone data may be required. Currently, in a Lawful Interception (LI) of cell phones, Law Enforcement Agencies engage via the carrier's infrastructure, the intercep-tion of specific data, such as phone calls, messaging services, and network data traffic [START_REF]Lawful Interception; Requirements of Law Enforcement Agencies[END_REF]. The need for direct and in-time access to forensics data is also present in other technological contexts.

In the organizational context, Grobler et al. [START_REF] Grobler | A Multi-component View of Digital Forensics[END_REF] refer to proactivity, as "creating or controlling a situation rather just responding to it". They stress that a Proactive Digital Forensics (ProDF) as a process, ensures the facilitation of the investigation in a successful and cost-effective manner for enterprise systems. ProDF refers, for example, to the deployment of forensic readiness processes [START_REF] Tan | Forensic readiness[END_REF], which aim to maximize an environment's ability to collect credible digital evidence and, at the same time, minimize the forensics cost during incident response. These processes incorporate tools and techniques for active/live forensics that acquire volatile data for detecting criminal activity [START_REF] Sutherland | Acquiring Volatile Operating System Data Tools and Techniques[END_REF].

In traditional, i.e. post mortem, forensics the need for forensic triage [START_REF] Mislan | The growing need for on-scene triage of mobile devices[END_REF], [START_REF] Rogers | Computer forensics field triage process model[END_REF] emerges. Forensic triage refers to the notion of on-site forensics, which allows an investigator to directly assess a crime scene. Assessment is feasible for a subset of the available digital evidence. Consequently, delays on results, stemming from timeconsuming processes in the forensics lab, are avoided. Furthermore, in on-going crime investigations, forensic triage can assist an investigator to determine critical issues, such as subjects in immediate need or the suspect's call activity [START_REF] Walls | Forensic Triage for Mobile Phones with DEC0DE[END_REF], and act as appropriate. Also, mobile live memory forensic techniques focus on the acquisition of volatile data, which reside in device's memory [START_REF] Thing | Live memory forensics of mobile phones[END_REF].

In this paper, we examine the technological aspects of proactive smartphone digital forensics. A smartphone can provide additional information, which exceeds communication data. The multitude, variety and 'context awareness' of smartphone data may constitute crime evidence beyond the scope of current LI systems, both in technical and legal terms. Thus, we propose a Proactive Smartphone Investigation Scheme that incorporates misuse avoidance of proactive evidence collection.

The paper is organized as follows. In Section 2, a taxonomy of smartphone evidence and evidence transport channels is presented. Section 3 proposes an Investigation Scheme for proactive smartphone forensics. Section 4 discusses legal considerations for proactive evidence acquisition on smartphones. Section 5 concludes the paper.

Smartphone Evidence

Smartphones host a plethora of heterogeneous data generated from hardware or software sources. This section associates smartphone data sources with evidence types and then correlates these sources with smartphone evidence transport channels. These associations will be used in the sequel for smartphone ad hoc evidence acquisition.

Smartphone Evidence Taxonomy

In order to associate smartphone data to evidence types, a data-oriented analysis was followed. The analysis used a smartphone data taxonomy presented in [START_REF] Mylonas | Smartphone spying tools[END_REF]. Data are categorized, with respect to their source, as: a) Messaging Data, i.e. the content and metadata (e.g. sender, delivery time, etc.) from messaging services (e.g. Short Message Service (SMS), email etc.), b) Device data, i.e. data that are stored in the device storage media and are not related to any application (e.g. multimedia files, software and hardware identifiers etc.), c) (U)SIM Card Data, that reside in a (Universal) Subscriber Identity Module, such as IMSI2 and MSIN3 , d) Usage History Data, i.e. user logs (e.g. call logs, browsing history, etc.) and system logs kept for monitoring and debugging, e) Application Data, i.e. permanent or temporal data that are used during application execution (e.g. flat files, databases, etc.), f) Sensor Data, which are created by sensors that are found in most devices (e.g. camera, microphone, GPS), motion sensors (accelerometer, gyroscope), or environment sensors (magnetometer, proximity, light, temperature, etc.) and g) User Input Data, i.e. data from keystrokes, gestures, etc., which are processed on the fly, or stored in a keyboard cache for performance reasons.

The above mentioned data sources were organized in a taxonomy of evidence types, which derived from a set of questions -i.e. {who, where, when, what, why, how} [START_REF] Zachman | A framework for information systems architecture[END_REF]. These questions are being used in digital forensics literature [START_REF] Ieong | FORZA -Digital forensics investigation framework that incorporate legal issues[END_REF], [START_REF] Jansen | Guidelines on cell phone forensics[END_REF], [START_REF] Blackwell | An Investigative Framework for Incident Analysis[END_REF] for evidence examination and analysis, as well as for evidence presentation in courts of law.

 Identity Evidence. Data identify subjects that are part of an event.  Location Evidence. Data define the approximate or exact location, where an event takes place.  Time Evidence. Data can be used to infer the time that an event takes place.  Context Evidence. Data provide adequate context, such as user actions and activities for an event description [START_REF] Lane | A survey of mobile phone sensing[END_REF], or the event nature.  Motivation Evidence. Data can be used to determine event motivation.  Means Evidence. Data describe the way that an event took place, or the mean that were used.

Even if we both assume that smartphone data are generated in a deterministic and undisturbed way and their acquisition is always feasible, this does not necessarily mean that evidence will always be present. Hence, we use three levels of association of direct relationship between a data source and an evidence type, namely: a) Strong Correlation to represent that data sources always (or in most cases) provide potential evidence, b) Weak Correlation to represent that data sources may provide potential evidence according to their state, and c) No Correlation to represent lack of relationship between a data source and evidence type. In this point we note that motivation evidence may be deduced indirectly via the combination of the other evidence types. The rest of this section presents the correlation of the evidence types with the data sources.

 Messaging Data. Both traditional messaging services (e.g. SMS) and modern ones, e.g. email, often constitute potential evidence. Specifically, external communication data reveal the subjects and the communication time and, as a result, this source is strongly correlated with time and identity evidence. In addition, the communication content may reveal location evidence, motive evidence, etc., therefore this source is weakly correlated with them as well.  Device Data. Data such as system identifiers (e.g. IMEI) can be used to determine a subject from the provider's records, therefore a strong correlation with identity evidence exists. File system metadata can be used to determine time (e.g. file access time). Hence, a strong correlation with time evidence exists. Data created by the user (e.g. multimedia) may reveal motive or means evidence. In addition, device data may include sensor data as metadata (e.g. in geo-tagging). This provides a weak correlation with location, context, motivation or means of an incident.  (U)SIM Card Data includes identifiers (e.g. ICCID 4 , IMSI, etc.) that uniquely identify a device owner, thus, a strong correlation exists. Other data that may be stored in this source (e.g. contact entries, SMS and LAI5 ) [START_REF] Jansen | Guidelines on cell phone forensics[END_REF] can be used to deduce the rest evidence types, and, in this case a weak correlation exists.  Usage History Data can infer the event time and the means used by a digital incident, or they can even reconstruct user events, thus implying a strong correlation with the respective evidence types. Furthermore, under certain circumstances, the wireless connection history (i.e. access point MAC logs) may be used to infer the device location 6 , implying a weak correlation with this evidence type. Finally, Bluetooth pairing logs can be used to infer whether the user is in a crowded area and, in some cases, identify subject evidence via the device Bluetooth id.  Application Data. In some cases, private application data stored on the device may lead to potential evidence about an event and, thus, weak associations with the corresponding evidence exist. For instance: a) cached maps in navigation applications determine location evidence, b) cached social networking application data can be used to infer all the other evidence types depending on their content, etc.  Sensor Data provide weak correlations with all evidence types, since they can be used to infer the device context. For instance, a microphone can be remotely enabled [START_REF] Mylonas | Smartphone spying tools[END_REF] and harvest speech data related to all evidence types. Nonetheless, in the case of location evidences, the correlation is strong due to the popularity and location accuracy of GPS sensors. .  User Input Data can be used to identify a subject via keystroke analysis and, as a result, a weak correlation with this evidence type exists. Often, the keystroke cache content may reveal other evidence types, thus, a weak correlation with them exists.

Table 1 depicts the correlations between data sources and potential evidence types, where: (✓) stands for strong correlation, (~) for weak and (✘) for no correlation. Finally, the above evidence types can be combined to form evidence chains when they include valid timestamps. For instance, call logs combined with cached data of a navigation application can be used to reveal or confirm a subject's alibi.

~ ✓ ~ ~ ~ Device data ✓ ~ ✓ ~ ~ ~ (U)SIM Card Data ✓ ~ ~ ~ ~ ~ Usage History Data ✘ ~ ✓ ~ ✘ ✓ Application Data ~ ~ ~ ~ ~ ~ Sensor Data ~ ✓ ~ ~ ~ ~ User Input Data ~ ~ ~ ~ ~ ~

Evidence Transport Channels

Smartphones can use four data transport channels (or interfaces) that provide different transport services. This section discusses their ability to support evidence transfer during a proactive forensic investigation.

1. GSM Messaging interface (e.g. SMS, etc.) provides a remote channel appropriate for small volume data transfers, which is nearly always available. Apart from the restriction in volume, another refers to cost. Increased cost a) may limit the messaging service availability, thus, large data may not be transferrable and b) may alert suspects, who thoroughly check their carrier bills in the case a proactive investigation taking place. 2. Personal Area Network (PAN) interface (e.g. Bluetooth, IrDA, etc.) provides a cost free, ad hoc, remote data channel, appropriate if the data collector is in the smartphone's proximity. By not relying on any base station existence, it avoids network monitoring mechanisms, such as Intrusion Detection System (IDS). Furthermore, as this channel requires no cost, it is stealthier than others. Potential shortcomings are: a) distance constraint between the device and the collector, which increases attack complexity (e.g. Bluetooth range is 10 meters), b) the average transfer speed and c) the requirement for a pairing bypass without alerting the smartphone user. 3. WLAN interface (e.g. Wi-Fi) provides a fast, remote channel that is appropriate for any data volume often without a cost. Due to the general popularity of Wi-Fi, availability is considered high. A shortcoming is that data transfer speed and availability rely on the distance from a base station. This distance, though, is considerably larger than the PAN's requirement, thus, it does not add considerable complexity on evidence collection. 4. Cellular network (CN) interface provides a data transport channel of variable speed, which is dependent on the supported carrier network technology (e.g. GPRS, HSDPA, etc). A CN channel is not restrained by the antenna range. It provides greater mobility than any of the aforementioned channels, since the smartphone may travel through cells. Nonetheless, this channel is not considered suitable for large data volume, as: a) it suffers from connection drops, b) the network speed may vary as the user moves inside a cell or visits others, and c) this channel use has considerable cost, and thus it may be discovered by the owner.

Proactive Smartphone Forensics Investigation

This section focuses on proactive forensics, where ad hoc acquisition of smartphone evidence takes place. A proactive smartphone forensics investigation may take place for the investigation of crimes considered 'severe' by the legal and regulatory context in place (e.g. crimes against public or the state, pedophilia, etc.). In such cases, the creation and defence of an investigation hypothesis7 may use the aforementioned associations of smartphone sources with transport channels and evidence types. In this context, an investigation scheme is presented and outlined.

Proactive Smartphone Forensics Scheme

The proposed scheme consists of three entities (Fig. 1), namely: a) subject(s) carrying out a proactive smartphone forensic investigation (hereinafter 'investigator'), b) an Independent Authority (IA), and c) the investigation's subject(s) (hereinafter 'suspect').

Fig. 1. Proactive Smartphone Forensics Scheme

As depicted in Fig. 1, the IA is the scheme's corner stone, as it: a) controls evidence collection from the Software Agent (SA) that resides in the suspect's smartphone, b) handles evidence storage for a time period compliant with existing laws and regulations, and c) authorizes investigator's requests for a proactive forensic investigation against individuals.

This architecture was selected so as to hinder investigators, or other individuals, from misusing the evidence collection mechanism for profiling and intelligence gathering reasons (see Section 4).

Hence, it is assumed that the IA allows a proactive digital forensic investigation to take place only in suspected 'severe' crimes. It is also assumed that the IA maintains a database, where evidence data are stored and protected, in terms of forensic soundness and confidentiality.

The investigator's role in this scheme is to create a hypothesis, i.e. collect adequate evidence suitable for use in courts of law. An investigator may request from the IA authorization for a proactive smartphone forensics investigation to take place when: a) other mechanisms for data collection are either incapable to gather the required data (e.g. cases where the suspect's context is required), or they collect data of reduced accuracy, inadequate for evidence presentation in a court of law (e.g. the location accuracy of the GPS sensor is greater than the approximate location provided by the cell phone provider), and b) the suspected crime is considered 'severe' by laws and regulations.

In this scheme, it is assumed that a Software Agent (SA), controlled by the IA, is present in the suspect's smartphone. Also, the IA has the capability to commence the collection of evidence types from selected smartphone sources. The scheme's architecture is depicted in Fig. 1, while its processes are described in the following section.

Scheme Processes

The proposed scheme consists of six building blocks -processes, namely: 1) investigation engagement, 2) evidence type selection, 3) evidence collection, 4) evidence transmission, 5) evidence storage and 6) investigation completion.

The first process takes place once per suspect investigation, while the remaining processes are iterative and incremental. The last process (Process 6: Investigation Completion) is completed when the investigation's requirements are satisfied, i.e. the hypothesis can be created and its validity can be defended in the courts of law, or when the IA's granted permission becomes invalid. The other processes are described in detail in the sequel.

Process 1: Investigation Engagement. It consists of two sub processes that define an investigation's details:  Process 1.1: Investigation Request (IR). This is the formal request of investigation authorization, addressed to the IA. The request contains a definition of investigation specific parameters, such as: a) the investigator who creates the hypothesis, b) the suspects(s), c) the nature of the examined crime, d) the expected investigation period, e) the required data sources that will be collected as potential evidence, and f) the required channels for evidence transmission.  Process 1.2: Investigation Session. Once an Investigation Request is submitted to the IA, a non-automated process determines the investigation's permission level upon the suspect's smartphone. This permission level is determined by the IR details and the evaluation criteria of each IA, which are dependent on the regulatory context. If the IR is accepted, an investigation session is provided to the investigator that is used for the following processes.

Process 2: Evidence Type Selection. This process is initiated after the investigation engagement process. It refers to the selection of evidence types and the corresponding transport channels by the investigator. This selection is carried out based on the two associations presented previously: (1) between smartphone data and digital evidences, and (2) between smartphone data and transport channels. For instance, an investigator may compile a configuration request for the SA evidence collection process. This configuration request specifies the desired data sources (e.g. motion sensors data) and transport channels (e.g. WLAN), and it is forwarded to the IA. Then, the IA executes the request by acquiring evidence from the SA, only if the configuration request parameters are conformant with the current investigation session permission level. In this way, misuse of evidence collection is avoided. Finally, this activity takes place every time the investigator makes a new request for potential evidence in the context of the same investigation session.

Process 3: Evidence Collection. It is triggered every time the SA configuration is altered. Based on configuration attributes (i.e. data source, transfer channel, interception period and duration, etc.) the SA harvests potential evidence, applies integrity mechanisms and forwards them to the evidence transmission process.

Process 4: Evidence Transmission. The transmission of evidence takes place, when the collection process ends. It is assumed that an Evidence Transmission Protocol (ETP) is applied between IA and SA. This ETP must include messages for the collection of all smartphone data sources and support the various smartphone transport channels. Furthermore, the ETP must impose security properties, such as message authenticity, integrity, liveness, and confidentiality.

Process 5: Evidence Storage. It refers to the storage of potential evidence that is received from the SA in the IA's infrastructure. The preservation of potential evidence in the forensics database must ensure their forensic soundness via employing integrity mechanisms, as well as, their confidentiality. The stored evidence is bound to be revisited during an investigation, so as to be further examined and analyzed before being presented in court. Thus, limited access (e.g. read-only) is provided to the investigator via an interface.

Legal Considerations

A smartphone combines the features of a cell phone along with PC-like functionalities. It permits access to saved and sent messages and files and provides tools for accessing data not presently stored on the device.

Even if some Courts (like the Fifth Circuit) do not recognize any conceptual differences between searching a person's body and searching electronic equipment that this person possesses or carries with him, a smartphone stores and reveals apparently and tremendously more information, thereby providing law enforcement with access to information that a person would never carry in her pocket [START_REF] Gershowitz | The iPhone meets the Fourth Amendment[END_REF].

A smartphone itself, alone or in its technical networking, can contain personal data to such a degree and in such diversity that it may provide a revealing picture of her personality, and/or facilitate insight even into the core area of private life of a person. With the increasing use of such devices for every kind of communications, including social networking, the importance of digital evidence gathering is increasing as well. A smartphone offers law enforcement authorities "a window into their suspect" not only via hard evidences but also through the character and habit information it may provide [START_REF] Morrissey | IOS Forensic Analysis: for IPhone, IPad and IPod Touch[END_REF].

Accessing, searching, and using as evidence the data communicated, accessed or stored by a smartphone, poses new challenges to courts and legislators that are far reaching and go far beyond the secrecy of telecommunications. Neither regulatory regimes concerning the monitoring and recording of communication content, nor rules providing for the retention of external communications data (traffic data) is deemed appropriate and/or sufficient to deal with evidence acquisition for smartphone forensics, as interception refers to the surveillance of a communication taking place between communication partners.

Sensor data or User Input Data could be deemed as biometric data, enabling the collecting of sensitive data and the profiling of the person concerned. Different legal standards and requirements apply to the lawful interception of communications by law enforcement authorities than to the recovery of data stored on a smartphone.

Especially if the data provided by such a device are remotely searched or are not presently stored with the confines of the device, it appears that the acquisition evidence appears to be comparable to a search of premises [START_REF] Wiebke | Agents, Trojans and tags: The next generation of investigators[END_REF]. The need for review of existing regulatory concepts and converged regulatory regimes in order to face modern converged communication and IT systems in a consistent way is obvious.

The German Constitutional Court has recently (2008) placed strict limits upon the ability law enforcement authorities to remotely access computers, PDAs and mobile phones. The Court has specified the rights to "informational self-determination" and "absolute protection of the core area of the private conduct of life" and has lifted "security and integrity of information systems" as a fundamental right of the user, expressing a right to the unhampered development of her personality in the information era [START_REF] Wiebe | The new Fundamental Right to IT Security -First evaluation and comparative view at the U.S[END_REF]. On the other side it is not clear if the Fourth Amendment of the US Constitution affords reasonable expectation of privacy and protection against unreasonable searches and seizures to a person who uses a smartphone.

Evidence acquisition and surveillance in the digital world need to be adapted to keep pace with technological progress. Legislators have to constantly struggle to keep up with technology and to new risks and challenges. The proposed smartphone investigation scheme is valuable for combating crime and security threats through proactiveness.

Proactive, routine data and preservation reflects the transformation from the traditional constitutional model of gathering conclusive evidence of wrongdoing of suspect individuals toward a model of intelligence gathering where information is collected at random on all users [START_REF] Mitrou | Data Retention: a Pandora Box for Rights and Liberties?[END_REF].

Both legislators and IT-designers should take care to prevent the deployment of technology that treats all users as potential criminals or suspects without any cause [START_REF] Brown | Regulation of Converged Communications Surveillance[END_REF].

Therefore, the proposed proactive forensic investigation scheme has been conceived and designed with protective mechanisms in place that hinder investigators or other malicious individuals, from misusing it, and, in a way that allows the acquisition and preservation of data, without infringing fundamental rights.

Conclusions

Proactive digital forensics is, per se, an interdisciplinary task, requiring the cooperation of computer and law scientists. In this paper, we examined the technological aspects of proactive smartphone digital forensics. We studied associations between the smartphone data sources and evidence types, as well as the available connection channels in order to deliver potential evidence from a smartphone.

Then, a proactive smartphone forensics scheme was developed. By using this scheme, the appropriate person can collect smartphone data that are essential for combating 'severe' crimes.

We also examined the current legal and regulatory framework concerning ad hoc data acquisition from smartphones. We stressed that even though our proposed investigation scheme can be an essential tool in combating specific types of crime, its application and legality lies clearly with the presence of strong protection mechanisms that ensure its lawful use. Otherwise, this scheme could be used as a tool for profiling or intelligence gathering, thus violating fundamental rights of individuals.

Future work will include the implementation of the proposed scheme with a focus on the Software Agent and the Evidence Transmission Protocol. We also plan to evaluate the implementation performance in real world scenarios, explore alternative misuse avoidance mechanisms and add stealthiness techniques to the agent. Finally, we plan to elaborate more on the proposed taxonomies by identifying subgroups in each smartphone data source and their respective correlations.

Fig. 2 .

 2 Fig. 2. Processes of the Investigation Scheme

Table 1 .

 1 Correlation between evidence types and data sources

	Data sources	Evidence Types	Identity Location Time Context Motivation Means
	Messaging Data	✓

Table 2

 2 summarizes each channel's ability to effectively transfer each source data volume (hereto referred as 'volume'). For the association notation three symbols were used, i.e.: 1. (?) transfers small subset of the data source, 2. (~) transfers most data in this data source and 3. (✓) can transfer source type. Obviously, the WLAN channel is able to transfer all data sources. The rest of the associations are listed below:Messaging data are not volume intense, thus, they can be transferred by all channels.  Device data include data with different volume requirements, ranging from small files to high definition videos. Hence, the GSMMe channel can only convey a subset of this source, whereas PAN and CN can convey, in general, this data source. Nonetheless, the latter are limited by time and transfer cost respectively.  (U)SIM Card Data is not volume demanding, and can be transferred by all channels.  Application Data volume requirements range from few Kbytes up to hundreds of Mbytes. As a result, PAN and CN (provided that available quota exist) are able to transfer this data type. GSMMe can only transfer application data that are not volume intense.  Usage History Data are not always volume demanding (e.g. recent call logs) and, hence, can be transferred by GSMMe. Nonetheless, this data type includes OS logs, which are data volume intense and are transferable by PANs and CNs (if available bandwidth quota exists).

 Similarly to Usage History Data, Sensor data can be a) either not volume intense (e.g. GPS coordinates) and, thus, transferrable by GSMMe, or b) volume intense (e.g. accelerometer data) that can be transferred by PAN and CN.  User Input Data volume requirements range from a few Bytes, which are transferable even by GSMMe, up to several Mbytes (e.g. keystroke dictionaries) that are transferable by PANs and CNs.

Table 2 .

 2 Correlation between transport channels and data sources

	Data type	Transport channel	GSMMe	PAN	WLAN	CN
	Messaging Data		✓	✓	✓	✓
	Device data		?	~	✓	~
	(U)SIM Card Data	✓	✓	✓	✓
	Application Data	?	✓	✓	~
	Usage History Data	?	✓	✓	~
	Sensor Data		?	✓	✓	~
	User Input Data		?	✓	✓	✓

International Data Corporation (IDC). Smartphones Outstrip Feature Phones for First Time in Western Europe as Android Sees Strong Growth in

2Q11, September 2011.

The International Mobile Subscriber Identity (IMSI) identifies the subscriber to the network.

Mobile Subscriber Identification Number (MSIN) is the 10-digit phone subscriber number.

Integrated Circuit Card ID (ICCID) is the serial number of the (U)SIM card.

Simply put the Location Area Identity (LAI) identifies the cell where the device is in and as a result can be used to get an approximation of device location.

Via public mapping of MAC addresses to GPS coordinates, such as http://samy.pl/mapxss/

Hypothesis is a report based on the examination and the analysis of collected evidence that are admissible to court.

Acknowledgements

This research has been co-funded by the European Union (ESF) and Greek national funds, through the Operational Program "Education and Lifelong Learning" of the National Strategic Reference Framework (Program HERACLEITUS II: Investing in knowledge society through the European Social Fund).

The authors would like to thank Marianthi Theoharidou (AUEB) for her valuable contribution.


Yannis Soupionis

Miltiadis Kandias
email: kandiasm@aueb.gr

Web Services Security Assessment: An Authenticationfocused Approach

Keywords: Security Assessment, Web Services, Authentication, Performance

Web services may be able to publish easily their functions to the rest of the web world. At the same time they suffer by several security pitfalls. Currently, there is limited research on how the proposed web-services security countermeasures affect performance and applicability. In this paper, we introduce the threats/attacks vs. web-services authentication, present the most widely used security method for protecting it, and identify the threats/attacks tackled by those methods. Moreover, we evaluate the web service authentication mechanism proposed in these implementations, not only on a theoretical level (by taking into consideration all the security issues of the implementing authentication sub-mechanisms), but also in a laboratory environment (by conducting extensive experiments). Finally we demonstrate the trade-offs between sophisticated web-service security methods and their performance.

Introduction and Related Work

The explosive growth of the World Wide Web has introduced a wide array of new technological advances and several sophisticated end-user services. Development in data networks facilitated the introduction of web services [START_REF] Papazoglou | Web Services and Business Transactions[END_REF] [2] [START_REF] Erl | Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services[END_REF], which have been increasingly penetrating the web market. Web services are a realization of a more abstract architectural style, called Service-Oriented Architecture. While web services introduce a variety of new functionalities, they also increase the complexity of the system and can be subject to a significant variety of attacks. Currently, there is limited evaluation on how web services security are practically enforced. Existing work focuses on high level aspects of security, namely business-oriented ones, while it has paid limited attention to technical aspects. A relevant publication shows an extension of the WS-Security standard [START_REF] Vedamuthu | Web Services Policy 1.5 -Framework[END_REF]. Another publication [START_REF]WS-SecurityPolicy 1.3[END_REF] defines three security policy assertions provided in SOAP Message Security, WS-Trust and WS-Secure Conversation. The paper defines a basic set of assertions, which describes how messages are to be secured, without providing enough information on development or performance trade-offs. Both the above papers propose mechanisms to enforce specific security aspects, but they provide no metric, capable of assessing a balance between performance and security.

In our paper, we provide a model capable of measuring the effectiveness and performance of security mechanisms and put in place with web services. In particular, we focus on the authentication process. A web service cannot function properly if the authentication mechanism is either compromised, or complex enough to inadequately downgrade the performance of the web service. Our approach is based on (a) identifying all possible attacks/threats of web services authentication, (b) assessing the key methods of securing web authentication, and (c) evaluating the system performance.

In Section 2, we present authentication in web services and we illustrate the web services authentication threats. We also show whether they are tackled by the authentication methods. In Section 3 we provide the results of a series of experiments on how different implementations of authentication mechanisms affect the system performance. Finally, we describe our conclusions, together with plans for future work.

Web Services Threats and Countermeasures

In addition to software development best practices that are proposed mainly by the various WS standards, numerous countermeasures exist. An authentication process consists of: a) the authentication data of the requesting entity, b) the channel through which this data is transmitted, and c) the data validation according to an authentication database.

The security countermeasures, which were chosen to protect the service, are: a) a username and a password (credentials), b) encryption over the channel, and c) password hashing [START_REF]WS-SecurityPolicy 1.3[END_REF]. Each of the above countermeasures may be implemented by different technologies, which are:

1. Password: a) One-Time-Password, b) good practice based password, c) based on no good practice (i.e., chosen once and valid forever, no rules about using special characters, etc.).

Channel

: a) VPN, b) Asymmetric SSL, c) Symmetric SSL, d) unprotected channel (HTTP). 3. Password storage: a) MD5, b) SHA1, c) Plaintext.
The vulnerabilities introduced by the software implementing these methods, which can introduce new attacks to the service, are out-of-scope of this paper.

In order to study the effectiveness of the above security countermeasures, we produced a list of known web-service attacks. The list is based on WS standards [START_REF] Nadalin | OASIS WS-Trust 1.4[END_REF][START_REF] Nadalin | Web Services Security: SOAP Message Security 1.1 (WS-Security[END_REF][START_REF] Vedamuthu | Web Services Policy 1.5 -Attachment[END_REF][START_REF] Nadalin | WS-SecureConversation 1.3[END_REF] and research output. From the produced list of 24 attacks we excluded 7, because they do not affect authentication mechanism. In Table 1, if a countermeasure/ mechanism deals with an attack, then the corresponding cell is checked. This table is a useful tool for those in charge of either the security or the development of a web service. Fur-thermore, based on the results of a risk assessment review, the analyst can choose a combination or a single countermeasure to tackle attacks assessed as important.

   
In this section we identify the performance issues raised when a secure mechanism is used for a web-service authentication. The performance issue depends on the resources consumed, as well as on the time needed for establishing a web-service session. In order to determine and evaluate how the authentication method affects the system performance, we had to record the corresponding values of the monitoring subjects (time, computational resources) during significant overload. The tests were performed so as to evaluate a web service authentication mechanism, strengthened by the countermeasures mentioned in Section 2. The password policy was not tested through experimentation, as it is based solely on human factor parameters and do not differentiate, in terms of computational cost. The purpose of the first two tests is to evaluate the performance of each countermeasure, separately. In the final test, we implemented combinations of countermeasures in order to get a more holistic view of the authentication web service's performance.

Mechanism scenarios and results. In order to implement the scenarios, we used ten external clients, which initiated web-service requests. The scenarios consisted of five phases. During the first phase, each external client made only one request. Thus, the web-service received a total of 10 requests. During the second phase, every external client made 100 requests. Thus, the proxy received a total of 100 requests, while in the last one, with proportional way, the web-service received 105 requests. Only one mechanism was evaluated for each scenario. The other mechanism was implemented so as to produce the minimum overload to the test. If the channel type was the one tested, then the password storage parameter was set permanently to plaintext. The results of the evaluation of the channel type are summarized in Table 2.

The average processing time, for a request to be properly handled, was <300 msec. The maximum time for handling a request was 2.5 sec. This appears to be excessively high. It happened when many requests were to be handled and thus a very high CPU and memory overload occurred. Therefore, if a web service expects many simultaneous requests, then a VPN implementation is not a good solution. The results produced by the evaluation of the password storage policy are summarized in Table 3. The average processing time, for a request to be properly handled, is <150 msec. The maximum time for retrieving a password was 1.9 sec for the SHA1 and 1.3 sec for MD5. These time periods may not be always acceptable, as several applications that cooperate with the web-services have lower timeouts. The long time is needed in case there were many requests to be handled. In this case, there was a high I/O to the hard drives, while both CPU and memory were overloaded.

Extended test scenarios and results. In order to implement these scenarios, we used ten external clients, which initiated web-service requests. The extended test scenario consisted of three phases (1000, 10000, 100000 requests). During these tests, all authentication sub-mechanisms were implemented, in all combinations. In Figure 1, we illustrate the most important fraction of these implementations, as well as the average time needed to serve an incoming request. Our main conclusions are: a) the symmetric SSL implementation is from 15-20% quicker than asymmetric, b) the performance is slightly affected by the use of SHA1 or MD5 (5%), and c) the non-encrypted channel improves significantly the web service performance. Taking into consideration the above mentioned conclusions, as well as the maximum time period to serve a request, which is ~3 sec (except of SHA1/HTTP), it turns out that the web-service providers should use these results when selecting which countermeasure to use for strengthening a web-service authentication mechanism.

Concluding, the main questions a web-service provider should answer, before hardening the a web service security, are: a) how many requests are going to be received?, b) is it possible for the web-service and the participating machines to handle the key management for a symmetric SSL implementation?, c) should all the transmitted data between the corresponding entities, apart from authentication process, be encrypted in order to justify the VPN overload?, and d) is the processed web-service data useful enough to worth the additional overload of the encrypted channel?

Conclusions and further research

In this paper, we described a security assessment capable of evaluating web service authentication mechanisms. Based on security mechanisms, such as communication channel type, password storage, and password alteration policy, we managed to identify how these mechanisms deal with the corresponding attacks. Then, we evaluated the mechanisms by implementing a web-service. Our experimentation aimed at determining the performance in various combinations of the authentication implementations. We showed that security countermeasures/mechanisms selection should be based not only on their ability to tackle attacks, but also under the prism of their computational cost. Thus, web services, which are expected to serve requests under heavy load, must be developed with this parameter in mind. The correlation between security and computational cost can be used to explain to security unaware stakeholders the requirements put and the decisions made. Our assessment proved to be a useful tool not only for those implementing web-services, but also for those who make management decisions. Further research could extend the proposed security assessment with additional goals, such as data integrity, non-repudiation, or authorization. As the additional security-related goals may add complexity, we may adopt different methods for security assessment, e.g., entropy algorithms [START_REF] Serjantov | Towards an Information Theoretic Metric for Anonymity[END_REF], or take into consideration information for detected authentication vulnerabilities through formal analysis [START_REF] Basagiannis | Intrusion Attack Tactics for the model checking of e-commerce security guarantees[END_REF]. Finally, we intend to study the aforementioned characteristics in composed web-service environments (mashups) [START_REF] Zeng | QoS-Aware Middleware for Web Services Composition[END_REF], [START_REF] Rosenberg | End-to-end security for enterprise mashups[END_REF].

Fig. 1 .

 1 Fig. 1. The average time needed for serving a web-service request

Table 1 .

 1 Countermeasures vs. Threats

	Mechanism		Password		Channel	Password Storage
	Threats	OTP	Good Practice Based	No Good Practice	VPN	Symmetric SSL	Asymmet-ric SSL	HTTP SHA1 MD5 Plaintext
	Replay attack

Table 2 .

 2 Channel type experimental performance

		Requests	10	100	1.000	10.000	100.000
	Average	V P N	29,3	28,9	29,1	171,1	298,0
	time per	Asymmetric SSL	27,4	27,6	27,4	188,2	282,3
	session	Symmetric SSL	20,4	21,9	20,7	112,1	204,4
	(msec)	HTTP	12,0	12,0	12,0	28,0	125,0

Table 3 .

 3 Password storage experimental performance

	Requests		10	100	1.000	10.000	100.000
	Average time per session (msec)	MD5 SHA1 Plaintext	9,5 9,8 7,1	9,2 10,0 6,9	12,6 16,8 6,7	75,4 107,8 8,1	102,8 143,2 12,4

Acknowledgments

This work was performed in the framework of the SPHINX (09SYN-72-419) Project, which is partly funded by the Hellenic General Secretariat for Research and Technology (http://sphinx.vtrip.net).