Kalpana Singh
email: kalpana@deakin.edu.au

Lynn Batten
email: lynn.batten@deakin.edu.au

An Attack-resistant Hybrid Data-privatization Method with Low Information Loss

Keywords: data privatization, information loss, Chebyshev polynomial, Spectral Filtering, Bayes-Estimated Data Reconstruction, data mining

We examine a recent proposal for data privatization by testing it against well-known attacks; we show that all of these attacks successfully retrieve a relatively large (and unacceptable) portion of the original data. We then indicate how the data privatization method examined can be modified to assist it to withstand these attacks and compare the performance of the two approaches. We also show that the new method has better privacy and lower information loss than the former method.

Introduction and Background 1.Data Privatization

Privacy preservation is an important issue in many data mining applications dealing with sensitive data such as health-care records. Privacy preserving data mining (PPDM) has become an important enabling technology for integrating data and determining interesting patterns from private collections of databases, thus improving productivity and competitiveness for many businesses. PPDM requires data modification which limits information loss (thus increasing utility) as it is intended that a legitimate receiver of the modified data be able to recover the original data needed for a response. Perturbation techniques have to manage the intrinsic trade-off between preserving data privacy and information loss, as each affects the other. Several perturbation techniques [START_REF] Agrawal | Privacy-Preserving Data Mining[END_REF]- [START_REF] Du | Using Randomized Response Techniques for Privacy-Preserving Data Mining[END_REF] have been proposed for mining purposes, but in all these papers, privacy and utility are not satisfactorily balanced. In the research literature, there are two general approaches to privacy preserving data mining: the randomization approach [START_REF] Agrawal | Privacy-Preserving Data Mining[END_REF] and the secure multi-party computation approach [START_REF] Du | Secure Multi-Party Computation Problems and Their Applications: A Review and Open Problems[END_REF]. We focus only on the former because it can distort data more efficiently than the latter.

There are two major randomization methods: Random Perturbation [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF] and Randomized Response [START_REF] Du | Using Randomized Response Techniques for Privacy-Preserving Data Mining[END_REF]. The former is a technique which deals mostly with numerical data, perturbing attribute by attribute, and concentrating on a statistical analysis of the data; it is a well-studied sanitization method that simultaneously allows access to the data by publishing them and at the same time preserving the privacy of the data. Randomized Response perturbs multiple attributes rather than one at a time, and so we ignore this method.

In the literature, perturbation is of two main types: additive [START_REF] Agrawal | Privacy-Preserving Data Mining[END_REF], [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF] and multiplicative [START_REF] Liu | Multiplicative Data Perturbation for Privacy Preserving Data Mining[END_REF], where random data (noise) is respectively either added or multiplied with the original data. As shown by Kargupta et al. multiplicative noise techniques can pro-vide a good level of privacy (http://www.csee.umbc.edu/~hillol/PUBS/kargupta_privacy03a.pdf), while additive noise perturbation techniques are more effective in reducing information loss [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF].

There is a growing body of literature on additive perturbation techniques which work by adding random noise to the data in such a way that the individual data values are distorted while, at the same time, the underlying distribution properties are preserved thus helping to reduce information loss. Agrawal and Srikant [START_REF] Agrawal | Privacy-Preserving Data Mining[END_REF] proposed a scheme for PPDM using random perturbation in which a random number is added to the value of each sensitive attribute. It has been shown [START_REF] Agrawal | Privacy-Preserving Data Mining[END_REF] that this scheme suffers from information loss, but Agrawal and Aggarwal [START_REF] Agrawal | On The Design and Quantification of Privacy Preserving Data Mining Algorithms[END_REF] developed a novel reconstruction algorithm which minimizes the information loss of the former scheme. Liu has proposed a multiplicative method [START_REF] Liu | Multiplicative Data Perturbation for Privacy Preserving Data Mining[END_REF] which improves on the level of privacy achieved in [START_REF] Agrawal | Privacy-Preserving Data Mining[END_REF] and [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF], but with reduced utility.

This leads us to the following research question: Given a data-privatization method which leaks data under certain attacks, can it be improved to withstand these attacks without affecting information loss?

In this paper, we demonstrate that this is possible by taking a particular example of a data-privatization technique, showing that it leaks data under three attacks and then adapting it to withstand these attacks while retaining low information loss characteristics.

The Research Literature

The usefulness of additive noise perturbation techniques in preserving privacy was firstly questioned by Kargupta et al. [START_REF] Kargupta | On The Privacy Preserving Properties of Random Data Perturbation Techniques[END_REF] who showed that attackers can derive a good estimation of the original dataset values from the perturbed dataset using a spectral filter that exploits some theoretical properties of random matrices and, as a result, the data privacy can be seriously compromised. Huang et al. [START_REF] Huang | Deriving private information from randomized data[END_REF] further proposed two data reconstruction algorithms which are efficient when the added noise is independent of the original data; one is based on Principal Component Analysis [START_REF] Huang | Deriving private information from randomized data[END_REF], the other one chooses Maximum Likelihood Estimation [START_REF] Huang | Deriving private information from randomized data[END_REF] to estimate the data.

The purpose of the current paper is to test a specific additive perturbation method (described in Section 2) to see how well it withstands three classical additive datareconstruction attacks. We choose: Spectral Filtering (SPF) [START_REF] Kargupta | On The Privacy Preserving Properties of Random Data Perturbation Techniques[END_REF], Bayes-Estimated Data Reconstruction (BE-DR) [START_REF] Huang | Deriving private information from randomized data[END_REF] and Multiple Miner attack with Fusion (MDMF) [START_REF] Sramka | An Attack on The Privacy of Sanitized Data That Fuses the Outputs of Multiple Data Miners[END_REF]. We use the SPF method because it has a good track record in reconstructing original data based on additive perturbation; it is based on eigenvalues of a covariance matrix and the theory of random matrices [START_REF] Kargupta | On The Privacy Preserving Properties of Random Data Perturbation Techniques[END_REF]. We choose BE-DR for its ease of calculation and also because of its similarity to the calculations of SPF. The MDMF method is a combination of multiple data mining [START_REF] Sramka | An Attack on The Privacy of Sanitized Data That Fuses the Outputs of Multiple Data Miners[END_REF] and fusion techniques [START_REF] Sramka | An Attack on The Privacy of Sanitized Data That Fuses the Outputs of Multiple Data Miners[END_REF]; we use WEKA software [START_REF] Hall | The WEKA Data Mining Software: An Update[END_REF] for data mining techniques in this method.

The particular data-privatization method [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF] we test is based on Chebyshev polynomials of the first kind [START_REF] Mason | Chebyshev Polynomials[END_REF] which are explained in detail in Section 2. This method was developed recently by a group of researchers [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF] but needs testing to see if it withstands the classical attacks. For testing, we derive 4500 test sets and each is tested for reconstruction using the three attack methods just described. We show that in all cases, some of the original data can be recovered. In addition, for each attack, we are able to specify how to modify the data privatization algorithm to make the data resistant to the attack with the result that we produce a revised data privatization method and show that it is resistant to these attacks.

In Section 2, we present the Chebyshev-based data-privatization method as described in [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF]; Section 3 presents the attacks on this method, and results of these attacks. Section 4 describes our revised version of the Chebyshev-based dataprivatization method and we produce the results of three attacks on it and compare the performance with the former method. Section 5 discusses our results.

The Chebyshev Polynomial Perturbation Method

An additive perturbation technique based on Chebyshev polynomials was presented in [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF] and in this section we describe it in detail. The Chebyshev polynomials (http://mathworld.wolfram.com/ChebyshevPolynomialoftheFirstKind.html) used in the paper [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF] are said to be Chebyshev of the first kind as opposed to Chebyshev polynomials of the second kind. In this paper we use the expression "Chebyshev Polynomial' to refer exclusively to the Chebyshev Polynomials T n (t) of the first kind.

The authors of [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF] propose an additive perturbation algorithm based on Chebyshev polynomials as described below in sub-section 2.1.

Chebyshev Data Perturbation Algorithm (CDP)

1. Data: In the paper [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF] numerical type data for computation, such as the age of a patient which is common in health data, are considered. While the original data are commonly in matrix form, we store them in vector form. Section 2.2 provides notations. The original data set is referred to as O and the added noise data as N. These have the same size. 2. Setting parameters: m: the (square integer) number of entries in the original vector (or matrix). n: the degree of the Chebyshev polynomial of the first kind, n ≥ 2. l: a positive integer divisor of m, l >1.

Data perturbation:

The initial values of the above parameters m, n and l, are assumed to be fixed. a) Preparation: Derive the n th degree Chebyshev polynomial 𝑇 𝑛 . b) Division process: Divide the original data in vector form into intervals of length l; this results in 𝐷 =

