added attack overview table
This commit is contained in:
parent
604761f6cc
commit
4bc583e680
1
.gitignore
vendored
1
.gitignore
vendored
|
@ -3,3 +3,4 @@
|
||||||
*.synctex.gz
|
*.synctex.gz
|
||||||
*.bbl
|
*.bbl
|
||||||
*.blg
|
*.blg
|
||||||
|
*.out
|
||||||
|
|
23
main.tex
23
main.tex
|
@ -413,14 +413,14 @@ Is the attacker an \textbf{insider} – i.e. can it successfully authenticate at
|
||||||
So let us combine some of these characteristics to common attacker models and take them as a basis for evaluation: \\
|
So let us 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 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 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}. \\
|
||||||
At last we take a brief look on the abilities of \ac{privileged authorities as attackers}. \\
|
At last we take a brief look on the abilities of \textit{privileged authorities as attackers}. \\
|
||||||
These attacker models should cover the predominant adversaries trying to gather a user's location patterns: The main possibilities of accessing network messages are combined with different levels of privilege.
|
These attacker models should cover the predominant adversaries trying to gather a user's location patterns: The main possibilities of accessing network messages are combined with different levels of privilege.
|
||||||
|
|
||||||
The trust assumptions of the ETSI ITS security services architecture are layed out in section 6.2.5 of \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}.
|
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}
|
||||||
|
|
||||||
To show the necessity of different pseudonym scheme concepts, we start with a restricted attacker and the basic pseudonym scheme proposed by the \ac{ETSI} standards (\ref{sec:pseudonym_management} . From there on we choose a change strategy accordingly to protect against the attacks, while gradually increasing the attacker's abilities.
|
To show the necessity of different pseudonym scheme concepts, we start with a restricted attacker and the basic pseudonym scheme proposed by the \ac{ETSI} standards (\ref{sec:pseudonym_management} . From there on we choose a change strategy accordingly to protect against the attacks, while gradually increasing the attacker's abilities. A simplified overview is given in table \ref{tab:attacker_comparison}.
|
||||||
|
|
||||||
\subsubsection{multi-point passive outsider attacks}
|
\subsubsection{multi-point passive outsider attacks}
|
||||||
I assume our attacker to be a multi-point passive outsider eavesdropping on the wireless communication and our \ac{ITS} network to use the pseudonym scheme proposed in the \ac{ETSI} standards. \\
|
I assume our attacker to be a multi-point passive outsider eavesdropping on the wireless communication and our \ac{ITS} network to use the pseudonym scheme proposed in the \ac{ETSI} standards. \\
|
||||||
|
@ -448,12 +448,29 @@ If an insider active attacker node has access to multiple pseudonyms at once and
|
||||||
\subsubsection{privileged authority attackers}
|
\subsubsection{privileged authority attackers}
|
||||||
Privileged attackers from an authories like law enforcement have many options when trying to deanonymize \iac{ITS} station. The challenge here is that law enforcement agencies shall only be able to deanonymize a user for legitimate and lawful purposes, but shall not abuse this power.
|
Privileged attackers from an authories like law enforcement have many options when trying to deanonymize \iac{ITS} station. The challenge here is that law enforcement agencies shall only be able to deanonymize a user for legitimate and lawful purposes, but shall not abuse this power.
|
||||||
|
|
||||||
For allowing accountability through official ways, the \acf{RA} has to retain a mapping between the canonical enrolment credentials and the given pseudonyms. This sensitive information must only be accessible in a lawful way, thus building a legal and organizational framework for that purpose is crucial. Technical measures can help with that by splitting and distributing the mapping over multiple authorities and domains of control. Furthermore it needs to be ensured that these mapping information are not exposed in vulnerable parts of the infrastructure like \acp{RSU}. \\
|
For allowing accountability through official ways, the \acf{AA} has to retain a mapping between the canonical enrolment credentials and the given pseudonyms. This sensitive information must only be accessible in a lawful way, thus building a legal and organizational framework for that purpose is crucial. Technical measures can help with that by splitting and distributing the mapping over multiple authorities and domains of control. Furthermore it needs to be ensured that these mapping information are not exposed in vulnerable parts of the infrastructure like \acp{RSU}. \\
|
||||||
Given the legal basis for ordering the infrastructure operator to cooperate with law enforcement, authorities additionally have the capabilities of a global (within the scope of infrastructure coverage) active insider attacker. \\
|
Given the legal basis for ordering the infrastructure operator to cooperate with law enforcement, authorities additionally have the capabilities of a global (within the scope of infrastructure coverage) active insider attacker. \\
|
||||||
Due to this maintaining both user privacy and accountability is only possible in areas with independent judicial systems and separation of powers.
|
Due to this maintaining both user privacy and accountability is only possible in areas with independent judicial systems and separation of powers.
|
||||||
|
|
||||||
Without access to infrastructure or mapping authorities, law enforcement agents still have the capabilities of multi-point passive outsiders. As this approach doesn't require any cooperation with other authorities, this is most likely to be abused when ther is no legal ground to take the official route.
|
Without access to infrastructure or mapping authorities, law enforcement agents still have the capabilities of multi-point passive outsiders. As this approach doesn't require any cooperation with other authorities, this is most likely to be abused when ther is no legal ground to take the official route.
|
||||||
|
|
||||||
|
\begin{table}[h]
|
||||||
|
%\centering
|
||||||
|
|
||||||
|
\begin{tabular}{l | p{4cm} }
|
||||||
|
\textbf{attacker} & \textbf{possible countermeasures} \\ \hline
|
||||||
|
multi-point passive outsider & 3-segment pseudonym change \\ \hline
|
||||||
|
global passive outsider & cooperative pseudonym change: silent periods or (cryptographic) mix zones \\ \hline
|
||||||
|
active insider & resistance against pseudonym depletion (e.g. pseudonym reuse) \\ \hline
|
||||||
|
attacking infrastructure & frequent cooperative pseudonym change with real silent periods \\
|
||||||
|
|
||||||
|
\end{tabular}
|
||||||
|
\caption{overview of countermeasure against certain attackers}
|
||||||
|
\label{tab:attacker_comparison}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
\subsection{Influence of Pseudonyms on Performance}
|
\subsection{Influence of Pseudonyms on Performance}
|
||||||
|
|
||||||
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?
|
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?
|
||||||
|
|
Loading…
Reference in a new issue