A broadcast protocol with drivers’ anonymity for vehicle ...ece.eng.wayne.edu/~smahmud/PersonalData/PubPapers/IJVICS-2009.pdfvehicle-to-vehicle communication networks’, Int. J

Int. J. Vehicle Information and Communication Systems, Vol. 2, Nos. 1/2, 2009 1

Copyright © 2009 Inderscience Enterprises Ltd.

A broadcast protocol with drivers’ anonymity for vehicle-to-vehicle communication networks

Nader Mazen Rabadi and Syed Masud Mahmud* Electrical and Computer Engineering Department, Wayne State University, 5050 Anthony Wayne Dr., Detroit, Michigan 48202, USA Email: [email protected] Email: [email protected] *Corresponding author

Abstract: In Vehicle-to-Vehicle (V2V) communication networks, vehicles broadcast their safety-critical information to alert nearby vehicles of possible collisions. It is necessary to provide secure wireless communications for V2V safety applications to prevent unauthorised entities from tampering with the broadcast data. A Certificate Authority (CA) can provide trust and secure communications among drivers in V2V networks. However, the disclosure of drivers’ unique public keys from their certificates will allow unauthorised entities to trace drivers’ movements and locations they visit. Revealing such information without consent from drivers is a violation of their privacy. In this paper, we propose a broadcast protocol for V2V safety applications that provides anonymity for drivers. In our scheme, drivers frequently change their public keys using the digital signature algorithm. The CA is not required to authenticate the generated public keys. The recipients of a signed message can verify the correctness of the signature without identifying the signer.

Keywords: anonymity; authentication; DSA; digital signature algorithm; V2V networks; vehicle-to-vehicle networks.

Reference to this paper should be made as follows: Rabadi, N.M. and Mahmud, S.M. (2009) ‘A broadcast protocol with drivers’ anonymity for vehicle-to-vehicle communication networks’, Int. J. Vehicle Information and Communication Systems, Vol. 2, Nos. 1/2, pp.1–26.

Biographical notes: Nader Mazen Rabadi has been working as an Embedded Software Engineer in the automotive and the electric metering industries, since 1998. He received his BSc degree in Electrical and Computer Engineering from Philadelphia University, Amman, Jordan, in 1996, MSc degree in Computer Engineering from Wayne State University, MI, USA, in 1998 and PhD degree in Computer Engineering from Wayne State University in 2008. His research interests include security and anonymity in vehicle-to-vehicle and wireless communication networks, medium access control protocols, and intelligent transportation system technologies and applications.

Syed Masud Mahmud is currently an Associate Professor at Electrical and Computer Engineering Department, USA. He received his PhD degree in Electrical Engineering from the University of Washington, Seattle, USA, in 1984. Since 1988, he has been with Wayne State University, Detroit, MI. During the last 20 years, he has been working in the areas of hierarchical

2 N.M. Rabadi and S.M. Mahmud

multiprocessors, hierarchical networks, performance analysis of computer systems, digital signal processing, embedded systems, in-vehicle networking, performance analysis of networking protocols, secure wireless communications, and privacy protected inter-vehicle communications and simulation techniques. He has published over 100 peer-reviewed journal and conference proceeding papers.

1 Introduction

With the aid of Intelligent Transportation System (ITS) technologies, future vehicles will be able to communicate wirelessly with each other, and form Vehicle-to-Vehicle (V2V) communication networks (Intelligent Transportation Society of America, 2007; Intelligent Transportation Systems – US Department of Transportation, 2007). In V2V networks, vehicles broadcast their safety-critical information such as speed, acceleration, heading and position to nearby vehicles. Receiving vehicles will process such information and provide visual and audible alerts to their drivers to take preventive measures and avoid collisions.

V2V communication networks will utilise the new Dedicated Short Range Communications (DSRC) (ASTM, 2003) at 5.9 GHz. A comprehensive list of vehicle safety applications that are enabled by DSRC was compiled (National Highway Traffic Safety Administration – US Department of Transportation, 2005). More than 75 application scenarios were identified and analysed such as intersection-collision avoidance, rear-end collision avoidance and post-crash warning system. These safety applications require a high processing speed, low communication latencies and short message lengths.

It is essential to provide secure communications among vehicles in V2V networks. Vehicles that are participants in V2V networks should be able to authenticate each other and verify the integrity of the safety-critical information. Unauthorised entities to the network can masquerade as trusted participants in V2V networks and can broadcast inaccurate safety-critical information to other vehicles. Furthermore, they can tamper with the contents of the broadcasted messages and retransmit inaccurate information to vehicles on the road.

The challenges of authentication and data integrity in V2V networks can be solved using cryptographic public-key algorithms, digital signatures and Public Key Infrastructure (PKI). A level of trust between users of public keys deemed necessary to establish the public-key certification infrastructure. PKI relies on trusted third-party Certificate Authorities (CA) to verify and authenticate the validity of users involved in secure communications. The CA issues a certificate for endorsing the user’s public key. One of the well-known certificate formats is the standard public key certificate framework X.509. The certification is a process of binding a public key to its owner. The certificate contains information about the identity of the holder, the validity period, the certificate issuer name, the encryption method used by the CA and the digital signature of the certificate signed by the CA.

Figure 1 shows our proposed in-vehicle network architecture. Vehicles will be equipped with a DSRC Electronic Control Unit (ECU) that handles the transmission and reception of messages containing safety-critical information. In order to transmit a

A broadcast protocol with drivers’ anonymity 3

message, several ECUs inside a vehicle, such as GPS, compass, brake and speed ECUs, collect data from the vehicle’s sensors about its position, direction, deceleration and speed, respectively. Nowadays, vehicles have an internal network communication bus, such as the controller area network, which connects these ECUs together. The collected data are then sent through the vehicle’s internal network communication bus to a Crypto ECU. We assume there is a Crypto ECU that is connected to the internal network communication bus. The Crypto ECU assembles these data into a message and performs the necessary cryptographic algorithms and protocols on this message to produce a cipher-text message. Then it sends the cipher-text message to the DSRC ECU, which in turn broadcasts the message to nearby vehicles. Similarly, when the DSRC ECU receives a cipher-text message, it forwards the message to the Crypto ECU. The Crypto ECU performs the necessary cryptographic algorithms to authenticate and validate the integrity of the cipher-text message and extracts from it the plain-text message. Then, the Crypto ECU forwards the plain-text message to the Driver Information ECU for evaluation and for issuing audible and warning messages to the driver if necessary.

The Crypto ECU will also have the driver’s certificate that is issued by the CA. When a vehicle is ready to broadcast a message that includes its safety-critical information, the Crypto ECU includes the driver’s certificate in the message as well. Vehicles that receive the broadcasted message authenticate the transmitter using the included certificate. Accordingly, the transmitter’s public key will be revealed to other drivers and to any unauthorised entities listening to the communication channel. Since a public key is bound to its owner, the disclosure of the driver’s unique public key from the driver’s certificate will allow unauthorised entities to trace driver’s movements and locations this driver visits. Revealing such information without consent from the driver is a violation of the driver’s privacy. If an algorithm is used to keep the identity of drivers anonymous, then it may not be easy to identify the source that sent forged information or that caused accidents.

In this paper, we propose a broadcast communication protocol for V2V safety applications that provides drivers with anonymity, message authentication and data integrity. The main goal of this work is to preserve drivers’ anonymity from any unauthorised entities listening to the channel during the broadcast of safety-critical messages. The unauthorised entities may include other drivers, attackers and adversaries to the V2V network. As we describe later in this paper, CA, law enforcement agencies or legal authorities may identify drivers in case of disputes and emergencies. We would like to emphasise again that the main goal of this paper is not to preserve the anonymity of drivers from legal authorities including the CA.

The rest of the paper is organised as follows. In Section 2, we review the related works. In Section 3, we discuss our motivation and contributions in this paper. In Section 4, we present the security framework for designing our proposed protocol. In Section 5, we describe our proposed protocol. In Section 6, we discuss the anonymity and security analysis. In Section 7, we discuss the key management in our protocol. In Section 8, we present the performance analysis of our protocol. Finally, we conclude the paper in Section 9.


