Olivier Darné

Amélie Lemna

Charles

Volatility estimation for Bitcoin: Replication and robustness

Keywords: Bitcoin, GARCH, volatility, jumps. JEL Classification: C22, C50, G10

Katsiampa [Volatility estimation for Bitcoin: A comparison of GARCH mod-els.

Economics Letters, 158, 3-6, 2017] compares several GARCH-type models to estimate volatility for Bitcoin returns. First, we propose a replication study (i) by verification, using the same sample and period (July 2010 to October 2016), and (ii) by reproduction, extending the sample until March 2018. We obtain only partially different results from those of Kasiampa (2017) on both samples. Sec-ond, we propose a robustness analysis (i) by reanalysis, using the robust QML estimator for computing the standard errors of the parameters, and (ii) by exten-sion, taking into account the presence of jumps in the Bitcoin returns. The results show that the six GARCH-type models studied, namely GARCH-type models characterized by short memory, asymmetric effects, or long-run and short-run movements, seem not to be appropriate for modelling the Bitcoin returns.

Introduction

Reproducibility, replicability and robustness are fundamental characteristics of scientific studies. Replication, reproduction and robustness studies stimulate scientific rigor and enhance the validity and reliability of published research. Burman et al. (2010) emphasize that replication is a critical tool for scientific progress and that the absence of such studies "is particularly problematic because empirical economic research is often prone to error". [START_REF] Andersen | No-arbitrage semi-martingale restrictions for continous-time volatility models subject to leverage effects, jumps and i.i.d. noise: Theory and testable distributional implications[END_REF] However, there is no consensus on definitions for the concepts of reproducibility, replicability and robustness (see, e.g., Arulampalam et al., 1997; Pesaran, 2003; Hamermesh, 2007; Clemens, 2017), which can lead to confusion. In order to avoid confusion on these concepts Clemens (2017) identifies four categories that we present briefly in Figure 1: 2 These issues are of increasing importance for the scientific literature as shown by the computational infrastructures (e.g., runmycode.org, Hurlin et al, 2012, codeocean.com), the websites providing information on replication studies (e.g., Replication in Economics or Replication Network), the special sections proposed by some journals (e.g., "Replication section" in Journal of Applied Econometrics or "Data, Tools, and

Replication" in International Economics, the special issue on replication in Energy Economics), the replication policy to make data and code available by some journals on their website (e.g., The American Economic Review, Econometrica, Review of Economic Studies, Journal of Applied Econometrics, etc.) [START_REF] Baur | Bitcoin, gold and the US dollar -A replication and extension[END_REF] Cryptocurrencies, such as Bitcoin, are a new breed of digital currency systems built on computer cryptology and decentralized (peer-to-peer) network architecture.

Bitcoin, the most popular virtual (digital) currency and cryptocurrency (Nakamoto, 2008), is an open source virtual currency, as it is managed by an open source software algorithm that uses the global internet network both to create Bitcoins as well as to record and verify its transactions. [START_REF] Böhme | Bitcoin: Economics, Technology, and Governance[END_REF] While central authorities and central banks guarantee or have control over standard (fiat) currencies, Bitcoin is fully decentralized and depends on a sophisticated protocol that uses only cryptography to control transactions, manage its supply, and prevent harmful actions that may endanger the system. All transactions are stored digitally and recorded in a shared ledger data technology known as blockchain (see, e.g., Dwyer, 2015; Böhme et al., 2015). [START_REF] Bollerslev | Generalized Autoregressive Conditional Heteroskedasticity[END_REF] Since its inception in January 2009, Bitcoin exhibits an extreme increase of its market

Replication study

In this section we follow Katsiampa (2017) and consider the returns series r t , described by a Normal AR(1)-GARCH(1,1) model:

r t = µ t + ε t , µ t = c + ∞ ∑ i=1 ξ i ε t-i , (1)
ε t = σ t z t , z t ∼ i.i.d.N(0, 1), (2)
σ 2 t = ω + αε 2 t-1 + βσ 2 t-1 , (3)
where ε t is the error term, z t is a white noise process, σ t is the conditional standard deviation, and ξ i are the coefficients of

ξ(L) = φ -1 (L) = 1 + ∑ ∞ i=1 ξ i L i
, with L the lag operator and φ(L) the AR polynomial of order 1.

For the conditional variance σ 2 t we consider six different GARCH-type models, namely GARCH (Bollerslev, 1986), EGARCH (Nelson, 1991), GJR-GARCH (Glosten et al., 1993) [START_REF] Bouri | On the return-volatility relationship in the Bitcoin market around the price crash of 2013[END_REF] , Asymmetric Power ARCH (APARCH, Ding et al., 1993), Component GARCH and Asymmetric Component GARCH (CGARCH and ACGARCH, respectively, Engle and Lee, 1993) models. A brief presentation of the models is given in Table 2. [START_REF] Burman | A call for replication studies[END_REF]

Replication by verification

We use the same data and sample period as in Katsiampa (2017), covering July 18, 2010 to October 01, 2016 (2 268 observations). [START_REF] Carnero | Outliers and conditional autoregressive heteroskedasticity in time series[END_REF] The Bitcoin returns are calculated as the first differences of the logarithmic prices, defined by r t = log P tlog P t-1 , where P t is the observed price at time t. The graphical representations of prices, returns and volatility are in Figure 1.

The replication of the summary statistics for Bitcoin returns are presented in Table 1 (Panel A). However, the values are not equal to Katsiampa (2017), whatever the descriptive statistics. We then compute the descriptive statistics on the Bitcoin returns calculated as arithmetic returns defined by r g t = (P t -P t-1 )/P t-1 and find exactly the same values to those displayed in Katsiampa (2017). Even if the different approaches to calculate the returns do not change the main characteristics of Bitcoin [START_REF] Bouri | On the return-volatility relationship in the Bitcoin market around the price crash of 2013[END_REF] Note that Katsiampa (2017) estimates a TARCH model whereas we estimate a GJR-GARCH model. However, the estimated parameters are the same because EViews proposes the estimation of a TARCH model but its TARCH model is estimated on σ 2 t and not on σ t as defined in Rabemananjara and Zakoian (1993). Its TARCH specification is rather similar to the GJR-GARCH model of Glosten et al. (1993). [START_REF] Burman | A call for replication studies[END_REF] The parameters of the volatility models are estimated by the quasi-maximum likelihood (QML) method and the quasi-likelihood function is maximized using the quasi-Newton method of Broyden, Fletcher, Goldfarb and Shanno (BFGS) with the Marquardt correction, namely the same code and software as in Katsiampa (2017). In a previous version of the study we have used the Berndt-Hall-Hall-Hausman (BHHH) algorithm with the Marquardt correction, from the default option of EViews 7.0. Katsiampa (2017) did not give information about the software package used in estimation, what the default estimation methods are, such as method to optimize the likelihood function or how the standard errors are computed. We have tried different software packages and only EViews produced similar results to those obtained in Katsiampa (2017). However, in an author's reply to this previous study she mentions that the BFGS optimization method with Marquardt step method was employed, and the standard errors were computed from the outer product of the gradient (OPG) estimator, from the default option of EViews 9.0. 10 Bitcoin price data is downloaded from coindesk.com.

returns, namely highly non-Normal, evidence of significant excess skewness and kurtosis, and strong conditional heteroscedasticity, except for excess skewness which is with the opposed sign, these differences could have implications in the estimation of GARCH-type models.

Table 3 shows the estimation results of the GARCH-type models, computed using

Replication by reproduction

We now propose a replication by reproduction of the Katsiampa's (2017) study by estimating the GARCH-type models on a longer period, namely until March 22, 2018, producing 2, 803 observations (see Figure 2). For this analysis we use Bitcoin logarithmic returns, r t .

Table 1 (Panel B) presents the summary statistics and shows the same main characteristics as those for the shorter period, namely highly non-Normal, evidence of significant excess skewness and kurtosis, and strong conditional heteroscedasticity.

After the estimation of the models, the AR(1)-CGARCH model seems to be again the best specification (Table 5).

Robustness analysis

In this section we first reanalyze the study of Katsiampa (2017) by computing robust standard errors of the parameters in the GARCH-type models, and second we extend her study by taking into account the presence of jumps, which can be classified as robustness tests.

Robustness by reanalysis

Since the Bitcoin returns are characterized by non-Normality we apply a more appropriate estimator for computing standard errors rather than the outer product of the gradient (OPG) estimator. For that, the so-called QML "sandwich" estimator (also known as robust covariance matrix estimator or heteroscedasticity-consistent covariance matrix estimator) proposed by Bollerslev and Wooldridge (1992) is used to compute robust standard errors of the parameters in the GARCH-type models.

The covariance matrix is estimated using both matrices of second order derivatives (the Hessian matrix, H(.)) and outer products of first derivatives (or OPG, B(.)) of the log-likelihood function:

Q( θ) = H( θ QML ) -1 B( θ QML )H( θ QML ) -1 ,
where θ QML is the robust QML estimator of θ, and the coefficient standard errors as the (robust) Bollerslev-Wooldridge standard errors. [START_REF] Carnero | Effects of outliers on the identification and estimation of the GARCH models[END_REF] The results are displayed in brackets in Table 3 and show that the asymmetric parameters are become not statistically significant for all the asymmetric models. This finding is not consistent with the presence of asymmetry detected from asymmetric The GARCH model is the only volatility model for which all the parameters are [START_REF] Carnero | Effects of outliers on the identification and estimation of the GARCH models[END_REF] Katsiampa (2017) uses the OPG estimator for computing standard errors, given by

I( θ) ≈ E B( θ) = E ∑ T t=1 G t ( θ)G t ( θ) = E ∂lnL ∂θ ∂lnL
∂θ , with G(.) the gradient matrix.

statistically significant, however its stationarity and fourth-moment conditions are not satisfied.

In Table 5 we estimate the GARCH-type models on the longer period (2010-2018) and the robust QML t-statistics are given in brackets. The results confirm those obtained for the shorter period.

Robustness by extension

We apply the semi-parametric procedure to detect jumps proposed by Laurent et al.

(LLP) (2016). Their test is similar to the non-parametric tests for jumps in Lee and Mykland (2008) and Andersen, Bollerslev, and Dobrev (2007) for daily data.

The returns r t are described by the AR(1)-GARCH(1,1) model of equations ( 1)-( 3).

Consider the return series with an independent jump component a t I t , defined as:

r * t = r t + a t I t , (4)
where r * t denotes the observed returns, I t is a dummy variable for a jump on day t, and a t is the jump size. In equation ( 4) a jump a t I t will not affect σ 2 t+1 (the conditional variance of r t+1 ), so that we can have non-Gaussian fat-tailed conditional distributions of r * t . The bounded innovation propagation (BIP)-AR(1) proposed by Muler, Peña and Yohai (2009) and the BIP-GARCH(1,1) of Muler and Yohai (2008) is used to obtain robust estimates of µ t and σ 2 t respectively in equations ( 1) and (3). These are denoted by µ t and σ t and are robust to potential jumps a t I t (i.e. they are estimated on r * t and not on r t ). The BIP-AR(1) and BIP-GARCH(1,1) are defined as:

µ t = µ + ∞ ∑ i=1 ξ i σ t-i ω MPY k δ ( J t-i ), (5)
σ 2 t = ω + α 1 σ 2 t-1 c δ ω MPY k δ J t-1 2 + β 1 σ 2 t-1 , (6)
where ξ i are the coefficients from the AR(1) polynomial defined in equation (1),

ω MPY k δ (.
) is the weight function, and c δ a factor ensuring that the conditional expectation of the weighted square of unexpected shocks equals the conditional variance of r t in the absence of jumps (Boudt et al., 2013).

Consider the standardized return on day t given by:

J t = r * t -µ t σ t . (7)
LLP detect the presence of jumps by testing the null hypothesis H 0 : a t I t = 0 against the alternative H 1 :

a t I t = 0. The null is rejected if max T | J t | > g T,λ , t = 1, . . . , T, (8)
where g T,λ is the suitable critical value. [START_REF] Ciaian | Virtual relationships: Short-and long-run evidence from BitCoin and altcoin markets[END_REF] If H 0 is rejected a dummy variable is defined as follows:

I t = I | J t | > k , (9)
where I(.) is the indicator function, with I t = 1 when a jump is detected at time t. The filtered returns r t are obtained as follows:

r t = r * t -(r * t -µ t ) I t . (10)
Laurent et al. ( 2016) extend this test for additive jumps in AR-GARCH models, called BIP-AR-BIP-GARCH models, to AR-GJR-GARCH models, called BIP-AR-BIP-GJR models, to account for asymmetric effects.

In Table 4, detected jumps are given with their timing and t-statistics as well as the percent changes. A number of jumps is found in the daily Bitcoin returns during the whole period, giving strong proof of infrequent large shocks. This finding shows the importance to take into account these large shocks in modelling the volatility of Bitcoin returns. We also try to associate the date of each jumps with a specific event that occurred near that date, presenting the jump dates in chronological order.

Overall, most of jumps seem to be associated with attacks, hacks, thefts, closings or bankruptcies of Bitcoin exchange platforms and Bitcoin services, such as the hacking of the Japanese-based Mt.Gox exchange (-49%) on June 11, 2011. [START_REF] Clemens | The meaning of failed replications: A review and proposal[END_REF] We just give few detailed explanations on jumps associated with "technical" issues of Bitcoin due to its specific functioning. Bitcoin Core is the reference implementation of Bitcoin. Initially, the software was published by Satoshi Nakamoto under the name "Bitcoin", then "Bitcoin-Qt" and later renamed to "Bitcoin Core" to distinguish [START_REF] Ciaian | Virtual relationships: Short-and long-run evidence from BitCoin and altcoin markets[END_REF] The critical values are defined by g T,λ =log (log(1λ)) b T + c T , with b T = 1/ √ 2 log T , and The estimation results of the GARCH-type models on the filtered returns (Panel B, Table 5) show that the better specification for the Bitcoin returns is the GARCH model, as this is the only volatility model for which all the parameters are statistically significant. The value of α decreases and the value of β increases when the data are cleaned of jumps. This finding is in line with those of Carnero et al. (2001, 2007), showing that this behavior on volatility parameters can be due to jumps. The stationarity condition is satisfied but the existence of the fourth moment is not satisfied.

c T = (2 log T ) 1/2 -[log π + log(log T )]/[2(2 log T ) 1/2 ].
Finally, our results suggest that asymmetric and component GARCH models are not appropriate for modelling the Bitcoin returns as well as the standard GARCH model.

Conclusion

This paper proposed a replication in two ways of the Katsiampa's (2017) study on volatility estimation for Bitcoin returns based on six GARCH-type models, where the best specification is the AR-CGARCH model. We first replicated by verification on the same sample and period (2010-2016), and second by reproduction on a longer period (2010-2018). Our results are only partially different from those of Kasiampa (2017) in terms of values of GARCH coefficients and t-ratios due to the difference in computing the returns. We then proposed robustness tests in two ways. We first reanalyzed her study by using robust QML estimator which is robust to conditional non-Normality to produce standard errors of the estimated parameters. We found that all the GARCHtype models are rejected because either the parameters are not statistically significant or the stationarity condition is not satisfied. Second, we extended the study by detecting jumps in volatility and analyzing their effect on volatility modelling on the Bitcoin returns. We found that the Bitcoin returns are strongly characterized by the presence of jumps. The results on the filtered returns show that the six GARCHtype models studied, namely GARCH-type models characterized by short memory, asymmetric effects, or long-run and short-run movements, are not appropriate for modelling the Bitcoin returns. Therefore, it would be interesting to extend this work to long-memory and Markow-switching multifractal models.

GARCH σ 2 t = ω + αε 2 t-1 + βσ 2 t-1 ω > 0, α ≥ 0, α + β < 1 β ≥ 0 GJR-GARCH σ 2 t = ω + (α + γ I t-1 ) ε 2 t-1 + β σ 2 t-1 ω > 0, α, γ, β ≥ 0 α + β + (γ/2) < 1 α + γ ≥ 0 EGARCH ln(σ 2 t ) = ω + g(z t-1 ) + β ln(σ 2 t-1 ) |β| < 1 g(z t ) = θ 1 (|z t | -E(|z t |)) + θ 2 z t APARCH σ δ t = ω + α (|ε t-1 | -γε t-1 ) δ + βσ δ t-1 ω > 0, α ≥ 0, β ≥ 0, -1 < γ < 1 CGARCH σ 2 t = q t + α(ε 2 t-1 -q t-1 ) + β(σ 2 t-1 -q t-1 ) α, β, θ ≥ 0 0 < α + β < ρ ≤ 1 q t = ω + ρ(q t-1 -ω) + θ(ε 2 t-1 -σ 2 t-1 ) ω > 0 θ < β < 1 ACGARCH σ 2 t = q t + α(ε 2 t-1 -q t-1 ) + β(σ 2 t-1 -q t-1 ) 0 ≤ α < ρ, ω > 0, 0 ≤ θ < β 0 ≤ ρ < 1 +γ(ε 2 t-1 -q t-1 ) I t-1 0 ≤ β < (ρ -α) q t = ω + ρq t-1 + θ(ε 2 t-1 -σ 2 t-1 ) 0 ≤ γ < (ρ -α -β)
Notes: where I t-1 = 1 if ε t-1 < 0, and 0 otherwise. The existence of the fourth moment implies that LL is the log-likelihood value, AIC and HQ correspond to the Akaike and Hannan-Quinn criteria, respectively. Q (10) and Q 2 (10) are respectively the Box-Pierce statistics with lag 10 of the standardized and squared standardized residuals. These are asymptotically distributed as

E[ε 4 t ] < ∞, which is satisfied if kα 2 + 2αβ + β 2 < 1 and kα 2 + 2αβ + β 2 + βγ + kαγ + kδγ 2 < 1 for the GARCH(1,
χ 2 (k),
where k is the lag length. ARCH( 5) is the ARCH LM test with lag 5. This is distributed as

χ 2
(q), where q is the lag length. * and * * indicate that the null hypothesis is rejected at the 5% and 10% level, respectively. The standard and robust t-ratios appear in parentheses and brackets, respectively. The best in-sample criteria appear in bold.

  arithmetic (Panel A) and logarithmic returns (Panel B). The comparison between the volatility models is effected via various in-sample criteria: Log-Likehood (LL), Akaike (AIC) and Hannan-Quinn (HQ). Each time, the best model appears in bold showing the highest value of LL and the lowest values of AIC and HQ. The residual tests are also shown to see whether the chosen volatility model is the most appropriate.When estimating GARCH-type models on returns computed as arithmetic returns we find exactly the same values for GARCH parameters, t-ratios, in-sample criteria and residual tests as inKatsiampa (2017), whatever the GARCH-type models, except for the ACGARCH models where the estimations are slightly different. Nevertheless, we also find that the Bitcoin volatility is best modelled by the AR(1)-CGARCH model.When estimating GARCH-type models on returns computed as logarithmic returns we find similar values of GARCH coefficients and t-ratios for all the GARCH-type models. The AR(1)-CGARCH model stays the best specification for the Bitcoin returns. Overall, our results are only partially different from those of Kasiampa (2017) due to the difference in computing the returns.

  volatility models by Katsiampa (2017), Bouri et al. (2017) and Baur et al. (2018).[START_REF] Charles | Relevance of detecting outliers in GARCH models for modelling and forecasting financial data[END_REF]

Finally, as emphasizedFigure 1 :

 1 Figure 1: Bitcoin prices, returns and squared returns -July 2010 to October 2016.

  1) and GJR-GARCH(1,1) models, respectively. Under a Normal distribution k = 3 and δ = 1 2 .

  Laurent et al. (2016) suggest setting λ = 0.5. from the network. On 19 March, 2012, a bug on Bitcoin-Qt implies a fall of Bitcoin (-11.9%). On 18 August, 2015, Bitcoin Core developers Mike Hearn and Gavin Andresen release a separate version of the Bitcoin client software, called Bitcoin XT.

	Bitcoin XT implements BIP 101 15 , which proposes replacing the fixed one megabyte
	maximum block size with a maximum size that grows over time at a predictable rate.
	The release of Bitcoin XT culminated fears that the Bitcoin community may not be
	able to reach a consensus on the issue, and the blockchain may hard fork, resulting in
	two separate versions of Bitcoin's global ledger (-16%). On July 20, 2017, the Bitcoin
	averted a split into two currencies after its network (miners) supported an upgrade to
	its software, the so-called BIP 91 through a software called SegWit2x (Segregated Wit-

[START_REF] Clemens | The meaning of failed replications: A review and proposal[END_REF]

Note that the year 2010 is characterized by a lot of zero returns. it ness), that would enhance its ability to process an increasing number of transactions

(22.6%)

. The announcement of the first version of the Lightning Network protocol on January 16, 2018 can explain the fall of Bitcoin (-18%). This payment protocol is touted as a solution to the Bitcoin scalability problem. It could enable (almost) instant transactions between participating, including micro-transactions, for a very low price.

Table

1

(Panel B) presents the summary statistics for the filtered returns and show that the jump-filtered returns ( r t ) also exhibit excess skewness, excess kurtosis and conditional heteroscedasticity, although the excess kurtosis and skewness decrease dramatically. Note that the original returns exhibit negative excess skewness while the filtered returns display positive excess skewness, signifying that the series have a longer right tail (extreme gains) than left tail (extreme losses).

Table 1 :

 1 Descriptive statistics.Notes: * * denotes significance at the 5% level. Growth rate and Log 1st diff. indicate that the returns are calculated as a growth rate, defined by r Original and Filtered indicate that the descriptive statistics are calculated on the original and jump-filtered returns, respectively, and the returns are calculated as the first differences in the logs of the prices.

	ARCH(5)		54.36935 *	59.47672 *		72.52037 *	124.5632 *
	Obs. Mean Median Max Min Std. Skew Kurt JB	Panel A: 2010-2016	Growth rate 2267 0.005778 0.000290 0.528947 -0.388309 0.061737 0.857187 * 15.11666 * 14145.36 *	Log 1st diff. 2267 0.003894 0.000290 0.424580 -0.491528 0.061248 -0.371206 * 14.96872 * 13583.25 *	Panel B: 2010-2018	Original 2803 0.004103 0.001427 0.424580 -0.491528 0.058896 -0.355962 * 14.63687 * 15874.73 *	Filtered 9.984921 * 5717.31 * 2803 0.005080 0.001970 0.308564 -0.332134 0.049564 0.202438 *	g t = (P t-1 , and as the first differences t-1 )/P t -P	in the logs of the prices, defined by r t = log P t -log P t-1 , respectively, where P

t is the observed price at time t.

Table 2 :

 2 GARCH(1,1)-type models.

	Constraints

Table 3 :

 3 Estimates of GARCH-type models for Bitcoin returns on original data -July 2010 to October 2016. LL is the log-likelihood value, AIC and HQ correspond to the Akaike and Hannan-Quinn criteria, respectively. Q(10)

	Parameters In-sample criteria Residual tests	ω α β γ δ/ρ θ LL AIC HQ Q(10) Q 2 (10) ARCH(5)	Panel A: growth rate	0.73 GARCH 0.0001 0.2363 0.7753 3844.4 -3.3887 -3.3841 40.9 * 6.01	(28.1) (20.8) (117.8)	0.33 EGARCH -0.6759 0.4008 27.9 (-31.8) 0.9328 (348.8) 0.0251 (2.68) 3834.3 -3.3789 -3.3734 43.4 * 3.56	0.76 GJR-GARCH 0.0001 0.2577 0.7752 -0.0476 3845.7 -3.3890 -3.3835 39.8 * 6.22	(26.9) (15.6) (112.3) (-2.67)	1.05 APARCH 0.0003 0.2391 0.7839 -0.0517 1.6560 3847.8 -3.3900 -3.3835 39.8 * 7.70	(3.62) (22.6) (118.5) (-2.56) (21.5)	0.33 CGARCH 0.1327 * * 0.1825 0.7855 0.9999 0.0549 3885.7 -3.4234 -3.4169 44.3 * 4.73	(1.76) (19.2) (86.1) (17074.6) (12.4)	0.05 ACGARCH 0.0035 0.14434 0.6552 0.0512 0.9923 0.0915 3865.5 -3.4047 -3.3973 39.3 * 2.58	(3.26) (10.8) (21.8) (3.79) (448.0) (10.5)	Panel B: log first diff.	0.45 GARCH 0.0001 0.2510 0.7630 3835.0 -3.3804 -3.3758 36.0 * 4.52	(28.8)[2.63] (22.4)[5.61] (115.5)[22.2]	0.20 EGARCH -0.7475 0.4231 0.9232 0.0208 (2.07)[0.52 * (-31.9)[-3.99] (28.3)[7.58] (321.7)[34.3] ] 3830.0 -3.3751 -3.3696 35.4 * 2.92	0.47 GJR-GARCH 0.0001 0.2756 0.7640 -0.0539 (-2.76)[-0.63 * (27.6)[2.64] (14.9)[5.18] (109.4)[21.8] ] 3836.4 -3.3808 -3.3753 35.1 * 4.64	0.65 APARCH 0.0004 (4.28)[0.77 * ] 0.2527 (24.0)[5.53] 0.7754 (118.4)[17.5] -0.0392 (-1.89)[-0.39 * ] 1.5627 (23.8)[3.62] 3839.9 -3.3829 -3.3765 34.8 * 5.55	0.13 CGARCH 0.1704 (2.22)[0.01 * ] 0.2080 (19.5)[0.06 * ] 0.7583 (72.0)[0.19 * ] 0.9999 (218173.2)[1.93] 0.0601 (13.3)[0.01 * ] 3870.3 -3.4098 -3.4034 38.6 * 2.93	0.11 ACGARCH 0.0042 (3.42)[0.27 * ] 0.1292 (7.27)[0.40 * ] 0.5662 (14.2)[1.23 * ] 0.0852 (4.93)[0.70 * ] 0.9891 (333.3)[51.7] 0.1154 (11.2)[0.36 * ] 3854.4 -3.3949 -3.3875 37.9 * 2.74	and Q 2 (10) are respectively the Box-Pierce statistics with lag 10 of	the standardized and squared standardized residuals. These are asymptotically distributed as χ 2 (k), where k is the lag length. ARCH(5) is the ARCH LM test with lag 5. This is distributed as	appear in parentheses and brackets, χ 2 (q), where q is the lag length. * and * * indicate that the null hypothesis is rejected at the 5% and 10% level, respectively. The standard and robust t-ratios	respectively. The best in-sample criteria appear in bold.

Notes:

Table 4 :

 4 Jumps detected in the Bitcoin returns.

	Date	t-stat	Percent change Events
	07-22-2010	4.58	-47.0	Mt.Gox exchange opens
	11-06-2010	3.53	40.1	Bitcoin economy passed $1 million
	01-14-2011	7.93	22.3	The Silk Road website (online black market) opens
	01-20-2011	4.37	23.0	The Electronic Frontier Foundation accepts Bitcoins
	02-01-2011	4.63	29.7	Parity between the US dollar and the Bitcoin
	04-04-2011	6.70	-13.7	Three Bitcoin exchanges open
	06-11-2011	3.95	-49.2	Hacking of Mt.Gox exchange
	08-03-2011	10.23	-26.3	Bitomat exchange lost wallet data
	08-06-2011	6.61	-40.3	MyBitCoin (e-wallet service) shuts down
	09-09-2011	3.76	-26.1	Massive sellof
	10-17-2011	6.91	-33.0	ExchB exchange shuts down
	11-14-2011	7.34	-30.1	High trading
	02-14-2012	4.25	-16.5	Paxum (online payment service) stops accepting Bitcoins
	03-19-2012	5.87	-11.9	Bug in Bitcoin-Qt (ex Bitcoin Core)
	08-17-2012	5.71	-15.3	Bitcoins Savings & Trust halts payments (Ponzi scheme)
	07-01-2013	5.05	-14.2	Germany plans tax on Bitcoins
	10-02-2013	15.59	-22.9	The Silk Road website shuts down
	11-18-2013	4.56	34.8	US Senate qualifies Bitcoin as a "legitimate" currency
	02-07-2014	3.93	-10.8	Attacks against major Bitcoin exchanges
	03-27-2014	8.36	-19.1	IRS declares Bitcoins to be taxed as property
	04-10-2014	6.53	-19.9	Chinese Bitcoin exchanges' bank accounts closed
	05-20-2014	6.31	8.9	Thai Bitcoin Exchange is coming back online
	09-18-2014	4.57	-7.6	Upcoming IPO of Alibaba
	11-12-2014	5.77	15.2	Microsoft accepts Bitcoins
	01-03-2015	5.40	-11.7	Hacking of Bitstamp exchange
	01-13-2015	4.86	-16.3	Announcement of Bitcoin auction by the US Marshals Service
	01-14-2015	5.50	-24.7	Announcement of closing Vault of Satoshi exchange
	08-08-2015	5.08	-7.0	Closing exchange services to residents of New Yor state (BitLicense)
	08-18-2015	9.72	-16.0	Launch of Bitcoin XT by Mike Hearn et Gavin Andresen (Bitcoin Core developers)
	01-15-2016	9.90	-18.1	Mike Hearn quits Bitcoin
	04-27-2016	4.32	-5.0	Payment institution status for Bitstamp
	05-28-2016	5.51	10.4	Bankruptcy of KnCMiner
	06-12-2016	3.98	9.9	Attack on Etherrum network
	08-02-2016	4.63	-9.4	Theft on Bitfinex exchange
	01-05-2017	4.01	-11.6	Intervention of the People's Bank of China
	01-11-2017	4.64	-15.4	End of margin trading on Chinese platforms
	07-20-2017	4.07	22.6	Avoid a split into two cryptocurrencies of the Bitcoin
	09-14-2017	4.49	-18.3	Closure of the Chinese exchanges BTCC and ViaBTC
	10-12-2017	4.69	11.9	Japanese licenses to cryptocurrecncy stock exchanges
	12-07-2017	4.09	20.7	High trading volume
	01-16-2018	3.93	-18.0	Announcement of the Lightning Network protocol

Notes:

The Gumbel critical value with T = 2, 803 and α = 0.5 is 3.84.

Table 5 :

 5 Estimates of GARCH-type models for Bitcoin returns on original data -July 2010 to March 2018.

	Residual tests	Q 2 (10) ARCH(5)	4.52 0.45		--		4.64 0.47		7.17 0.70		2.93 0.13	2.74 0.11		13.7 1.32
		Q(10)	36.0 *		-		35.1 *		43.4 *		38.6 *	37.9 *		29.1 *
	In-sample criteria	LL AIC HQ	4777.6 -3.4066 -3.4028		---		4778.6 -3.4066 -3.4020		4782.6 -3.4087 -3.4034		4816.4 -3.4329 -3.4275	4814.6 -3.4308 -3.4247		5307.5 -3.7848 -3.7810		---		---		---		---	---
											]		]
		θ									0.0600 (13.9)[0.01 *	0.0454 (4.80)[1.17 *										0.1716	[6.06]
											]
		δ/ρ							1.5577	(24.8)[4.20]	0.9999 (22106.5)[1.92 * *	0.9987	(985.7)[244.2]							2.1410	[3.02]	0.1710	[7.00]	0.9909	[54.4]
	Parameters	β γ	0.7732	(125.2)[26.1]	0.9308 0.0132 (1.54 * (362.0)[41.7] )[0.38 * ]	0.7742 -0.0369 (-2.18)[-0.53 * (118.9)[25.9] ]	0.7859 -0.0266 (-1.42 * (131.4)[20.8] ] )[-0.31 *	0.7892 (87.9)[0.23 * ]	0.7817 0.0218 (3.82)[0.48 * (70.0)[15.3] ]	0.8116	[37.1]	0.9584 0.0309 [1.14 * [61.8] ]	0.8150 -0.0527 [-1.21 * [37.9] ]	0.8108 -0.0721 [-1.16 * [21.3] ]	0.6108 [1.17 * ] 0.9909 [55.8]	[1.03 * ] 0.6070 [-0.17 * -0.0111 ]
		α	0.2384	(23.6)[6.54]	0.4042	(28.3)[8.33]	0.2555	(15.8)[5.93]	0.2404	(25.6)[6.38]	0.1765 (19.1)[0.06 * ]	0.1643	(15.1)[5.47]	0.1805	[8.01]	0.3161	[7.19]	0.2024	[7.04]	0.1723	[5.82]	0.0325 [0.98 * ]	[0.74 * 0.0364 ]
		ω	0.0001	(29.7)[2.75]	-0.6959	(-32.9)[-4.43]	0.0001	(28.8)[2.74]	0.0004 (4.45)[0.89 * ]	0.1723 (2.39)[0.01 * ]	] (1.29 * 0.0066 )[0.32 *	0.0001	[2.10]	-0.4942	[-4.22]	0.0001	[2.12]	0.0001 [0.45 * ]	0.0045 [0.63 * ]	[0.62 * 0.0044 ]
		Panel A: original	GARCH		EGARCH		GJR-GARCH		APARCH		CGARCH	ACGARCH	Panel B: filtered	GARCH		EGARCH		GJR-GARCH		APARCH		CGARCH	ACGARCH	Notes:

The information is available at: www.coindesk.com (CoinDesk) and https://coinmarketcap.com (CoinMarketCap).

In his definition of 'new data' for robustness test by extension Clemens (2017) includes "dropping influential observations, since a truncated sample cannot represent the same population" (p. 327).

Bouri et al. (2017) fit GRJ-GARCH(1,1) and EGARCH(1,1) models from August 18, 2011 to April 29, 2016, and Baur et al. (2018) estimate a GJR-GARCH(1,1) model from July 19, 2010 to July 14, 2017. Note that Baur et al. (2018) use Bitcoin prices from CoinDesk whereas Bouri et al. (2017) use data from Bitstamp.

A Bitcoin Improvement Proposal (BIP) is a design document for introducing features or information to Bitcoin. This is the standard way of communicating ideas since Bitcoin has no formal structure.


Stevan Coroller

Sophie Chabridon

Maryline Laurent

Denis Conan

Jean Leneutre

Towards End-to-end Privacy for Publish/Subscribe Architectures in the Internet of Things

Keywords: Privacy, IoT, Usage Control, Content-based Distributed Event-Based Systems

The Internet of Things paradigm lacks end-to-end privacy solutions to consider its full adoption in real life scenarios in the near future. The recent enactment of the EU General Data Protection Regulation (GDPR) indeed emphasises the need for stronger security and privacy measures for personal data processing and free movement, including consent management and accountability by the data controller and processor. In this paper, we suggest an architecture to enforce end-to-end data usage control in Distributed Event-Based Systems (DEBS), from data producers to consumer services, taking into account some of the GDPR requirements concerning consent management and data processing transparency. Our architecture proposal is based on UCONABC usage control models, which we overlap with a distributed hash table overlay for scalability and faulttolerance concerns, and across and within systems data usage control. Our proposal highlights the benefits of combining both DEBS and end-user usage control architectures. To complete our approach, we quickly survey existing encryption models that ensure data confidentiality in topic-based Publish/Subscribe systems and highlight the remaining obstacles to transpose them to content-based DEBS with an overlay of brokers.

I. INTRODUCTION

The Internet of Things (IoT) is an ever-growing topic in current research as it combines high stakes with unique constraints requiring specific solutions: how to distribute multiple context data flows between low performance heterogeneous devices and systems in constrained networks, with a generic, scalable and fault-tolerant infrastructure? As stated in [START_REF] Bellavista | A Survey of Context Data Distribution for Mobile Ubiquitous Systems[END_REF], Distributed Event-Based Systems (DEBS), also called publishsubscribe systems, are a suitable solution to disseminate vast amounts of data in the IoT in a scalable way, especially when leveraging distributed infrastructures [START_REF] Eugster | The Many Faces of Publish/Subscribe[END_REF]. Furthermore, with recently increasing global expectations in terms of privacy, there is an urgent need for confidentiality-preserving solutions well tailored to the IoT. The survey [START_REF] Onica | Confidentiality-Preserving Publish/Subscribe: A Survey[END_REF] shows that confidentiality concerns in Pub/Sub architectures are addressed by two, commonly separated, lines of research: specific encryption models and security models based on access control. More precisely, the recent enactment of GDPR 1 raises new requirements in terms of confidentiality and data usage control, in particular: services must obtain the users' consent for a wellmotivated purpose before collecting their data, allow users to revoke this consent at anytime, minimise data collection, and 1 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex\ %3A32016R0679 ensure transparency at all steps of data processing. This paper proposes a technical approach for addressing subparts of the GDPR requirements, in the very specific DEBS environment.

Topic-based and content-based filtering are two main filtering models of Pub/Sub architectures [START_REF] Eugster | The Many Faces of Publish/Subscribe[END_REF]. In topic-based filtering, event data are complemented with metadata tags called topics, and subscription filters correspond to regular expressions of topics that consumers are interested in. As a consequence, topics constitute a vocabulary or ontology that is shared by producers and consumers, and event data may remain opaque to routing. Content-based filters are conjunction of filters that parse different parts of the event data, and possibly some metadata that are added for instance to model the quality of event data. Consequently, the filtering is potentially more powerful, but more expensive, and the whole content of event data should be disclosed to routers. Since IoT systems are open systems, we chose content-based filtering for our study.

In this paper, we consider that access control alone is not sufficient to protect privacy and must be associated with usage control. We propose to integrate usage control, as defined by the UCON model [START_REF] Park | The UCON ABC Usage Control Model[END_REF], in Distributed Event-Based Systems with specific design choices for tackling the IOT: a broker-based infrastructure, content-based routing and Attribute-Based Access Control (ABAC) context-aware privacy policies.

The rest of this paper is organised as follows. In Section II, we specify the context of our work and we propose a motivating scenario that depicts what threat models are at stake. Then, in Section III, we detail our vision of the core part of a privacy-preserving content-based DEBS in order to provide usage control and obligations management in a brokerbased dissemination architecture. In Section IV, we highlight recent works on topic-based encryption models that would complete our proposed architecture and explain the remaining issues to be addressed to transpose them to content-based DEBS. Finally, we discuss related works in Section V, and we conclude our paper and identify future works in Section VI.

II. MOTIVATIONS AND OBJECTIVES

We present a motivating scenario in Section II-A with the description of the stakeholders in Section II-B and the corresponding threat models in Section II-C.

A. Motivating scenario

Alice is a bather on beaches watched by a lifeguard service. Bob is a lifeguard on duty on the same beach as Alice. The lifeguard service provides all bathers and lifeguards with wristbands equipped with geolocation sensors (e.g. RFID wristbands). The lifeguard service uses a data dissemination middleware to collect geolocations, along with personnal data like bathers age and name, for instance to increase children surveillance. The brokers of the dissemination middleware are deployed on all monitored beaches of the seafront. These brokers may be owned by third party organisations: e.g., local shops and snack bars, or public infrastructures such as bus stops. The rationale is that brokers are shared by multiple services as shown in Figure 1.

Bathers' location must be sent to local lifeguards-i.e. lifeguards on duty on the same beach. When registering to the service, bathers send their consent. Thereafter, local lifeguards can visualise on their smartphone bathers' location and will be alerted when some bathers are swimming too far from the shore. In this application, consent revocation is needed for several reasons: GDPR requires users to be able to revoke their consent at anytime; bathers may loose their geolocation device in the water, which could interfere with lifeguards' work; or bathers may leave the beach. Meanwhile, both bathers' and lifeguards' locations must be sent to the servers runnning the lifeguard service in order to adapt the number of lifeguards on each beach, for instance by shifting some lifeguards from one beach to another. This processing could take additional data into account: e.g. proportion of children, sea and swimming conditions, and the new assignments are broadcast to lifeguards using the same infrastructure. This scenario stresses out the need for content-based DEBS expressiveness: lifeguards need precise location figures to be able to quickly locate bathers in danger, but lifeguard servers only need to know on which beach bathers are located, and thus can accept lowprecision location data. Such quality of context filtering is difficult to handle with topic-based filtering.

The first requirement that is demonstrated in this scenario is end-to-end data confidentiality-i.e. from data producers to consumer services, consent management (collection and withdrawing), along with data processing transparency on the consumer side, thus offering technical directions for addressing some of the GDPR principles. In addition, the approach must be generic so as to handle fine-grained consents, or to adapt to a wide range of application domains. The architecture must also scale and be fault-tolerant.

B. Scenario stakeholders

We identify the various stakeholders of our scenario: 1) Bathers: They produce sensitive data: e.g. their position on the beach. 2) Lifeguards: They subscribe to local bathers precise location and also publish their own low-precision location. 3) Lifeguard service: It subscribes to both bathers' and lifeguards' location data, and processes them on several servers for allocating lifeguards to beaches. Furthermore, bathers should be able to differentiate the precision of the location that they publish, and without any data leakage between the different services.

C. Threat models

In this section, we list the threats to data confidentiality, integrity and availability that are at stake in our scenario.

First of all, we make some assumptions. We consider that all communication channels between components (subscribers and publishers, commonly called clients, and brokers) are secured-i.e. authenticated and confidential. For this reason, we will further ignore several threat models like MITM attacks or rogue devices. We also consider that manufacturers are responsible for the security of their devices that results from implementation choices. Consequently, we will not consider the case of corrupted brokers or clients. The combination of these two assumptions ensures that all brokers and clients are authenticated.

In addition to the requirements identified in Section II-A, our work tackles the three following threat models that focus on privacy issues of relevance for our scenario:

1) Honest-but-curious brokers or semi-trusted brokers. It is a common assumption in security research. In our case, we consider that brokers strictly follow the DEBS routing algorithms, but may disclose any clear-text data they are provided with. Sensitive data do not only include publications content but also advertisement and subscription filters. The authors of [START_REF] Belguith | Secure Publish and Subscribe Systems with Efficient Revocation[END_REF] highlight more complex threat models where semi-trusted brokers can collude together or with subscribers to obtain unauthorised access to publications. These threat models are discussed in Section IV. 2) Semi-trusted subscribers. Authenticated subscribers may use loose subscription filters to receive numerous publications, even if they do not have the consent of data owners to receive such data. In our scenario, it means that food service subscribers might abuse loose subscription filters to receive bathers geolocation. 3) Data misuse within consumers infrastructure. Once publications are sent to authorised subscribers, the infrastructure looses control over the data. Only legal obligations remain, like data owners consent, which do not prevent data consumers to process data as they will, and as long as their infrastructure is not completely inspected. For example, the lifeguard service could sell bathers geolocation to food services that may then focus their sellers to most busy beaches.

