Harmonized Group Mix for ITS

Mirja Nitschke

, Christian Roth

, Christian Hoyer and Do

gan Kesdo

gan

University of Regensburg, Regensburg, Germany

Keywords:

V2V Communication, Mix, Privacy, k-Anonymity, ITS.

Abstract:

Vehicle-to-Vehicle (V2V) communication is crucial for almost all future applications in the context of smart

trafﬁc, such as autonomous driving. However, while current standards like WAVE provide a technical platform

for communication and management, they lack aspects of privacy for their participants. In this paper, we

introduce a Harmonized Group Mix (HGM), an architecture suited to exchange information in ITS, compatible

with current standards. HGM does not rely on expensive Road-Side-Units (RSUs) or complex organizational

relationships to introduce a trust anchor but is built on the concept of peer-to-peer networks. Hence, our

proposal does not require any changes to current environments and is eventually easy to deploy in the real

world. Our proposed method provides k-anonymity using group signatures and splits trust between multiple

parties. At the same time, the integrity of the system is preserved. We evaluate our approach using the

simulation framework Veins. Our experiments show that HGM is feasible from a performance and privacy

perspective in the given context.

1 INTRODUCTION

In the EU and USA, the potential of Vehicle-to-

Vehicle (V2V) communication has been identiﬁed

years ago. With the creation of the CAR 2 CAR Com-

munication Consortium and the Transportation Sys-

tems Committee efforts are being made to standard-

ize communication in this ﬁeld, crucial for global suc-

cess. Existing standards like WAVE provide a modern

platform for V2V communication allowing real time

communication and thus enabling modern use cases,

such as autonomous driving. Data needed for this

kind of application has to be precise, up-to-date, and

most importantly integer. The exact location of every

user must be known at all times in order to provide a

safe and secure environment. This may conﬂict with

interests of privacy of participants. For instance, loca-

tion traces are sensitive because they give insight into

a user’s behavior and daily routine. Current standards

treat privacy interest as an orphan, hence, privacy has

become an issue of interest to science and industry.

Our contribution is an architecture extension for

V2V communication that provides anonymous and

yet authenticated broadcast messages by using the

idea of mix technology to harmonize the appearance

of different messages of miscellaneous users. The

https://orcid.org/0000-0002-2527-6340

https://orcid.org/0000-0002-1668-5441

Harmonized Group Mix (HGM) is designed to be

compatible to current standards. The architecture has

several advantages. First, the organizational structure

is simple, beside the users we only need one other en-

tity. Second, this entity is merely semi-trusted. Third,

we limit cryptographic overhead by only using group

signatures. Fourth, a sender cannot easily be iden-

tiﬁed because the collaboration of several tracing au-

thorities is needed to decrypt the group signature, pro-

viding maximum privacy. We follow the classical ap-

proach of the triple bottom line of security “algorithm,

adversary and evaluation”.

The remainder of this paper is organized as fol-

lows. After a review of related work in Section 2, we

discuss the system model in Section 3. We present our

approach Harmonized Group Mix (HGM) to provide

anonymous and yet authenticated broadcast Messages

in the context of the ITS in Section 4. In Section 5

we evaluate the proposed approach and discuss the re-

sults. Section 6 concludes the paper and names possi-

ble extensions of our approach. A list of notation can

be found in Appendix A.

2 RELATED WORK

The topic of privacy in vehicular ad-hoc networks

(VANETs) has been investigated in various works,

152

Nitschke, M., Roth, C., Hoyer, C. and Kesdo

gan, D.

Harmonized Group Mix for ITS.

DOI: 10.5220/0008989101520163

In Proceedings of the 6th International Conference on Information Systems Security and Privacy (ICISSP 2020), pages 152-163

ISBN: 978-989-758-399-5; ISSN: 2184-4356

for example, (Papadimitratos et al., 2007) focus on

management of identities and cryptographic keys,

(Sampigethaya et al., 2005) concentrate on the possi-

bility of tracking of broadcast communications. (Ca-

landriello et al., 2007) investigate in their archi-

tecture into pseudonym-based authentication, while

(Khodaei and Papadimitratos, 2015) direct their at-

tention towards Vehicular Public Key Infrastructure.

Other interesting approaches are (Alexiou et al., 2013;

Plossl et al., 2006; Laurendeau and Barbeau, 2007).

(Brecht et al., 2018) propose a security credential

system that uses certiﬁcates to balance privacy and

anonmyity. However, they rely on a complex struc-

ture of multiple organizations in contrast to our work.

(Guo et al., 2007) suggest a superﬁcial group sig-

nature based security framework in which the iden-

tity of an individual can be uncovered using only one

other entity. (Verheul, 2016) use short time certiﬁ-

cates where multiple deactivated certiﬁcates are given

to a vehicle during a setup phase. Activation can be

then be performed once a central authority dispatches

activation keys for a speciﬁc certiﬁcate, however, the

vehicle must be connected to the network to receive

the codes. The certiﬁcate holder can change the cer-

tiﬁcate to sign off messages at a given time to protect

himself against location based attacks.

There is also a great deal of literature on archi-

tectures that enable anonymous V2V communication

(Sun et al., 2007; Hao et al., 2008; Xiaonan et al.,

2007; Sampigethaya et al., 2005; Hu et al., 2011;

Zhang et al., 2010). However most of these papers

rely on Road-Side-Units (RSU), which are either au-

tonomous or controlled by a single trusted third party.

We focus in our work on unlinkability between

messages, as previously mentioned. We try to en-

hance the idea of linking single messages not to a spe-

ciﬁc (pseudonymized) entity but to a group of people.

Thus we combine the Mix idea with group signatures

to provide location aware message while not disclos-

ing a speciﬁc identity.

3 SYSTEM MODEL

Our system model is compatible with the typical sce-

nario of an Intelligent Transportation System (ITS).

Vehicles (i.e. users u ∈ U) drive along a road network

in different trajectories and eventually pass other ve-

hicles, most of the time quite quickly. Each vehicle

is inseparably equipped with communication devices

called On-Board-Units (OBUs; see (Papadimitratos

et al., 2007)) that enable them to exchange informa-

tion in an authenticated and unforgeable way. It can

be preloaded with cryptographic material.

In typical ITS scenarios, vehicles have to ex-

change information, thus silent periods are not accept-

able and the ability to send messages must be in place

at all times. Messages are broadcasted within the net-

work and can be relayed by all participants U and/or

external (static) entities such as Road-Side-Units. The

set M describes all messages m ∈ M sent.

Each user u is uniquely identiﬁable via his ve-

hicle ID id(obu) which is inextricably linked to his

OBU. The OBU is responsible for signing off mes-

sages, thus allowing each m to be traced back to u

via id(obu). The information in general is arbitrary,

but is always enriched with a timestamp and a GPS

location due to the nature of an ITS. Since every mes-

sage is traceable to a speciﬁc location it is obvious

that such messages are a threat for a participant’s pri-

vacy. A trajectory of several messages traceable to

a single user provides information about a user’s be-

havior and is thus a sensitive asset that needs to be

protected. Therefore, each participant has an interest

in hiding their true identity in combination with the

originating messages.

3.1 Group Signatures

A feasible approach to provide anonymity is the us-

age of group signatures, which were ﬁrst presented in

(Chaum and Van Heyst, 1991) and were extended by

(Chen and Pedersen, 1995; Boneh et al., 2004; Lin

et al., 2007; Camenisch, 1997). Group signatures al-

low members of a group to sign messages on behalf

of the entire group. They are veriﬁable with a single

public veriﬁcation key associated to the group as a

whole. Afterwards, nobody can identify the origina-

tor of that signature or link signed messages of the

same originator, except for a tracer authority hold-

ing a special opening key. A second role, called

group leader, distributes signing keys along all mem-

bers. Furthermore, next to anonymity and traceabil-

ity, group signatures provide non-frameability and un-

forgeability, essential building blocks for a vehicular

communication protocol. In particular, we select a

scheme providing the following functionality:

• Users may join a group after it has been created

(dynamic groups).

• A group leader must not be the only tracer (two

authorities).

• The ability to identify the originator of a message

has to be split across multiple entities (distributed

tracers).

• No central key distributing agency or any other

similar trusted third party.

Harmonized Group Mix for ITS

153

• CCA-full-anonymous (Fischlin, 2005) properties

against insider attacks since every vehicle can be

a potential attacker.

• Very short signatures due to limited packet size

(around 1024 byte) while providing enough space

left for payload.

Such a protocol can be realized using the group signa-

ture scheme by (Bl

omer et al., 2016) which is based

on work from (Boneh et al., 2004) and extends it

to provide distributed traceability. Furthermore, we

adapt (Delerabl

ee and Pointcheval, 2006) to feature

dynamic groups.

3.2 Mix

A viable approach to anonymize the communication

between two users is the Mix Network introduced in

(Chaum, 1981). Presented simply, a Mix is a chain of

nodes that a message has to pass from a user to its des-

tination. A Mix collects several messages from dif-

ferent people which have been multi-layer encrypted

by the originator using known asymmetric keys of all

Mix nodes in the chain. Then each Mix node de-

crypts the respective layer of the message using its

private key and thus changes the message’s appear-

ance. It now issues all messages in changed order and

the next Mix node performs the same operation un-

til the message reaches its destination. Thereby an

eavesdropper can not link incoming to outgoing mes-

sages in the system due to changes in shape and or-

der. We pick up this idea, by harmonizing the ap-

pearance of several messages from different users by

using group signature encryption. Because the users

act themselves as mix, see Figure 1, nobody sees the

incoming messages and the mix does not have to col-

lect various messages. Instead an attacker can only

link a message to a group of users and not to a single

user.

3.3 Attacker

All participants are considered to be honest-but-

curious, i.e. they respect each protocol step but want

to gain more knowledge about others. Given that, the

attacker in our system is typically anyone who can

actively interact with the system like replaying mes-

sages. Thus we require CCA full-anonymity. As a

consequence each user is able to collect messages dis-

tributed in the system and store them in a message log

M . The attacker’s main goal is to link multiple mes-

sages m to a user u, however a user may use different

pseudonyms π at the same time to craft messages m.

In the end, the attacker can then use the log of col-

lected messages

M and his knowledge about his own

behavior along with π and to build a full location tra-

jectory of a user u.

For our setup, we assume that the attacker knows

all system parameters. This results in an even more

severe threat to stress our algorithm. He starts his at-

tack to link messages to user and derive information

about that participant’s driven path. However, as men-

tioned, it is very resource intensive for an attacker to

gain access to multiple OBUs, hence, we assume that

he is unable to control a big part of the network. We

do not focus on approaches to validate a message’s

content (i.e. the substance) in this work. One can, for

example, rely on (Chen et al., 2011) for that. How-

ever, we provide a method to reveal the originator of

a message.

3.4 WAVE

This section presents a brief derivation of re-

quirements for our approach on the basis of the

IEEE 802.11p standard and the IEEE 1609 extension.

Together they are collectively called WAVE (Wire-

less Access for Vehicular Environments) (IEEE 1609

Working Group, 2017). In order to exchange infor-

mation, participants form a WAVE Basic Service Set

(WBSS, c.f. IEEE 1609.3) for the organization of our

anonymity groups (see (Uzcategui et al., 2009)).

The IEEE 1609.4 standard features multichannel

operation over WAVE PHY and MAC layers. It pro-

vides a control channel (CCH) and 6 service channels

(SCH) usable by different applications. Each chan-

nel has different characteristics regarding maximum

transmit power or frequency depending on the appli-

cation requirements. Depending on the speed of a

vehicle, packet loss and bandwidth may vary (Bilgin

and Gungor, 2013). Due to its safety-critical property,

the control channel is best suited for stable and longer

range communication in the urban context (Gr

aﬂing

et al., 2010). Thus, we derive the following require-

ments: communication exchange on SCHs should be

minimal and must be completed while vehicles are in

close range. The protocol shall be as efﬁcient and ro-

bust as possible.

4 HARMONIZED GROUP MIX

We now introduce Harmonized Group Mix (HGM)

for ITS. Our approach combines ideas from Mixes

to change the shape of a message, i.e. harmonizing

them, with group signatures to dynamically build new

Mix groups.

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

154

User

Group

User

Group

Figure 1: White- and Blackbox view on the Mix groups

each producing harmonized messages unlinkable to the

originator. Because every user operates his own Mix node

the group does not need to communicate after exchanging

the group keys.

User

Group Leader

Tracer

LEA

Key-

Directory

User-

List

Blame-

List

User

Group

Figure 2: A organizational overview of HGM’s entities and

roles.

4.1 High Level Overview

HGM only relies on two basic entities to balance

anonymity and integrity and is therefore signiﬁcantly

less complex than other approaches. Next to all users,

a semi trusted third party called Law Enforcement

Agency (LEA), managing a userlist containing U, is

present. Figure 2 illustrates all entities and relation-

ships. Each user can own multiple roles in the system.

In general, there is no need to attach personally

identiﬁable information to a message or restrict any

access to it at all. However, in real world scenarios

it is likely that dishonest users try to attack the sys-

tem by e.g. ﬂooding it with bogus information. This

is in particular true for the open nature of V2V archi-

tectures where dishonest users are eventually present.

Thus, countermeasures to exclude such users from

a system are needed; potential threats are discussed

later on in section 4.4.

HGM uses separation of duties to isolate a user’s

activity from his identity. Messages are not directly

linkable to a user u or his respective pseudonym π

but to arbitrary groups g

∈ G. A group is managed

by another user (called group leader l(g

) = π

with

being the group leader’s pseudonym) who is re-

sponsible for creating groups or adding new members

while preventing the need for a trusted third party. All

messages from a group are harmonized, i.e. identiﬁ-

able information to a user is obfuscated. Hence, every

member of a group may be the originator of a message

making it hard for an adversary to gain any additional

information about a user. To further distribute power

this obfuscation can only be removed if the majority

𝑔

𝜋

𝑡

𝜋

Join

Lazy

Join

Pseudonym lifetime

Δ𝑡

𝐺,𝑣

Δ𝑡

𝐺,𝑖

Δ𝑡

𝐺,𝑐

Figure 3: Process ﬂow of HGM. A user holds multiple

pseudonyms π which he uses to participate in different

groups g. Each message (rectangle, circle, plus) is only

linkable to a group but not the pseudonym. A user can se-

lect a pseudonym to join multiple groups at once even his

own enhancing anonymity.

of a user group (called tracers) agrees. After sending

a message, it is impossible for an receiver to tell the

originator of a message since all messages have been

mixed within the group. Messages are crafted locally

in a user’s domain using their private group key (see

Figure 1) because only the local vehicle is assumed to

be fully trusted.

In contrast to existing approaches, no silent peri-

ods are needed when changing from one π to another

since a user holds multiple πs and is always member

in multiple groups. Figure 3 shows an except of the

lifetime of a single user u. He can use every π ∈ Π

during its pseudonym lifetime to join groups at any

time as long as they are accepting new users (up to

∆t

G,i

after creation). He can then randomly use each

joined group to craft messages breaking up a poten-

tial location trajectory. Groups also have a speciﬁc

lifetime of ∆t

G,v

to ensure that expired or blocked

pseudonyms are not able to send messages anymore.

As a consequence messages from such groups are dis-

carded upon reception. A new group can be formed at

any time but has to be completed within ∆t

G,c

4.2 Roles

Our approach uses different entities to separate

knowledge and control. Communication between

these different entities should be minimized, not only

because of the performance aspect but also because of

anonymity.

Law Enforcement Agency (LEA): Managed, for in-

stance, by the government, LEA keeps track of all

U and acts as a doorkeeper. She is a semi-trusted

party since all users trust authenticated entities from

her. LEA is not considered and needed to be fully

trusted, since she can only detect that users want to

participate, but is unable to gain any knowledge about

their activity. This is important since this entity rep-

Harmonized Group Mix for ITS

155

resents a global attacker in the honest-but-curious at-

tacker model. For example, the LEA is interested in

the GPS trajectory of a speciﬁc OBU – something

HGM targets to protect against.

Participant: A user becomes a participant when

he has an entitled OBU allowing him to interact with

the system. It is the most basic role in our system.

Participants can use multiple signed pseudonyms π

to enroll in dynamically created anonymity groups.

Only participants in a group can create messages. A

user’s permission to be a participant is controlled by

LEA.

Group Leader: Since anonymity in our system is

achieved by organizing multiple and unique partici-

pants in groups, there has to be a managing entity

called group leader. A group leader is responsible

for managing groups including key distribution, al-

though, he is not needed during crunch time. Further-

more, the group leader does not gain any additional

knowledge about his group participants except know-

ing which pseudonym has joined with what role. He

is unable to tell if different signed pseudonyms point

to the same id(obu).

Tracer: Because any group member can create

valid messages on the behalf of his anonymity group,

the whole group is to blame in the case of, for ex-

ample, forged messages. Therefore the system allows

to reveal the real identity of the originator. We split

the ability to map m → π between multiple, randomly

chosen group members, called tracers. A speciﬁc per-

centage of these tracers has to work together to reveal

a message originator. Thus, they are accountable for

the integrity of the whole group including their own

messages.

4.3 Protocol

We now present an in depth look into the protocol.

Communication between users is done via V2V com-

munication channels (e.g. WAVE) while information

between LEA is exchanged and directory lookups are

performed out-of-band, for instance via LTE support-

ing higher ranges and bandwidth. In Figures 4 to 6 we

denote out-of-band communication using - before the

entity.

Notation. c, d denote a public private key pair

used supporting encryption+decryption and sign-

ing+verifying. A group g of n members is denoted as

, . . . , u

∈ g where g holds a subset U

of all users

U and all groups G. |U

| deﬁnes the number of mem-

bers in that group. As mentioned in Section 3.1, we

use group signatures by (Bl

omer et al., 2016) with the

stated extension. For the sake of simplicity, we do not

list all parameters of that group signature scheme but

only name additions needed for HGM. If stated, X and

Y always denote parameters for the group signature

scheme.

4.3.1 Initialization of the System

HGM provides anonymity i.a. through pseudonyms.

These pseudonyms are derived from a users id(obu)

in a reversible way to protect integrity. However, un-

veiling those shall only be possible by LEA. Request-

ing pseudonyms may be upstreamed so that problems

with unreliabe long-range communication can be mit-

igated.

To request an authenticated pseudonym, a user

sends a PSEUDOSIGNREQUEST(4) to LEA using

a user generated signing payload 4 = {id(obu) k

{0, 1}

}

LEA

, zk with k random bits. LEA is then re-

sponsible for signing the 4 and thus conﬁrming the

rightful participation of the user. LEA responds with

a PSEUDOSIGNSUCCESS({4, ts}

LEA

) using the in-

put from the PSEUDOSIGNREQUEST. We call the

payload of that response π created at timestamp ts.

However, LEA also can reject a signing request if the

user’s vehicle ID is not in the user list or blacklisted

due to several reasons. In that case a PSEUDOSIGN-

DENIAL is sent and the user is unable to participate.

Since our system uses the WAVE protocol, each

message is broadcasted, therefore such πs are easily

interceptable. Thus, a user must prove his rightful

possession of that pseudonym. This is done by per-

forming a zero knowledge proof of knowledge when

showing π to other users. Public parameters zk are

therefore included.

4.3.2 Managing Groups

Each participant can become a group leader once it is

necessary. There are two different strategies when a

member decides to offer a new group for other partic-

ipants. A user may enter an area where he can admit-

tedly connect to others but none of these users within

reach intents to be a group leader. As a consequence,

the new user decides to open his own group according

to our protocol. In order to prevent situations where

not enough groups are available, a user decides with

probability ζ to open a new group.

HGM requires a setup phase for new groups ac-

cording to the group signature scheme’s step Setup

(Bl

omer et al., 2016), however, no central key creat-

ing instance is used but speciﬁc steps are distributed.

We separate the sign ability from the trace ability ac-

cording to our constraints. Since this process requires

all participants to be able to communicate and ex-

change information, data size and number of commu-

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

156

Group Leader

Other users -LEA

-Key-Directory

GROUPPUBLISHPARAMS

GROUPCREATE

GROUPCREATEINTENTION

Initial phaseInitial phase

Advertising new group and wait for users

GROUPTRACERINVITATION

GROUPTRACERKEYINFORM

GROUPTRACERINVITATION

GROUPTRACERKEYINFORM

Tracer phaseTracer phase

Collectively create trace key

INVITEGROUP

GROUPUPDATEPARAMS

Figure 4: Sequence of GROUPCREATE.

nication is minimized. The setup phase has two steps

(cf. Figure 4) but has to be completed within ∆t

G,c

seconds.

Firstly, the group leader signals, during the ini-

tial phase, to create a new group g

by updating

GROUPPUBLISHPARAMS the central key directory

with required information of his group ((id(g

),ts, X )

with ts being the creating timestamp) followed

by a GROUPCREATE broadcast, where he invites

users to join his group. Hence, he broadcasts

a GROUPCREATE(π, id(g

), SCH RC, ts

exp

) message

on the Control Channel (using an unused π ∈ Π and

a group id id(g

) ≡ H (π k {0, 1}

). In our scheme,

each group is organized in a WBSS (Wave Basic Ser-

vice Set) using one of the multiple channels (the se-

lected one is SCH RC) to minimize packet collisions

across different groups. At least θ

users need to state

their intention to join (GROUPCREATEINTENTION).

Otherwise the group setup phase may fail due to a

timeout. This is a precaution because during the setup

phase no user is able to send any payload messages

(using this group) and is only passively waiting for

response from l(g

Assuming θ

members are found, the group leader

starts the tracer phase by selecting θ

− 1 < θ

users using a direct message GROUPTRACERINVI-

TATION. Hopefully, θ

− 1 members respond with

GROUPTRACERKEYINFORM providing each infor-

mation about their secret key part sk

0,...,θ

−1

, the

group leader requests the remaining tracer part sk

from LEA as well. She always responds. Eventually,

the group leader can generate the veriﬁcation key V K

and the public key PK (see (Bl

omer et al., 2016)).

The setup is now complete and the group is ready

to accept members (U

0), broadcasting INVITE-

GROUP(π, id(g

)) for ∆t

G,i

seconds. At the same

time, he deposits the membership list, public group

key and veriﬁcation key in an online directory for oth-

ers to download once they want to verify a signature

(GROUPUPDATEPARAMS).

4.3.3 Joining an Existing Group

A participant u

uses one π

∈ Π

to join a group g

(equals Join from (Bl

omer et al., 2016) with the ex-

tension of (Delerabl

ee and Pointcheval, 2006)). In

order to ﬁnd a group he observes the Control Chan-

nel for INVITEGROUP messages sent by l(g

), af-

terwards he checks the key directory, which it can

cache locally, for all required information. (cf. Fig-

ure 5) Once a user ﬁnds such a message indicat-

ing that a group leader accepts new members, a

user ask in a two way phase to join the group us-

ing GROUPSETUPJOIN1,2(π

, X , id(g

)). A success-

ful join ﬁnishes once the group leader answers with

a GROUPSETUPACCEPT1,2(id(g

), Y ) and executes

← u

A group leader is not able to tell if two distinct

pseudonyms point to the same user. Therefore, a

group leader only checks the received pseudonym π

for a correct signature from the LEA. He also uses

π’s included timestamp ts to enforce particular join-

ing constrains.

Harmonized Group Mix for ITS

157

Group Leader Participant -Key-Directory

INVITEGROUP

GETGROUPPARAMETER

RECEIVEGROUPPARAMETER

GROUPSETUPJOIN1

GROUPSETUPACCEPT1

GROUPSETUPJOIN2

GROUPSETUPACCEPT2

Join phaseJoin phase

Advertising group and wait for users

Figure 5: Sequence of GROUPJOIN.

4.3.4 Sending Messages

A user u

can send messages at any given time, but

usually every ∆t

M,b

seconds, as long as u

∈ U

(equals Sign from (Bl

omer et al., 2016)). They then

send messages on behalf of that group. Consequently,

if a user wants to send some payload , he uses

his private part of the group key to craft a message

m = (,ts, id(g

), σ). σ is the signature of the mes-

sage m. To save space, H (σ) is the message ID. Also,

id(g

) is included in the message. This fulﬁlls two

purposes. Firstly, a user receiving a message can vali-

date the signature by just acquiring the group’s public

key from the online directory and then use this key to

verify the signature. Secondly, id(g

) is used for the

blame process explained in the next section.

By design, a user should be a member of differ-

ent groups at the same time. Therefore he can send

messages using any of his private group keys. This

allows him to become untraceable by interrupting any

message trajectories. As a note, any other identifying

information (e.g. MAC address) must be changed.

Messages are relayed by other members receiving

them. However, they always verify a message’s signa-

ture ﬁrst

(using SignatureVerify from (Bl

omer et al.,

2016)) before they resend the message without chang-

ing it. Furthermore, users do not relay messages if the

payload’s geographical location is too far away from

the user’s current position. This is done to reduce load

on the network. Also, messages are discarded if they

are too old.

4.3.5 Blaming a Message

Our system allows users to send any payload (includ-

ing sensitive GPS-coordinates) without revealing the

Required information can be looked up in the key di-

rectory and be cached locally.

identity, yet all messages are authenticated making

HGM an integer system. Keeping that state is done

by a deliberate backdoor. A user who suspects a mes-

sage m from group g

can start a blame process (cf.

Figure 6) which potentially reveal m’s originator (i.e.

ﬁnd m → π). This can only be done with the sup-

port of the tracers of the message’s group. LEA itself

is unable to ﬁnd out any more information about the

message conforming our requirements. We recall a

message m = (, ts, id(g

), σ) holds all the required

information, and in particular the group ID id(g

Blaming one m requires a valid π. Any user

owning π

sends a MESSAGEBLAMEREQ(m, π

) to

LEA. She validates the blame request by extracting

the id(obu)

from the pseudonym π

using her private

key d

LEA

. LEA keeps a record of all blame request for

each id(obu)

to prevent abusive use of blaming. A

unsuccessful blame request (i.e. a blame request de-

nied by tracers) increases id(obu)

’s penalty score on

the userlist.

LEA posts a valid MESSAGEBLAMEREVEAL(m)

to a blame list. For maximum transparency, a

blockchain based list can be used. Every tracer

has subscribed to that list and listens for changes

(MESSAGEBLAMEUPDATE). If a new entry is added,

each tracer ﬁrst checks if he was tracer for that spe-

ciﬁc group using the id(g

) ﬁeld. If so, he decides on

its own if he wants to use his part of the tracer key to

reveal his part of the user’s real identity (ShareOpen

from (Bl

omer et al., 2016)). The process has to be

completed within ∆t

G,b

, otherwise fails.

• MESSAGEBLAMEACCEPT: A tracer also doubts

that the message’s payload is true because, e.g.

he has seen otherwise or he tries to compromise a

user.

• MESSAGEBLAMEDENIAL: A conﬁrmation of the

payload ultimately leads to this behavior of a

tracer, but it is also possible that an adverse tracer

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

158

-LEA

Participant

All Tracers -Blamelist

-Userlist

MESSAGEBLAMEREQ

MESSAGEBLAMEREVEAL

MESSAGEBLAMEUPDATE

List updateList update

MESSAGEBLAMEACCEPT or

MESSAGEBLAMEDENIAL

VotingVoting

MESSAGEBLAMEFINISH

Figure 6: Sequence of MESSAGEBLAME.

is shielding the originator.

Since we are in a highly dynamic network it may oc-

cur that a proportion of former tracers leaves the net-

work or does not answer the blame request. There-

fore, HGM does not require all θ

tracers to accept

an blame request. Instead only λ ∗ θ

< θ

tracers

need to accept an request. This is sufﬁcient to reveal

the real identity (i.e. the π used in that group) of the

message originator. Once, λ percent of T (g

) coop-

erated to reveal the π, LEA can perform ShareVer-

ify in combination with ShareCombine from (Bl

omer

et al., 2016) and then extract the id(obu) and add a

penalty point to it which may lead to putting it on

the blacklist if a penalty point threshold is exceeded

(MESSAGEBLAMEFINISH).

4.4 Security & Anonymity

LEA is responsible for authenticating the

pseudonyms of the speciﬁc users. Only she can

match different pseudonyms to single users. Thus,

she is able to limit the amount of pseudonyms a

user can have at the same time and is essential for

the protection against sybil attacks. She sends a

PSEUDOSIGNDENIAL once a user already exceeds

the limit of valid pseudonyms allowed at a particular

time. A pseudonym is considered valid as long it is

not expired. LEA is unable to tell if a pseudonym is

in active use, therefore each π given to a user counts

towards a limit θ

HGM is build on the idea that people hold multiple

pseudonyms at once which sounds counterintuitive at

ﬁrst. Table 1 discusses how HGM protects against

multiple attacks.

It is also important to consider the ratio of θ

and

, i.e. the minimum number of tracers and users

during group setup phase (and in particular GROUP-

TRACERKEYNEGOTIATION). If θ

= θ

then the

group leader is forced to select every member of the

group as a tracer resulting in predictability to become

a tracer. An adversary user may circle the group

leader with all of his θ

pseudonyms knowing that he

will later hold θ

parts of the tracer key. Therefore, it

is recommended to set θ

 θ

5 EVALUATION

We now evaluate HGM using a state-of-the-art

vehicular network simulation framework called

Veins (Sommer et al., 2011). Veins has support for

IEEE 802.11p and WAVE module. In the following

sections, we will describe the setup and parametriza-

tion of our simulation model. We then present our

results and show that HGM is feasible from a privacy

and performance perspective.

An urban area around the city of Regensburg,

Germany (about 5 km

in size) was extracted from

OpenStreetMap and prepared using netconvert,

randomTrips, and polyconvert for SUMO (Kra-

jzewicz et al., 2012) and Veins. The chosen area in-

cludes all the different aspects of an urban area. To

present realistic results, we use SimpleObstacleShad-

owing included in Veins to simulate radio interference

due to obstacles. For the sake of simplicity, we dis-

abled WAVE channel switching in our simulation, al-

though, HGM is designed to work with different chan-

nels.

A number of parameters inﬂuence the system.

Relevant parameters for simulation and evaluation are

= 3, θ

= 5, θ

= 3, ρ

U,b

= 0, ρ

G,o

= 0, ρ

G, j

= 1,

∆t

G,c

= 20 s, ∆t

G,v

= 80 s, ∆t

G,i

= 60 s, and ∆t

M,b

= 1 s.

Harmonized Group Mix for ITS

159

Table 1: List of security threats and how HGM protects against them.

Role

Participant Group Leader Tracer

Attack

Alter

σ prevents to change  or

ts. Pointing to another group

by changing id(g) points to

other group key.

Forging any key parameters to track

an individual during group join is eas-

ily detectable by a user via the public

group key directory which shows the

same attributes for each group.

Altering any MESSAGE-

BLAMEREQ is not possible

since these requests are

always initiated by LEA.

Suppress

No effect since messages are

relayed by all participants

(cf. Mesh networks).

Group creation or join fails automati-

cally once a timeout is exceeded.

Not responding to a blame

MESSAGEBLAMEREQ is

implicitly a MESSAGE-

BLAMEDENIAL.

Replay

Intended since each message

is unique via its H (σ) and

HGM uses relaying tech-

niques.

Using another user’s π to join another

group is not possible because of a zero

knowledge proof. Resending key pa-

rameters during create or join is im-

possible since recipient may not know

the respective secrets.

Each tracer only has

one vote (either MES-

SAGEBLAMEACCEPT or

MESSAGEBLAMEDENIAL),

successive responses may be

discarded.

Inject

Blame of bogus messages

will eventually remove them.

Group leader can violate θ

and/or

. He can either track a user by per-

forming an n − 1 attack or create a

group without LEA as a tracer or any

other independent tracers. As a conse-

quence each blame request will even-

tually fail. Such a rogue group can

be easily identiﬁed by LEA with the

group leader being ultimately respon-

sible for it.

Sending either MESSAGE-

BLAMEACCEPT or MES-

SAGEBLAMEDENIAL with-

out a proper MESSAGE-

BLAMEREQ has no effect.

If not otherwise stated, the defaults are used. To

ensure that enough vehicles are in the simulation, a

warm-up period of 10 min is preceded. Key statistics

are tracked after the warm-up period for a duration of

another 10 min. Every second a vehicle spawns and

drives along a random path. To ensure the accuracy

of the results, every parameter conﬁguration is run at

least ﬁve times and afterwards the mean of the results

is calculated.

5.1 Privacy

We measure privacy using two metrics mentioned

by (Wagner and Eckhoff, 2018). Of interest is the

anonymity set size, which describes ”the set of users

that the adversary cannot distinguish from u” (Wag-

ner and Eckhoff, 2018). Furthermore, the size of un-

certainty region illustrates “the minimal size of the

region R

to which an adversary can narrow down

the position of a target user u” (Wagner and Eckhoff,

2018).

In theory, the anonymity set size is at least θ

Therefore, it would be wise to choose θ

as big as

possible. However, from a performance perspective,

the upper bound of θ

is limited since larger groups

are more unlikely to be successfully created. Thus,

our algorithm allows subsequent group joins, subse-

quently increasing the anonymity set size. The simu-

lation helps to balance these conﬂicting interests. To

extract feasible values, we track the sender of a pay-

load message (called safety beacons in the simulation)

and his group afﬁliation. On that, we derive the ra-

tio of messages sent by a user in comparison to all

messages sent by the afﬁliated group called multitude

of messages. Also, we count the average number of

users within each group (|U

|). As Figure 7 illus-

trates, there is a direct correlation between ∆t

M,b

and

these parameters indicating that low values for ∆t

M,b

are to prefer.

To gain insight into the size of uncertainty region,

we collect payload messages sent by users U

a group g

. With the help of the Gauss’s area for-

mula, we calculate the region span of U

which sent

a safety beacon message at the same time. However,

this yields just the minimum of the uncertainty region

because not all u ∈ U

may have send a safety bea-

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

160

1 2 3 4

∆t

M,b

[sec]

| [#]

1 2 3 4

∆t

M,b

[sec]

multitude

of m

Figure 7: Anonymity set size deﬁned by the user who send

a safety beacon message under the same group ID.

3 4 5 6

8 9 10 11 12

[#]

uncertainty

region [m

]

Figure 8: Boxplot of the uncertainty region.

con message using that speciﬁc group g

. Figure 8

shows that we can choose θ

small because the uncer-

tainty region stays more or less constant with a de-

crease of θ

Figure 9 plots the inﬂuence of parameters ∆t

G,c

∆t

G,i

, and ∆t

G,v

, on the percentage of the time

a user

is able to sent messages on behalf of a group and the

uncertainty region. We can see that there is no cor-

relation between the uncertainty region and the per-

centage of active time. To determine the parameters

which have an impact on the uncertainty region, we

calculated the correlation coefﬁcient between all rele-

vant parameters in our simulation and the uncertainty

region. We reason that none of the considered param-

eters have a nonambiguous effect on the uncertainty

region. The movement of vehicles may have a more

signiﬁcant impact than the presented parameters.

5.2 Performance

To depict the overhead of HGM, we list in Table 2

the distribution of messages types in relation to ∆t

M,b

Most received messages are payload messages. With

bigger ∆t

M,b

decreases their percentage because the

group setup phases take more time and the users can

send fewer payload messages.

Figure 10 shows the time for group creation ∆t in

relation to different parameters. It shows that increas-

ing ∆t

M,b

∆t

G,c

, or θ

also increases ∆t. However, this

does not come as a surprise, since for instance search-

ing for more members depends on the density of cars

which was constant during our simulation.

Figure 11 illustrates HGM’s robustness because

even when 90% of the vehicles in the simulation are

In relation to the user’s overall simulation lifetime.

30, 10, 120

60, 10, 120

60, 30, 60

60, 10, 60

30, 10, 90

60, 10, 90

60, 30, 90

30, 30, 90

60, 60, 90

15, 10, 120

60, 60, 60

15, 120, 120

30, 120, 120

60, 10, 45

60, 30, 30

60, 30, 45

60, 30, 120

60, 60, 120

30, 60, 120

30, 10, 60

60, 10, 30

15, 60, 120

15, 60, 90

30, 30, 120

15, 30, 120

30, 60, 90

30, 30, 60

60, 120, 120

15, 30, 60

15, 10, 90

·10

Parameter setting

region size [m

]

0.2

0.4

0.6

active time [%]

Figure 9: The inﬂuence of ∆t

G,c

, ∆t

G,i

, ∆t

G,v

on the per-

centage of the users active group time, and the uncertainty

region in m

Table 2: Distribution of messages types in relation to ∆t

M,b

∆t

M,b

1 [%] 2 [%] 3 [%] 4 [%]

received

payload 39.28 50.87 43.18 29.26

broadcast 43.97 34.73 37.76 45.19

direct 0.99 0.87 0.71 0.49

send

payload 3.70 3.57 2.32 1.04

broadcast 1.26 0.97 0.99 0.99

direct 4.09 4.50 6.98 10.34

LEA 6.71 4.49 8.05 12.68

blocked, groups with θ

= 5 are created and on aver-

age at least 5 participants send a message under the

same id(g).

6 CONCLUSION AND FUTURE

WORK

In this paper we presented a privacy enhanced ap-

proach for V2V communication which can be used

with current standards like WAVE. HGM uses a state-

of-the-art group signature scheme feasible for the

tight requirements of ITSs. It only relies on a semi-

trusted entity called LEA and apart from that, is fully

1 2 3 4

∆t

M,b

[sec]

∆t [sec]

15 30 60

∆t

G,c

[sec]

3 6 9 12

[#]

Figure 10: Time for group creation ∆t is correlated to mul-

tiple parameters.

Harmonized Group Mix for ITS

161

0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

U,b

| [#]

Figure 11: The anonymity set size in dependence of the

probability of blocked users.

decentralized. We tackle to balance both require-

ments, privacy and integrity.

Our evaluation was done with Veins showing that

HGM improves the privacy of users by hiding them

along with other members in regions with uniform

probability. Among other things, the results also show

that our approach is robust in terms of dishonest par-

ticipants who suppress messages. We also show that

the overhead related to HGM is acceptable.

In future work we would like to extend our anal-

ysis to a more realistic scenario such as (Codeca

et al., 2016). We want to increase performance using

WAVE’s channel switching in the simulation. In addi-

tion, we want to strengthen our attacker by including

external knowledge such as derived user behavior and

analyze tracers.

ACKNOWLEDGEMENTS

This research was partly funded by the German Fed-

eral Ministry of Education and Research (BMBF)

with grant number: 16KIS0367K.

REFERENCES

Alexiou, N., Lagan

a, M., Gisdakis, S., Khodaei, M., and

Papadimitratos, P. (2013). VeSPA. In Proceedings

of the 2nd ACM workshop on Hot topics on wireless

network security and privacy - HotWiSec ’13, page 19,

New York, New York, USA. ACM Press.

Bilgin, B. E. and Gungor, V. C. (2013). Performance

Comparison of IEEE 802.11p and IEEE 802.11b for

Vehicle-to-Vehicle Communications in Highway, Ru-

ral, and Urban Areas. International Journal of Vehic-

ular Technology, 2013:1–10.

omer, J., Juhnke, J., and L

oken, N. (2016). Short group

signatures with distributed traceability. In Mathemat-

ical Aspects of Computer and Information Sciences.

MACIS 2015. Lecture Notes in Computer Science, vol-

ume 9582, pages 166–180. Springer, Cham.

Boneh, D., Boyen, X., and Shacham, H. (2004). Short

group signatures. In Franklin, M., editor, Advances

in Cryptology – CRYPTO 2004, pages 41–55, Berlin,

Heidelberg. Springer Berlin Heidelberg.

Brecht, B., Therriault, D., Weimerskirch, A., Whyte, W.,

Kumar, V., Hehn, T., and Goudy, R. (2018). A secu-

rity credential management system for V2X commu-

nications. CoRR, abs/1802.05323.

Calandriello, G., Papadimitratos, P., Hubaux, J.-P., and

Lioy, A. (2007). Efﬁcient and robust pseudonymous

authentication in VANET. In Proceedings of the

Fourth ACM International Workshop on Vehicular Ad

Hoc Networks, VANET ’07, pages 19–28, New York,

NY, USA. ACM.

Camenisch, J. (1997). Efﬁcient and generalized group

signatures. In Advances in Cryptology – EURO-

CRYPT ’97. EUROCRYPT 1997. Lecture Notes in

Computer Science, volume 1233, pages 465–479.

Springer, Berlin, Heidelberg.

Chaum, D. and Van Heyst, E. (1991). Group signatures.

In Advances in Cryptology — EUROCRYPT ’91. EU-

ROCRYPT 1991. Lecture Notes in Computer Science,

volume 547 LNCS, pages 257–265. Springer, Berlin,

Heidelberg.

Chaum, D. L. (1981). Untraceable electronic mail, return

addresses, and digital pseudonyms. Communications

of the ACM, 24(2):84–90.

Chen, L., Ng, S.-L., and Wang, G. (2011). Threshold anony-

mous announcement in vanets. IEEE Journal on Se-

lected Areas in Communications, 29:605–615.

Chen, L. and Pedersen, T. P. (1995). New group signature

schemes. In De Santis, A., editor, Advances in Cryp-

tology – EUROCRYPT’94, pages 171–181. Springer,

Berlin, Heidelberg.

Codeca, L., Frank, R., and Engel, T. (2016). Luxembourg

SUMO Trafﬁc (LuST) Scenario: 24 hours of mobility

for vehicular networking research. In IEEE Vehicular

Networking Conference, VNC, volume 2016-January,

pages 1–8. IEEE Computer Society.

Delerabl

ee, C. and Pointcheval, D. (2006). Dynamic Fully

Anonymous Short Group Signatures. In VIETCRYPT

2006, pages 193–210.

Fischlin, M. (2005). Communication-Efﬁcient Non-

interactive Proofs of Knowledge with Online Extrac-

tors. In Shoup, V., editor, Advances in Cryptology –

CRYPTO 2005, pages 152–168. Springer Berlin Hei-

delberg.

aﬂing, S., M

onen, P., and Riihij

arvi, J. (2010). Per-

formance evaluation of IEEE 1609 WAVE and IEEE

802.11p for vehicular communications. In ICUFN

2010 - 2nd International Conference on Ubiquitous

and Future Networks, pages 344–348.

Guo, J., Baugh, J. P., and Wang, S. (2007). A group sig-

nature based secure and privacy-preserving vehicu-

lar communication framework. In 2007 Mobile Net-

working for Vehicular Environments, pages 103–108.

IEEE.

Hao, Y., Cheng, Y., and Ren, K. (2008). Distributed key

management with protection against RSU compro-

mise in group signature based VANETs. In GLOBE-

COM - IEEE Global Telecommunications Conference,

pages 4951–4955. IEEE.

Hu, W., Xue, K., Hong, P., and Wu, C. (2011). Atcs:

A novel anonymous and traceable communication

scheme for vehicular Ad hoc networks. International

Journal of Network Security, 13(2):71–78.

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

162

IEEE 1609 Working Group (2017). IEEE Guide for Wire-

less Access in Vehicular Environments (WAVE) - Ar-

chitecture. IEEE Std 1609.0-2013, pages 1–78.

Khodaei, M. and Papadimitratos, P. (2015). The Key to In-

telligent Transportation: Identity and Credential Man-

agement in Vehicular Communication Systems. IEEE

Vehicular Technology Magazine, 10(4):63–69.

Krajzewicz, D., Erdmann, J., Behrisch, M., and Bieker,

L. (2012). Recent Development and Applications of

SUMO - Simulation of Urban MObility. International

Journal On Advances in Systems and Measurements,

5(3&4):128–138.

Laurendeau, C. and Barbeau, M. (2007). Secure Anony-

mous Broadcasting in Vehicular Networks. In 32nd

IEEE Conference on Local Computer Networks (LCN

2007), pages 661–668. IEEE.

Lin, X., Sun, X., Ho, P. H., and Shen, X. (2007). GSIS:

A secure and privacy-preserving protocol for vehicu-

lar communications. IEEE Transactions on Vehicular

Technology, 56(6 I):3442–3456.

Papadimitratos, P., Buttyan, L., Hubaux, J.-P., Kargl, F.,

Kung, A., and Raya, M. (2007). Architecture for Se-

cure and Private Vehicular Communications. In 2007

7th International Conference on ITS Telecommunica-

tions, pages 1–6. IEEE.

Plossl, K., Nowey, T., and Mletzko, C. (2006). Towards a

security architecture for vehicular ad hoc networks. In

First International Conference on Availability, Relia-

bility and Security (ARES’06), pages 8 pp.–381. IEEE.

Sampigethaya, K., Huang, L., Li, M., Poovendran, Radha

Matsuura, K., and Sezaki, K. (2005). CARAVAN:

Providing location privacy for VANET. Embedded Se-

curity in Cars, pages 1–15.

Sommer, C., German, R., and Dressler, F. (2011). Bidirec-

tionally Coupled Network and Road Trafﬁc Simula-

tion for Improved IVC Analysis. IEEE Transactions

on Mobile Computing, 10(1):3–15.

Sun, J., Zhang, C., and Fang, Y. (2007). An ID-based frame-

work achieving privacy and non-repudiation in vehic-

ular ad hoc networks. In Proceedings - IEEE Mili-

tary Communications Conference MILCOM, pages 1–

7. IEEE.

Uzcategui, R. A., De Sucre, A. J., and Acosta-Marum, G.

(2009). Wave: A tutorial. IEEE Communications

Magazine, 47(5):126–133.

Verheul, E. R. (2016). Activate later certiﬁcates for v2x -

combining its efﬁciency with privacy. IACR Cryptol-

ogy ePrint Archive, 2016:1158.

Wagner, I. and Eckhoff, D. (2018). Technical Privacy Met-

rics. ACM Computing Surveys, 51(3):1–38.

Xiaonan, L., Zhiyi, F., and Lijun, S. (2007). Securing ve-

hicular ad hoc networks. In Ning, P. and Du, W., edi-

tors, 2007 2nd International Conference on Pervasive

Computing and Applications, ICPCA’07, volume 15,

pages 424–429. IOS Press.

Zhang, L., Wu, Q., Solanas, A., and Domingo-Ferrer, J.

(2010). A scalable robust authentication protocol for

secure vehicular communications. IEEE Transactions

on Vehicular Technology, 59(4):1606–1617.

APPENDIX

A Notation

u Known user in the system

U Set of all users

g Existing group in the system

G Set of all groups with id(g)

Users in group g

l Group leader

t Tracer

T Set of tracers

π Pseudonym signed by LEA

Π Set of all signed pseudonyms

H Hash function

m Message

M Set of all messages

σ Signature of a message m

zk Public parameters of a zero knowledge proof

Minimum number of tracers

Minimum number of group users

Maximum number of concurrent pseudonyms

of a single user

λ Proportion of tracers needed to reveal

k Length of randomness

α Percentage of dishonest users in the system

∆t

G,c

Group creation time

∆t

G,v

Group valid time

∆t

G,i

Group invition time

∆t

G,b

Blame duration time

∆t

M,b

Message safety beacon time interval

G,o

Probability of opening a group

G, j

Probability of joining a group

U,b

Probability of beeing blocked

Harmonized Group Mix for ITS

163