Privacy Assessment Using Static Taint Analysis (Tool Paper)

Abstract

When developing and maintaining distributed systems, auditing privacy properties gains more and more relevance. Nevertheless, this task is lacking support of automated tools and, hence, is mostly carried out manually. We present a formal approach which enables auditors to model the flow of critical data in order to shed new light on a system and to automatically verify given privacy constraints. The formalization is incorporated into a larger policy analysis and verification framework and overall soundness is proven with Isabelle/HOL. Using this solution, it becomes possible to automatically compute architectures which follow specified privacy conditions or to input an existing architecture for verification. Our tool is evaluated in two real-world case studies, where we uncover and fix previously unknown violations of privacy.

This work has been supported by the German Federal Ministry of Education and Research, project DecADe, grant 16KIS0538.

A Case Studies

The main idea and usage of our model was already motivated by the fictional example of Fig. 1. In this appendix, we present details on two real-world case studies where we evaluate and audit two distributed systems for data collection which are deployed at the Technical University of Munich. For the sake of brevity, we only present the most interesting aspects. We will write node labels as $X \text {---} Y$, where X corresponds to the tainted labels and Y corresponds to the untainted labels. For example, $t\ Anonymizer = \lbrace \mathsf {energy}\rbrace \text {---} \lbrace \mathsf {location} \rbrace$.

1.1 A.1 Energy Monitoring System

Energy monitoring systems (EMS) have severe privacy implications: If installed in an office, such a system for example allows to draw conclusions about the effective working periods and behavior of employees by measuring the devices they use. EMS consist of at least two components: A logging unit which records energy usage locally and a server which stores and processes all recorded data. Considering privacy, storing all collected data in a single, possibly external place without fine-grained access control on the data level is critical.

We examined how to improve privacy of the data before persisting it [14]: Since the logger is an off-the-shelf component which we cannot modify, we suggest to add an additional component, called $P4S$, directly after the logger. This component separates the data by different owners, recipients, or some given predicate and applies further protection measures. The separated data can then be forwarded to (possibly different) cloud services. For the sake of brevity, we do not discuss this service, key management, and how cloud services could collaborate. Our proposed architecture is shown in Fig. 2. We modeled four different kinds of privacy-related data the logger captures by the taint labels $\mathsf {A}$, $\mathsf {B}$, $\mathsf {C}$, and $\mathsf {D}$.

As input to our tool, we provided the set of components including taint labels and system boundaries as architectural constraints. The results are as follows: Our model shows that data flow from the $Logger$ to $P4S$ (which crosses a system boundary physically over the network) is highly critical. For this taint label specification, topoS verified that our architecture is compliant with the security invariants. It also asserts that any attempt to interlink the different data processing pipelines within $P4S$ would be a severe privacy violation. These insights generated by topoS can be further incorporated into the architecture: The designed pipelines can be separated into individual, isolated, stateless containers within $P4S$ that can be instantiated on demand for each different taint label. In summary, our extended topoS allowed us to formally assess privacy properties of our proposed architecture before we invested time implementing it.

Fig. 2.

Architecture of an energy monitoring system

1.2 A.2 MeasrDroid

MeasrDroid [5] is a system for collecting smartphone sensor data for research purposes. Via an app it may collect location data, information from the smartphone sensors, and networking properties such as signal strength, latency, and reliability. Ultimately, the data is stored and analyzed by a trusted machine, called $Collect Droid$. To decrease the attack surface of this machine, it is not reachable over the Internet. Instead, the smartphones push the data to a server called $Upload Droid$, which is regularly polled by $Collect Droid$ for new information. Since $Upload Droid$ is particularly exposed, a compromise of this machine must not lead to a privacy violation. Hence, it must be completely uncritical, i.e. not having any taint or untaint labels. This is achieved by having the smartphones encrypt the data for $Collect Droid$ as only recipient. Consequently, $Upload Droid$ only sees encrypted data. The model of the architecture is shown in Fig. 3. We modeled three users, each producing data with its individual tainting label $\mathsf {A}$, $\mathsf {B}$, or $\mathsf {C}$. To model encryption of some taint label $x$, we create a pair of related nodes $( Enc _\mathrm { x }, Dec _\mathrm { x })$ where the first untaints and the second taints accordingly.