III. END-TO-END USAGE CONTROL ARCHITECTURE FOR PUB/SUB NETWORKS

In this section, we detail our proposition: an end-to-end usage control architecture for broker-based DEBS. The overall architecture of the proposition is depicted in Figure 2. In Sections III-A and III-B, we introduce UCON ABC usage control model, and then we detail its adaptation to brokerbased DEBS. In Section III-C, we describe the architecture of usage control on the consumer side. Concerning the last component, namely the usage log storage system, we do not further detail it in this paper because it constitutes an external and independent system.

A. UCON ABC usage control models

The UCON ABC family of reference models for usage control provides three decision factors: authorizations, obligations and conditions [START_REF] Park | The UCON ABC Usage Control Model[END_REF]. UCON ABC authorizations work in the same way as Attribute-Based Access Control to define users' rights over objects: users provide ABAC information that are matched against a policy to define their rights. Obligations allow to check if users have performed some determined actions before they can access objects. Conditions are external conditions bound to the execution environment, like current time or network load.

UCON ABC also provides two essential features: continuity of access decision and attribute mutability. Objects are protected by policies, and the previously-defined three decisions factors can be checked at three different instants: before users have access to the object (pre), during the access (ongoing), and after the access (post). When a user accesses an object, their ABAC information can be changed to modify their rights, as a consequence of the access.

These features and decision factors cover a wide range of use cases. In our scenario, pre-authorizations allow us to check that data consumers own producers' consent before receiving their data, and consequently avoid the "semi-trusted subscribers" threat model. Ongoing obligations and mutable attributes allow us to continuously check if consumers have sent back tamper-proof usage logs for previously received data, and thus to ensure data processing transparency.

B. UCON ABC adaptation to broker-based DEBS

In regular broker-based DEBS, as drawn in Figure 2, the clients, being producers or consumers, are connected to the system through a link to their access brokers. Internal or inner brokers, which do not have any local client connected to them, serve to route publications from the access broker of the producer to consumers via their access broker. The second role of brokers is to implement UCON ABC usage control. The usage control data are stored in a reliable and scalable manner into a distributed hash table (DHT) organised as an additional overlay on top of the brokers: the peers of the DHT are the brokers. Therefore, as drawn in Figure 3, brokers comprise three sub-components: the DEBS routing part for forwarding publications to interested consumers, the usage control system (UCS) that is embedded into the broker, and the DHT node that stores UCS data.

1) Brokers role in usage control: We choose XACML 3.0, which is a recognised OASIS standard commonly used to enforce ABAC in production environments, as the representation for usage control policies that are to be matched against ABAC information. The work presented in [START_REF] Colombo | A Proposal on Enhancing XACML with Continuous Usage Control Features[END_REF] and [START_REF] E-Ghazia | Usage Control Model Specification in XACML Policy Language[END_REF] provide XACML adaptations to handle all UCON ABC features. The XACML 3.0 documentation provides a reference architecture2 to enforce access control. In Figure 3, we adapt this reference architecture.