𝑝𝑡(𝑡 𝑖 ) 1 = 𝑇 𝑛 -1 + 1 𝑛 + 2 1- 1 𝑛 𝑗 𝑙+1 obtaining 𝑝 𝑖1 = 𝑜 𝑖1 + 𝑝𝑡(𝑡 𝑖 ) 1 .
And so, the general equation describing this method is, 𝑃 = 𝑂 + 𝑁.

(1) 4. Restoration: When 𝑝 𝑖1 and 𝑝𝑡(𝑡 𝑖 ) 1 are known, the data can easily be restored by using: 𝑜 𝑖1 = 𝑝 𝑖1 -𝑝𝑡(𝑡 𝑖 ) 1 .

Our aim is, knowing only 𝑃 and not O, to reconstruct the original dataset values from 𝑃 thus breaking the privatization method of the paper [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF]. For the reconstruction we use the three attacks mentioned in Part B of Section 1.

Summary of Symbols and Values Used

This sub-section provides the notation for sub-section 2.1 and subsequent parts of the paper. bounds for the eigenvalues of a matrix

Description and Results of the Reconstruction Attacks

In this section we explore the SPF, BE-DR and MDMF reconstruction methods and examine how well they estimate the original data. We use the same assumptions on data mentioned in [START_REF] Kargupta | On The Privacy Preserving Properties of Random Data Perturbation Techniques[END_REF] (SPF), [START_REF] Huang | Deriving private information from randomized data[END_REF] (BE-DR) and [START_REF] Sramka | An Attack on The Privacy of Sanitized Data That Fuses the Outputs of Multiple Data Miners[END_REF] (MDMF) as appropriate, and use the notation of Table 1. We generate 4500 matrices using the algorithm described in Section 2; 1500 of these were of size 400, 1500 of size 1600 and 1500 of size 6400. Because our data is stored in vector form, we are at liberty to decide on the matrix size for the reconstruction, and since we work heavily with eigenvalues, which are easy to produce from square matrices, we assume that O is square. We use MATLAB R2009b [START_REF] Franco-Pereira | An introductory course in MATLAB: MATLAB for beginners[END_REF] and WEKA 3.7.7 [START_REF] Hall | The WEKA Data Mining Software: An Update[END_REF] for our experiment analysis. Using the Chebyshev Polynomial method described in Section 2 and the test matrices described above. (Note that because MATLAB [START_REF] Franco-Pereira | An introductory course in MATLAB: MATLAB for beginners[END_REF] was used to generate and attack the vectors, we were restricted to the largest vector size it can handle, which is 6400 elements.) We implemented all data reconstruction methods on the 4500 datasets mentioned above. In each case, we obtained an estimation of the original data set which was then compared with the original data set in terms of the success measures described in the papers [START_REF] Kargupta | On The Privacy Preserving Properties of Random Data Perturbation Techniques[END_REF], [START_REF] Huang | Deriving private information from randomized data[END_REF] and [START_REF] Sramka | An Attack on The Privacy of Sanitized Data That Fuses the Outputs of Multiple Data Miners[END_REF]. In each case, although we tested (the same) 4500 matrices in each attack, we present the details of only one of our matrices -one which has 6400 entries.

Spectral Filtering Reconstruction Method Test Example i

We calculate the eigenvalues of the covariance matrix of the perturbed matrix 𝑃 of the fixed example matrix O. Then we calculate 𝜆 𝑚𝑖𝑛 = 0 and 𝜆 𝑚𝑎𝑥 = 0.4556 from which we obtain those noisy eigenvalues 𝜆 𝑖 which satisfy the inequality 𝜆 𝑚𝑖𝑛 ≤ 𝜆 𝑖 ≤ 𝜆 𝑚𝑎𝑥 ., that is, which are in the range (0, 0.4556). The remaining eigenvalues should be those of O. Now from the SPF algorithm [START_REF] Kargupta | On The Privacy Preserving Properties of Random Data Perturbation Techniques[END_REF] we can calculate the eigenvalues of the covariance matrix of the estimated matrix. In order to obtain the eigenvalues of 𝑂 , we need only consider those above or equal to 𝜆 𝑚𝑎𝑥 . To measure the success of the attack, we calculate the closeness of eigenvalues of 𝑂 and eigenvalues of O. We obtain 𝜆 63 -𝜆 63 =0, 𝜆 64 -𝜆 64 =0,........, 𝜆 80 -𝜆 80 =0; all these differences are (very close to) zero, so an attacker can easily reconstruct the original data by using the SPF method.

ii To check the condition when values of reconstruction error increases as SNR [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF] decreases, we give here only the average of reconstruction error values -0.4384 while the value of 𝑆𝑁𝑅 is 0.2408. So, in this case also we achieve a successful attack.

iii Lower and upper bound analysis, [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF], we calculate the lower bound to be 35.0716, and the upper bound to be 56.1346. Using [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF], 𝑂 -𝑂 𝐹 = 37.4507. Since 37.4507 ≥ 35.0716 and 37.4507 ≤ 56.1346, both lower and upper bound conditions are satisfied. iv We get RMSE [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF] = 0.4384. The fact that 0.4384 < 1 means our estimated dataset is not erroneous; so the attacker has breached the privacy. In summary, the SPF method breached the privacy of the data-privatization method. In fact, SPF reconstruction is known to work well against additive techniques [START_REF] Kargupta | On The Privacy Preserving Properties of Random Data Perturbation Techniques[END_REF].

Bayes-Estimated Data Reconstruction Method Test Example i

We calculate RMSE = 0.5187 <1; so the attacker has breached the privacy ( [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF]). ii We calculate the reconstruction error corresponding to every element of the data set in vector form: 𝑜 11 -𝑜 11 = 0.015161, 𝑜 21 -𝑜 21 = 0.014837, 𝑜 31 -𝑜 31 = 0.014654 and so on until 𝑜 6400 1 -𝑜 6400 1 = 0.000035037. From the calculation we find that the attack has been successful ( [START_REF] Huang | Deriving private information from randomized data[END_REF]).

Multiple Data Mining and Fusion Reconstruction Method

We use seven data mining algorithms 𝑀𝑠, 𝑠 = 1, … ,7. The following 7 miners, representing four different categories, were selected from the WEKA software package, version 3.7.7 [START_REF] Hall | The WEKA Data Mining Software: An Update[END_REF], and used in the attack: Function-based: Simple linear regression (M1), Meta: CVParameterSelection (M2), Stacking (M3), Vote (M4); Rule-based: ZeroR (M5); Tree-based: DecisionStump (M6) and REPTree (M7).

Test Example i