2 Related work

There are several papers that pointed out the importance and necessity of protecting the privacy of drivers (El Zarki et al., 2002; Holtmanns, 2002; Brodie et al., 2004; Raya and Hubaux, 2005). Current and future drivers may use mobile commerce services in their vehicles for safe and efficient driving. Such services include emergency roadside assistance, navigation information, email, automatic toll payment and pay-for-use rental and insurance. These services may collect information about the location of vehicles, personal health information of drivers and the behaviour of the drivers. Duri et al. (2004) and Bohrer et al. (2003) proposed a framework in which drivers can choose the amount of disclosed personal information to these services. Service providers can provide drivers with several policies with different degrees of protecting the privacy of disclosed personal information. The higher the degree, the more expensive the policy is. Gollan and Meinel (2002) addressed the problem of data privacy when utilising GPS devices. They suggested that if a consumer owns a vehicle, the consumer must have the option to switch off the location service or to give consent every time the service is used. Hubaux et al. (2004) proposed that authorities must provide each vehicle with a private/public key pair, along with a shared symmetric key. Vehicles authenticate each other via authorities. They argued that the public would accept and agree to trace their movements for the sake of improved safety. However, the authors suggested a scheme to protect user’s privacy. The certified public keys must be pseudonyms that change over time. Only authorities should be able to determine the relationship between a pseudonym and its real identity. Blum and Eskandarian (2004) described their work of building a Secure Communication Architecture (SecCar) for use with V2V networks. SecCar will be able to detect security attacks, continue operations under attacks, restore the system’s functionality after an attack and lock out malicious users to prevent further attacks. The architecture is based on PKI and digital signatures. In SecCar architecture, an authentication service can discover the identity of malicious users, while preserving the privacy of all other users. They also proposed to use a virtual network infrastructure where vehicles serve as the infrastructure. The authors proposed that this virtual network would provide security and scalability in V2V networks where infrastructure does not exist. Vehicles of virtual networks would provide access control and guarantee message delivery.

Sampigethaya et al. (2005) proposed a scheme, named CARAVAN, to protect the drivers’ location privacy. Each vehicle in their scheme is pre-loaded with a set of pseudonyms, a pair of public/private keys and a corresponding public key certificate for each pseudonym. All communications from a vehicle must contain one of its pseudonyms to avoid traceability. Only the trusted authority has the association between a vehicle’s pseudonyms and the identity of the vehicle’s owner. They also proposed a silent period between two consecutive transmissions to avoid linkability. Furthermore, their scheme relies on vehicles to form a group among each other. When a group of vehicles have the same driving conditions on the road, then according to the authors, it is sufficient for one of the vehicles to communicate with the trusted authority on behalf of other members. The reason behind forming this group is to provide privacy of drivers even while communicating with trusted authorities. A group leader has the role of communicating with a trusted authority infrastructure to obtain a symmetric key for one of the group member. This symmetric key will be used by the member of the group with


the trusted authority. Papadimitratos et al. (2006) and Raya et al. (2006a, 2006b) discussed a set of security requirements for V2V networks; such as message authentication and integrity, message non-repudiation, entity authentication, access control, message confidentiality, privacy and anonymity, network availability and liability identification. They also proposed a system and communication model for securing V2V and Vehicle-to-Infrastructure (V2I) networks. The authors discussed the use of anonymous public keys in V2V networks that are frequently changed depending on a vehicle’s speed. They also discussed the use of symmetric keys to reduce the cryptographic overhead. They proposed that vehicles can form a group and a group leader distributes to its members a symmetric key using the Group Key Management Protocol GKMP (Harney and Muckenhirn, 1997).

Several secure protocols were proposed for mobile users in wireless networks (Papadimitratos and Haas, 2003; Zhu et al., 2004; Zhou et al., 2005). These protocols assume the existence of a key-management system or public-key certification infrastructure. Capkun et al. (2004) presented a Dynamic Public Key scheme to protect anonymity and location privacy. Their approach is based on frequently changing node’s cryptographic keys, which enable users to avoid being identified by locations they visit. The network operator has access to locations and identifiers of registered mobile users. Each node has public/private key pairs and certificates signed by the CA. Key pairs can be generated either by the node or by the CA. Then, using the public/private key, each node establishes symmetric secret keys with its neighbours. Each time a node changes its public/private key pair, the CA authenticates the new pair. Then, this node establishes new symmetric keys with its neighbours. This approach is efficient but requires a high communication cost between the central authority and mobile users to certify new generated keys. Furthermore, it requires an additional communication cost to establish new symmetric secret keys with neighbours.

Zhu and Ma (2004), Asokan (1994), Samfat and Molva (1994), Askwith et al. (1997) share a similar approach in proposing an authentication scheme with anonymity. The approach is based on issuing a temporary certificate to a mobile user. First, the user registers at a Local Certificate Authority (LCA) and obtains a smart card that contains the identity of the LCA. When a user enters an area where the LCA is not available, the user has to establish a secure link with an available CA, called Remote Certificate Authority (RCA). The RCA will authenticate the user through the LCA via routers using the user’s smart card. If the RCA authenticates the user successfully, then the RCA issues a temporary certificate to the user. This temporary certificate can then be used when exchanging messages in V2V networks. Similarly, this approach requires a high communication cost and additional processing time between several central authorities and mobile users to certify the temporary certificate.

There are several research works that deal with anonymity of users. These works are based on the concept of group signatures (Chaum and van Heyst, 1991). Users are organised into groups. A group member signs messages anonymously on behalf of the group. Recipients of a signed message can verify the correctness of the signature without identifying the signer. In case of a dispute, the identity of the member who signed the disputed message can be revealed only by a designated entity (e.g. CA). Several group signatures have been proposed (Ateniese et al., 2000; Bresson and Stern, 2001; Song, 2001; Ateniese and Tsudik, 2002; Goh and Jarecki, 2003; Popescu et al., 2003; Boneh et al., 2004; Camenisch and Groth, 2005). All these research works are proved secure


under certain theoretical assumptions such as strong RSA assumption and strong Diffie-Hellman assumption. The basic operation of these works is the transformation of a secure honest-verifier zero knowledge protocols into digital signatures using the Fiat-Shamir heuristic (Fiat and Shamir, 1987). These group signatures are computationally intensive and produce long signatures.

3 Motivation and contribution

3.1 Motivation

In V2V networks, it is necessary to provide low-latency and secure communication protocols with minimum processing time, while preserving the anonymity of drivers. Furthermore, every broadcast message will be signed by its transmitter to support source authentication and data integrity. According to Boneh et al. (2004), there is a hard requirement that the length of each signature be under 250 bytes.

As we discussed in the previous section, the related work utilise the infrastructure CA frequently in request for a new pair of private/public key. Furthermore, new symmetric keys have to be established with nearby users in order to complete the authentication process. Their approaches require additional communication cost and processing time to V2V networks. Furthermore, the research works that proposed group signatures have not been standardised and not been proved its applicability in wireless mobile applications such as V2V safety applications. Although these works in group signatures are secure, there are two disadvantages to V2V networks. First, the processing speed is very slow. Second, the size of digital signatures generated by these research works is too long. However, Boneh et al. (2004) proposed a group signature that generates a signature of length ~192 bytes.

In this paper, we were motivated to provide anonymity for drivers with a signature length less than 192 bytes. Furthermore, we were motivated to reduce the communication cost between vehicles and the infrastructure CA.

3.2 Contribution

In this paper, we propose a broadcast protocol that provides drivers with anonymity, message authentication and data integrity using the Digital Signature Algorithm (DSA). The length of the signature in DSA is 40 bytes. Thus, compared with the work of Boneh et al. (2004), we improve the message signature overhead by 152 bytes (79%). Drivers generate and change their own set of public keys frequently using the DSA. Unlike previous works (Asokan, 1994; Samfat and Molva, 1994; Askwith et al., 1997; Capkun et al., 2004; Zhu and Ma, 2004; Zhu et al., 2004; Zhou et al., 2005), in our approach the CA is not required to authenticate the frequently generated public keys. When a driver changes its own public keys, it is hard to trace driver’s movements and locations that driver visits. Recipients of a signed message can verify the correctness of the signature without identifying the signer. In case of a dispute and malicious activities, the identity of the driver who signed the disputed message can be revealed only by the CA. In our proposed protocol, we avoided the additional communication cost and processing time


