improved citations
- add some citations to indtroduction - attempt to make clear what judgements come from the papers and which from me
This commit is contained in:
parent
8a88d051fd
commit
4cc3b104cc
38
main.tex
38
main.tex
|
@ -26,7 +26,17 @@
|
|||
\usepackage[]{svg}
|
||||
|
||||
\usepackage{acronym}
|
||||
\usepackage{hyperref}
|
||||
|
||||
\newcommand{\documenttitle}{An ETSI look at the State of the Art of pseudonym schemes in Vehicle-to-Everything (V2X) communication}
|
||||
|
||||
\newcommand{\abstracttext}{While \aclp{ITS} can contribute to increased road safety, they also allow tracking their user's location.\\
|
||||
This survey combines an overview of the \acs{ETSI} \acs{ITS} standard with a look at the state-of-the-art of pseudonym schemes for \acs{V2X} communication, evaluating their applicability for protecting against location tracking and the possibility of combination of different approaches. Thereby it focuses on the middle layers of the used network stack, examining both protocols and services specially designed for \acs{ITS} as well as more general internet protocols used there.}
|
||||
|
||||
% set pdf metadata
|
||||
\usepackage[
|
||||
pdftitle={\documenttitle},
|
||||
pdfauthor={Oliver Schmidt}
|
||||
]{hyperref}
|
||||
|
||||
\newcommand{\comment}[1]{{\parindent0pt\fbox{\begin{minipage}{0.45\textwidth}{\em #1}\end{minipage}}}}
|
||||
\newenvironment{changed}{\red}{\color{black}}
|
||||
|
@ -39,7 +49,6 @@
|
|||
}
|
||||
%\renewcommand{\Hide}[1]{}
|
||||
|
||||
\newcommand{\documenttitle}{An ETSI look at the State of the Art of pseudonym schemes in Vehicle-to-Everything (V2X) communication}
|
||||
|
||||
\pagenumbering{arabic}
|
||||
|
||||
|
@ -88,8 +97,7 @@
|
|||
|
||||
\begin{abstract}
|
||||
|
||||
While \aclp{ITS} can contribute to increased road safety, they also allow tracking their user's location.\\
|
||||
This survey combines an overview of the \acs{ETSI} \acs{ITS} standard with a look at the state-of-the-art of pseudonym schemes for \acs{V2X} communication, evaluating their applicability for protecting against location tracking and the possibility of combination of different approaches. Thereby it focuses on the middle layers of the used network stack.
|
||||
\abstracttext
|
||||
|
||||
\end{abstract}
|
||||
|
||||
|
@ -108,12 +116,12 @@ Networks, Intelligent transportation systems, Security, Mesh networks, Privacy
|
|||
\section{Introduction}
|
||||
|
||||
\IEEEPARstart{I}{n} recent
|
||||
years, traffic got safer and safer. Improved safety technologies in our vehicles have contributed a lot to that development. But so far safety assistant systems are mostly working on their own while trying to evaluate the situation around them. \\
|
||||
\aclp{ITS} aim to create an ecosystem of networked vehicles and their infrastructure, collaborating with other vehicles and road infrastructure to improve safety and additionally providing new services to users. This step will be crucial for achieving the \textit{vision zero} of no deaths caused by traffic worldwide.
|
||||
years, traffic got safer and safer \cite{europeancommission-directorategeneralformobilityandtransportEvolutionEURoad2018}. Improved safety technologies in our vehicles have contributed a lot to that development. But so far safety assistant systems are mostly working on their own while trying to evaluate the situation around them. \\
|
||||
\aclp{ITS} aim to create an ecosystem of networked vehicles and their infrastructure, collaborating with other vehicles and road infrastructure to improve safety and additionally providing new services to users. This step will be crucial for achieving the \textit{vision zero\footnote{This term is common nowadays in traffic planning and politics and has been introduced for that field in 1997} \cite{claestingvallVisionZeroEthical1999}} of no deaths caused by traffic worldwide.
|
||||
|
||||
While being an important step for traffic safety, \ac{ITS} can pose a danger for user's privacy as always connected vehicles sending their positional data around in computer networks might allow tracking the users and creating location profiles. \\
|
||||
Multiple solutions have been proposed so far to tackle this issue, protecting the human right of privacy.
|
||||
There already are some surveys giving an overview about the usage of different \textit{pseudonym schemes} for preserving privacy in \acp{ITS}. But often the cutting-edge research is far ahead of standardization attempts, while the latter are deciding how future practical implementations might work while the former can provide valuable inspirations and introduce new technologies to the stack.
|
||||
There already are some surveys (like \cite{petitPseudonymSchemesVehicular2015}, \cite{boualouacheSurveyPseudonymChanging2018}) giving an overview about the usage of different \textit{pseudonym schemes} for preserving privacy in \acp{ITS}. But often the cutting-edge research is far ahead of standardization attempts, while the latter are deciding how future practical implementations might work while the former can provide valuable inspirations and introduce new technologies to the stack.
|
||||
|
||||
This survey combines the current status of the European standardization efforts for \acp{ITS} by the \ac{ETSI} with state-of-the-art approaches from newer research.
|
||||
Thereby it takes a look at how the middle layers of the \ac{ETSI} \ac{ITS} standard architecture are affected by the threat against privacy and what can be done about this.
|
||||
|
@ -306,7 +314,7 @@ For \textbf{revocation} of node access to the \ac{ITS} network, e.g. in case of
|
|||
\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 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 connections 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}.
|
||||
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 connections 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 mentioned 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}\label{sec:change-strategies}
|
||||
|
||||
|
@ -314,15 +322,15 @@ A crucial parameter of pseudonym schemes has been left out so far: How and when
|
|||
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. \\
|
||||
A last example so far: Focusing on one vehicle, let us assume it changes its pseudonym in a perfectly ambiguously way which can't be linked to the old one reliably. But after the pseudonym change, an already enqueued packet is sent, containing identifiers linkable to the previous pseudonyms.
|
||||
|
||||
These examples already show important points to take care of when changing pseudonyms: There needs to be some ambiguity regarding which node changed to which pseudonym – there shall be other nodes present within the reception range, coordination and frequency of change matter, and all identifiers need to be changed simultaneously with buffers being flushed or discarded. The position needs to be updated during pseudonym change, too, to prevent re-identification through stale position coordinates included in GN packets. \todo{sequence number}
|
||||
These examples already show important points to take care of when changing pseudonyms: There needs to be some ambiguity regarding which node changed to which pseudonym – there shall be other nodes present within the reception range, coordination and frequency of change matter, and all identifiers need to be changed simultaneously with buffers being flushed or discarded. The position needs to be updated during pseudonym change, too, to prevent re-identification through stale position coordinates included in GN packets. Control metadata like sequence numbers in \ac{GN} packets have to be reset as well.
|
||||
|
||||
The \ac{ETSI} \ac{ITS} working group gathers a number of concepts for pseudonym change strategies in a technical report \cite{europeantelecommunicationsstandardsinstituteetsiETSITR1032018}: The parameters deciding about a pseudonym change (e.g. time period or way length) shall be randomized to prevent linkability by analyzing the periodicity of changes. After changing pseudonyms, random-length \textit{silent periods} shall be abided in which nodes stop sending any packages. When using a \textit{vehicle-centric} strategy, pseudonym change time, its frequency and duration of silent periods are influenced by the vehicle's mobility and trajectory to make linkage of pseudonyms based on broadcasted movement parameters harder. When using a density-based approach, pseudonyms are changed only if enough other vehicles are around to avoid unnecessary unambiguous pseudonym changes.
|
||||
|
||||
Mix-zones are geographical areas where no messages of location-aware services are exchanged. This concept is supposed to make linkage of in-going and outgoing vehicles from the zone difficult. These zones are especially effective in high-density and high-fluctuation areas like intersections or parking spots. \\
|
||||
Within these zones, vehicles could collaboratively change pseudonyms by first announcing it via broadcast messages and then changing synchronously. The efficiency of that approach depends heavily on the density of the situation. \\
|
||||
Within these zones, vehicles could collaboratively change pseudonyms by first announcing it via broadcast messages and then changing synchronously. As stated in the report, the efficiency of that approach depends heavily on the density of the situation. \\
|
||||
A special variant are \textit{cryptographic mix-zones}: Within these zones with a size limited to the radio coverage of \iac{RSU}, no identifying data is sent in plaintext but everything is encrypted with the same symmetric key provided by the \ac{RSU}. This allows the usage of location-aware collision detection messages while preventing an outsider from eavesdropping, without having to switch off important safety features.
|
||||
|
||||
An alternative to just changing from one pseudonym to the next one from a node's internal storage is swapping pseudonyms randomly between nearby vehicles. This approach is limited though by the inclusion of vehicle-specific data into messages and legal requirements demanding the possibility of an identity resolution for law enforcement.
|
||||
An alternative to just changing from one pseudonym to the next one from a node's internal storage is swapping pseudonyms randomly between nearby vehicles. We find this approach to limited though by the inclusion of vehicle-specific data into messages and legal requirements demanding the possibility of an identity resolution for law enforcement.
|
||||
|
||||
The \ac{ETSI} survey \cite{europeantelecommunicationsstandardsinstituteetsiETSITR1032018} also gives an overview of used strategies in existing standards or projects. These include some interesting further approaches: \\
|
||||
The SCOOP@F project proposes a timeslot-based round-robin pseudonym selection. The interesting thing about this is that reuse of pseudonyms from the local pool is explicitly allowed as the selection mechanism makes sure they are not always re-used in the same order. This is a useful approach against the problem of pseudonym refill (acquiring new pseudonyms) not always being possible. \\
|
||||
|
@ -345,9 +353,9 @@ When it comes to enhancing the privacy of pseudonym resolution, several approach
|
|||
|
||||
The IFAL protocol \cite{verheulIssueFirstActivate} introduces a mechanism tackling the issue of pseudonym refill: Pseudonym certificates can be distributed in big numbers already well in advance, as they are in principal valid in the future, but only if activated with periodically distributed activation codes. This is possible even over bad connections, SMS messages or via broadcasts as the codes are not confidential, but requires more storage space for the unactivated certificates.
|
||||
|
||||
The clear advantage of this class of schemes is the applicability to existing \ac{V2X} standards, as all major V2X Specifications use some kind of certificates.
|
||||
We see the clear advantage of this class of schemes in the applicability to existing \ac{V2X} standards, as all major V2X Specifications use some kind of certificates.
|
||||
|
||||
These certificates have to be included into each message though and their storage and verification requires notable resources. Furthermore is the maintenance of the \ac{PKI} system quite complicated, both regarding infrastructure requirements and legal and organisational frameworks. Because of these disadvantaged, we now take a look at other cryptographic pseudonym schemes.
|
||||
As mentioned by Petit et al. tough these certificates have to be included into each message and their storage and verification requires notable resources. Furthermore is the maintenance of the \ac{PKI} system quite complicated, both regarding infrastructure requirements and legal and organisational frameworks. Because of these disadvantaged, we now take a look at other cryptographic pseudonym schemes.
|
||||
|
||||
\subsubsection{Identity-based Cryptographic Pseudonyms}
|
||||
|
||||
|
@ -355,7 +363,7 @@ These certificates have to be included into each message though and their storag
|
|||
When it comes to pseudonym change, the same strategies as for certificate-based pseudonyms apply. As the network interface identifiers are equivalent with the public key, especially the strategies for changing the network identifiers are relevant.
|
||||
|
||||
As the public key is directly derivable from the destination address of messages, a \ac{MITM} relay-interception is prevented.
|
||||
Not having to include the certificate into each message and the smaller size of pseudonyms reduce the needed storage resources of ITS nodes. This though has to be compensated by the higher computational requirements of the used \textit{bilinear mappings}, which are the basis for most of these schemes.
|
||||
Not having to include the certificate into each message and the smaller size of pseudonyms reduce the needed storage resources of ITS nodes. According to the survey, this has to be compensated by the higher computational requirements of the used \textit{bilinear mappings}, which are the basis for most of these schemes.
|
||||
|
||||
With the \ac{TA} being involved in deriving the public key, pseudonym refill always requires a connection to this authority node. Another downside of this scheme is the required high trust into the \ac{TA} which retains all the mapping information and needs to be directly exposed to the ITS network, thus being an exposed and valuable attack target. Some promising attempts for approaching this downside are mentioned in the survey \cite{petitPseudonymSchemesVehicular2015} though.
|
||||
|
||||
|
@ -382,7 +390,7 @@ There are also pseudonym schemes utilizing symmetric cryptography authentication
|
|||
The big issue with these schemes is that creation and verification of signatures uses the same key. Thus every node having the key for verification purpose can also create valid signatures in the name of another node pseudonym. Thus signature verification can not be done by each node themselves. After a node got a vehicle-ID from an \ac{EA}, it creates several pseudonyms from it by hashing and combining with seed and counter values. These values then serve as pseudonym identifiers for connecting to \iac{RSU} and jointly creating a symmetric signature key. The \ac{RSU} retains a mapping of key and pseudonym identifier. \\
|
||||
For verification a node has to send the message (or a hash of it, depending on the MAC scheme) and the supposed sender pseudonym to the \ac{RSU}. That station then verifies the signature using the retained mapping and sends the result back to the requesting node.
|
||||
|
||||
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.
|
||||
Thus symmetric pseudonym signature schemes heavily rely on infrastructure for signature verification and introduce additional delays due to the needed round trips. Having these issues mentioned in the survey, they are hardly usable in practice.
|
||||
|
||||
There are some attempts of getting rid of these 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.
|
||||
|
||||
|
|
20
mybib.bib
20
mybib.bib
|
@ -554,4 +554,24 @@
|
|||
file = {/home/spiollinux/Zotero/storage/7K3VSIEV/ts_10289402v010201p.pdf}
|
||||
}
|
||||
|
||||
@misc{europeancommission-directorategeneralformobilityandtransportEvolutionEURoad2018,
|
||||
type = {Statistics},
|
||||
title = {Evolution of {{EU}} Road Fatalities over Time},
|
||||
howpublished = {https://ec.europa.eu/transport/road\_safety/sites/roadsafety/files/pdf/statistics/trends\_figures.pdf},
|
||||
author = {{European Commission - Directorate General for Mobility and Transport}},
|
||||
month = apr,
|
||||
year = {2018}
|
||||
}
|
||||
|
||||
@inproceedings{claestingvallVisionZeroEthical1999,
|
||||
address = {Melbourne},
|
||||
title = {Vision {{Zero}} - {{An}} Ethical Approach to Safety and Mobility},
|
||||
abstract = {Vision Zero is a philosophy of road safety that eventually no one will be killed or seriously injured within the road transport system. This paper describes Vision Zero and its view that safety cannot be traded for mobility. The applicability of Vision Zero to Victoria in the short- and long-term is discussed.},
|
||||
language = {en},
|
||||
author = {{Claes Tingvall} and {Narelle Haworth}},
|
||||
month = sep,
|
||||
year = {1999},
|
||||
file = {/home/spiollinux/Zotero/storage/J9PVY5ED/visionzero.html}
|
||||
}
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue