Kyriakos Stefanidis
email: stefanidis@isi.gr

Artemios G Voyiatzis
email: avoyiatzis@sba-research.org

An HMM-based Anomaly Detection Approach for SCADA Systems

We describe the architecture of an anomaly detection system based on the Hidden Markov Model (HMM) for intrusion detection in Industrial Control Systems (ICS) and especially in SCADA systems interconnected using TCP/IP. The proposed system exploits the unique characteristics of ICS networks and protocols to efficiently detect multiple attack vectors. We evaluate the proposed system in terms of detection accuracy using as reference datasets made available by other researchers. These datasets refer to real industrial networks and contain a variety of identified attack vectors. We benchmark our findings against a large set of machine learning algorithms and demonstrate that our proposal exhibits superior performance characteristics.

Introduction

The continuous interconnection of Industrial Control Systems (ICS) to public and corporate networks exposes them to the common Information Technology (IT) vulnerabilities and attacks. The security mechanisms that are traditionally used in the ICS environment cover the basic needs for authentication, authorization and (sometimes) communication confidentiality. However, they leave the Operations Technology (OT) networks open to more elaborate IT-based network attacks.

The rise of security incidents involving malicious network activity in critical infrastructures drives the need for intrusion detection technologies and mechanisms to be adapted for the OT environment. Several methodologies have been proposed recently that attempt to solve the problem of designing an efficient Network Intrusion Detection System (NIDS) specifically for the integrated IT-OT environment [START_REF] Zhu | Resilient Control and Intrusion Detection for SCADA Systems[END_REF].

There are many approaches proposed in the literature, especially using anomaly detection techniques. These approaches use a combination of the known machine learning algorithms in order to determine the normal behavior of the network and detect any abnormal network traffic. The unique characteristics of network traffic in OT environments, including stable connectivity, periodicity in traffic patterns, use of standard application level protocols, are discussed in [START_REF] Barbosa | Anomaly detection in SCADA systems: a network based approach[END_REF]. These characteristics render network-based anomaly detection a useful approach.

The main issue discussed in the literature for NIDS is the need to correlate a high enough amount of traffic (i.e., network packets) so as to decide on the abnormality of the sampled traffic. To support real-time detection of abnormal traffic, it is interesting to explore the efficiency of an approach that relies only on individual packets. Towards this direction, the use of Hidden Markov Model (HMM) approaches is limited within the literature. This despite that HMM is among the most promising approaches for this problem [START_REF] Yasakethu | Intrusion Detection via Machine Learning for SCADA System Protection[END_REF].

In this paper, we design and evaluate an HMM-based Network Intrusion Detection System (NIDS) for the OT environment. The system exploits the unique traffic characteristics of an ICS, and especially of SCADA systems communicating over TCP/IP technologies. Our aim is achieve a high-rate of detection of a wide range of attack vectors. The evaluation of the system is based on freely-available datasets that represent the operation of real industrial networks and have already been used to test several machine learning algorithms. This allows a fair comparison of our HMM-based approach with other machine learning approaches that are proposed in the literature.

The rest of the paper is organized in four sections. Section 2 provides a survey of approaches for anomaly detection in the ICS environment. Section 3 describes the proposed system architecture. Section 4 describes the experimental setup and the datasets used for evaluating the accuracy of the system. Section 5 presents and discusses our findings. Finally, Section 6 provides our conclusions and the future directions of work.

Literature Review

Many researchers tackled the problem of efficient anomaly detection in ICS environments using a wide range of machine learning techniques and targeting different application scenarios. A recent comprehensive account of such IDS, including a taxonomy of attacks is available in [START_REF] Zhu | Resilient Control and Intrusion Detection for SCADA Systems[END_REF]. We revisit some representative works in the following paragraphs.

Ali et al. focused on the advanced metering infrastructure (AMI) [START_REF] Ali | Randomization-Based Intrusion Detection System for Advanced Metering Infrastructure[END_REF]. The authors used a fourth-order Markov chain to model the AMI behavior via the event logs of the network. They proposed a configuration randomization mechanism in order to make the system more robust against evasion attempts.

Caselli et al. dealt with semantic attacks that involve sequences of permitted events and how they elude a normal NIDS [START_REF] Caselli | Sequence-aware Intrusion Detection in Industrial Control Systems[END_REF]. The authors used discrete-time Markov chains to describe the normal operations and calculated the weighted distance between the states for the detection mechanism.

Erez et al. considered the Modbus/TCP protocol and focused only on the values of the control registers [START_REF] Erez | Control variable classification, modeling and anomaly detection in Modbus/TCP SCADA systems[END_REF]. They classified the control registers in three classes and constructed three different behavior models, one for each class. Yoon et al. also considered the Modbus/TCP protocol [START_REF] Yoon | Communication Pattern Monitoring : Improving the Utility of Anomaly Detection for Industrial Control Systems[END_REF]. They used Dynamic Bayesian Networks and Probabilistic Suffix Trees for traffic modeling. They also incorporates a mechanism that checks whether a detected anomaly is based on missing messages instead of an attack.

Ntalampiras et al. used an HMM to model the relationship between data streams from two network nodes [START_REF] Ntalampiras | A fault diagnosis system for interdependent critical infrastructures based on HMMs[END_REF]. They used a combination of emulated network components and simulated physical devices for the experimental framework. They considered only two types of attacks, namely denial of service and replay attacks, for the evaluation of the system's efficiency.

Marti et al. combined a segmentation algorithm with a one-class support vector machine (SVM) [START_REF] Martí | Anomaly Detection Based on Sensor Data in Petroleum Industry Applications[END_REF]. They constructed an anomaly detection system specifically for petroleum industry applications. Schuster et al. also evaluated the efficiency on one class SVMs [START_REF] Schuster | Potentials of Using One-class SVM for Detecting Protocolspecific Anomalies in Industrial Networks[END_REF].

Almalawi et al. explored a two-step methodology based on unsupervised learning [START_REF] Almalawi | An unsupervised anomalybased detection approach for integrity attacks on SCADA systems[END_REF]. They performed an automatic classification of normal and abnormal operation states as a first step. Then, they automatically extracted proximity detection rules for those states. The detection step is based on the kNN algorithm, raising the computational complexity to impractical levels. Hadziosmanovic et al. followed the path of integrating the operational parameters of the network and its devices [START_REF] Hadžiosmanović | Through the eye of the PLC: Semantic Security Monitoring for Industrial Processes[END_REF]. They extracted these parameters and used auto-regression and control limits in order to map the changes in the time domain. An alert was raised if the data did not fit the model or were outside the control limits.

Raciti et al. tackled the problem of designing a real-time detection system that can be implemented insider a smart metering system [START_REF] Raciti | Embedded cyber-physical anomaly detection in smart meters[END_REF]. They used a basic clustering algorithm for this and they were more concerned on the deployment issues of such a system on a massive scale.

System Architecture

The proposed system is an anomaly detection system. Its underlying detection algorithm is based on Hidden Markov Model (HMM). The merits of an HMMbased approach for anomaly detection in ICS environments are discussed in [START_REF] Yasakethu | Intrusion Detection via Machine Learning for SCADA System Protection[END_REF]. This approach assumes that a model emits sequences of symbols. This model is a Markov process and its states are hidden from the observer. The model has a probability of transitioning from one state to another one and each state has a probability of emitting a symbol. An HMM is characterized by the following parameters:

-N : The number of states.

-M : The number of symbols (vocabulary).

-A: The probability distribution between stages (N × N ).

-B: The probability distribution to emit a symbol (N × M ).

p: The probability vector on the starting state.

The overall system architecture is depicted in Figure 1. The system operates in two distinct phases: the training phase and the detection (evaluation) phase. In the training phase, the parameters (A, B, p) of the model are estimated, using a training set of sequences. The Baum-Welch algorithm is used in order to maximize the probability that the model emits the training sequences. In the detection phase, the Forward-Backward algorithm is used to calculate the probability that a received (captured) sequence is emitted by the model.

The core design problem is the selection of the sequences that are used to construct the model(s). We opted for two distinct models that are implemented in two subsystems, namely header and data. The subsystems collect different segments from each traversing network packet. The byte sequences of the segments are the sequences used at each subsystem's HMM. The exact choice of segments depends on the network and application protocols used in the SCADA system.

In general, an NIDS that targets all major ICS protocols must provide a configuration for each protocol. In the following, we will discuss the subsystems' design for the case of a Modbus/TCP protocol.

The Modbus Protocol

Modbus is the de facto standard for connecting industrial electronic devices in ICS. Modbus is a simple and robust protocol, with two roles (master and slave) and stateless communication of request/response frame pairs. Modbus frames can be carried over serial links or TCP/IP. The Modbus slave device is modelled as a set of four memories, namely coils, discrete inputs, holding registers, and input registers. The control loops and the reporting can be modeled as a series of reads and writes of these memories.

The format of a Modbus frame when transmitted over TCP/IP is depicted in Figure 2. The Modbus/TCP Application Data Unit (ADU) consists of a 7-byte header (Modbus Application Header, MBAP) and a Modbus Protocol Data Unit (PDU) of up to 253 bytes.

Fig. 2. Modbus frame encapsulation in TCP segments

The MBAP consists of a 2-byte transaction identifier; a 2-byte protocol identifier (set to 0x0000 for Modbus); a 2-byte length field, indicating the number of the following bytes; and a 1-byte unit identifier (set to 0xFF, equivalent to the slave address in the serial version of Modbus).

The Modbus PDU carries requests that are defined in function codes (FC), ranging from 0 to 127, while negative responses range from 128 to 255. Each function code can be followed by function parameters, passing request parameters to the slave. For example, a read coil function code is followed by the address (number) of the specific coil to be read. Modbus is a simple protocol and its implementation should be straightforward and bug-free; however this is not the case [START_REF] Voyiatzis | A Modbus/TCP fuzzer for testing internetworked industrial systems[END_REF].

