Mansour Ahmadi

Angelo Sotgiu

Giorgio Giacinto

IntelliAV: Toward the Feasibility of Building Intelligent Anti-Malware on Android Devices

Keywords: Android, Malware Detection, Machine Learning, On-Device, Ten-sorFlow, Mobile Security, Classification

Android is targeted the most by malware coders as the number of Android users is increasing. Although there are many Android antimalware solutions available in the market, almost all of them are based on malware signatures, and more advanced solutions based on machine learning techniques are not deemed to be practical for the limited computational resources of mobile devices. In this paper we aim to show not only that the computational resources of consumer mobile devices allow deploying an efficient anti-malware solution based on machine learning techniques, but also that such a tool provides an effective defense against novel malware, for which signatures are not yet available. To this end, we first propose the extraction of a set of lightweight yet effective features from Android applications. Then, we embed these features in a vector space, and use a pre-trained machine learning model on the device for detecting malicious applications. We show that without resorting to any signatures, and relying only on a training phase involving a reasonable set of samples, the proposed system outperforms many commercial antimalware products, as well as providing slightly better performances than the most effective commercial products.

Introduction

Nowadays, mobile devices are ubiquitous tools for everyday life. Among them, Android devices dominated the global smartphone market, with nearly 90% of the market share in the second quarter of 2016 [START_REF]IDC: Smartphone os market share, q2 2016[END_REF]. The majority of the security issues affecting Android systems can be attributed to third party applications (app) rather than to the Android OS itself. Based on F-secure reports on mobile threats [35], researchers found 277 new malware families, among which 275 specifically targeting Android devices. Also other recent reports clearly show that the malware infection rate of Android mobile devices is soaring. In particular, a report from McAfee [START_REF]McAfee: Mobile threat report[END_REF] reported a significant growth of mobile malware in the wild. We believe that this huge amount of mobile malware needs to be timely detected, possibly by smart tools running on the device, because it has been shown that malware can bypass offline security checks, and live in the wild for a while. As a matter of fact, to the best of our knowledge, even the most recent versions of Android anti-malware products are still not intelligent enough to catch most of the novel malware.

The success of machine learning approaches for malware detection and classification [START_REF] Amos | Applying machine learning classifiers to dynamic android malware detection at scale[END_REF][START_REF] Arp | Drebin: Effective and explainable detection of android malware in your pocket[END_REF][START_REF] Yang | DroidMiner: Automated Mining and Characterization of Fine-grained Malicious Behaviors in Android Applications[END_REF][START_REF] Suarez-Tangil | Droidsieve: Fast and accurate classification of obfuscated android malware[END_REF][START_REF] Islam | On-device mobile phone security exploits machine learning[END_REF], as well as the advance in machine learning software for the execution in mobile environments, motivated us to empower Android devices with a machine-learning anti-malware engine. Although modern mobile devices come to the market with a huge amount of computational power, the development of any Android anti-malware product should consider its efficiency on the device to avoid battery drain, in particular when machine learning techniques are employed, as they are known to be computational demanding. On the other hand, we observe that an intelligent Android anti-malware product doesn't need to be unnecessarily complex, as it has been shown that Android malware executes simpler tasks than the desktop counterparts [START_REF] Aresu | Clustering android malware families by http traffic[END_REF]. All the aforementioned reasons motivate the proposal for a machine learning solution to be deployed on mobile devices to detect potential malicious software.

On-Device Advanced Security

Although there are many offline systems proposed for mobile malware detection, mostly based on machine learning approaches (see Section 5), there are many reasons for a user to have an intelligent security tool capable of identifying potential malware on the device.

(i ) The Google Play store is not totally free of malware. There has been many reports that have shown that malware could pass the Google security checks, and remain accessible to users for sometime on the Play store until someone flags it as inappropriate. For instance, the Check Point security firm reported a zero-day mobile ransomware found in Google Play in January 2017, which was dubbed as a Charger application, and was downloaded by more than a million users [START_REF] Point | Charger malware calls and raises the risk on google play[END_REF]. Another report from the same vendor cites the case of new variants of the famous Android malware family HummingBad [START_REF] Point | A whale of a tale: Hummingbad returns[END_REF]. We vet these samples in Section 3.2.

(ii ) Third-party app stores are popular among mobile users, because they usually offer applications at great discounts. Moreover, the Google Play store has restricted access in some countries, so people have to download their required applications from third-party app stores. Nevertheless, security checks on the third-party stores are not as effective as those available on the Google Play store. Therefore, third-party markets are a good source of propagation for mobile malware. Many malware samples have been found on these stores during the past years, that were downloaded by millions of users. In addition, quite often users can be dodged by fake tempting titles like free games when browsing the web, so that applications are downloaded and installed directly on devices from untrusted websites. Another source of infection is phishing SMS messages that contain links to malicious applications. Recent reports by Lookout and Google [START_REF]Lookout: Pegasus for android[END_REF][START_REF]Google: An investigation of chrysaor malware on android[END_REF] show how a targeted attack malware, namely Pegasus, which is suspected to infect devices via a phishing attack, could remain undetected for a few years. We vet these samples in Section 3.2.

(iii ) One of the main concerns for any 'computing' device in the industry, is to make sure that the device a user buys is free of malware. Mobile devices make no exception, and securing the 'supply chain' is paramount difficult, for the number of people and companies involved in the supply chain of the components. There is a recent report that shows how some malware were added to Android devices somewhere along the supply chain, before the user received the phone [32]. We vet these samples in Section 3.2.

(iv ) To the best of our knowledge, almost all of the Android anti-malware products are mostly signature-based, which lets both malware variants of known families, and zero-day threats to devices. There are claims by a few Android antimalware vendors that they use machine learning approaches, even if no detail is available on the mechanisms that are actually implemented on the device. We analyze this issue in more details in Section 3.2.

All of the above observations show that an anti-malware solution based on machine-learning approaches, either completely, or as a complement to signatures, can reduce the vulnerability of Android devices against novel malware.

Contribution

Accordingly, in this paper we introduce IntelliAV1 , which is a practical intelligent anti-malware solution for Android devices based on the open-source and multi-platform TensorFlow library. It is worth to mention that this paper does not aim to propose yet another learning-based system for Android malware detection, but by leveraging on the existing literature, and on previous works by the authors, we would like to test the feasibility of having an on-device intelligent anti-malware tool to tackle the deficiencies of existing Android antimalware products, mainly based on pattern matching techniques. To the best of our knowledge, the performances of learning-based malware detection systems for Android have been only tested off-device, i.e., with computational power and memory space well beyond the capabilities of mobile devices. More specifically, the two main contributions of IntelliAV are as follows:

(i) We propose a machine-learning model based on lightweight and effective features extracted on a substantial set of applications. The model is carefully constructed to be both effective and efficient by wisely selecting the features, the model, and by tuning the parameters as well as being precisely validated to be practical for the capabilities of Android devices. (ii) We show how the proposed model can be embedded in the IntelliAV application, and easily deployed on Android devices to detect new and unseen malware. Performance of IntelliAV has been evaluated by cross-validation, and achieved 92% detection rate that is comparable to other off-device learningbased Android malware detection relying on a relatively small set of features. Moreover, IntelliAV has been tested on a set of unseen malware, and achieved 72% detection rate that is higher than the top 5 commercial Android anti-malware products. The rest of the paper is organized as follows: First, we reveal the detail of IntelliAV by motivating the choice of features and the procedure followed to construct the model ( §2). We then present the experimental setup and results ( §3). After that, we briefly mention the limitations of IntelliAV ( §4) and review the related works on Android malware detection ( §5). Finally, we conclude our paper discussing future directions of IntelliAV ( §6).

System Design

The architecture of the proposed IntelliAV system is depicted in Figure 1, and its design consists of two main phases, namely offline training the model, and then its operation on the device to detect potential malware samples. As a first phase, a classification model is built offline, by resorting to a conventional computing environment. It is not necessary to perform the training phase on the device, because it has to be performed on a substantial set of samples whenever needed to take into account the evolution of malware. The number of times the model needs to be updated should be quite small, as reports showed that just the 4% of the total number of Android malware is actually new malware [10]. To perform the training phase we gathered a relatively large number of applications ( §3.1). Then, a carefully selected set of characteristics (features) is extracted from the applications to learn a discriminant function allowing the distinction between malicious and benign behaviors ( §2.1). Next, the extracted features are passed to the model construction step in which a classification function is learnt by associating each feature to the type of applications it has been extracted from, i.e., malware or goodware ( §2.2). Finally, as the second phase, the model is embedded in the IntelliAV Android application that will provide a risk score for each application on the device ( §2.3).

Feature Extraction

The feature extraction step is the core phase for any learning-based system. Various kinds of features have been proposed for Android malware detection by the security community, such as permissions, APIs, API dependencies, Intents, statistical features, etc. (see Section5 for a detailed discussion on the issue of feature extraction for Android malware detection). However, some sets of features related to basic Android behaviors, like permissions, APIs, and Intents, usually allow achieving reasonable detection results, with the aim to alert for the presence of probably harmful applications [START_REF] Arp | Drebin: Effective and explainable detection of android malware in your pocket[END_REF][START_REF] Suarez-Tangil | Droidsieve: Fast and accurate classification of obfuscated android malware[END_REF]. Extracting this set of features is also feasible on mobile devices because they do not need deep static analysis, thus requiring a limited computational effort. Therefore, with the aim of extracting a set of efficient and effective features for IntelliAV, we resorted to the following four sets of features: permissions, Intent Filters, statistical features based on the 'manifest' of Android applications, and the APIs, which are extracted from the dex code. Therefore, to construct the feature vector, we considered all the permissions and intent-filters that are used by the samples included in the training set. In addition, four statistical features from application's components such as the total number of activities, services, broadcast receivers, and content providers are added to the feature vector as they can reveal the amount of abilities each application has. For instance, the number of activities in many malware categories is usually fewer than the number of activities available in benign applications, except for the case of malware that is built by repackaging benign applications. Moreover, we manually selected a set of 179 APIs as features and included in the feature vector. The selected APIs are those that reveal some particular characteristics of application that are known to be peculiar to either goodware or malware. For instance, the invoke API from the java.lang.reflect.Method class shows whether an application uses reflection or not. Note that permissions and APIs are coded as binary features, which means that their value is either one or zero depending on the feature being or not present in the application. By contrast, intent-filters are integer-valued features, as they represent the number of times an intent-filters is declared in the manifest. Considering this count for intent-filter features makes them more meaningful rather than simply considering their presence or not in the application. Similarly, the application's components are represented as integer valued features, as we count the number of components for each different type (e.g., activities, services, etc.). On the other hand, if we considered the number of permissions, we would have ended up with useless information, as each permission needs to be declared just once in the manifest. The same reasoning motivates the use of binary feature to represent API usage. The main reason is that although it is possible to get the count of the usage of an API in an application, the procedure would increase the processing time without producing more useful information, so that we ignored it. In total, the feature vector contains 3955 features. To avoid overfitting, and make IntelliAV faster on the mobile device, we decided to reduce the number of feature by selecting the 1000 meaningful features thorough a feature selection procedure (see Section 2.2). The final set 1).

Model Construction

To discriminate malware from benign applications, we need to rely on binary classification algorithms. Over the past years, a large number of classification techniques have been proposed by the scientific community, and the choice of the most appropriate classifier for a given task is often guided by previous experience in different domains, as well as by trial-and-error procedures. However, among all of the existing classifiers, Random Forest classifier [START_REF] Breiman | Random forests[END_REF] have shown high performances in a variety of tasks [19]. Random Forests algorithm is an ensemble learning method in which a number of decision trees are constructed at training time by randomly selecting the features used by each decision tree, and it outputs the class of an instance at testing time based on the collective decision of the ensemble. As far as the Random forest model is an ensemble classifier, it often achieves better results than a single classifier. The main reason of achieving good results by Random Forests is that ensemble methods reduce the variance in performances of a number of decision trees, which in turn are complex models with low bias. So, the final model exhibits low bias, and low variance, which makes the model more robust against both the underfitting and overfitting problems [START_REF] Bishop | Pattern Recognition and Machine Learning[END_REF].

To be able to train our model offline, as well as to test it on Android devices, we built IntelliAV on top of TensorFlow [START_REF] Abadi | Tensorflow: A system for large-scale machine learning[END_REF]. More specifically, we employ an implementation of Random Forests in TensorFlow, called TensorForest [START_REF] Colthurst | Tensorforest: Scalable random forests on tensorflow[END_REF]. Ten-sorFlow is an open source library for machine learning, which was released by Google in November 2015. To the best of our knowledge, IntelliAV is the first anti-malware tool that has proposed employing TensorFlow. The TensorFlow model is highly portable as it supports the vast majority of platforms such as Linux, Mac OS, Windows, and mobile computing platforms including Android and iOS. TensorFlow computations are expressed as data flow graphs. Nodes in the graph represent mathematical operations, while the graph edges represent the multidimensional data arrays (tensors) communicating between them.

As mentioned in the previous subsection, to simplify the learning task and reduce the risk of the so-called overfitting problem, i.e., to avoid that the model fits the training set but exhibits a low generalization capability with respect to novel unknown samples, we exploited feature selection that reduced the feature set size by removing irrelevant and noisy features . In particular, as done in [START_REF] Ahmadi | Novel feature extraction, selection and fusion for effective malware family classification[END_REF], we computed the so-called mean decrease impurity score for each feature, and retained those features which have been assigned the highest scores. Note that the mean decrease impurity technique is often referred to as the Gini impurity, or information gain criterion.

On-Device Testing

As we mentioned before, TensorFlow eases the task of using machine learning models on mobile devices. So, we embedded in IntelliAV the trained model obtained according to the procedure described in Section 2.2. The size of the TensorFlow models depends on the complexity of the model. For instance, if the number of trees in TensorForest increases, consequently the size of the model increases as well. The size of IntelliAV model that we obtained according to the above procedure and that we transferred to the device, is about 14.1MB. Having said that, when it is embedded into the apk, the model is compressed and the total size of the model becomes just 3.3MB. Whenever an application needs to be tested, first, IntelliAV extracts the features from the application on the device, then it loads the model, and finally it feeds the model by the extracted features to get the application's risk score. The model provides a likelihood value between 0 and 1, denoting the degree of maliciousness of the application, that we scale to a percentage that we called risk score, to make it more understandable for the end user. We empirically provide the following guideline for interpreting the risk score. If the risk score is lower than 40%, the risk is low and we suggest to consider the application as being benign. If the risk score is between 40% and 50%, then the application should be removed if the user isn't sure about the trustworthiness of the application. Finally, the application has to be removed if the risk score is higher than 50%. These thresholds have been set after testing the system on a set containing different applications. We deployed IntelliAV so that two main abilities are provided, as shown in figure 2. IntelliAV can scan all of the installed applications on the device, and verify their risk scores (Quick Scan). In addition, when a user downloads an apk, it can be analyzed by IntelliAV before installation to check the related risk score, and take the appropriate decision (Custom Scan). To access the contents of an application's package on the external storage, IntelliAV needs the READ EXTERNAL STORAGE permission. To access the contents of the packages of installed applications, IntelliAV needs to read base.apk in a sub-directory with a name corresponding to the package name, which is located in /data/app/ directory. As far as the permission of base.apk file is -rw-r--r--, which means every user can read the content of this file, IntelliAV doesn't need neither any permission, nor a rooted device to evaluate the installed applications.

Experimental Analysis

In this section, we address the following research questions:

-Is IntelliAV able to detect new and unseen malware ( §3.2)? -Are the performances of IntelliAV comparable to the ones of popular mobile anti-malware products, although IntelliAV is completely based on machine learning techniques ( §3.2)? -Which is the overhead of IntelliAV on real devices ( §3.3)?

Before addressing these questions, we discuss the data used, and the experimental settings of our evaluation ( §3.1).

Experimental Setup

To evaluate IntelliAV, we have collected 19,722 applications, divided into 10,058 benign and 9,664 malicious applications from VirusTotal [39]. When gathering malicious applications, we considered their diversity, by including samples belonging to different categories, such as Adware, Ransomware [START_REF] Andronio | Heldroid: Dissecting and detecting mobile ransomware[END_REF][START_REF] Maiorca | R-packdroid: Api package-based characterization and detection of mobile ransomware[END_REF], GCM malware [START_REF] Ahmadi | Detecting misuse of google cloud messaging in android badware[END_REF], etc. All of the gathered samples have been first seen by VirusTotal between January 2011 and December 2016. The whole process of feature extraction and model construction was carried out on a laptop with a 2 GHz quad-core processor and 8GB of memory. Two metrics that are used for evaluating the performance of our approach are the False Positive Rate (FPR) and the True Positive Rate (TPR). FPR is the percentage of goodware samples misclassified as badware, while TPR is the fraction of correctly-detected badware samples (also known as detection rate). A Receiver-Operating-Characteristic (ROC) curve reports TPR against FPR for all possible model's decision thresholds.

Results

To better understand the effectiveness of IntelliAV, we evaluate it in following scenarios.

Cross Validation

One might fit a model on the training set very well, so that the model will perfectly classify all of the samples that are used during the training phase. However, this might not provide the model with the generalization capability, and that's why we evaluated the model by a cross-validation procedure to find the best tuned parameters to be used for constructing the final model as a trade-off between correct detection and generalization capability. Consequently, we evaluated IntelliAV on the set of applications described in Section 3.1 through a 5-fold cross validation, to provide statistically-sound results. In this validation technique, samples are divided into 5 groups, called folds, with almost equal sizes. The prediction model is built using 4 folds, and then it is tested on the final remaining fold. The procedure is repeated 5 times on different folds to be sure that each data point is evaluated exactly once. We repeated the procedure by running the Random Forest algorithm multiple times to obtain the most appropriate parameters. The ROC of the best fitted model is shown in Figure 3. The values of FPR and TPR are respectively 4.2% and 92.5% which is quite acceptable although the set of considered features is relatively small, namely 1000 features.

Evaluation on the training set

To verify the effectiveness of the tuned parameters based on the cross-validation procedure explained in Section 3.2, we tested the model on all the samples used for training. Table 2 shows the results on the training set. It shows that IntelliAV misclassified just a few training samples. This shows how the model is carefully fitted on the training set, so that is able to correctly classify almost all of the training samples with very high accuracy, while it avoids being overfitted, and thus can detect unseen malware with a high accuracy as well (see the following).

Evaluation on new Malware

We then tested the system on a set made up of 2311 malware samples, and 2898 benign applications, that have been first seen by VirusTotal between January and March of 2017. We considered an application as being malicious when it was labeled as malware by at least 5 of the tools used by VirusTotal. This set of test samples contains randomly selected applications that were newer than the samples in the training set, and thus they were not part of the training set.

Test results are shown in Table 3. The detection rate on the test set is 71.96%, which is quite good if compared with the performances of other Android antimalware solutions that are available in the market, as shown in Section 3.2. Moreover, the false positive rate is around 7.52%, which is acceptable if we consider that an individual user typically installs a few dozen applications, and thus it might receive a false alert from time to time. This casual alert allows the user that the application has some characteristics similar to badware, and so it can be used only if the source is trusted. It is also worth noting that our classification of false positives is related to the classification provided by VirusTotal at the time of writing. It is not unlikely that some of these applications might turn out to be classified as malware by other anti-malware tools in the near future, as we have already noticed during the experiments. However, due to the small time frame, we haven't the possibility to collect enough examples to provide reliable statistics, as the samples used for the test phase are quite recent. We expect in a future work to show how many applications were correctly predicted as being malicious before their signatures were created. However, our experience suggests that even if the application is benign but labeled as being potentially risky by IntelliAV, then the user might look for less risky alternatives applications in Google Play [START_REF] Taylor | Securank: Starving permission-hungry apps using contextual permission analysis[END_REF]. In fact, we believe that it is better that people is aware of some applications that might be potentially harmful, even if it turns out not to be so, rather than missing some real threats.

Challenging Modern AV vendors Based on the recent reports by Virustotal

[39], there is an increase in the number of anti-malware developers that resort to machine learning approaches for malware detection. However, the main focus of these products appears to be on desktop malware, especially Windows PE malware. Based on the available public information, there are just a few evidences of two anti-malware developers that use machine learning approaches for Android malware detection, namely Symantec [START_REF] Eweek ; Fernández-Delgado | Do we need hundreds of classifiers to solve real world classification problems?[END_REF] and TrustLook [START_REF]Trustlook: Trustlook ai[END_REF]. Their products are installed by more than 10 million users. While it is not clear to us how these products use machine learning, we considered them as two candidates for comparison with IntelliAV. To provide a sound comparison, in addition to the Symantec and Trustlook products, we selected three other Android anti-malware products, i.e., AVG, Avast, and Qihoo 360, that are the most popular among Android users as they have been installed more than 100 million times. 2 We compared the performances of IntelliAV on the test dataset (see Section 3.2) with the ones attained by these five popular Android anti-malware As shown in Figure 4, IntelliAV performs slightly better than two of the products used for comparison, while it outperforms the other three. As we gathered the label assigned by anti-malware products to the test samples at most two months after they are first seen in VirusTotal, the comparison could be more interesting if we had the label given to samples at the time they are first seen in the wild. As an additional check, we performed a comparison in detection performance by considering a set of very recent malware reported by four vendors, namely Check Point, Fortinet, Lookout, and Google (see Table 4). The good performances of IntelliAV compared to the ones of other products, shows that Fig. 4: Comparison between the detection rate of IntelliAV with top five Android anti-malware. We didn't put the name of vendors as we don't aim to rank other anti-malware products.

IntelliAV AV1 AV2 AV3 AV4 AV5 0 500 1,
the selected lightweight features and training procedure allows attaining very good performances, especially if we consider that 21 of the considered samples were first seen before 2017, so it is expected that they can be detected antimalware tools either by signatures, or by the generalization capability provided by their machine learning engines. If we have a close look at the two misclassified samples by IntelliAV (Table 4), we can see that the associated risk scores are quite close to the decision threshold that we set at training time. The main reasons for the misclassification of these two samples can be related to the use of the runtime.exec API to run some shell commands, and to the presence of native-code that is used to hide some of their malicious behaviors.

IntelliAV Overhead on Device

