Covert Association of Applications on Edge Devices by Processor Workload

In this scenario, the two apps $x$ and $y$ are native apps running on top of a mobile OS. The transmitter app $x$ modulates its installation ID by affecting the processor workload. The receiver app $y$ detects and demodulates the installation ID by monitoring the processor workload. In Section IV, we will implement this scenario based on the Android OS. We will elaborate the detailed constraints imposed by the Android OS for the receiver $y$ to access the processor workload and our approach to overcome the constraints.

In this scenario, a JavaScript-instrumented web page running in a web browser on top of a mobile OS is the transmitter $x$ and a native app running in the mobile OS is the receiver $y$. The web session ID of $x$ can be generated by the remote web server dynamically when the web browser requests the web page. Section IV will present the technical details of using JavaScript to affect the processor workload and modulate the web session ID. The web browser can be a Tor browser [8] that integrates the Tor for anonymous communications over an overlay network and various modifications for enhanced anonymity. The user wishes to achieve guaranteed anonymity by using the Tor browser. Unfortunately, if the user is not anonymous to $y$, through the covert device association, the anonymity protection provided by the Tor browser will be breached since the colluding vendors that provide the JavaScript-instrumented web page and the app $y$, respectively, can associate the user’s identity (e.g., e-mail address) provided to $y$ with the anonymous web session $x$ or the user’s pseudonym provided to $x$.

We extend the first scenario to address the case with two native apps running in an edge OS. We envisage that indoor appliances will increasingly adopt edge OSes that can run multiple apps concurrently. Many smart appliances have adopted customized Android OSes, such as TVs, fridges, and washers. The recently released Android Things [13] is a lightweight edge OS that caters better into low-power and resource-constrained edge devices. The prototype implementation of the covert device association on Android Things will suggest the credibility of the attack on a wide spectrum of edge devices.

Unipolar non-return-to-zero (NRZ) line code is used to encode the app installation ID. For modulation, we consider the amplitude-shift keying (ASK) and the frequency-shift keying (FSK), which are two basic band-pass modulation schemes widely used in digital communication systems. We will compare the performance of the ASK-based and FSK-based covert communications via extensive evaluation, in the presence of interfering compute tasks. We do not use the phase-shift keying (PSK) because it is hard to control the phase of the carrier (i.e., the processor workload) in the presence of interfering workload.

Fig. 2 illustrates the ideal processor workload waveforms of ASK and FSK. Under ASK, a high processor workload represents binary 1, whereas a low processor workload represents binary 0. The two binaries use the identical bit duration that is denoted by $T$ in seconds. Our evaluation will vary the bit duration to achieve various data rates in bit per second (bps) and assess the resulted bit error rates (BERs).

Under FSK, the two binaries also use the identical bit duration $T$. The processor workload following a square wave with a period of $T$ seconds represents binary 0, whereas that following a square wave with a period of $\frac{T}{5}$ seconds represents binary 1. Thus, the carrier frequency for binary 1 is five times of the carrier frequency for binary 0. The frequencies are chosen to achieve well separation of the two states.

The receiver samples the processor workload to demodulate the signal. From the Nyquist sampling theorem, the sampling rate should be at least twice of the highest frequency of the carrier. We adopt an overprovisioned sampling rate of four times of the highest frequency of the carrier. Therefore, the sampling rates for the ASK and FSK schemes are $\frac{4}{T}\,\text{Hz}$ and $\frac{20}{T}\,\text{Hz}$, respectively.

Note that as the transmitter and the receiver are synchronized by the scheduled rendezvous mechanism, the demodulation can be coherent.

We use threshold-based bit detection. Specifically, for ASK, if 75% of the sampled data points are higher than a detection threshold, the bit is detected as 1; otherwise, it is detected as 0. We use the average of the full processor workload and the baseline processor workload before the transmission of the installation ID as the detection threshold.

For FSK, we first perform the fast Fourier transform (FFT) on the sampled data over the current bit duration to generate the power spectrum density (PSD). If the peak value of the PSD occurs at a frequency higher than $\frac{3}{T}\,\text{Hz}$, the bit is detected as 1; otherwise, it is detected as 0. Note that the used frequency threshold of $\frac{3}{T}\,\text{Hz}$ is the mid point between the two carrier frequencies of $\frac{1}{T}\,\text{Hz}$ and $\frac{5}{T}\,\text{Hz}$ respectively representing binary 0 and 1.

The synthetic file “/proc/stat” of the Android OS and Android Things provides the accumulated and aggregated core and processor times in the unit of ten milliseconds spent for different types of processes (i.e., user, system, and idle times, etc). Thus, by reading this file twice at the start and end of a time duration, we can compute the percentage of the processor time spent for the user apps. This percentage is referred to the time load of the processor. Note that the Android or Android Things apps can also invoke the “top” utility to obtain the processor times. In fact, the “top” utility also relies on the information contained in “/proc/stat”. Reading “/proc/stat” suffices for sensing time load.

Most modern processors feature DVFS that allows the processor clock rate to vary according to the real-time compute load and/or the configurations specified via Android’s CPU governor. DVFS is critical to extend the battery lifetime of battery-based edge devices such as smartphones. Due to DVFS, the processor clock rate is an indicator of the processor workload. Although DVFS may have time delays in reacting to the variations of processor workload, the delay will not affect the information bit demodulation if the bit duration is long enough.

The maximum, minimum, and real-time processor clock rates can be obtained by reading the files with a prefix “scaling_” in the “/sys/devices/system/cpu/cpu$i$/cpufreq” directory, where the $i$ represents the index of the core. The user app can read these files without any privileged permissions. For a device with $n$ cores, the frequency load is computed as:

Note that in this paper, we do not consider hyperthreading that virtualizes a physical core into multiple virtual cores, since this technique is not widely adopted for edge processors.

For processor workload control, to achieve a high workload level used by ASK or FSK, the transmitter app creates $n-2$ threads (where $n$ is the number of cores) and uses repeated matrix multiplications in each thread to increase the workload as much as possible until the high workload level should end. The rationale of using $n-2$ cycle-exhausting threads is as follows. As the Linux kernel tends to assign the threads evenly to the processor cores, our approach will most likely leave two cores not assigned with the cycle-exhausting threads. Thus, these two remaining cores can handle other compute tasks and retain the responsiveness of the OS to the user’s input. Otherwise, the other compute tasks may severely interfere with the modulation/demodulation processes; the deteriorated system responsiveness to user’s inputs can also reduce the stealthiness of the attack. Note that an Android app can obtain the value of $n$ by using the API java.lang.Runtime.availableProcessors().

For processor workload sensing, with Android prior to version 8.0, the synthetic file “/proc/stat” can be read by user apps without requiring any privileged permissions. Thus, the time load-based demodulation can be implemented. However, with Android version 8.0 and newer, the SELinux configuration does not allow the user apps to access the synthetic file. Thus, only the frequency load-based demodulation can be implemented in Android 8.0 and newer.

Fig. 3 shows the sensed workload traces under various combinations of modulation methods and processor workload metrics on Phone-A. During the transmissions, a movie is played to create interference. Although the waveforms are different from the ideal waveforms, all the shown waveforms can be correctly demodulated. From Fig. 3, we can also see that the frequency load traces are less noisy than the time load traces, due to the discrete nature of the frequency load.

We use a JavaScript program that runs in a web browser in the Android OS to control the processor workload, while a native Android app as described in Section IV-C1 senses and demodulates the processor workload. JavaScript was originally designed as a single-threaded scripting language. The latest JavaScript can use the Web Worker API of HTML5 to implement multi-threaded concurrency. By using Web Worker, we implement the modulation approach described in Section IV-C1 by exhausting $n-2$ cores. Note that JavaScript can obtain the value of $n$ by accessing the read-only property navigator.hardwareConcurrency.

We also investigate whether the covert device association threat is valid against the Tor browser [8]. Only the following two features of the Tor browser affect our design. First, to preserve the user’s location privacy, the Tor browser provides Coordinated Universal Time (UTC) only. Thus, the scheduled rendezvous cannot be based on the local time and cannot exploit the night time to increase the stealthiness of the attack. Nevertheless, as the Tor browser unlikely runs in the background unattended for long periods of time (e.g., days) due to the mobile user’s heightened caution in using anonymous communications, the opportunities for exploiting unattended times for attack stealthiness are limited. From our evaluation results in Section V, although the user activities may degrade the performance of the covert device association, the transmissions are still successful when the data rate is low. Thus, this restriction of the Tor browser does not invalidate the covert device association threat.

Second, as recent studies [28, 29, 30] show that the attackers can leverage the 1-millisecond accurate timer of JavaScript to de-anonymize the Tor browser, the Tor browser has reduced the JavaScript timer’s resolution to 100 or 250 milliseconds [31]. As the processor workload modulation requires the JavaScript timer, the reduced timer resolution may lead to data rate reduction of the covert communications. However, from our evaluation results in Section V, the main bottleneck in modulation is the response delay of processor workload to the JavaScript program, rather than the reduced timer resolution. Fig. 4 shows the sensed workload traces when an Android app and a web page in Tor browser running on Phone-A perform covert communications. A vertical dash line represents the boundary between two bit periods. We can see that, under ASK, there is a time delay of up to 0.5 seconds from when the JavaScript intends to reduce the workload to when the workload starts dropping. This is the aforementioned main limiting factor for JavaScript to achieve high data rate.