We calculate the RMSE value to be 0.4033<1, and so privacy has been breached ( [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF]). ii We evaluate the success of attack by calculating 𝑑(𝑜 𝑤𝑗 , 𝑜 𝑤𝑗 ) < 𝑑(𝑝 𝑤𝑗 , 𝑜 𝑤𝑗 ) for all 1≤ w, j ≤ √m ( [START_REF] Sramka | An Attack on The Privacy of Sanitized Data That Fuses the Outputs of Multiple Data Miners[END_REF]) and find that 5337 elements out of 6400 elements of the matrices have satisfied the inequalities. In this case, the attacker has obtained 83.39% of the original data and failed to recover [START_REF] Liu | Random Projection-Based Multiplicative Data Perturbation for Privacy Preserving Distributed Data Mining[END_REF] = 0.2711<1. Because this is close to zero, the attack has been successful ( [START_REF] Sramka | An Attack on The Privacy of Sanitized Data That Fuses the Outputs of Multiple Data Miners[END_REF]).

Presentation of Proposed Method and Results of Attacks

Proposed Method

In this section, we propose a new hybrid data perturbation method with better utility preservation and privacy preservation than that described in Section 2. It has been pointed out that attacks which work on an additive data perturbation method will also work on a multiplicative data perturbation method as the latter can be logarithmically transformed into an additive data perturbation method [START_REF] Pandya | An Overview of Traditional Multiplicative Data Perturbation[END_REF]; hence we avoid a straightforward additive or multiplicative method.

While the noise matrix (N) is again generated using a Chebyshev polynomial of the first kind, our proposed method includes an orthogonal, rotation transformation matrix (R) and a translation matrix (T). R is added because rotation transformations preserve the utility of the most critical information for many classification models [START_REF] Liu | Multiplicative Data Perturbation for Privacy Preserving Data Mining[END_REF]. T is added to increase resilience to attack [START_REF] Liu | Random Projection-Based Multiplicative Data Perturbation for Privacy Preserving Distributed Data Mining[END_REF]. I is the √mx√m identity matrix. Our proposed hybrid perturbation is defined as follows: 1. Data: We use the format of sub-section 2.1.

Setting parameters:

The values m, n and l are as in sub-section 2.1.

Data perturbation:

Data preparation and division are as in sub-section 2.1, part 3. Data processing: In this step we generate the orthogonal matrix R to multiply by the original data and the translation matrix T as well as the noise to add to the original data. The choice of the type of R is based on observations in [START_REF] Liu | Multiplicative Data Perturbation for Privacy Preserving Data Mining[END_REF] stating "random orthogonal transformation seems to be a good way to protect data"s privacy while preserving its utility." And, for a legitimate user, "it is possible to re-identify the original data through a proper rotation." Also, as part of future work, the authors suggest that "The random projection-based technique may be even more powerful when used with some other geometric transformation techniques like … translation, and rotation." [16; p. 105] In addition, the author of [START_REF] Liu | Multiplicative Data Perturbation for Privacy Preserving Data Mining[END_REF] demonstrates that a rotation matrix preserves data privacy and quality. Indeed, our current hybrid proposal confirms this suggestion. Producing R: We use MATLAB [START_REF] Franco-Pereira | An introductory course in MATLAB: MATLAB for beginners[END_REF] to produce an orthogonal matrix [START_REF] Liu | Multiplicative Data Perturbation for Privacy Preserving Data Mining[END_REF] on input of the size m. Producing T: Again, MATLAB produces a translation matrix on input of m. Each element of the noise vector 𝑝𝑡 𝑡 𝑖 1 as generated in (c) of Part 1. We divide by 100 to bring the values of the perturbed matrix within the range of values of the original data.

We test this hybrid method with the three additive attacks used to test the earlier method described in Section 2. As in the earlier testing, for all tests we choose 4500 'original' matrices of three different sizes, but this time, derive the perturbed matrices from (2). The experiment followed the methods of Section 3 and the attacker fails with respect to each of the reconstruction methods. Due to space limitations, we merely summarize the experimental results in Table 2 to three decimal places.

Table 2. Comparative analysis between additive method [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF] and our proposed method 5 Summary and Discussion

Level of Privacy and Information loss

First, we calculate success and failure of the attacker attack by attack, averaged over all the matrices of the same size and for each of the old additive method of Section 2 and the new proposal of Section 4. Table 2 indicates that the results do not depend on matrix size. Success (PoS) measures how much of O is reconstructed successfully by the attacker and is measured by 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑠 ( 𝑂 -𝑂 < 𝑃 -𝑂 ) 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑠 𝑜𝑓 𝑂 [START_REF] Mcmullen | Probability Theory[END_REF] as a percentage; the Failure (PoF) [START_REF] Mcmullen | Probability Theory[END_REF] is defined as 100 minus this value. The actual values are given in Table 2.

We also use a variance-of-difference (VoD) method [START_REF] Liu | Multiplicative Data Perturbation for Privacy Preserving Data Mining[END_REF] for measuring privacy in order to compare the two methods discussed in this paper. VoD measures privacy of matrices column-wise and we can calculate it with no knowledge of the original data. The perfect estimation will have zero mean and variance. We define VoD for all 1 ≤ 𝑖 ≤ 𝑚 as 𝐷 𝑖 = 𝑜 𝑖1 ′ -𝑜 𝑖1 , and calculate E[𝐷 𝑖 ] the mean of all 𝐷 𝑖 and var [𝐷 𝑖 ] the variance of all 𝐷 𝑖 . The average values are shown in Table 2. The fact that the mean and variance of the 𝐷 𝑖 are higher than 1 means that the attacker cannot estimate the original data; lower than 1 indicates a breach of privacy.

The level of information loss is measured by using a dissimilarity function [START_REF] Datta | On Random Additive Perturbation for Privacy Preserving Data Mining[END_REF] between the original dataset O and the perturbed dataset 𝑃 . This dissimilarity function is ) near 0 denotes low information loss. We calculate average information loss for our proposed method as 0.004310 which is very low. We also calculate the dissimilarity function for the additive method [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF] obtaining Diss (O, 𝑃 ) = 0.864534. So, average information loss for our proposed method is 0.4310% and for the additive method of [START_REF] Singh | Recovering Private Data: A Comparision of Three Methods[END_REF] is 86.4534%. We conclude that our proposed method has achieved low information loss in comparison with the additive perturbation method of equation [START_REF] Agrawal | Privacy-Preserving Data Mining[END_REF].

In summary, we have shown how a data perturbation method can be attacked by several reconstruction methods and then adjusted to withstand the attacks.

  The first interval t 1 contains the original data o 11 , o 21 , ... o l1 ; the second contains the next l elements o l+1 1 , o l+2 1 , ... o 2l 1 and so on. c) CDP data processing: In this step we generate noise to add to the original data. If an element o i1, 1 ≤ i ≤ m, of the original data set is in interval j, 1 ≤ 𝑗 ≤ 𝐷, then we add it to the corresponding element of the noise matrix defined as

𝑚 𝑙 intervals. Label the D intervals t 1 , t 2 , ...t D .

Table 1 .

 1 Summary of symbols and definitions

	Symbols	Definitions
	O	original dataset matrix
	𝑜 𝑖𝑗 , 1 ≤ 𝑖, 𝑗 ≤ 𝑚	elements of the original dataset with matrix and vector indexation respec-
	and 𝑜 𝑖1 , 1 ≤ 𝑖 ≤ 𝑚	tively
	𝑃	perturbed dataset matrix 𝑃 = 𝑂 + 𝑁
	𝑝 𝑖𝑗 , 1 ≤ 𝑖, 𝑗 ≤ 𝑚 and 𝑝 𝑖1 , 1 ≤ 𝑖 ≤ 𝑚	elements of the perturbed dataset with matrix and vector indexation respec-tively
	N	noise dataset matrix
	𝑝𝑡 𝑡 𝑖 j , 1 ≤ 𝑖, 𝑗 ≤ 𝑚	elements of the noise dataset with matrix and vector indexation respectively
	and 𝑝𝑡(𝑡 𝑖 ) 1 , 1 ≤ 𝑖 ≤ 𝑚
	𝑂	estimated dataset matrix
	𝑜 𝑖𝑗 , 1 ≤ 𝑖, 𝑗 ≤ 𝑚	elements of the estimated dataset with matrix and vector indexation respec-
	and 𝑜 𝑖1 , 1 ≤ 𝑖 ≤ 𝑚 mi	tively i" th row of the matrix M
	𝑀 𝑐𝑜𝑣	covariance matrix of the matrix M
	I	identity matrix
	𝜎 and 𝜎 2	standard deviation and variance of the noise matrix elements
	𝜇 𝑀	mean vector of the matrix M
	[𝜆 𝑚𝑖𝑛 , 𝜆 𝑚𝑎𝑥 ]

  .61 % of it.

	iii The added noise is	𝑜 𝑤𝑗	𝑝 𝑤𝑗 -𝑜 𝑤𝑗	=116.1852; the remaining noise is	𝑜 𝑤𝑗	𝑜 𝑤𝑗 -
	𝑜 𝑤𝑗 = 31.5011. So, we get the ratio	𝑟𝑒𝑚𝑎𝑖𝑛𝑖𝑛𝑔 𝑛𝑜𝑖𝑠𝑒 𝑎𝑑𝑑𝑒𝑑 𝑛𝑜𝑖𝑠𝑒

  𝑃 ) and lies in [0,1]. A value of Diss (O, 𝑃

	denoted by Diss (O,
	Recon-		Additive Method [12]				Our Proposed Method
	struc-
	tion
	attack
	me-thods	Size of matrices	400 size	1600 size	6400 size	Level of privacy (VoD)	400 size	1600 size	6400 size	Level of privacy (VoD)
	And infor-loss mation	factor ment Meas-ure-				E[D]	Var [D]				E[D]	Var [D]
	SPF	SNR	0.213	0.230	0.241	0.203	0.151	34.24	35.65	36.59	48.44	16.23
								7				5
		RMSE	0.314	0.386	0.438			42.36	46.43	47.75
								4	4	8
		PoS	80.28	78.63	76.86			0.115	0.091	0.042
		PoF	19.72	21.37	23.14			99.89	99.91	99.96
	BE-DR	RMSE	0.387	0.469	0.519	0.496	0.023	38.93	42.03	43.95	44.65	16.12
		PoS	73.68	71.85	69.27			0.493	0.454	0.441
		PoF	26.32	28.15	30.73			99.51	99.55	99.56
	MDMF	RMSE	0.369	0.389	0.403	0.505	0.061	40.01	44.49	45.78	46.35	16.66
		PoS	87.45	85.79	83.39			0.428	0.416	0.304
		PoF	12.55	14.21	16.61			99.57	99.58	99.70
		Relative	0.189	0.258	0.271			10.27	14.36	15.85
		Noise/								1
		Added
		Noise


Alexandre Bouard
email: alexandre.bouard@bmw.de

Maximilian Graf
email: maximilian.graf@bmw.de

Dennis Burgkhardt
email: dennis.burgkhardt@bmw.de

Middleware-based Security & Privacy for In-car Integration of Third-party Applications

Keywords: Security & Privacy, IP-based Middleware, Automotive Application, Car-to-X Communication

Today's vehicles include up to seventy networked electronic platforms handling simultaneously infotainment and safety functions. Fully connected to the world, the car is now customizable, communicates with several external devices, online services and will be soon hosting third party applications, as our smartphones already do. Such an evolution raises several critical security and privacy issues. While offering numerous advantages, the use of Ethernet, the Internet Protocol (IP) and their associated security protocols as on-board communication standards may not be sufficient. A generic framework focused on information security and on the aforementioned use cases would fill this gap and is still missing. In this paper, we present a combination of car-wide and local security concepts for IP-based middleware securing the integration of unsafe automotive scenarios. We describe the implementation and integration of these mechanisms and show their evaluation.

Introduction

More than just a simple transportation mean, the car evolved into a very complex system, efficiently networking powerful electronic platforms for various purposes. While still serving its primary goal, the car now offers additional mobility services involving road-side units, other cars, smartphones and online services. Like Consumer Electronic (CE) devices, the car will soon host loadable and on-the-fly installable applications allowing better car customization and deeper integration of the aforementioned mobility services [START_REF] Lutz | Renault debuts R-Link, engadget and Renault press release at LeWeb[END_REF]. However, current automotive technologies and requirements for high robustness and low latency slow down the process and let little space for security, an essential parameter considering the numerous security issues and their life threatening consequences, that were recently brought up [START_REF] Koscher | Experimental Security Analysis of a Modern Automobile[END_REF][START_REF] Checkoway | Comprehensive Experimental Analyses of Automotive Attack Surfaces[END_REF].

Part of the solution seems to lie in the use of Ethernet and the Internet Protocol (IP) as standard for both on-board and external communications [START_REF] Glass | SEIS -Security in Embedded IP-based Systems[END_REF]: a larger bandwidth and strong security protocols already designed for the Internet world can secure the communication between two on-board platforms and with external entities. But security considerations only at the communication layer, without considering information security, may remain insufficient. Future use cases will involve large amounts of data, presenting different levels of confidentiality and integrity, originating from in-car and external sources. In order to integrate such unsafe and uncontrollable scenarios, the on-board architecture needs to be secured accordingly and the driver's privacy needs to be protected.

Our approach proposes an on-board integration of several local and distributed security mechanisms: i) a security communication proxy on the edge of the on-board network, which filters inbound and outbound communications [START_REF] Bouard | Automotive Proxy-based Security Architecture for CE Device Integration[END_REF]; ii) a dynamic data flow tracking (DFT) tool based on libdft [START_REF] Kemerlis | libdft: Practical dynamic data flow tracking for commodity systems[END_REF], which monitors third-party applications and iii) an in-band signaling protocol integrated in the communication middleware Etch [START_REF]Etch homepage[END_REF]. Their combination allows a secure tethering of external communication partners with internal functionalities, e.g., original on-board functions, developed by the car manufacturer, or third-party (TP) applications. The resulting framework provides acceptable performances and sufficient flexibility to comply with our security and privacy requirements.

The main contributions presented in this paper are:

-A security model combining complementary IP-based security concepts in a car-wide security framework; -A simple and efficient taxonomy for untrustworthy use cases highlighting the security and privacy/trust context of the communication; -A prototype implementation integrating an automotive middleware, its associated communication proxy and a customized DFT tool.

The rest of the paper proceeds as follows: After having given a brief overview about future automotive on-board architectures, Section 2 presents our use cases and related work. Section 3 introduces our concepts for a car-wide security framework. Then, Section 4 describes our taxonomy for "unsafe" use cases. Section 5 presents the implementation and integration of our IP-based security framework. Section 6 provides our evaluation of our framework and Section 7 our conclusion.

Background and Related Work

In this section background information on future automotive systems and related work about security and privacy are provided. A threat model and some relevant scenarios are presented as well.

Current and Future Automotive Architecture

The automotive on-board network comprises up to 70 Electronic Control Units (ECUs) interlinked by different communication buses and organized in several sub-networks around specific domains (e.g. power train, infotainment). On-board applications are divided in elementary function blocks over several ECUs exchanging broadcasted signal-based messages. Due to internal communication in plaintext and a lack of input validation in the ECUs, cars have been shown to be vulnerable to common attacks exploiting local [START_REF] Koscher | Experimental Security Analysis of a Modern Automobile[END_REF] and remote [START_REF] Checkoway | Comprehensive Experimental Analyses of Automotive Attack Surfaces[END_REF] interfaces. The introduction of Ethernet/IP for vehicle on-board network will be beneficial for both functionalities and security. Firstly, a larger bandwidth will allow to exchange bigger objects (e.g. environment models) internally between ECUs and to comply with future requirements of distributed applications for driver assistance and infotainment [START_REF] Maier | Ethernet -The standard for In-car Communication[END_REF]. Secondly, mature and secure protocols from the Internet world will be instantly applicable. Future automotive applications will certainly require more powerful ECUs and will allow car manufacturers to redesign their software management. On-board applications will remain distributed and the communication management will be simplified thanks to performing engineering-driven middleware infrastructures, abstracting and automating the network addressing and security enforcement [START_REF] Bouard | Driving Automotive Middleware Towards a Secure IP-based Future[END_REF]. In addition the centralization of most external communication interfaces (e.g., LTE, Wi-Fi) around a multiplatform antenna (MPA) [START_REF] Mecklenbrauker | Vehicular Channel Characterization and Its Implications for Wireless System Design and Performance[END_REF] will allow the car makers to design a single security gateway for Car-to-X (C2X) communications.

Threat Model

Today's cars are facing several challenges. Automotive applications are rarely updated and involve more and more new connected features. Their functional behavior relies on complex software, not free from any security flaw [START_REF] Koscher | Experimental Security Analysis of a Modern Automobile[END_REF] and processing considerable amount of sensitive data. An attacker could therefore take advantage of defects in the logic of an application or in a weak security mechanism. This could result in leaks of private information or industrial secrets, threaten the car integrity and in the worst case the life of its occupants.

Use cases & attack scenarios: The scenario for our use cases is depicted in Figure 1 and features both internal and external communication partners. We take the example of a TP application installed on the Head Unit (HU) of "Car 1 ", which is connected to services of the Internet, another car "Car 2 ", a CE device and to several original on-board functions of "Car 1 ". We mainly focus on attack scenarios trying to elude security policies and leveraging the TP application in order to i) compromise internal resources or ii) leak sensitive data to an unauthorized external entity. We consider a TP application functionally conform to the internal API of the car. However, it may present some flaws that are exploitable by an attacker.

(i) Integrity attack scenario: the TP application gets compromised or forwards messages from an external malicious communication partner. As a result the TP application may send bogus packets on the on-board network or access/modify sensitive resources on the HU and may therefore critically disturb the car's functioning. (ii) Confidentiality attack scenario: the TP application gets access to sensitive information, like the driver's home address stored in the navigation system. However even without the authorization to share it, the TP application may still send it to the outside, either directly over the proxy or through an intermediate step, e.g., a forwarding multicast address.

This work aims at improving the information security and addressing the threats related to unfair entities, on which the car manufacturer has no control , while still considering our requirements for high robustness and low latency.

Assumptions: Next-generation ECUs will be equipped with security middleware establishing communication channels over strong security protocols like IPsec [START_REF] Bouard | Driving Automotive Middleware Towards a Secure IP-based Future[END_REF]. In addition they will soon include a hardware secure extension providing secure key storage and secure boot [START_REF]Fujitsu Announces Powerful MCU with Secure Hardware Extension (SHE) for Automotive Instrument Clusters[END_REF]. As a consequence we assume that the middleware and the hardware platform cannot be compromised. Besides, we trust ECUs to establish secure communications to each other and to enforce the expected security mechanisms. We do not consider denial-of-service attacks here.

Related Work

During the last decade, some automotive projects investigated the security issues related to external communications. SeVeCom addressed some of them and designed C2X security mechanisms focused on authentication and encryption [START_REF] Kargl | Secure vehicular communication systems: implementation, performance, and research challenges[END_REF], but did not consider the impact of external inputs on the on-board architecture. The SEIS project proposed a proxy-based architecture for CE device integration [START_REF] Bouard | Automotive Proxy-based Security Architecture for CE Device Integration[END_REF]. The proxy evaluates the security level of the communication and transmits it to the ECU for an adapted security enforcement. Their choice of use cases and security evaluation are limited, but we propose to extend their concept to our architecture. Corporate network security and automotive on-board security present several similarities, e.g., when integrating mobile devices. The corporate approaches rely mostly on strong authentication mechanisms and device integrity measurements in order to establish network connections or a VPN tunnel [START_REF] Detken | Leveraging Trusted Network Connected for Secure Connection of Mobile Devices to Corporate Networks[END_REF]. However they only regulate the network access and usually lack specifications for resources, data management and specifically information flows.

As for the TP application monitoring, we chose to focus on DFT-based approaches. They allow to taint and track data of interest within a running application and have been successfully applied for various purposes, e.g., malware monitoring [START_REF] Yin | Panorama: Capturing Systemwide Information Flow for Malware Detection and Analysis[END_REF] or privacy-aware OS monitoring [START_REF] Enck | TaintDroid: An Information-flow Tracking System for Realtime Privacy Monitoring on Smartphones[END_REF]. These approaches, monitoring the whole OS, rely on a modified runtime environment [START_REF] Enck | TaintDroid: An Information-flow Tracking System for Realtime Privacy Monitoring on Smartphones[END_REF] or on emulators like QEMU [START_REF] Yin | Panorama: Capturing Systemwide Information Flow for Malware Detection and Analysis[END_REF] and require extensive maintenance. They track every machine instruction performed on the host and as a consequence suffer from a significant performance issues. Considering our requirements for robustness and low latency, we orient our work toward a lighter approach monitoring only one process [START_REF] Kemerlis | libdft: Practical dynamic data flow tracking for commodity systems[END_REF]. This is more efficient, does not require any OS or source code modification and has been already used for distributed [START_REF] Zavou | Taint-Exchange: A Generic System for Cross-process and Cross-host Taint Tracking[END_REF] and automotive [START_REF] Schweppe | Security and Privacy for In-vehicle Networks[END_REF] environments. We propose to limit the DFT monitoring to the TP application only and combine it to the middleware for a car-wide security enforcement.

Combining Local Mechanisms for Car-wide Security

Controlling information flows in distributed systems like cars is essential for holistic security. ECUs internally exchange genuine messages and therefore only necessitate secure communication channels and simple access control mechanisms. But integrating unregulated communication partners or software components requires a more complex security model. In addition, ECUs communicate behind the MPA, i.e. communications with an external partner are decoupled at the MPA level. It allows the car to be able to use a suitable communication protocol for outside while using a unique internal security protocol. It also requires the MPA to help the ECU to determine the right security decision to enforce.

For this purpose, we propose to develop an application independent in-band signaling protocol allowing on-board exchanges of security metadata. Concretely we extend the header of the middleware protocol with a field characterizing the context of security and trust, in which data are exchanged over an external network. Instead of directly qualifying the privacy aspect of an information, we chose to focus on the trust we grant an external receiving peer and to quantify that. The security aspect defines how secure the communication is, while the trust aspect indicates how trustworthy the remote device or service is considered to be. We name this context Security & Trust Level (STL) and propose its precise evaluation in Section 4. Two types of STL can be distinguished: the first one, the STL status , describing the actual STL of the received data and the second one, the STL req describing the required STL, necessary to send the data out. The rest of this section presents the three security enforcement points, which make use of the STLs, in more detail: i) the security proxy, ii) the security middleware present on every ECU and iii) the TP application monitoring framework.

Security Proxy

Implemented on the MPA, the security proxy stands in the middle of every communication between an on-board entity and an external partner. The proxy is in charge of managing the external communication channels and their security. For each external partner, it performs a STL status evaluation and extends the header of every inbound message with it. In addition the proxy enforces a coarse domainbased filtering, for example an online service related to a social network won't be able to access on-board functions of the power train management domain. Inversely the proxy will make sure that every STL req received with an outbound message matches the actual STL of the communication in order to send out the message. Section 4 provides more information about the STL-based policies.

Security Middleware

Present on every ECU, the middleware abstracts and automates the communication and security management. The application developers can thereby focus on the functional logic and let the security part to a team of experts. Based on the received STL ( status or req ), the middleware decides whether it is safe and allowed to process the payload. Depending on the middleware capacity, the unsafe or sensitive data can be processed in a security parser, in an isolated environment (e.g., an isolated web-browser for unsafe JavaScript) or handled as private data. Inversely, before sending a message, the middleware automatically integrates its STL req in the payload and trusts the proxy or the receiving ECU to enforce the right decision. The STL req reflects the sensitivity of the data and also in which situation such data may leave the car. The STL-based policies, enforced by the middleware, are defined by the car manufacturer at design time.

TP Application Monitoring Framework

For performance reasons, we limit the DFT-based monitoring only to the TP applications. DFT tools allow to monitor every instruction performed within a running application, i.e. to monitor every system call and to track every data flow between registers and memory. Such tools can raise a warning or stop the runtime in case of a behavior in contradiction to one of its security policies. Besides, they usually rely on dynamic binary instrumentation (DBI) frameworks (named Injector in Figure 2), like Intel's Pin [START_REF]A Dynamic Binary Instrumentation Tool[END_REF], in order to inject custom code into the unmodified application binary, e.g., for the enforcement of a policy. The DFT monitoring can be explained by looking at these three instances: i) the taint sources, ii) the taint propagation and iii) the taint sinks. The rest of this section refers to Figure 2 and the pseudocode it presents.

i) Taint sources: Taint sources are the interfaces, through which new data are entering the TP application. If recognized as data of interest, the data are tainted and the resulting taints are stored in the shadow memory, mapped to the actual memory of the application. The number of taints depends on the expected granularity. Originally, DFT was used to detect attacks related to stack pointers overwriting like buffer overflow or string-format and a simple binary tagging was sufficient. Here we consider data with different levels of sensitivity and therefore need more than two taints (taints and taxonomy are specified in Section 4). In our example, we identify as taint sources the input functions shown at lines 1, 2 and 3 of our pseudocode. The DFT tool monitors these functions and taints the buffer a as private data and b based on the sensitivity of the file. For a network input from an ECU like the buffer c, the framework extracts the present STL req and taints the data according to it. In the case of data received from the proxy, where no STL req is specified, we chose to taint the data as being private like a.

ii) Taint propagation: During runtime, tainted data are tracked while being processed in the application. Data resulting from tainted inputs (e.g., line 4) receive the most relevant taint, i.e. the higher trust and security level. In our example we consider data c received from the sender ECU as not sensitive, whereas the data a are private or "driver-sensitive", so x receives the taint of a.

iii) Taint sinks: The taint sinks are the functions or memory locations where the presence of a taint is checked in order to enforce a policy. The policies generally decide whether the data can be passed to a specific system call or whether they can be used as program control data, e.g. a return address. In our example it concerns the emission of data over the network (line 6). The DFT tool blocks the emission if the destination address is blacklisted, or otherwise automatically adds the most relevant taint in the middleware header. Even with a DFT tool, no packets coming from a TP application can be directly trusted and processed by an ECU. Like for messages from the outside, ECUs have to evaluate whether they are authorized to process the data; if so, they can trust the STL req provided by the DFT tool and keep track of the data sensitivity.

DFT Security policies: We do not trust the TP application or its middleware to enforce any policy, but rely on the DFT tool to do it. We distinguish both static and dynamic rules: a) Static rules: These rules define the taint propagation and the taint management related to user input or file management. They are defined by the car manufacturer and cannot be overridden.

b) Dynamic rules: These rules are loaded with the TP application, in a rule set, similar to the one provided by an Android application. They define which internal and external communications are authorized and specify the trust level of an online service, they will communicate with. This rule set has to be approved and signed by the car manufacture after a testing process. Moreover, a TP application may ask the DFT tool to declassify some data, i.e. taint them with a lower STL in order to send them to an untrusted service. Such cases have to be specified in the rule set as well and concern the driver's data only. For example the declassification of private information may trigger the display of a warning pop-up asking for the driver's approval.

Automotive Security & Trust Taxonomy

In Section 3 we defined the STL as describing the security and trust context in which data are (" req ") or should be exchanged (" status ") between the car and an external communication partner. This section presents its evaluation based on i) security aspects and ii) trust aspects.

i) Security Considerations. We define the Security Level (SL) as a qualitative description of the security strength of an external communication. Concretely, we associate to each C2X security protocol a specific SL value. The different levels and the security requirements, they have to comply with, can be characterized as follows:

-SL=0 : Communications providing no security mechanisms or protocols presenting exploitable design flaws; -SL=1 : Communications providing authentication of the external peer, security integrity for the exchanged message (against unauthorized modifications); -SL=2 : Communication providing authentication, security integrity and strong confidentiality (i.e. one secret key per user, no shared key between users); -SL=3 : Communication using protocols of SL2 level and assuring the presence of a secure hardware element protecting the cryptographic materials on the external communication partner.

Table 1 shows security protocols and their associated SL. ii) Trust Considerations. As explained earlier in Section 2.2, the car contains sensitive data, that have to be controlled when released to the outside. For this purpose, we define the notion of Trust Level (T L), an abstract representation of how trustworthy the data emission and the data receiver are. In the literature [START_REF] Shankar | Online trust: a stakeholder perspective, concepts, implications, an future directions[END_REF][START_REF] Gutowska | Research in Online Trust: Trust Taxonomy as A Multi-Dimensional Model[END_REF][START_REF] Mayer | An Integrative Model of Organizational Trust[END_REF], the notion of trust is usually defined by three major components: reputation, reliability and security. Since the factor security has already been considered in the previous paragraph, we focus here in the two remaining ones. For an efficient T L management and enforcement, we decide to only make use of criteria clear and easy to assess. We consider that sensitive data can be misused, only if they are i) physically and ii) juridically accessible, i.e. i) if the data leave the car and ii) if the data addressee can and is legally allowed to receive them and to endanger the driver's privacy (e.g., information selling/forwarding, data stored on an unprotected server). The T L should thereby reflect these risks. For this purpose we make use of the following criteria: -Criterion 1 (Cr.1) "Local usage": determines whether data have to be used and stored only within the car (e.g., industrial secret). -Criterion 2 (Cr.2) "Anonymization": determines whether data, if released, will have to be anonymized, i.e. whether the addressee will be able to trace back the driver or the car based on the received data . -Criterion 3 (Cr.3) "Jurisdiction": determines whether data have to be released to an online service storing and using the driver's data in "safe" place of jurisdiction (POJ), i.e. whether the service's server are located in a country imposing a regulation protecting the user's privacy.

In order to determine the T L values, we make use of a simple binary decision tree. Every criterion is iteratively evaluated, a "true" answer stops the process and sets the T L as shown in Table 2. Highly sensitive data, like industrial secrets, are only for a internal usage (Cr.1=true) and are tainted as requiring a very trustworthy usage (TL=3). Very sensitive data, like the car position, can leave the car but have to be untraceable (Cr.2=true), i.e. anonymized by the proxy (TL=2). Data with a low sensitivity, like the driver's name, can be forwarded to services presenting a safe POJ (Cr.3=true, TL=1). While Cr.1 and Cr.2 are easy to assess and enforce by the DFT or the proxy, Cr.3 needs to be specified by privacy experts, for example relying on literature inspecting the data protection laws of different countries [START_REF] Ling | Baker & McKenzie -Global Privacy Handbook[END_REF].