To better understand the efficiency of IntelliAV, we show the time consumption for feature extraction as well as classification of some medium/large-sized applications on three devices with different technical specifications. The three mobile devices used for the reported experiments are a Samsung Galaxy S6 Edge (released in April, 2015), a Huawei P8 Lite (released in May, 2015), and an LG D280 L65 (released in June, 2014), which respectively have 3GB, 2GB, and 1GB of RAM. In addition, we computed the time required on the Android Emulator that is dispatched along with Android Studio. The time is simply computed by specifying a timer before starting the feature extraction procedure, that stops when the features from both the manifest and the dex code are extracted. For classification, the reported time refers to the interval between the feature vector is passed to the model, to the production of the risk score. The time required to load the model is negligible, and so we are not reporting it for the sake of clarity. Table 4: Point to point comparison of IntelliAV and three anti-malware vendors on some recent and well-known malware reported by Check Point, Fortinet, Lookout, and Google from January to April of 2017. These samples were evaluated on an Android emulator. The time column refers to the required time for performing both feature extraction and classification on the emulator. As shown in Table 5, the time required to analyze even large applications is less than 10 seconds, which makes IntelliAV practical and reasonable as the number of installed applications on each device is not too large. The classification part is performed in native code, that provides a fast execution. As expected, it can be noted that the largest fraction of the time required by IntelliAV is spent for feature extraction, especially for the extraction of the API features. This figure is even worse in the case an application is made up of multiple dex files, because the extraction of API features is much slower. For example, the Uber app is made up of 10 dex files, so that searching for a specific API requires much more time compared to applications having just one dex file.

Limitations

As far as IntelliAV is based on static analysis, it inherits some of the wellknown limitations of static analysis approaches. For instance, we didn't address reflection and dynamic code loading techniques that are used to hide the malicious code. Moreover, in the proposed implementation, IntelliAV doesn't handle those malware samples that use JavaScript to perform an attack. However, the most common evasion techniques are based on obfuscation of names, and the use of downloaders that download the malicious payload at run-time. The reported test results show that IntelliAV is robust against these common obfuscation techniques as it doesn't rely on features extracted from strings or names of classes or methods. In addition, as far as IntelliAV runs on the device, it can track all downloaded and installed apps, scanning them on the fly. Consequently, it can be more robust compared to off-device systems. In addition, we are aware that the system can be a victim of evasion techniques against the learning approach, such as mimicry attacks that let an attacker inject some data to the app so that its features resembles the ones of benign apps [START_REF] Biggio | Evasion Attacks against Machine Learning at Test Time[END_REF]. Consequently, more methodological and experimental analysis will be needed to make a quantitative evaluation of the robustness of IntelliAV in an adversarial environment, to provide the system with the required hardening. Nonetheless, we believe that the good performances of the proposed system is a good starting point for further development. Moreover, employing the multiple classifier system approach, considering a larger number of semantic features, as well as performing a fine grained classifier parameter tuning, can provide a degree of robustness against adversarial attacks against the machine learning engine.

Related works

At present, a large number of papers addressed the topic of detecting Android malware by proposing different systems. The proposed approaches can be divided into two main categories, namely offline malware detection, and on-device malware detection. While a complete overview is outside of the scope of this paper, and we suggest the interested reader to resort to one of the good survey that have been recently published (e.g., the recent taxonomy proposed in [START_REF] Sadeghi | A taxonomy and qualitative comparison of program analysis techniques for security assessment of android software[END_REF]), we provide here some of the more closely related papers that rely on static analysis technique. We omit reviewing the malware classification systems based on dynamic analysis [START_REF] Dash | Droidscribe: Classifying android malware based on runtime behavior[END_REF][START_REF] Amos | Applying machine learning classifiers to dynamic android malware detection at scale[END_REF][START_REF] Burguera | Crowdroid: Behavior-based malware detection system for android[END_REF] as they have their own benefits and pitfalls. Moreover, as we are dealing with an on-device tool, it is not officially possible that a process access system calls of other process without root privileges, which makes the dynamic analysis approaches almost impractical on the end user device. Offline Malware Detection. Usually, offline testing has no hard computational constraints, thanks to the availability of computational power compared to the one available on mobile devices, thus allowing for sophisticated application analysis. Hence, a number of approaches have been proposed to construct complex models capable of detecting malware with a very high accuracy. Some of the prominent approaches that focus on building a model and offline testing of Android applications by static analysis techniques are briefly summarized. MudFlow [START_REF] Avdiienko | Mining apps for abnormal usage of sensitive data[END_REF], AppAudit [START_REF] Xia | Effective real-time android application auditing[END_REF], and DroidSIFT [START_REF] Zhang | Semantics-aware android malware classification using weighted contextual api dependency graphs[END_REF] rely on information flow analysis [START_REF] Arzt | Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps[END_REF], while DroidMiner [START_REF] Yang | DroidMiner: Automated Mining and Characterization of Fine-grained Malicious Behaviors in Android Applications[END_REF], and MaMaDroid [START_REF] Mariconti | MaMaDroid: Detecting Android Malware by Building Markov Chains of Behavioral Models[END_REF] use API sequences to detect malware. The use of complex features such as information flows and API sequences, makes these approach more difficult to be carried out on the device. Lighter approaches have been proposed, such as Drebin [START_REF] Arp | Drebin: Effective and explainable detection of android malware in your pocket[END_REF], DroidAPIMiner [START_REF] Aafer | DroidAPIMiner: Mining API-Level Features for Robust Malware Detection in Android[END_REF], and DroidSieve [START_REF] Suarez-Tangil | Droidsieve: Fast and accurate classification of obfuscated android malware[END_REF] that make use of meta-data as well as syntactic features, and that allow for their porting to on-device applications.

On-Device Malware Detection. Based on the best of our knowledge, there are a few approaches in the research community that used machine learning for on-device malware detection, and none of them is publicly available for performance comparison. One that of the most cited research works on this topic is Drebin, and while the paper shows some screenshots of the UI, the application itself is not available. Among the commercial Android anti-malware tools, two of them claim to use machine learning techniques, as evaluated and reported in Section 3.2, but the real use of machine learning by these tools is blurred. Finally, Qualcomm recently announced the development of a machine learning tool for on-device mobile phone security, but the details of the system, as well as its performances are not available [START_REF] Islam | On-device mobile phone security exploits machine learning[END_REF].

As an overall comparison with the previous approaches, we believe that IntelliAV provides a first practical example of an on-device anti-malware solution for Android systems, completely based on machine learning techniques, that can move a step toward having an advanced security tool on mobile devices.

Conclusions and future work

In this paper, we introduced a practical learning-based anti-malware tool for Android systems on top of TensorFlow, in which both the efficiency and the effectiveness are considered. We showed that through the careful selection of a set of lightweight features, and a solid training phase comprising both a robust classification model, and a representative set of training samples, an efficient and effective tool can be deployed on Android mobile device. Our tool will be freely available so that it can help the end user to provide easy protection on the device, as well as allowing researchers to better explore the idea of having intelligent security systems on mobile devices. As a future plan, we aim to address the limitations of IntelliAV, to improve its robustness against attacks on the machine learning engine, while keeping the efficiency intact.

Acknowledgement

We appreciate VirusTotal's collaboration for providing us the access to a large set of Android applications.

Fig. 1 :

 1 Fig. 1: Overview of IntelliAV.

Fig. 2 :

 2 Fig. 2: IntelliAV abilities.

Fig. 3 :

 3 Fig. 3: ROC curve of TensorForest (5-fold cross validation). FPR and TPR are respectively 4.2% and 92.5%.

Table 1 :

 1 Features used in IntelliAV. features related to permissions, 503 features related to Intent filters, 4 statistical features from components (e.g., count of activities), and 171 features related to API usage (see Table

	Category Number of Features Type
		Meta-Data
	Permissions	322	Binary
	Intent Filters	503	Count
	Statistical	4	Count
		Dex Code
	APIs	171	Binary
	consists of 322

Table 2 :

 2 Training on the set of samples explained in Section 3.1 and testing on the same set. GT refers to the Ground-truth of samples.

	Train		Test
	#Samples GT (#Samples)	Classified as Malicious Benign
		Malicious (9,664)	9,640	24
	19,722	Benign (10,058)	(TPR = 99.75%) 7	10,051
			(FPR = 0.07%)

Table 3 :

 3 Training on the set of samples described in Section 3.1, and testing on new samples in 2017. GT refers to the Ground-truth of samples.

	Train		Test
	#Samples GT (#Samples)	Classified as Malicious Benign
		Malicious (2311)	1,663	648
	19,722	Benign (2898)	(TPR = 71.96%) 218	2,680
			(FPR = 7.52%)

Table 5 :

 5 Overhead of IntelliAV on different devices for very large applications. F.E. refers to feature extraction time and C. refers to classification time. The number in parenthesis shows the RAM size of the device.

			Galaxy S6 Edge Huawei P8 Lite LG D280 L65	Emulator
			Marshmallow (3GB) Lollipop (2GB) KitKat (1GB) Marshmallow (1.5GB)
	App	APK Size (MB) F.E. (s)	C. (s)	F.E. (s) C. (s) F.E. (s) C. (s) F.E. (s)	C. (s)
	Google Trips	8.19	0.67	0.003	0.82	0.005	3.86 0.012 0.43		0.001
	LinkedIn Pulse	12.9	1.28	0.003	1.14	0.005	4.40 0.012 0.55		0.001
	Stack Exchange	8.15	1.27	0.004	1.27	0.006	5.13 0.014 0.60		0.001
	Telegram	12.41	1.36	0.005	1.74	0.007	5.52 0.016 0.69		0.002
	WhatsApp	27.97	2.29	0.006	3.22	0.008 12.91 0.018 1.10		0.002
	SoundCloud	33.14	2.67	0.006	2.84	0.008 11.83 0.018 1.14		0.002
	Spotify	34.65	2.51	0.006	3.03	0.008 13.67 0.018 1.22		0.002
	Twitter	31.77	4.53	0.004	5.95	0.006 24.46 0.016 2.26		0.002
	LinkedIn	40.39	4.67	0.004	4.69	0.006 16.73 0.016 2.40		0.001
	Airbnb	54.34	8.24	0.006	8.79	0.008 35.71 0.018 4.23		0.002
	Messenger	59.43	5.85	0.011	7.94	0.013 19.13 0.028 3.35		0.004
	Uber	37.26	6.66	0.004	7.64	0.006 43.88 0.016 4.29		0.002
	Average	30.05	3.50	0.005	4.08	0.007 16.43 0.016 1.86		0.002

http://www.intelliav.com

http://www.androidrank.org/


Félix Iglesias

Valentin Bernhardt

Robert Annessi

Tanja Zseby

Decision Tree Rule Induction for Detecting Covert Timing Channels in TCP/IP Traffic

Keywords: covert channels, decision trees, forensic analysis, machine learning, network communications, statistics

The detection of covert channels in communication networks is a current security challenge. By clandestinely transferring information, covert channels are able to circumvent security barriers, compromise systems, and facilitate data leakage. A set of statistical methods called DAT (Descriptive Analytics of Traffic) has been previously proposed as a general approach for detecting covert channels. In this paper, we implement and evaluate DAT detectors for the specific case of covert timing channels. Additionally, we propose machine learning models to induce classification rules and enable the fine parameterization of DAT detectors. A testbed has been created to reproduce main timing techniques published in the literature; consequently, the testbed allows the evaluation of covert channel detection techniques. We specifically applied Decision Trees to infer DAT-rules, achieving high accuracy and detection rates. This paper is a step forward for the actual implementation of effective covert channel detection plugins in modern network security devices.

Introduction

Network communication platforms and protocols have been devised with clear structures and policies to allow fluent data transmission between different actors in networks. Covert channels profit from such structures and policies to send information in ways that are not in compliance with the original design of the communication schemes. The purpose of this unorthodox communication is that the covert data transfer remains generally unperceived but for the sender and receiver of the covert information. Ultimately, the pragmatic goal is usually-although not always-fraudulent or illicit, such as data exfiltration, or malware communication. For this reason, modern Intrusion Detection systems (IDS) should incorporate covert channel detection capabilities to cope with those hidden communication methods.

In [START_REF] Iglesias | DAT detectors: uncovering TCP/IP covert channels by descriptive analytics[END_REF], detectors based on descriptive analytics of traffic (DAT) were presented as a broad-scope solution for covert channel identification in TCP/IP networks. DAT detectors operate by extracting meaningful information from network traffic and transform it into flow vectors. In such vectors, every susceptible TCP/IP field is represented by a set of features based on aggregations, statistics, autocorrelation, and multimodality estimations.

There exists a wide variety of ways to send covert information in IP networks. Diverse taxonomies and schemes to classify covert channels have been proposed in the literature over the years, e.g., [START_REF] Shen | Optimization of covert channel identification[END_REF] [30] [START_REF] Zander | A survey of covert channels and countermeasures in computer network protocols[END_REF]. More recent surveys are given in [START_REF] Wendzel | Pattern-based survey and categorization of network covert channel techniques[END_REF] and [START_REF] Iglesias | DAT detectors: uncovering TCP/IP covert channels by descriptive analytics[END_REF]. In [START_REF] Wendzel | Pattern-based survey and categorization of network covert channel techniques[END_REF], Wendzel et al. analyze 109 techniques developed between 1987 and 2013 and organize covert channel techniques as variations of 11 characteristic patterns. In [START_REF] Iglesias | DAT detectors: uncovering TCP/IP covert channels by descriptive analytics[END_REF], covert channels are differently classified from a detection perspective. The interested reader can find good overviews as well as links to multiple publications about the design and detection of covert channels in the cited papers. Beyond accurate classifications, from a global perspective covert channels were originally differentiated as: timing channels, if timing properties of communications mask the covert message, and storage channels, if covert data is somehow conveyed inside packets. In this work, we focus on timing channels.

In [START_REF] Iglesias | DAT detectors: uncovering TCP/IP covert channels by descriptive analytics[END_REF], DAT detectors were theoretically depicted. The evaluation was conducted with a proof of concept where the rules of a DAT detector prototype were adjusted solely based on experts knowledge, achieving moderate performance rates. Therefore, the main goals and contributions of this paper are: 1. To deeply evaluate DAT detectors for the specific case of covert timing channels. To this end, a testbed for generating and testing covert channels has been created. The evaluation has been conducted by implementing eight of the most popular covert timing techniques proposed in the literature. 2. To establish a methodology for tuning DAT detector parameters and rules based on Decision Trees learners. 3. To generalize a set of constituent rules for DAT detectors in the scope of covert timing channels, thus enabling the incorporation of DAT detectors in future IDS.

Related Work

Already in the '70s, covert timing channels were identified by the USA Air Force experts as a potential problem of secure communications even in end-to-end encryption scenarios [START_REF] Padlipsky | Limitations of end-to-end encryption in secure computer networks[END_REF]. Actually, devised without paying a special attention to security concerns, TCP/IP protocols entail many possibilities to conceal covert information. As a consequence, a considerable number of covert channel techniques have been presented in the related literature since then.

In the '90s, J. C. Wray noticed that the partition between storage and timing channels was not always appropriate, since there are covert channels that share properties of both types [START_REF] Wray | An analysis of covert timing channels[END_REF]. An example of half-timing half-storage channel is given in [START_REF] Giffin | Covert Messaging through TCP Timestamps[END_REF], where a little delay is introduced in the packet delivery to make the lowest bit of TCP timestamps-usually seemingly random-to coincide with the covert bit to send. In this case, information is hidden in a TCP field, but the method invariably affects time properties in the communication. Note that, in this case, even if it is not possible for a warden to decode the message without checking packet fields, the detection by only analyzing packet inter-arrival times (henceforth iats) is theoretically possible. Another hybrid technique was proposed by W. Mazurczyk and K. Szczypiorski, who developed a method that inserts covert data in the payloads of VoIP packets that were intentionally delayed and normally dropped [START_REF] Mazurczyk | Steganography of VoIP Streams[END_REF]. In [START_REF] Girling | Covert channels in lan's[END_REF], C. G. Girling tested a covert timing channel assuming that a sender could address a number of hosts in a network, and a wiretapper in the middle would interpret destination addresses as codifications (e.g., [START_REF] Padlipsky | Limitations of end-to-end encryption in secure computer networks[END_REF] addresses can conceal 4 bits of information).

Nevertheless, covert timing channels do not usually involve using information of packet fields. The attention is normally focused on iats. For example, in [START_REF] Cabuk | IP covert timing channels: Design and detection[END_REF] the sender and receiver of the covert communication are synchronized and agree on a fixed sampling time interval. The existence or absence of a packet in the interval transports the covert information. V. Berk, A. Giani and G. Cybenko show a timing channel technique where covert 1s and 0s are deduced from two different packet delays [START_REF] Berk | Detection of covert channel encoding in network packet delays[END_REF]. Authors also discuss the bandwidth commitment in the design and implementation of covert timing channels, i.e., a low bandwidth is undesired for transmitting information but makes the covert channel stealthier.

Packet delays are also manipulated in [START_REF] Shah | Keyboards and covert channels[END_REF], where a Jitterbug slightly modifies the time behaviour (in a millisecond scale) of hacked input devices, such as a keyboard, in order to allow an eavesdropper to guess the introduced data by observing the generated time sequence. This is a good example of how different malware can exploit covert channels. Video stream data is proposed as a carrier for sending binary covert information in [START_REF] Gasior | Network covert channels on the android platform[END_REF], and a threshold for packet-iats is used to differentiate between 0s and 1s at the destination. Video on Demand services are used in [START_REF] Zi | Implementing a passive network covert timing channel[END_REF] to transport covert information also by carefully manipulating iat values. In [START_REF] Wu | Improving performance of network covert timing channel through huffman coding[END_REF] message redundancy is exploited by applying Huffman coding to transform covert symbols into packet delays.

Given that detection methods are often based on statistics and distributions of the network usage, in [START_REF] Gianvecchio | Model-based covert timing channels: Automated modeling and evasion[END_REF] covert timing channels are created by matching time-distributions generated by legitimate services. In [START_REF] Kiyavash | Covert timing channels codes for communication over interactive traffic[END_REF], Kiyavash and Coleman study a method for interactive traffic that relies on encoding mechanisms, statistical structures of network queues and packet iat for sending covert information. A different time-based approach is proposed in [START_REF] Luo | Tcp covert timing channels: Design and detection[END_REF]. Here, bursts of packets transport the covert information, and the total number of packets in the burst represents the covert symbol. Additional timing-based convert channel techniques can be consulted, for example, in [START_REF] Holloway | Covert dcf: A dcf-based covert timing channel in 802[END_REF], [START_REF] Walls | Liquid: A detection-resistant covert timing channel based on {IPD} shaping[END_REF] or [START_REF] Archibald | A covert timing channel based on fountain codes[END_REF].

The detection of covert timing channels has been classically faced from the perspective of the analysis of statistical properties. For instance, in [START_REF] Cabuk | IP covert timing channels: Design and detection[END_REF], in addition to present some covert timing techniques, the detection of the proposed channels is conducted by means of calculations on variance patterns and mea-suring similarity between adjacent iats. Entropy calculations are also used for such purpose, for example, Gianvecchio and Wang test entropy-based detection on three different techniques in [START_REF] Gianvecchio | An entropy-based approach to detecting covert timing channels[END_REF]. More recently, in [START_REF] Chen | Detecting covert timing channels with time-deterministic replay[END_REF], time-deterministic replay has been introduced as a technique that can reproduce the precise timing of applications and, therefore, be used for disclosing covert timing channels. As for machine learning approaches, Support Vector Machines has been proposed for covert channel detection several times, e.g., in [START_REF] Sohn | A Study on the Covert Channel Detection of TCP/IP Header Using Support Vector Machine[END_REF], and specifically for timing channels in [START_REF] Shrestha | A support vector machinebased framework for detection of covert timing channels[END_REF], achieving good results against four popular timing techniques. Decision tree learners also obtain successful detection rates when tested with basic timing techniques in [START_REF] Zander | Stealthier inter-packet timing covert channels[END_REF].

The detection framework presented in [START_REF] Iglesias | DAT detectors: uncovering TCP/IP covert channels by descriptive analytics[END_REF]-i.e., DAT detectors-focuses on the characterization of flows by means of a careful selection of statistical calculations and estimations. Therefore, it is a statistical approach in nature; nevertheless, in this paper we propose the application of machine learning to induce and adjust the rules embedded in DAT detectors, enhancing the basic proposal and making the most of the depicted framework. The excellent properties of Decision Trees for knowledge abstraction and generalization make them highly appropriated for the aimed purpose.

DAT Detector

DAT detectors are primarily introduced and widely described from a theoretical perspective in [START_REF] Iglesias | DAT detectors: uncovering TCP/IP covert channels by descriptive analytics[END_REF]. They are devised to be lightweight, fast traffic analyzers in network middleboxes. DAT detectors basically operate with descriptive analytics of traffic flows, creating flow vectors whose features are based on aggregations, statistics, autocorrelation, and multimodality estimations.

A DAT detector consists of three well-differentiated phases (Figure 1): preprocessing (P), feature extraction and transformation (T), and flow labeling and covert channel detection (D).

Preprocessing

The first phase takes raw traffic captures as inputs (e.g., PCAP files). Traffic captures are parsed and packet vectors are formed with meaningful, homogeneous information for the subsequent analysis.

For the specific case of covert timing channels, the selected information must provide time characteristics and allow the identification of flows. Assuming that raw traffic is obtained as packet captures and a flow is simply defined by the source IP and destination IP tuple1 , the output of the preprocessing phase will contain packet vectors as shown in equation 1:

pkt i = {timestamp, src.IP, dst.IP} (1)
where pkt i stands for the i th -captured-packet, "timestamp" refers to the actual time when packet i was captured, and "src.IP" and "dst.IP" correspond to the flow source and destination IP addresses respectively. The proposed features may vary depending on the field to analyze. In our experiments only iats are required, and we specifically redefine some features for the iat field. For example, µ ∆ and M o are not used, and µ ωS is a novelty and replaces w S . µ ωS is the mean of standard distributions of peaks obtained by kernel density estimations. Therefore, µ ωS allows to easily abstract the average distribution width. In addition, we add c, which depends on S k and pkts. c is an estimation of the number of potential covert bytes and is calculated by means of simple ad-hoc tables [START_REF] Iglesias | DAT detectors: uncovering TCP/IP covert channels by descriptive analytics[END_REF]. In the cited work, c is incorporated in the last detection phase, but it can perfectly be estimated in the OD-flow generation and included in the vector. Therefore, for the specific case of covert timing channel detection, a OD-flow vector is expressed as (equation 2) 3 : Here we aim to detect solely covert timing channels, so only a single TCP/IP flow field is to be analyzed: iats. It also means that only the Intra-field Analysis block must be adjusted and tested. Considering the specific case of covert timing channels, the evaluation of the Intra-field Analysis, the validation of Decision Trees as rule extractor-learners, and the proposal of a set of rules for actual implementations are the goals of this work.

flow vec = {U, S k , µ ωS , S s , p(M o), ρ A , pkts, c} (2)

Implemented Timing Techniques

We have created a testbed for the evaluation of covert channel detection techniques. Eight of the covert timing channels introduced in Section 2 have been implemented for the conducted experiments. We depict them with mnemonic names, using the first three letters of the author who originally published the technique and the corresponding reference. Note that covert channel generation manipulates packet delays in the communication source (aka inter departure times, henceforth abbreviated as idts), but detection uses iats; i.e., for two consecutive packets a and b, iat -Packet presence (CAB) As presented in [START_REF] Cabuk | IP covert timing channels: Design and detection[END_REF], the CAB technique requires synchronicity between the sender and the receiver, who agree on a fixed interval as sampling time.

The absence or presence of a packet during an interval represents the binary symbol 0 or 1 respectively (Figure 3). In [START_REF] Cabuk | IP covert timing channels: Design and detection[END_REF], different implementations for ensuring synchronization are suggested.

-Differential/derivative (ZAN) This differential covert channel was originally proposed for the IP-packet Time to Live field [START_REF] Zander | An empirical evaluation of ip time to live covert channels[END_REF], but can be easily implemented by using packet delays. Given a basic idt (t b ), whenever a 1 is to be send the previous idt is modified by adding or subtracting t inc ; in case of a 0, the last idt is kept the same, i.e., with no modification (Figure 4). -Fixed intervals (BER) Proposed in [START_REF] Berk | Detection of covert channel encoding in network packet delays[END_REF], this technique establishes fixed idts to represent 0s and 1s, respectively t 0 and t 1 (Figure 5). -Jitterbug/modulus (SHA)

The Jitterbug [START_REF] Shah | Keyboards and covert channels[END_REF] manipulates an existing transmission. It establishes a ground sampling time interval ω and adds a little delay to idts to make them divisible by ω or ω/2 according to the covert symbol to send (Figure 6). -Huffman coding (JIN) This technique codes every covert symbol directly into a set of packets with different idts according to the frequency of the symbol and based on a Huffman codification. For the experiments we applied this technique only for plain text files and using the codification presented in [START_REF] Wu | Improving performance of network covert timing channel through huffman coding[END_REF] (Figure 7). -Timestamp manipulation (GIF) By this technique [START_REF] Giffin | Covert Messaging through TCP Timestamps[END_REF], packet idts are manipulated based on the least significant bit (LSB) of the TCP timestamp. A minimum idt (t b ) between packets must be respected (authors propose, at least, t b = 10ms). If the LSB coincides with the covert symbol, the packet is sent; if not, the condition is checked again after a time t w (Figure 8).

-One threshold (GAS) Devised for Android platforms and with video services as carriers, this tech- nique establishes a threshold th for iats [START_REF] Gasior | Network covert channels on the android platform[END_REF]. Delays above and below th will be considered 1s and 0s respectively (Figure 9). -Packet bursts (LUO) By this technique presented in [START_REF] Luo | Tcp covert timing channels: Design and detection[END_REF], packet bursts are sent separated by a waiting time interval t w . The number of packets in a burst directly represents the covert symbol or piece of code to send. For example, three packets in a burst are used to send the symbol "3" (Figure 10).

Experiments

The objective of the experiments was to create and refine DAT rules for the detection of covert timing channels. For this purpose, training and testing processes were performed with known-i.e., labeled-datasets.

Dataset Generation

A testbed for traffic generation was built for creating IP flows containing covert channels as defined by the techniques published in the literature and briefly described in Section 4. In addition to selecting techniques, inputs included the files to covertly send and configuration parameters necessary for the setup. We have created two datasets (cc training and cc testing) with different files and random seeds. Selected files included different kinds of plain-text documents (poems, list of passwords, technical reports and programming scripts), images (PNG and JPEG), compressed files (in ZIP and GZ formats) and 3DES encrypted files. Parameters for the automated generation of flows with covert channels were randomly selected within the ranges defined in Table 1. The parameter ranges were adjusted according to the papers in which the techniques were originally presented or, if not documented, based on the knowledge of network traffic measurement experts.

Table 1. Parameters for the random generation of covert channels. As for the training sets that are free of covert channels, real network data was downloaded from the MAWI Working Group Traffic Archive. In the MAWI database4 , 15 minutes of real backbone traffic is published every day for research purposes. We downloaded traffic corresponding to Sun Feb. 5, 2017, and divided into three 5-minute datasets, from which we used one dataset for training (nocc training), one for testing (nocc testing), and discarded the third one.

Model Obtaining

During the second phase, OD-flows were extracted from the datasets, labeled, and jumbled before undergoing classification. To speed up classification, all flows with less than one packet were already discarded in this phase. For all explored datasets (with and without covert channels), the maximum observation window for a OD-flow was set to five minutes (the rest was simply discarded). The interested reader can freely download the used OD-flow datasets from [START_REF]Data Analysis and Algorithms[END_REF].

The objective in this phase was to obtain a classification model that could differentiate flows with covert channels from flows without. Since generalization was desired, Decision Trees were selected as classifiers. Decision Trees are known to be efficient learners, with good accuracy rates and, more importantly, they allow easy interpretation and rule extraction from results [START_REF] Kamber | Generalization and decision tree induction: efficient classification in data mining[END_REF]. We used basic Decision Tree algorithms based on recursive partitioning instead of more complex options (e.g., Random Forest) because they are more interpretable and predictions are easier to explain and generalize. Another characteristic of Decision Trees that make them eligible for the current application is that they are embedded feature selection methods [START_REF] Saeys | A review of feature selection techniques in bioinformatics[END_REF], i.e., they can potentially ignore features that are redundant or irrelevant.

During the experiments, pre-and postpruning were performed to avoid overfitting and favor generalization. 5 In addition, a 10-fold cross-validation process was performed to reinforce disclosed models. During the training phase, models were obtained from the cc training and nocc training datasets.

Rule Generalization

In the final phase, rules were extracted from the Decision Tree complete model. These rules were manually checked later and adjusted according to generalization criteria. An enhanced set of rules was obtained and implemented in DAT detectors.

Once new rules were embedded, DAT detectors underwent an additional testing phase with reserved datasets. Such validation was conducted with completely new data (not used before): cc testing and nocc testing.

It is worth remarking that, even not among the purposes of the current work, the presented testbed enables the modeling of covert timing channel techniques and the obtaining of patterns for the ML-based Detector block introduced in Section 3.

5 Details of the conducted parametrization are: Decision Trees used Information Gain (i.e., entropy-based) as splitting criterion; the minimal size for splitting was four samples; the minimal leaf size was two samples, allowing a maximal tree depth of 20 levels; the minimal gain for splitting a node was 0.1; the confidence level used for the pessimistic error calculation of pruning was 0.25, whereas the number of prepruning alternatives was three.

Results

The outcomes of the tests conducted in Section 5 were used to evaluate the performance of DAT detectors and the validity of the obtained constituent decision rules. Results were divided into two distinct phases:

1. Obtaining a rule-based decision model based on Decision Tree induction. 2. Validation of the generalized model with testing datasets.

Rule extraction experiments

Decision Trees generated the model illustrated in Figure 12. The corresponding performances indices are shown in Table 2. Results in Table 2 discloses that Decision Trees were able to capture significant patterns to discriminate between flows with and without covert channels. Provided training data is representative enough, the use of cross validation ensures the robustness of the obtained model and indices. One of the first aspects that draws attention from Figure 12 is the absence of ρ A , S s and S k in the solution model. Not using ρ A is not surprising as iats time series are chaotic and low self-correlated regardless of the class. This is due to the fact that, given a sampling resolution of 1 ms, delays in generation and transport invariably entail scenarios with a considerable entropy. The absence of S s is also understandable due to same reason, i.e., transmission delays make iats to take approximate but different values even when coming from the same idt by design. In this respect, S k is a better estimation of main symbols for the iat-case but, even so, it does not appear in the Tree either. Actually, S k is indirectly affecting the model through other parameters, such as c and µ ωS (which depend on S k ). Decision Trees just avoided redundancy with respect to this variable (given to its capabilities for feature selection), but the use of multimodality by kernel density estimation was determinant for the detection.

DAT testing after generalization

The close examination of the model in Figure 12 allows to carry out a rule generalization like the one exposed in Figure 13. The generalized Decision Tree in Figure 13 condenses the detection in two main common patterns (green leaves). One of these patterns corresponds to flows that, during the observation scope (5 minutes), show a considerable amount of packets (pkts > 170) but low potential covert bytes (c < 25). This is idiosyncratic of flows with most iats very close to one center value, making S k and S s equal one or close to one (for instance, the packet bursts technique, LUO). However, the behaviour emphasized by this decision branch can also be matched by some legitimate services and is prone to generate some false positives (see Table 3).

The second branch, which concentrates most of the discovered covert channels, reveals that covert channels show distributions where packet-iats are in a range between 1 ms and 50 ms around the center values; also, the iat-mode-value represents less that 70% of iats, the number of estimated possible covert bytes must be high (c > 50) and the number of unique values (in ms resolution) is somehow below the estimated covert bytes (U/c < 0.9). This revealing last property suggests the footprint of a structure behind iat-values, which are generated by algorithmic patterns. Note that in Figure 13 the U > 1 condition has been included, as such condition is not inferred by Decision Trees but previously imposed in the experiments (i.e., a flow with only one iat value cannot hide a covert timing channel). Except for this specific feature U , a certain fuzziness is naturally assumed when establishing rule thresholds. Therefore, in DAT detectors, instead of strictly applying the thresholds discovered by Decision Trees with a step function, the fitting of every feature to the given rules has been adjusted by using a smooth step function. Later, the final evaluation is obtained with the product t-norm among the different branch conditions.

Table 3 shows the results for the final validation experiments. Indices are promising for detectors that are designed to be lightweight detection barriers, although reveal some false positives to be corrected in final applications. Future implementations will gain robustness by the incorporation of fuzzy controllers in the DAT-decision making, whose capabilities to deal with vague thresholds make them perfect for the application. Detection accuracy is also expected to improve by the complementary analysis carried out by the ML-based Detector block, which stores a library with patterns related to known covert channel techniques. The development of such pattern library can be easily performed by the same testbed used together with Decision Trees rule extractors.

Conclusion

This work tested and validated statistics-based framework-DAT detectors-for the detection of covert timing channels. To this end, multiple cover channels have been generated based on a set of eight popular covert timing techniques, which were then mixed up with real traffic captures. Decision Trees classifiers were used to infer rules from training data to embed in final implementations of the DAT detector decision making. The final testing with new datasets corroborated the fitness of DAT detectors. In short, this work complements and satisfactorily proves the theoretical foundations exposed in [START_REF] Iglesias | DAT detectors: uncovering TCP/IP covert channels by descriptive analytics[END_REF], paving the way for an easy integration of fast covert channel detection in modern IDSs.

Fig. 1 .

 1 Fig. 1. DAT overall three-phase scheme.

Fig. 2 . 3 ) 3 .

 233 Fig. 2. iat-distribution of an example flow. Probability frequency diagram (blue) and kernel density estimation curve (red).

  ab = idt ab + (d b -d a ), where d a and d b are the transmission delays of packet a and packet b.The implemented covert timing techniques are:

Fig. 3 .

 3 Fig. 3. CAB technique: presence or absence of a packet.

Fig. 4 .

 4 Fig. 4. ZAN technique: differential idt.

Fig. 5 .

 5 Fig. 5. BER technique: fixed idts.

Fig. 6 .

 6 Fig. 6. SHA technique: jitterbug delay manipulation.

Fig. 7 .

 7 Fig. 7. JIN technique: Huffman coding.

Fig. 8 .

 8 Fig. 8. GIF technique: timestamp manipulation.

Fig. 9 .

 9 Fig. 9. GAS technique: one threshold.

Fig. 10 .

 10 Fig. 10. LUO technique: packet bursts.

  Figure 11 illustrates the training process, which consisted of three main phases: (1) dataset generation, (2) model obtaining, and (3) rule generalization.

Fig. 11 .

 11 Fig. 11. Phases of the training process: dataset generation, model obtaining, and rule generation.

  Parameters di (delay) By default, transmissions delays are modeled with a Lomax (Pareto Type II) distribution with α = 3 ms and λ = 10 ms CAB tint ∈ [60, 140] ms BER t0 ∈ [10, 50] ms, t1 ∈ [80, 220] ms SHA pkt-dist.: Gamma with k ∈ [40, 760] ms, φ ∈ [40, 360] ms ω ∈ [10, 90] ms GAS 0-idts pkt-dist.: t0 = th -ts 1-idts pkt-dist.: t1 = th -ts + ta th ∈ [100, 300] ms, ts ∈ [60, 140]ms, ta ∈ [20, 80] ms JIN Codification from [26] LUO tw ∈ [50, 250] ms Packets in a burst are sent every ms ZAN t b ∈ [30, 70] ms, tinc ∈ [30, 70] ms GIF t b ∈ [10, 30] ms, tw ∈ [4, 12] ms

