diff --git a/main.tex b/main.tex index 1289dd5..c0489a2 100755 --- a/main.tex +++ b/main.tex @@ -256,8 +256,6 @@ The signer information can be given in form of a digest, certificate or certific The security trailer contains a signature for verifying authenticity and integrity of the message. -\todo{sequence number initialized with 0} -\todo{packet buffers: LS, forwarding} \subsubsection{BTP} @@ -308,7 +306,7 @@ This enrollment certificate can then be used to get \acfp{AT} from an \ac{AA}. 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 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.\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. +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. 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. @@ -325,13 +323,13 @@ A crucial parameter of pseudonym schemes has been left out so far: How and when Another example: Let us look at a traffic jam with 10 cars standing within reception range of an observer. Now there are multiple cars around making the mapping of pseudonyms to cars not totally trivial. But if we assume that each car only changes pseudonyms every 24 hours and does this at an arbitrary time, the probability that only 1 vehicle changes pseudonyms within a short time range is very high, making linkage of pseudonyms easy again. \\ A last example so far: Focusing on one vehicle, let us assume it changes its pseudonym in a perfectly ambiguously way which can't be linked to the old one reliably. But after the pseudonym change, an already enqueued packet is sent, containing identifiers linkable to the previous pseudonyms. -These examples already show important points to take care of when changing pseudonyms: There needs to be some ambiguity regarding which node changed to which pseudonym – there shall be other nodes present within the reception range, coordination and frequency of change matter, and all identifiers need to be changed simultaneously with buffers being flushed or discarded. +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. 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. 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. \\ -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.\todo{insiders, infrastructure tracking} +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. @@ -339,7 +337,7 @@ The \ac{ETSI} survey \cite{europeantelecommunicationsstandardsinstituteetsiETSIT 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 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. -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. \todo{who can trigger this locking?} 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. +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. \subsection{Further Pseudonym Scheme Techniques}\label{sec:further-schemes} @@ -371,7 +369,7 @@ With the \ac{TA} being involved in deriving the public key, pseudonym refill alw \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. +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. 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. @@ -399,7 +397,6 @@ There are some attempts of getting rid of the issues. The TESLA protocol \cite{ 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. -\todo{revocation: how to distribute CRLs in distributed systems? passive revocation: short lifetimes, prevent refill} \subsection{Attacker Model} @@ -429,19 +426,24 @@ For this to work, pseudonym refill needs to be obstructed, e.g. by preventing th 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. \\ 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. +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. + 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}. \subsection{Influence of Pseudonyms on Performance} +\todo{revocation: how to distribute CRLs in distributed systems? passive revocation: short lifetimes, prevent refill} + distribution of CRLS; revocation - frequent pseudonym change - flushing queues: not all, e.g. LS should be safe +\todo{packet buffers: LS, forwarding} + The trust assumptions of the ETSI ITS security services architecture are layed out in section 6.2.5 of \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}. -\todo{sybil attack} \todo{prevent linking multiple segments from same location: area big enough; prevent linking same pseudonym at multiple points: time short enough} \section{Summary}