added section about IPv6-GN pseudonyms
This commit is contained in:
parent
bd436dcd73
commit
3d3f31b7ad
9
main.tex
9
main.tex
|
@ -282,12 +282,14 @@ There are no obvious identifiers specified in the Facilities layer, though some
|
|||
|
||||
As shown in the previous section, \ac{ITS} communication contains many identifiers potentially allowing linking vehicle communication even over longer periods of time and thus track and create movement profiles of vehicles.
|
||||
|
||||
This is a clear threat to the vehicle user's privacy. Complete anonymity of all network participants is no viable countermeasure, as security critical systems like these require certain levels of authenticity of data and accountability of the participants. Furthermore, request-response message schemes require at least short-term linkability of messages to establish a mutual session.
|
||||
This is a clear threat to the vehicle user's privacy, more precisely the \textit{location privacy}. Complete anonymity of all network participants is no viable countermeasure, as security critical systems like these require certain levels of authenticity of data and accountability of the participants. Furthermore, request-response message schemes require at least short-term linkability of messages to establish a mutual session.
|
||||
|
||||
A widely chosen approach for restoring user privacy is the usage of temporary pseudonyms for identification in the network. This section will look at the usage and kinds of pseudonym schemes in the ETSI standards, explore other approaches outside of the standardized ETSI world and look at the issue of when to change pseudonyms to minimize long-term linkability of nodes.
|
||||
|
||||
\subsection{Pseudonym Schemes for ETSI ITS Systems}
|
||||
|
||||
\subsubsection{Pseudonym Management}
|
||||
|
||||
\nocite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}The \ac{ETSI} standard on trust and privacy management \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022012} mentions the goal of pseudonymity and unlinkability of \ac{ITS} nodes and their messages as the way to achieve ITS privacy. This privacy goal is subdivided into two dimensions:
|
||||
|
||||
The \textbf{privacy} of ITS registration and authorisation shall be achieved by limiting the knbowledge of a node's canonical (fixed) identifier to a limited number of authorities. Furthermore, the responsibility for verifying the validity of a canonical identifier is given to an \acf{EA} and split from the authorisation to services by the \acf{AA}. These both authorites need to be operated in different areas of control to achieve a surplus of privacy.\\
|
||||
|
@ -311,6 +313,11 @@ The \ac{ETSI} standard \cite{europeantelecommunicationsstandardsinstituteetsiETS
|
|||
|
||||
For \textbf{revocation} of node access to the \ac{ITS} network, e.g. in case of misbehaviour, there exist multiple mechanisms: The \ac{EA} can be told to revoke the node's enrolment credentials to prevent it from updating its enrolment certificate and thus acquiring further \acp{AT}. Additionally, the \ac{EA} revokes the validity of the enrolment certificate and the \ac{AA} does the same for the authorization tickets. As ITS nodes are expected to check the validity of certificates using \acfp{CRL} and \acfp{CTL} \cite{europeantelecommunicationsstandardsinstituteetsiETSITR1032018}, messages of the revoked node are not accepted anymore.
|
||||
|
||||
\subsubsection{Pseudonym Change for IPv6 ITS Networking}
|
||||
|
||||
Section 11 of the \ac{ETSI} standard on IPv6 usage over \ac{GN} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636612014} covers the support for pseudonymes 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 loction tracking by \ac{GVL}.
|
||||
|
||||
\subsection{Further Pseudonym Techniques}
|
||||
|
||||
\subsection{Pseudonym Change Strategies}
|
||||
|
|
12
mybib.bib
12
mybib.bib
|
@ -468,4 +468,16 @@
|
|||
howpublished = {Internet Requests for Comments}
|
||||
}
|
||||
|
||||
@techreport{RFC3963,
|
||||
type = {{{RFC}}},
|
||||
title = {Network {{Mobility}} ({{NEMO}}) {{Basic Support Protocol}}},
|
||||
number = {3963},
|
||||
institution = {{RFC Editor}},
|
||||
author = {Devarapalli, V. and Wakikawa, R. and Petrescu, A. and Thubert, P.},
|
||||
month = jan,
|
||||
year = {2005},
|
||||
issn = {2070-1721},
|
||||
howpublished = {Internet Requests for Comments}
|
||||
}
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue