Richard Macwan
email: richard.macwan@u-bourgogne.fr

Yannick Benezeth
email: yannick.benezeth@u-bourgogne.fr

Alamin Mansouri
email: alamin.mansouri@u-bourgogne.fr

Heart rate estimation using Remote Photoplethysmography with Multi-objective Optimization

Introduction

Photoelectric plethysmography or photoplethysmography (PPG) was first introduced in 1937 by Hertzman where variations in the light absorption of human skin were measured by a photoelectric cell [11] placed under a finger illuminated by a light source above it. Since then PPG has been used widely because of its ease of usage, low cost and non-invasiveness. This non-invasiveness has, however, been superseded by that of remote photoplethysmography, henceforth referred to as rPPG, which aims at measuring the same parameters, but sans contact.

Verkrussysse et al. [START_REF] Verkruysse | Remote plethysmographic imaging using ambient light[END_REF] demonstrated the extraction of remote PPG signals using videos from a simple consumer level camera and that the strongest photoplethysmographic signal was manifested in the G channel of the RGB temporal traces. RGB temporal traces are generated by frame wise quantification, e.g. spatial averaging of skin pixels from the face, and concatenating them. Current research focuses on extracting robust rPPG signals from simple web cameras for which Blind Source Separation (BSS) using Independent Component Analysis (ICA) has been used in many different works [START_REF] De Haan | Robust pulse rate from chrominance-based rPPG[END_REF][START_REF] Mcduff | Improvements in remote cardiopulmonary measurement using a five band digital camera[END_REF]22,[START_REF] Poh | Advancements in noncontact, multiparameter physiological measurements using a webcam[END_REF].

ICA is a statistical technique for decomposing a multivariate signal into constituent signals assuming that the input signals are independent [START_REF] Hyvärinen | Independent component analysis: Algorithms and applications[END_REF]. The problem of rPPG measurements is posed as a signal separation problem where the rhythmic cardiac pulse, appearing as variations in skin color, is assumed to be linearly mixed into the temporal traces of color data from cameras. If the time varying color traces for n channels are represented as x = (x 1 , x 2 , ..., x n ) T , which is an instantaneous linear mixture of the original m independent signals denoted as c = (c 1 , c 2 , ..., c m ) T , then the process of mixing can be formulated as x = Ac, where the matrix A n×m represents the linear memoryless mixing of the channels. The goal of ICA, then, is to estimate the demixing matrix W m×n to recover all the independent components from the observed signal with no knowledge of A and c. The recovered signal s = (s 1 , s 2 , ..., s m ) T is given by s = Wx [18].

Owing to this linear formulation, ICA suffers from two unavoidable ambiguities [2,7]. First, the order of the independent components is indeterminable. A different permutation of the columns of W will give the same independent components. Second, the exact amplitude and sign of the independent components is also indeterminable. In spite of these limitations, ICA is being frequently used for rPPG measurements.

In this work, we propose to reformulate the objective function of ICA to make it a better posed problem by making two augmentations. First, we require only one component, i.e., the rPPG pulse from the mixture of the temporal traces. As a result, the problem of component separation can be modified into that of component extraction. This requirement is not uncommon and is manifested in various applications. For instance, the On-Off simulation scheme of fMRI experiments [18].

Second, we know that the blood volume pulse embedded in the RGB temporal traces is by definition periodic (or at least pseudo-periodic). Consequently, we use the periodicity of the rPPG signal as an a priori information to help extract the most periodic component. To this end, we use autocorrelation as the measure of periodicity for guiding the ICA separation algorithm. To compensate for the negative values, the mean of squared autocorrelation is used as the periodicity measure. The rPPG pulse extraction is accomplished by using a multi-objective optimization approach to maximize both mean squared autocorrelation and negentropy [13], a measure of nongaussianity fit for remote photoplethysmography. Our new method, Multi-objective optimization using Autocorrelation and ICA (MAICA), was validated with our inhouse database UBFC-RPPG, comprising of two datasets of 9 and 46 videos respectively, which is made publicly available along with the ground truth. To the best of our knowledge, this is the first dataset specifically geared towards rPPG analysis. Apart from the inhouse database, the algorithm was also validated against the MMSE-HR database. To gain an intuition on the advantage of incorporating periodicity information into the ICA source separation algorithm, a quick analysis of one of the difficult videos, where traditional ICA is not entirely successful, from our UBFC-RPPG database is presented here. The analysis was carried over sequential temporal windows of 30s and the corresponding weighting matrices that extract the rPPG signal of ICA in figure 1a are compared with those obtained by MAICA in figure 1c. It can be seen from figure 1d that the weighting matrices that simultaneously maximizes negentropy and periodicity indeed result in a heart rate closer to the ground truth heart rate. Moreover, the SNR obtained for the measured signal was improved from -10.89 for ICA to -3.39 for MAICA (also seen by the overall increase in SNR in table 1), proving the advantage of incorporating the periodicity information in the algorithm.

An overview of the related work is presented in section 2 followed by the formulation of the periodicity measure and multi-objective optimization in section 3 and the experiments and results are presented in section 4.

Previous Work

As mentioned earlier, rPPG signals have been successfully extracted using simple web cameras using the G channel which contains the relatively stronger plethysmographic signal [START_REF] Verkruysse | Remote plethysmographic imaging using ambient light[END_REF]. One of the first works that used ICA for rPPG measurements comprised of using RGB temporal traces from a simple web camera to extract the cardiac pulse, albeit with limited success under the presence of movement artifacts [22]. Usage of more color channels using a five band camera (RGBCO) with ICA was also investigated by investigated proposing that the Cyan, Green, Orange (CGO) channels were better suited for rPPG measurements [START_REF] Mcduff | Improvements in remote cardiopulmonary measurement using a five band digital camera[END_REF]. ICA's known caveat of the indeterminacy of the order of the estimated components calls for a heuristic to choose the correct component. Where Poh et al. [22] simply selected the second obtained component after applying ICA on RGB temporal traces, McDuff et al. [START_REF] Mcduff | Improvements in remote cardiopulmonary measurement using a five band digital camera[END_REF] chose the signal with the peak of greatest power of the normalized Fast Fourier Transform (FFT) spectrum between 40 and 180 bpm.

In a somewhat related work, Zhang et al. [START_REF] Zhang | Simultaneous detection of blink and heart rate using multi-channel ICA from smart phone videos[END_REF] signal estimation, using continuous wavelet transform to obtain instantaneous heart rate and heart rate variability. In another work, Gunther et al. [START_REF] Gunther | Model-based (passive) heart rate estimation using remote video recording of moving human subjects illuminated by ambient light[END_REF] quasi-periodic process model to extract the heart rate signal with the help of a Toeplitz-structured matrix formulation and a markov process to model the slowly fluctuating reflected light, and finally extract the heart rate signal using the CVX [8], [9] optimization toolbox for Matlab.

De Haan et al. [START_REF] De Haan | Robust pulse rate from chrominance-based rPPG[END_REF] introduced chrominance-based methods where two orthogonal chrominance signals were built from the RGB traces in addition to using skin-tone standardization to compensate for illumination variation of different skin colors. They further improved upon the chrominance based methods to show that the different absorption spectra of arterial blood happen along a specific vector in a normalized RGB space, termed as the Blood Volume Pulse vector [START_REF] De Haan | Improved motion robustness of remote-PPG by using the blood volume pulse signature[END_REF]. Recently, they introduced a mathematical model that incorporates the relevant optical and physiological properties of skin reflection using which they proposed a new algorithm based on the Plane-Orthogonal-to-Skin (POS) which is a plane orthogonal to the skin-tone in the temporally normalized RGB space, suitable for rPPG pulse extraction [30].

Another class of methods focuses on smart ROI selection paradigms. Bobbia et al. used temporal superpixels to extract candidate pulse signals which were then merged into a rPPG signal. Li et al. [START_REF] Li | Remote Heart Rate Measurement From Face Videos Under Realistic Situations[END_REF] used face tracking and Normalized Least Mean Square adaptive filtering methods to compensate against motion artifacts. In a related work, Wang et al. [START_REF] Wang | Exploiting spatial redundancy of image sensor for motion robust rPPG[END_REF] attempted to extract the rPPG signal by constructing pixel based rPPG sensors to estimate a robust pulse signal using motion compensated pixel-to-pixel pulse extraction based on optical flow vectors.

Many new rPPG measurement algorithms have been introduced recently. An overview of a wide range of rPPG methods has been provided by Sun and Thakur [24] demonstrating the research on rPPG and showing its ubiquity and widespread acceptance. In a similar work, McDuff et al. provide a review on state of the art PPG imaging considering measurements other than pulse rate under realistic conditions such as presence of motion artifacts [START_REF] Mcduff | A Survey of Remote Optical Photoplethysmographic Imaging Methods[END_REF]. Kranjec et al. also provide a comparative study on heart rate (HR) and heart rate variability measurement between remote PPG using RGB cameras and other methods such as capacitively coupled ECG and HR from speech [START_REF] Kranjec | Non-contact heart rate and heart rate variability measurements: A review[END_REF], highlighting their advantages, disadvantages and feasibility.

Incorporating a priori information to guide the optimization process is an interesting approach in signal separation. Lu and Rajapakse [18] have used an existing reference signal to guide the separation process by using the method of Lagrange multipliers where the distance between the reference signal and the estimated signal is taken as the constraint to be minimized. Based on this work, Tsouri et al. proposed a constrained ICA based approach, using a rectangular pulse as a reference signal for rPPG measurements, [26] which to the best of our knowledge is the closest contribution to ours.

Using a sufficiently accurate reference signal calls for one of two possible requirements. One possibility is to compare the extracted rPPG signal to reference signals of different frequencies (as done in [26]) which is computationally taxing and 30 times slower than traditional ICA. The other possibility is to continously update the frequency of the reference signal during the optimization process which highly reduces the probability of convergence. In rPPG measurements, a PPG signal is such an example the synthesis of which depends critically on the required frequency, even more so than on the actual shape of the signal.

Proposed Method

Quasi-periodicity is a ubiquitous property exhibited by various physiological signals such as electrocardiographic, electromyographic, electroencephalographic and photoplethysmography signals. However, this property has been unfairly ignored by most signal extraction problems, especially in remote photoplethysmography measurement scenarios. This inherent property of biomedical signals can be exploited by using a periodicity metric that can guide the component extraction process to choose the most periodic component. Of course, this periodicity metric needs to be combined with the ICA objective function in the case of traditional rPPG measurement, thereby converting the BSS ICA problem to semi-Blind Source Extraction (BSE) problem, since we are not entirely blind anymore with regards to the type of signal that needs to be extracted.

One possibility is to use autocorrelation as a constraint to nudge the algorithm towards selecting components having periodicity higher than a given threshold. However, formulation of such a constraint is critically dependent on the threshold which is quite complex to select, especially in stochastic scenarios such as that of rPPG measurements. A better solution would be to use autocorrelation as one of the objective function thereby maximizing autocorrelation along with negentropy formulated as a multi-objective optimization problem. The use of autocorrelation as a periodicity measure and formulation of the multi-objective optimization problem is presented next.

Autocorrelation as a periodicity measure

Autocorrelation is the correlation of a signal with itself at different lag times provided it is sampled at a sufficiently high frequency. For a time series signal y = [y 1 , y 2 , . . . , y N ] of N elements, its discrete autocorrelation

r k at lags k ∈ [-(N -1), • • • , N -1] is given by r k = N -1 j=0 y j k y j (1)
where k y j is the j th element of the signal y lagged (or led if k < 0) by k units and padded with zeroes to the left (or right if k < 0) and is the element-wise multiplication operator. A periodic signal typically has a higher correlation with itself compared to a non-periodic one which can be quantified by the mean of the squared autocorrelation of the signal and consequently can be used as a measure of the periodicity of a signal. Figure 2 depicts the high correlation of a periodic sinusoid compared to that of a uniform random signal with the mean of the squared autocorrelation being much higher than that of the random signal. To aid the use of autocorrelation as a periodicity measure and simplify its computation, two modifications need to be made. First, since the autocorrelation is symmetric, we only compute the correlation for lags k ∈ [0, • • • , N -1]. Second, since the correlation at lag 0 is always high, we set the autocorrelation to 0 at lag k = 0. Thus, the autocorrelation is given by r

= [r 1 , r 2 , • • • , r N -1 ]
comprising of N values given by equation 1 and r 0 = 0. Keeping in mind that r k is a scalar, equation 1 can be rewritten in matrix notation as

r k = y[ k y] T = k yy T (2)
where k y is again the signal y lagged by k units and k

∈ [1, • • • , N -1]
. Furthermore, to simplify the derivation of the autocorrelation, k y can be rewritten as yT k where T k is a toeplitz-like matrix that incorporates the lagging at lag k and padding with zeroes of the signal and is given by

T k =          0 • • • 0 1 0 • • • 0 0 • • • 0 0 1 • • • 0 . . . . . . . . . . . . . . . . . . . . . 0 • • • 0 0 0 • • • 1 0 • • • 0 0 0 • • • 0 . . . . . . . . . . . . . . . . . . . . . 0 . . . 0 0 0 • • • 0          = 0 N -k,k I N -k 0 k,k 0 k,N -k (3)
T k is an N × N matrix composed of the first N -k rows made up of (N -k) × k zeroes and an identity matrix of size N -k, the rest of the elements being zero. Thus, r k becomes

r k = yT k y T (4)
making its differential with respect to y easier to calculate. The optimization is implemented using a Newton-method like approach while constraining the output to have unit variance with the help of the Lagrange multipliers method. This calls for the calculation of the first and second derivatives of the autocorrelation with respect to the weighting matrix w which, since they are not trivial, are detailed in the appendix.

Multi-objective Optimization using Autocorrelation and ICA

Multi-objective optimization problems are generally formed by relaxing the constraints in a constrained optimization problem and interpreting them as additional objective functions. In this section we describe the formulation of the rPPG extraction module using Multi-objective optimization with Autocorrelation as a periodicity measure and ICA (MAICA).

Objective functions. Our two objective functions correspond to negentropy and autocorrelation respectively of the output y = w T x where the ideal orthogonal row vector w ∈ R 3 , obtained after optimization, extracts the desired component from the RGB temporal traces x.

Maximize J(y), R(y)

Subject to h(w) = 0 [START_REF] De Haan | Improved motion robustness of remote-PPG by using the blood volume pulse signature[END_REF] where R(y) = R(w T x), which is eventually a function of w, is the mean squared autocorrelation given by

R(y) = E{r 2 } (6) with r = [r 1 , r 2 , • • • , r N ]
being the autocorrelation and r k is given by equation 2. J(y) is the generic contrast function for ICA defined by [START_REF] Hyvärinen | Independent component analysis: Algorithms and applications[END_REF] as H(y gauss ) -H(y). H(.) is the differential entropy and y gauss is a random variable with a variance equal to that of the output signal y. In practice, an approximation of negentropy is used for ease of computation and flexibility given by

J(y) ≈ ρ[E{G(y)} -E{G(v)}] 2 (7)
where ρ is a positive constant, v is a Gaussian variable having zero mean and unit variance. G(.) can be any non-quadratic function as suggested by [13]. A good general purpose function is given by

G(y) = log cos(ay) a (8)
with 1 ≤ a ≤ 2. Finally, as suggested by [18] the constraint, h(w) = E{y 2 } -1 = 0 was introduced to make sure that objective functions J(y) and R(y) and the weighting vector w are bounded.

Linear Scalarization. A simple way to incorporate the a priori information in the optimization problem is to scalarize the multi-objective optimization by forming a single-objective optimization such that the solutions to the scalarized problem are the set of feasible solutions commonly known as Pareto optimal solutions [6]. The linearly scalarized version of the multi-objective contrast function then becomes

Maximize J(y) + R(y)

Subject to h(w) = 0 (9)
where

J(y) = J(y) -J min J max -J min = s 1 (J(y) -J min ) (10)
and

R(y) = R(y) -R min R max -R min = s 2 (R(y) -R min ) (11)
are the normalized versions of the respective objective functions in order to compensate for the disparities in scale and

s 1 = 1
Jmax-Jmin and s 2 = 1 Rmax-Rmin . Ideally, the boundary values of the objective functions correspond to their global maximum and minimum values. However, to emulate a live scenario as much as possible, all the processing was performed over a temporal window of 30 seconds. Using the actual boundary values in this case would not conform to the emulation.

Consequently, J min , R min , J max and R max were calculated by using a sinusoidal signal emulating an ideal blood volume pulse, y s = sin(t) where t corresponds to the time coordinates of the current temporal window. This was done by taking the maximum values of the objective functions over the frequency range of human heart rates, F ∈ [.7, 3] Hz. The minimum values were calculated in the same manner for a uniform random signal y r for the temporal window t.

Jmax = max F J(ys), Rmax = max F R(ys) (12) Jmin = min F J(yr), Rmin = min F R(yr) ( 13
)
Lagrange multipliers and Multi-objective Optimization. Finally, the entire problem was expressed as a Lagrange multiplier [START_REF] Bertsekas | Constrained Optimization and Lagrange Multiplier Methods[END_REF] formulation where a Newton-method like approach was used for optimization. The augmented Lagrangian method was used because of its wider applicability and robustness against the equality constraints owing to the penalty term that punishes violations to those constraints, making it more stable than the classical method of Lagrange multipliers. The Augmented Lagrangian for equation 9 is given as

L = [J(y) + R(y)] -λh(w) + 1 2 γ h(w) 2 ( 14
)
where λ is the lagrange multiplier for the constraint h(w), J(y) and R(y) are given by equations 10 and 11 respectively. . 2 denotes the Euclidean norm and the term 1 2 γ .

2 is the penalty term that makes sure that the optimization problem is held at the condition of local convexity assumption: ∇ 2 ww L >0. To find the maximum of L in equation 14 a Newton-like learning method was used to iteratively adapt w

w k+1 = w k -η(L w k ) -1 L w k ( 15
)
where k is the iteration index, η is the positive learning rate to avoid uncertainty in convergence and L w k is the first derivative of L at step k w.r.t w given by

L w k = s 1 ρE{xG y (y)} + s 2 E{R w (w)} -λE{xy} (16)
where the sign of E{G(y)} -E{G(v)} gives the value of ρ = ±ρ, G y (y) and R w (w) are the first derivatives of G(y) and R(w) w.r.t y and w respectively. The Hessian L w k in equation 15, is calculated as

L w k = s 1 ρR xx E{G y (y)} + s 2 E{R w (w)} -λR xx (17)
the inversion of which is not problematic because R xx being the covariance matrix of the whitened and centered signal x is an identity matrix. G y (y) and R w (w) are second order derivatives and L w k is of size 3 × 3. The first and second derivatives of R(w) are not trivial and are presented in the appendix. The optimum multiplier λ * is obtained iteratively based on a gradient-ascent method [18]:

λ k+1 = λ k + γh(w k ) (18)
Following the above equations, the optimization procedure converges to the optimum point defined by the doublet (w * , λ * ) representing the tuned parameter and final weighting matrix w * which is then used to obtain the final rPPG signal.

System Framework

The workflow of the procedure as depicted in figure 3 is presented here. Temporal RGB traces, x = [x 1 , x 2 , x 3 ] T where each x m , m ∈ [1...3], corresponds to a temporal trace of size N of each channel and was generated by spatial averaging of the pixels (face-cropped or skin-segmented). To this end, face detection and tracking was first performed using the Viola-Jones and the Kanade-Lucas-Tomasi implementations provided by the computer vision toolbox of MATLAB. Corner detection in the detected face was performed for tracking to crop the face based on facial landmarks. Skin detection as formulated by Conaire et al. [3] was then performed to select the candidate pixels which were then spatially averaged to obtain a triplet of RGB values per frame and concatenated to obtain the RGB temporal traces.

These temporal RGB traces were then detrended using a smoothness priors approach, with the regularization parameter λ set to 500, proposed by Karjalainen and Pasi [25] to remove low frequency trends in the signal. Next, after normalization, two additional preprocessing steps are generally recommended for ICA to simplify calculations. First, centering was performed so that the obtained signal y in y = Wx is zero-mean. Next, whitening was performed to ensure that the components were uncorrelated and their variances equal to unity. The traces were then passed to the rPPG extraction module where the MAICA algorithm was used to extract the rPPG signal.

After the rPPG signal was obtained, the per window heart rate was calculated from the highest peak of the FFT filtered within the acceptable range of heart rate F ∈ [.7, 3] Hz over a 30 second moving window using a step size of 0.5 second for our in-house datasets. Although, ICA is known to work much better with signals of longer duration, as mentioned earlier, all the processing was performed over a 30 second window, using the weighting matrix w k obtained at window k as an initial estimate for calculation of w k+1 at the next window. This 30 second window size was chosen as a trade-off between speed and availability of enough data for convergence. On the other hand, a 15 second window was needed for the MMSE-HR dataset owing to the shorter length of many constituent videos. The window-wise heart rate estimations were then smoothed using a Kalman filter.

The Kalman filter helped to remove spurious outliers resulting from abrupt variations in illumination and/or motion. The constant velocity motion model was used in the HR measurement with the motion and measurement noise variances set to 1 1 to reflect a standard deviation of 1 BPM. These values were fixed for the analysis of all the videos in the three different datasets that we used. They were chosen to represent a margin of 1 BPM in the motion and measurement noise models and were verified by trial and error in their ability to discard spurious outliers. The next section presents the experiments and results.

Experiments and Results

Two video databases, namely UBFC-RPPG and MMSE-HR were used to test the MAICA method. The inhouse UBFC-RPPG database comprises of two datasets. The first, labeled as SIMPLE, comprises of 9 videos (about 21k frames), where the subjects were requested to relax and close their eyes. The second dataset comprises of 46 videos (about 94k frames), labeled as REALISTIC, where the subjects were required to play a time sensitive mathematical game in order to vary the heart rate and also simultaneously emulate the scenario of the typical activity of using a computer. Both the datasets comprise of subjects with skin colors varying from dark to light tones. All the videos were taken under ambient light with limited illumination variations. The UBFC-RPPG database is made publicly available along with the ground truth data from the pulse The video frames were obtained with a custom C++ application using a Logitech C920 web camera placed at a distance of about 1m from the subject with a resolution of 640x480 in 8-bit uncompressed RGB format at 30 frames per second. A CMS50E transmissive pulse oximeter was used to obtain the ground truth PPG data. The experimental setup with sample images from UBFC-RPPG database are shown in figure 4 depicting the lighting conditions.

The MMSE-HR database was also used to test our method, the samples of which are equally shown in figure 4. The dataset comprises of 97 usable videos (about 105k frames) of varying length, at 25 frames per second of varied skin colors. Although, the main objective of the MMSE-HR database was for emotion elicitation, it does provide the video data and HR ground truth data for our validation. Also, MMSE-HR only provides the heart rate, and not the actual PPG waveform of the ground truth as compared to our UBFC-RPPG dataset. Thus, when using the UBFC-RPPG database, a more meaningful validation and comparison can be achieved since the same algorithm can be used to extract the heart rate from both the PPG and the rPPG waveforms.

Figure 5 shows a typical rPPG signal from a simple video and its heart rate estimation, HR rP P G vs HR P P G , the heart rate estimation of the ground truth signal using the Fast Fourier Transform (FFT). The high correlation between the rPPG and PPG signal is clearly visible in the figure, and so is the correlation between HR rP P G and HR P P G .

Figure 6 shows the correlation comparisons between ICA [22] and MAICA for the two databases where HR P P G and HR rP P G are plotted against each other. The metrics PRECIS 2.5 and PRECIS 5 show the percentage of windows where δ = |HR rP P G -HR P P G | < 2.5 and 5 beats per minute (bpm) respectively. MAE corresponds to the average mean absolute error between HR rP P G and HR P P G in bpm calculated over all the windows for all videos. As the name suggests, the analysis of the SIMPLE dataset, which can be thought of emulating a patient at rest, was not challenging and both ICA and MAICA performed well. However, MAICA did result in fewer outliers than ICA.

The REALISTIC and the MMSE-HR datasets were understandably more challenging. However, MAICA demonstrated a better correlation between HR P P G and HR rP P G . It is also evident that the lesser number of outliers were a direct cause of better convergence towards the correct rPPG signal. The MAICA method also provided stronger peaks in the FFT periodogram along with better HR estimates. It also provides a better performance than the Self-Adaptive-Matrix Completion method introduced in [START_REF] Tulyakov | Self-Adaptive Matrix Completion for Heart Rate Estimation from Face Videos under Realistic Conditions[END_REF] whose MAE is 7.6 bpm as compared to our 5.2 bpm. However, this comparison is not very clear since we do not use the same ROI selection method as them. We also provide more rPPG data using our skin masks. Table 1 shows the accuracy comparisons between ICA and MAICA and other state of the art methods, viz., PCA [16], Green [START_REF] Verkruysse | Remote plethysmographic imaging using ambient light[END_REF], CHROM [START_REF] De Haan | Robust pulse rate from chrominance-based rPPG[END_REF], POS [30], and G-R [12]. The metrics used are apart from MAE are signal-to-noise ratio (SNR) and Pearson's correlation coefficient (r) between heart rate calculated using the rPPG signal, HR rP P G and the heart rate calculated using the ground truth PPG waveform, HR P P G . The windowed method is computationally more taxing, owing to the smaller window length, but is more realistic. The SNR (dB) was calculated as the ratio of the power of the main pulsatile component of the PPG to that of the background noise to accommodate the wide dynamic range of the signals. However, it is to be noted that the MMSE-HR database does not provide the ground truth waveforms, thereby obliging the use of the main pulsatile component of the RPPG instead of the PPG for the SNR calculation. As a result, the SNR values for the MMSE-HR database are not really relevant and are omitted in table 1. It is worth mentioning here that although the MAICA is not faster than the ICA since one the autocorrelation objective function has to be additionally calculated, its novelty lies in the combination of the periodicity information with the notion of independence used by the ICA algorithm. Of course, optimizations can be easily performed for calculating these objective functions which can improve the computation times drastically. This combination can be also formulated as a Constrained ICA problem as has been done in [START_REF] Macwan | Remote photoplethysmography with constrained ICA using periodicity and chrominance constraints[END_REF].

The analysis of the SIMPLE dataset, as the name suggests, was quite easy for almost all the methods. However, MAICA did remove the few outliers that are present in the case of ICA. This is reflected in the low MAE and high SNR values as shown in table 1. This can be attributed to the fact that the subjects were generally relaxing, mostly with their eyes closed, which resulted in minimal motion artifacts. On the other hand, the REALISTIC dataset was more challenging since the subjects were actually working on the computer and were only requested to keep their hand still for the PPG sensor. Similarly, the MMSE-HR database was challenging owing to it being an emotion elicitation database. There were many instances where the subjects laughed out loud and exhibited considerable movements. This resulted in the usual problems arising from movement of the subjects. Consequently, the presence of outliers was more pronounced for both the REALISTIC dataset and the MMSE-HR database, which MAICA was able to reduce. This can be seen in table 1, where the pearson correlation coefficient was also closer to unity which is also evident from figure 6 where the fitting line was closer to the 45 • line as compared to ICA. Finally, in figure 7 we present the window-wise heart rate comparisons between ICA and MAICA, notably for videos where ICA is not entirely successful. The combination of the autocorrelation function with the ICA negentropy function in the premise of multi-objective optimization enables the extraction of a more accurate rPPG signal closer to the ground truth. Videos from the UBFC-RPPG SIMPLE dataset are not presented in this figure since there was not much difference between the performance between ICA and MAICA owing to the simplicity of these videos. With regards to the MMSE-HR dataset, it actually proved to be useful in highlighting the versatility of our method in presence of motion artifacts arising from facial expressions, as is visible in the snapshots in the figure. It is to be noted that almost all the videos of the MMSE-HR dataset manifested changing facial expressions and moving faces.

Conclusions and future work

In this paper we presented a novel semi blind source extraction method, MAICA, for the application of rPPG measurements using multi-objective optimization with mean squared autocorrelation and negentropy as the objective functions. The method provides better results than other state of the art methods while removing the extra step for choosing the best component. The periodogram of the extracted signals was also consistently closer to that of the PPG. Our method can also be combined with other methods like smart ROI selection [START_REF] Li | Remote Heart Rate Measurement From Face Videos Under Realistic Situations[END_REF] to further obtain better rPPG estimations.

We also present two datasets of 9 and 46 videos respectively recorded under ambient light. This database is aimed towards testing of rPPG algorithms and is made publicly available. The SIMPLE dataset is not very challenging and can be used as a starting point for basic rPPG algorithms. The REALISTIC dataset emulates an everyday working scenario and can be used as a benchmark for applications aimed at working in live environments.

The assumption that the most periodic component is the cardiac pulse signal does not hold in scenarios with periodic motion e.g. in fitness. Our method can thus benefit from motion compensation and improve HR estimations in a more realistic scenario with motion disturbances. We have not considered constraints related to the unique manner of light scattering on skin due to its physical properties. Such constraints might help to improve the method further. Finally, we average the pixel data (cropped or skin segmented) to obtain a single value and thus loose any spatial information. Higher order analysis which preserves the spatial relationships between pixel neighborhoods can be an important avenue to look into. can be obtained as follows considering squared autocorrelation as r 2 = [r 2 1 r 2 2 ... r 2 N ].

R (w) = -E{ ∂ ∂w ( r 2 1 r 2 2 • • • r 2 N )} (A.2)
where the derivative of the squared autocorrelation r 2 is then obtained using the chain rule of derivatives. Also, we have y = w T x giving ∂y ∂w = x. The size of ∂(r 2 ) ∂w is then 3×N from the product of x 3×N with the jacobian of size N ×N . Consequently, its expectation ends up having a size of 3×1 since it is nothing but a temporal mean over N samples. The jacobian in equation A.6 can be concisely expressed as r 1 where ∂ ∂y (T k y T ) = T T k comes from the fact that the differential of T k y T , a vector, will remain the same even when it is transposed and the derivative is computed element-wise. This result is owing to the fact that T k is not symmetric. If it were symmetric, then the result would have been 2yT k .

∂(r 2 ) ∂w = x ∂(r 2 ) ∂y (A.3) = x        ∂(r 2 1 ) ∂y1 ∂(r 2 2 ) ∂y1 • • • ∂(r 2 N ) ∂y1 ∂(r 2 1 ) ∂y2 ∂(r 2 2 ) ∂y2 • • • ∂(
For conciseness, we will represent the sum T k + T T k as T k . Finally to be consistent with our convention, using the same argument of the differential being immutable under transpositions, the row vector ∂r k

∂y can be transposed into a column vector and the matrix ∂r ∂y can be built as ∂r ∂y

= r 1 T 1 y T • • • r N T N y T (A.8)

  (a) W eights ICA (b) HR ICA (c) W eights M AICA (d) HR M AICA

Figure 1 :

 1 Figure 1: Window-wise weight analysis showing ICA weights and HR in (a) and (b) vs MAICA weights and HR in (c) and (d). For the exact same data, different values of w = |w R , w G , w B | corresponding to the RGB channels can extract an accurate rPPG signal. Absolute values of the weights are shown for concise display.

Figure 2 :

 2 Figure 2: Autocorrelation of a sinusoid vs a random signal

Figure 3 :

 3 Figure 3: Flowchart of the proposed method

Figure 4 :

 4 Figure 4: Experimental Setup (left) and sample images from the SIMPLE and REALISTIC datasets from the UBFC-RPPG database (top-right) and the MMSE-HR (bottom-right) database

Figure 5 :

 5 Figure 5: Extracted rPPG signal for video 10 of the SIMPLE dataset of the UBFC-RPPG database. HR sensor is HR from the finger sensor. HR rPPG filtered is HR rPPG after Kalman filtering

Figure 7 :

 7 Figure 7: ICA vs MAICA for certain videos from the UBFC-RPPG\REALISTIC and MMSE-HR datasets. The FFT periodogram was used to perform the HR measurements over temporal windows of 30s and 15s respectively for the two datasets owing to the shorter lengths of videos in the latter dataset.

  where each column is the product of the derivative ∂r1 ∂y and the scalar r k and is of size N × 1. Deriving r k = yT k y T w.r.t y using the product rule of differentiation,∂r k ∂y = y ∂ ∂y (T k y T ) + yT k ∂ ∂y (y T ) = y ∂ ∂y (yT T k ) + yT k = yT T k + yT k = y(T T k + T k ) (A.7)

Table 1 :

 1 Performance comparisons between the various methods using Mean Absolute Error (MAE), Signal-to-Noise Ratio (SNR) and Pearson's correlation coefficient (r)

				UBFC-RPPG			MMSE-HR
			SIMPLE		REALISTIC
		MAE SNR	r	MAE	SNR	r	MAE r
	MAICA	0.55	2.98	0.99	3.34	-0.26 0.89	3.91	0.86
	ICA	0.82	2.73	0.98	6.16	-1.23	0.76	5.28	0.70
	PCA	2.04	-1.43	0.97	9.65	-3.45	0.67	9.15	0.49
	Green	9.86	-1.61	0.29	7.73	-2.78	0.68	10.65 0.47
	CHROM	0.72	3.04	0.99	3.81	-0.93	0.87	5.59	0.83
	POS	0.67	2.57	0.99	4.73	-1.60	0.80	5.77	0.82
	G-R	0.67	1.97	0.99	9.79	-3.10	0.65	8.56	0.58

http://ilt.u-bourgogne.fr/benezeth/projects/UBFCRPPG

Appendix A. Derivatives of R(w)

Here we present the first and second derivatives of R(w) needed by the Lagrange multipliers method. We follow the convention that the derivative of a scalar w.r.t a column vector is a column vector of the same size as that of the vector. The first derivative of R(w) in

giving R (w) in equation A.2 as

which can be further simplified to

since the expectation is a temporal mean the element-wise multiplication with r k can be replaced by multiplication with the vector r T which also simplifies the computation. Next, to simplify the calculation of the second derivative of R(w), we perform column-wise matrix multiplication in equation A.9, omitting the scalar multiplication and division, to obtain

And since differentiation and summation are interchangeable based on the sum rule, R (w) can be obtained by

The derivative of T k r k y T w.r.t y is then obtained by the product rule of differentiation.

which is of size N × N . Consequently, the size of R (w) turns out to be 3 × 3 since the sum of

over N samples is also of size N × N . These formulas of R (w) and R (w) are then used in the implementation of the multi-objective optimization algorithm.


Jean-François Lalande
email: jean-francois.lalande@inria.fr

Valérie Viet

Triem Tong

Pierre Graux

Guillaume Hiet

Wojciech Mazurczyk
email: wmazurczyk@tele.pw.edu.pl

Habiba Chaoui
email: habiba.chaoui@uit.ac.ma

Pascal Berthomé
email: pascal.berthome@insa-cvl.fr

Teaching Android Mobile Security

Keywords: platform security, Software security engineering, Software reverse engineering teaching, mobile, security

At present, computer science studies generally offer courses addressing mobile development and they use mobile technologies for illustrating theoretical concepts such as operating system, design patterns, and compilation because Android and iOS use a large variety of technologies for developing applications. Teaching courses on security is also becoming an important concern for academics, and the use of mobile platforms (such as Android) as supporting material is becoming a reasonable option. In this paper, we intend to bridge a gap in the literature by reversing this paradigm: Android is not only an opportunity to learn security concepts but requires strong pedagogical efforts for covering all the aspects of mobile security. Thus, we propose teaching Android mobile security through a two-dimensional approach. The first dimension addresses the cognitive process of the Bloom taxonomy, and the second dimension addresses the technical layers of the architecture of the Android operating system. We describe a set of comprehensive security laboratory courses covering various concepts, ranging from the application development perspective to a deep investigation of the Android Open Source Project and its interaction with the Linux kernel. We evaluated this approach, and our results verify that the designed security labs impart the required knowledge to the students.

INTRODUCTION

At present, Android programming is an integral part of most undergraduate studies in computer science. It was introduced as a complete knowledge area in 2013 (platform-based development) in the Curriculum Guidelines for Undergraduate Degree Programs in Computer Science [START_REF] Rizwan | Teaching Cyber Security Using Competitive Software Obfuscation and Reverse Engineering Activities[END_REF]. The same year, security aspects were also introduced as a new knowledge area named "Information Assurance and Security." The Android platform can be used for a variety of learning purposes concerning operating system, wireless communications, advanced design pattern, etc. Skills in mobile programming are of significance as even web services generally develop a companion application that the user can install on a smartphone.

When addressing the security aspects of mobile computing, it is challenging to discuss concepts without referring to their implementation. Security concepts such as access control, authentication, or cryptography can still be presented as an independent course. However, the manner in which attackers attempt to bypass the implemented security countermeasures of modern smartphones should be presented with complete knowledge of the Android's internal aspects.

In this paper, we propose a set of labs intended to teach about threats and the security internals of Android applications and operating system. The approach is original in that it follows a progression based on the Bloom taxonomy [START_REF] David R Krathwohl | A Revision of Bloom's Taxonomy: An Overview[END_REF] and works on the security aspects of the complete software stack of Android. We propose a variety of activities that enhance students' skills from those for developing simple applications to those for more complex activities such as analyzing vulnerable applications under attack or reversing packers. Additionally, the labs cover the different internal components of Android, which aids students to gain knowledge of the internal classes of the Android runtime, the execution and compilation of Android applications, and the link with the operating system. These two dimensions-the student cognitive process and the coverage of the different levels of the Android software stack-aid students to better analyze mobile security problems.

The paper is organized as follows: Section 2 summarizes the state of the art in the learning of Android development and security. Section 3 presents our approach, and Section 4 provides the technical details of each lab. Section 5 summarizes the feedback we have collected. Section 6 concludes the paper.

RELATED WORK

Application Development and Operating Systems with Android. It is apparent that a pre-requisite for teaching mobile security is fluency in the underlying programming language and the main concepts of application development. For example, Tigrek et al. [START_REF] Tigrek | Teaching smartphones programming using (Android Java): Pedagogy and innovation[END_REF] propose a minimal course for first year engineering students to discover Android programming. Among the presented principles, "How Without Why" (program based on tutorials) combined with "Just Enough Java" (learn the essential Java patterns) are effective for learning to develop an application, although is not sufficient for understanding the security impact of a selected implementation [START_REF] Acar | You Get Where You're Looking for: The Impact of Information Sources on Code Security[END_REF]. In Bloom's revised taxonomy of educational objectives [START_REF] David R Krathwohl | A Revision of Bloom's Taxonomy: An Overview[END_REF], these two pieces of procedural knowledge are used to distinguish between "knowledge of subject-specific skills" and "knowledge of criteria for determining when to use appropriate procedures". Additionally, we consider that in the structure of the cognitive process (remember, understand, apply, analyze, evaluate, and create) the three last cognitive processes require a deep understanding of the internal aspects of mobile application and the underlying operating system.

The Android framework can also be used as supporting material to teach more general software engineering [START_REF] Campbell | An Experience Report: Using Mobile Development To Teach Software Design[END_REF][START_REF] Sung | Mobile application development classes for the mobile era[END_REF] or operating system [START_REF] Andrus | Teaching operating systems using android[END_REF] concepts. Notwithstanding whether these works are effective for a better understanding of the concepts, most of the presented material does not describe the Android system with adequate details to aid the investigation of the security aspects of mobile devices.

Mobile Security.

A few studies use Android as a platform for experimenting with general security notions, e.g., filtering traffic in firewalls [START_REF] Trabelsi | Android based mobile apps for information security hands-on education[END_REF] or countering Denial of Service attacks [START_REF] Trabelsi | A Smartphone App for Enhancing Students' Hands-on Learning on Network and DoS Attacks Traffic Generation[END_REF]. However, they do not address the specificities of mobile systems and applications.

A few previous works [START_REF] Guo | Learning mobile security with android security labware[END_REF][START_REF] Neis | Developing a Unique Android App-driven Nifty Middle-School Educational Module on Mobile Security for Driving Basic Information Security Awareness and Generating Interests in Cybersecurity[END_REF][START_REF] Yuan | Teaching mobile computing and mobile security[END_REF] have described the particularities of teaching security aspects of mobile applications and platforms. Nevertheless, in most cases, only foundational aspects that are relevant for Android developers are covered.

The approach of Guo et al. [START_REF] Guo | Learning mobile security with android security labware[END_REF] is one of the works closest to our proposal. They have designed a labware of seven modules, which illustrates the concepts of mobile security and privacy. The learning approach is based on two main concepts. First, the course uses an attack/defense lab, where the students are required to implement attacks prior to implementing the corresponding protection mechanisms. Such an approach aids the students to better comprehend the security issue and to implement more effective protections. Secondly, the provided material (slide, tutorials) and the content of the In our opinion, these works lack progression in the Bloom taxonomy and do not cover the different levels of the Android software stack. The next section develops this concept before the description of the labs in Section 4.

LEARNING MOBILE SECURITY

A deeper understanding of all the security components of Android requires comprehension of the whole stack of technologies that is used by the Android Open Source Project (AOSP) [START_REF] Elenkov | Android Security Internals: An In-Depth Guide to Android's Security Architecture[END_REF][START_REF] Gunasekera | Android Apps Security[END_REF]. Describing security APIs from the developer's perspective can be a starting point for discovering features such as account management, permissions, and cryptographic primitives. Nevertheless, most of the security features are provided by the operating system, and explaining them requires sufficient knowledge of operating systems, runtime environments, and networks. Examples of such features are the installation process of applications, storage of credentials, role of SELinux, and update process of the operating system.

Additionally, students should comprehend the heterogeneous nature of the attacks likely to target Android devices. We have presented a few examples of vulnerabilities in Table 1 that illustrate the diversity of the likely threats. The kernel is the most challenging component to attack, and a representative vulnerability is the Futex vulnerability 1 , which enables, under certain conditions, the execution of arbitrary code in the kernel mode and to root the phone. On top of the kernel, the Android services can be exploited, e.g., the process that installs or updates applications. An example of such a threat is the Janus exploit that abuses a vulnerable signature verification implementation. Similar attacks target the direct environment of the malicious application, i.e., the Dalvik virtual machine or the ART library that implements security verifications for the running application. Moreover, the attacker can attempt to abuse the SDK itself by identifying vulnerable classes [START_REF] Peles | One Class to Rule Them All: 0-Day Deserialization Vulnerabilities in Android[END_REF] with controllable side-effects. Finally, and this constitutes a significant part of the attacks, the attacker does not exploit any vulnerability but performs malicious activities using the requested permissions. Examples of such applications are ransomware, cryptominers, and remote administration tools.

Taking these remarks into consideration, we describe the structure of the proposed labs and detail their content, in the next section. [START_REF] Levin | Android Internals: A Confectioner's Cookbook[END_REF][START_REF] Yaghmour | Embedded Android: Porting, Extending, and Customizing[END_REF] Designing graphical interfaces Messaging components

Chapter 2 Concurrency and synchronization

Connectivity and sensors Chapter 3 Security [START_REF] Elenkov | Android Security Internals: An In-Depth Guide to Android's Security Architecture[END_REF][START_REF] Gunasekera | Android Apps Security[END_REF] Wear OS [START_REF] Esakia | Augmenting Undergraduate Computer Science Education With Programmable Smartwatches[END_REF] Firebase Cloud Messaging

ANDROID SECURITY LABS 4.1 Security Labs Design

We have developed several labs 2 which cover different Android components involved in the understanding of mobile security. We present these labs in Table 2, following Bloom's revised taxonomy of educational objectives [START_REF] David R Krathwohl | A Revision of Bloom's Taxonomy: An Overview[END_REF]. Students should follow these labs from left to right in the table, eventually completing the sequence with a security project (PROJ) that corresponds to the deepest cognitive process of the taxonomy (Create).

The number of hours depends of the level of knowledge teachers intend to obtain. We distinguish three levels: level 1 (~2h) provides fundamental knowledge or focuses on a particular aspect; level 2 (~5h-8h) enables the student to cover more notions and practice with real devices; level 3 (~20h) aids the student to cover a large variety of notions or to work on a particular one with important software development. Most of the labs use level 1 or 2 (e.g., INST and MAL); however, a few of them (e.g., DEV and COV) can use level 3 or can be adapted as a security project (PROJ).

The first two labs (Remember process) train the students to develop Android applications (DEV) and to flash a custom Android image on a smartphone (INST). Such labs are typically observed in other available approaches [START_REF] Andrus | Teaching operating systems using android[END_REF][START_REF] Sung | Mobile application development classes for the mobile era[END_REF][START_REF] Tigrek | Teaching smartphones programming using (Android Java): Pedagogy and innovation[END_REF]. Then, two labs enhance the students in the understanding of benign (BANK) and malicious applications (MAL) by reversing their bytecode. This aids the studying of attacks at the application level and their associated countermeasures (debugger detection, obfuscation, etc.) that can be used both by malicious and legitimate applications.

The subsequent labs correspond to the "Apply" step in the taxonomy. Students are encouraged to implement attacks and countermeasures with their previously acquired knowledge. For this purpose, we propose two use cases. The first one (COV) is proposed to defeat the Android access control system by implementing a covert channel between two applications that do not have permission to interact with each other. The second one (MEM) is proposed to exploit a dump of the volatile memory to recover certain confidential information. The likely benefit of these labs is to compel the students to obtain deeper knowledge of the low-level components of Android, i.e., the leakage induced by the operating system and its primitives (COV) and the Dalvik (or Art) data structures used to represent the Java classes of the applications in volatile memory (MEM).

2 https://gitlab.inria.fr/jlalande/teaching-android-mobile-security Contrary to the previous labs, wherein students are completely guided while they practice, the three subsequent labs require the performance of security analysis (Analyze process). We provide the symptoms of certain issues to the students, and we expect an investigation and eventually certain remediation. In the first lab (CLASS), students are required to analyze an application that uses a vulnerable class loader. The second lab (PACK) proposes to analyze a malicious application obfuscated with packing techniques. The third lab (KERN) focuses on low level vulnerabilities by performing ROP attacks using gadgets of the kernel.

Note that no lab is classified in the "Evaluate" cognitive process as the distinction between "Analyze" and "Evaluate" is marginal. In particular, in [START_REF] Rizwan | Teaching Cyber Security Using Competitive Software Obfuscation and Reverse Engineering Activities[END_REF], only three levels of mastery is proposed (familiarity, usage, assessment). Thus, we use only four levels of the Bloom taxonomy for classifying our labs; additionally, we propose various security projects (PROJ). They are designed to explore a specific subject with a large number of hours (level 3 or higher) for a group of students and may be linked to research activities.

DEV Lab: Android Development

The DEV lab provides the pre-requisite for understanding the fundamentals of Android development. We classify this lab in Bloom's taxonomy in the "Remember" process as we do not intend to train software developers and rather intend to teach the fundamentals for discussing security aspects. The topics covered depend on the amount of time allocated, and we distinguish three chapters of knowledge, as presented in Table 3.

Learning outcomes. At the end of the lab, we expect the students to comprehend the architecture and deployment of an Android application. The students should be capable of developing an application that communicates with a remote server, using REST API.

INST Lab -Compiling, Modifying, Flashing

Numerous other laboratories presented in this paper are required to be able to setup a clean image of the smartphone. As indicated by Guo et al. [START_REF] Guo | Learning mobile security with android security labware[END_REF], students appreciate having a real device to experiment with while performing development or hacking activities. Moreover, it is occasionally more difficult to work with an emulator, for example to play with the different sensors, or to pair an emulated smartphone with an emulated Wear watch, which may require the installation of the Google APIs with an active Google account.

The INST lab (level 1) includes the compilation of a complete AOSP distribution for a Google Nexus 5 or 5X or Sony Xperia X smartphone and then the flashing of the compiled images. Additionally, the Nexus models offer the capability to debug the kernel output using serial headphone jack. For that purpose, we constructed a small serial debugger that aids students involved in advanced labs, where the kernel is modified and is likely to crash during runtime.

Learning outcomes. Students are able to customize the source of an operating system and install it on a device.

MAL Lab -Malware Reverse Engineering

The MAL lab consists in reversing several types of malware using different open source tools. The pedagogical goal of the lab is to demonstrate that each type of malware requires a custom reverse process. The lab consists of multiple exercises. Thus, the required number of hours can be adapted from level 1 to 3. In Bloom's taxonomy, we place this lab in the "Understand" process because we provide the students with the entire set of instructions for reversing the malware. We present the two most representative ones.

Programming an antidote for a ransomware. The students install a ransomware on a provided smartphone. They observe that the image files are encrypted by the malware. Then, the students explore the code using BytecodeViewer 3 or Jadx4 in order to identify the service that encrypts the images. The code analysis reveals that the AES ciphering key used by the ransomware is a constant. Thus, after locating the deciphering code, the students modify the malicious application using to a bytecode editor so that it calls the deciphering code. Finally, they use this modified application to recover the images on the smartphone.

Observing spyware. The students are first required to reverse the spyware and locate the code that extracts personal data (accounts, phone number, IMEI) and the code that transmits the data to a remote server, whose domain name is identified. for the sake of simplicity. We also propose the observation of the leaked data in network traces as part of the lab in order to confirm the static analysis. To achieve this goal, the students setup a local web server, use the ngrok website 5 to create a public URL of the form x.ngrok.io, and link this URL to the local web server. Then, using a provided tool based on Soot 6 , the students substitute the domain name used by the malware with this URL. Executing this new version of the malware enables one to capture the first requests that are responsible for leaking user's data.

Learning outcomes. Students comprehend the different types of threat that security analysts confront. They discover the process of reverse engineering with three approaches. This emphasizes the fact that security analysts have to adapt their methodology to the nature of the threat. At this stage, the investigation process is specified; however, students understand that a custom process should be designed for each malware.

BANK Lab -Banking Application Reverse

This lab consists in reversing the authentication activity of a real banking application. This lab is completely guided, which places it in the "Understand" process of the taxonomy and aids to fit its duration to level 2.

The students are required to comprehend the protocol that is used by the application to authenticate the user to a remote server. The banking application receives a challenge from the server, which is used to generate a virtual keyboard. This permits the application to obfuscate the entered password.

First, students unpack the application and uncompile the bytecode into Java source code using Jadx. This phase aids them to identify the activities and classes involved in password encoding. Second, students observe the evolution of the application state. Using AndBug 7 , students can put breakpoints on specific bytecode instructions. In particular, it aids them to identify the code that transmits the encoded password to the server. They also install a counterfeit certificate in the smartphone to bypass the verification of the remote server's authenticity. This permits them to monitor the network traffic using the Burp Suite proxy 8 . Finally, the students precisely identify the Java objects that encode the password and that are transmitted to the server when the user attempts to authenticate. By capturing both the challenge received from the server and the encoded password transmitted by the application, the students can recover the password.

Learning outcomes. Students comprehend the countermeasures used by applications for critical parts such as the authentication phase. They train themselves to bypass these countermeasures as a real attacker would. Working on attack design aids the understanding of the limits of current security implementations.

COV Lab -Developing Covert Channels

The COV lab (level 2 or 3) consists in developing a covert channel between two Android applications [START_REF] Marforio | Analysis of the communication between colluding applications on modern smartphones[END_REF] in order to bypass the enforced security policy.

We provide two applications App1 and App2 to the students. App1 collects certain sensitive data of a user but does not have the permissions to use the network. App2 cannot access confidential data but has the necessary permissions to use the network. Those applications cooperate to leak the data. To achieve this, App1 establishes a local covert channel with App2 which is based on the remaining free space in the flash memory. This can encode the secret data bits if the sender (App1) creates and deletes large files. Snippets of code are provided to the students to aid them to develop the covert channel inside an asynchronous task. Moreover, countermeasures against such threats are discussed and analyzed. If time permits, certain countermeasures can be implemented using papers of the literature [START_REF] Marforio | Analysis of the communication between colluding applications on modern smartphones[END_REF][START_REF] Urbanski | Detecting Local Covert Channels Using Process Activity Correlation on Android Smartphones[END_REF].

Learning outcomes. By completing this lab, the students become aware of the threat posed by covert channels and the means by which an enforced security policy can be bypassed. Students can also discover advanced detection techniques.

MEM Lab -Memory Dump Forensic

This lab (level 2) has been inspired by studies on recovering credentials from volatile memory [START_REF] Apostolopoulos | Discovering authentication credentials in volatile memory of Android mobile devices[END_REF][START_REF] Stirparo | Data-in-use leakages from Android memory -Test and analysis[END_REF]. It is highly challenging for Java applications to clean their memory after allocating certain objects even after rebooting the device [START_REF] Ntantogian | Evaluating the privacy of Android mobile applications under forensic analysis[END_REF]. Thus, we have designed a lab wherein students inspect a dump of the memory obtained with Lime 9 . This dump is achieved after displaying a simple application with two EditText objects, which simulates an authentication activity. The goal of the lab is to capture the content of the two EditText objects from the dump.

Then, students should inspect the memory dump using the Volatility framework 10 . After identifying the Linux process corresponding to the Dalvik VM, we provide extensions for inspecting the heap of the virtual machine based on the work of Hilgers et al. [START_REF] Hilgers | Post-Mortem Memory Analysis of Cold-Booted Android Devices[END_REF]. Using Python scripts, students can manipulate classes and objects and their implementation at the C programming language level. Students are invited to write the script that enumerates all the classes and to identify the ones that extends EditText. This aids them to retrieve the credential from the memory dump.

Learning outcomes. Students comprehend the likely leaks induced by the memory management of Java-like virtual machines, Dalvik and Art. They are capable of conducting a simple forensic of a memory dump, which is of interest to digital investigators.

CLASS Lab -Vulnerable Class Loader

The CLASS lab (level 2) places the students in a situation wherein an attacker has compromised the remote server used by the application. We ask students to analyze and solve the situation following Bloom's taxonomy. This learning approach has already been investigated for learning web development in a secure manner [START_REF] Sonntag | Learning security through insecurity[END_REF]. In our lab, the vulnerable application loads a few classes from the remote server that is supposed to have been compromised by the attacker. The students have access to the source code of the first activity although not to the sources of the remote classes. They are required to investigate different attacks and if feasible, implement countermeasures.

The vulnerable application is composed of a regular activity that dynamically loads other activities from the remote server. The vulnerabilities are twofold. First, the application uses a custom class loader that is ineffectively implemented because it systematically loads classes from the remote resources rather than first asking the hierarchy of class loaders. Thus, the classes from the Android runtime such as Checkbox or LinearLayout can be overwritten by the downloaded activities. This can be used by the attacker to take control of the main activity. Secondly, the first activity stores certain confidential data in a static field. The attacker can access it later from the loaded activity, which is an unintentional leak of information. To disable those attacks, the students are required to patch the class loader and use an instance field rather than the static field.

Learning outcomes. Students should be capable of conducting a complete investigation of an application connected to a compromised server. Tthey should understand that an implementation can contain vulnerabilities if the developer does not comprehend the mechanisms induced by the used language or the operating system.

PACK Lab -Packers

The PACK lab (level 2) consists in reversing the MAL lab ransomware that are now obfuscated with different packing techniques. The packer uses native code to unpack the payload at runtime. The obfuscated methods are decoded immediately before being called and are re-encoded when they return. This lab requires a deep analysis to determine how the obfuscated code can be retrieved.

First, the students execute the applications in order to observe that they behave as those of the MAL lab. Then, they use Bytecode-Viewer or Jadx to inspect a specified malware sample and determine that the code of certain methods is empty. Using IDA Pro 11 , the students are required to discover how the native code obfuscates the Java methods. At this stage of the lab, it is feasible to retrieve the original code of the malware sample.

However, additional ransomware samples using different packing algorithms are provided to the students. Consequently, new static analysis of each packing algorithm would be required, and therefore, we propose to switch to a dynamic approach. The students are guided to modify the code of AOSP: The Android VM is modified to dump the code of each method before executing them. We provide the most challenging parts of the modifications to the students to aid them to complete the lab. Based on the INST lab, the students flash the Sony Xperia X smartphone with the modified Android system. This permits them to automatically reverse all the samples.

Learning outcomes. Students comprehend and analyze the work achieved by a packer using ciphering algorithms. They also comprehend the benefit of a solution based on a combination of a static analysis and a dump that is performed during execution.

KERN Lab -Kernel ROP Attacks

The KERN lab (level 2 or 3) goes deeper into the security aspects related to Android's kernel. In this lab, we provide an emulator with a kernel containing a vulnerable driver. This driver can be exploited with a buffer overflow vulnerability that enables the execution of an arbitrary short payload. Because the kernel implements a W xor X policy, students are required to perform a ROP attack with gadgets available in the kernel. For achieving this step, students use ROPgadget 12 to search for gadgets in the vmlinuz file. The "Hello World" example consists in printing a message in the kernel logs. Students should learn to call the printk kernel function using several gadgets. If time permits, more complex attacks can be achieved to spy the memory of a targeted process.

Learning outcomes. This lab illustrates the importance of the security of all Android components. It trains students to perform attacks using multiple vectors including attacking the system itself.

The material associated to these labs can be found online at https://gitlab.inria.fr/jlalande/teaching-android-mobile-security

EVALUATION 5.1 Audience

The presented labs have been used in several undergraduate programs in eight universities and engineering schools of three countries. We did not have the opportunity to play all the labs for the same pool of students. Nevertheless, multiple combinations of two or three labs have been tested. We have also used these labs for research summer schools and tutorials at international conferences for illustrating technical aspects of mobile security. Nevertheless, at the time of writing, the goal of this work is also to introduce the whole sequence of labs in the master degree curriculum, where security aspects have an important position.

Evaluation Design

We designed a survey for asking students to evaluate their capabilities with regard to the labs they attended. The concept was to ask the students to evaluate themselves regarding only one lab in order to measure the correlation between the lab they followed and the skill evaluated. If they followed two labs, we asked them to evaluate themselves with respect to the lab with the highest number of hours. The survey was sent in spring 2018 to the students we had taught between 2014 and 2018. From among the approximately 200 students, we obtained responses from 87.61% followed the lab a few months ago, 19% a year ago, 14% two years ago, and the remaining 6% over two years ago. Table 4 presents the obtained results. The left column recalls the asked questions which correspond to the pedagogical goal of a lab. On the right, student evaluations have been reported in the column corresponding to the name of the lab they followed. With such a presentation of the results, the correlation should occur on the diagonal of the table. For evaluating each question, we used the following marking system inspired by the work of Campbell et al. [START_REF] Campbell | An Experience Report: Using Mobile Development To Teach Software Design[END_REF]: 1) Unknown (No trace in my memory); 2) Discovering (I recall some of the content); 3) Intermediate (I understood most of the content); 4) Good knowledge (I am able to do the lab again, without a supervisor and with the help of documents); 5) Advanced (I can reuse my knowledge in another use case).

For each question, a student is asked to rate himself/herself "before" and "after" the lab, which enables the computation of a differential score corresponding to the difference in the mark before and after the lab. This provides more information than the raw mark does with regard to whether the students have previously followed courses on related topics. It enables the evaluation of the progress of the students irrespective of their starting point. In Table 4, m corresponds to the average of the marks "after the lab" (from one to five) and δ corresponds to the average of the differential marks.

Evaluation Results

The correlation between the labs and the evaluated skills is evident: for each lab, the highest scores correspond to the pedagogical goal of the lab. The improvement in student's skills on the diagonal is an average of +1.85, which is encouraging as it is approximately equivalent to shifting from "Discovering" to "Good knowledge." Only the CLASS lab achieves an improvement of +0.91. This can be explained by the level of difficulty of the lab, which corresponds to the Analyze phase of the taxonomy and requires substantial effort of investigation by the students. The CLASS lab also achieves a progression of +1.36 for the DEV lab. This can be explained by the fact that the CLASS lab involves HTTP requests.

The self-evaluation of skills by the students yielded an average mark of 3.31 on the diagonal. The marks of the MAL and MEM labs are approximately equal to 3, which is a reasonable result considering the technical challenge associated with them. The COV labs achieved the highest mark (3.82). We conjecture this to be a result of the high number of allocated hours for this lab. More simple activities achieve higher results (DEV, INST) as students feel comfortable when performing the labs.

The results confirm that the labs are aligned with their pedagogical goal. The marks reveal that students tend to evaluate their skills between intermediate and reasonable knowledge levels. Indeed, only years of practice can provide further knowledge.

CONCLUSION

This paper explores several technical aspects with regard to the learning of Android security. Based on Bloom's taxonomy, we designed various labs that aid students to learn more deeply about the internal aspects of Android. By programming attacks and studying malware or vulnerable applications, students are trained to analyze complex security problems. This pedagogical design aids them to improve their skills in mobile security by providing a deeper understanding of the complexity of the software components used by Google to design its operating system.

Table 1 :

 1 Attacks targeting different Android components

	Components	Examples of attack	CVE
	Applications	Android ransomware, spyware, adware
	AOSP classes	OpenSSLX509Certificate vulnerability [17]	2015-3825
	DVM & ART	DoS via an unspecified Dalvik function	2009-3698
	AOSP services Janus: Hiding Payload & Bypass signatures 2017-13156
	Kernel	Towelroot: Futex Requeue Kernel Exploit	2014-3153
	labs can be used directly on real smartphones, enhancing the con-
	fidence of the students in their skills. Each lab intends to develop
	skills of protection against one type of threat. The fundamentals of
	Android security are introduced in different labs, such as those on
	the use of permissions or cryptographic API. Advanced threats and
	prevention mechanisms, such as buffer overflows or obfuscation,
	are discussed in a lab entitled "Secure Mobile App Development,"
	which was under development at the time of the article writing.

