implementing changes according to supervisor feedback

main.tex

@@ -257,7 +257,7 @@ Some further identifiers might be introduced in real-world implementations, e.g.
 
 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, 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 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.
 
@@ -272,8 +272,6 @@ During manufacture the following data is to be stored in an ITS node using a phy
 \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 enrollment credentials, its public key and a link to further profile information.  
@@ -281,8 +279,15 @@ ITS nodes can now request an enrolment certificate with their enrolment credenti
 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.  \\
 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.
 
+\begin{figure}
+ \includegraphics[width=0.48\textwidth]{figures/etsi-pki.png}
+ \caption{\ac{ETSI} \ac{ITS} \ac{PKI} trust model; source: \cite{europeantelecommunicationsstandardsinstituteetsiETSITR1032018}}
+ \label{fig:pki}
+\end{figure}
+
+
 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 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 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.
 
 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.
 
@@ -330,11 +335,13 @@ When it comes to enhancing the privacy of pseudonym resolution, several approach
 
 The IFAL protocol \cite{verheulIssueFirstActivate} introduces a mechanism tackling the issue of pseudonym refill:  Pseudonym certificates can be distributed in big numbers already well in advance, as they are in principal valid in the future, but only if activated with periodically distributed activation codes.  This is possible even over bad connections, SMS messages or via broadcasts as the codes are not confidential, but requires more storage space for the unactivated certificates.
 
-The clear advantage of this class of schemes is the applicability for 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.
+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.
+
+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.
 
 \subsubsection{Identity-based Cryptographic Pseudonyms}
 
-\textit{Identity-based cryptography} is a form of asymmetric cryptography where a node's identifier (i.e. network interface and protocol address) serves as a nodes public key.  A private key has to be derived from that public-key-id, this is usually done by a central \ac{TA} which has additional secret parameters to prevent that any node would be able to do this derivation.  Some of the parameters are published and required for verifying message signatures.   This \ac{TA} can then also retain identity-mapping information, but doesn't distribute these mappings over multiple authorities.  Revocation of pseudonyms can work similarly to the classical certificate-based scheme by revoking the canonical registration identifier of a node.  The lifetime of pseudonyms can also be limited by adding an additional timestamp to the identifier string before deriving the private key from it.  In theory revocation of certain pseudonyms could also be done by distributing revocation lists, but this has the same scalability issues like it has with certificates.  \\
+\textit{Identity-based cryptography} is a form of asymmetric cryptography where a node's identifier (i.e. network interface and protocol address) serves as a nodes public key.  A private key has to be derived from that public-key-id, this is usually done by a central \ac{TA} which has additional secret parameters to prevent that any node would be able to do this derivation.  Some of the parameters are published and required for verifying message signatures.   This \ac{TA} can then also retain identity-mapping information, but doesn't distribute these mappings over multiple authorities.  Revocation of pseudonyms can work similarly to the classical certificate-based scheme by revoking the canonical registration identifier of a node.  The lifetime of pseudonyms can also be limited by adding an additional timestamp to the identifier string before deriving the private key from it.  In theory revocation of certain pseudonyms could also be done by distributing revocation lists, but this has the same scalability issues like it has with certificates (see evaluation in \ref{sec:evaluation}).  \\
 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.  
@@ -399,6 +406,8 @@ The change strategy proposed by the Car-2-Car Communication Consortium defined i
 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.  \\
 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.
 
+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}.
+
 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}.