Fig. 12 .

 12 Fig. 12. Decision Tree obtained during the training phase. '1' corresponds to leaves that identify covert channels, '0' for leaves that identify normal traffic.

Fig. 13 .

 13 Fig. 13. Generalized Decision Tree implemented in final DAT detectors.

Table 2 .

 2 Performance Indices of the complete model during training (datasets: cc training and nocc training).

		Predicted CC Predicted Normal
	Real CC	1015 (TP)	17 (FN)
	Real Normal	7 (FP)	16302 (TN)
	Accuracy		99.86% ± 0.05%
	Precision		99.96% ± 0.04%
	Recall		99.90% ± 0.06%
	AUC (area under ROC) 0.996 ± 0.004

Table 3 .

 3 Performance Indices of the generalized model during evaluation and testing. DATA: cc training dataset and nocc training dataset

		Predicted CC Predicted Normal
	Real CC	990 (TP)	33 (FN)
	Real Normal	94 (FP)	16320 (TN)
		Accuracy 99.23%
		Precision 91.33%
		Recall	96.77%
	DATA: cc testing dataset and nocc testing dataset
		Predicted CC Predicted Normal
	Real CC	995 (TP)	42 (FN)
	Real Normal	99 (FP)	16013 (TN)
		Accuracy 99.18%
		Precision 90.95%
		Recall	95.95%

Note that the classic 5-tuple used to identify communication flows is not used here (i.e., src.IP, dst.IP, Protocol, src.Port, dst.Port). Unlike overt IP communications, covert channels can be constructed using different protocols, source and destination ports in the transmission of the same hidden message.

iat is treated like a header field for DAT detectors.

Features in equation 2 should be annotated with the first-level field to which they correspond (i.e., UT T L, Usrc.P ort, Uiat,...). Since in this work we only use iats, we omit such subindices for the sake of clarity.

http://mawi.wide.ad.jp/mawi/

Acknowledgments

The research leading to these results has been partially funded by the Vienna Science and Technology Fund (WWTF) through project ICT15-129, "BigDAMA".