In order to test this taxonomy, we evaluate the authorized T L-tainted data of four realistic TP application scenarios: a TP application linked to the social network Facebook [START_REF]Facebook homepage[END_REF]; a TP application for Safebook [START_REF]Safebook homepage[END_REF], a privacy-aware peerto-peer social network allowing the user to locally store its data and having full control about the release thereof; a TP application related to an online banking service having its servers in Germany; and a Local Hazard Warning (LHW) application, broadcasting to other road user safety messages including the car position. Table 3 presents the evaluation results. Because of its servers' unsafe POJ, namely the USA [START_REF] Ling | Baker & McKenzie -Global Privacy Handbook[END_REF], Facebook can only receive non-sensitive data. The Safebook's peers (i.e. "friends") can not be considered as being in a safe POJ and therefore are in the same case as Facebook. The Bank servers in Germany, a safe POJ [START_REF] Ling | Baker & McKenzie -Global Privacy Handbook[END_REF], can receive "TL=1"-and "TL=0"-tainted data. As for the LWH scenario, other cars will receive the "TL=2" tainted data only if the proxy is sure they have been anonymized. Fig. 3: ST L vector and evaluation criteria Even if the taxonomy seems to provide a suitable way to control the data release to the outside, further tests involving more use cases are required. The evaluation parameters are very coarse, but give to the car manufacturer a simple way to define default configuration settings. For more flexibility the driver should be able to temporary taint a piece of information with a lower TL or to upgrade external peers limited to "TL=0" data as peers allowed to receive "TL=1" data.

Managing and Enforcing STL rules

We consider security and trust as two independent variables requiring two different types of enforcement. Anonymized data with a TL=2 may be sent with a SL=1 in plaintext (e.g. LHW scenario), while data of TL=1 may be sent with a SL=2 because the driver wants to keep them private. Therefore we define the STL as the concatenation of the SL and the TL, as shown in Figure 3. For an efficient enforcement, we limit ourselves to 4 values for the SL and 4 for the TL and can code the resulting vector on 4 bits.

Concretely, tainted data arriving on the proxy will be allowed to be released to an external peer X: i) if X complies with the conditions of the received TL and ii) if the external communication's SL is higher or equal to the one received. This implies for the DFT engine, that a buffer processed from several pieces of information will be assigned their higher SL and TL. However with such rules data can only flow to a higher level of trust and security and risk to never be able to leave the car. Declassification methods to assign a lower STL have to be possible, but have to be part of cases defined by the car manufacturer and if necessary involving the driver's decision.

As previously said, the STL-based policies of the ECUs are statically defined at design time by the car manufacturer. The STL management does not require any update of the ECUs. Either the ECU generated the data and associates to them a STL req according to its policy, otherwise the ECU received the data and can also label them with the received STL req . In addition, DFT engine and proxy can receive notifications to update the authorized TL values of external entities and the SL of a protocol for example via the security rule set provided by a TP application. As for the CE device case, the proxy authenticates the device as belonging to the driver and attributes an adapted STL status to it, i.e. with a SL dependent on the used protocol and a TL=1 since we assume that the driver's smartphone is under her control and therefore safe to handle sensitive data.

Implementation

This section describes the extensions, that we implemented in order to combine the DFT tool libdft, the middleware Etch and its associated communication proxy.

The Middleware: As prototype basis for our implementation, we chose the middleware Etch, an open-source software project under the Apache 2.0 license. Etch features a modular and extensible architecture providing an efficient serialization and is considered as a serious candidate for the automotive purpose [START_REF] Weckemann | Lessons from a Minimal Middleware for IP-based In-car Communication[END_REF]. We made use of the C-binding and extended the header by four bits, in order to add the ST L field. Authorized ST L can be specified before the code generation thanks to an adapted interface description language (IDL).

Regarding the communication proxy, we extended the Etch-proxy developed in Java for [START_REF] Bouard | Automotive Proxy-based Security Architecture for CE Device Integration[END_REF] and adapted it to the new payload serialization. The proxy provides two communication interfaces and automates the service discovery for both internal and external peers. Internal and external communication partners communicate over a mirror-service, making the communication decoupling totally transparent. Depending on the actual communication features (e.g., network interface, IP address or protocol used), the proxy performs on-the-fly evaluation of the ST L and an adapted filtering for both ingress and egress traffic.

The DFT tool: As for the monitoring tool we chose libdft [START_REF] Kemerlis | libdft: Practical dynamic data flow tracking for commodity systems[END_REF], a dynamic DFT framework relying on the Intel Pin [START_REF]A Dynamic Binary Instrumentation Tool[END_REF] for binary instrumentation. libdft provides an implementation of the shadow memory allowing an efficient taint propagation and a well-defined API for system call monitoring. Limited to a simple binary tainting (i.e. a bit of the shadow memory tainting a byte of the real memory) we extended the taint propagation mechanisms, in order to have a byte of memory tainted by two values of two bits each, so four bits total.

More than monitoring all inputs, our framework now differentiates a user input (i.e. standard input from the keyboard) from a file input and tags them accordingly. The framework manages the access to files present on the HU thanks to a white-list specifying for each TP application how to tag information read from a file and how data should be tainted in order to be written in a file. The framework monitors system calls related to network inputs and outputs. It allows us to taint ingress traffic depending on the IP address of origin (proxy's case) or on the provided taint present in the payload (ECU's case). For outbound messages, the framework automatically determines the different taints of the payload data and injects the most relevant one directly in the middleware header.

Testing environment: We performed the implementation and the experiments described in Section 6.1 on several computers interlinked with Gigabit Ethernet and running standard 32-bit Fedora Linux on an Intel Atom N270 (1,6 GHz) with 1GB RAM. While being more resourceful than most of the embedded platforms in cars, they provide performances similar to a HU [START_REF] Bmw | Navigation system Professional[END_REF]. Besides we did not perform extensive modifications of the Etch middleware mechanisms, providing suitable performances when tested on a microcontroller [START_REF] Weckemann | Lessons from a Minimal Middleware for IP-based In-car Communication[END_REF]. Therefore we believe that the addition of this access control layer should not significantly slow down the system. Though this should be verified for a more rigorous validation.

Evaluation

In order to evaluate our system, we quantify in this section the performance overhead of our implementation and discuss several of its security aspects.

Performance Evaluation

Considering the limited space in this paper and our focus on the integration of TP applications, we will limit ourselves to the performance evaluation of our DFT framework. Benchmarks are run on two separated machines running a simple Etch service: a client sends a buffer over UDP and waits for an answer from a DFT monitored server. The server taints the received data and copies it in another location. A tainted integer is produced based on the same data and is sent back to the server with its associated taint, which is injected in the midlleware header. We measure the throughput of the client (call/sec) in order to demonstrate the communication overhead of our DFT framework, i.e. tainting a buffer and taking a decision as for sending a tainted information over the network. This experiment does not generate much application processing, but mostly stresses the middleware mechanisms. We performed the measures for different buffer sizes (from 128 to 8192 bytes) and different versions of the DFT engine. First we performed our tests for a native execution without any DFT engine ("null") that we use as reference. Then we did the same with the framework Pin alone, in order to get a lower bound overhead imposed by the instrumentation framework, i.e. without enforcing any security policies or memory tainting. Finally we made use of the original version of libdft [START_REF] Kemerlis | libdft: Practical dynamic data flow tracking for commodity systems[END_REF] ("libdft.v1") and of our customized version ("libdft.v2"), in order to compare the impact of the taint number. The results of Figure 4 presents the throughput average for each case, calculated from 10 time measurements of 5000 calls each.

Discussion: The performance results in Table 4 show that the Pin binary instrumentation is responsible for a significant part of the application overhead (∼10%). Even if the framework is not enforcing any policies, Pin gets control of the execution each time a new instruction is invoked in order to provide the new compiled code to run before the next instruction. A second significant overhead (∼10-20%) is resulting from the library libdft itself and is caused by the taint propagation mechanisms and the system call monitoring. The induced performance overhead is less consequent for bigger buffers. The instrumentation of the socket connection calls seems to be mostly responsible for this. Finally our tests show an additional overhead when using the customized versions of libdft. Increasing the complexity of the taint mechanisms, of the system call monitoring and extending the shadow memory slow down the system performances (∼10%).

As previously mentioned, our evaluation is mostly focused on our middleware and the libdft library with a simple application. Tests performed with this DFT engine and bigger applications like a web-browser [START_REF] Kemerlis | libdft: Practical dynamic data flow tracking for commodity systems[END_REF] or a MP3-player [START_REF] Schweppe | Security and Privacy for In-vehicle Networks[END_REF] have shown more significant latency. The use of a DFT framework adds a significant performance penalty but remains suitable for infotainment applications requiring a limited bandwidth (up to 5,4 Mbit/s). For optimal performances, the TP Fig. 4: Middleware throughput average for various buffer sizes and binary instrumentation methods.

. applications should remain small and simple and maximize the use of "trusted", i.e. non monitored, libraries. A second approach, not investigated here, would be to run the application in a fully virtualized environment providing isolation but less control during runtime, e.g., XEN [START_REF]Xen R hypervisor homepage[END_REF]. Then we limit our evaluation to buffers with a size inferior as 8192 kBytes, because the Etch version we used has been optimized for relatively small payload. Further investigation are recommended for more realistic and bigger networks, generating more traffic, in order to test the suitability of this system for more demanding use cases, e.g. video streaming and safety applications.

Security Evaluation

For this section we refer to the attack scenarios presented in Section 2.2 and describe how our system would react to such attacks. Both scenarios feature an attacker getting control of the TP application by launching for example an attack related to the overwriting of a stack pointer. By design, the DFT can detect such exploits and stop the program. As result, the attacker cannot compromise the TP application integrity to perform our attack scenario. About the integrity attack scenario: This scenario considers an unauthorized access of a HU resource (e.g., file or process) aiming at disturbing the platform functionality. The DFT engine can monitor every system call and function invoked by the TP application. It can therefore blacklist the function and process that the TP application should not get access to and can restrict its file access in writing and reading. This scenario also considered the case of a TP application sending bogus packets to an ECU in order to disturb its functioning. The DFT engine controls the socket management and only allows communication with authorized ECUs. Then based on the received STL, provided by the DFT engine, the ECU is aware of the potential risk and adapts its data processing.

About the confidentiality attack scenario: This scenario mostly considers the release of sensitive information to the outside. The TP application can receive information through multiple ways: by accessing shared memory, via filesystem access, with inter-process communications or from the network. The DFT engine monitors every of these input channels and taints data coming from them according to their sensitivity. On the other hand, the only way to release the information is through the network and then over the proxy. The DFT engine monitors the socket, which tainted information are going through, to which destination and can therefore block an unauthorized flow. If the framework cannot enforce a decision, the addition of the STL req value in the message header allows the proxy to enforce a final decision based on the actual information sensitivity.

Unlike OSes like Android, which control applications with a limited set of coarse permissions, our DFT engine allows a very fine granular security enforcement. It monitors every invoked function, every Input/Output (I/O) channel of the TP application and tracks every byte of the application memory. The taint values, coded over four bits, offer sixteen different values expressing as much sensitivity levels. Such monitoring allows the application to remain functional even when simultaneously handling very sensitive data and communicating with untrusted sources. Let's take the example shown earlier in Figure 2: the TP application takes as input non-sensitive (TL=0) and sensitive (TL=3) data, but is still able to generate outputs tainted as "not containing any sensitive information" (TL=0) and those can be sent out. Monitoring the middleware and injecting a taint in its header allows us to export the local DFT benefits all over the on-board network. The in-band middleware protocol makes on-board applications information security aware and contributes to a homogeneous security enforcement in the whole car. However we do not propose any formal evaluation of the STL taxonomy in this paper. Our goal was to describe concrete examples of security and trust levels based on clear security requirements and quantitative parameters.

About some system limitations and countermeasures: Several drivers can drive a single car and may be joined by some passengers. The DFT engine we use only monitors an application and implicitly considers a unique car user. But it would be quite simple to associate the monitored application to one user. The modifications will mostly concern the middleware. The taint field of the middleware header could be extended in order to contain a user ID. Then STL-based policies should be adapted in the whole system in order to take into account the different user requirements.

Then, we assumed in Section 2.2 that the integrity of the OS and the middleware were ensured by a secure boot. But these mechanisms do not protect against runtime attacks, which could be significantly harmful when being performed on critical entities like the proxy or the HU. They may be detected by host-based intrusion detection tools performing scans and recognition of instruction patterns within a running platform [START_REF] Garfinkel | A Virtual Machine Introspection Based Architecture for Intrusion Detection[END_REF]. Though these solutions might significantly degrade the system performance and should be used in a carefully selected manner.

Conclusion

Upcoming automotive applications and use cases will require higher security standards in order to preserve the car integrity and to protect the information it contains. In this paper we presented a security architecture, leveraging dynamic data flow tainting engine in order to secure an automotive integration of third-party applications and external communication partners. At a local level, the DFT engine monitors the TP application and tracks/taints every byte of information it processes during its execution. The framework locally controls the network I/O and manages security metadata provided by the middleware in-band protocol, in order to enforce adapted security policies, locally and remotely on other ECUs. In addition, we proposed a security and trust taxonomy for external "unsafe" use cases, integrated to our concepts and supporting a distributed middleware-based policy enforcement. While enhancing the security and privacy in cars, such mechanisms have shown some limitations in term of performance and may be not used for any use case, especially the time-critical ones. As following work we will determine the necessary trade-off between granularity and efficiency for an optimal use of such mechanisms. Besides we will investigate alternative solutions making use of full virtualization. Finally we intend to refine our T L concepts and take into account user preferences while still ensuring a secure management of private information.

Fig. 1 :

 1 Fig. 1: Automotive scenario and considered communication channels. Solid rightangle lines represent the wired on-board network. The dashed arrows represent external communications over different wireless networks.

Fig. 2 :

 2 Fig. 2: Overview of the DFT framework in the on-board network. The solid lines show the input and output data of the TP application. The dashed arrows show the instrumentation of the system calls related to the taint sources (1-3) and sinks (4) monitored by the Injector. m1 and m2 represent tainted messages sent respectively to and from the TP application. The circled numbers link the functions of the pseudocode (right side) to their instrumentation (left side).

Table 1 :

 1 Examples of security protocols ordered within the SL scale.

Table 2 :

 2 Method for T L evaluation.

		Decision tree				Which criteria are fulfilled?
	Cr.1 → Cr.2 → Cr.3 → TL		Scenarios Cr.1 → Cr.2 → Cr.3 → TL
	Case 1 true	-	-	3		Facebook false	false	false	0
	Case 2 false	true	-	2		Safebook false	false	false	0
	Case 3 false	false	true	1	.	Banking false	false	true	1/0
	Case 4 false	false	false	0		LHW	false	true	-	2/1/0

Table 3 :

 3 Scenarios and authorized data T L. (LHW: Local Hazard Warning).

Table 4 :

 4 Normalized throughput performance. The case without instrumentation is taken as reference.

	Buffer
	size	null Pin libdft.v1 libdft.v2
	(kByte)
	128	1 0,94 0,75	0,69
	256	1 0,90 0,71	0,67
	512	1 0,92 0,78	0,66
	1024	1 0,89 0,85	0,71
	2048	1 0,93 0,83	0,66
	4096	1 0,87 0,86	0,71
	8192	1 0,87 0,85	0,80
	average 1 0,90 0,80	0,70