that previous related works have. We also prove in Sections 5 and 6 that the DSA can be used to provide anonymity and security for drivers in V2V networks. We also discuss in Section 7 key management and propose a communication protocol between vehicles and the CA for updating the required keys when the validity period of keys expires. Finally, we compare our protocol with the previous related works in group signatures.

4 Security framework

The main objective of this work is to build a secure communication broadcast protocol that is based on two existing technologies: (1) tamper-resistant hardware and (2) the standardised DSA.

4.1 Tamper-resistant hardware

The National Institute of Standards and Technology (NIST) (which is an agency of the US Department of Commerce) publish standards recommending practices for securing information and media. The standards are called the Federal Information Processing Standards (FIPS) publications. These are issued by NIST after approval by the Secretary of Commerce. One of the standards is FIPS 140-2 (National Institute of Standards and Technology, FIPS PUB 140-2, 2001) which defines security requirements for cryptographic modules. A cryptographic module is a set of hardware, software or both that implements cryptographic algorithms and key generation. FIPS 140-2 was developed by a US government and industry working group. The working group identified 11 requirements for cryptographic modules to conform to the standard, and four security levels for each of the 11 requirements. These security levels provide cost-effective solutions for different applications and data protection. Beginning with Level 0, each security level is an increase in security requirements over the preceding level. The requirements also refer to the Over-The-Air-Rekeying (OTAR) (New Technology Standards Project, OTAR protocol, 1996) protocol, if key generation and delivery over the air is desired between a management entity (e.g. a CA) and a mobile node. A brief representation of the 11 requirements and the four security levels is described next. For detailed and complete descriptions of these requirements and their security levels, we refer the reader to FIPS 140-2.

1 Requirements for a cryptographic module

• Requirement 1: Cryptographic module specification – it describes the components of a cryptographic module; hardware, software, firmware and security algorithms. It also specifies what the vendor of a cryptographic module should document in terms of the operation of each component, hardware schematics and software requirements.

• Requirement 2: Cryptographic module ports and interfaces – it describes logical interfaces to a cryptographic module; specifies requirements for data input interface, data output interface, control input interface, status output interface and power interface.


• Requirement 3: Roles, services, and authentication – it describes specifications for a cryptographic module to identify and authenticate its users: a role- or identity-based authentication. It describes also services that a cryptographic module should provide to its users such as status indicators, self-testing and security algorithms.

• Requirement 4: Finite state model – it describes specifications for a cryptographic module to operate in a finite state model. The requirement specifies that a cryptographic module should have operational and error states and should specify the transition from one state to another and the inputs and outputs for each state.

• Requirement 5: Physical security – it describes specifications on how to protect a cryptographic module from physical security attacks. It also describes the specifications for a cryptographic module to operate under a range of environmental condition such as voltage and temperature. A cryptographic module should provide assurance that its security cannot be compromised if an attacker applies extreme environmental conditions that reveals the contents of a cryptographic module.

• Requirement 6: Operational environment – it describes specifications on using an operating system in a cryptographic module.

• Requirement 7: Cryptographic key management – it describes specifications on the mechanisms for generating random numbers, generating keys, establishing keys, storage of keys and erasure of keys.

• Requirement 8: Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) – it describes specifications for a cryptographic module to comply with a standard EMI/EMC.

• Requirement 9: Self-tests – it describes specifications on the mechanisms for self-testing the security algorithms used in a cryptographic module, and testing the integrity of its firmware to ensure that the module is working and functioning as required.

• Requirement 10: Design assurance – it describes specifications on methods, processes and best practices to ensure that the requirements, designs, implementation and testing of a cryptographic module is well documented and that the module is properly designed, developed, tested, delivered and installed at the user’s location.

• Requirement 11: Mitigation of other attacks – it describes specifications for mitigation of security attacks that this FIPS document did not provide testable security requirements at the time it was published.

2 Security levels of a cryptographic module

• Security Level 1: It is the lowest level of security. In this level, at least one approved security algorithm [National Institute of Standards and Technology FIPS PUB 140-2 (2007), Annex A] shall be used in a cryptographic module.


• Security Level 2: It provides an increase in security over Level 1 by adding a physical security mechanism to a cryptographic module. This increase in security shall be accomplished by adding the requirement for a tamper-evidence mechanism. For example, the use of tamper-evident coatings or seals are placed on a cryptographic module in such a way that to gain physical access to the module and to access its plaintext cryptographic keys and parameters, the coating or seal must be broken.

In addition to the physical security mechanism, Security Level 2 requires the cryptographic module to authenticate the authorisation and role of its operator to perform a corresponding set of security services.

• Security Level 3: It provides an increase in security over Level 2 in tamper-evident physical security mechanisms. Security Level 3 requires the cryptographic module to have a high probability of detecting tampering and physical access, and is required to use a tamper detection/response circuitry that clears all plaintext secret keys if the tamper-evident mechanisms are broken.

Security Level 3 also enhances the role-based authentication of Security Level 2, by using identity-based authentication mechanisms. A cryptographic module authenticates the identity of an operator in order to perform a corresponding set of security services.

Security Level 3 also requires storing or reading plaintext keys from a cryptographic module to be performed on dedicated interfaces or ports that are not shared with any other data. Plaintext private keys may be entered into or output from the cryptographic module in encrypted form.

• Security Level 4: It is the highest level of security defined in the standard. In this level, the cryptographic module has a very high probability to detect all unauthorised attempts to access its contents resulting in the immediate erasure of all plaintext private keys and security parameters. Security Level 4 cryptographic modules are useful for operation in physically unprotected environments.

In addition, Security Level 4 protects a cryptographic module against environmental conditions or fluctuations outside its normal operating range that can compromise its security. An attacker can apply intentional fluctuations of voltage and temperature beyond the normal operating ranges of the cryptographic module to thwart its security defences. Thus, Security Level 4 requires the use of special environmental protection features designed to detect fluctuations and erase the contents of the cryptographic module.

A list of validated cryptographic modules against FIPS 140-2 can be found at the NIST Cryptographic Module Validation Program (CMVP) website (National Institute of Standards and Technology, CMVP, 2008). Nowadays, smart cards (Smart Card Alliance, 2007) are used worldwide for authentication for many applications. A hardware device, such as a smart card, that contains cryptographic keys and algorithms is considered secure if it has the following properties (Gennaro et al., 2004): (1) read-proof hardware: that is, a hardware device that prevents an attacker from reading anything about its contents; (2) tamper-proof hardware: that is, a hardware device that prevents an attacker


from changing its contents and (3) self-destructing capability: that is, a hardware device that can destroy its contents if an attacker tries to access it. In this paper, we refer to the hardware device that meets the security requirements and properties that are described in this section as a tamper-resistant hardware. The Crypto ECU that is shown in Figure 1 is assumed to be a tamper-resistant hardware that meets Level 4.

Figure 1 A set of ECUs connected through a vehicle’s internal communication bus

4.2 Digital signature algorithm

Digital signature algorithm is an algorithm used only for digitally signing messages. The NIST proposed it for use in their digital signature standard. The algorithm uses the following parameters:

p a 1024-bit prime number

q a 160-bit prime divisor of p – 1, where 2159 < q < 2160

x a randomly generated number less than q

H(m) a one-way hash function of message m

h a number less than p – 1 such that h(p – 1)/q mod p > 1.

Then, ( 1) / modp qg h p−≡ (1)

mod .≡ xy g p (2)

The public keys are p, q, g and y. The private key is x. To sign a message, m, a user generates a random number k less than q. The parameter k must be regenerated for each signature. Then the user computes ( mod ) modkr g p q≡ and ( )1( ( ) )s k H m x r−≡ ⋅ + ⋅