Fig. 3.

MeasrDroid architecture

For this taint label specification, topoS verified that our architecture is compliant with the security invariants. In addition, given the taint label specification and adding an additional adversary node, topoS automatically computes an alternative architecture which is also compliant with the security invariants. Comparing our manually designed architecture with the topoS-generated architecture with adversary, we asserted that we did not overlook subtle information leaks. Our evaluation shows that our architecture is a subset of the topoS-generated architecture and only uncritical data can leak to an adversary. It also reveals that our architecture provides no protection against an adversary flooding $Upload Droid$ with nonsensical data. We found topoS to be a suitable tool to formally support the previous informal privacy claims about the architecture.

Auditing the Real MeasrDroid. The previous paragraphs presents a theoretical evaluation of the architecture of MeasrDroid. The question arises how the real system, which exists since 2013, compares to our theoretical evaluation. Together with the authors of MeasrDroid we evaluate the implementation regarding our previous findings: We collect all machines which are associated with MeasrDroid. We find that they do not have a firewall set up, but instead rely on the central firewall of our lab. With over 5500 rules for IPv4, this firewall may be the largest real-world, publicly available iptables firewall in the world¹ and handles many different use cases. MeasrDroid is only a tiny fragment of it, relying on the protocols http, https, and ssh. For brevity, we focus our audit port 80 (http).

Fig. 4.

MeasrDroid: Main firewall – IPv4 http connectivity matrix (Color figure online)

Fig. 5.

MeasrDroid: Main firewall – simplified connectivity matrix (Color figure online)

The model of the MeasrDroid architecture (cf. Fig. 3) should be recognizable in the rules of our firewall. In particular, $Collect Droid$ should not be reachable from the Internet while $Upload Droid$ should, and the former should be able to pull data from the latter. This information may be hidden somewhere in the firewall rule set. We used fffuu [10] to extract the access control structure of the firewall. The result is visualized in Fig. 4. This figure reflects the sheer intrinsic complexity of the access control policy enforced by the firewall. We have highlighted three entities. First, the IP range enclosed in a cloud corresponds to the IP range which is not used by our department, i.e. the Internet. The large block on the left corresponds to most internal machines which are not globally accessible. The IP address we marked in bold red belongs to $Collect Droid$. Inspecting the arrows, we have formally verified our first auditing goal: $Collect Droid$ is not directly accessible from the Internet. The other large IP block on the right belongs to machines which are globally accessible. The IP address in bold red belongs to $Upload Droid$. Therefore, we have verified our second auditing goal: $Upload Droid$ should be reachable from the Internet. In general, it is pleasant to see that the two machines are in different access groups. Finally, we see that the class of IP addresses including $Collect Droid$ can access $Upload Droid$ which proves our third auditing goal.

For the sake of example, we disregard that most machines at the bottom of Fig. 4 could attack $Collect Droid$. Under this assumption, we ignore this part of the graph and extract only the relevant and simplified parts in Fig. 5. So far, we presented only the positive audit finding. Our audit also reveals many problems, visualized with red arrows. They can be clearly recognized in Fig. 5: First, $Upload Droid$ can connect to $Collect Droid$. This is a clear violation of the architecture. We have empirically verified this highly severe problem by logging into $Upload Droid$ and connecting to $Collect Droid$. Second, most internal machines may access $Collect Droid$. Third, there are no restrictions for $Upload Droid$ with regard to outgoing connections. In theory, it should only passively retrieve data and never initiate connections by itself (disregarding system updates).

Therefore, our audit could verify some core assertions about the actual implementation. In addition, it could uncover and confirm serious bugs. These bugs were unknown prior to our audit and we could only uncover them with the help of the presented tools. Using the firewall serialization feature of topoS, we fixed the problems and reiterated our evaluation to assert that our fix is effective.