Our implementations for two Android 8.0 can be easily ported to Android Things 1.0. Oriented to embedded edge devices, the Android Things 1.0 does not prevent the user apps from accessing the synthetic files storing run-time processor time and frequency information as mentioned in Section IV-B. Therefore, the receiver app can implement the demodulation methods based on either time workload or frequency workload. However, we find that the RPi’s processor mostly operates at its maximum clock rate of 1.2GHz among its two available clock rates of 600MHz and 1.2GHz, even when it is idle. This is because the RPi design is not optimized for power conservation, rendering the frequency load-based modulation/demodulation ineffective. Differently, the battery-based smartphones actively scale down the clock rate to save battery energy when the processor is idle or less busy. Thus, in this paper, we only evaluate the time load-based scheme for this attack scenario. Fig. 5 shows the sensed time load traces when the two Android Things apps communicate. During the transmissions, the RPi compresses a 300MB data file to introduce interference. Both ASK and FSK work satisfactorily.

We conduct experiments using Phone-A. Fig. 6 shows the BER versus data rate under various settings. We have the following three general observations. First, the BER increases with the data rate. Second, in the presence of interfering computation, the BER-versus-data rate curves become higher, because the interference causes bit errors. Third, compared with ASK, FSK achieves much lower data rates, because FSK uses multiple workload cycles to represent a bit. In addition, we have the following observation when we compare the subfigures of Fig. 6. The gaps between the two curves in Fig. 6(a) and Fig. 6(d) are larger than those in Fig. 6(b) and Fig. 6(c). This suggests that the demodulation methods based on the combinations of $\langle\text{time load},\text{FSK}\rangle$ and $\langle\text{frequency load},\text{ASK}\rangle$ are more resilient to interference than those based on $\langle\text{time load},\text{ASK}\rangle$ and $\langle\text{frequency load},\text{FSK}\rangle$.

Then, we investigate the heat generation during the covert transmission process, since overheating may cause the mobile user’s suspicion and investigation. In our experiments, we record the smartphone’s battery temperature that can characterize the overall heat generation status of the smartphone. During the experiments, the phone’s battery temperatures are around 35°C only, lower than the human body temperature. Therefore, the covert transmission does not lead to salient overheating.

Lastly, we conduct experiments using Phone-B. A key difference between Phone-A and Phone-B is that Phone-B is equipped with two processors (i.e., ARM’s big.LITTLE architecture). The phone can dynamically switch between the two processors depending on the real-time compute workload. This introduces challenges to maintaining the processor workload for modulation purpose. In addition, as Phone-B runs Android 8.0, it cannot measure the time load due to the OS’ restriction as discussed in Section IV-C1. Fig. 7 shows the experiment results on Phone-B, where the frequency load is used as the processor workload metric. By comparing the results with those shown in Figs. 6(c) and 6(d) for Phone-A, the covert transmissions on Phone-B in general have higher BERs for the same data rates. This degradation of covert communication performance is due to the extra uncertainty introduced by the dynamic switching between the two processors. Nevertheless, as long as the data rate is no greater than $0.25\,\text{bps}$, the empirical BERs measured under the various settings are zero.

We evaluate the implementation presented in Section IV-C2 using both the Google Chrome and the Tor browser on Phone-A. As shown in Section IV-C2, the processor workload has delays in responding to the JavaScript program’s intent to change the processor’s workload. This can be caused by the browser’s design for controlling the JavaScript engine’s use of compute resources. As such, when the bit duration is too short, the modulation cannot be performed correctly. Table I shows the maximum achievable data rates with zero empirical BER in the absence and presence of interference. When the data rates are higher than the values shown in Table I, the modulation cannot be performed correctly. Moreover, the results shown in Table I for the Google Chrome and the Tor browser are similar. The results obtained in the absence and presence of interference are also similar. These results suggest that the bottleneck preventing from achieving higher data rates is the processor workload’s delay in responding to the JavaScript program, rather than the Tor browser’s reduced timer resolution and the impact of interference.

We evaluate our implementation for two Android Things 1.0 apps running on the RPi. As discussed in Section IV-C3, RPi’s limited frequency scales and inactive DVFS render the frequency load an ineffective processor workload metric. Thus, we only evaluate the time load-based covert transmissions. Fig. 8 shows the results. We can see that, in both subfigures, the gap between the two curves corresponding to the presence and absence of interference is small. This suggests that the covert transmissions are resilient to the interference.

From the benchmark results obtained on the three edge devices, the covert transmission via processor workload can achieve a data rate of at least $0.25\,\text{bps}$ with zero empirical BER under the three attack scenarios, without requiring any privileged permissions. If the app installation ID is represented using six bytes, the covert device association can be completed within $6\times 8/0.25\,\text{seconds}=3.2\,\text{minutes}$.