finished privacy analysis part

main.tex

@@ -177,8 +177,6 @@ The protocol architecture of \ac{ITS} stations according to the \ac{ETSI} refere
 \ac{OSI} layers 1 and 2 are combined into the \textit{Access} layer, \ac{OSI} layers 3 and 4 into the \textit{Networking \& Transport} layer and \ac{OSI} layers 5, 6 and 7 are put into the \textit{Facilities} layer (see Fig. \ref{fig:etsi-its-arch} ).  \\
 The two vertical \textit{Management} and \textit{Security} layers provide supporting functionality throughout the whole stack.   \textit{Applications} make use of the \ac{ITS}-station services and thus sit on top of it all.
 
-\todo{participants, structure, special requirements: changing topology, speed, real-time}
-
 Designed for modularity, the \ac{ETSI} \ac{ITS} architecture allows for a big number of access protocols.  Similarly, a great variety of applications can run on top of the stack.  Because of that variety, access and application layer are considered out-of-scope of this survey.
 
 The \textbf{Networking \& Transport} layer takes care of addressing and routing of messages within the ITS network and multiplexing them to higher-level services.  Similarly to the \ac{OSI} model, the groundwork of this functionality is provided by various networking protocols: \\
@@ -201,7 +199,6 @@ Every \ac{GN} node has to know its geographical position, e.g. through \acp{GNSS
 \end{itemize}
 
 For this to work, each node maintains a \ac{LT} with the positions of its direct neighbours.  This \ac{LT} is populated with information from periodically-sent beaconing messages. These beacons advertise a node's position, \ac{GN} address, its speed, station type and heading (see \ref{GN-identifiers}.  This information is also included in all other sent \ac{GN} packets.  \ac{LT} entries have a lifetime attached, after which they expire if not refreshed periodically.  
-For allowing to retrieve the position of non-neighbour nodes, the \ac{LS}, a collaborative functionality of all nodes, forwards request packets, until the node with the destination \ac{GN} address is found and has replied via geo-unicast or a retransmission counter has expired.\todo{influence of frequent pseudonym change}
 
 Security properties of \ac{GN} messages are ensured by signing (authenticity), encrypting (confidentiality) the messages and checking their plausibility and consistency. The necessary information for that is given in a security header \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636412017}.
 
@@ -244,7 +241,7 @@ Each \ac{GN} node is identified by a 64bit GN\_ADDR address \cite{europeanteleco
 
 As shown in Fig. \ref{fig:GNstructure}, \ac{GN} packets have a basic, a common and an optional extended header. The \textit{basic header} contains information like the packet's maximum lifetime and the remaining hop limit. These information are non-critical for identification. The \textit{common header} also doesn't contain identifying, only the flag indicating a mobile or stationary \ac{ITS} station could slightly reduce the anonymity set. The \textit{extended header} fields depend on the actual \ac{GN} package type and can contain information like the sequence number (initialized with 0) and position vectors.
 
-The \ac{LT} is populated with information from beaconing messages and all other messages received by the \ac{ITS} node.  \acl{LT} entries also contain identifying data: Additionally to the GN\_ADDR, station type and link-layer address of the peer node it contains a timestamped geographical position (including accuracy), its current speed and its heading. \todo{update position/ reacquire it when changing pseudonym}
+The \ac{LT} is populated with information from beaconing messages and all other messages received by the \ac{ITS} node.  \acl{LT} entries also contain identifying data: Additionally to the GN\_ADDR, station type and link-layer address of the peer node it contains a timestamped geographical position (including accuracy), its current speed and its heading.
 
 \begin{figure}
  \includegraphics[width=0.49\textwidth]{figures/GeoNetworking_structure_secured.png}
@@ -322,7 +319,7 @@ For \textbf{revocation} of node access to the \ac{ITS} network, e.g. in case of
 Section 11 of the \ac{ETSI} standard on IPv6 usage over \ac{GN} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636612014} covers the support for pseudonyms and their change of that protocol stack.  The binding of a \ac{GVL}'s prefix to a distinct geographical area can be a threat to users' location privacy as a static interface identifier part of the IPv6 address would allow singling out a node over multiple \ac{GVL} networks and track their location by the \ac{GVL} prefix and its associated geographical region.  \\
 The proposed countermeasure is again the adoption and regular change of pseudonyms.  In this case the affected identifier is the interface identifier part of IPv6 address.  As this identifier is derived from the link-layer address, this also implies a change of the link-layer identifier address (MAC address).  The same is true for the \ac{GN}\_ADDR thus it also changes accordingly with the changed link-layer address.  All existing IPv6 addresses have to be terminated as a clear cut between the old and new pseudonym IP address has to be made to prevent correlation of the old and new pseudonym during migration.  A possible countermeasure against the interruption is the usage of \textit{Network Mobility support} \cite{RFC3963}. As this mobility support requires a home agent where all traffic flows through, this home agent needs to be trusted as it still has the possibility of location tracking by \ac{GVL}.
 