mod q. The signature is (r, s). To verify the signature, compute w ≡ s–l mod q, ( )1 ( ) mod≡ ⋅u H m w q , 2 ( ) mod≡ ⋅u r w q and ( )1 2( ) mod mod≡ ⋅u uv g y p q . If v = r,

then the signature is verified.

5 Proposed protocol

In this section, we describe our proposed protocol to preserve the anonymity of drivers in V2V networks. Our proposed protocol consists of four procedures: (1) generating membership keys and certification, (2) signing messages, (3) verifying messages and (4) opening messages. The following is a description of these four procedures.

5.1 Generating membership keys and certification

Let { }1 2, , , nG G G G= be a set of n groups of vehicles, and let ∈jG G . Let

{ }1 2, , mj j jM M M M= be a set of m vehicles in Gj and let ∈i

j jM G . The CA randomly

arranges registered vehicles into groups in its secure database and generates two sets of keys:

First set of keys: The CA uses DSA to generate a set { }1 1 1 2 2 2( , ), ( , ), , ( , )n n np G p q G p q G p q= ← ← ←… of n distinct pair of public keys.

Each pair of public keys ( , )j jp q P∈ is certified by the CA. Then, from a pair of public keys ( , )j jp q , the CA uses the DSA to generate a set

{ }1 1 2 2, , m mj j j j j j jX M x M x M x= ← ← ←… of m distinct private keys, where

1 2{ , , , }j nX X X X X∈ = . The CA maintains in its secure database the set Xj and its associated pair of public keys ( , )j jp q . Figure 2 shows a database of the n distinct pair of public keys in set P and their m distinct private keys in set X.

Second set of keys: The CA uses DSA to generate a set { }1 1 1 1 1 1 2 2 2 2 2 2( , , , , ), ( , , , , ), , ( , , , , )n n n n n nP G p q g y x G p q g y x G p q g y x′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′= ← ← ←… of n

distinct groups of public and private keys. Each group of public and private keys ( , , , , )j j j j jp q g y x P′ ′ ′ ′ ′ ′∈ is certified by the CA. Figure 2 shows the CA’s database that contains all the necessary keys.

Before participating in V2V networks, each driver applies for a certificate from the CA. The CA associates the driver’s vehicle to a group ∈jG G , and allows the driver’s

vehicle to be a member ∈ij jM G . Assume a secure communication channel between the

CA and a tamper-resistant hardware. Then the CA stores inside the tamper-resistant hardware of i

jM two sets of keys: the first set of keys ( , , )ij j jp q x and the second set of

keys ( , , , , )′ ′ ′ ′ ′j j j j jp q g y x . The CA securely installs the tamper-resistant hardware inside

the driver’s vehicle, ijM . Vehicle i

jM is now ready to participate in V2V networks. Figure 3 shows the assignment of the first and second set of keys among three groups of vehicles, where each group has four vehicles.


Figure 2 The distribution of DSA keys in a database where the private keys

{ }1 2, , , mj j jx x x… are associated with a pair of public keys (pj, qj) and

the second set of keys ( , , , , )′ ′ ′ ′ ′j j j j jp q g y x

Figure 3 The distribution of keys to members of V2V network by a CA


5.2 Signing messages

To protect the anonymity of drivers, each vehicle with a tamper-resistant hardware that is provided by the CA can sign messages using the DSA. The following three theorems provide the basis for our proposed anonymity protocol that uses the DSA. Theorem 1 states that the generated public keys that are used to sign messages by a vehicle are distinct. Hence, the anonymity of drivers is protected by these distinct public keys. Theorem 2 states in general that it is sufficient to choose a residue from a range of values in a set of rth root residues modulo n. This theorem provides us with a condition to generate distinct public keys. Therefore, Theorem 3 applies Theorem 2 to our proposed anonymity protocol that uses the DSA to generate distinct public keys.

Theorem 1: For a given pair of DSA public keys ( , )j jp q for ,i ij j jM G M∈ generates qj

distinct public keys { },,1 ,2, , ji qi ij j jg g g .

Proof: According to DSA, let ( 1) / modj jp qj jg h p−≡ for 1 ( 1)< ≤ −jh p By the definition

of the Order of a Group, the group of ( 1) /j jp qh − is an order qj subgroup of h since qj is

the least integer satisfying ( )( 1) / 1mod− ≡j

j jqp q

jh p , where ( )( 1) / 1modj

j j jqp q p

jh p h− −=

mod pj = 1 by Fermat’s Little Theorem. Hence, the qj subgroup h generate qj distinct public keys { },,1 ,2, , , ji qi i

j j jg g g . It can also be concluded that the polynomial ( 1) /− − =j jp q

j jh kp g , for some integers k, has ( 1) /j jp q− roots for 1 ( 1)< ≤ −jh p .

Hence, the number of distinct gj equals to ( 1)

( 1) /−

=−j

ij j

pq

p q.

Definition 1: Let integer n > 1. For *∈ na Z , a is called rth root residue modulo n if ra x≡ mod n for some ∈ nx Z . The set of rth root residues modulo n is denoted by RRn.

Theorem 2: For a prime number p, the relationship { }| 0 ( 1) / 2rpRR x mod p x p= < ≤ −

holds if r is an even number.

Proof: Assume an integer pa RR∈ such that a ≡ xr mod n for some ( 1) / 2≤ −x p .

Assume that x > (p – 1)/2, then p – x < (p + 1)/2. This implies that ( 1) 12

pp x +− ≤ − and

( 1) / 2p x p− ≤ − for a prime integer p. Let a' ≡ (p – x)r mod p. Using the binomial formula, we get the following:

1 2 2 3 3( 1) ( 1)( 2)( ) ( ) ( ) ( ) ( ) .2! 3!

− − −− − −⎛ ⎞′ ≡ − ≡ + − + − + − + + −⎜ ⎟⎝ ⎠

…r r r r r rr r r r ra p x mod p p rp x p x p x x mod p

Since p mod p = 0, ( )ra p x′ ≡ − mod ( )rp x≡ − mod p. If r is an even number, then

( )ra x′ ≡ mod p ≡ a. Hence, { }| 0 ( 1) / 2= < ≤ −rpRR x mod p x p , which is also equal to

{ }| ( 1) / 2 ( 1)rx mod p p x p− < ≤ − .


Theorem 3: For a given pair of DSA public keys (pj, qj) for ∈ij jM G ,

the public key gj, generated by the vehicle, satisfies the relation

{ }( 1) / | 0 ( 1) / 2−∈ = < ≤ −j j

j

p qj p j jg RR h mod p h p .

Proof: According to DSA, the public key pj is a prime modulus and the public key qj is a prime divisor of pj – 1. Then, (pj – 1)/qj is an even number. Hence, by Theorem 2, we get

{ }( 1) / | 0 ( 1) / 2−∈ = < ≤ −j j

j

p qj p jg RR h mod p h p . In other words, to generate the public

key gj it is sufficient to choose 1 ( 1) / 2jh p< ≤ − since the same gj will also be generated for ( 1) / 2 ( 1)− < ≤ −j jp h p .

Therefore, the tamper-resistant hardware stored in the driver’s vehicle ijM uses DSA and

the keys ( , , )ij j jp q x that are obtained from the CA to generate its own set of public keys

{ }, ,,1 ,1 ,2 ,2( , ), ( , ), , ( , )j ji q i qi i i ij j j j j jY y g y g y g= from (2). The pair , ,( , )i z i z

j jy g Y∈ (where the

index z = 1, 2, …, qj) and ijx are the public keys and private key of the vehicle i

jM , respectively. When the tamper-resistant hardware frequently generates a different pair of public keys , ,( , )i z i z

j jy g , it is made hard to associate those public keys to a driver and trace locations the driver visits. We show in Section 6 the anonymity and security analysis of our protocol. If a generated pair of public keys , ,( , )i z i z

j jy g is constant and never changes,

i.e. { }, ,,1 ,1 ,2 ,2( , ) ( , ) ( , )j ji q i qi i i ij j j j j jY y g y g y g= = = = as with the standard DSA, then this

pair of public keys is always bound to its owner, the driver. As a result, it would be easy to trace this individual driver.

