1 Introduction

Smart cities involve the management of different infrastructures in order to provide better services to citizens. Among these services, those intended to improve road traffic play a key role in smart cities development [3]. In order to achieve this goal, vehicular ad hoc networks (VANETs) are being developed. VANETs allow the exchange of information with vehicles around and also with the traffic manager and other service providers. In this way, VANETs enable not only traffic management but also a plethora of services to enhance citizens’ experience of travelling. In particular, the European Telecommunications Standards Institute (ETSI) has defined the Basic Set of Applications (BSA), which “can be deployed simultaneously at a targeted time (day 1) with the objective to serve societal and business objectives of private and public road transport stakeholders” [18]. Therefore, BSA is a stepping stone towards the development of smart cities.

However, despite their benefits, privacy is a key concern in this facet of smart cities [22]. For example, given that vehicles will be exchanging data with other entities, path tracking becomes a feasible threat. What is more, the passive collection of data will enable the attacker to keep track of driver’s and/or vehicle’s issues (e.g. behavior, preferences, and characteristics) and their automatic analysis [17, 43, 44].

To address the privacy issue, a plethora of contributions have been proposed so far. Several approaches have mainly focused on public key cryptography based on certificates [43], or ID-based (i.e. certificateless) cryptography [8]. Traditional PKI authentication systems were not designed to provide any privacy protection [22, 23]; thus, in typical PKI approaches, the use of certificates leads to unnecessarily revealing the identity of their holders as well as other privacy-sensitive attributes [24]. In a more privacy-preserving way, the use of pseudonyms has been proposed. Pseudonyms are different identities to conceal the real one to unauthorized parties [7]. However, privacy threats are still possible when a pseudonym is used in scarce networks [22], where even small correlations of data could reveal sensitive information.

In a smart city context, when a driver or vehicle requests a resource or service using VANET communications, the provider only needs to verify if the vehicle is authorized to access the requested issue. However, revealing more information than necessary could lead to privacy risks [48]. Thus, achieving minimum information disclosure, that is minimizing as much as possible the disclosed information (attributes in this case) to achieve a goal, is of utmost relevance. This property contributes to avoid data inference from a service provider or a collusion of them. Credential holders (e.g. drivers) must be able to disclose a subset of credential attributes without giving away their identity or other private information. In order to achieve this goal, Attribute-Based Credentials (ABCs) have been explored [45, 55].

ABCs are slowly gaining momentum, and yet a number of ABC theoretical approaches exist [13, 35, 39, 40]. Regardless of ABC benefits, few proposals have suggested applying them in the field of VANETs. [38] presents challenges and open issues regarding privacy and identity management in vehicular communication and point out ABCs as a potential solution for addressing privacy needs in generic scenarios; neither specific scenarios are discussed, nor an evaluation of ABC’s applicability or technical feasibility is introduced. Authors in [50] introduce a conceptual framework including the use of ABCs, to provide trustworthy vehicular communications, in their work, authors highlighted the need of evaluating different ABC technologies in order to assess both: the privacy features offered by each technology and their technical feasibility for VANET environments. ABCs could enable, for instance, showing that a driver is neighbour of a given zone, without actually disclosing his identity or real address. Nevertheless, developing such an application requires a theoretical and practical analysis on the suitability of each ABC technique. This would enable to take an informed decision on the best mechanism for each VANET application.

To address this issue, this paper presents a feasibility analysis of ABC techniques for the vehicular context which, to the best of the authors’ knowledge, remains unaddressed. This issue has been pointed out as a research need [50] due to the complexity of these technologies [60]. Thus, the goal of this paper is to analyze how these systems can be adapted to VANETs and to assess if such adaptation is feasible and useful for VANET use cases. The analysis is focused on a subset of the aforementioned BSA services in which we identify privacy issues. We consider two major ABC systems—Idemix [13] and U-Prove [39]—which have not been assessed yet. This analysis is completed with a third system, an updated version of Persiano’s ABC system [25], as it has already been applied to the VANET context. According to existing literature [31], our selection is consistent in that it represents the two major families of ABC systems, namely those based on blind signatures (U-Prove) and those based on zero-knowledge proofs (Idemix, Persiano). Furthermore, the ABC technology introduced in [4] was afterwards discarded by the authors who developed more efficient technologies based on the specifications provided by U-Prove and Idemix, and introduced them in [34] and [57], respectively. Authors in [26] proposed an anonymous credential system which was limited in functionality, since it did not provide all privacy features offered by Idemix and U-Prove. Therefore, we stick to the aforementioned alternatives since they are more complete and count with a working implementation.

The rest of the paper is organized as follows. Section 2 describes the related work. Section 3 introduces the required background. Section 4 shows the road traffic services in smart cities that can benefit from ABCs. Section 5 focuses on how to adapt these techniques to the VANET context. Section 6 performs a suitability assessment of the so-adapted ABC technologies. Section 7 highlights several open research directions. Finally, Section 8 draws the main conclusions of the paper.

2 Related work

Credentials are essential in identity management systems. They attest that an entity (e.g. user or vehicle) has a certain type of feature, knowledge, skill, etc. A credential can be composed of attributes with attached values, e.g. d e g r e e = “ s c i e n c e ” or d r i v e r L i c e n s e = “ y e s ”. In the field of VANETs, public key digital certificates [27] are one of the most used types of credentials. They attest that an entity holds a particular public key. Their use is specially associated with providing authenticated communications, as well as integrity and confidentiality in interchanged messages. By contrast, in multiple scenarios (e.g. parking payment) identity disclosure is not a mandatory requirement, since only attribute verification is needed. As a privacy-preserving solution to the problem, Brands presents the concept of digital credentials [9], as an instantiation of pseudonymous systems proposed by Chaum [14]. One main point is that credentials involve attributes of an entity without including identity information which allows linking the credential to its owner. Furthermore, assuming that security and privacy are among the most relevant aspects in VANETs, the actual driver identity has to be revealed only to authorized entities, as it could be used for malicious purposes otherwise [7]. Therefore, credentials are the first step towards anonymity management.

Anonymity is the state of being not identifiable [42], which actually means much more than just identity preservation. Questions like ‘why should I reveal the age of my vehicle when just the tax records are requested?’ or ‘why should I reveal my postal address when just the driving license is needed?’ are at stake. Chaum was one of the first researchers to provide an answer to this kind of questions [14]. He envisioned anonymous credentials systems. His approach is based on a cryptographic scheme called blind signatures in which signers neither learn the signed message nor the identity of the individuals who request signatures except for uncommon occasions, e.g. a court order.

An anonymous or ABC system consists of users who obtain credentials from organizations and prove the possession of such credentials without disclosing values within them. In these systems, transactions carried out by the same user may not be linkable with each other.

Several works have been developed in relation to anonymous credentials. Nkenyereye et al. [36] presents an attribute-based access control protocol to manage access to services. In that work, anonymous credentials are used to protect vehicles’ privacy but without detailing management processes. In [53], an identity-based encryption system in VANETs is proposed to achieve the privacy users desire and the traceability required by government authorities. However, the way anonymous certificates are applied is generally described but not detailed. Büttner et al. [11] propose a system in which anonymous credentials are used to get attribute-based authorization tickets. The system is described but specifications regarding credentials management are not provided. More recently, PUCA, a pseudonym scheme with user-controlled anonymity for VANETs is presented [20]. Anonymous credentials are used for authentication purposes in car-to-X communications applying Camenisch et al. approach [13]. Chim et al. [16] propose a VANET-based secure navigation protocol which takes advantage of anonymous credentials to provide secure navigation services to drivers. In that work, anonymous credential creation and management follow Chaum’s approach which was later enhanced by Brands [9] as well as Camenisch and Lysyanskaya [13]. Also looking for anonymity Raya et al. [44] present a protocol based on anonymous keys to conceal vehicles’ identity. However, though anonymous keys can be compared to credentials, their management and use is analogous to that of a public key infrastructure. Petit et al. [41] present a survey of pseudonyms schemes in VANETs noticing that pseudonym-based credentials must be efficient to support real-time requirements in applications. It can be extrapolated to anonymous certificates as it is pointed out that anonymous credentials are one way of implementing one-time pseudonyms.

Apart from anonymous credential theoretical approaches, two main implementations of these systems have been developed—U-Prove technology from Microsoft [39] and Idemix from IBM [13]. Some proposals have compared their developments against these technologies, e.g. [35] and [58] assess the efficiency of implementing U-Prove and Idemix in smart cards, respectively. Specifically in the vehicular context, to the best of the authors’ knowledge, only Gonzalez-Tablas et al. [25] propose and implement an ABC system, namely a VANET-updated version of Persiano et al. scheme [40].

3 Background

This section provides the reader with an introduction to VANETs (Section 3.1) and a brief description of the three Privacy-ABC techniques considered in this paper, namely U-Prove, Idemix and the VANET-updated version of Persiano (Section 3.2).

3.1 Vehicular ad-hoc networks (VANETs)

Information and communication technologies in the vehicular context encouraged the emergence of new services called intelligent transport systems (ITS) [59]. ITS facilitate the presentation of immediate and accurate information concerning road traffic status or entertainment services, e.g info about the nearest shopping malls or restaurants. Therefore, ITS can be seen as an instantiation of location-based services (LBS) [51]. However, ITS also consider other traffic- and safety-related aspects for the service provision.

In order to realize ITS, different architectures have been proposed. Apart from regional initiatives, such as the European ITS architecture [21], standardized approaches are gaining attention. In particular, ISO 21217 standard defines the entities at stake as well as their internal structure. Thus, the main elements are Road-Side Units (RSUs), On-Board Units (OBUs), central ITS stations and personal ITS stations. Each one is introduced below.

RSUs are communication nodes placed aside roads to behave as a proxy between vehicles and infrastructure. On the other hand, OBUs are vehicle-mounted devices to allow the exchange of data with RSUs and other surrounding OBUs. These devices are resource-constrained, which poses a performance challenge when designing applications and services. Central ITS stations are infrastructure elements that provide with ITS-based services. Finally, personal ITS stations are portable devices that may offer services to its owner (say the driver or a passenger).

In order for these entities to communicate with each other, different technologies may be applied. In particular, both short-range and long-range alternatives are considered. For short range, dedicated short-range communications (DSRC) are being developed following standard family IEEE 1609 [29]. DSRC is reserved for automotive traffic safety applications using vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I/I2V) communications forming vehicular ad hoc networks (VANETs). On the other hand, 3G is representative for long-range communications.

From the architectural point of view, the said entities present significant similarities. On the one hand, all of them contain a gateway if they are connected to more than one network. For example, it is the case of OBUs, since they need to share information between its network and that internal of the vehicle. Similarly, they contain a router to exchange packets with other ITS entities. Considering OBUs again, the router enables V2V or V2I/I2V communications. Furthermore, a central element called ITS-SU (ITS Station Unit) properly handles each packet by executing applications.

As ABC-related protocols can be seen as applications themselves, in the following, we focus on ITS-SU composition (Fig. 1). Particularly, it is organized following an ISO-layered protocol stack. Thus, the access, networking and transport, facilities and application elements offer their services by leveraging on what the immediate inferior provides. Additionally, the management and security elements offer transversal services to the said components.

Fig. 1
figure 1

ITS-SU architecture according to ISO 21217 [30]. The security entity is further decomposed

Full size image

The security component is specially relevant for the sake of this work. In particular, Fig. 1 shows its four sub-components. A firewall and an intrusion detection system prevent network attacks such as illegal accesses. On the other hand, an authentication, authorization and profile management cares about these procedures. For this purpose, it cooperates with the Security Management Information Base (S-MIB) which manages cryptographic credentials and certificates. These elements are stored in a special device called hardware security module (HSM). This module is assumed to provide with secure storage, reliable time source and cryptographic capabilities [37].

One important remark is that the security aspects are not fully refined in ISO 21217. Particularly, the definition of which of the said elements (gateway, router, ITS-SU) have to carry out each security operation has not been clarified. For the sake of simplicity and without loss of generality, in this work, we assume that ABC-related operations are carried out by the security component of ITS-SU.

3.2 Attribute-Based Credentials fundamentals

ABC technologies have been designed to enhance users’ privacy. For several years, they have been investigated as part of anonymous credential systems and group signatures [15]. ABCs are issued like ordinary cryptographic credentials (e.g. X.509 credentials) using a digital (secret) signature key [45]—basically a PKI with privacy-enhancing features. In ABCs, the main enhancing feature is that credential’s attributes could be transformed into unlinkable and non-transferable presentation tokensFootnote 1 able to protect the holder’s privacy, while offering the same level of security. In the following sections, participant roles and involved phases are described. The set of features provided by ABCs are presented in Section 3.4, after presenting each technique in detail.

3.2.1 Roles

Roles within a general ABC system are defined as follows:

  • Issuer: it is an infrastructure-based (trusted) identity provider also known as an attribute authority; this entity or organization is responsible of issuing credentials, that is, a certified container of attributes where an attribute has a type and a value (e.g. first name, Bob). It is also responsible for vouching for the correctness of the information contained in the credentials; therefore, the issuer might request other means of authentication prior to credential issuance.

  • Users: entities to which the identity providers (issuers) will issue the ABCs. They will use these credentials to assert claims about their identity to service providers.

  • Verifier: any relying party willing to protect access to resources, information or services.

  • Revocation Authority: this entity is responsible for revoking issued credentials and preventing their further usage. A revocation authority is not a mandatory entity in typical ABC systems.

  • Inspector: it consists of a trusted authority comprised of either a single entity or a multi-party cooperation. The inspector’s role is to de-anonymize the user under specific situations (e.g. misuse or liability). The inclusion of this entity is not mandatory in traditional approaches. Ideally, the capability of inspection should be done in a distributed fashion, and it must be compliant with a policy that specifies which information should be recoverable by an inspector and under which circumstances.

3.2.2 Phases

In an ABC system, the following phases are distinguished:

  • Set-up: it is performed only once by each entity of the system. A trusted authority generates all public and secret global parameters used by the entities of the system. At the end of this phase, the issuer is ready to release credentials to users and the verifier is ready to validate such credentials.

  • Issuance: an issuer can issue a credential without being related to any existing credential owned by the user.

  • Presentation: it is one of the most important stages from the ABC life-cycle. Verifiers request a credential and users provide it (or a presentation token derived from it) to be later verified.

  • Revocation: credentials are revoked by the revocation authority, which is also responsible for making available updated revocation information.

  • Inspection: there are scenarios in which it is necessary to de-anonymize the credential holder. This is achieved by performing token inspection. Conditional anonymity is provided if and only if a token was generated in compliance with a policy specifying which information could be revealed and under which conditions. A typical example is the case of misbehaving nodes. The process of de-anonymization is restricted to authorized entities and it should ideally require a multi-party intervention.

3.3 ABC systems

This section describes the considered ABC systems, namely Idemix [13], U-Prove [39] and the VANET-updated version of Persiano [25]. Note that the first pair of ABC technologies are jointly described due to their working similarities.

3.3.1 Idemix and U-Prove

Idemix (short for Identity Mixer) [28], developed and distributed by IBM, and U-Prove [33] of Microsoft are two examples of the most prominent ABC technologies currently available. Both technologies represent a suite of cryptographic libraries that can be combined into a functional ABC system. In terms of their construction, the main difference between the two technologies consists in the type of the digital signature scheme being used. While Idemix’s main building block is the Camenisch-Lysyanskaya digital signature scheme [12], U-Prove [33] is based on the Brands’ digital signature scheme [10] instead.

Both technologies support most of the common features of ABCs. However, there are some practical differences between them in the degree of privacy they provide (see Section 3.4), their efficiency and the methods that can be used to practically construct them. For instance, U-Prove’s design allows the use of elliptic curves instead of standard subgroups, which could result in better efficiency. However, in this paper, we focus on the available implementations, which are based on the latter.

Details on how both systems carry out each phase are given below (Fig. 2):

  • Set-up: it is performed once by each of the entities in the system except by the user. In the case of the issuer, it generates a credential specification, issuer parameters and a secret issuance key used to issue credentials. The credential specification describes the type of attributes encoded in a credential and the corresponding encoding mechanism (e.g. cryptographic hash function). Issuer parameters are cryptographic information used by service providers to verify the authenticity of presentation tokens, i.e. issuer’s public key, identifier of a cryptographically secure hash algorithm, revocation information -if revocation process is supported, etc. The issuance key (secret key) needs to be kept secret and it is used by the issuer to issue credentials.

  • Issuance: issuance of a credential is an interactive protocol between the user and the issuer, and works similarly for both Idemix and U-Prove. A difference in the protocol flow is the number of protocol rounds (and the corresponding number of messages during each round). In the case of Idemix, issuance of a credential is done in a single protocol round (two messages exchanged); the user first requests a credential, and if eligible, the issuer produces a credential by signing a statement containing the corresponding attributes [28]. In the case of U-Prove, it requires two rounds (four messages); the user first requests a credential, and if eligible, the issuer generates a signature specific for the requested credential. Afterwards, the user generates a proof using the U-Prove token’s public key, user and issuer parameters, on reception the issuer generates the corresponding credential. In both cases, the issuer defines an issuance policy that describes the requirements that must be met by the user in order to get a credential and contains the identifiers of the credential specification and the issuer parameters of the credential to be issued. The user receives the issuance policy and generates an issuance token. The issuance token contains cryptographic information required by the issuance policy, the token is generated from the token description and the proof generation (ZKProof). Upon reception, the issuer verifies the proof and generates the credential, i.e., a zero-knowledge proof containing issuer’s blind signature on the credential, the issuer-set attributes and if applicable the revocation information.

  • Presentation: Idemix and U-Prove protocols work quite similar. For a particular requested policy, a presentation token is delivered. The presentation policy may define the type of credential(s) that are accepted, which attributes must be disclosed, and potentially the predicates that should be used. Predicates over attributes consist of statements that allow the user proving certain property of an attribute value without disclosing the actual value (e.g. birthdate < 1993/01/01). The presentation token includes a cryptographic evidence for the possession of a credential by proving the knowledge of the credential secret by the user, token information such as validity period, and cryptographic commitments to the encoded attributes (a commitment is the product of generators with attributes and a secret key as their exponents). When the verifier receives the presentation token, it verifies that the statements are logically satisfied as well as the validity of the cryptographic evidence.

  • Revocation: the revocation mechanism implemented for both U-Prove and Idemix requires that both users and verifiers have the most recent revocation information from the corresponding revocation authority. There are two different settings for revocation: (1) issuer-driven revocation (global context), this approach requires that any presentation token should be proved against the most recent revocation information, which mainly requires online interaction. Additionally, nodes are responsible for updating their non-revocation evidence, which can derive potential privacy risks due to timing correlations, especially when performed at presentation time; (2) verifier-driven revocation (specific context), this approach can be done offline, it consists of a black list of attribute values managed by the verifier. It is worth mentioning that this approach will only affect the specific verifier and does not have any global effect.

  • Inspection: Idemix and U-Prove share the implementation of a mechanism that only supports one inspector. This entity is able to uncover inspectable attributes which can lead to the identification of the credential owner. Note that by default Idemix and U-Prove tokens are anonymous and can only become inspectable if defined in the presentation policy.

Fig. 2
figure 2

Idemix and U-Prove protocol. Issuance and verification phases

Full size image

3.3.2 VANET-updated Persiano

This technology is based on the use of anonymous credentials to prove their on-the-fly holdership in the context of VANETs for motor vehicles. Its phases work as follows (Fig. 3):

  • Set-up: as in previous techniques, public and secret parameters are established. In this updated version, each user receives a set of single-use certificates each of them linked to a pseudonym (\(\phantom {\dot {i}\!}\overline {CERT}\)).

  • Issuance: the user requests a credential and demonstrates the possession of certain attributes (in a non-anonymous fashion). Once the proof is successful, the issuer provides a signed credential whose signature is finally verified.

  • Verification: the user and the verifier enrol in a credential joint proving process, comprised of an offline and an online part. In the former part, the user creates a set of commitments and proves their ownership constructing four Zero Knowledge Proof of Knowledge (ZK-PoKs). In the online part, the verifier requests a presentation token (called proof) and the user provides the computed ZK-PoKs (and one certificate of the set \(\phantom {\dot {i}\!}\overline {CERT}\)). Finally, when the verification is performed, the result is published in a public repository which is later accessed by the user. This allows the user having feedback, which is specially useful when failing this verification involves sanctions.

  • Revocation: the certificate of the set \(\phantom {\dot {i}\!}\overline {CERT}\), involved in the creation of the presentation token, can be revoked. This action can be seen as a temporal de-registration of the vehicle (e.g. after verification, driving taxes are found to be unpaid).

  • Inspection: certificates within the set \(\phantom {\dot {i}\!}\overline {CERT}\) allow the retrieval of the user’s identity for the authorized entity (i.e. traffic agency). In this way, it is possible to de-anonymize a given credential holder when needed.

Fig. 3
figure 3

VANET-updated Persiano protocol. Issuance and verification phases

Full size image

3.4 Privacy features. Analysis per mechanism

This section introduces the most relevant features provided by ABC techniques and compares them against each mechanism. Eleven privacy features can be identified:

  • Issuance unlinkability: the issuer cannot link an issued credential to the presentation of such credential.

  • Multi-show unlinkability: a credential can be used multiple times without the resulting evidence becoming linkable.

  • Selective disclosure of attributes: allows users to prove only a subset of attributes to a verifier.

  • Predicate proof: it consists of statements that allow to prove a property of an attribute without disclosing its actual value. Example of these statements are the logical operators > or < .

  • Proof of holdership: a cryptographic evidence for proving ownership or possession of a credential without disclosing the attributes contained in that credential.

  • Non-transferability: key binding can be used to bind one or more credentials of the user to the same secret and discourage users to perform credential pooling.

  • Scope-exclusive pseudonyms: a certified pseudonym unique for a specific scope and secret key, i.e. a single pseudonym can be created for each credential.

  • Carry-over attributes: it relies on the assumption that the user already possesses a credential, from which a given attribute can be carried over into the new credential without disclosing the attribute value to the issuer.

  • Cross-credential proofs: it allows users to prove relations between attributes from two or more credentials without revealing them to the verifier. For instance, that the name contained on a credit card and on a passport match.

  • De-anonymization: it is an optional feature that allows an authority (either alone or in cooperation with other entities) to reveal the identity of users in cases of accountability and non-repudiation.

  • Revocation: in case of misuse, it allows the revocation of issued credentials to (misbehaving) users. Thus, revoked credentials cannot longer be used to generate presentation tokens.

Based on the aforementioned features, the chosen mechanisms are compared in terms of their supported privacy and privacy-influencing features. Table 1 summarizes the main results, where √, P and − respectively denote that a feature is completely, partially or not provided.

Table 1 ABC features comparison
Full size table

All three given technologies provide issuance unlinkability, while only Idemix and VANET-updated Persiano provide natively the functionality of multi-show unlinkability. In the case of U-Prove, to be able to guarantee unlinkability, the use of the same token in two different transactions must be avoided.

The three technologies enable attribute hiding, selective disclosure of attributes, and use of predicates over certain attributes, which make them suitable for scenarios where minimal information disclosure must be guaranteed.

Also, all three technologies support anonymous proof of possession of a credential, which allows users to prove holdership of a credential without disclosing the credential, as well as the non-transferability of credentials, aimed at discouraging users to perform credential pooling and at the same time enforcing non-repudiation.

Limited usage of credential and scope-based pseudonymity are both supported by U-Prove and Idemix; this is particularly useful in scenarios where users are restricted to a single pseudonym for a given scope, e.g. for accessing a certain website where multiple votes from the same user should be avoided.

Carry-over attributes is a feature that is supported by Idemix and U-Prove, while cross-credential proofs are supported by the three ABC schemes. The latter is a highly relevant feature in scenarios where the user is offered to access either joint services or a single service that requires to prove holdership of two or more credentials, e.g. a service-related credential and an authority-based credential. Finally, in cases of user misbehavior, both revocation and de-anonymization are supported by the three schemes, providing in this way the possibility of accountability. However, Persiano offers de-anonymization in a more constrained way than the other mechanisms, since it does not involve multi-party cooperation to reveal the identity.

4 Road traffic services benefiting from ABCs

After presenting the background on VANETs and ABCs, this section focuses on motivating why applying the latter to the former. In recent years, smart city services built on top of VANETs are being proposed. Among them, ETSI TR 102 638 [18] points out a set of them to be available in the ‘day 1’, thus being specially relevant for the early development of smart cities. This set is referred to as Basic Set of Applications (BSA). In this section, the subset of applications of BSA that can benefit from ABC is identified, along with their related use cases. After analysing their privacy needs and considering the privacy features per ABC technique already introduced, this section finishes with the election of the most theoretically suitable technique for each use case.

4.1 Applications and use cases

In BSA, four classes of applications are distinguished, namely Active road safety, Cooperative traffic efficiency, Cooperative local services and Global internet services. For each class, different set of applications, use cases and attributes are distinguished. Among the seven applications and 33 use cases of BSA, Table 2 depicts in italic those applications and use cases that can leverage ABCs. For each one, the set of attributes at stake is identified, clarifying if they may be jointly proved (marked with J) or independently (I). Besides the applied communication protocol is also specified in Table 2. This may be an Internet connection through IPv6 or RSU communication through DSRC.

Table 2 Road traffic services for smart cities benefiting from ABCs
Full size table

In the following, the use of ABCs in BSA applications is described, particularized per use case:

  • Enhanced route guidance and navigation: RSU provides passing-by vehicles with travel itinerary information downloaded from servers based on particular requirements. However, the interaction between vehicles and internet servers may involve some transactions. They may affect privacy due to requested data. For instance, to download an itinerary, vehicles may have to attest that they have paid some fee. However, it has to be done anonymously, without disclosing any information of the vehicle or the driver. Anonymous credentials may attest a fee paid, the positive current account or the existence of a discount without disclosing further information.

  • Limited access warning and detour notification: vehicles are warned of some road limit access, restriction or access control need. Other itinerary may be recommended to avoid a restricted area. Limitations may be related to the type of vehicle or, in general, it may be necessary to provide some information to gain access. For instance, a road that goes to a particular city district is closed to everybody except for those that attest they have a parking place in it. ABCs avoid showing the exact parking place of a vehicle but they allow attesting vehicles can park in a particular city district.

  • Automatic access control and parking management: accessing or leaving a controlled area, e.g. a parking, requires the entitled vehicle to supply its identity. However, privacy is a key security issue in this regard. Providing information, such as having paid the monthly fee, having a particular parking place reserved, have a discount or a positive current account have to be carried out anonymously without disclosing vehicle’s owner data and without being able to link multiple parking transactions of a given car.

  • ITS local electronic commerce: RSUs signal some service, i.e. point of interest or location-based service, which requires local payment for reservation and/or purchasing. Vehicles have to pay accordingly but without disclosing any private information. They may use anonymous credentials to attest that they have some kind of discount or prove they have paid it in advance.

  • Media downloading: RSUs provide multimedia to passengers with or without internet access. Downloading can be conditioned by a commercial transaction. Therefore, multimedia access may depend on provided data, e.g. downloading a film has some cost, whose delivery should prevent privacy issues. The use of anonymous credentials to attest, e.g. after having paid a fee, owning a voucher to access free content or being client of the downloading service, avoids privacy data disclosures.

  • Insurance and financial services: on-demand and real-time interaction to a financial or insurance service, e.g. pay as you drive. As in other applications, the use of anonymous credentials for committing to a payment and for being authenticated preserves privacy avoiding the disclosure of more information than the one needed.

  • Fleet management: RSUs provide and collect data from vehicle fleet management data. Vehicles can, for instance, apply anonymous credentials to attest their private involvement in a particular fleet. Thus, e.g. a bus of a given company entering a parking lot just requires a credential attesting the relationship between the bus (driver) and the company without disclosing any identifying information.

  • Loading zone management: drivers, fleet managers and road operators need support regarding booking, monitoring and management of the urban parking zones. They have the possibility to book in advance an urban loading bay specifying the delivery mission, the planned delivery time frame, the loading/unloading time required, the vehicle type and the estimated time to reach the parking zone. Anonymous credentials can be used to provide information preserving privacy, e.g. without disclosing vehicle’s owner identity when just the vehicle type is required.

Without ABCs, a naive provision of these applications involves the excessive disclosure of information, thus threatening users’ privacy. For example, in case of economic transactions, users have to provide their credit card information which discloses, among other issues, their names and surnames. Other examples are related to the vehicle’s type and the parking place. In the former case, vehicles’ logbook shows vehicles’ type and other data such as the vehicles’ identity number or where/who sold them. In the latter case, the parking place can be attested showing drivers’ identity card but it shows the exact location of drivers’ home together with additional data like drivers’ birth date.

4.2 Privacy requirements per use case

The set of identified use cases need privacy preservation to some extent. This section explores which requirements are present for each one. Tables 3 and 4 summarize the analysis presented herein, where √ means needed, √∗ desirable and − not required.

Table 3 Summary of privacy properties needed for each application
Full size table
Table 4 Summary of privacy-related properties needed for each application
Full size table

A total of 12 general VANET privacy requirements have been identified across works by different authors [17, 19, 20, 43, 48]. One important remark is that most of them are the same than the identified ABC features. This aspect is relevant to decide which ABC technique to apply for each VANET use case. This issue is studied in Section 4.3.

Among these 12 requirements, 6 of them are privacy needs (Table 3) whereas the remaining 6 are privacy-related ones (Table 4). With respect to the first group, the first requirement is minimal information disclosure, by which vehicles and drivers may disclose a set of attributes while keeping others hidden [46]. This need is present in all use cases, as it means to minimize the data leakage to the remaining entities.

On the other hand, conditional anonymity allows drivers and vehicles to be de-anonymized in cases of liability (e.g. due to offences) [43]. This action must be restricted to authorized entities and under certain circumstances. This is also needed in all use cases as this deters misbehavior.

A related requirement is having distributed (multi-party) inspection, by which de-anonymization is carried out by cooperation of several entities to prevent abuses. This is required in some applications, such as ITS local electronic commerce. In this use case, the bank together with the particular electronic service should cooperate to de-anonymize. On the contrary, this is not needed in fleet management and loading zone management. In the former use case, the fleet service is the only one interested in the inspection process and similarly, in the latter, the loading entity/manager is the only one who wants to perform the inspection process. Then, in both cases, abuses are not a concern.

Regarding privacy-preservation by continuous observation of a given vehicle, unlinkability comes into play.Footnote 2 This prevents two different transactions performed by the same vehicle to be linked. There are two variants of this requirement, namely issuance-show and multi-show unlinkability. In the former, the authority issuing a credential cannot link the credential with the presentation tokens being shown to a service provider. Thus, it is not needed in use cases in which the issuing authority is the same that checks the credentials or belongs to the public domain, such as limited access warning and detour notification. The remaining applications have this requirement. Consider ITS electronic commerce, the credential attesting having a positive account balance can be provided by a bank authority and verified by a given service provider.

With respect to multi-show unlinkability, it allows drivers and vehicles to prove possession of credentials (i.e. present tokens) multiple times without being linkable across different sessions, transactions or domains. This is needed in all identified use cases except for media downloading and fleet management. In both use cases, this requirement is desirable because even users are linked between different uses of a credential; they do not involve high privacy risk, in contrast to others like limited access warning and detour notification which, i.e. allow users tracking.

Another requirement is perfect forward privacy [48]. It states that the de-anonymization of one credential should only reveal information associated with such credential and should not reveal any information that could decrease the unlikability of other credentials of the same user. This requirement is present in all use cases to prevent abuses by collusion of different service providers. Otherwise, de-anonymizing a misbehaving driver of the access control use case could lead to guess that she was the same buying a given service through ITS electronic commerce.

Concerning privacy-related requirements, the first one is proof of holdership. Thanks to this, vehicles and drivers have the ability to prove holdership of a credential to a verifier without disclosing the actual credential. As in the previous case, this is critical for all use cases because all of them need to verify the possession before granting the service.

On the other hand, non-transferability prevents credential pooling by binding a set of credentials to a user’s (e.g. vehicle owner or driver) secret key. In this way, several users cannot collude to get a service that would be unattainable for them separately. Remarkably, this need is not present in fleet management, since a vehicle belonging to a company’s fleet may be driven by any employee, so the credential must be transferable between drivers.

The revocation requirement allows invalidating a credential when needed. This may be because of compromise (e.g. stolen vehicle) or due to credential refreshing (e.g. a vehicle’s owner changing his parking place). These two reasons may be present in all use cases, thus motivating this need for all of them.

Some use cases also require scope-exclusive pseudonyms. These pseudonyms are unique for a specific scope or application. This allows the provider to profile drivers and/or vehicles by ensuring that a single pseudonym is created from a corresponding credential. Four use cases have this requirement, namely enhanced route guidance and navigation, ITS local electronic commerce, media downloading and fleet management. The first three applications may involve belonging to a particular service, thus owning a credential regarding the use of such service. Additionally, fleet management involves attributes related to membership of a fleet which are limited to this scope. This requirement is desirable in all cases but not mandatory because, among other issues, these credentials are not expected to be used in other scenarios. Likewise, even these credentials were used in different scopes, these use cases do not involve high privacy risk by just avoiding the satisfaction of this requirement.

In scenarios in which service providers need to verify different credentials from a given user, cross-credential proving may appear. Thanks to this, multiple credentials from the same or different issuers can be jointly proven in the same presentation token; with this feature, vehicles and drivers are able to access joint services offered by different providers. This is the case of all applications except for fleet management and loading zone management. Credentals can be provided by, for instance, bank authorities, e.g. to attest positive balance; web services, e.g. to attest users membership; or council authorities, e.g. to attest the ownership of a parking place in a concrete area. For example, in media downloading, it may be needed to proof membership and a positive balance in the bank account. Conversely, regarding fleet management and loading zone management, the use of a single credential is identified and thus, this property does not apply.

Last but not the least, carry-over attributes allow that newly issued credentials may contain attribute values from other credentials without the issuer learning them. This feature is specially relevant in VANETs since some current credentials (e.g. taxes and licenses) are periodically renewed. It may be relevant to accumulate the seniority. It is a desirable property in all use cases except for fleet management and loading zone management as the credentials at stake are not likely to be renewable.

4.3 ABC techniques per use case. Theoretical analysis

Once the analysis of privacy features per VANET use case has been presented, a theoretical selection of the most suitable ABC technique is presented herein. In particular, recalling that each technique provides with a different set of privacy properties (recall Section 3.4), it is possible to determine which technique best fits for each use case.

In order to address this issue, it is necessary to clarify how ABC features and VANET requirements match. Particularly, it is noticeable that Selective disclosure of attributes and Predicate proofs Privacy-ABC features, are related to Minimal information disclosure in VANETs. Similarly, De-anonymization Privacy-ABC feature leads to Conditional anonymity and Distributed inspection VANETs properties. Moreover, Perfect forward privacy appears as a VANET privacy property which has not been currently implemented in Privacy-ABC.

Table 5 presents results of the analysis where √ means suitable, − the contrary and √∗ partially suitable. Concerning studied use cases, it is noteworthy that all of them can leverage Idemix since it provides with all privacy and privacy-related features.

Table 5 Analysis of ABC technique suitable for each use case
Full size table

On the other hand, media downloading can be addressed by all techniques though under several premises. U-Prove can be applied if multi-show unlinkability is avoided and Persiano updated can be used when scope-exclusive and carry-over attributes are not an issue. Besides, fleet management application can be applied by Idemix in any circumstances and by U-Prove as long as multi-show unlinkability is not at stake.

5 Tailoring ABCs to VANETs

Section 4 has shown different road traffic services for smart cities that could benefit from ABCs. Nevertheless, one open issue is how to adapt these mechanisms to vehicular networks. This section focuses on this matter. For this purpose, the VANET architecture presented in Section 3.1 is considered. Section 5.1 describes how each ABC role is taken by each VANET entity. Afterwards, Section 5.2 addresses how each phase is carried out in these networks.

5.1 Distribution of roles

This section describes how each ABC role may be implemented in the VANET context.

  • Issuer: this role can be taken by a regional vehicular registration authority, the vehicle manufacturer, public administration entities, or any service provider, such as telecommunication operators. The particular entity at stake depends on the considered ITS service. In any case, all of them are realized in a Central ITS station. In particular, there are two components of its ITS-SU at stake. The Applications one contains the issuance policy and the credential creation procedure itself. On the other hand, the Security one (and, in particular, its S-MIB and the HSM) is in charge of creating the credentials and storing the materials needed for future verification.

  • Users: this role is represented by vehicles and drivers. In the case of vehicles, ABCs will be bound to the owner of the vehicle (e.g. individual or a company). This decision is in line with current laws in several countries in which the owner is liable for traffic offences until the driver gets identified (e.g. UK, [1]). Thus, the OBU-internal ITS-SU comes into play. Particularly, the Applications element dictates when authentication is required, whereas the Authentication module of the Security element carries out the related cryptographic processes. For this purpose, again the S-MIB and HSM will cooperate.

    In the case of the driver, it is her personal ITS station which participates in the process. The elements at stake are the same than in the vehicle case.

  • Verifier: as it happened with the issuer role, different entities may be verifiers according to the service or application at stake. Thus, RSUs, other vehicles, public administration authorities (e.g. police and traffic authorities), and service providers (e.g. emergency services and location-based commercial services) may take this role. Therefore, this role may be performed through Road-side ITS stations, Central ITS stations or OBU stations. In all cases, the components at stake are Applications and Security in the same terms as in the issuance.

  • Revocation authority and inspector: revocation is a requirement to prevent misbehaving or faulty vehicles to communicate and threat the proper operation of the network. To this extent, the inspector becomes active in cases of accountability. These roles are mainly taken by the regional vehicular registration authority. Vehicle manufacturers and service providers may also take these roles in particular cases such as misuse. As in the previous cases, Central ITS stations are at stake, particularly their Applications and Security components.

5.2 Implementation of phases

This section shows how the general ABC phases (recall Section 3.2.2) are implemented in VANETs. Each one is studied below. We omit the sequence diagram for the Revocation phase since it is an internal process carried out by the credential issuer.

  • Set-up: all entities have to be equipped with required cryptographic materials. Importantly, credentials issued by a trusted CA (regional vehicular authority) are stored in the HSM of the ITS entity at stake (Roadside ITS station, OBU ITS station, Personal ITS station). The procedure is shown in messages 1–11 of Fig. 4. Management and distribution of the credential specification and issuer parameters can be done either leveraging on regular vehicular processes (e.g. yearly inspection, tax renewal, etc.) or using over-the-air (OTA) updates managed by the Security component. It must be noted that secure OTA software updates have already been considered for vehicular platforms [49].

  • Issuance: this phase is shown in messages 12–27 of Fig. 4. At first, the vehicle will provide either the CertID or the full certificate to the issuer (msg. 12). Such certificate could also consist of a short-term certificate based on an underlying pseudonym solution. The vehicle may provide with the requested proofs as introduced in Section 3.3. On successful validation, the issuer will then prepare the corresponding ABCs (msgs. 13–19). Simple issuance in VANET will include key binding (i.e. making two or more credentials bind to the same key). This will discourage users in VANETs to give away their credentials. Moreover, service providers may request users to prove that they are authorized to communicate in the VANET system, and at the same time authorized to access their resources. Thus, a proof of holdership of multiple credentials bound to the same key (i.e. cross-credential proving, recall Section 3.4) is needed. Carry-over credentials may also be issued, as a means of adding new properties to existing credentials (e.g. extensions to the insurance policy). Once created, these materials are sent to the OBU HSM (msgs. 20–27).

  • Presentation: this phase starts by creating the commitments that will be at stake to anonymously prove one or more attributes. The procedure is shown in Fig. 5. For the sake of simplicity, the message in which the prover asks for credentials is omitted from Fig. 5. Thus, after the said creation (messages 1–10), the verifier asks for the required proof considering a given policy (msg. 11). The Application component of the OBU collaborates with the Security MIB and the HSM to build up the presentation token according to the specified policy (msgs. 12–24). The Application at the verifier then checks the token validity and the commitment correctness (msgs. 25–39). It must be noted that for this purpose, its Security MIB and HSM are involved.

  • Revocation: there can be many reasons for revoking a credential, e.g. a malicious attacker sending spoofed or forged information that might jeopardize the security and safety of vehicles in the network. This process is carried out by the authority, being this information spread to all VANET entities to ensure a proper exclusion of revoked parties.

  • Inspection: this task has to be done by an authorized entity. In the VANET context, the traffic authority is the ideal holder of this matter. Other trusted service providers (e.g. technical inspection facilities) may take this role as well. The process is shown in Fig. 6. In this case, the central ITS station’s HSM is used to open the commitment (msgs. 1–5). This leads to obtaining the pseudonym under which the vehicle is operating. Based on this information, the Security MIB reveals which is the real identity of the misbehaving vehicleb (msgs. 6–9).

Fig. 4
figure 4

Setup and issuance phases of ABC according to VANET architecture

Full size image
Fig. 5
figure 5

Presentation phase of ABC according to VANET architecture

Full size image
Fig. 6
figure 6

Credential inspection phase of ABC according to VANET architecture

Full size image

6 Performance assessment

While the previous section focused on how ABCs may be integrated into VANETs, this section assesses the suitability of the said integration. Particularly, a performance comparison between Idemix, U-Prove and VANET-updated Persiano is presented. Considering this aspect as well as the provision of privacy properties (recall Section 3.4), Section 6.3 discusses the feasibility of each ABC technique in the considered use cases.

For this assessment, we have adopted the framework for evaluation of Privacy-ABC technologies proposed in [56]. We enhance this framework by considering additional criteria particularly useful for understanding the potential of ABCs in VANETs. Accordingly, we show empirical results obtained from a quantitative analysis focused on latency. We have used the ABC4Trust reference implementation [6] of a unified architecture for ABC technologies, which currently integrates Idemix and U-Prvove technologies, and the implementation of VANET-updated Persiano introduced in [25].

For the sake of simplicity, we did not use all of the criteria described in [56], but only those elements that were common for the three technologies and which we considered to be suitable for the scenarios we have chosen. Particularly, we evaluated the time taken for system setup, issuance, as well as time to do a presentation, which is split into two parts, namely proving, which happens at the User side (in our case, on the vehicle), and verification, which is done by the verifier (in our case, by the Central ITS Station). For all these phases, this assessment focuses on the computational time taken on same machine configurations. It must be noted that this time is independent of the particular road traffic scenario. Thus, network-related incidental factors such as the road design (which may affect coverage range) or vehicular density (which may alter channel availability) are left out of the analysis. Therefore, our analysis shows an unavoidable, lower-bound time taken to carry out these computations.

6.1 Experimental setup

We have considered different setups for the different entities, namely the Central ITS station and the OBU. In order to provide a modest setup for the Central ITS Station, we used a machine with an 8-core i7 CPU of 2.3 GHz and 8 GB of RAM. Regarding the OBU, we simulated the experiments on a less powerful machine with a 3-core CPU of 460 Mhz and 256 MB of RAM, comparable to state-of-the-art devices, such as the OBU-201U.Footnote 3 Thus, each of these machines carry out the steps and operations that correspond to its entity in every ABC technique.

We have performed a number of simulations using varying parameters, such as the number of attributes in a credential, disclosing (hiding) attributes, and increasing the key size for the crypto operations. For the sake of clarity, the performance of each phase for the three technologies is discussed separately. Each experiment has been run 50 times, showing the average herein. We assume credentials with 2, 5 and 10 attributes and key sizes 1024 and 2048 bits. We believe these values are representative, and appropriate from the security point of view [54]. Appendix presents the main data obtained from experiments, which are discussed herein.

6.2 Performance results

Regarding system setup (Fig. 7), all steps to generate the necessary cryptographic materials, including the public-private key pairs of the issuer and verifier, are measured. The most efficient technology regarding this phase is U-Prove, which completes the system setup in 2.5 and 24.3 s for key sizes 1024 bits and 2048 bits, respectively, followed by VANET-updated Persiano with 5.6 and 38.5 s and U-Prove with 14.8 and 58.5 s for key sizes 1024 bits and 2048 bits, respectively. Results show a significant increase for 2048 bits key, being specially remarkable in U-Prove whose suffers an increment of 1200%.

Fig. 7
figure 7

Evaluation for the impact of setup and issuance for all three technologies

Full size image

With respect to issuance (Fig. 7), a credential with five attributes using a 1024 bits key with VANET-updated Persiano takes on average 0.09 s, with U-Prove 2.1 s, whereas with Idemix 2.8 s For 2048 bits key, though the increase of VANET-updated Persiano is the highest one, it continues being the technology which produces the lowest impact in the issuance phase, it takes 0.6 s in comparison with U-Prove and Idemix which take 5.5 and 3.4 s, respectively. According to Section 3, these results are expected because U-Prove requires two rounds to complete the issuance while Idemix requires one. Likewise, VANET-updated Persiano needs to demonstrate the possession of attributes in an non-anonymous fashion. Note that, according to our experiments, issuance time is independent of the number of attributes and thus we have chosen five attributes as a representative value.

Certainly, the most relevant results for the use of these techniques while driving are those related to the presentation of Privacy-ABCs. In particular, proving possession of credentials (by the OBU) and verification of such proofs (by the Central ITS) are at stake. We have studied the performance for the three technologies using a cryptographic key size of 1024 bits when presenting a credential with five attributes and iteratively disclosing attributes (Fig. 8). It is identified that Idemix is the best choice, as it presents the lowest time either for proving or verification, while U-Prove and VANET-updated Persiano are comparable. Moreover, the number of disclosed attributes does not significantly affect computation time.

Fig. 8
figure 8

Evaluation for the impact of the selective disclosure on the time efficiency of presentation. Results based on the key size of 1024 bits and a credential with five attributes for all three technologies

Full size image

Similarly, Fig. 9 shows results for the same configuration but doubling the key size to 2048 bits. Though time increases in all technologies, the high computation time required in the proving phase is particularly remarkable in VANET-updated Persiano. Indeed, in this last technology, credential proving requires the computation of ZK-POKs which are highly affected by the key size [25].

Fig. 9
figure 9

Evaluation for the impact of the selective disclosure on the time efficiency of presentation. Results based on the key size of 2048 bits and a credential with five attributes for all three technologies

Full size image

Finally, the impact of the number of attributes on the presentation time for all three technologies is assessed (Fig. 10). Here, each technology is assessed when presenting (proving and verifying) credentials with respectively 2, 5 and 10 attributes using a key size of 1024 bits (2048 key size is not studied because VANET-updated Persiano produces very high impact, e.g. computation time for proving higher than 22 s.). It is identified that Idemix continues being the best alternative considering computation time and, though VANET-updated Persiano is worse at verification, it is comparable with U-Prove at proving and even better when 10 attributes are at stake.

Fig. 10
figure 10

Evaluation for the impact of the total number of attributes in a credential on the time efficiency of presentation. Results based on the key size of 1024 bits and no disclosed attributes for all three technologies

Full size image

6.3 Feasibility analysis and discussion

Given the different nature of the use cases at stake, the time constraints can be determinant to adopt or reject ABC techniques. To this extent, in this section, the time taken to carry out each phase is studied.

The first point to consider is the high impact of 2048 bits key specially for VANET-updated Persiano. The use of this technology and key size is not recommendable for use cases when significant immediacy is demanding, e.g. automatic access control. This result may be produced by the fact that while U-Prove and Idemix have tested and well-known implementations, VANET-updated Persiano implementation has not reached such a high level of maturity.

Regarding setup and issuance, both phases are computed by trusted authorities which are assumed to have stronger computational capabilities. Furthermore, involved communication is not an issue since they may take place in controlled scenarios (e.g. technical inspection).

The proving and verification steps of the presentation phase are the main challenge to address. Although the use cases at stake are not safety-related, a practical feasibility threshold exists. In case that a given ABC mechanisms takes too long to execute, the vehicle may be far away from its original location when the protocol started. This renders some use cases impractical. For example, the limited access warning use case is intended to warn approaching vehicles. If ABCs involve a huge time for execution, the vehicle may have passed through the controlled area. Similarly, the access control and parking use case cannot wait for a long time in practice—the vehicle must be authorized prior to area entrance (for security) and it cannot be stuck for a long time before leaving (for practical reasons). It must be recalled that this situation may get worse in geographically harsh scenarios or roads with high density, as the packet delivery ratio (which indicates the proportion of correctly received packets) decreases dramatically [2]. In such situation, re-transmission costs increase the mechanism latency. However, for the sake of consistency, in the following, we leave networking aspects out of the discussion.

Considering these issues, our feasibility analysis concentrates on the distance traveled by the vehicle while computing the proving and verification phases in each ABC mechanism. Thus, considering 42 m/s (i.e. around 150 km/h) as driving speed, 1024 bits for key sizes and five disclosed attributes, the vehicle will be moving for 115.1 m in VANET-updated Persiano, 102.5 m in U-Prove and 18.1 m in Idemix. If 2048 bits were considered, results would be affected specially in VANET-updated Persiano, requiring 1043.3 m to complete.

Combining the previous results with the theoretical suitability of ABC mechanisms per VANET use case (recall Section 4.3), an overall suitability can be concluded. Thus, Idemix is the most suitable technique since except for the issuance phase, it offers the best performance results. The reduced driving distance is specially relevant for uses cases in which DSRC communications technology comes into play. Recalling Table 2, it happens in the limited access warning, automatic access control, ITS e-commerce and loading zone management use cases. According to our findings, data transmission has to be carried out in 300 − 18.1 = 281.9 m driving distance for these use cases to be feasible, if 300 m is taken as the effective communication range [2] and no geonetworking or RSU handover is considered. Of course, this threshold can be raised by relaxing any of the previous conditions.

On the other hand, media downloading is also feasible by using U-Prove or VANET-updated Persiano. Nevertheless, U-Prove is dramatically more efficient than VANET-updated Persiano. Particularly, as four attributes are at stake in this use case (recall Table 2), U-Prove is almost three times faster than VANET-updated Persiano. This difference is relevant if the anonymous authentication is to be carried out periodically (e.g. after each downloaded chunk), as the shorter the process takes, the faster the download is completed.

Finally, recalling that both Idemix and U-Prove can be applied in the fleet management use case, Idemix is the most suitable choice for performance issues and the only one if multi-show unlinkability is needed.

7 Open research issues

The use of ABCs into smart city services built on top of VANETs opens the door to three main research directions, namely the real-world implementation and assessment of this technology, the extension to other use cases and the improvement of the cryptographic primitives at stake.

Concerning the real-world assessment, the networking aspect of ABC is a critical factor. Our results support the computational feasibility of ABCs in vehicular environments. Thus, they enable carrying out another step of experiments, which consider the impact of channel reliability. In particular, as vehicular density affects to the packet delivery ratio, it is important to assess the suitability of every ITS use case design in different road traffic scenarios, ranging from rural areas (with sparse RSU coverage and low traffic) to urban settings (with high RSU coverage and high density of vehicles).

Regarding the extension to other use cases, the following list may serve as a starting point for designing promising smart city services in which ABCs may be at stake:

  • Parking meter: modern cities usually have parking meters spread around them. Parking cost is dependent on factors like the type or the age of the vehicle to park. Some parking meters require the user to type the vehicle’s license plate. However, this enables a potential “big brother” effect by authorities. Thus, parking meter tickets have to be delivered just taking into account particular factors.

  • Start the vehicle: from the development of traditional keys to start vehicles until present time many techniques have emerged. Smart-keys are challenging developments in this regard which are applied by multiple carmakers [47]. These keys may have the look and feel of a card or just a small rectangular box. The point is that some vehicles may be driven by people who share some common features. For instance, bus drivers of company A are allowed to drive all buses of this company, thus each of them needs a personal key that attests their link with the company and can be used in all coaches. Furthermore, to avoid excessive surveillance, the actual identity of the driver should only be disclosed under particular circumstances (e.g. traffic offences).

  • Incentives for users profiling: in VANETs content dissemination scenarios, users and service providers may find a privacy-preserving tradeoff—service providers will be able to build profiles from anonymized users and deliver personalized services, while users might receive other incentives in exchange of disclosing their attributes, such as, special offers or discount coupons [32]. It must be noted that users must be able to control the amount and linkability of the information disclosed.

Implementation issues of ABCs have to be considered as well. In particular, improving HSM native support for ABCs could dramatically improve the overall performance. On the other hand, the development of Proofs of Knowledge (PoK) based on lightweight cryptography would be also beneficial. As OBUs are resource-constrained devices, leveraging on cryptography for similar environments (such as Internet of Things [5] or smart health [52]) is a promising approach.

8 Conclusions

Road traffic services are essential in the future development of smart cities. They can be designed on top of the upcoming vehicular ad hoc networks (VANETs). However, privacy aspects in this scenario must be addressed prior to their deployment. Multiple cryptographic approaches have been developed in this regard, particularly those focused on traditional PKI systems. However, in many situations, too much unnecessary data is delivered in contrast to the principle of minimum information disclosure. Attribute-Based Credentials (ABCs) help to address this issue by allowing the disclosure of only the necessary data. In this paper, the suitability of three prominent ABC techniques (U-Prove, Idemix and VANET-updated Persiano) to VANETs has been studied. A set of smart city services, chosen from ETSI’s Basic Set of Applications, has been considered for the analysis. Our results show that they are feasible according to current state-of-the-art devices and that they can be applied taking into account the standard vehicular architecture. Moreover, Idemix is the most promising approach for this scenario both in terms of performance and the set of smart city road traffic services that could adopt it.