-\subsection{Pseudonym Change Strategies}
+\subsection{Pseudonym Change Strategies}\label{sec:change-strategies}
 
 A crucial parameter of pseudonym schemes has been left out so far:  How and when pseudonyms are actually changed.  To show why that is so important, let us imagine a lone car on a street in the countryside:  If a single car just changes pseudonyms there, immediately continuing its broadcasts under the new pseudonym, linkage of the both pseudonyms is trivial for an observer.  \\
 Another example: Let us look at a traffic jam with 10 cars standing within reception range of an observer.  Now there are multiple cars around making the mapping of pseudonyms to cars not totally trivial.  But if we assume that each car only changes pseudonyms every 24 hours and does this at an arbitrary time, the probability that only 1 vehicle changes pseudonyms within a short time range is very high, making linkage of pseudonyms easy again.  \\
@@ -344,7 +341,7 @@ The strategy proposed by the Car-2-Car Communication Consortium is dividing each
 
 Some safety requirements of the \ac{ETSI} standard affect pseudonym change:  In critical situations when a receiving station would need to take immediate action in response to received safety information, pseudonyms have to be locked.  The reason behind that is that cooperational collision avoidance depends on all vehicles broadcasting their location and trajectory.  Vehicles in a silent period due to a pseudonym change wouldn't be taken into account, and vehicles changing pseudonyms without silent period could appear as duplicate or ghosting vehicles hindering collision evasion. \todo{who can trigger this locking?}  Recognizing such critical situations and initiating the pseudonym locking is done by the receiving \ac{ITS} vehicle, which decreases the risk of an attacker trying to deliberately lock pseudonyms without a critical situation being present.
 
-\subsection{Further Pseudonym Scheme Techniques}
+\subsection{Further Pseudonym Scheme Techniques}\label{sec:further-schemes}
 
 Petit et al. made an extensive survey \cite{petitPseudonymSchemesVehicular2015} of cryptographic approaches for pseudonym schemes and defined a representative pseudonym life-cycle for comparing the different approaches.  
 
@@ -384,6 +381,8 @@ As an advantage of these schemes, nodes don't have to deal with generating, issu
 
 Revocation is more complicated in group signature schemes: As all group nodes are indistinguishable by their exposed pseudonym identifiers, it's not possible to distribute revocation lists.  A re-setup of the group by changing system parameters can exclude certain nodes, but has a big overhead as all group members are required to change their keys.  A proposed solution for that circumvents the problem by remote-controlling the \ac{HSM} to remove the keys from its memory.
 
+The keys from group signature schemes are not directly usable for public key encryption of messages due to the special relationship of one public and multiple private keys.  They can be used though to authenticate key-exchange protocols like Diffie-Hellman which are unauthenticated by themselves.
+
 A special kind of group signature schemes not requiring setup and being more dynamic are \textit{ring signature schemes}.  Their usage is only briefly covered in \cite{petitPseudonymSchemesVehicular2015}.
 
 \subsubsection{Pseudonyms using Symmetric Cryptography}
@@ -394,15 +393,54 @@ For verification a node has to send the message (or a hash of it, depending on t
 
 Thus symmetric pseudonym signature schemes heavily rely on infrastructure for signature verification and introduce additional delays due to the needed round trips.  These issues make them hardly usable in practice.
 
-There are some attempts of getting rid of the issues.  The TESLA protocol \cite{perrigTESLABroadcastAuthentication} for example manages to reduce the infrastructure dependance by revealing previous signature keys using beaconing messages.  This approach still suffers from high latency times though.
+There are some attempts of getting rid of the issues.  The TESLA protocol \cite{perrigTESLABroadcastAuthentication} for example manages to reduce the infrastructure dependence by revealing previous signature keys using beaconing messages.  This approach still suffers from high latency times though.
 
 \section{Evaluation}
 
+This section evaluates the security of the proposed pseudonym schemes with an emphasis on the goals of privacy and anonymity, and the pseudonym schemes proposed in the \ac{ETSI} standards.  I also look at how much the pseudonym schemes influence the general functionality of the \ac{ITS} system.
+
 \todo{revocation: how to distribute CRLs in distributed systems? passive revocation: short lifetimes, prevent refill}
 
 \subsection{Attacker Model}
 
+In a security system for a network so ubiquitous like \ac{ITS} networks will be in our world with omnipresent, we can have a wide range of different adversaries with different capabilities and interests. So let's try to categorize the possibilities:
+
+Let's consider the \textbf{reach} of an attacker: Is the attacker limited to a single position, do they have a set of access points or do they even have a nearly global view on the network and their participants?  Are they accessing the network over wireless interfaces or are they part of the backbone infrastructure or internet?
+
+Is the attacker \textbf{active}ly trying to create, forge, block, modify, \dots messages like a \textit{Dolev-Yao adversary} \cite{dolevSecurityPublicKey1983a} or just \textbf{passive}ly eavesdropping?
+
+Is the attacker an \textbf{insider} - i.e. can it successfully authenticate at least with parts of the network – or an \textbf{outsider}?
+
+So let's combine some of these characteristics to common attacker models and take them as a basis for evaluation:  \\
+Our first attacker is a \textit{multi-point passive outsider}\label{attacker:1} which we then further extend to a \textit{global-point passive outsider}\label{attacker:2}.  \\
+For our third attacker we look at the power of \textit{attackers in the infrastructure}\label{attacker:3}.
+
+\subsection{Resilience against Attacks}
+
+Assuming our attacker is a multi-point passive outsider eavesdropping on the wireless communication and our \ac{ITS} network uses the pseudonym scheme proposed in the \ac{ETSI} standards.  \\
+As all communication to the \ac{AA} and \ac{EA} is securely encrypted, we can't get any information about the exchanged certificates and IDs from the eavesdropped communication to the PKI even if it happens to occur in our range of reception.  Assuming that all identifiers are changed simultaneously, we now can only threaten a node's location privacy by managing to link its pseudonyms to each other.  \\
+The change strategy proposed by the Car-2-Car Communication Consortium defined in \ref{sec:change-Strategies} is deliberately designed with our chosen adversary in mind:  Way lengths of segments are chosen big enough to prevent a single radio station tracking multiple segments including the pseudonym change itself while the middle-segment change interval time is chosen short enough to prevent multiple stations tracking the same pseudonym at multiple points.  So unless the adversary is lucky enough to have enough stations located at the correct points, we don't even need cooperative pseudonym change strategies so far.  \\
+When it comes to a global passive outsider though, the presence of other nodes and a cooperative pseudonym change strategy are necessary for reducing the linkability of pseudonyms well enough.  Cooperative dynamic pseudonym change reduces the probability of correctly linking pseudonyms together with each change and with the number of cooperating vehicles.  Silent periods in mix zones even improve the improbability as now projecting the last broadcasted trajectory into the the future includes too much entropy to reliably link pseudonyms.  As we are dealing with an outsider we can even choose the concept of a cryptographic mix zone to keep safety features working.  \\
+This changes though as we move to an insider attacker:  As all authenticated \ac{ITS} nodes get dealt the same symmetric key, our attacker can decrypt the broadcasted messages of all nodes, too, rendering this measure useless compared with a real silent period.  Other cryptographic measures like using a group signature scheme within the mix zone might help with the indistinguishability of nodes, though correlations of the actual beaconing messages including positions and trajectories can still help with the linkage of pseudonyms.  Additionally this can introduce other attack vectors like the \textit{Sybil attack} described later in this section.
+
+Other active insider attackers can attempt a \textit{pseudonym depletion attack} by initiating so many pseudonym changes that the victim node runs out of pseudonyms and has to keep the same pseudonym although a change would be due.  One possibility for this can be deliberately creating colliding network interface identifiers e.g. on the link layer.  As many identifiers are derived from the node's link layer address, such a collision breaks several functionality throughout the stack, one of them e.g. \ac{GN}.  To evade this collision and restore functionality again, the victim node changes its network identifiers, triggering a pseudonym change.  \\
+For this to work, pseudonym refill needs to be obstructed, e.g. by preventing the connection to an \ac{AA}.  A connection might fail due to bad network connectivity, possibly made worse by active jamming of the attacker, a denial-of-service attack to the \ac{AA} itself rendering it unusable or by collaboration of parts of the infrastructure (e.g. the \acp{RSU}) as our third attacker type suggests.  The SCOOP@F change strategy (see \ref{sec:change-strategies}) allows pseudonym reuse and thus prevents pseudonym depletion.  But this again can open an attack vector for \textit{Sybil attacks}.
+
+If the attacker has access to infrastructure components the issues with cryptographic mix zones already mentioned arise, too.  As all \acp{RSU} are connected to the internet, they can even collaborate to track all changes in (cryptographic) mix zones to become a long-term global active insider adversary.  Only frequent cooperative pseudonym change with silent periods introduces enough entropy to obstruct reliable pseudonym linkage.  \\
+Thanks to router advertisement and stateless autoconfiguration node's IPv6 addresses can't be linked to each other by the \ac{RSU} serving as the subnet router, as nodes don't have to request an IPv6 address but just construct it themselves using the announced prefix and their own interface identifier.  Thus also arbitrary IPv6 peers in the internet can't link the IPv6 addresses to recognize \ac{ITS} clients again.
+
+If an insider active attacker node has access to multiple pseudonyms at once and can change between these at will, it can create the impression of additional spoofed \ac{ITS} nodes in the surrounding area, tricking victim nodes into assuming being surrounded by many other vehicles and doing an ineffective pseudonym change.  This so called \textit{Sybil attack} can be prevented by limiting the number of available pseudonyms at a time, e.g by not exposing the pseudonym key material directly by storing it inside a \ac{HSM}.
+
+\subsection{Influence of Pseudonyms on Performance}
+
+distribution of CRLS; revocation
+
+- frequent pseudonym change
+
+- flushing queues: not all, e.g. LS should be safe
+
 The trust assumptions of the ETSI ITS security services architecture are layed out in section 6.2.5 of \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}.
+
 \todo{sybil attack}
 \todo{prevent linking multiple segments from same location: area big enough; prevent linking same pseudonym at multiple points: time short enough}
 

mybib.bib

@@ -531,4 +531,18 @@
   file = {/home/spiollinux/Zotero/storage/7BUPIGNJ/Verheul - Issue First Activate Later Certificates for V2X.pdf}
 }
 
+@article{dolevSecurityPublicKey1983a,
+  title = {On the Security of Public Key Protocols},
+  volume = {29},
+  issn = {0018-9448},
+  doi = {10.1109/TIT.1983.1056650},
+  language = {en},
+  number = {2},
+  journal = {IEEE Transactions on Information Theory},
+  author = {Dolev, D. and Yao, A.},
+  month = mar,
+  year = {1983},
+  pages = {198-208}
+}
+