We embed several components of the UCS directly into brokers. Hence, brokers play the role of Policy Enforcement Points (PEP). The usage control policies are specific to each producer because of being closely related to legal consents. This explains why we do not use any Policy Administration Point (PAP) to create generic policies, but producers send their own policies to their access broker, which stores them. Additionally, we define three different types of Policy Information Points (PIP), which are responsible for attribute queries: 1) the local PIP that fetches locally stored attributes, 2) the remote PIP that fetches attributes stored in other DHT nodes, and 3) the PIP responsible for fetching environment attributes in order to perform condition checks. Finally, we use a standard Policy Decision Point (PDP) that interacts with a Context Handler (CH) to fetch missing attributes from corresponding PIPs. (advId, subID, interestedBrokers) "adv", "sub", "ID" stand for "advertisement", "subscription", and "identifier", respectively. Underlined fields correspond to primary keys to build indexes. As described in [START_REF] Lazouski | A Prototype for Enforcing Usage Control Policies Based on XACML[END_REF], UCON ABC can be specified in U-XACML, in the form of a tuple of five XACML policies including notably: pre-decision (U-PD), ongoing authorisations and conditions (U-OAC), and ongoing obligations and attribute updates (U-OBU). This tuple of XACML policies corresponds to the policySet field.

3) API for routing and usage control: We now detail the five types of messages that producers and consumers can send to their access broker, and the corresponding treatments. Producers declare the kind of data they will publish (call advertise). Then, they publish these data (call publish). Consumers declare the information they want to receive (call As will be discussed in Section III-C, consumers' usages of the data are logged and they inform their access broker of new logs (call logReception). At anytime, after considering usage logs, producers can revoke their consents (call revoke).

a) Call advertise(advFilter, qocAttr, policySet): ad-vId: Producers advertise before publishing so that they declare 1) which data they are willing to send (advFilter), 2) the quality of context 3 they guarantee on these data (in the form on attributes, qocAttr), and 3) their privacy requirements, in the form of policies (policySet). The caller receives a unique identifier (advId) and the broker adds a new T1 entry into the DHT.