After generating the keys, the tamper-resistant hardware uses DSA to generate a signature Sig1(msg) on message msg. The message msg contains

, ,i z i zj j j jDATA y g p q TimeStamp (where || denotes concatenation). The transmitted

DATA contains the safety-critical information of the transmitting vehicle. We use TimeStamp in signatures to protect the protocol from replay attacks.

The public keys , ,( , , , )i z i zj j j jy g p q are transmitted in plaintext for use by the receiving

vehicle to verify the received signature. Since , ,( , )i z i zj jy g are generated by i

j jM G∈ and are not certified by the CA, an unauthorised entity listening to the network channel can obtain the public keys ( , )j jp q and then generate an arbitrary set of keys , ,( , , )i z i z i

j j jy g x− − − such that (2) is satisfied. Therefore, this unauthorised entity can generate a valid signature but with forged information. Consequently, the receiving vehicle will successfully verify and authenticate the received forged information. In addition, the association between the pair of public keys ( , )j jp q and private keys

{ }1 1 2 2, , , m mj j j j j j jX M x M x M x= ← ← ←… that the CA maintains in its secure database

will no longer be valid. To protect our protocol from this attack, the tamper-resistant hardware signs the

signature Sig1(msg) using the second set of keys ( , , , , )′ ′ ′ ′ ′j j j j jp q g y x . Signing the signature using the second keys ensures the authenticity of the transmitted message since all keys


of the second set are certified by the CA. As shown in Figure 4, the message to be broadcasted to other vehicles is Tx = msg || Sig1(msg) || Sig2(Sig1(msg)|| msg), where

, , ′ ′ ′ ′= i z i zj j j j j j j jmsg DATA y g p q p q g y TimeStamp .

Figure 4 The sign procedure by the member ij jM G∈ on msg using the DSA and

the keys , ,( , , , , )i z i z ij j j j jy g p q x and ( , , , , )′ ′ ′ ′ ′j j j j jp q g y x

5.3 Verifying signatures

The receiving vehicle with a tamper-resistant hardware provided by the CA applies the DSA verification algorithm to verify the signatures Sig2(Sig1(msg)||msg) and Sig1(msg), as shown in Figure 5. If the DSA verification passes, then the receiving vehicle accepts this message and its contents. The message and its signature are stored in the tamper-resistant hardware of the receiving vehicle for use by the CA to open the signature, if it is needed, as explained next.

Figure 5 The verify procedure using the DSA verification and the keys , ,( , , , )i z i z

j j j jy g p q and ( , , , )′ ′ ′ ′j j j jp q g y


5.4 Opening signatures

By storing incoming messages inside a tamper-resistant hardware in the receiving vehicle, the CA can identify malicious members as follows. The CA obtains from the stored message, msg, the public keys , ,( , , , )i z i z

j j j jy g p q . Then the CA gets from

its database the set of private keys { }1 1 2 2, , , , m mj j j j j j jX M x M x M x= ← ← ←… that is

associated with group public keys ( , )j jp q . For each private key in set Xj, the CA applies

(2) using , ,( , , )i z i zj j jy g p . The private key, i

jx , that gives ,( )ijxi z

jY g≡ mod pj equals to ,i zjy identifies the vehicle that transmitted the message msg. Otherwise, the CA applies

the next private key to this process until a key is identified.

6 Anonymity and security analysis

6.1 Anonymity and unlinkability

Unlinkability is a property that must be met in communication protocols that provide anonymity. Signatures are unlinkable if it is computationally hard to decide whether any two different signatures have been computed and produced by the same person (Ateniese and Tsudik, 2002; Popescu et al., 2003). Assume in our protocol that i

jM generates two signatures: (1) signature (r, s) using ,1 ,1( , , , , )i i i

j j j j jy g p q x , and then signing (r, s) using

( , , , , ).j j j j jp q g y x′ ′ ′ ′ ′ (2) Signature ( , )r s using ,2 ,2( , , , , ),i i ij j j j jy g p q x and then signing

( , )r s using ( , , , , ).j j j j jp q g y x′ ′ ′ ′ ′ Linking the two signatures (r, s) and ( , ),r s and their public keys ,1 ,1( , , , , )i i i

j j j j jy g p q x and ,2 ,2( , , , , ),i i ij j j j jy g p q x respectively, is possible if

an attacker can decided from (2) that ( ) ( ),1 ,2,1 ,2 .i i

j j

i i ij j jg g

log y log y x= = In order for the

attacker to solve ( ),1,1

ij

ijg

log y or ( ),2,2

ij

ijg

log y to find ,ijx it is generally believed that

solving this discrete logarithm problem is computationally hard. Since the private key is unknown and cannot be computed, then it is computationally hard from (2) to bind the public keys { },,1 ,2, , , ji qi i

j j jg g g and { },,1 ,2, , , ji qi ij j jy y y to .i

j jM G∈ Hence, it is difficult

to link the signature (r) to ( )r since .r r≠ The use of the pair of public keys ( , )j jp q

does not bind the two signatures to ij jM G∈ since this pair binds to all members

{ }1 2, , , mj j jM M M M= in Gj.

Furthermore, it should be computationally hard to find two messages m1 and m2 such that their hash functions are equal, i.e. h(m1) = h(m2). This property of hash functions is referred to as collision resistance. Therefore, linking the two signatures (s) and ( )s is also difficult since 1 2 1 2, ( ) ( )≠ ≠k k h m h m and r r≠ (where k1 and k2 are two random numbers used in DSA to generate signatures as described in Section 4).


Recall also that signatures (r, s) and ( , )r s are then signed using DSA with keys ( , , , , ).j j j j jp q g y x′ ′ ′ ′ ′ Those keys are certified by the CA and do not bind to a single

.ij jM G∈ Those keys bind to all members { }1 2, , , m

j j jM M M M= in Gj. Therefore,

signatures in our proposed protocol are anonymous and unlinkable.

6.2 Security

The security of our proposed protocol relies on the difficulty of solving the discrete logarithm problem and on the security of the DSA. Pointcheval and Sterrn (2000) proved the security of a large class of known signature schemes, such as Schnorr Signature, in the random oracle model (Bellare and Rogaway, 1993). They proved that signature schemes are resistant to adaptive chosen-message attack. That is, it is computationally hard to find the private key from signatures. Since the DSA is a variant of Schnorr Signature and since the DSA matches the definition of a signature scheme in Pointcheval and Sterrn (2000), then the DSA is secure in the random oracle model.

Our proposed protocol is a broadcast one and not a handshake protocol. The main security threat to our protocol is the replay attack. Our assumption of using time stamps and accurate time synchronisation among vehicles in V2V networks guarantees operation against replay attacks. Other security attacks such as reflection attack or man-in-the-middle attack do not pose a threat in our protocol since those attacks require a mutual authentication or a handshake protocol.

We also pointed out in Section 5 that a masquerade attack is possible if an attacker obtains the public keys (pj, qj) and then generates an arbitrary set of keys , ,( , , )i z i z i

j j jy g x− − − such that (2) is satisfied. However, the same attacker needs also the second set of certified keys ( , , , , )j j j j jp q g y x′ ′ ′ ′ ′ in order to complete the signature process and the attack. Since only the private key jx′ is unknown, by means of the secure DSA, the attacker cannot masquerade as a participant to V2V networks and generate a signature.

6.3 Members of the same group and their generated keys

Assume there are two members 1 2( , )j j jM M G∈ in the same group and a pair of their generated keys 1, 1,( , )z z

j jy g and 2, 2,( , ),z zj jy g respectively. If 1, 1,( , )z z

j jy g = 2, 2,( , ),z zj jy g then

the opening messages procedure will identify two private keys 1jx and 2 ,jx where

11, 1,( ) jxz zj jy g≡ mod pj and

22, 2,( ) jxz zj jy g≡ mod pj, respectively. In this case, it may be

difficult to identify the signer, and the system will be considered unreliable.

Lemma: Members in the same group cannot generate equal public keys , .i zjy

Proof: In our proposed protocol, it is possible that 1jM and 2

jM generate the same key 1, 2, .z z

j jg g= Assume that 1jM and 2

jM also generate two equal keys 1,zjy

and 2,zjy such that

11, 1,( ) jxz zj jy g≡ mod pj and

22, 2,( ) jxz zj jy g≡ mod pj, respectively.

Therefore, 1 21, 2,( ) mod ( ) modj jx xz z

j j j jg p g p= which implies that 1 2 ( 1)j j jx x mod p≡ − and


1 2 ( 1)j j jx x k p≡ + − for some integer k. Hence, 1 2( ) | ( 1).j j jx x k p− − Since | ( 1)j jq p − also, then the two members will generate the same keys 1, 2, 1 2( )z z

j j j j jy y if x x nq= − = for some integer n > 0. For this reason, the CA chooses the private keys 1 2

j jx and x be less than qj, according to the DSA, such that 1 2( ) .j j jx x q− <

7 Key management

7.1 Key revocation

Group members are likely to join or be excluded from the group. In cases of forgery (as an example), the CA may find it necessary to delete members from a group, hence, revoking their private keys. A revoked member should not be allowed to generate a valid signature in the future. In addition, the CA should preserve the anonymity of group members after membership revocation [backward unlinkability (Song, 2001)]. One simple solution is to issue a new pair of public keys, and new certificates to all valid members whenever a member of a group is revoked. Therefore, all non-revoked members must be notified by the CA of the change and of new certificates. This solution is inconvenient and expensive in terms of communications. Another solution is to have all non-revoked members look up revoked keys in a database. The approach is to provide a list of revoked keys called Certificate Revocation List (CRL) (Bresson and Stern, 2001; Ateniese and Tsudik, 2002). This list contains information about revoked keys. Each time a non-revoked member verifies a received signature, this member searches the list of revoked keys and makes sure that the signature is not signed by any of the revoked keys. This solution adds communication and computational costs to all non-revoked members. However, it is impossible to revoke keys and identify messages signed by these keys without the existence of infrastructure. Vehicles have to obtain the latest revocation list from the CA in order to look up revoked keys.