Table 2 :

 2 Proposed security activities in Bloom taxonomy of cognitive process structure[START_REF] David R Krathwohl | A Revision of Bloom's Taxonomy: An Overview[END_REF]

	a a components Cognitive a a a a a Soft. process	Remember	Understand	Apply	Analyze	Eval. Create
	Applications	DEV	MAL malware reverse
	AOSP classes	app development	BANK banking app reverse	COV	CLASS
	DVM & ART			covert channels	vulnerable class loader PACK	PROJ
		INST			reverse packers
	AOSP internals	compile, flash		MEM	KERN
	Kernel			memory forensic	ROP programming

Table 3 :

 3 Knowledge chapters for the DEV lab

	Chapter 1
	Application's architecture

Table 4 :

 4 Evaluation of progress (δ ) and average mark after labs (m) for each type of lab

		Attended lab:	DEV		INST	MAL	MEM	COV	CLASS
		Nb of students:	n = 27	n = 7	n = 28	n = 3	n = 11	n = 11
	Questions	Scoring	δ	m	δ	m	δ	m	δ	mark	δ	m	δ	m
	Are you able to develop an Android application that	DEV	+1.74 3.67	+0.14	2.14	+0.75	2.64	+0.00	1.67	+0.18	2.36	+1.36	2.73
	interacts with an HTTP server?
	Are you able to compile and/or flash an Android	INST	+0.93	2.59	+2.57 4.14	+0.82	2.71	+0.00	1.00	+0.18	2.09	+0.55	1.91
	distribution (e.g. AOSP)?
	Are you able to reverse Android malware?	MAL	+0.56	1.74	+1.29	2.29	+1.46 2.96	+0.00	1.00	+0.18	1.82	+0.55	1.73
	Are you able to perform a forensic analysis of a	MEM	+0.56	1.78	+0.86	1.86	+0.86	2.11	+2.00	3.00	+0.00	1.55	+0.18	1.27
	dump of volatile Android memory?
	Are you able to develop a covert channel to hide	COV	+0.52	1.74	+0.00	1.00	+1.00	2.14	+0.00	1.00	+2.45 3.82	+0.36	1.55
	communication between two Android applications?
	Are you able to comprehend how a vulnerable class	CLASS	+0.44	1.59	+0.29	1.43	+0.96	2.21	+0.33	1.33	+0.09	1.64	+0.91 2.27
	loader can be exploited and propose some patch?
			1 = Unknown -2 = Discovering -3 = Intermediate -4 = Good knowledge -5 = Advanced

https://bytecodeviewer.com

https://github.com/skylot/jadx

Ngrog is a tunneling service from a public URL to a local server: https://ngrok.com

http://sable.github.io/soot/

https://github.com/swdunlop/AndBug

https://portswigger.net/burp

https://github.com/504ensicsLabs/LiME

https://www.volatilityfoundation.org/

https://www.hex-rays.com/products/ida/

https://github.com/JonathanSalwan/ROPgadget

This work has received a French government support granted to the COMIN Labs excellence laboratory and managed by the National Research Agency in the "Investing for the Future" program under reference ANR-10-LABX-07-01.