b) Call subscribe(subFilter, qocFilter, preABAC): subId: Consumers subscribe to receive publications by providing 1) a filter to describe the information they are interested in (subFilter), 2) the quality of context they require on these data (qocFilter), and 3) the ABAC information that will be 3 QoC and privacy are linked [START_REF] Chabridon | A Survey on Addressing Privacy together with Quality of Context for Context Management in the Internet of Things[END_REF] matched against U-PD policies (preABAC). A unique subscription identifier (subId) is returned and the system builds a covering tree in the overlay of brokers for routing publications to the consumer. c) Matching advertisements and subscriptions: Anytime an advertisement is received, the access broker matches the new U-PD policy with the preABAC data locally stored. Anytime a subscription is received, every broker matches the new preABAC data with its locally stored U-PD policies. When a broker finds a matching, it stores T2, T3 and T4 entries into the DHT. Notably, subscriber attributes subAttr are initialised and the valid boolean is truthified into the T2 entry. This boolean value can be changed after any policy reevaluation: if the result becomes DENY, then the boolean is falsified.

Since a matching can be cancelled (valid is falsified), a T5 entry is also updated so that interested brokers register to future notification of change to the fields subAttr or valid. In other words, we use the DHT to build a Pub/Sub system [START_REF] Kermarrec | XL Peer-to-peer Pub/Sub Systems[END_REF]. The difference between the overlay of the DEBS for routing and the overlay for the DHT is the following: the brokers are physically distributed (e.g. in smart cities) for data flow control of the routing function; the brokers form a DHT for storing usage control in sparse accesses.

d) Call publish(advID, n): When a producer publishes notification n, n is parsed to match advFilter (done at producer's access broker, namely B prod ), and next subFilter. Then, valid is checked to be true. The latter condition may be tested in three different ways according to message traffic and computation costs: 1) the check is performed by B prod and all the brokers send n complemented by advId and the set {subID: valid}, 2) B prod sends n with advId and all the brokers towards the consumer computes {subID: valid}, and 3) B prod sends n with advId and the access broker of a subscriber computes valid.

In any case, publications are sent to consumers along with the related advID and subID so that usage logs created by consumers contain both advID and subID. Data owners can then identify the usage logs they receive from the log storage infrastructure. In addition, the U-OBU policy from each concerned policy set can be used to update subscribers' attributes everytime a publication is successfully routed. When attributes are updated, the U-OAC policies must be re-evaluated by the access broker of the publishers, and valid is potentially updated.

e) Call logReception(advID, subID): When a producer receives a new data usage log from the log storage infrastructure, this producer (or the storage infrastructure itself, by proxy), must send a logReception message to its access broker, which updates subAttr values in the corresponding T2 entry of the DHT. This update can be performed thanks to U-OBU's attribute update feature. The node responsible for updating policies for the (advId, subId) pair is notified of the updates via the DHT's internal Pub/Sub system. It then reevaluates the U-OAC policy and potentially updates the valid attribute.

f) Call revoke(advID, subID): At anytime, a producer can revoke their consent. The workflow is similar to that of logReception. The access broker updates the revoke field of subAttr, the U-OBU policy is re-evaluated to imperatively decide DENY, and the valid attribute is falsified. This solution suffices to (eventually) stop consumers from receiving additional data from producers who revoked their consent. In order to go even further, an additional table could be created in the DHT to keep track of consumers' reputation that would be updated at revocation time by post-obligations and attribute update policies.

g) Calls unadvertise(advID) and unsubscribe(subID): Tables T3 andT4 of the DHT are present to manage these two calls.

h) Usage control in action: Let us return to the scenario of Section II. Alice publishes her geolocation and wants to receive a usage log of her sensitive data for every publication. The subAttr field contains a requiredLog field that is incremented by the U-OBU policy everytime a publication from Alice is published. The U-OBU policy checks whether requiredLog is strictly smaller than 1, and deny the access if not so. This field is decremented by the U-OBU policy at the reception of a logReception message. This constitutes a trivial use case. In real life scenarios, requiredLog would be replaced by timers, or a more advanced reputation system, for instance by using post-obligations and attribute update policies.

For now, our architecture handles usage control based on fine-grained users consent, which counteracts the second threat model presented in Section II-C, along with consent revocation. The use of obligations enables consumer-side processing transparency, but does not preventively counteract the third threat model. In addition, nothing ensures the authenticity of data usage logs. The next section links our DEBS usage control architecture to a consumer-side usage control solution, in order to tackle these two issues.

C. Consumer-side within and across systems usage control

In [START_REF] Kelbert | Data Usage Control for Distributed Systems[END_REF], the authors propose a within and across system usage control architecture which provides both preventive and detective usage control. "Within system usage control" is ensured by system calls monitoring: the usage control application includes a PEP based on the strace tool to intercept system calls that may affect monitored data, and a PDP that matches intercepted calls against data usage control policies. Unauthorised system calls can then be interrupted to perform preventive usage control, or they can be released but logged to enable detective usage control. This solution ensures that any copy of monitored data remains monitored, whatever its representation. "Across system usage control" is ensured by intercepting socket-related system calls and sending data usage control policies to remote machines before sending them monitored data. This requires that all machines that want to receive monitored data previously install the usage control application.

The only drawbackof this implementation is the overhead induced in computation, which makes it not suitable for monitoring real-time consumer applications, among others. The authors of [START_REF] Kelbert | Data Usage Control for Distributed Systems[END_REF] claim that "it depends on use case scenarios whether the imposed overheads are acceptable in practice". For this reason, in [START_REF] Pohlack | Towards Runtime Monitoring in Real-Time Systems[END_REF], the authors show that system calls should not be used for monitoring purposes, and provide an alternative low-intrusive solution, which is adapted to real-time systems requirements in terms of latencies. This alternative is to be used instead of [START_REF] Kelbert | Data Usage Control for Distributed Systems[END_REF]'s implementation in case system call monitoring is effectively proved not to be suited for applications which require low latencies.

The rationale for using the work of [START_REF] Kelbert | Data Usage Control for Distributed Systems[END_REF] in conjunction with our DEBS usage control architecture is that it tackles the third threat model "data misuse within consumers infrastructure", while ensuring that data usage logs are tamper-proof, as they can themselves be monitored by the usage control application.

By adding consumer-side within and across systems usage control, we obtain an end-to-end usage control architecture that fills the requirements stated in Section II. Its complete decentralisation using an overlay of brokers managing a DHT additionally provides both scalability and fault tolerance. In the first threat model (see Section II-C), third-party-owned brokers can only be considered as semi-trusted. Yet, brokers can realistically be considered as honest-be-curious, or able to collude with semi-trusted consumers, as explained by [START_REF] Belguith | Secure Publish and Subscribe Systems with Efficient Revocation[END_REF]. This last obstacle towards end-to-end privacy in the IoT is discussed in the next section.

IV. SEMI-TRUSTED THIRD-PARTY-OWNED BROKERS

As stated by [START_REF] Onica | Confidentiality-Preserving Publish/Subscribe: A Survey[END_REF], threat models related to the semi-trusted brokers assumption in Pub/Sub is tackled by research on encryption models and encrypted matching. Yet, some obstacles remain in this field, like key management and distribution. In addition, [START_REF] Belguith | Secure Publish and Subscribe Systems with Efficient Revocation[END_REF] argues that most of the recent works in this field still tackle simple threat models, ignoring the possibility of collusions between brokers and consumers.

The context of distributed content-based Pub/Sub implies additional constraints in the choice of a suitable encryption model to complete our end-to-end privacy-preserving architecture: most of the existing works rely on trusted authorities, which would introduce a single centralised element in our fully decentralised architecture. Additionally, works based on Attribute-Based Encryption (ABE) rely on the fact that an exhaustive list of topics is globally known: some secrets are associated to each topic, and publications are encrypted with the secret of the topic they belong to. Thus, ABE is hardly transposable to content-based Pub/Sub where there is an infinite number of possible subscription filters.

The solution in [START_REF] Shikfa | Privacy-preserving content-based publish/subscribe networks[END_REF] does not rely on ABE, but it tackles the trusted authority issue, and even addresses the key management issue by performing local key management on each broker. However, it still fails to efficiently render content-based high expressiveness.

V. RELATED WORKS

The authors of [START_REF] Marra | Implementing Usage Control in Internet of Things: A Smart Home Use Case[END_REF] provide a UCON implementation using the Cassandra DHT into P2P networks in the IoT. Just like our achitecture, they use a DHT to distribute UCON policies and ABAC information storage. However, this solution aims at providing smart devices collaboration and does not tackle privacy and confidentiality issues.

In [START_REF] Marra | Improving MQTT by Inclusion of Usage Control[END_REF], UCON is implemented into MQTT, a topic-based pub/sub protocol. This implementation being fully centralised, it lacks both scalability and fault tolerance. Yet, this implementation consists of a single application, completely separated from the broker one, and thus completely generic to the MQTT implementation of brokers and clients. This is not the case of our architecture, especially because we chose to embed several UCS components within the broker application. On the other hand, this implementation only handles access revocation in case consumers do not respect their obligations. It does not allow producers to revoke consumers' access at anytime, which was one of our first requirements.

The work presented in [START_REF] Pearson | Sticky Policies: An Approach for Managing Privacy across Multiple Parties[END_REF] aims at providing technical solutions to handle usage control based on users' consent, while also taking into account consent revocation issues. The approach is to piggyback usage control policies onto every piece of data, so that data is always transferred along with its usage control policy. Usage control is then enforced in a decentralised manner, on every machine that owns a copy of the monitored data. Yet, this solution heavily relies on encryption techniques, and thus requires a centralised trusted authority. This solution is closely related to [START_REF] Kelbert | Data Usage Control for Distributed Systems[END_REF], as it focuses rather on digital rights management issues.

Another line of research extends Information Flow Control (IFC) [START_REF] Myers | A Decentralized Model for Information Flow Control[END_REF]. Data within messages are tagged with security labels. These labels are then checked by processes to ensure that data can only flow to processes with compatible labels. The approach proposed in [START_REF] Singh | Big Ideas Paper: Policy-driven Middleware for a Legally-compliant Internet of Things[END_REF] revisits IFC to build a middlewarebased solution for policy-enforcement in order to enable a legally-compliant IoT. IFC and UCON share similarities and are promising solutions for the IoT. Although an in-depth comparison of these two approaches is still missing in the literature, we consider that the mutability of attributes in UCON is well suited to the dynamicity of context data in the IoT.

VI. CONCLUSION AND FUTURE WORK

In this paper, we identified several requirements in terms of confidentiality and several threats to privacy that need to be addressed to ensure data privacy in the IoT. In the more restricted context of distributed content-based Pub/Sub, we presented a fully decentralised usage control architecture, to be used in conjunction with an already existing solution for within and across systems monitoring. Our proposal enables end-toend data usage control, the management of the consent of the users with potential consent revocation at anytime, and ensures data processing transparency. It highlights the possibilities enabled by combining middleware security models with enduser data usage control, and the benefits of overlapping broker and DHT overlay networks within the same architecture, to ensure fault-tolerance and scalability.

Yet, our usage control architecture only provides complete end-to-end data confidentiality if we make the hypothesis that all brokers are fully trusted. In a real case scenario like the one we described in Section II-A, this assumption is not realistic, but no encryption model tackles the issue of semitrusted brokers in content-based DEBS. This remains the only obstacle towards end-to-end privacy-preserving architectures in our context.

As part of our future work, we want to provide an implementation of our Pub/Sub usage control architecture, carry out performance tests to compare it with existing implementations of UCON ABC into Pub/Sub environments, and further discuss how obligations should be used in our architecture to adapt to the widest range of scenarios. Finally, we want to carry out further research to determine if security models are adapted to tackle the issue of data confidentiality under the semi-trusted brokers assumption.

Fig. 1 .

 1 Fig. 1. Data dissemination and lifeguard service

Fig. 2 .

 2 Fig. 2. DEBS with end-to-end usage control

Fig. 3 .

 3 Fig. 3. Broker-based DEBS and usage control architecture

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html\# Toc325047089