finished evaluation

This commit is contained in:
Trolli Schmittlauch 2018-06-12 04:23:38 +02:00
parent dded18b034
commit 80c35a2626
2 changed files with 18 additions and 11 deletions

View file

@ -273,7 +273,7 @@ There exists a static mapping between IPv6 multicast groups and geographical are
\subsubsection{Facilities Layer} \subsubsection{Facilities Layer}
The Facilities layer introduces a \textit{StationID}, an integer identifying the \ac{ITS} system. The standard document \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022014} already mentions that this ID may be a pseudonym. The Facilities layer introduces a \textit{StationID}, an integer identifying the \ac{ITS} system. The standard document \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022014a} already mentions that this ID may be a pseudonym.
Some further identifiers might be introduced in real-world implementations, e.g. for realising certain service over their dedicated protocols. Some further identifiers might be introduced in real-world implementations, e.g. for realising certain service over their dedicated protocols.
@ -412,11 +412,13 @@ So let's combine some of these characteristics to common attacker models and tak
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}. \\ 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}. For our third attacker we look at the power of \textit{attackers in the infrastructure}\label{attacker:3}.
The trust assumptions of the ETSI ITS security services architecture are layed out in section 6.2.5 of \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}.
\subsection{Resilience against Attacks} \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. \\ 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. \\ 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. \\ 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. \\ 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. 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.
@ -432,19 +434,15 @@ If an insider active attacker node has access to multiple pseudonyms at once and
\subsection{Influence of Pseudonyms on Performance} \subsection{Influence of Pseudonyms on Performance}
\todo{revocation: how to distribute CRLs in distributed systems? passive revocation: short lifetimes, prevent refill} Preserving user's privacy through the use of pseudonym schemes is an additional requirement likely to add additional overhead to \ac{ITS} networks. So we need to ask ourselves: Is this additional overhead still reasonable?
distribution of CRLS; revocation As shown in the previous section, frequent psudonym change is needed at least each few minutes to prevent linkability of pseudonyms. This requires all network identifiers to change at the same frequency, too, interrupting existing long-standing connections. Applications either need to tolerate this or adopt countermeasures like the usage of a NEMO mobile IP home agent.
\cite{RFC3963}
- frequent pseudonym change To prevent old identifiers being sent after pseudonym changes in packets already queued before the pseudonym change it is recommended to flush or drop all packet buffers before the change. This isn't necessary if one can be sure that there is no node identifying data in the queued packets. That is true for the \ac{GN} packet forwarding queue, as nodes don't add their own source address when forwarding packages. The same is true for \ac{LS} packets. The source address included in their is the address of the original requesting node and though gives no reliable information about the address of the packet's sender as that node can also just be forwarding the package.
- flushing queues: not all, e.g. LS should be safe Active pseudonym certificate revocation turns out quite problematic in pseudonym schemes using asymmetric certificates and a \ac{PKI}: \acp{CRL} or \acp{CTL} can quickly grow so big that they don't propagate through the network in reasonable times. Additionally checking each message against them quickly becomes too much for the limited computational resources of the node. So instead of active revocation, passive revocation by preventing misbehaving nodes from refilling their short-lived pseudonyms is the way to go.
\todo{packet buffers: LS, forwarding}
The trust assumptions of the ETSI ITS security services architecture are layed out in section 6.2.5 of \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}.
\todo{prevent linking multiple segments from same location: area big enough; prevent linking same pseudonym at multiple points: time short enough}
\section{Summary} \section{Summary}
% % % % % %

View file

@ -545,4 +545,13 @@
pages = {198-208} pages = {198-208}
} }
@misc{europeantelecommunicationsstandardsinstituteetsiETSITS1022014a,
title = {{{ETSI TS}} 102 894-2 {{V1}}.2.1 {{Intelligent Transport Systems}} ({{ITS}}); {{Users}} and Applications Requirements; {{Part}} 2: {{Applications}} and Facilities Layer Common Data Dictionary},
lccn = {ETSI TS 102 894-2 V1.2.1},
author = {{European Telecommunications Standards Institute (ETSI)}},
month = sep,
year = {2014},
file = {/home/spiollinux/Zotero/storage/7K3VSIEV/ts_10289402v010201p.pdf}
}