some minor talk flow additions

- submitted version to conference preparation
- include cute "thank you" slide

.gitignore

@@ -3,3 +3,8 @@
 *.synctex.gz
 *.bbl
 *.blg
+*.out
+*.nav
+*.shm
+*.toc
+*.snm

glossary.tex

@@ -12,9 +12,10 @@
 \acro{GN}{GeoNetworking}
 \acro{GNSS}{Global Navigation Satellite System}
 \acro{GVL}{Geographical Virtual Link}
-\acro{HSM}{Hardware Security Module}: a dedicated piece of hardware providing strictly regulated access to cryptographic operations based on stored data (e.g. keys)
+\acro{HSM}{Hardware Security Module}
 \acro{IPv6}{Internet Protocol version 6}
 \acro{ITS}{Intelligent Transportation System}
+\acroindefinite{ITS}{an}{an}
 \acro{LLC}{Logical Link Control}
 \acro{LS}{GeoNetworking Location Service}
 \acro{LT}{GeoNetworking Location Table}

main.tex

@@ -14,19 +14,18 @@
 \usepackage{xcolor}
 \usepackage[]{graphicx}
 
-% svg conversion support
-\usepackage{ifluatex}
-\ifluatex
-  \usepackage{pdftexcmds}
-  \makeatletter
-  \let\pdfstrcmp\pdf@strcmp
-  \let\pdffilemoddate\pdf@filemoddate
-  \makeatother
-\fi
-\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 +38,8 @@
 }
 %\renewcommand{\Hide}[1]{}
 
-\newcommand{\documenttitle}{An ETSI look at the State of the Art of pseudonym scheme in Vehicle-to-Everything (V2X) communication}
+
+\pagenumbering{arabic}
 
 \begin{document}
 
@@ -48,26 +48,31 @@
 %----------------------------------------------------------------------
 \title{\documenttitle}
 
+
 % % %
 % In case of double blind submissions:
-\author{
-  \IEEEauthorblockN{Anonymous}
-  \IEEEauthorblockA{Some Research Group\\
-    Some Institution\\
-    Some Email Addresses%
-  }
-}
-
 %\author{
-%  \IEEEauthorblockN{Oliver Schmidt}
+%  \IEEEauthorblockN{Anonymous}
-%  \IEEEauthorblockA{TU Dresden\\
+%  \IEEEauthorblockA{Some Research Group\\
-%    oliver.schmidt3$[$at$]$mailbox.tu-dresden.de%
+%    Some Institution\\
-%   } 
+%    Some Email Addresses%
+%  }
 %}
 
+\author{
+  \IEEEauthorblockN{Oliver Schmidt}
+  \IEEEauthorblockA{TU Dresden\\
+    oliver.schmidt3$[$at$]$mailbox.tu-dresden.de%
+   } 
+}
+
 
 \maketitle
 
+% force pagenumbering
+\thispagestyle{plain}
+\pagestyle{plain}
+
 % % % 
 % sources on writing papers:
 % look for a /good/ outline at the end of this text, the /why/ is found at this link:
@@ -81,8 +86,7 @@
 
 \begin{abstract} 
 
-While \aclp{ITS} can contribute to increased road safety, they also allow tracking their user's location.\\
+\abstracttext
-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.
 
 \end{abstract}
 
@@ -101,22 +105,24 @@ 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.  \\
+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} of no death caused by traffic worldwide.
+\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 also already are some surveys giving an overview about the usage of different \textit{pseudonym schemes} for preserving privacy in \acp{ITS}.  But ofthen 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.
 
-In section \ref{sec:background} I describe the background knowledge needed to judge the functionality of \ac{ETSI} \ac{ITS} networks by giving an overview of their architecture. Afterwards I describe the protocols involved in the middle layers of the networking stack and single out potential identifiers usable for tracking of users.
+In Section \ref{sec:background} we describe the background knowledge needed to judge the functionality of \ac{ETSI} \ac{ITS} networks by giving an overview of their architecture. Afterwards we describe the protocols involved in the middle layers of the networking stack and single out potential identifiers usable for the tracking of users.
 
-In section \ref{sec:schemes} I describe the pseudonym scheme proposed in the \ac{ETSI} standard, emphasize the importance of pseudonym change strategies and present some further cutting edge pseudonym schemes not covered by standards so far.
+In Section \ref{sec:schemes} we describe the pseudonym scheme proposed in the \ac{ETSI} standard, emphasize the importance of pseudonym change strategies and present some further cutting edge pseudonym schemes not covered by standards so far.
 
 Section \ref{sec:evaluation} defines attacker models, uses them to evaluate the privacy gained by the \ac{ETSI} pseudonym scheme and looks at the feasability of that approach from a performance perspective.
 
+As this field introduces many new acronyms, the meaning of most of them can be looked up in the Glossary \ref{sec:glossary} at the end of this survey.
+
 % % % 
 % Literature Survey and Background
 \section{Background}
@@ -129,13 +135,13 @@ This section gives a brief overview of the \ac{ETSI} architecture for Intelligen
 \acp{VANET} have some special requirements: Due to many nodes being constantly on the move at higher speeds, tolerance for quickly changing topologies and low-latency communication are important points.  Multi-hop mesh-networking is an important ability to keep the network functional in areas without designated infrastructure.
 
 A \ac{VANET} consists of different kinds of ITS stations: \\