Header Subsystem

The first subsystem is the "Header subsystem". This subsystem is responsible for detecting anomalies on the network traffic from attacks that manipulate the header information. Example attacks of this type include denial of service, fake devices, sending data to third parties, and Modbus response or command injection.

The header subsystem sequences the Modbus Function Code, the Modbus/TCP header, and selected parts of the TCP and IP headers. One sequence is extracted from each captured packet. The output of the subsystem is one probability.

Data Subsystem

The second subsystem is the "Data subsystem". This subsystem outputs n distinct probabilities for each packet. The mean value of those is the final output of the subsystem for this packet. This subsystem is responsible for detecting attacks that manipulate the data that are produced by all the devices participating in the network. Such attacks are usually malicious device tampering or could be side-effects of a network attack.

The data subsystem sequences the Modbus/TCP data value(s). Each sequence is the concatenation of the IP address, the Modbus device identifier, and one data value. The sequencer extracts from each packet n sequences, where n is the number of data values in the network packet. In the case of Modbus/TCP, this is equal to the number of memory addresses requested.

Detection Process

Each subsystem contains multiple HMMs and each sequence is routed through all the contained models. The use of multiple classifiers can help reach better accuracy, as shown in [START_REF] Perdisci | McPAD: A multiple classifier system for accurate payload-based anomaly detection[END_REF]. The resulting probabilities from each classifier are fused together, as described in [START_REF] Ariu | HMMPayl: An intrusion detection system based on Hidden Markov Models[END_REF]. The final outcome is an overall probability for each packet. We note that all the HMMs are trained with the same training data but with different (random) starting parameters.

The last part of the detection process is the classification. Each subsystem has a certain threshold under which the packet is classified as being part of an attack. The threshold is necessary because the result of an HMM is an unweighted probability (i.e., a "log-likelihood"), which can only be evaluated in conjunction with the log-likelihoods that the HMM outputs for normal traffic.

Finally, if one of the subsystems issues an alert, the system routes this alert to the SCADA or another part of the IDS, depending on the system deployment.

Datasets and Experimental Setup

In order to evaluate the efficiency of the proposed system, we need a set of data from either a simulated or a real environment. This dataset should have a mix of normal traffic and attack traffic from various attacks. We opted for freelyavailable datasets that have already been used for the evaluation of existing systems, in order to be able to compare our approach with known solutions and algorithms.

Description of Datasets

The datasets that are originally chosen are the three datasets of [START_REF] Morris | A control system testbed to validate critical infrastructure protection concepts[END_REF]. These datasets contain measurements from a laboratory-scale gas pipeline, a laboratoryscale water tower, and a laboratory-scale electric transmission system. All three datasets contain pre-processed network transaction data but the lower communication layers (Ethernet, IP, and TCP) are stripped. The range on the number of entries on each dataset varies from 100,000 to 5,000,000.

Due to the vast amount of data in the given datasets, the time needed for each experiment grew prohibitively long. We resorted on using the limited versions (offered from the same source) that contain 10% random samples from the original datasets. The effectiveness of various tested machine learning algorithms remains mostly unchanged, regardless on the version of datasets that is used for the experiment [START_REF] Hsu | Mississippi state university project report -SCADA anomaly detection project summary[END_REF].

The value of these datasets for the evaluation of our system lies on the fact that these datasets contain real measurements and both the network protocol headers and the payload of each entry (measurement) are available. Furthermore, these datasets include both normal traffic and a variety of simulated attacks. Each entry is categorized in one of seven [START_REF] Caselli | Sequence-aware Intrusion Detection in Industrial Control Systems[END_REF] The attack vectors contain both header and payload manipulation patterns. We consider them sufficient for the purpose of the evaluation of our system.

One last limitation is the absence of TCP/IP data on each packet. Since our system combines the payload data, the IP address and the unit (device) identifier (id), we had to simplify the data sequencing subsystem and assume that the pairs (unit id, measurement) define each a distinct sensor measurement.

Training Dataset

For the construction of the training dataset, we used a subset of the entries that are classified as "normal". We excluded the entries that contain apparent erroneous measurements, in order to keep the HMM training process as accurate as possible. The erroneous measurements are probably the result of a sensor malfunction or network error. Also, it is commonly-acceptable that the training process is not performed in real time but rather off-line and based on pre-processed data. Hence, the training dataset should not contain apparently faulty packets. We also performed quantization (rounding) of the measurements in order to further enhance the accuracy of the training process for the data subsystem. The exact rounding of each value is dependent on the range of the readings for each device.

We used only a subset of the normal traffic as a training dataset, in order to measure the efficiency of our system in classifying normal data as such and evaluate the false positive probability. This traffic was not used afterwards during the detection phase.

Experimental Setup

For the experiment implementation, we used the machine learning framework Accord [START_REF]Accord.NET: Accord.NET Machine Learning Framework[END_REF]. Accord provides a well-tested and documented library for constructing various types of HMMs, training them using the Baum-Welch learning algorithm and evaluating the log-likelihood that they generate a given sequence, using the Forward-Backward algorithm. Since the datasets were already available in text format, there was no need for actual packet capture and manipulation for the purposes of this experiment.

We note that a complete implementation of our system requires the use of an established NIDS (e.g., snort! [START_REF]Cisco: Snort[END_REF]) and the implementation of the subsystems as a preprocessor that runs before the normal detection engine but once the packet is decoded.

Our initial experiments showed that the water and the gas datasets produce similar results. Therefore, we will present in the next Section only the results from the water pipeline. On the other hand, the electric data lacks information about the header values on each entry and gives only the measurements from the 132 sensors. Since our system relies on both the header and the payload data, we opted not to use this dataset in the evaluation.

Results and Discussion

In this section, we will present the experimental results and provide some insights regarding the use of HMMs in detecting network attacks in ICS environments. We first showcase the operation of the two subsystems and then present the overall evaluation of the system in terms of detection efficiency. Then, we present a comparison of the results against already established algorithms that have been tried on the same dataset.

Operation Scenarios

Figure 3 depicts a time window during which an NMRI attack takes place. One of the outcomes of this attack is that the sensor measurements are skewed to the extent that they cross the boundaries of a normal operation. In the first part of the Figure, the sensor measurements as taken from the dataset are shown; the effect of the attack is clearly identifiable between the samples 36 and 67. In the second part of the Figure, the estimations by the data subsystem are depicted as a series of likelihoods for each entry (the exponent of the log-likelihood that the subsystem outputs). The likelihood becomes zero during the attack. This piece of information can be used as an alert signal from the data subsystem, as it correctly identifies one of the outcomes of the attack.

It might be the case that the effect of this NMRI-type attack, i.e., the skewing of the measurements, is an unintended consequence of the way the dataset was compiled in first place. We note that i) only few of the attacks in the dataset have any effect on the actual sensor measurements and ii) we evaluate the effectiveness of both the subsystems in our system. Thus, we include this data skewness as an attack indicator for the purpose of the experiments. Such manipulations of the readings are common in attack scenarios where an outsider tampers the information in-transit rather than directly in the sending system.

Figure 4 depicts a time window during which a Recon attack takes place. While this attack is active, various header fields deviate from their "normal" values, as the attacker tries to derive useful information. The first part of the Figure We note that for the case of the header values, the likelihoods during normal operation are more or less stable, while for the case of the data values (e.g., those shown in Figure 3), the likelihoods exhibit a wider distribution. However, in both cases the likelihood drops to almost zero during the attacks in both cases. Still, there are scenarios where the likelihood does fall a few orders of magnitude compared to normal traffic but does not reach zero. These facts affect the selection of a threshold value for denoting an abnormal behavior. The threshold for the data subsystem needs to be set after the training procedure and upon careful examination of the system's output (likelihoods) during normal operation.

Results

Classification Efficiency The efficiency of the system in correctly classifying normal and attack traffic for the whole dataset is summarized in Table 1. Line one and two depict the actual number of entries for each attack vector (0-7) and the number of entries that are correctly classified. Line three depicts the classification Fig. 4. The attack and detection graph under a Reconnaissance attack efficiency as a percentage for each attack vector. The "All" column contains the overall classification efficiency for all the entries (normal and attacks), while the "Attacks" column contains the classification only for the attack entries.

The classification efficiency is more than 95% for most of the attacks and the normal traffic. The classification does not succeed in identifying the CMRI and MSCI attacks. Upon further inspection, it appeared that this can be attributed to some flaws in the training dataset that allowed the HMMs to be trained to recognize such attacks as normal traffic. However, these flaws were identified by the header subsystem; the data subsystem could not identify them as the attack forced data values that are predictable but yet within the "normal" boundaries for the specific sensor they came from. Further details as well as the ramifications of this behavior are discussed in the next section.

There are only a few false positives, i.e., normal traffic classified as attack traffic, less than 1%. The false positives consist almost entirely of erroneous sensor readings or network packets. This is an expected outcome, given the preprocessing of the training dataset. It can be considered as a trade-off between raising the probability of correctly identifying actual attacks and raising the probability of generating false positives.

Comparisons The dataset we used for the evaluation of our system has been used extensively as a reference dataset for evaluating a wide range of machine learning algorithms [START_REF] Hsu | Mississippi state university project report -SCADA anomaly detection project summary[END_REF]. The applicability of these algorithms for anomaly detection in the ICS environment is studied in [START_REF] Beaver | An Evaluation of Machine Learning Methods to Detect Malicious SCADA Communications[END_REF]. We compare the efficiency of our approach with the published study in Table 2. While not all the algorithms are directly comparable with our approach, the efficiency of the latter is directly comparable to most of them.

In the case of a DoS attack, 16 out of the 34 algorithms have less than 90% accuracy, while our approach reaches 99%. During Recon, MPCI, and MFCI attacks, almost all algorithms produce nearly perfect results. The case of CMRI and MSCI is an area of future improvement for our system, while they can be handled by most the evaluated algorithms. In contrast, the NMRI attack is a hard case for 14 algorithms, while it can be easily detected by our approach. All the algorithms and our approach as well exhibit a very low number of false positives in all cases.

It is clear that our approach gives comparable results to the most effective machine learning algorithms while using only the information on each individual sample without the need of correlation of multiple samples of the same traffic flow. It is also clear that it is unable to detect all the attack vectors within the dataset. A discussion on why those attack vectors eluded detection and how this can be remedied is found in the next section.

Discussion

The approach we propose exploits the unique characteristics of an ICS environment and is able to identify most of the attacks presented in the reference datasets. The detection rate is comparable to already-tested machine learning algorithms and through careful adjustment of the training data and the HMM parameters, this rate can be further enhanced. As an example, the detection rate for the NMRI attack has doubled by eliminating easily identifiable erroneous data from the training set. Also, system design parameters, such as the number of parallel HMMs and the number of hidden states can affect the efficiency of the overall system.

We highlight that our proposed approach relies only on per-packet information and needs not to correlate multiple packets on the same network stream. This makes the system suitable for real-time applications, where correlation of multiple packets can adversely effect the speed of detection. It also allows it to be deployed in data storage constrained environments due to non existent storage requirements. Considering also the case of low rate (or stealthy) attacks, the system is able to detect such an attack without the need of a large number of packets that are part of the attack.

On the topic of the training data, we see that the proposed system exhibits increased sensitivity to errors or malicious activities during the preparation of the training data. As an example, our system was unable to detect the CMRI attack; this can be mostly credited to the fact that a limited amount of normal data exhibited the same pattern, probably due to some network error. This fact remained unnoticed during the preparation phase of the training set, which in turn resulted in the less-optimal training of the system's parameters. Hence, we highlight the importance of having access to carefully-inspected and validated reference datasets.

The reference datasets we used for our evaluation exhibit some limitations that might affect the applicability of our approach in real-world scenarios. Such limitations include the lack of information for the lower-than-IP network layers and that the measurements come from only one sensor node. We hope that more detailed datasets become publicly available for the benefit of the research community and the industry practice alike. We consider as an interesting enhancement for the detection itself to incorporate information regarding the actions performed by the SCADA operators themselves; such information can be utilized to detect suspicious traffic, which is a result of a malicious operators' actions.

As it has been raised many time in the research literature already, an anomalybased NIDS cannot effectively capture the whole picture of the complex ICS system under attack. It is better to integrate it in a defense-in-depth strategy, combined with a signature-based IDS for known attacks; this would speed up more the detection capabilities and provide more fine-grained information under specific attacks. Furthermore, this integration could significantly reduce the number of fake alerts (false positives) for the SCADA operator and contribute towards a more comprehensive reporting system that can present the alerts in a meaningful for the SCADA operator context.

Conclusions and Future Work

In this paper, we presented a novel approach for an HMM-based NIDS. Our approach exploits the unique characteristics of the ICS environment. We evaluate the efficiency of our approach using reference datasets taken from a real-world industrial system. These datasets contain a diverse set of attack vectors allowing for the evaluation of our approach under realistic operation scenarios.

The proposed system succeeds in detecting most of the attack vectors, both targeting application logic via payload information (i.e., the sensor measurements) and network logic via header information. We evaluated the detection rate and compared the efficiency of our approach with a large set of algorithms available in the literature. The detection rate is directly comparable with the latter and can further improved by tuning the system parameters and the quality of the training set.

More importantly, the proposed system, in contrast to other approaches, can produce the results on a per-packet basis, without needing to correlate samples with historical traffic information. This makes it more suitable for real-time applications and high-speed or large-scale environments (high traffic volumes). Also, for detecting low-rate, stealthy attacks, that are often used as part of advanced persistent threats (APTs) against critical systems and infrastructures.

An interesting direction for future work includes the integration, if possible, of information related to actions performed by SCADA operators that can result unexpected (anomalous) traffic. Also, the integration of our approach with a signature-based IDS. Also, a study on the impact of the basic design parameters (number of parallel HMMs, number of hidden states, etc) on the overall performance of the system is a mandatory step towards its adoption and deployment in real-time critical ICS. Last but not least, we consider necessary to extend the scope of the experiments using more diverse datasets, if they become publicly-available, which should incorporate a larger ICS environment, including more network segments, ICS devices, and sensors.

Fig. 1 .

 1 Fig. 1. System Architecture

Fig. 3 .

 3 Fig. 3. Attack and detection under an NMRI attack

Table 1 .

 1 Detection accuracy

	Classification Normal NMRI CMRI MSCI MPCI MFCI DoS Recon	All Attacks
	Actual	19,503 1,198 1,457 209	410 155 135 4,132 27,199 7,696
	Detected	19,424 1,159	0	0	389 155 134 4,132 25,393 5,969
	Percentage (%)	99.6 96.7 0.00 0.00 94.9 100 99.3	100 93.4	77.6

Table 2 .

 2 Comparisons with known machine learning algorithms (as reported in[START_REF] Hsu | Mississippi state university project report -SCADA anomaly detection project summary[END_REF])

	Algorithm	Normal(0) NMRI(1) CMRI(2) MSCI(3) MPCI(4) MFCI(5) DOS(6) Recon(7)
	Proposed and Evaluated System	100%	97%	0%	0%	95%	100%	99%	100%
	Best First Decision Tree(BFTree)	100%	97%	99%	87%	99%	95%	95%	100%
	Decision Stump	99%	0%	0%	0%	0%	0%	0%	100%
	FaultTree(FT)	100%	94%	100%	93%	99%	95%	96%	100%
	J48 Decision Tree	100%	95%	100%	90%	99%	73%	91%	100%
	J48Graft Decision Tree	100%	95%	100%	89%	99%	68%	88%	100%
	Logiboost Alternating Decision Tree(LADTree) 100%	94%	99%	93%	99%	0%	73%	100%
	Logistic Model Tree(LMT)	100%	86%	100%	93%	99%	95%	93%	100%
	Logistic Regression	100%	4%	99%	93%	99%	95%	67%	100%
	Multilayer Perceptron	98%	2%	99%	93%	99%	95%	68%	100%
	Nave Bayes Tree(NBTree)	100%	96%	99%	93%	98%	95%	95%	100%
	Radial Basis Function Network(RBFNetwork) 98%	1%	99%	93%	99%	95%	88%	100%
	RandomErrorPruning Tree(REPTree)	100%	95%	100%	90%	99%	95%	95%	100%
	RandomForrest	100%	96%	100%	90%	99%	93%	93%	100%
	RandomTree	99%	96%	100%	90%	98%	81%	91%	100%
	SimpleCart	100%	96%	100%	88%	99%	95%	94%	100%
	SimpleLogistic	98%	36%	99%	93%	99%	95%	68%	100%
	Sequential Minimal Optimization(SMO)	98%	1%	99%	93%	99%	73%	44%	100%
	BayesNet	98%	98%	95%	97%	100%	100%	99%	100%
	ComplementNaiveBayes	100%	0%	0%	0%	29%	100%	0%	100%
	DMNBtext	100%	0%	0%	0%	44%	100%	0%	100%
	NaiveBayes	43%	0%	99%	97%	99%	100%	96%	100%
	NavieBayesMultinomial	100%	0%	0%	97%	81%	100%	39%	100%
	NaiveBayesMultinomialUpdateable	100%	0%	0%	97%	81%	100%	39%	100%
	NaiveBayesSimple	0%	95%	98%	56%	62%	0%	0%	2%
	NaiveBayesUpdateable	43%	0%	99%	97%	99%	100%	96%	100%
	ConjunctiveRule	100%	0%	0%	0%	0%	0%	0%	100%
	DecisionTable	98%	98%	95%	94%	98%	95%	91%	100%
	DTNB	98%	98%	95%	97%	99%	100%	100% 100%
	Jrip	99%	98%	94%	97%	99%	100%	100% 100%
	Nnge	97%	97%	75%	97%	99%	100%	97%	100%
	OneR	97%	98%	95%	0%	0%	0%	0%	100%
	PART	99%	98%	95%	97%	99%	100%	100% 100%
	Ridor	99%	98%	94%	97%	99%	100%	100% 100%
	ZeroR	0%	0%	0%	0%	0%	0%	0%	0%

Acknowledgements. This work was partially supported by the GSRT Action "KRIPIS" of Greece with national and EU funds in the context of the research project "ISRTDI" and the COMET K1-Centres programme line of the Austrian Research Promotion Agency (FFG).


Panagiotis Papadopoulos

Elias Athanasopoulos

Eleni Kosta

George Siganos

Angelos D Keromytis

Evangelos P Markatos

Provable Network Activity for Protecting Users against False Accusation

With the proliferation of the World Wide Web, data traces that correspond to users' network activity can be collected by several Internet actors, including (i) web sites, (ii) smartphone apps, and even (iii) Internet Service Providers. Given that the collection and storage of these data are beyond the control of the end user, these data traces can be easily manipulated, if not, tampered with. The result of such manipulated digital traces can be severe: Innocent users can be shamed or even wrongfully accused of carrying out illegal transactions.

To eliminate these potential accusations on innocent users, we introduce Provable Network Activity (PNA): a framework with which the ISPs can give the end users control of their stored traces. The framework guarantees that the information collected for the end users is accurate and will remain accurate for as long as it is stored. Our implementation and preliminary evaluation suggest that PNA is fast, easy to deploy, and introduces zero network latency to the end clients.

Introduction

Over the past few years the degree to which computers are involved in evidence collection for crime and security investigations has profoundly changed. A couple of decades ago there were few cases that could be associated with cyber crime. Nowadays, there is hardly ever a case that does not involve a computer or a smartphone. Data from such devices are so important that even the FBI [START_REF]Digital Trends Staff: Apple vs. the FBI: A complete timeline of the war over tech encryption[END_REF] or the government's prosecutors [START_REF] Kravets | Twitter reluctantly coughs up occupy protesters data[END_REF] want to get access to them almost at any cost.

Unfortunately, despite their importance, data collected by our digital infrastructure today are not necessarily trustworthy. Indeed, malicious attackers or even rogue insiders may tamper with the process of collecting and/or storing data and may add fake data about individual users. Such fake data may later be used to ridicule and slander users, or worse, accuse them of questionable or even illegal activities. Although fake digital evidence usually does not stand in a court of law, it is often enough to send people to jail [7].

In this paper we propose that data collection processes should actively involve the users concerned. We advocate that the users should not only give their consent in all data collections, but should also make sure that the collected data are accurate and will always remain accurate for as long as they are stored. To do so, we involve the user in every step of the process: (i) users collect, (ii) users double check, (iii) users sign, and finally, (iv) users encrypt the collected data.

Our proposal is Provable Network Activity (PNA): an architecture that enables both clients and ISPs to collaborate in the data collection process and make sure that the collected data are accurate. PNA works as follows:

-A client who wants to gain control of her traffic and data, and ensure their authenticity can simply register to the service by providing her ISP with her public key. Then, she installs a software responsible for signing all outgoing traffic, before it is sent to the ISP, with her private key 6 . -If the ISP receives traffic from the client without receiving the corresponding signature, the traffic is blocked7 . -If the ISP receives a valid signature, it keeps a record of the access in its log.

Threat Model

In this paper we focus on protecting innocent users from false accusations based on fake network logs. We assume that the user's access logs have been collected by a local ISP (or similar service). We also assume that, at some point in time (either during the collection process or later), the logs were tampered with, maybe by intruders, or even by insiders.

More precisely, the setup is composed by three different entities: (i) the user U , (ii) the last-mile ISP I, and (iii) an web site s hosting offensive or even illegal content. We make the following assumptions:

-user U never accessed web site s (via ISP I).

-although ISP I is considered generally trusted, its data logs may be tampered with to show that U has accessed s [START_REF]Insider Attack and Cyber Security -Beyond the Hacker[END_REF].

Provable Network Activity

Traditional data collection has been done by the ISPs without consulting the users at all. That is, ISPs collected data about the users without the users being able to verify that the collected data are correct and that the data will remain correct for as long as they are stored. We advocate that this approach should change. Data should not be collected without the user being able to verify that the data are (and will remain) correct. To bring the user back in the game, PNA proposes that the collected data (i) should be reviewed by a user's application (ii) should be signed by the user, and (iii) should be encrypted by the user. Any attempts to tamper with the data will stumble upon the signing and encryption process which becomes impossible (or obviously detectable) without the user's cryptographic keys.

Passive Traffic Monitor

Signature Server

Connection Server

Logging Server

Client's traffic

Signatures Network Flows

Fig. 1. Overview of the PNA components and their interconnections on the ISP side.

Client Side

Key Management. The client is responsible for generating a public-private key pair, and is responsible for the security of her private key8 . The client at any time can replace her public-private key pair, but it is her responsibility to store the old private key and update the public key provided to the provider. Daemon. A daemon runs in the client's computer and passively monitors all outgoing traffic. For each outgoing flow a signature is computed. The signature is computed on the tuple (destination IP address, port number, protocol, timestamp) by first using SHA and then encrypting with the user's private key. The daemon then sends the tuple plus the signature of the tuple to the ISP's server 9 . This signature is a proof generated by the client that the client did make this network connection. If the ISP does not receive such a proof, it will not allow the connection to be established.

ISP Side

For each client connection (e.g. network flow), the ISP expects to receive a signature from the client. If the signature is received, the connection is allowed to proceed and a log record is generated. If the signature is not received, or is not valid, the connection is not allowed to proceed. The infrastructure on the ISP side consists of the following entities: (i) a Passive Traffic Monitor, (ii) a Signature Server that is interacting with the client-side, (iii) a Connection Server that maintains the connections and enforces policy, and (iv) a Logging Server that provides persistence in a privacy-preserving way.

-Passive Traffic Monitor. The ISP passively monitors all traffic to identify new flows. For each new flow identified, the monitor creates a new record to characterize the flow, and sends the record to the Connection Server that handles the policy. -Signature Server. The Signature Server acts as a gateway to the system. It receives signatures from the client side and forwards them to the Connection Server. -Connection Server. The Connection Server collects information (i) from the Passive Traffic Monitor and (ii) from the Signature Server, and makes sure that for each flow received by the Passive Traffic Monitor a corresponding signature is received from the Signature Server. If a signature is not received (or is not valid) for a given flow, the flow is blocked/terminated. -Logging Server. The Logging Server is responsible for storing all signatures for each subscriber.

Privacy-Preserving Logging

The approach described so far keeps a record only of the IP addresses really accessed by the client:

-If an attacker tries to add a record to the log, this record will just not have the client's signature, and therefore it will be easily singled out as fake.

-If the client tries to access an IP address without providing a signed record for this access, the ISP will clock/reset the access.

Therefore, the log will be an always accurate record of the user's activity. Unfortunately, keeping the log as described so far may seriously violate the user's privacy. Indeed, if the log is leaked, then all the user's accesses will be easily visible. Encrypting the log with an ISP's key does not help either. A malicious attacker may accuse the client of illegal activity just to force the client to reveal the entire log in order to prove that the illegal activity is not there. Such an approach will help the user demonstrate her innocence, at the price of her privacy. It seems therefore that there is a dilemma the user needs to choose from: either demonstrate her innocence or protect her privacy. In this paper we believe that this is a false dilemma. We believe we can do both: i.e. both demonstrate the client's innocence and protect the client's privacy at the same time. To do so, instead of keeping each signed record, we keep a hash of it. We use bcrypt [START_REF] Provos | A future-adaptive password scheme[END_REF] in order to hash all network signatures.

Implementation

PNA Prototype

We implemented PNA in Linux using libpcap a building block for capturing network traffic, and OpenSSL a module that provides all cryptographic opera-tions. The implementation was rather straightforward: all software is written in C++ totalling around 2,000 lines of code.

Client-side implementation A Linux-based host runs the code for the client: a DSL subscriber. This host runs the daemon software as we described in Section 3.1. The daemon initially connects to a predefined port of a Linux-based server, which is run by the ISP. In parallel, the daemon monitors all TCP/UDP traffic and captures (i) all TCP packets having the TCP-SYN flag on and (ii) all UDP packets. For each TCP-SYN packet and for each UDP packet that starts a new flow, the client daemon generates a signature of the packet with the user's private key and sends it to the server using the established connection.

ISP-side implementation At ISP side, the server runs the passive traffic monitor, as we described in Section 3.2, for capturing all incoming traffic and infer (i) new TCP flows (by inspecting the TCP-SYN flag), and (ii) new UDP flows. The monitor uses Redis, an open source in-memory key-value store for maintaining all identified UDP flows. In addition, it also runs the signature module, which listens to a predefined port for incoming signatures by the client. The server verifies each incoming signature, by decrypting it using the user's public key. If the signature is valid, it is forwarded to the logging server and it is stored using bcrypt [START_REF] Provos | A future-adaptive password scheme[END_REF]. Otherwise, (i) if the signature is not valid, or (ii) if the signature is not sent by the client, or (iii) if the signature arrives too late, the connection is terminated. TCP/IP connections area terminated by an explicit TCP-RST to the user's host. For UDP connections, the flow is just blocked.

For the asymmetric encryption/decryption, the RSA algorithm is used with PKCS1 padding as provided by OpenSSL). The length of the keys is 2048 bits. For hashing before encrypting we use SHA512 as provided by OpenSSL. For bcrypt we use the implementation as provided by the original paper [START_REF] Provos | A future-adaptive password scheme[END_REF].

Evaluation

Client Side

The cryptographic overhead is the only computational overhead we impose on the client side. More specifically, the client needs to sign every new flow and send this signature to the ISP in time no more than T. To quantify the latency imposed by this required cryptographic operations, we perform 10,000 privatekey encryptions for a testing tuple and we measure the average latency. In this experiment we use OpenSSL's RSA implementation with keys of length of 2048 bits in two devices: a Linux desktop and a Mac OS laptop. In both cases, the overhead per encryption was less than 10 ms. This means that a typical computer can handle more than a hundred of new flows (i.e. new signatures) per second. Fig. 2. Passive Monitor Performance. We see that even for 5 million flows, the server requires less that 1 GB of memory.

ISP Side

Passive Traffic Monitor (PTM). As we described in previous section, PTM is responsible for identifying new network flows. While this operation is straightforward when the flows are TCP, in the case of UDP flows it is not that trivial.

For each UDP packet, a query needs to be sent to the key-value store to check if this UDP flow has been encountered in the past. Given this complexity, we focus on the UDP flows identification, which evidently is the most expensive part of this component.

To measure the performance of PTM, we simulate traffic sent from client to ISP, containing various number UDP flows (ranging from 100K to 5M). The UDP packets of these flows are distributed using a long-tail distribution (80% of the packets are distributed to 20% of the flows). In Figure 2, we can see the results, where it seems that our server is able to process more than 40K reqs/sec.

In the same experiment, we measure the memory requirements of our system. In Figure 2, we can see that, as expected, the memory consumption demands grow linearly with the number of UDP flows. Indeed, we see that even if we have as many as 5M UDP flows we probably need less than 1 GB of memory to store all data. Of course, this is a trivial amount of memory for contemporary servers.

Logging Server. This is the component responsible for securely storing the signatures in a privacy-preserving fashion. The main bottleneck in the logging server is the computation of the hash key using bcrypt. To measure this computation overhead we stress a desktop equipped with one Quad-core Intel processor at 2.4G to identify how many bcrypt operations per second can achieve and in Figure 3 we plot the results. As we see, we can have more than 2000 bcrypt operations per second, and consequently, we can process more than 2000 new flows per second. Additionally, recall that it is an off-line operation, and thus does not increase the typical packet routing operation of the ISP.

It is worth mentioning at this point, that bcrypt wastes computational resources on purpose for prohibiting massive in-parallel cracking of the generated hash products and resist dictionary attacks. To achieve that, bcrypt uses cost parameter. In our experiment, we explore how this parameter affects the overall calculation performance by testing various values of cost. As we can see, up to cost=4, the single CPU can still perform more than 2, 000 operations per second. As a result, even when using a cost value able to sky-rocket the amount of work required by an attacker to reveal the network logs, it is not capable of degrading the system's performance.

Related Work

Pretty Good Packet Authentication (PGPA) [START_REF] Haeberlen | Pretty good packet authentication[END_REF]) is a system that hashes all user's outgoing traffic and stores it to a device. The device must be placed between client and ISP: either towards the user's side, i.e. in her household, or it can be hosted by the ISP. Packet Attestation (PA) [START_REF] Haeberlen | Fighting Cybercrime with Packet Attestation[END_REF] suggests installing special monitors, independent of the current Internet's routing infrastructure, in every Autonomous System (AS). These monitors hash and collect all user traffic, and they can attest if the traffic is authentic under a particular case, where a user is accused for receiving offensive traffic. Clue [START_REF] Afanasyev | Privacy-preserving network forensics[END_REF] attempts to bring the notion of physical evidence, such as DNA, in the digital world. More precisely, Clue uses Group Signatures [3] for delivering a scheme, where each Internet packet can be attributed to its original source.

All these systems propose major reconstruction of fundamental parts of today's Internet. We agree with a large fraction of these proposals and we believe that a clean-slate design will terminate a rich collection of problems that we exhibit today. However, deployment is not always trivial. Changing fundamental Internet-core concepts, such as routing or addressing, is really hard.

Conclusion

In this paper we designed, implemented, and evaluated PNA, a framework which gives end users control of their own traces as they recorded by their last-mile ISP. PNA empowers users with the ability to double check the data collected about them and to make sure that these collected data are correct and will remain correct for as long as they are stored in the ISP's logs. To do so, users explicitly sign each network flow. The ISP makes sure that each network flow is accompanied by the associated signature. If a signature is not received, the ISP blocks the flow. To ensure the correctness of the log, the ISP stores both the network flow records end their associated signatures. In this way, tampering with the stored data is extremely difficult: even if attackers manage to add records to the log, they will not be able to add the corresponding signatures. Our preliminary implementation and evaluation shows that our system does not impose any extra latency to the end user and has low computational requirements.

Fig. 3 .

 3 Fig.3. Bcrypt performance as a function of the value of cost. Up to cost=4, the single CPU can perform more than 2, 000 operations per second.

The exact details of the key management process is beyond the scope of this paper.

Note that this service works on an opt-in basis.

For simplicity, we describe our approach as if the user has one device, but it can be easily generalized to include several devices and users, as well

Note, that we do not use the source IP/port, since usually NAT/Proxies overwrite the source part[START_REF] Clayton | Mobile internet access data retention (not!)[END_REF].

Acknowledgements. This work was supported in part by the project GCC, funded by the Prevention of and Fight against Crime Programme of the European Commission -Directorate-General Home Affairs under Grant Agreement HOME/2011/ISEC/AG/INT/4000002166. This project has received funding from the European Unions Horizon 2020 research and innovation programme under the Marie Skodowska-Curie grant agreement No 690972. This publication reflects the views only of the authors, and the European Commission cannot be held responsible for any use which may be made of the information contained therein.


Ahmad Sabouri
email: ahmad.sabouri@m-chair.de

The Effect of Semantic Elaboration on the Perceived Security and Privacy Risk of Privacy-ABCs -An Empirical Experiment

Privacy-ABCs are elegant techniques to deliver secure yet privacy-enhanced authentication solutions. The cryptography behind them enables new capabilities, such as selective disclosure of attributes, set membership, and predicates over attributes, which many of them were never experienced by typical users before. Even if the users intuitively accept the existence of such features, they may not be still ready to perceive the semantic of such a proof within the context of authentication. In this work, we argue that additional information is necessary to support the user understand the semantic of their operations. We present the results of our empirical experiment on investigating the effect of providing such a support during authentication with Privacy-ABCs on the perceived security and privacy risk of the users.

Introduction

The research community has been trying to enhance the strong authentication techniques to respect the privacy of the users. More specifically, efforts have been dedicated to design schemes for providing data minimization, unlinkability and untraceability during an authentication session. In this regard, Privacypreserving Attribute-based Credentials (Privacy-ABCs), also known as anonymous credentials, have been in the focus of various recent research projects such as Prime, PrimeLife, FutureID, and ABC4Trust. From the different flavours of Privacy-ABCs, the IBM Idemix and Microsoft U-Prove are among the most prominent ones. Privacy-ABCs are cryptographically proven to be unlinkable and untraceable. Thus, the service providers cannot tell whether two tokens were generated by the same user or not. Also the issuers cannot trace tokens back to the issuance phase and the person behind them, unless the disclosed attributes contains some identifying information.

Privacy-ABCs come with new capabilities such as selective disclosure of attributes, predicate over attributes, and proof of set membership, which mainly were never experienced by the users in any of the previous authentication schemes. For instance, using predicates over attributes, a user is able to prove facts such as less than or greater than about their attributes without actually disclosing the attribute value itself. Taking the example of our experiment, a service provider can request a "German" user to prove if her postal code is in the range of 59999 to 61000. In this way, the service provider learns that the user is living in the city of Frankfurt am Main but it does not learn in which district of the city, which could possibly cause leak of information about the financial status. Some scholars [8] reported that users lack an appropriate mental model for such technologies regarding even simpler features, such as combining individual attributes from different credentials in a single authentication. Consequently, we argue in this paper that without additional support regarding the semantic of their actions, the users may not be appropriately influenced by such privacy-enhancing technology regarding their security and privacy risk perception.

In this paper, we demonstrate that the users' perception of security and privacy risks changes, when they are supported with additional information regarding the semantic of their proofs during authentication with Privacy-ABCs. Our findings are based on the results of an empirical experiment with 80 users. We compared the perceived security and privacy risk of two groups of participants who received different treatments during their practice of authentication with Privacy-ABCs. For this experiment, we first implemented an experiment platform where the user could practice authentication with Privacy-ABCs. In the next step, we used the platform to conduct the experiment with the users and afterwards measured their perceived security and privacy risk using part of a systematically developed measurement instrument (cf. Appendix A).

In the rest of this paper, we review the previously conducted related research in Section 2. Later on, we explain the details of our experiment in Section 3. The results and implications of our experiment are provided in Section 4. In the end, we conclude the paper in Section 5.

Related Works

To the best of our knowledge, there have not been many studies in the literature concerning the human aspects of Privacy-ABCs. Wästlund et. al. [8] were the first ones who reported about the challenges to design user-friendly interfaces that convey the privacy benefits of Privacy-ABCs to users. They observed that users were still unfamiliar with the new and rather complex concept of Privacy-ABCs, since no obvious real-world analogies existed that could help them create the correct mental models. Benenson et al. [2,3] investigated one of the ABC4Trust trials using the Technology Acceptance Model (TAM) [4]. Benenson et. al. discovered significant negative correlation of Perceived Risk with the Intention to Use, the Perceived Usefulness for the first and secondary goals, the Perceived Ease of Use and the Trust. In the same study, they found the Perceived Risk to be dependent to Perceived Anonymity.

An experts survey was conducted in [7] to predict the factors influencing adoption of Privacy-ABCs. The results indicate that the complexity for the user is among the most important factors. In our study, we try to reduce the complex- ity by providing additional support for the semantic analysis of the presentation policies (which are the artefact describing the requested attributes and proofs by service providers) and observe the effect on the perceived security and privacy risks, because perceived risk is reported to be particularly important for the adoption of e-services [6]. The method to influence the perceived risk was chosen based on the recommendations of the warning theory. The warning theory suggests that more specific information about hazards and consequences can reduce uncertainty and enable people to make better-informed cost-benefit trade-off decisions regarding the need to comply [5]. Bal [1] extended this design theory to the field of information privacy warning design by experimentally investigating the effects of explicitness in privacy warnings on individuals' perceived risk and trustworthiness of smartphone apps and observed significant effects.

Experiment Design

The experiment was designed to evaluate the effect of additional semantic analysis of the presentation policy on the perceived privacy risk by end users. We first implemented the necessary software components to enable authentication with Privacy-ABCs. We called our mock-up Privacy-ABC identity card as "ID+" and let the users try it in our experiment portal, "Politiks.eu". We also adjusted our developed questionnaire for the perceived security and privacy risk to reflect our experiment environment (the details of developing the questionnaire are presented in Appendix A). We used a 7-points Likert scale in the questionnaire ranging from Strongly disagree to Strongly agree. Table 1 demonstrates the final questionnaire for our experiment. Then, we conducted the experiment through the network of the students at the Goethe University Frankfurt in October and November 2015. In the following sections, we explain the details of our process.

Experiment Platform Setup

A precondition for our experiment was to set up a platform where scenarios for authenticating with Privacy-ABCs could be tried out. We decided to develop a mock-up prototype which presents the workflow of authenticating with Privacy-ABCs with a more friendly interface than the ABC4Trust reference implementation and better integration into the web browser. We designed the User Agent as a Firefox plugin and integrate it into the browser.We added a button, called "ID" into the toolbar of the Firefox browser, which upon clicking, it would show the users' identity credential in case the smartcard was connected to the computer. In the experiment, the authentication was emulated, therefore, the smart card was employed to provide the feeling of a real process but the users' attributes were actually stored in the browser configurations. A small Java application was developed to run in the background in order to check the status of the smartcard, which allowed the browser plugin to query the status via a Restful web-service call. The plugin was designed to attach specific Javascript codes to the html content of the web-page when opening the experiment portal URL. The Javascript codes would provide the possibility of communicating with the plugin in order to invoke the GUI for authentication with Privacy-ABCs. When a button on the web-page triggers login with Privacy-ABCs, the message is communicated to the plugin. The GUI would pop up as small window next to the "ID" button if the smart card is present. The window guides the user through the steps of authentication and upon completion the user is redirected to the requested page.

Conducting the Experiment

The experiment was conducted within the student community of the Goethe university Frankfurt. The only limitation was to limit the age to be between 18 and 34. The participants were randomly assigned to one of the two envisioned groups, the "control group" and the the "experiment group". All participants received a brief introduction of ID+ and its privacy-enhancing features. Afterwards, the participants were given a smartcard and were asked to open Firefox and browse to the experiment portal, "http://politiks.eu". In order to urge the Fig. 2. Experiment Process need for privacy, we decided the deliver political discussion as the main content of the portal. Two forums were initiated in the portal; one about mayoral election in the city of Frankfurt and one about legalizing drugs. Each forum required the user to authenticate with her ID+ in order to get access to the discussion. The process of authenticating with ID+ for the two groups are shown in Figure 2. Upon clicking on "Login with ID+" the respective GUI would pop up to guide the participant through the authentication process. The Frankfurt mayoral election forum asked the users to deliver a proof for "Your Postal code is between 59999 and 61000" and the forum on legalizing drugs, would request the users a proof of "Your birth date is before the 01.01.1997". The former policy semantically means that the participant is living in the Frankfurt am Main area as the postal code is following 60xxx format, and therefore the forum ensures that she is a stakeholder. The latter also proves that the participant is older than 18 (by the time of the experiment) and consequently allowed to discuss about drugs. A semantic analysis of the given access policy was presented to the participants of the "experiment group" and not to the "control group". This additional step was the only difference of the process between the two groups and it was introduced as an additional transparency mechanism which could influence the perceived privacy risk of the users. The participants were guided through a task list (presented in Figure 1) to interact with the portal. In the end, each participant was asked to fill the questionnaire that we developed to measure their perceived security and privacy risk with regard to the use of ID+.

Results and Implications

In total 80 participants took part in the experiment, 35 female and 45 males. All the participant were between 18 and 34 years old. Regarding the education Fig. 3. Participants' Answers to the Security and Privacy Risk Questions. First Column = Control Group, Second Column = Experiment Group level, 13 had no university degree yet, 42 hold a Bachelor's degree, and 25 had Master's degree or above. We statistically analysed the questionnaire results using the IBM SPSS tool. Perceived security and privacy risk is a complex construct and can have various factors. Within the items measuring the perceived security and privacy risk, we covered various aspects namely, Linkability, Traceability, Anonymity, Security, Control, Collection, Impersonation and Unwanted Authorization.

The responses to each of the questions are demonstrated in Figure 3 We performed a Principal Component Analysis (PCA) using Varimax rotation with Kaiser Normalization on the security and privacy risk items to investigate whether all the items were loading one "total security and privacy risk" or not. To perform a PCA, the rule of thumb is to have at least 10 participants per variable, which our total number of participants met this requirements for our eight variables. As shown in Table 2, the results indicate that our eight items were loading two components (which we named C1 and C2). Consequently, we calculated component C1 as an un-weighted average of Security, Unwanted Authorization, Impersonation, Collection and Control, and also C2 as the unweighted average of Unlinkability, Untraceability and Anonymity. Regarding the reliability test, the Bartlett test indicated significant correlation and the Kaiser-Meyer-Olkin (KMO) measure verified the sampling adequacy for the analysis with KMO = .789. Moreover the Cronbach's α was calculated as 0.82 and 0.6 for C1 and C2, respectively.

After identifying the components, we compared the mean value of C1 and C2 between the control group and the experiment group using a Independent Samples T-test. As reported in Table 3, the results demonstrate statistically significant difference of C1 between the two groups, p-value 0.005, which means that the probability of the corresponding difference in the means to occur by chance is less than or equal to 0.5%. This shows that the participants of the experiment group perceived less risk (mean diff. = .725) concerning the dimensions of security and privacy covered by C1. Intuitively, the experiment group received additional explicit information with regard to the consequences of delivering the proofs requested by the portal, which made them specially perceive better control over their attributes and their collections.

Conclusion

In this work, we designed and conducted an empirical experiment with Privacy-ABCs in order to demonstrate the effect of additional supports to the users with regard to the semantic of the Privacy-ABC proofs. Privacy-ABCs enable new privacy features such as minimal disclosure, predicate over attributes, and set membership. However, users are not very familiar with those concepts and have difficulties to build a mental model of such advanced operations. We argued that additional information explaining the facts and semantics of required Privacy-ABC proofs during an authentication process has an influence on the perceived security and privacy risk of the users. We verified our hypothesis through our experiment, where we examined 80 participants in two groups and measured their perceived security and privacy risk using our systematically developed measurement instrument. Our results demonstrated that the group who received additional information about the semantic of the proofs had a statistically significant difference in some aspects of their perceived security and privacy risk. Despite following methodological approaches, the experiment was conducted through the student network of the Goethe University Frankfurt and the age of the participants were limited to 18-34 years old. Consequently, the results may not be generalizable to users who are significantly different from our sample group.

Fig. 1 .

 1 Fig. 1. User Tasks List

  . The xaxis represents the answers (1 = Strongly Disagree, 2 = Disagree, 3 = Somewhat Disagree, 4 = Neither Agree nor Disagree, 5 = Somewhat Agree, 6 = Agree, 7 = Strongly Agree). Comparing the descriptive statistical values for the answers of the control group and the experiment group, we can say both groups Somewhat Disagreed to the risk of Linkability (m c = 2.85, σ c = 1.96, m e = 2.95, σ e = 1.78). With regard to Traceability, both groups had on average a neutral perception (m c = 3.98, σ c = 1.72, m e = 3.75, σ e = 1.46. The results concerning Anonymity were almost the same for both groups and laid between Somewhat Agree and Agree (m c = 5.60, σ c = 1.67, m e = 5.50, σ e = 1.41). For Security, the experiment group demonstrated a slightly stronger disagreement compared to the control group but in general they were both around Somewhat Disagree (m c = 3.38, σ c = 1.72, m e = 2.88, σ e = 1.44). The results also indicate a slight difference concerning perception of Unwanted Authorization but the average on both groups was close to Somewhat Disagree (m c = 2.93, σ c = 1.46, m e = 2.75, σ e = 1.13). The perception of the control group was on average between Somewhat Disagree and Neutral towards Impersonation while the experiment group's perception was be-

tween

  Disagree and Somewhat Disagree (m c = 3.38, σ c = 1.78, m e = 2.40, σ e = 1.28). A similar result was observed for Collection (m c = 3.48, σ c = 1.57, m e = 2.50, σ e = 1.47), and Control (m c = 3.40, σ c = 1.53, m e = 2.40, σ e = 1.43).

Table 1 .

 1 .eu is not secure enough to be used with ID+. Security I believe using ID+ to login to Politiks.eu puts other services, which are used with ID+, at risk and enables unauthorised/unwanted actions at those other services.Unwanted Authorization I believe using ID+ to login to Politiks.eu leads to identity theft or impersonation. Impersonation I believe that my usage of ID+ to login to Politiks.eu leads to loss of privacy for me because my personal data are collected without my knowledge and consent. Collection I believe by using ID+ to login to Politiks.eu, I lose control over my personal data. Control I believe by using ID+ to login to Politiks.eu, my posts at Politiks.eu become known to the ID+ operator.Traceability Measurement Instrument for Security and Privacy Risk of using ID+ to Authenticate towards Politiks.EU

	Items	Concept Behind
	I think by using ID+ to login to Politiks.eu, my various posts at Politiks.eu become linkable together.	Linkability
	I believe by using ID+ to login to Politis.eu, I will be able to use the Politiks.eu anony-mously/pseudonymously.	Anonymity
	I think Politiks

Table 2 .

 2 Rotated Component Matrix. Rotation Method Varimax with Kaiser Normalization.

						Component
						C1	C2
			Unlinkability		.150 .736
			Anonymity (rev)	.101 .830
			Impersonation		.701 .208
			Collection		.894 .052
			Control		.887 .177
			Untraceability		.464 .470
			Unwanted Authorization .467 .448
			Security		.603 .358
		Leven's Test for
		Equality of Vari-		t-test for Equality of Means
		ance F	Sig.	t	df	Sig. (2-tailed)	Mean Diff.	Std. Error	95% Confidence Interval of the
								Diff.	Diff
									Lower	Upper
	C1 Equal variances	3.809	.055	2.887	78	.005	.72500	.25108	.22513	1.22487
	assumed
	Equal variances			2.887	73.092	.005	.72500	.25108	.22460	1.22540
	not assumed
	C2 Equal variances	3.396	.069	.030	78	.976	.00833	.27932	-.54774	.56441
	assumed
	Equal variances			.030	71.051	.976	.00833	.27932	-.54860	.56527
	not assumed

Table 3 .

 3 Independent Samples T-test

A Appendix: Developing a Measurement Instrument

Designing an appropriate and robust measurement instrument is an essential part of any experiment. One of the contributions of this paper is the systematic development of an instrument which measures multi-faceted risk of using an identity management solution to access a service. Perceived risk is theorized as being multi-dimensional [3]. Jacoby and Kaplan [5] defined the following five components of risk: financial, performance, physical, psychological, social, and the overall risk. Roselius [START_REF] Roselius | Consumer rankings of risk reduction methods[END_REF] also identified a sixth dimension called Time loss. Featherman and Pavlou [4] proposed to consider privacy risk in the context of e-commerce instead of the physical risk which seems to be very unlikely. Since then multi-faceted risk has been considered in various studies such as adoption of Internet Banking [6], initial acceptance of emerging technologies [7], and selfservice technologies and e-services [3]. Table 4 introduces the dimensions we considered in our instrument.

Dimension Definition Performance Risk

User assessment of potential performance problems and malfunctioning, transaction processing errors, etc., and therefore not delivering the service as promised.

Financial Risk

User assessment of potential financial losses due to the employment of an Identity Service Provider XXX and its login mechanism for accessing Service Provider YYY. Security & Privacy Risk User assessment of potential security violation or losses to the privacy and confidentiality of their online/offline identity, personal data, or activities Time Risk

User assessment of potential losses to convenience, time and effort caused by wasting time researching, setting up, switching and learning how to use the Identity Service Provider XXX login process.

Psychological Risk

User assessment of potential losses to their self-esteem, peace of mind or self-perception (ego) due to worrying, feeling frustrated, foolish, or stressful as a result of employing an Identity Service Provider XXX to login to the Service Provider YYY Social Risk User assessment of potential losses to their perceived status in their social group as a result of using and Identity Service Provider XXX to access the Service Provider YYY. The assessment of the probability that consumers believe that they will look foolish to important others Physical Risk

User assessment of potential losses to their health and their physical status In this work, we followed the three stages proposed by Moore and Benbasat [8] in order to develop an instrument to measure the multi-faceted risk of using an identity management solution to authenticate towards a service. The first stage aims at the identification of existing items and the creation of new ones which fit to the definition of the respective constructs.

The second stage focuses on assessing the construct validity and refining ambiguous items. This stage was done following the approach by Anderson and Gerbing [2] by a pretest assessment of the substantive validities of the measures, which is achieved by an item-sorting task. In this iterative exercise, some representatives of the population were asked to judge each item and assign it to the construct to which they think the item belongs. After carrying out each round, two indices were calculated: proportion of substantive agreement, P sa , and substantive validity coefficient, Csv. The indices range from 0.0 to 1.0 and from -1.0 to 1.0 respectively. P sa is defined as the proportion of respondents who assign an item to its intended construct. The equation for this calculation is: P sa = nc/N where nc represents the number of people assigning an item to its posited construct and N represents the total number of respondents. Csv represents the extent to which respondents assign an item to its posited construct more than to any other construct. The formula for this index is: C sv = (nc -no)/N , where nc and N are defined as before and no indicates the highest number of assignments of the item to any other construct.

Larger values for both indices show greater substantive validity and the recthreshold is 0.5. We conducted the pretest with the help of 20 participants. Even though the majority of the constructs met the threshold, we had to do some refinements in order to improve the items and remove ambiguity. The second round was performed by involving 7 participants, which verified the validity of all the constructs. Table 5 The final version of the multi-faceted risk measurement instrument is as follows:

Performance:

-Identity Service Provider XXX does not perform reliable enough to guarantee access to Service Provider YYY at anytime. (adapted from [3]) -Identity Service Provider XXX goes down (unreachable) and therefore creates problem with my access to Service Provider YYY. (adapted from [3]) -In future Identity Service Provider XXX discontinues its service and incurs trouble for me to access Service Provider. (new based on the identified risks by [1])

Financial:

-Using Identity Service Provider XXX to login to Service Provider YYY leads to financial loss for me. (adapted from [3])

-Using Identity Service Provider XXX to login to Service Provider YYY stands me to lose money. (adapted from [4]) -Using Identity Service Provider XXX to login to Service Provider YYY causes undesired/unintended withdrawal from my financial (e.g. bank) accounts. (adapted from [4])

Security and Privacy:

- -Using Identity Service Provider XXX to login to Service Provider YYY harms the way others think of me. (adapted from [3]) -Using Identity Service Provider XXX to login to Service Provider YYY leads to a loss of status and reputation for me because my friends and relatives will think less of me. (adapted from [3])

Physical:

-Logging into Service Provider YYY using Identity Service Provider XXX is not safe; i. e. may be (or become) harmful or injurious to my health. (adapted from [5]) -Using Identity Service Provider XXX to login to Service Provider YYY leads to physical harm by governmental organizations. (new) -I will get physically hurt by others if I login to Service Provider YYY using Identity Service Provider XXX. (new)


Fatma Al Maqbali

Chris J Mitchell

Password Generators: Old Ideas and New

Password generators that generate site-specific passwords on demand are an alternative to password managers. Over the last 15 years a range of such systems have been described. We propose the first general model for such systems, and critically examine options for instantiating it. The model enables an objective assessment of the design of such systems; it has also been used to sketch a possible new scheme, AutoPass, intended to incorporate the best features of the prior art while addressing many of the shortcomings of existing systems.

Introduction

Passwords remain a very widely used method for user authentication, despite widely shared concerns about the level of security they provide. There are many potential replacement technologies, including combinations of biometrics and trusted personal devices (e.g. as supported by protocols such as FIDO UAF [3]), but it seems likely that it will be some time before passwords are relegated to history. Given their current and likely future wide use, finding ways of improving the use and management of passwords remains a vitally important issue. We focus here on an important practical matter, namely how to make passwordbased user authentication to a website both more secure and more convenient.

An important class of schemes designed to ease password use are password managers (what McCarney [12] calls retrieval password managers). A password manager stores user passwords and produces them when required (e.g. by autofilling-in login pages). Passwords can be stored either locally or on a trusted server; most browsers provide a local-storage password manager. However, the shortcomings of password managers have also been widely documented (see, e.g., McCarney [12]). Passwords stored on a user platform restrict user mobility, since they are not available when a user switches platform, e.g. from a laptop to a tablet or phone. However, if passwords are stored 'in the cloud', then there is a danger of compromise through poorly configured and managed servers, [2,8,13].

An alternative approach, which we consider here, involves generating sitespecific passwords on demand from a combination of inputs, including those supplied by the user and those based on the site itself. A number of schemes have been proposed but, apart from a brief summary by McCarney [12], they have not been studied in a more general setting. The main purposes of this paper are to (a) provide a general model for password generation schemes, and (b) use the model to propose a new system combining the best features of existing schemes. This is the first time these schemes have been considered in a unified way.

Password generators simplify user password management by generating sitespecific passwords on demand from a small set of inputs. The term has also been used to describe the generation random or pseudorandom passwords which a user must remember; however, we use the term for schemes that generate a password in a repeatable way. We focus on the general properties of such schemes and options for operation. The schemes have been briefly considered previously by McCarney [12] under the name generative password managers.

A Model

A password generator is functionality on an end-user platform to support passwordbased user authentication to a remote server (assumed to be a web site). It generates, on demand, a site-unique password for use in authentication. Clearly this password also needs to be available to the web site authenticating the user; the registration step, in which the password is set up, is discussed further in section 2.3 below. A password generator has the following components.

-A set of input values is used to determine the password for a site; some must be site-specific so the generated password is site-specific. The values could be: stored (locally or online), based on characteristics of the authenticating site, user-entered, or some combination of types. -A password generation function combines the input values to generate an appropriate password. This function must meet the requirements of the authenticating web site; e.g. one web site might forbid non-alphanumeric characters in a password, whereas another might insist that a password contains at least one such character. A password generation function must therefore be customisable. -A password output method transfers the password to the authenticating site, e.g. by displaying the generated password to the user.

All this functionality needs to be implemented on the user platform. There are various possibilities for implementation, e.g. as a stand-alone application or a browser plug-in; these issues are discussed further in section 3 below.

Examples

We next briefly outline some existing proposals for password generation schemes, presented in chronological order of publication. The functional components of the various examples are considered in greater detail in section 3 below.

The Site-Specific Passwords (SSP) scheme proposed by Karp [7] in 2002/03 is one of the earliest proposed examples. It generates a site-specific password by combining a long-term (global) user master password and an easy-to-remember name for the web site, as chosen by the user. PwdHash, due to Ross et al. [14], generates a site-specific password by combining a long-term master password, data associated with the web site, and (optionally) a second global password stored on the platform. The 2005 Password Multiplier scheme of Halderman, Waters and Felten, [4], computes a site-specific password as a function of a longterm master password, the web site name, and the user name for the user at the web site concerned. Wolf and Schneider's 2006 PasswordSitter [15] scheme generates a site-specific password as a function of a long-term master password, the user identity, the application/service name, and some configurable parameters. Passpet, due to Yee and Sitaker [16] and also published in 2006, takes a very similar approach to SSP, i.e. the site-specific password is a function of a long-term master password and a user-chosen name for the web site known as a petname. Each petname has an associated icon, which is automatically displayed to the user and is intended to reduce the risk of phishing attacks. ObPwd, due to Mannan et al. [START_REF] Biddle | User study, analysis, and usable security of passwords based on digital objects[END_REF]9,10,11], first surfaced in 2008. It takes a somewhat different approach by generating a site-specific password as a function of a user-selected (site-specific) object (e.g. a file), together with a number of optional parameters, including a long-term master password (referred to as a salt ), and the web site URL. Finally, PALPAS was published in 2015 [5]. PALPAS generates passwords complying with site-specific requirements using server-provided password policy data, a stored secret value (the seed ), and a site-and user-specific secret value (the salt ) that is synchronised across all the user devices using the server.

Registration and Configuration

We only consider schemes whose operation is completely transparent to the authenticating website. As a result, the 'normal' website registration procedure, where the user selects a password and sends it to the site, is assumed to be used. This means that the password generation process needs to be in place before the registration procedure, or the introduction of a password generator will require the user to modify their password. A possible way of avoiding the need to change passwords is examined in section 4 below.

A password generator may need to store configuration data. Such data can be divided into: global configuration data, i.e. values unique to the user, used to help generate all passwords for that user, and site-specific configuration data, i.e. values used to help generate a password for a specific site. Not all schemes use configuration data, although building a workable system without at least some global configuration data seems challenging. However, the use of configuration data is clearly a major barrier to portability. That is, for a user with multiple platforms, the configuration data must be kept synchronised across all these platforms, a non-trivial task -exactly the issue addressed in a recent paper by Horsch, Hülsing and Buchmann [5].

Components of the Model

Inputs to Password Generation: The following data input types have been employed in existing schemes. A master password is a user-specific long-term secret value; this could either be a user-entered password, i.e. entered by the user whenever a password is to be generated, or a stored password, i.e. a userspecific secret value stored as global configuration data. A site name is a name for the authenticating site; this could take a variety of forms, including a user site name, i.e., a name for a site chosen by a user, all or part of the site's URL, or a site-specific secret, e.g. a random value associated with the site URL. A digital object is anything available on the user platform which could be used as input to the password generation process, e.g. a file or a selected block of text on the target web site. A password policy is information governing the nature of the password generated, e.g. the set of acceptable symbols.

Generating the Password: Combining inputs to generate a password can be done variously. All approaches involve a 2-stage process, i.e. first combining inputs to generate a bit-string, then formatting the bit-string to obtain a password in the desired format. Horsch et al. [6] propose an XML syntax, the Password Requirements Markup Language (PRML), designed specifically to enable requirements on passwords, as needed in the second stage, to be specified.

Password Output and Use: There are many ways in which a generated password could be transferred to the password field of a login page. Simplest is manual copy and paste, as used by SSP [7], where the password generator displays the password, and the user copies it to the login page. A slightly more automated approach is copy to clipboard in which the generated password is copied to the clipboard; for security reasons the password can be made to only reside in the clipboard for a limited period, e.g. in PasswordSitter the generated password is saved to the clipboard for 60 seconds before being deleted [15]. The simplest approach for the user is probably automatic copying to the target password field; this can either be done automatically, as is the case for PwdHash in the web page implementation [14] and the ObPwd Firefox browser extension [9]. Alternatively it can require the user to perform an action, e.g. clicking a specific key combination, before copying; PassPet requires the user to click on a screen button, [16], and Password Multiplier, [4], requires the user to double click the password field or press ctrl+P to trigger password copying.

Approaches to Implementation: A password generator can be implemented as a browser add-on, e.g. as a browser plug-in, browser extension or signed browser applet. Many existing password generator schemes adopt this approach, at least as one option, including [4,14,15,16]. An alternative is to implement the scheme as a stand-alone application, e.g. to run on a phone, tablet or desktop. Such an approach is adopted by SSP; ObPwd, [9], is also available as both a browser extension and a mobile app. A somewhat different approach is to use a web-based application, either running on a remote server or executing on the user platform as a dynamically downloaded JavaScript.

Improving System Operation

We next consider ways to improve password generators. In section 5 we consider how these might be integrated into a novel system.

We have mentioned certain types of configuration data, including global data, such as master secrets, and site-specific data, e.g. password policy values, possibly specified in PRML [6]. We now introduce two new configuration data types.

-A password offset (site-specific configuration data) allows users to continue using existing passwords after introducing use of a password generator. It also help when specific password values are imposed on users, or when users need to change their passwords. Addressing such requirements previously has been problematic. A password offset is as an input to the second stage of password generation.

A password offset induces this stage to generate a specific password value. E.g., suppose a password policy dictates that a password must be a string of letters and numerals, where each such character is internally represented as a numeric value in the range 0-61. After converting the bit-string to a string of alphanumeric characters of the desired length, and given a 'desired password' consisting of an alphanumeric string of the same length, the password offset could simply be the character-wise modulo 62 difference between the two strings1 . Changing a password can be easily implemented by changing the offset, either to a random value (randomising the password choice), or to a chosen value if the new password value is chosen by the user.

If implemented appropriately, this offset is not hugely confidential, since it need not reveal anything about the actual password value. Of course, if an 'old' password is compromised, and the old and new offsets are also revealed, then this could compromise the new password value. -A password generator might generate a password for one site using a different set of input types to those used to generate a password for another site. E.g., a password for a mission-critical site (e.g. a bank account) might be generated using a large set of input values, e.g. including a digital object, whereas a password for a less sensitive site could be generated using a master secret and site name only. Such a possibility could be captured using site-specific configuration data, referred to here as password input parameters. -A system might also store password reminders as site-specific configuration data. E.g., when using a digital object as input, a user could specify a phrase as a reminder of the chosen value (without specifying it precisely). This could be revealed on demand via the password generator user interface.

Storing configuration data on a user platform creates a major barrier to portability; it also poses a security risk through possible platform compromise, although much of the configuration data we have discussed is not necessarily confidential. The 'obvious' solution is to use a server to store configuration data, or at least the less sensitive such data, much as many password managers keep passwords in the cloud. While it would seem prudent to keep a master secret on the user platform, all site-specific configuration data could be held in the cloud. This type of solution is advocated by Horsch et al. [5,6].

If the site-specific configuration data is all non-confidential, then there is no need for a highly trusted server, a great advantage by comparison with some server-based password managers. Server use need not impact password availability, since a password generator could cache a copy of the configuration data downloaded from the server, addressing short-term loss of server availability.

AutoPass: A New Proposal

We now outline AutoPass (from 'automatic password generator'), a novel password generation scheme combining the best features of the prior art together with the novel ideas introduced in this paper, particularly those devised to address some of the shortcomings of previously proposed schemes. AutoPass uses all the types of input given in section 3 to generate a password, since they all contribute to security in different ways. Following the approach of PALPAS, [5], we also make use of a server to store non-sensitive configuration data, such as website password policies.

Operation

Following section 2, to describe AutoPass we must define: (a) the input types, (b) how the password is generated, and (c) how the password is output, together with the implementation strategy. We cover these points in turn. Since we also propose the use of a cloud service to support AutoPass operation, we also briefly sketch its operation.

-For inputs, we propose the use of a master password, stored by the system (as global configuration data), and a password (or PIN) to be entered by the user. We also propose use of the first part of the URL of the site, where, depending on the implementation, this should also be stored as part of the site-specific configuration and used to retrieve the other site-specific data.

The master password can be held encrypted by a key derived from the user password. We also propose the optional use of a digital object, where use of this option is indicated in the site-specific configuration data. -The first stage of password generation adopts a two-level hash approach, giving some protection against brute force attacks. The second stage, i.e. encoding, uses the AutoPass cloud service to retrieve the password policy for the web site being visited (cf. PALPAS [5]); this policy could be encoded using PRML, [6]. It also uses other cloud-stored configuration data, notably the password offset, password input parameters, and password reminders introduced in section 2.3. -The precise option for password output and use depends on the implementation. Where possible, auto-filling the password is desirable; where this is impossible, the copy to clipboard/paste buffer approach is advocated. -Implementation as a browser add-on is probably the best option, not least in giving simple access to the web page of the target site, although a range of options may need to be pursued depending on the platform type.

We next consider the AutoPass Cloud Service, whch will be required to store two main types of data. User-independent data will be accessed by AutoPass users, and will include non-sensitive site-specific data, e.g. password policies. Even if corrupted by a malicious party, it would at worst cause a denial of service. User-specific data will only be accessed by a single user, and includes a range of password configuration data. Although this data is not highly confidential, access to it will need to be restricted to the user to whom it belongs, e.g. via a one-off login process in the local AutoPass application (with access permissions encoded in a cookie stored in the user platform).

Any cloud service has associated risks arising from non-availability; however, this can be addressed through caching. The local AutoPass app should maintain a copy of the data downloaded from the cloud service; since this data is not likely to change very quickly, the cached data should normally be sufficient. To avoid risks arising from fake AutoPass services, e.g. using DNS spoofing, the cloud service could sign all provided data, and the AutoPass app could verify signatures using a built-in copy of the cloud public key.

Assessment

AutoPass incorporates both the best features of the existing password generation schemes and certain novel features, notably the use of password configuration data (see section 4). A full assessment of AutoPass will require prototyping and user testing. Nonetheless, we can at least consider the known issues in existing systems and see whether AutoPass addresses these concerns.

By using a combination of stored secret and memorised password/PIN as inputs to the generation process, we enable strong passwords to be generated while protecting against compromise through platform loss. Use of the URL enables automatic generation of site-specific passwords, and optional use of digital objects enables passwords of varying strength to be generated without imposing an unnecessarily onerous load on the user for 'everyday' use. URL use has residual problems, notably if a site URL changes, but user site names also have problems. In this connection, an advantage of AutoPass is that password offsets enable a generated password to remain constant even if a URL changes.

Use of cloud-served password policies solves problems relating to site-specific password requirements. Continued use of existing passwords and the need to change passwords are addressed by use of cloud-stored password configuration data. Password generation/synchronisation issues arising from use of multiple platforms can also be addressed through use of a cloud service. Of course, use of a cloud service brings with it certain availability and security risks; however, by only storing non-sensitive data in the cloud and using caching, these problems are largely addressed.

Concluding Remarks

We introduced a general model for password generation, and considered existing proposals in the context of this model. The model enables us to propose certain new options to enhance such schemes. The operation of a novel scheme, AutoPass, has been sketched, but has not yet been tested in practice. The next step is to prototype AutoPass, both to verify that the underlying idea works and also as a basis for practical user trials.

Such an idea is widely implemented to enable credit/debit card holders to select their own PIN value.