%!TeX program=pdflatex
%!TeX encoding=utf8
%!TeX spellcheck = en_US
%!TeX root = ../../messageVortex.tex



% ********************************************************************************************************
% *** Intro
% ********************************************************************************************************
\partepigraph{The most effective way to do it is TO DO IT}{Amelia Earhart}
\part{Introduction}
\chapter{Preface}
Almon Brown Strowger was the owner of a funeral parlor in St. Petersburg. He filed a patent on March \nth{10}, 1891 for an ``Automatic Telephone Exchange''~\cite{pulseDialingPatent} which built the basis for modern automated telephone systems. According to several sources, he was annoyed that the local telephone operator was married to another undertaker. She diverted potential customers of Mr. Strowger to her husband instead, which caused Almon B. Strowger to lose business. In 1922, this telephone dialing system, now called pulse dialing, became the standard dialing technology for more than 70 years until it was replaced by tone dialing.

This dialing technology was the basis for automatic messaging of voice and text messages (e.g., telex) and is the foundation for current routed networks. These networks established our communication-based society and allow us to quickly connect with any person or company we wish. However, computers do not only allow to route at high speed and throughput. They also allow the collection and analysis of data. Today, we use these networks as communication means for all purposes, and most people spend minimal thought on the possible consequences, should the wrong person get their hands on this communication. 

Information data miners may use this collected data to judge our intentions, which are confidential if we have something to hide. This problem has dramatically increased in the last years as large companies and countries started to collect all sorts of data and created the means to process them. It supposedly allows judging people not only on what they are doing but also on what they already have done in the past and what they might do in the future. Past and present, numerous events show that actors, some state-sponsored, collected data on a broad basis within the Internet. Whether this is a problem or not is a disputable fact. However, undisputed is that such data requires careful handling, and accusations should then be based on solid facts. While people may classify personalized advertising as a legitimate use of data, a general classification of citizens is broadly considered unacceptable~\cite{NCR2013,XKeyscore,Ball2013,Greenberg2013,Leuenberger1989}.

To show that this may occur even in democracies, we refer to events such as the ``secret files scandal'' (or  ``Fichenskandal'') in Switzerland. From 1900 to 1990 the Swiss government collected 900’000 files in a secret archive (covering more than 10\% of the natural and juristic entities within Switzerland at that time). The Swiss Federal Archives have documented this event in depth~\cite{Leuenberger1989}.

In 2009, whistleblower Edward Snowden leaked a vast amount of documents which suggest that such attacks on privacy common on a global scale. The documents claim that a data collection was going to be initiated in 2010. Since these documents are not publicly available, it is difficult to prove the claims based on these documents. However, a significant number of journalists from multiple countries screened these documents and claimed that the information seemed credible. According to these documents (verified by \href{http://www.nrc.nl/nieuws/2013/11/23/nederland-sinds-1946-doelwit-van-nsa}{NRC}), the NSA infiltrated more than 50K computers with malware to collect classified or personal information. They furthermore infiltrated telecom operators (mainly executed by British GCHQ) such as Belgacom to collect data and targeted high members of governments even in associated states (such as the mobile phone number of Germany's chancellor)~\cite{NCR2013,XKeyscore,Ball2013,Ackerman2013,Greenberg2013}. A later published shortened list of ``selectors'' in Germany showed 68 telephone and fax numbers targeting the German government's economy, finance, and agricultural departments. A global survey done by the freedom house~\cite{FOTN2020} claims a decrease in Internet freedom for the $\text{11}^{th}$ year in a row.

This list of events shows that big players collect and store vast amounts of data for analysis or possible future use. The list of events also shows that the use of such data was at least partially questionable. This work analyzes the possibility of using state-of-the-art technology to minimize a person's information footprint on the Internet. 

When looking at e-voting~\cite{haenni2008research} compared to traditional secret voting systems, anonymity becomes crucial as the observation of voting behavior becomes an immediate threat for each identifiable voter for an opponent, as they may fear subsequent repression.

We leave a large information footprint in our daily communication. In a regular email, we disclose everything in a ``postcard'' to any entity on its way. Even when encrypting a message perfectly with today's technology (S/MIME~\cite{rfc2045} or PGP~\cite{rfc2015}), it still leaves at least the originating and the receiving entity disclosed, or we rely on the promises of a third-party provider that offers a proprietary solution. Even in those cases, we leak information such as ``message subject'', ``frequency of exchanged messages'', ``size of messages'', or ``client being used''. A suitable anonymity protocol must cover more than the sent message itself. In addition to the message itself, it includes all metadata and all traffic flows. Furthermore, a protocol to anonymize messages should not rely on trusting infrastructure other than infrastructure under the sending or receiving entity's control. Trust in any third party might be misleading in terms of security or privacy.

Furthermore, central infrastructure is bound to be of particular interest to anyone gathering data. Such control by an adversary would allow manipulating the system, the data or the data flow. Thus, avoiding a central infrastructure is valid for minimizing the information footprint available to a single entity.

Leaving no information trail when sending information from one person to another is difficult to achieve. Most messaging systems disclose at least the peer partners when posting messages. Metadata such as starting and endpoints, frequency, or message size are leaked in all standard protocols even when encrypting messages.

Allowing an entity to collect data may affect senders and recipients of any information. The collection of vast amounts of data allows a potent adversary to build a profile of a person. With the dawn of the Internet, the availability of information has risen to an unknown extent.

An entity in possession of such profiles may use them for many purposes. These include service adoption, directed advertising, or the classification of citizens. The examples given above show that this data's effects are not limited to the Internet but can also reach us in the real world.

The main problem with this data is that it may be collected over a considerable amount of time and evaluated at any time. It could even occur that standard practices at one time are judged differently at a later time. Governments, companies, or people could then judge others retrospectively on these types of practices. This questionable type of judgment is visible in the tax avoidance discussion~\cite{Amat1999}. 

People with a ``bad'', ``unsuitable'', or ``non-conformant'' information footprint may be subject to banning, repression, or information access exclusion. People must be able to control their own data footprint. Not providing those means allows any country or a more prominent player to effectively ban and control any number of persons within or outside the Internet. 

\section{Our Approach}
Our approach in this work is to provide a new form of communication for such environments. Messages should be exchangeable without the knowledge of anyone including any observer on a governmental or ISP level. This unobservability must not only cover any message but all associated metadata as well. The infrastructure needed for this means of communication must be standard, off-the-shelf and unsuspicious. Communication should be secure without any or minimal trust in the infrastructure routing the messages.

The primary goal is to enable freedom of speech, as defined in Article 19 of the International Covenant on Civil and Political Rights (ICCPR)~\cite{iccpr}.
\begin{shadequote}{}
		everyone shall have the right to hold opinions without interference 
\end{shadequote}
and
\begin{shadequote}{}
	Everyone shall have the right to freedom of expression; this right shall include freedom to seek, receive and impart information and ideas of all kinds, regardless of frontiers, either orally, in writing or print, in the form of art, or through any other media of his choice.
\end{shadequote}

We imply that not all participants on the Internet share this value. As of March \nth{23}, 2021, Countries such as China (signatory), Cuba (signatory), Qatar (signatory), Saudi Arabia, Singapore, United Arab Emirates, or Myanmar have yet to ratify the ICCPR. Other countries such as the United States or Russia either put local laws in place superseding the ICCPR or made reservations rendering parts ineffective. Therefore, we may safely assume that freedom of speech is not given on the Internet.

If we transfer the right of free speech in the world of networks, then uncensored network packet flow is the equivalent in the networking world. Network packets may pass through any point in the world. A sender has no control over it. This lack of control occurs because every routing device decides on its own for the next hop. This decision may be based on static rules or influenced by third-party nodes or circumstances (e.g., BGB, RIP, OSPF\ldots). It is furthermore not possible to detect which way a packet has taken. The standard network diagnostic tool \verb|tracert| respectively \verb|traceroute| returns a potential list of hops. This list is only correct under certain circumstances (e.g., a stable route for multiple packets or the same routing decisions regardless of other properties than the source and destination address). Any output of these tools may, therefore, not be taken as a log of routing decisions. There is no possibility in standard IP routed networks to foresee a route for a packet, nor can it be measured, recorded, or predicted before, during, or after sending. 

As an example of the problems analyzing a packet route, we look at \verb|traceroute|. According to the man page of traceroute, \verb|traceroute| uses UDP, TCP, or ICMP packets with a short TTL and analyzes the IP of the peer sending a TIME\_EXCEEDED (message of the ICMP protocol). This information is then collected and shown as a route. This route may be completely false. The man page describes some of the possible causes.

We cannot state that data packets we are sending pass only through countries accepting the ICCPR to the full extent, nor can we craft packages following such a rule.

\begin{figure}[H]
	\begin{lstlisting}[language=bash,breaklines=true,basicstyle=\tiny]
		$ traceroute www.ietf.org
		traceroute to www.ietf.org.cdn.cloudflare-dnssec.net (104.20.0.85), 64 hops max
		1   147.86.8.253  0.418ms  0.593ms  0.421ms
		2   10.19.0.253  1.177ms  0.829ms  0.782ms
		3   10.19.0.253  0.620ms  0.427ms  0.402ms
		4   193.73.125.35  1.121ms  0.828ms  0.905ms
		5   193.73.125.81  2.991ms  2.450ms  2.414ms
		6   193.73.125.81  2.264ms  1.961ms  1.959ms
		7   192.43.192.196  6.472ms  199.543ms  201.152ms
		8   130.59.37.105  3.465ms  3.138ms  3.121ms
		9   130.59.36.34  3.904ms  3.897ms  4.989ms
		10   130.59.38.110  3.625ms  3.333ms  3.379ms
		11   130.59.36.93  7.518ms  7.232ms  7.246ms
		12   130.59.38.82  7.155ms  17.166ms  7.034ms
		13   80.249.211.140  22.749ms  22.415ms  22.467ms
		14   104.20.0.85  22.398ms  22.222ms  22.146ms
		$
	\end{lstlisting}
	\caption{A traceroute to the host www.ietf.org.}
\end{figure}

To enable freedom of speech, we need a means of transport for messages which keep sender and recipient anonymous to an adversary.

We feel that this work is needed, as much work in the anonymity field is focused on the aspect of ``how to achieve anonymity'' and analyzing it against the means of an adversary, which is simple and technocratically based. In this work, we define an adversary who observes or disrupts communication, but may also suppress the use of technology. Therefore, the focus is not only to create a protocol for anonymity but to create a protocol that is undetectable.

\chapter{Our Contribution}
This thesis contributes to anonymization with an asynchronous messaging protocol called \MessageVortex.

The protocol employs a new type of \hilight{programmable forwarders} called \VortexNodes{} (nodes) with a novel way of message mixing, moving away from a strictly chunked and onionized system to one, where routing operations allow an increase or decrease in size without differentiating between decoy traffic and message routing. We refer to the \hilight{instructions} required to process a node as ``routing blocks''. These \hilight{routing blocks} have an onionized structure, only exposing the required information for the current node. Routing blocks may travel with a message or join the message at any common \VortexNode.

Our protocol differentiates from other protocols by the fact that mixing and routing messages does not rely on knowingly injected decoy traffic and that we are capable of piggybacking multiple other carrier protocols without modifying the required, already available infrastructure on the Internet or requiring a dedicated infrastructure. The carrier protocols may even be switched during routing, making it even more difficult to observe message traffic. 

For non-traceable routing, we introduce a novel type of routing operation called ``add\-Redundancy''. This operation is a \hilight{Reed--Solomon-calculation with encryption and a new} \hilight{type of padding}. This operation transposes the received information in a larger or smaller form than the original message by adding or removing redundancy operations. The applied padding structures the message so that any possible result of a decryption operation results in a plausible padding structure. With standard paddings, decoy operations on traffic would possibly be identifiable as the resulting padding structure may be invalid leaking information. After applying these operations, the routing node sends this transposed information to subsequent peers without any knowledge of what parts of the sent messages are relevant for the successful message delivery. Therefore, applying such operations makes it impossible for any node to differentiate between \hilight{decoy traffic} and real message traffic. Furthermore, tagging beyond peering nodes is not possible, as building relations between non-neighboring nodes' messages is not possible.

An outside observer cannot identify messages, as they do not use a proprietary communication protocol but hide within other standard Internet protocols. We \hilight{blend} these transport protocols without modifying the servers used for message transport. This property makes the protocol very robust as server administrators' prosecution is not sensible if traffic is running over their infrastructures. 

As the structure of routing blocks does not expose the encryption keys required to build routing blocks for a peering node, a malicious node may only discover other possible peer partners when routing traffic without gaining the capability of talking to them. Other properties, such as routed traffic, message size, message content, communication partners, or intensity of communication remain hidden. External global observers are unable to differentiate between regular protocol traffic and Vortex traffic. Assuming an observer can identify the steganographically hidden information, he may apply censorship but remains unable to trace messages according to external attributes, even assuming that he has additional information from collaborating nodes within the message path.

This protocol can even withstand a censoring adversary on a regional or super-regional scale, as our protocol hides in common protocols and remains undetectable. As the creator of a routing block fully controls anonymity, we achieve either sender or receiver anonymity. The protocol is built with crypto-agility and thus is able to adapt to the anonymity needs of its user.

Our protocol was \hilight{implemented in Java}, is publicly available under \href{https://messagevortex.net/}, and runs on RaspberryPI Zero W computers as a proof of concept, showing that weak nodes may participate in such a network. In addition to the scientific aspects of the protocol, we shed light on many \hilight{operational aspects} relevant for a real-world usage of the protocol and added these findings to the work.

\chapter{Scope and Aproach}
The main topic of this thesis was defined as follows:

\begin{itemize}
	\item Is it possible to have a messaging protocol used on the Internet, based on ``state of the science'' technologies offering a high degree of unlinkability (sender and receiver anonymity) towards an adversary with a high budget and privileged access to the Internet infrastructure?
\end{itemize}

Based on this central question, there are several sub-questions grouped around various topics:

\begin{enumerate}
	\item What technologies and methods may be used to provide sender and receiver anonymity and unlinkability when sending messages against a potential censoring or observing adversary? 
	
	This question covers the principal part of the work. We first collect relevant concepts, systems and technologies in \cref{sec:concepts} and \ref{sec:systems}. We then elaborate on a list of criteria for the \MessageVortex{} protocol in \cref{sec:genRequirements}. In \cref{sec:coreMVProtocol}, we then create a list of suitable technologies and methods and explain our choice in \cref{sec:rationale}. Based on these findings, we define a protocol combining these technologies and researches into a solution in \cref{sec:protocol}. The implementation of this solution is explained in \cref{sec:implementation} and then in \cref{sec:analysis} analyzed for suitability based on the criteria specified. 
	
	\item How can entities utilizing \MessageVortex{} be attacked, and what measures are available to circumvent such attacks? 
	
	Within this question, we look at various attacks and test the protocol's resistance based on the definition of the protocol in \cref{sec:coreMVProtocol}. First, we collected well-known attacks in \cref{sec:attacks}. We then elaborate if those attacks might be successful (and if so under what circumstances) in \cref{sec:staticAnalysis} and \cref{sec:dynamicAnalysis}.
	
	\item How can design mitigate attacks targeting the anonymity of a sending or receiving entity within \MessageVortex? 
	
	Within this question, we define baselines to mitigate attacks by identifying guidelines for using the protocol in \cref{sec:operation}. We analyze the guidelines' effectiveness and elaborate on the general achievement level of the protocol by referring to the criteria defined in SQ1. 
	
\end{enumerate}

\chapter{Notation}

\section{Cryptography \label{sec:encNot}}
The theory in this document is heavily based on symmetric encryption, asymmetric encryption and hashing. As a uniformed notation we use $E^{K_a}(M)$ (where $a$ is an index to distinguish multiple keys) resulting in $\mathbf{M^{K_a}}$ as the encrypted message. If reflecting a tuple of information, it is written in boldface. To express the content of the tuple, angular brackets $\splitatcommas{\mathbf{L\langle normalAddress,vortexAddress\rangle }}$ are used. If we want messages encrypted with multiple keys, we list the used keys as a comma-separated list in superscript $E^{K_b}\left(E^{K_a}\left(M\right)\right)=M^{{K_{a}},{K_b}}$.

For a symmetric encryption of a message $\mathbf{M}$ with a key $K_a$ resulting in $\mathbf{M^{K_a}}$ where $a$ is an index to distinguish different keys. Decryption uses $D^{K_a}(\mathbf{M^{K_a}})=\mathbf{M}$.

As notation for asymetric encryption we use $E^{K^{1}_a}(\mathbf{M})$ where $K^{-1}_a$ is the private key and $K^{1}_a$ is the public key of a key pair $K^p_a$. The asymmetric decryption is noted as $D^{K^{-1}_a}(\mathbf{M})$.

For hashing, we use $H(\mathbf{M})$ if unsalted and $H^{S_a}$ if using a salted hash with salt $S_a$. The generated hash is shown as $H_M$ if unsalted and $H^{S_a}_M$ if salted.

If we want to express what details are contained in a tuple we use the notation $\mathbf{M\langle t,MURB,serial\rangle }$ respectively if encrypted $\mathbf{M^{K_{a}}\langle t,MURB,serial\rangle}$.

\begin{align*}
	\text{Asymmetric:}         & E^{K^{-1}_a}\left(\mathbf{M}\right)                            && =\mathbf{M}^{K^{-1}_a}\\
	& D^{K^{1}_a}\left(E^{K^{-1}_a}\left(\mathbf{M}\right)\right)    && =\mathbf{M}\\
	& D^{K^{-1}_a}\left(E^{K^{1}_a}\left(\mathbf{M}\right)\right)    && =\mathbf{M}\\
	\text{Symmetric:}          & E^{K_a}\left(\mathbf{M}\right)                                 && =\mathbf{M}^{K_a}\\
	& D^{K_a}\left(E^{K_a}\left(\mathbf{M}\right)\right)          && =\mathbf{M}\\
	\text{hashing (unsalted):}& H\left(\mathbf{M}\right)                                       && =\mathbf{H}_M\\
	\text{hashing (salted):}  & H^{S_a}\left(\mathbf{M}\right)                                 && =\mathbf{H}^{S_a}_M
\end{align*}

In general, subscripts denote selectors to differentiate the same type's values, and superscript denotes relevant parameters to operations expressed. The subscripted and superscripted pieces of information are omitted if not needed.

We refer to the components of a \VortexMessage{} as follows:
\begin{align*}
	\text{Prefix component:}         & \mathbf{PREFIX}                 &=D^{K^{1}_a}\left(\mathbf{P}^{K^{-1}_a}\right) &=D\left(\mathbf{P}\right)\\
	\text{Header component:}         & \mathbf{HEAD}                   &=D^{K^{1}_a}\left(\mathbf{H}^{K^{-1}_a}\right) &=D\left(\mathbf{H}\right)\\
	\text{Route component:}         & \mathbf{ROUTING}                 &=D^{K^{1}_a}\left(\mathbf{R}^{K^{-1}_a}\right) &=D\left(\mathbf{R}\right)\\
\end{align*}

In general, a decrypted block is written as a capitalized multi-character boldface sequence. An encrypted block is expressed as a capitalized, single character, boldface letter.

\section{Code and Commands}
We write code blocks as a light grey block with line numbers:

\begin{lstlisting}
	public class Hello {
		public static void main(String args[]) {
			System.println("Hello. "+args[1]);
		}
	}
\end{lstlisting}

Commands entered at the command line are in a grey box with a top and bottom line. Whenever root rights are required, the command line is prefixed with a ``\#''. Commands not requiring specific rights are prefixed with a ``\$''. Lines without a trailing ``\$'' or ``\#'' are output lines of the previous command. If long lines are split to fit, a ``$\hookleftarrow$'' is inserted to indicate that the system inserted a line break for readability.

\begin{lstlisting}[language=bash]
	# su -
	# javac Hello.java 
	# exit
	$ java Hello
	Hello.
	$ java Hello "This is a very long command-line that had to be broken to fit into the code box displayed on this page."
	Hello. This is a very long command-line that had to be broken to fit into the code box displayed on this page.
\end{lstlisting}

\section{Hyperlinking}
The electronic version of this document is hyperlinked. Readers may click references to the glossary or the literature to find the respective entry. Chapter or table references are clickable as well. 