-\acfp{OBU} residing inside vehicles can be divided into the communication and \acl{CCU}, managing the \ac{ITS} specific network communication over the car's wireless interfaces, and \acfp{AU} utilizing the network services provided by the \ac{CCU} to communicate transparently over a standard \acs{IPv6} stack.  \\
+\acfp{OBU} reside inside vehicles and can be divided into two different kinds of components:  The \acf{CCU} manages the \ac{ITS} specific network communication over the car's wireless interfaces, and the \acfp{AU} utilize the network services provided by the \ac{CCU} to communicate transparently over a standard \acs{IPv6} stack.  \\
-On the stationary infrastructure side, \acfp{RSU} can either just provide some special local services or even be connected to a network operator's infrastructure and thus provide an uplink to the Internet.
+On the stationary infrastructure side, \acfp{RSU} can either just provide some special local services or even be connected to a network operator's infrastructure and thus provide an uplink to the Internet (see Fig. \ref{fig:schema_internet_components}).
 
 \begin{figure}
  \includegraphics[width=0.48\textwidth]{figures/schema_internet_communication.png}
  \caption{Components of an ITS network, communicating with the internet; source: \cite{sandonisVehicleInternetCommunications2016}}
- \label{schema_internet_components}
+ \label{fig:schema_internet_components}
 \end{figure}
 
 
@@ -173,9 +179,9 @@ Every \ac{GN} node has to know its geographical position, e.g. through \acp{GNSS
  \item geo-anycast: routing packet to an arbitrary node within a specified geographical area
 \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 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.  
 
-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}.
+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}.  Encryption is only available for messages addressed to certain GN nodes (multicast and unicast)\cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022012}.  Key management for multicast groups is left to application-specific mechanisms or existing systems.
 
 \subsubsection{IPv6}
 
@@ -183,7 +189,7 @@ Security properties of \ac{GN} messages are ensured by signing (authenticity), e
 
 \subsubsection{IPv6 over GeoNetworking}
 
-Transparently exposing IP networking to higher layers allows re-using existing services based on the classical Internet TCP/IP stack without modification.  The \acf{GN6ASL} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636612014} specifies a mechanism for sending \ac{IPv6} packets over the GN protocol by using it as a sub-IP coupling layer. \ac{GN} takes care of encapsulating and routing the IP packets to its final destination node, so that the whole underlying \ac{VANET} looks like a flat layer 2 network to IP services.  
+Transparently exposing IP networking to higher layers allows re-using existing services based on the classical Internet TCP/IP stack without modification.  The \acf{GN6ASL} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636612014} specifies a mechanism for sending \ac{IPv6} packets over the GN protocol by using it as a sub-IP coupling layer. \ac{GN} takes care of encapsulating and routing the IP packets to their final destination node, so that the whole underlying \ac{VANET} looks like a flat layer 2 network to IP services.  
 \ac{GN6ASL} specifies how to derive a \ac{GN} address from an \ac{IPv6} address and extends \ac{IPv6} with some \acl{GN} specific extensions like geographic multicast, Geographically
 Scoped stateless Address Configuration or (un)reachability detection.
 
@@ -201,7 +207,7 @@ The \textbf{Management Layer} takes care of software changes like updates and in
 
 \subsection{Identifiers}
 
-There are many different addresses, IDs or other identifying information scattered around the network layers. This sections gives a list of relevant identifiers and the information encoded in them. Media-dependent, that means bound to a certain physical or data link layer, additional identifiers are considered out-of-scope.
+There are many different addresses, IDs or other identifying information scattered around the network layers. This section gives a list of relevant identifiers and the information encoded in them. Media-dependent, that means bound to a certain physical or data link layer technology, additional identifiers are considered out-of-scope.
 
 \subsubsection{GeoNetworking}
 \label{GN-identifiers}
@@ -214,7 +220,7 @@ Each \ac{GN} node is identified by a 64bit GN\_ADDR address \cite{europeanteleco
  \label{fig:GNstructure}
 \end{figure}
 
-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.
+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 information, 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.
 
@@ -224,7 +230,7 @@ The \ac{LT} is populated with information from beaconing messages and all other
  \label{fig:GNstructure_secured}
 \end{figure}
 
-Parts of \ac{GN} packets can be secured by wrapping them into security headers as defined in \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1032017} as shown in Fig. \ref{fig:GNstructure_secured}.  This service is provided by the vertical security layer in the \ac{ETSI} \ac{ITS} architecture and secures all parts shown in Fig. \ref{fig:GNstructure_secured} between security header and trailer according to the chosen security profile.  The standard defines security profiles for encrypted, signed, externally signed, and signed encrypted messages. 
+Parts of \ac{GN} packets can be secured by wrapping them into security headers as defined in \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1032017} and shown in Fig. \ref{fig:GNstructure_secured}.  This service is provided by the vertical security layer in the \ac{ETSI} \ac{ITS} architecture and secures all parts shown in Fig. \ref{fig:GNstructure_secured} between security header and trailer according to the chosen security profile.  The standard defines security profiles for encrypted, signed, externally signed, and signed encrypted messages. 
 
 The certificates used contain information about signer  subject (name, type, keys), validity restrictions and the actual certificate signature from the \ac{CA}.
 The signer information can be given in form of a digest, certificate or certificate chain.
@@ -255,20 +261,20 @@ Some further identifiers might be introduced in real-world implementations, e.g.
 \section{Pseudonym Schemes}
 \label{sec:schemes}
 
-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.
+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 tracking and creating movement profiles of vehicles.
 
 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.  This is needed e.g. for requesting data from infrastructure or managing automatical payment at car chargers.
 
-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.
+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}
+\subsubsection{Pseudonym Management}\label{sec: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 authorization shall be achieved by limiting the knowledge 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 authorization to services by the \acf{AA}.  These both authorities are parts of the needed \ac{PKI} and need to be operated in different areas of control to achieve a surplus of privacy.\\
+The \textbf{privacy} of ITS registration and authorization shall be achieved by limiting the knowledge 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 authorization to services by the \acf{AA}.  Both these authorities are parts of the needed \ac{PKI} and need to be operated in different areas of control to achieve a surplus of privacy.\\
-During manufacture the following data is to be stored in an ITS node using a physically secure process:
+During manufacture, the following data is to be stored in an ITS node using a physically secure process:
 \begin{itemize}
  \item a globally unique canonical identifier
  \item contact addresses + public keys of an \ac{EA} and\ac{AA},
@@ -276,8 +282,9 @@ During manufacture the following data is to be stored in an ITS node using a phy
 \end{itemize}
 The \ac{EA} has to hold the following information about a node: The permanent canonical identifier, its enrollment credentials, its public key and a link to further profile information.  
 ITS nodes can now request an enrolment certificate with their enrolment credentials from the EA.  The task of the \ac{EA} is to verify that an \ac{ITS} node can be trusted to function correctly as the EA must only know the credentials of certified \ac{ITS} nodes.  Credentials of compromised nodes have to be revoked.  With the enrollment request being encrypted and signed by the enrolling node and the response being encrypted as well, only the \ac{EA} knows the mapping between the enrollment certificate and the requesting identity.  The enrollment certificate contains a pseudonymous identifier being signed with a certificate chain leading back to the originating \ac{EA}.
-This enrollment certificate can then be used to get \acfp{AT} from an \ac{AA}.  These \acp{AT} too are certificates denoting the permissions a node has.  Authorization ticket certificates may be stored in a \ac{HSM}, at least the security service Specification \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010} offers such an option.  \\
+This enrollment certificate can then be used to get \acfp{AT} from an \ac{AA}.  These \acp{AT} too are certificates denoting the permissions a node has.  Authorization ticket certificates may be stored in a \ac{HSM} to prevent direct unregulated access to the cryptographic keys, at least the security service Specification \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010} offers such an option.  \\
-All authority responses are encrypted and signed in a for the node verifiable way. Certificate requests include a start and end time as well as a \textit{challenge} \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}, a random string encrypted with the public key of the receiver.  These two measures prevent against message replay attacks.  Enrolment credentials and \acp{AT} can also be updated if needed over similar mechanisms.
+All authority responses are encrypted and signed in a way verifiable for the node.  Certificate requests include a start and end time as well as a \textit{challenge} \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}, a random string encrypted with the public key of the receiver.  These two measures prevent against message replay attacks.  Enrolment credentials and \acp{AT} can also be updated if needed over similar mechanisms.  \\
+The overall trust model is sketched in Figure \ref{fig:pki}.
 
 \begin{figure}
  \includegraphics[width=0.48\textwidth]{figures/etsi-pki.png}
@@ -287,36 +294,36 @@ All authority responses are encrypted and signed in a for the node verifiable wa
 
 
 The second dimension of privacy covers the communication between \ac{ITS} stations. The obtained authorization tickets serve as pseudonyms for authenticating and signing messages with other \ac{ITS} services and nodes.  ITS stations have to check the validity of the \ac{AT} certificates included in every message and can check the permissions for the message's action (e.g. sending messages to certain broadcast domains) or access to certain services.  These pseudonyms are to be regularly changed to preserve the privacy of the node's user by achieving long-term unlinkability of messages by the ITS node.  According to \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636412017} the \ac{AT} may even be used to derive a \ac{GN}\_ADDR from.\\
-There are different kinds of \acp{AT}:  Those used by official role vehicles (e.g. state authorities) and \ac{ITS} infrastructure don't always need to preserve the node's privacy and thus can contain a long-lived identifier for the official role they are fulfilling.  \acp{AT} of personal user nodes can contain further personal identifying information if required for service usage, but then shall only be sent to already authorized nodes over encrypted channels.  For broadcasting, first contact and all other uses, personal user nodes shall only use minimal pseudonymous \acp{AT} which then can be sent even over non-encrypted channels.
+There are different kinds of \acp{AT}:  Those used by official role vehicles (e.g. state authorities) and \ac{ITS} infrastructure do not always need to preserve the node's privacy and thus can contain a long-lived identifier for the official role they are fulfilling.  \acp{AT} of personal user nodes can contain further personal identifying information if required for service usage, but then shall only be sent to already authorized nodes over encrypted channels.  For broadcasting, first contact and all other uses, personal user nodes shall only use minimal pseudonymous \acp{AT} which then can be sent even over non-encrypted channels.
 
-The \ac{ETSI} standard \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010} mentions the retaining of an audit log of incoming messages as the way of holding nodes \textbf{accountable} in case of misbehaviour.  This only helps though if the \ac{EA} retains a mapping of enrollment certificate to the canonical identifiers they were given to and the \ac{AA} does the some for \acp{AT} and enrolment certificates.  The legal and organisational framework for making sure that the information from the \ac{EA} and \ac{AA} are only combined for legitimate cases is crucial for maintaining user privacy, but are left out-of-scope of this survey.
+The \ac{ETSI} standard \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010} mentions the retaining of an audit log of incoming messages as the way of holding nodes \textbf{accountable} in case of misbehaviour.  This only helps though if the \ac{EA} retains a mapping of enrollment certificates to the canonical identifiers they were given to and the \ac{AA} does the same for \acp{AT} and enrolment certificates.  The legal and organisational framework for making sure that the information from the \ac{EA} and \ac{AA} are only combined for legitimate cases is crucial for maintaining user privacy, but is left out-of-scope of this survey.
 
 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 enrollment credentials to prevent it from updating its enrollment certificate and thus acquiring further \acp{AT}.  Additionally, the \ac{EA} revokes the validity of the enrollment 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 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}.
+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}
 
-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.  \\
+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 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.  \\
 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 need to be updated during pseudonym change, too, to prevent re-identification through stale position coordinates included in GN packets.
+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 released gathers a number of concept for pseudonym change strategies in \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.
+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 \textit{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.  \\
+\textit{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 \textit{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.  \\
+The SCOOP@F project proposes a \textit{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.  \\
-The strategy proposed by the Car-2-Car Communication Consortium is dividing each trip into at least 3 segments:  The first one from the start of the trip to a middle segment, the middle segment being common to a number of people and unassociated to certain origins and destinations, and the last segment to the intended destination of the trip.  This shall achieve that locations significant to a user can neither be linked together nor to the user and thus preventing individual movement profiles.  The values for changing pseudonyms have been statistically obtained with the outcome of changing pseudonyms at the beginning of a trip, then randomly after 0.8-1.5 km, and from then on randomly at least every 0.8 km or 2-6 minutes.
+The strategy proposed by the Car-2-Car Communication Consortium is \textit{dividing each trip} into at least 3 segments:  The first one from the start of the trip to a middle segment, the middle segment being common to a number of people and unassociated to certain origins and destinations, and the last segment to the intended destination of the trip.  This shall achieve that locations significant to a user can neither be linked together nor to the user and thus preventing individual movement profiles.  The values for changing pseudonyms have been statistically obtained with the outcome of changing pseudonyms at the beginning of a trip, then randomly after 0.8-1.5 km, and from then on randomly at least every 0.8 km or 2-6 minutes.
 
 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.   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.
 
@@ -328,16 +335,16 @@ Petit et al. made an extensive survey \cite{petitPseudonymSchemesVehicular2015}
 
 The \ac{ETSI} standardized pseudonym scheme is one instance of the ones categorized as \textit{asymmetric cryptography schemes} in that survey.  The class of these schemes is characterized by the use of asymmetric cryptography based on hierarchical certificates acquired from a \ac{PKI}.  This PKI has to be divided into at least 2 different administrative and legal control domains to make sure pseudonym resolution using the retained pseudonym-to-identity escrow mapping information only happens under specific legal circumstances.  Important parameters of these kinds of pseudonym schemes are the number of available pseudonyms acquired and available at a time, their lifetime, the used way of acquiring new pseudonyms (\textit{pseudonym refill}) and the number of collaborating different authorities to resolve the split information for pseudonym resolution.
 
-Some approaches covered don't require contact to an external \ac{PKI} for pseudonym refill, but allow pseudonym self-issuance:  Armknecht et al. \cite{armknechtCrosslayerPrivacyEnhancement2007} propose the self-issuance of pseudonym certificates with the node's own master keys.  Verification of these pseudonyms utilizes zero-knowledge proofs and bilinear pairings while revocation of certificates works via changing the cryptographic system's parameters.  \\
+Some approaches covered do not require contact to an external \ac{PKI} for pseudonym refill, but allow pseudonym self-issuance:  Armknecht et al. \cite{armknechtCrosslayerPrivacyEnhancement2007} propose the self-issuance of pseudonym certificates with the node's own master keys.  Verification of these pseudonyms utilizes zero-knowledge proofs and bilinear pairings while revocation of certificates works via changing the cryptographic system's parameters.  \\
 Calandriello et al. \cite{calandrielloEfficientRobustPseudonymous2007} combine the classical certificate scheme with \textit{group signature schemes} (see \ref{sec:group-signatures}) for pseudonym generation with individual private keys, and verification with the public common group key.
 
-When it comes to enhancing the privacy of pseudonym resolution, several approaches of further splitting and distributing identity mapping information over several authorities utilizing blind signature schemes or group signature schemes.
+When it comes to enhancing the privacy of pseudonym resolution, several approaches of further splitting and distributing identity mapping information over several authorities utilizing blind signature schemes or group signature schemes are mentioned.
 
 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 for 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, I 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}
 
@@ -345,22 +352,22 @@ 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.
 
 \subsubsection{Group Signature Scheme based Pseudonyms}
 \label{sec:group-signatures}
 
-The idea behind group signature schemes is that all nodes of a group are using the same shared public key for signing their messages, but have individual private keys for creating these signatures.  As every group member could have created the signature validated with that shared public key, all nodes of the group are using the same pseudonym and this are anonymous within the anonymity set of the group.  Two messages of the same vehicle are not linkable to each other as they're not distinguishable from two messages of different vehicles which are members of the same group.
+The idea behind group signature schemes is that all nodes of a group are using the same shared public key for signing their messages, but have individual private keys for creating these signatures.  As every group member could have created the signature validated with that shared public key, all nodes of the group are using the same pseudonym and thus are anonymous within the anonymity set of the group.  Two messages of the same vehicle are not linkable to each other as they are not distinguishable from two messages of different vehicles which are members of the same group.
 
-Groups require a setup, during which the members of the group are determined and individual private keys are assigned to them by the \textit{group leader}.  The group manager is an entity that determines the system parameters including the public group key, creates and assigns private keys based on them to members and may revoke pseudonymity for certain members.  This role could be assigned to any node of the group but as it allows certain privileged actions the process of group manager election needs to be concisely designed.  Proposals include using \acp{RSU} as regional group managers, which makes infrastructure operators even more powerful potential tracking abilities.
+Groups require a setup, during which the members of the group are determined and individual private keys are assigned to them by the \textit{group leader}.  The group manager is an entity that determines the system parameters including the public group key, creates and assigns private keys based on them to members and may revoke pseudonymity for certain members.  This role could be assigned to any node of the group, but as it allows certain privileged actions the process of group manager election needs to be concisely designed.  Proposals include using \acp{RSU} as regional group managers, which gives infrastructure operators even more powerful potential tracking abilities.
 
-Pseudonyms are only changed to manage group dynamics, i.e. change of members of the group.  Then the group manager generates new system parameters and issues new keys.  When this happened already mentioned strategies like silent periods may be used.  But individual network interface addresses still need to be unique per node and thus still have to change regularly like in other pseudonym schemes.  
+Pseudonyms are only changed to manage group dynamics, i.e. change of members of the group.  Then the group manager generates new system parameters and issues new keys.  When this happens, already mentioned strategies like silent periods may be used.  But individual network interface addresses still need to be unique per node and thus still have to change regularly like in other pseudonym schemes.  
 
-As an advantage of these schemes, nodes don't have to deal with generating, issuing and storing many pseudonym certificates.
+As an advantage of these schemes, nodes do not have to deal with generating, issuing and storing many pseudonym certificates.
 
-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.
+Revocation is more complicated in group signature schemes: As all group nodes are indistinguishable by their exposed pseudonym identifiers, it is 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.
 
@@ -369,66 +376,102 @@ A special kind of group signature schemes not requiring setup and being more dyn
 \subsubsection{Pseudonyms using Symmetric Cryptography}
 
 There are also pseudonym schemes utilizing symmetric cryptography authentication using Message Authentication Codes.  Symmetric crypto algorithms are often computationally more efficient which would fit the requirements of near-realtime processing in \acp{VANET}.  \\
-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't 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.  \\
+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 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.
+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.
 
 \section{Evaluation}
 \label{sec: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.
+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.  We also look at how much the pseudonym schemes influence the general functionality of the \ac{ITS} system.
 
 
 \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:
+In a security system for a network so ubiquitous like \ac{ITS} networks will be in our world with omnipresent nodes, users and infrastructure, we can have a wide range of different adversaries with different capabilities and interests. We can categorise them according to different characteristics:
 
-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?
+We can 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}?
+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:  \\
+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-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 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 \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.
 
 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}
 
-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.  \\
+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}.
-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.  \\
+\subsubsection{multi-point passive outsider attacks}
-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.  \\
+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.  \\
-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.
+As all communication to the \ac{AA} and \ac{EA} is securely encrypted, we can not 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 do not even need cooperative pseudonym change strategies so far.
 
 Authority vehicles shall only use their non-anonymized privileged tickets when they clearly want to exhibit this privileged status.  Ambulances or firefighter trucks using these non-anonymized \acp{AT} can be recognized immediately and are granted special privileges.  Nevertheless there needs to be an additional mechanism of utilizing these privileges while being pseudonymous and not appearing as an authority node to everyone.  Police cars need a possibility of being undercover without passive outsider adversaries just recognizing them as the authority they are, otherwise avoiding police cars without even seeing them becomes much easier.  For executing their privileges they can authenticate themselves as a privileged authority over an encrypted connection, similar to the personal \acp{AT}.
 
+\subsubsection{global passive outsider attacks}
+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.
+
+\subsubsection{insider attackers}
+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.  \\
+If the attacker has access to \textit{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.
+Thanks to router advertisement and stateless autoconfiguration node's IPv6 addresses can not be linked to each other by the \ac{RSU} serving as the subnet router, as nodes do not 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 not link the IPv6 addresses to recognize \ac{ITS} clients again.
 
-Personal \acp{AT} sent to already authenticated \ac{ITS} stations can include additional personal data.  This might be necessary for some kinds of services (e.g. payment information for charging services) but allows limited loaction tracking, especially if multiple stations of this kind and the same operator are located at different positions.  They might exchange information about a node being close to them over the internet.  As countermeasures it needs to be ensured that such personal identifying data is only included if it's really necessary.  Additionally this data must be only sent to the service nodes when they're actually used, not just because they're within reception range.
+Personal \acp{AT} sent to already authenticated \ac{ITS} stations can include additional personal data.  This might be necessary for some kinds of services (e.g. payment information for charging services) but allows limited loaction tracking, especially if multiple stations of this kind and the same operator are located at different positions.  They might exchange information about a node being close to them over the internet.  As countermeasures it needs to be ensured that such personal identifying data is only included if it is really necessary.  Additionally this data must be only sent to the service nodes when they are actually used, not just because they are within reception range.
 
 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}.
 
+\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.
+
+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.  \\
+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.  
+
+\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}
 
 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?
 
-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.
+As shown in the previous section, frequent pseudonym change is needed at least each few minutes to prevent linkability of pseudonyms.  This requires all network identifiers to change with 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}
 
-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.
+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 is not 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 do not add their own source address when forwarding packages.  The same is true for \ac{LS} packets.  The source address included in there 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.
 
-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.
+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 do not 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 approach to choose.
 
+Generally certificate checking is a quite computationally expensive process requiring either specialized hardware units like \acp{HSM} or high-performance CPUs, as the message frequency can easily reach hundreds of thousands broadcast messages per second. \cite{hamidaSecurityCooperativeIntelligent2015}  But as this is a general issue of such PKI-based asymmetric cryptography and not directly related to pseudonym usage, these issues are left for other work to investigate.
 
 \section{Summary}
 % % % 
@@ -437,9 +480,12 @@ The \acf{ETSI} \acf{ITS} standard architecture contains many identifiers through
 
 To counter this threat for a user's location privacy, various pseudonym schemes have been proposed.  The one proposed for usage with the \ac{ETSI} standards uses asymmetric cryptography and a \acf{PKI}, but lacks a proper definition of important aspects like a detailed pseudonym change strategy, pseudonym resolution resilient against authority misuse or the usage of more advanced cryptographic schemes.  But combined with technologies from other research the scheme is feasible to protect user privacy against several proposed attackers.
 
-As many advanced cryptographic schemes are not compatible with the standardsproposed by \ac{ETSI} so far, future work should evaluate whether the standard could be changed to utilize some of these more modern approaches to counter current drawbacks.
+As many advanced cryptographic schemes are not compatible with the standards proposed by \ac{ETSI} so far, future work should evaluate whether the standard could be changed to utilize some of these more modern approaches to counter current drawbacks.
+
+Additionally, future work may investigate the issue of possible identifiers or other linkable information in the lower network layers (physical and data link) and in the message contents themselves (application layer).
 
 \section{Glossary}
+\label{sec:glossary}
 
 \nobreak
 

mybib.bib

@@ -81,7 +81,7 @@
   abstract = {Pseudonym certificates are the state-of-the-art approach for secure and privacy-friendly message authentication in vehicular ad-hoc networks. However, most of the proposed pseudonym schemes focus on privacy among participants. Privacy towards backend providers is usually (if at all) only protected by separation of responsibilities. The protection can be overridden, when the entities collaborate, e.g. when revocation of long-term credentials is required. This approach puts the users' privacy at risk, if the backend systems are not fully trusted.},
   language = {en},
   journal = {Ad Hoc Networks},
-  author = {F{\"o}rster, David and Kargl, Frank and L{\"o}hr, Hans},
+  author = {F\"orster, David and Kargl, Frank and L\"ohr, Hans},
   year = {2016},
   keywords = {unread},
   pages = {11},
@@ -200,7 +200,7 @@
   doi = {10.1007/s00779-012-0633-z},
   number = {1},
   journal = {Personal Ubiquitous Comput.},
-  author = {Wernke, Marius and Skvortsov, Pavel and D{\"u}rr, Frank and Rothermel, Kurt},
+  author = {Wernke, Marius and Skvortsov, Pavel and D\"urr, Frank and Rothermel, Kurt},
   month = jan,
   year = {2014},
   keywords = {Adversary,Approaches,Attacks,Classification,Location privacy,Location-based services,Principles,Protection goals,unread},
@@ -318,7 +318,7 @@
   language = {en},
   number = {3},
   journal = {Transactions on Emerging Telecommunications Technologies},
-  author = {Sandonis, Victor and Soto, Ignacio and Calderon, Maria and Urue{\~n}a, Manuel},
+  author = {Sandonis, Victor and Soto, Ignacio and Calderon, Maria and Urue\~na, Manuel},
   month = mar,
   year = {2016},
   keywords = {GeoNetworking},
@@ -394,11 +394,11 @@
 
 @article{TN_libero_mab2,
   title = {{{ISO}} 29281-1},
-  abstract = {Bibliographische Datenbank (monatlich aktualisiert, 3sprachig) mit ca. 1.100.000 Daten von Normen aus 23 L{\"a}ndern, (z.B. ANSI, DIN, ISO), technischen Regeln sowie von deutschen Rechtsvorschriften mit technischen Bezug und geltenden EU-Richtlinien incl. VDI-Richtlinien. Der Volltextzugriff auf Normen ist nur bei entsprechender Lizenz verf{\"u}gbar!},
+  abstract = {Bibliographische Datenbank (monatlich aktualisiert, 3sprachig) mit ca. 1.100.000 Daten von Normen aus 23 L\"andern, (z.B. ANSI, DIN, ISO), technischen Regeln sowie von deutschen Rechtsvorschriften mit technischen Bezug und geltenden EU-Richtlinien incl. VDI-Richtlinien. Der Volltextzugriff auf Normen ist nur bei entsprechender Lizenz verf\"ugbar!},
-  author = {intelligents de transport {ISO/TC 204 Systeme f{\"u}r Verkehrsbeeinflussung und -information , ISO/TC 204 Intelligent transport systems}, ISO/TC 204 Syst{\`e}mes},
+  author = {intelligents de transport {ISO/TC 204 Systeme f\"ur Verkehrsbeeinflussung und -information , ISO/TC 204 Intelligent transport systems}, ISO/TC 204 Syst\`emes},
   year = {2013},
   keywords = {DIN-Norm,Internationale Norm,Norm,Regeln der Technik,Verzeichnis},
-  publisher = {{ISO Internationale Organisation f{\"u}r Normung, ISO International Organization for Standardization, ISO Organisation Internationale de Normalisation}}
+  publisher = {{ISO Internationale Organisation f\"ur Normung, ISO International Organization for Standardization, ISO Organisation Internationale de Normalisation}}
 }
 
 @techreport{RFC8200,
@@ -554,4 +554,29 @@
   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}
+}
+
+@misc{careeuroadaccidentsdatabaseEUFatalitiesTargets,
+  title = {{{EU Fatalities}} and {{Targets}} 2001-2020},
+  author = {{CARE (EU road accidents database)}}
+}
+
 

talk-slides.tex

@@ -0,0 +1,361 @@
+% $Header$
+% use lualatex for compilation
+
+\documentclass[aspectratio=169]{beamer}
+
+% This file is a solution template for:
+
+% - Talk at a conference/colloquium.
+% - Talk length is about 20min.
+% - Style is ornate.
+
+
+
+% Copyright 2004 by Till Tantau <tantau@users.sourceforge.net>.
+%
+% In principle, this file can be redistributed and/or modified under
+% the terms of the GNU Public License, version 2.
+%
+% However, this file is supposed to be a template to be modified
+% for your own needs. For this reason, if you use this file as a
+% template and not specifically distribute it as part of a another
+% package/program, I grant the extra permission to freely copy and
+% modify this file as you see fit and even to delete this copyright
+% notice. 
+
+
+\mode<presentation>
+{
+  \usetheme[cd2018,noddc,navbar,darktitlepage]{tud}
+  \usecolortheme{tud}
+  % or ...
+
+  %\setbeamercovered{transparent}
+  % or whatever (possibly just delete it)
+}
+
+% notes on 2nd screen:
+\usepackage{pgfpages}
+%\setbeameroption{show notes on second screen}
+
+\usepackage[english]{babel}
+% or whatever
+
+\usepackage{ifluatex}
+
+\ifluatex
+\usepackage{fontspec}
+
+\else
+\usepackage[T1]{fontenc}
+\usepackage[utf8]{inputenc}
+% Or whatever. Note that the encoding and the font should match. If T1
+% does not look nice, try deleting the line with the fontenc.
+\fi
+
+\usepackage{cite}
+
+\title[Pseudonym Schemes in ETSI V2X communication] % (optional, use only with long paper titles)
+{An ETSI look at the State of the Art of pseudonym
+schemes in Vehicle-to-Everything (V2X)
+communication}
+
+\author
+{Oliver Schmidt}
+% - Give the names in the same order as the appear in the paper.
+% - Use the \inst{?} command only if the authors have different
+%   affiliation.
+
+\institute[] % (optional, but mostly needed)
+{
+  Department of Computer Science\\
+  Technical University Dresden
+}
+
+\date[HSTS 2018] % (optional, should be abbreviation of conference name)
+{Hauptseminar Technischer Datenschutz, 2018}
+% - Either use conference name or its abbreviation.
+% - Not really informative to the audience, more for people (including
+%   yourself) who are reading the slides online
+
+\subject{Privacy}
+% This is only inserted into the PDF information catalog. Can be left
+% out. 
+
+
+
+% If you have a file called "university-logo-filename.xxx", where xxx
+% is a graphic format that can be processed by latex or pdflatex,
+% resp., then you can add a logo as follows:
+
+% \pgfdeclareimage[height=0.5cm]{university-logo}{university-logo-filename}
+% \logo{\pgfuseimage{university-logo}}
+
+
+
+% Delete this, if you do not want the table of contents to pop up at
+% the beginning of each subsection:
+%\AtBeginSubsection[]
+%{
+%  \begin{frame}<beamer>{Outline}
+%    \tableofcontents[currentsection,currentsubsection]
+%  \end{frame}
+%}
+
+
+% If you wish to uncover everything in a step-wise fashion, uncomment
+% the following command: 
+
+%\beamerdefaultoverlayspecification{<+->}
+
+
+\begin{document}
+
+\maketitle
+
+
+\begin{frame}{Outline}
+  \tableofcontents
+  % You might wish to add the option [pausesections]
+\end{frame}
+
+
+% Structuring a talk is a difficult task and the following structure
+% may not be suitable. Here are some rules that apply for this
+% solution: 
+
+% - Exactly two or three sections (other than the summary).
+% - At *most* three subsections per section.
+% - Talk about 30s to 2min per frame. So there should be between about
+%   15 and 30 frames, all told.
+
+% - A conference audience is likely to know very little of what you
+%   are going to talk about. So *simplify*!
+% - In a 20min talk, getting the main ideas across is hard
+%   enough. Leave out details, even if it means being less precise than
+%   you think necessary.
+% - If you omit details that are vital to the proof/implementation,
+%   just say so once. Everybody will be happy with that.
+
+\section{Motivation}
+
+\subsection{Intelligent Transport Systems}
+
+\begin{frame}{Intelligent Transportation Systems}{Network Communication for Increased Traffic Safety}
+  % - A title should summarize the slide in an understandable fashion
+  %   for anyone how does not follow everything on the slide itself.
+
+  \begin{columns}
+  \begin{column}{0.47\textwidth}
+
+    \begin{itemize}
+    \item
+        \textbf{Vision Zero}: the aim of having no traffic-related fatalities\note{vision zero: late 90s, aim: no road traffic fatalities}
+    \item
+        includes shifting responsibility to infrastructure\note{paradigm shift}
+    \item
+        communication between safety assistance systems to increase safety
+    \item periodical broadcast of position and proximity
+    \end{itemize}
+  \end{column}
+  \begin{column}{0.5\textwidth}
+    \begin{figure}
+    \includegraphics[width=\textwidth]{figures/eu-fatalities-and-targets-2001-2020.jpg}
+    \nocite{careeuroadaccidentsdatabaseEUFatalitiesTargets}
+    \end{figure}
+    
+  \end{column}
+  \end{columns}
+
+\end{frame}
+
+
+\subsection{ETSI ITS network architecture}
+\begin{frame}{ETSI ITS network architecture}
+
+\begin{columns}
+  \begin{column}{0.49\textwidth}
+
+  \begin{itemize}
+   \item \textbf{E}uropean \textbf{T}elecommunications \textbf{S}tandards \textbf{I}nstitute
+   \item this survey: focus on network technologies used in middle layers:
+      \begin{itemize}
+       \item GeoNetworking for geographical routing
+       \item BTP as transport protocol
+       \item IPv6 encapsulated in GeoNetworking
+       
+      \end{itemize}
+  
+  \end{itemize}
+  \end{column}
+  
+  \begin{column}{0.52\textwidth}
+   \includegraphics[width=\textwidth]{figures/schema_internet_communication.png}
+  \end{column}
+
+\end{columns}
+
+ 
+\end{frame}
+
+\begin{frame}{Intelligent Transportation Systems}{Tracking in Vehicular Networks}
+ \begin{itemize}
+  \item problem: constant communication allows tracking of vehicles
+  \item \textit{linkability} of messages threat to \textit{location privacy}
+  \item linkable identifiers in messages:
+    \begin{itemize}
+     \item vehicle position
+     \item network addresses: IP, GeoNetworking, port numbers
+     \item certificates for message signing\note{for security purposes authenticity of messages needs to be ensured by asymmetric signing}
+     \item StationID
+     \item state residing in message queues, counters, \dots
+     \item message content left out of scope
+     \item \dots
+    \end{itemize}
+    
+ \end{itemize}
+
+\end{frame}
+
+
+\section{Pseudonym Schemes}
+
+\subsection{Pseudonym Schemes for ETSI ITS}
+
+\begin{frame}{Pseudonym Schemes for ETSI ITS}
+
+ 
+\only<2>{\begin{figure}
+ \includegraphics[width=0.7\textwidth]{figures/etsi-pki.png}
+ \end{figure}}
+
+\begin{itemize}
+ \item<1,3-> basic idea: use temporary identifiers, change them periodically \& simultaneously together
+ \item<1,3> pseudonymity while maintaining authentication of vehicle node:
+    \begin{itemize}
+    \item<1,3> divide knowledge about identities within a PKI
+    \end{itemize}
+ \item<3-> crucial operations: pseudonym issuance, use, change, revocation, resolution
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Pseudonym Change}
+ \begin{itemize}
+  \item requirements for an effective change strategy:
+    \begin{itemize}
+     \item other nodes present for ambiguity
+     \item coordinated change
+     \item random change frequency
+     \item all identifiers changed simultaneously, buffers flushed
+    \end{itemize}
+  \item Car-2-Car CC: divide trips into 3 segments
+  \item Silent Periods
+  \item Mix Zones
+ \end{itemize}
+
+\end{frame}
+
+
+
+\subsection{More Advanced Pseudonym Schemes}
+
+\begin{frame}{Advanced Cryptographic Pseudonym Schemes}
+\begin{itemize}
+ \item ETSI standard uses PKI certificate-based pseudonyms
+ \item other approaches: \note{all of them have their challenges}
+    \begin{itemize}
+     \item identity-based cryptography
+     \item group signature schemes
+     \item symmetric MACs
+    \end{itemize}
+
+\end{itemize}
+
+
+\end{frame}
+
+\subsection{Evaluation}
+
+\begin{frame}{Attacker Model}{Characteristics}
+ \center
+ \begin{tabular}{r | l}
+  \textbf{capability} & \\ \hline
+  reach & single-point/ multi-point/ global \\
+  authentication in network & insider/ outsider \\
+  activity & Dolev-Yao (active)/ passive
+ \end{tabular}
+
+\end{frame}
+
+
+\begin{frame}{Resilience Against Attacks}
+\begin{tabular}{l | p{0.6\textwidth} }
+ \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 attacker & resistance against pseudonym depletion (e.g. pseudonym reuse) \\ \hline
+ attacking infrastructure &  frequent cooperative pseudonym change with real silent periods  \\ 
+
+\end{tabular}
+\end{frame}
+
+
+\section{Summary}
+
+\begin{frame}{Summary}
+
+  % Keep the summary *very short*.
+  \begin{itemize}
+  \item
+    ETSI ITS messages contain \alert{many potential linkable identifiers}.
+  \item
+    The \alert{PKI based pseudonym scheme} by ETSI \alert{lacks a change strategy, resilient resolution and advanced cryptography}.
+  \item
+    \alert{Other work} can provide these missing aspects, but \alert{needs to be integrated into the standard}.
+  \end{itemize}
+  
+  % The following outlook is optional.
+  \vskip0pt plus.5fill
+  \begin{itemize}
+  \item
+    Outlook
+    \begin{itemize}
+    \item
+      Expanding and adjusting the ETSI standard.
+    \item
+      Look at linkability in lower network layers or applications.
+    \end{itemize}
+  \end{itemize}
+\end{frame}
+
+
+
+% All of the following is optional and typically not needed. 
+\appendix
+\section<presentation>*{\appendixname}
+\subsection<presentation>*{For Further Reading}
+
+\begin{frame}[allowframebreaks]
+  \frametitle{References}
+    
+  
+  
+    \bibliographystyle{IEEEtran}
+    \bibliography{mybib}
+   
+\end{frame}
+
+\begin{frame}
+ 
+ \center\huge{Thank you for your attention!}
+ 
+ \includegraphics[height=0.5\textheight]{figures/nomnompingu.png}\tiny\footnote{CC-BY-SA 3.0 by Elektroll}
+ 
+\end{frame}
+
+
+\end{document}
+
+

talk_notes.md

@@ -0,0 +1,72 @@
+% notes ITS talk
+
+- quite a long title, so let's 1st talk about ITS before we get to the Pseudonym Schemes
+
+## ITS
+
+- road traffic is still dangerous part of our everyday lives
+- infrastructure assist safety
+- recent years: decrease of traffic deaths
+- probably also thanks to assistance systems
+    - currently working on their own
+- collaboration, proactively broadcast, communicate
+
+- multiple standardization groups working on it
+- survey focuses on middle layers
+- GN: geograhical ad-hoc routing, broadcast unicast multicast
+
+- constant communication, linkability
+- location privacy: deriving location patterns of a single user
+- authorized senders: message signing
+
+## pseudonym schemes
+
+- proposed solution: pseudonyms
+    - must not be linkable
+- we only want authorized vehicles to communicate
+
+- a priori trusted: RootCA
+- EA knows vehicle ID & public key
+- AA trusts valid EA certificates
+- pseudonym resolution: desirable for law enforcement agencies
+
+## pseudonym change
+
+- many strategies have been proposed
+- C2C CC: statistical values:
+    - shall achieve that locations significant to a user can't be linked together nor to the user
+    - 0.8-1.5km, then each 0.8km or 2-6min
+- vehicle-centric change strategies: depending on mobility, trajectory
+- density-based
+- cryptographic mix zones: symm. key from RSU
+    - safety of collision avoidance systems
+
+### advanced schemes
+
+- identity-based:
+    - advantage: no certificates needed as ID = key
+    - disadvantage: splitting mapping information hard, Trusted Authority involved in key derivation
+- group signature:
+    - all members of group can sign for same public key
+    - problems: group leader, group change -> re-setup of all group keys
+- symmetric MACs:
+    - less computation overhead
+    - but not really practically usable, as signature checking is done by 3rd parties
+
+## attacker model
+
+- single-point:
+    - communication with EA and AA encrypted, C2C 3 segments (reception range)
+    - no cooperative change needed
+- global passive:
+    - cooperative change
+    - cryptographic mix zones sufficient
+- active: pseudonym depeltion
+- active insider:
+    - real silent periods needed, crypto mix zones don't work anymore
+    - servers in the internet can't link IPv6 address thanks to stateless autoconfiguration
+- special attacks:
+    - pseudonym depletion attack
+    - sybil attack
+- privileged: accountability, resolution
+    -  needs independent judicial systems and separation of powers