finished (1st attempt) overview about EA and AA ETSI pseudonyms

glossary.tex

@@ -1,49 +1,26 @@
-\begin{acronym}[GN6ASL]
-
 \acro{AA}{Authorization Authority}
-
+\acro{AT}{Authorization Ticket}
 \acro{AU}{Application Unit}
-
 \acro{BTP}{Basic Transport Protocol}
-
 \acro{CA}{Certificate Authority}
-
 \acro{CCU}{Communication \& Control Unit}
-
+\acro{CRL}{Certificate Revocation List}
+\acro{CTL}{Certificate Trust List}
 \acro{EA}{Enrolment Authority}
-
 \acro{ETSI}{European Telecommunications Standards Institute}
-
-\acro{GN}{GeoNetworking}
-
 \acro{GN6ASL}{GeoNetworking to IPv6 Adaptation Sub-Layer}
-
+\acro{GN}{GeoNetworking}
 \acro{GNSS}{Global Navigation Satellite System}
-
 \acro{GVL}{Geographical Virtual Link}
-
 \acro{IPv6}{Internet Protocol version 6}
-
 \acro{ITS}{Intelligent Transportation Systems}
-
-\acro{LS}{GeoNetworking Location Service}
-
 \acro{LLC}{Logical Link Control}
-
+\acro{LS}{GeoNetworking Location Service}
 \acro{LT}{GeoNetworking Location Table}
-
 \acro{MAC}{Medium Access Control}
-
 \acro{OBU}{On-Board Unit}
-
 \acro{OSI}{Open Systems Interconnection}
-
 \acro{RA}{Router Advertisement}
-
 \acro{RSU}{Road-Site Unit}
-
-\acro{VANET}{Vehicular Ad-Hoc Network}
-
 \acro{V2X}{Vehicle-to-Everything}
-
-\end{acronym}
+\acro{VANET}{Vehicular Ad-Hoc Network}

main.tex

@@ -1,4 +1,4 @@
-\documentclass[10pt,conference,twocolumn,final]{IEEEtran}
+\documentclass[10pt,conference,twocolumn,final,a4paper]{IEEEtran}
 
 \usepackage{ifluatex}
 \ifluatex
@@ -157,6 +157,13 @@ 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} utilising 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.
 
+\begin{figure}
+ \includegraphics[width=0.49\textwidth]{figures/schema_internet_communication.png}
+ \caption{Components of an ITS network, communicating with the internet; source: \cite{sandonisVehicleInternetCommunications2016}}
+ \label{schema_internet_components}
+\end{figure}
+
+
 The protocol architecture of \ac{ITS} stations according to the \ac{ETSI} reference architecture \cite{europeantelecommunicationsstandardsinstituteetsiETSI3026652010} is mostly based on the well-known \ac{OSI} layer model.  
 
 \begin{figure}
@@ -273,16 +280,48 @@ There are no obvious identifiers specified in the Facilities layer, though some
 
 \section{Pseudonym 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.
+
+This is a clear threat to the vehicle user's privacy. Complete anonymity of all network participants is no viable countermeasure, as security critical systems like these require certain levels of authenticity of data and accountability of the participants. Furthermore, request-response message schemes require at least short-term linkability of messages to establish a mutual session.
+
+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}
 
-\subsection{Pseudonym Change Strategies}
+\nocite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}The \ac{ETSI} standard on trust and privacy management \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022012} mentions the goal of pseudonymity and unlinkability of \ac{ITS} nodes and their messages as the way to achieve ITS privacy.  This privacy goal is subdivided into two dimensions:
+
+The \textbf{privacy} of ITS registration and authorisation shall be achieved by limiting the knbowledge of a node's canonical (fixed) identifier to a limited number of authorities. Furthermore, the responsibility for verifying the validity of a canonical identifier is given to an \acf{EA} and split from the authorisation to services by the \acf{AA}.  These both authorites need to be operated in different areas of control to achieve a surplus of privacy.\\
+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},
+ \item a public key
+ \item a network address
+ \item a set of trusted \ac{EA} and \ac{AA} certificates
+\end{itemize}
+The \ac{EA} has to hold the following information about a node: The permanent canonical identifier, its enrolment 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 enrolment 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 enrolment certificate and the requesting identity.  The enrolment certificate contains a pseudonymous identifier being signed with a certificate chain leading back to the originating \ac{EA}.
+This enrolment 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.  \\
+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.
+
+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 differnt kinds of \acp{AT}:  Those used by official role vehicles (e.g. state authorities) and \ac{ITS} infrastructure don't 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.\todo{restrict this only to services where this is really necessary}  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 enrolment 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 organisatorial 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.
+
+For \textbf{revocation} of node access to the \ac{ITS} network, e.g. in case of misbehaviour, there exist multiple mechanisms:  The \ac{EA} can be told to revoke the node's enrolment credentials to prevent it from updating its enrolment certificate and thus acquiring further \acp{AT}.  Additionally, the \ac{EA} revokes the validity of the enrolment certificate and the \ac{AA} does the same for the authorization tickets. As ITS nodes are expected to check the validity of certificates using \acfp{CRL} and \acfp{CTL} \cite{europeantelecommunicationsstandardsinstituteetsiETSITR1032018}, messages of the revoked node are not accepted anymore.
 
 \subsection{Further Pseudonym Techniques}
 
+\subsection{Pseudonym Change Strategies}
+
 \section{Evaluation}
 
 \subsection{Attacker Model}
 
+The trust assumptions of the ETSI ITS security services architecture are layed out in section 6.2.5 of \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}.
+\todo{sybil attack}
+
 \section{Summary}
 % % % 
 % Theory (probably)
@@ -310,7 +349,9 @@ There are no obvious identifiers specified in the Facilities layer, though some
 
 \nobreak
 
+\begin{acronym}[GN6ASL]
 \input{glossary.tex}
+\end{acronym}
 
 \bibliographystyle{IEEEtran}
 \bibliography{mybib}