In V2V safety applications, it is not feasible to search a revocation list since it may cause high communication latencies and additional processing time. The problem of finding an efficient key-revocation scheme is not an easy one, especially for safety-critical applications such as V2V networks. The problem of finding an efficient scheme to identify signatures that are signed by revoked keys is still open and under research. A possible solution for key revocation in our proposed protocol is that the CA maintains a database that has a list of revoked private keys. When the CA revokes a private key, the CA updates this database to include this revoked key, and then performs a secure communication with the tamper-resistant hardware of the revoked key. Such secure communications should be implemented as Over-The-Air-Rekeying (OTAR) specification protocol. We also indicated in Subsection 4.1 that FIPS 140-2 has a requirement for a cryptographic module to identify and authenticate its users. Such a requirement can be achieved using one of several available authentication protocols [National Institute of Standards and Technology FIPS PUB 196, Public Key Cryptography Standards (PKCS; http://www.rsa.com/rsalabs), Transport Layer Security (TLS) Protocol; http://www.ietf.org]. These protocols can be used to provide secure communications between the CA and the tamper-resistant hardware. This secure communication allows the CA to access the memory locations where public keys and


private keys ( , , , , , , , )ij j j j j j j jp q x p q g y x′ ′ ′ ′ ′ are stored, and then zeroing these memory

locations (maintenance role, FIPS 140-2). As a result, members with revoked keys have a tamper-resistant hardware without any key. This tamper-resistant hardware will not be able to generate signatures and transmit messages. Members with revoked keys have to obtain a new tamper-resistant hardware from the CA.

Raya and Hubaux (2007) and Raya et al. (2006b) proposed a similar approach in three revocation protocols: Revocation Protocol of the Tamper-Proof Device (RTPD), Revocation Protocol using Compressed Certificate Revocation Lists (RCCRL) and Distributed Revocation Protocol (DRP). In RTPD, the CA has to know the vehicle’s location in order to communicate securely with the tamper-resistant hardware via base stations. If a vehicle’s location is determined, the CA sends a secure revocation message to erase the keys from the vehicle’s tamper-resistant hardware. The authors suggested a backup mechanism, in case the location of a vehicle cannot be determined, by broadcasting the revocation message via the low-speed FM radio or via a satellite. In RCCRL, the CA revokes only a subset of a vehicle’s keys. According to Raya et al. (2006b), RCCRL can be used when the tamper-resistant hardware of the target vehicle is unreachable (e.g. because of jamming) and can be used to warn the neighbours of a revoked vehicle. In DRP, the CA revokes misbehaving vehicles (vehicles that transmits malicious data). Vehicles communicating with each other can detect and collect information about a neighbouring misbehaving vehicle. This information is reported to the CA which in turn will revoke the keys of the misbehaving vehicle.

7.2 The validity period of the certified keys and the tamper-resistant hardware

The second set of keys ( , , , , )j j j j jp q g y x′ ′ ′ ′ ′ that are certified by the CA should have a validity period. When the validity period is about to expire or expired, a vehicle’s tamper-resistant hardware with those keys communicates securely and anonymously with the CA to obtain a new set of keys ( , , , , )j j j j jp q g y x′′ ′′ ′′ ′′ ′′ . The ISO/IEC 11770-3 (1999) can be used to transfer the new keys ( , , , , )j j j j jp q g y x′′ ′′ ′′ ′′ ′′ to a vehicle’s tamper-resistant hardware. We discuss next a communication protocol between the CA and a vehicle’s tamper-resistant hardware that incorporates our proposed anonymity scheme, described in Section 5, into the ISO/IEC 11770-3 protocol.

During the procedure Generating Membership Keys and Certification, the CA stores in a vehicle’s tamper-resistant hardware the CA’s public key PCA and an asymmetric RSA pair of public and private keys ( , )i i

j jM MP X that belong to .i

j jM G∈

The CA maintains the public key ijM

P in its secure database as shown in Figure 6.

In a secure communication channel, this vehicle’s tamper-resistant hardware provides a request in a message m1 to the CA, and generates message

2 1 1( ( )) || || ,CA iM j

P Xm Enc Enc Sig m m TimeStamp⎛ ⎞= ⎜ ⎟⎝ ⎠

where ( )pEnc m means encrypting

message m with the key .p The signature Sig(m1) is signed using our proposed protocol in Section 5 with the keys , ,( , , , , ),i z i z i

j j j j jy g p q x and the message m1 contains the public keys , ,( , , , ).i z i z

j j j jy g p q


Figure 6 The CA’s database with the RSA public keys ijM

P for each member

The CA gets the request from m1 by decrypting m2 using the CA’s private key PvCA to obtain 1 1( ( )) || || .

iM jXEnc Sig m m TimeStamp From the public keys , ,( , , , )i z i z

j j j jy g p q in m1,

the CA gets from its database the private key, ,ijx that gives , ,( )

ijxi z i z

j jy g≡ mod pj. Then, the CA gets from its database the public key i

jMP of this vehicle that is associated with

.ijx Finally, the CA performs a decryption operation using the vehicle’s public key i

jMP

to verify the signature on message m1. The CA provides the new keys, ( , , , , ),j j j j jp q g y x′′ ′′ ′′ ′′ ′′ in message

3 ( ( ) || || .CA iM j

Pv Pm Enc Enc Sig N N TimeStamp⎛ ⎞= ⎜ ⎟⎝ ⎠

The signature Sig(N) is signed using

some set of DSA public keys owned by the CA that is included in message N. The vehicle’s tamper-resistant hardware gets N by decrypting m3 with the public key of CA, PCA, and then by its own private key .i

jMX Finally, the vehicle’s tamper-resistant

hardware authenticates the signature and accepts the new set of keys ( , , , , )j j j j jp q g y x′′ ′′ ′′ ′′ ′′ in message N.

Our proposed anonymity protocol that we described in previous sections relies on the security of the tamper-resistant hardware and on the security of the DSA. As with any cryptographic protocol that has keys with a validity period, the tamper-resistant hardware should also have a validity period. These hardware devices should be updated


periodically with the latest technology to protect it from hardware attacks. If a tamper-resistant hardware in a vehicle is compromised, then the tamper-resistant hardware in other vehicles will be easily compromised. Hence, the whole V2V network will be insecure. Furthermore, we assume a trusted CA that maintains a secure and tamper-resistant database. The database contains all the keys issued by the CA, including the revoked keys. The method to securely maintain keys in the CA’s database is out of the scope of this paper.

7.3 Number of generated keys

According to the US Department of Transportation (Federal Highway Administration – US Department of Transportation, 2005), the total number of registered vehicles in the USA in 2005 is 241,193,974 vehicles. For the purpose of calculations, assume 242 million vehicles are arranged into 24,200 groups of 10,000 vehicles each. Therefore, the CA has to generate 24,200 distinct pair of public keys (pj, qj) and 24,200 distinct second-set public keys ( , ),j jp q′ ′ for a total of 48,400 public keys. Assume also that all those keys have a validity period of one day. In one year, the CA has to issue 17,666,000 public keys. According to the prime number theorem (Havil, 2003), if a public modulus key p is of a size 1024 bits, then the estimated total number of prime numbers that are less than p is 3051.267 10 .× Therefore, the CA has 2977.1754 10× years to consume all public keys.

In a similar analysis, vehicles generate qj distinct public keys , .i zjg Assume that a

vehicle will generate those keys every five seconds. Then this vehicle will generate 6,307,200 public keys a year. Since qj is of size 160 bits, then this vehicle has

412.317 10× years to consume all , .i zjg

8 Performance analysis

The advantage of our proposed protocol over related works that use dynamic public/private key pair is that we do not acquire new public/private keys from the CA whenever we need to generate a signature. Public keys , ,( , )i z i z

j jy g are generated by the tamper-resistant hardware inside a vehicle and used immediately for signing messages. Signed messages are then guaranteed authenticity by the use of the second key-set ( , , , , ),j j j j jp q g y x′ ′ ′ ′ ′ as we explained in Section 4. The protocols in related works require continuous communications with the CA to acquire new public/private keys. In our protocol, vehicles communicate with the CA only at the end of the validity period of the second key-set.

In this section, we also compare the related works in group signatures with our proposed protocol that utilises DSA. Table 1 shows the processing speed and the size of the signature for some of these recent research works. The processing speed of the previous works is about 10–15 times slower than the DSA. In addition, the size of signatures generated by previous works is too long compared with the size of the DSA signature, which is 320 bits.


Table 1 Performance analysis of some group signatures

Group signature Processing speed Signature size Sign • 6 exponentiations with a modulo size length

of 1600 bits • 1 exponentiation with a modulo size length of

2048 bits, and length of exponent is 1024 bits• 1 multi-base exponentiation with a size length

of one of the exponents is 1244 bits, and length of other two exponents is 502 bits

Verify • 3 two-base exponentiation with a module

size length of 1600 bits

Camenisch and Groth (2005)

• 1 multi-base exponentiation with a modulo size length of 2048 bits

~6500 bits (~812 bytes)

Sign • 4 exponentiation with a modulo size length

of 1024 bits • 3 multi-based exponentiation, where the

length of exponents may range from 2000 to 6000 bits

Verify

Ateniese et al. (2000)

• 4 multi-based exponentiation, where the length of exponents may range from 2000 to 6000 bits

>50 Kbits (6.1 Kbytes)

Sign • 5 exponentiations with a modulo size length

of 1200 bits, length of exponent between 240 and 670 bits

• 3 multi-base exponentiations, where length of exponents between 240 and 670 bits

Verify

Popescu et al. (2003)

• Processing time is same as Sign procedure

>100 Kbits (12.2 Kbytes)

Sign • 5 exponentiations with a modulo size length

of 170 bits • 3 multi-base exponentiations

Boneh et al. (2004)

Verify

1600 bits (200 bytes)

• 5 multi-base exponentiations

Comparing our proposed protocol with the group signature by Boneh et al. (2004), we achieve anonymity using the standardised DSA with a signature size of 320 bits (40 bytes) while the group signature of Boneh et al. (2004) has a size of ~192 bytes. In addition to the overhead improvement in message signature size by 152 bytes (79%), the advantages of our proposed protocol over Boneh et al. (2004) are: (1) the computational power is less intensive and (2) the DSA is a standardised signature algorithm and is practically used in a great number of applications.


Handschuh and Paillier (2000) studied the performance of popular public-key algorithms and hash functions such as DSA and data encryption standard. They showed that on 8-bit commercial microcontrollers running at 10 MHz, the processing time of signing with DSA is 100 ms and the processing time of verifying the signature is 160 ms. Therefore, in our proposed protocol, the total processing time for signing a message would be 200 ms, and the total processing time for verifying the signature would be 320 ms. Nowadays, vehicles are equipped with several ECUs that control engines, airbags and anti-lock braking systems. These units use 16- and 32-bit microcontrollers that run at 66–132 MHz. There are also other mobile devices that are used for cell phones, portable media players and GPS navigation systems. These devices run at 250–532 MHz. With the evolvement of V2V communication networks, a demand for higher speed may be required for safety-critical applications. Using a microcontroller that runs at 500 MHz for example, the processing time for signature and verification in our protocol might drop to ~5 ms.

9 Conclusion

Vehicle safety applications have stringent requirements in communication latencies, processing time and the length of broadcasted messages. Providing a reliable, secure and anonymity-preserving protocol relies on the size of cryptographic keys and the number of cryptographic operations. We proposed a broadcast communication protocol suitable for V2V safety applications. Our proposed protocol provides drivers with anonymity, message authentication and data integrity. The protocol is based on the standardised DSA. We achieve anonymity by allowing drivers to generate and change their own set of public keys frequently using the DSA. In our approach, the CA is not required to authenticate the frequently generated public keys. The recipients of a signed message can verify the correctness of the signature without identifying the signer. In case of a dispute and malicious activities, the identity of the driver who signed the disputed message can be revealed only by the CA. Our anonymity and security analysis showed that the DSA can be used to preserve the anonymity of drivers in V2V networks. The advantages of our protocol are: (1) a small signature size of 40 bytes, (2) less computationally intensive than other related protocols in group signatures and (3) a standardised signature scheme. In addition, our proposed protocol can be processed in ~5 ms. Therefore, by using current technologies, it is viable to preserve the anonymity of drivers while providing secure communications in V2V safety applications.

References Askwith, B., Merabti, M., Shi, Q. and Whiteley, K. (1997) ‘Achieving user privacy in mobile

networks’, IEEE 13th Annual Computer Security Applications Conference, pp.108–116. Asokan, N. (1994, December) ‘Anonymity in a mobile computing environment’, IEEE Workshop

on Mobile Computing Systems and Applications, pp.200–204. ASTM (2003) Standard Specification for Telecommunications and Information Exchange Between

Roadside and Vehicle Systems – 5 GHz Band Dedicated Short Range Communications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) Specifications, ASTM E2213-03, September.


Ateniese, G., Camenisch, J., Joye, M. and Tsudik, G. (2000) ‘A practical and provably secure coalition-resistant group signature scheme’, Advances in Cryptology – CRYPTO 2000, Vol. 1880 of Lecture Notes in Computer Science, Springer-Verlag.

Ateniese, G. and Tsudik, G. (2002) ‘Quasi-efficient revocation of group signatures’, Proceedings of Financial Cryptography ‘02, pp.183–197.

Bellare, M. and Rogaway, P. (1993) ‘Random oracles are practical: a paradigm for designing efficient protocols’, First ACM Conference on Computer and Communications Security, ACM Press, New York, pp.62–73.

Blum, J. and Eskandarian, A. (2004) ‘The threat of intelligent collisions’, IEEE IT Professional, Vol. 6, No. 1, pp.24–29.

Bohrer, K., Levy, S., Liu, X. and Schonberg, E. (2003) ‘Individualized privacy policy based access control’, ICECR6 – 6th International Conference on Electronic Commerce Research.

Boneh, D., Boyen, X. and Shacham, H. (2004) ‘Short group signatures’, Advances in Cryptology – CRYPTO 2004, Springer-Verlag.

Bresson, E. and Stern, J. (2001) ‘Group signatures with efficient revocation’, Proceedings of PKC2001, Vol. 1992 of Lecture Notes in Computer Science, Springer-Verlag, pp.190–206.

Brodie, C.A., Karat, C-M. and Karat, J. (2004) ‘Views of privacy: business drivers, strategy and directions’, IEEE Symposium on Security and Privacy.

Camenisch, J. and Groth, J. (2005) ‘Group signatures: better efficiency and new theoretical aspects’, 4th International Conference on Security in Communication Networks, SCN 2004, Vol. 3352 of Lecture Notes in Computer Science, Springer-Verlag.

Capkun, S., Hubaux, J-P. and Jakobsson, M. (2004) ‘Secure and privacy-preserving communication in hybrid ad hoc networks’, EPFL I&C Technical Reports in Computer and Communication Sciences.

Chaum, D. and van Heyst, E. (1991) ‘Group signatures’, Advances in Cryptology, EUROCRYPT ‘91, Vol. 547 of Lecture Notes in Computer Science, pp.257–265, Springer-Verlag.

Duri, S., Elliot, J., Gruteser, M., Liu, X., Moskowitz, P., Perez, R., Singh, M. and Tang, J-M. (2004) ‘Data protection and data sharing in telematics’, ACM Mobile Networks and Applications, Vol. 9, No. 9.

El Zarki, M., Mehrotra, S., Tsudik, G. and Venkatasubramanian, N. (2002) ‘Security issues in a future vehicular network’, European Wireless.

Federal Highway Administration – US Department of Transportation (2005) Highway statistics (Section II: motor vehicles). Available online at: http://www.fhwa.dot.gov/policy/ohim/ hs05/index.htm

Fiat, A. and Shamir, A. (1987) ‘How to prove yourself: practical solutions of identification and signature problems’, Advances in Cryptology – CRYPTO’86, Vol. 263 of Lecture Notes in Computes Science, Springer-Verlag, pp.186–194.

Gennaro, R., Lysyanskaya, A., Malkin, T., Micali S. and Rabin, T. (2004) ‘Algorithmic tamper-proof (ATP) security: theoretical foundations for security against hardware tampering’, TCC 2004, Vol. 2951 of Lecture Notes in Computer Science, Springer-Verlag, Berlin, Heidelberg, pp.258–277.

Goh, E-J. and Jarecki, S. (2003) ‘A signature scheme as secure as the Diffie-Hellman problem’, Advances in Cryptology – EUROCRYPT 2003, Lecture Notes in Computer Science, Springer-Verlag, pp.401–415.

Gollan, L. and Meinel, C. (2002) ‘Digital signatures for automobiles?’, Systemics, Cybernetics and Informatics.

Handschuh, H. and Paillier, P. (2000) ‘Smart card crypto-coprocessors for public-key cryptography’, Smart Card Research and Applications, Vol. 1820 of Lecture Notes in Computer Science, Springer-Verlag, pp.386–394.

Harney, H. and Muckenhirn, C. (1997) ‘Group key management protocol (GKMP) architecture’, RFC 2094.


Havil, J. (2003) Gamma: Exploring Euler’s Constant, Princeton University Press, Princeton, NJ, pp.174–176.

Holtmanns, S. (2002) ‘Privacy in a mobile environment’, Proceedings of the IEEE 13th International workshop on Database and Expert Systems Applications, pp.493–497.

Hubaux, J-P., Capkun, S. and Luo, J. (2004) ‘The security and privacy of smart vehicles’, IEEE Security and Privacy Magazine, Vol. 2, No. 3, pp.49–55.

Intelligent Transportation Society of America (2007) Available online at: http://www.itsa.org Intelligent Transportation Systems – US Department of Transportation (2007) Available online at:

http://www.its.dot.gov ISO/IEC 11770-3 (1999) Information Technology – Security Techniques – Key Management – Part

3: Mechanisms using Asymmetric Techniques, 1st ed. National Highway Traffic Safety Administration – US Department of Transportation (2005,

March) Vehicle Safety Communications Project, Task 3 Final Report, Identify Intelligent Vehicle Safety Applications Enabled by DSRC.

National Institute of Standards and Technology, CMVP (2008) Available online at: http://csrc.nist.gov/groups/STM/cmvp

National Institute of Standards and Technology FIPS PUB 196 (1997) Entity Authentication Using Public Key Cryptography, US Department of Commerce.

National Institute of Standards and Technology FIPS PUB 140-2 (2001) Security Requirements for Cryptographic Modules, US Department of Commerce.

National Institute of Standards and Technology FIPS PUB 140-2 (2007) Annex A: Approved Security Functions for FIPS PUB 140-2, US Department of Commerce.

New Technology Standards Project, Over-The-Air-Rekeying (OTAR) Protocol (1996) Digital Radio Technical Standards, TSB-102.AACA, Telecommunications Industry Association.

Papadimitratos, P., Gligor, V. and Hubaux, J-P. (2006) ‘Securing vehicular communications – assumptions, requirements, and principles’, Proceedings of the Workshop on Embedded Security in Cars (ESCAR), Berlin, Germany.

Papadimitratos, P. and Haas, Z.J. (2003) ‘Secure link state routing for mobile ad hoc networks’, IEEE Workshop on Security and Assurance in Ad hoc Networks, in conjunction with the 2003 International Symposium on Applications and the Internet, Orlando, FL.

Pointcheval, D. and Sterrn, J. (2000) ‘Security arguments for digital signatures and blind signatures’, Journal of Cryptology, Vol. 13, No. 3, pp.361–396.

Popescu, C., Noje, D., Bede, B. and Mang, I. (2003) ‘A group signature scheme with revocation’, 4th EURASIP Conference focused on Video/Image Processing and Multimedia Communications, Zagreb, Croatia.

Raya, M., Aziz, A. and Hubaux, J-P. (2006a) ‘Efficient secure aggregation in VANETs’, 3rd International Workshop on Vehicular Ad Hoc Networks (VANET’06).

Raya, M. and Hubaux, J-P. (2005) ‘Security aspects of inter-vehicle communications’, STRC 5th Swiss Transport Research Conference, Monte Verita/Ascona.

Raya, M. and Hubaux, J-P. (2007) ‘Securing vehicular ad hoc networks’, Journal of Computer Security, Special Issue on Security of Ad Hoc and Sensor Networks, Vol. 15, No. 1, pp.39–68.

Raya, M., Papadimitratos, P. and Hubaux, J-P. (2006b) ‘Securing vehicular communications’, IEEE Wireless Communications Magazine, Special Issue on Inter-Vehicular Communications.

Samfat, D. and Molva, R. (1994) ‘A method providing identity privacy to mobile users during authentication’, IEEE Workshop on Mobile Computing Systems and Applications, pp.196–199.

Sampigethaya, K., Huangy, L., Li, M., Poovendran, R., Matsuuray, K. and Sezakiy, K. (2005) ‘CARAVAN: providing location privacy for VANET’, Proceedings of Embedded Security in Cars (ESCAR).

Smart Card Alliance (2007) Available online at: http://www.smartcardalliance.org


Song, D.X. (2001) ‘Practical forward secure group signature schemes’, ACM Conference on Computer and Communications Security, pp.225–234.

Zhou, H., Mutka, M.W. and Ni, L. (2005) ‘Multiple-key cryptography-based distributed certificate authority in mobile ad hoc networks’, IEEE Globecom.

Zhu, J. and Ma, J. (2004) ‘A new authentication scheme with anonymity for wireless environments’, IEEE Transactions on Consumer Electronics, Vol. 50, No. 1, pp.231–235.

Zhu, B., Wan, Z., Kankanhalli, M.S., Bao, F. and Deng, R.H. (2004) ‘Anonymous secure routing in mobile ad-hoc networks’, Proceedings of IEEE International Conference on Local Computer Networks, pp.102–108.

Documents

A broadcast protocol with drivers’ anonymity for vehicle ...ece.eng.wayne.edu/~smahmud/PersonalData/PubPapers/IJVICS-2009.pdfvehicle-to-vehicle communication networks’, Int. J