finished pseudonym scheme section by finishing section on pseudonym change schemes
This commit is contained in:
parent
7579cd6e3c
commit
e632cf752a
33
main.tex
33
main.tex
|
@ -276,7 +276,11 @@ While each IPv6-capable network interface can have multiple addresses, it has at
|
||||||
There exists a static mapping between IPv6 multicast groups and geographical areas (relative to the station). That means it is possible to contact IPv6-based services within a node's surrounding. But as this mapping is static and relative, it shouldn't help reidentifying hosts.
|
There exists a static mapping between IPv6 multicast groups and geographical areas (relative to the station). That means it is possible to contact IPv6-based services within a node's surrounding. But as this mapping is static and relative, it shouldn't help reidentifying hosts.
|
||||||
\acfp{GVL} are another important concept for understanding the visibility scope of IPv6 packets to other nodes. These virtual links are defined as non-overlapping, restricted geographical areas wherein all IPv6 multicasts within the same subnet are forwarded via \ac{GN} to all nodes of that \ac{GVL}. Usually this is a zone around a specific \ac{RSU} serving as an Internet uplink and thus managing the whole subnet and its addresses. Globally routable IPv6 addresses are usually obtained via the stateless autoconfiguration with the help of \acp{RA}. So changing the \ac{GVL} means getting another IPv6 prefix announced via \ac{RA} and thus implies a change in the node's global IPv6 address.
|
\acfp{GVL} are another important concept for understanding the visibility scope of IPv6 packets to other nodes. These virtual links are defined as non-overlapping, restricted geographical areas wherein all IPv6 multicasts within the same subnet are forwarded via \ac{GN} to all nodes of that \ac{GVL}. Usually this is a zone around a specific \ac{RSU} serving as an Internet uplink and thus managing the whole subnet and its addresses. Globally routable IPv6 addresses are usually obtained via the stateless autoconfiguration with the help of \acp{RA}. So changing the \ac{GVL} means getting another IPv6 prefix announced via \ac{RA} and thus implies a change in the node's global IPv6 address.
|
||||||
|
|
||||||
There are no obvious identifiers specified in the Facilities layer, though some might be introduced in real-world implementations.
|
\subsubsection{Facilities Layer}
|
||||||
|
|
||||||
|
The Facilities layer introduces a \textit{StationID}, an integer identifying the \ac{ITS} system. The standard document \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022014} already mentions that this ID may be a pseudonym.
|
||||||
|
|
||||||
|
Some further identifiers might be introduced in real-world implementations, e.g. for realising certain service over their dedicated protocols.
|
||||||
|
|
||||||
\section{Pseudonym Schemes}
|
\section{Pseudonym Schemes}
|
||||||
|
|
||||||
|
@ -320,6 +324,26 @@ The proposed countermeasure is again the adoption and regular change of pseudony
|
||||||
|
|
||||||
\subsection{Pseudonym Change Strategies}
|
\subsection{Pseudonym 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. \\
|
||||||
|
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 probably that only 1 vehicle changes pseudonyms within a short time range is very high, making linkage os pseudonyms easy again. \\
|
||||||
|
A last example so far: Focusing on one vehicle, let us assume it changes its pseudonym in a perfectly ambiguosly way which can't be linked to the old one reliably. But after the pseudonym change, an alredy enqueued packet is sent, containing identifiers linkable to the preious 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 \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-legth \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 ingoing 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 sychronously. The efficiency of that apporach 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}
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 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 collison 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.
|
||||||
|
|
||||||
\subsection{Further Pseudonym Scheme Techniques}
|
\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.
|
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.
|
||||||
|
@ -333,11 +357,13 @@ Calandriello et al. \cite{calandrielloEfficientRobustPseudonymous2007} combine t
|
||||||
|
|
||||||
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.
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
\subsubsection{Identity-based Cryptographic Pseudonyms}
|
\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. \\
|
\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. \\
|
||||||
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.
|
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.
|
As the public key is directly derivable from the destination address of messages, a \ac{MITM} relay-interception is prevented.
|
||||||
|
@ -378,6 +404,7 @@ There are some attempts of getting rid of the issues. The TESLA protocol \cite{
|
||||||
|
|
||||||
The trust assumptions of the ETSI ITS security services architecture are layed out in section 6.2.5 of \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}.
|
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{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}
|
\section{Summary}
|
||||||
% % %
|
% % %
|
||||||
|
|
20
mybib.bib
20
mybib.bib
|
@ -511,4 +511,24 @@
|
||||||
file = {/home/spiollinux/Zotero/storage/HJETVNIF/Perrig et al. - The TESLA Broadcast Authentication Protocol∗.pdf}
|
file = {/home/spiollinux/Zotero/storage/HJETVNIF/Perrig et al. - The TESLA Broadcast Authentication Protocol∗.pdf}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@book{CommunicationTechnologiesVehicles2016,
|
||||||
|
address = {New York, NY},
|
||||||
|
title = {Communication Technologies for Vehicles},
|
||||||
|
isbn = {978-3-319-38920-2},
|
||||||
|
language = {en},
|
||||||
|
publisher = {{Springer Berlin Heidelberg}},
|
||||||
|
year = {2016},
|
||||||
|
file = {/home/spiollinux/Zotero/storage/PPCVTWVT/2016 - Communication technologies for vehicles.pdf}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{verheulIssueFirstActivate,
|
||||||
|
title = {Issue {{First Activate Later Certificates}} for {{V2X}}},
|
||||||
|
abstract = {We specify Issue First Activate Later (IFAL). This is an ETSI [11] type of V2X Public Key Infrastructure based on short-lived pseudonymous certificates without Certificate Revocation Lists. IFAL certificates are valid in the future but can only be used together with periodically provided activation codes. IFAL supports controlled de-pseudonymization enabling provisioning to stop for misbehaving vehicles. IFAL allows for flexible policies, trade-offs between three essential V2X properties: trust, privacy and usability. IFAL activation codes are small and can be sent in an SMS, through roadside equipment or even broadcasted. Like the Butterfly scheme [32], IFAL uses key derivation with one base private/public key pair. However in IFAL the security module can be simple as it can be kept oblivious of key derivation.},
|
||||||
|
language = {en},
|
||||||
|
author = {Verheul, Eric R},
|
||||||
|
keywords = {pseudonyms},
|
||||||
|
pages = {28},
|
||||||
|
file = {/home/spiollinux/Zotero/storage/7BUPIGNJ/Verheul - Issue First Activate Later Certificates for V2X.pdf}
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue