finished (first attempt) section on further pseudonym schemes

glossary.tex

@@ -12,16 +12,20 @@
 \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{IPv6}{Internet Protocol version 6}
 \acro{ITS}{Intelligent Transportation Systems}
 \acro{LLC}{Logical Link Control}
 \acro{LS}{GeoNetworking Location Service}
 \acro{LT}{GeoNetworking Location Table}
 \acro{MAC}{Medium Access Control}
+\acro{MITM}{Man-in-the-Middle}
 \acro{OBU}{On-Board Unit}
 \acro{OSI}{Open Systems Interconnection}
 \acro{PKI}{Public Key Infrastructure}
 \acro{RA}{Router Advertisement}
 \acro{RSU}{Road-Site Unit}
+\acroindefinite{RSU}{an}{a}
+\acro{TA}{Trusted Authority}
 \acro{V2X}{Vehicle-to-Everything}
 \acro{VANET}{Vehicular Ad-Hoc Network}

main.tex

@@ -158,7 +158,7 @@ A \ac{VANET} consists of different kinds of ITS stations: \\
 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}
+ \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}
 \end{figure}
@@ -303,7 +303,7 @@ 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.  \\
+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.
 
 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.\\
@@ -318,12 +318,62 @@ For \textbf{revocation} of node access to the \ac{ITS} network, e.g. in case of
 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}.
 
-\subsection{Further Pseudonym Scheme Techniques}
-
 \subsection{Pseudonym Change Strategies}
 
+\subsection{Further Pseudonym Scheme Techniques}
+
+Petit et al. made an extensive survey \cite{petitPseudonymSchemesVehicular2015} of cryptographic approaches for pseudonym schemes and defined a representative pseudonym life-cycle for comparing the different approaches.  
+
+\subsubsection{Certificate-based Pseudonyms}
+
+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.  \\
+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.
+
+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 complicate, both regarding infrastructure requirements and legal and organisational frameworks.
+
+\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 is 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.  \\
+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.
+
+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. \todo{what about encryption, can every group member decrypt?}  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.
+
+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.
+
+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.  
+
+As an advantage of these schemes, nodes don't 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.
+
+A special kind of group signature schemes not requiring setup and being more dynamic are \textit{ring signture schemes}.  Their usage is only briefly covered in \cite{petitPseudonymSchemesVehicular2015}.
+
+\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.  \\
+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.
+
+There are some attempts of getting rid of the issues.  The TESLA protocol \cite{perrigTESLABroadcastAuthentication} for example manages to reduce the infrastructure dependance by revealing previous signature keys using beaconing messages.  This approach still suffers from high latency times though.
+
 \section{Evaluation}
 
+\todo{revocation: how to distribute CRLs in distributed systems? passive revocation: short lifetimes, prevent refill}
+
 \subsection{Attacker Model}
 
 The trust assumptions of the ETSI ITS security services architecture are layed out in section 6.2.5 of \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}.

mybib.bib

@@ -480,4 +480,35 @@
   howpublished = {Internet Requests for Comments}
 }
 
+@article{armknechtCrosslayerPrivacyEnhancement2007,
+  title = {Cross-Layer {{Privacy Enhancement}} and {{Non}}-Repudiation in {{Vehicular Communication}}},
+  abstract = {We propose a security architecture that provides two funda- mental security services for VANETS: i) non-repudiation and ii) privacy enhancement. Due to a new PKI concept, referred to as PKI+, users are autonomous in deriving public keys, certificates and pseudonyms which minimizes the communication to the certificate authority. Security tech- niques are supported on all layers of the protocol stack. In particular we show how to link the PKI+ concepts to solutions for routing in vehicle- to-vehicle and vehicle-to-infrastructure communication.},
+  author = {Armknecht, Frederik and Festag, Andreas and Westho, Dirk and Zeng, Ke},
+  month = jan,
+  year = {2007},
+  file = {/home/spiollinux/Zotero/storage/PEH6YJAF/Armknecht et al. - 2007 - Cross-layer Privacy Enhancement and Non-repudiatio.pdf}
+}
+
+@inproceedings{calandrielloEfficientRobustPseudonymous2007,
+  address = {New York, NY, USA},
+  series = {VANET '07},
+  title = {Efficient and {{Robust Pseudonymous Authentication}} in {{VANET}}},
+  isbn = {978-1-59593-739-1},
+  doi = {10.1145/1287748.1287752},
+  booktitle = {Proceedings of the {{Fourth ACM International Workshop}} on {{Vehicular Ad Hoc Networks}}},
+  publisher = {{ACM}},
+  author = {Calandriello, Giorgio and Papadimitratos, Panos and Hubaux, Jean-Pierre and Lioy, Antonio},
+  year = {2007},
+  keywords = {security,vehicular networks,performance,reliability},
+  pages = {19--28}
+}
+
+@article{perrigTESLABroadcastAuthentication,
+  title = {The {{TESLA Broadcast Authentication Protocol}}${_\ast}$},
+  language = {en},
+  author = {Perrig, Adrian and Canetti, Ran and Tygar, J D and Song, Dawn},
+  pages = {12},
+  file = {/home/spiollinux/Zotero/storage/HJETVNIF/Perrig et al. - The TESLA Broadcast Authentication Protocol∗.pdf}
+}
+