A Secure Ambulance Communication Protocol for ... - Springer Link

Wireless Pers Commun (2013) 73:1187–1213 DOI 10.1007/s11277-013-1273-y

A Secure Ambulance Communication Protocol for VANET Chin-Ling Chen · Ing-Chau Chang · Chun-Hsin Chang · Yuan-Fen Wang

Published online: 30 July 2013 © Springer Science+Business Media New York 2013

Abstract Vehicular ad hoc networks (VANETs) have been a research focus in recent years. VANET’s main applications are enhancing road safety and reducing traffic accidents. Moreover, the VANET system can also reduce the time it takes for emergency vehicles to arrive at the accident location. The security of the transmission messages is of utmost importance, and to protect the transmission messages we propose a secure ambulance communication protocol for VANET to ensure that messages will not be revealed or stolen. The proposed scheme combines symmetric encryption, message authentication codes and digital signature mechanisms, and thereby achieves non-repudiation, availability, integrity, confidentiality, mutual authentication, session key security, known-key security and the ability to prevent known attacks. Finally, with NS2 simulation results that are based on realistic vehicle density statistics and the Taipei city road map, we argue that our secure ambulance communication protocol is effective in real VANET scenarios. Keywords

VANET · Security · Symmetric encryption · Ambulance · Session key

C.-L. Chen (B) · C.-H. Chang Department of Computer Science and Information Engineering, Chaoyang University of Technology, 168 Jifeng E. Road, Wufeng District, Taichung 41349, Taiwan, ROC e-mail: [email protected] C.-H. Chang e-mail: [email protected] I.-C. Chang · Y.-F. Wang Department of Computer Science and Information Engineering, National Changhua University of Education, 1 Jin De Road, Paisha Village, Changhua 500, Taiwan, ROC e-mail: [email protected] Y.-F. Wang e-mail: [email protected]

123

1188

C.-L. Chen et al.

1 Introduction With the growth in the number of vehicles on the roads, accident rates have also increased. In order to reduce the number of accidents which occur, research into vehicle ad hoc networks (VANET) has frequently been proposed. The original idea was based on a mobile ad hoc network (MANET, defined in [2,5]). However, MANET had limited speed, computation ability and insufficient power, while VANET provides high speed transmission, unlimited computation ability, power and a large-scale communication system. In 2008, Li et al. [19] proposed a secure and efficient communication scheme with the establishment of an authentication key and the preservation of privacy for vehicular ad hoc networks using asymmetric encryption. Jiang and Wang [12] proposed an anonymous authentication protocol for multi-services in wireless environments combined with a hash chain operation. Li et al. and Jiang and Wang combined asymmetric encryption and the hash chain operation to enhance the security requirements of their scheme, but the computation costs remained too high. As a result, we have proposed a secure ambulance communication protocol for VANET which reduces computation costs while maintaining security requirements. A VANET system model can be divided into three sections: Certification Authority (CA), Roadside Transportation Authority (RTA) and Road Side Unit (RSU). Generally, the CA is authorized by the government, and its main services are to issue the certificate as well as the signature; the RTA’s main services include verification of the vehicles and the issuing of the session key; and the RSU’s main services are forwarding the messages between the vehicles and the RTA [4,24]. VANET’s architecture is shown in Fig. 1.

Fig. 1 The construction of the proposed scheme

123

A Secure Ambulance Communication Protocol for VANET

1189

VANET research originally focused on traffic safety warnings, reducing traffic accidents and traffic control. In the future, there will be more research on e-commerce applications that involve communication messages via Vehicle-to-Vehicle (V2V) or Vehicle-to-Road (V2R), which could include privacy information (ex. privacy identity, account number etc). The resulting security issues have been raised and discussed in [25,34]. In this paper, we have assumed a particular situation: there is a traffic accident and the traffic situation is not clear. Someone reports the accident to a hospital. After receiving the report, the hospital sends the event report to the RTA and requests the session key between the ambulance and the RTA. When the RTA receives the accident event message, it generates the session key and sends it to hospital. Once the session key is received, the hospital sends the session key to the ambulance. The ambulance uses the session key to encrypt the communication message and sends it to the RTA. Upon receiving the message from the ambulance, the RTA generates the optimization path planning message for the quickest response time and sends it to the ambulance to reduce the time spent by the ambulance in getting to the accident scene. We have proposed a secure ambulance communication protocol for VANET to protect the transmission of the communication messages. The remainder of this paper is organized as follows. Related work is discussed in Sect. 2. Section 3 explains seven important security requirements. In Sect. 4, our proposed scheme is described in detail. After that, we present security and performance analyses in Sect. 5 to exhibit significant performance improvements of this proposed algorithm. Finally, Sect. 6 concludes this paper.

2 Related Work Wireless communications can be divided into microwave, infrared, radio frequency, etc. The main differences are the penetration and data communication rates. Dynamic mutual communications pass between nodes. Due to the higher requirements for security and immediacy, their main application is to protect the vehicular information between vehicles. The V2R application is fixed for one side, such as ETC, parking information, media information download and upload. In 2005, Raya and Hubaux [26] identified three VANET security issues: attacks on safety-related applications, attacks on payment-based applications, and attacks on privacy. In 2006, Jungels et al. [14] divided VANET’s communication module into two types: vehicle-to-vehicle communication (V2V) and vehicle-to-road communication (V2R). At present, VANET has three mechanisms: Wimax, WiFi and Dedicated Short Range Communications (DSRC) [17]. DSRC is universal in America. In 1992, the American Society for Testing Material (ASTM) [31] evaluated Electronic Toll Collection (ETC) [7] techniques across North America, and US DSRC was selected. US DSRC employs a 915 MHz frequency and uses TDMA technology. However, 915 MHz DSRC had the disadvantages of a limited transmission range and a low transmission rate. In 1999, the Federal Communication Commission (FCC) decided to employ 5.9 GHz for US DSRC to improve the transmission rate to 6–27 Mbps, which also expanded the transmission range to 1,000 m [11].

3 Security Requirements In 2005, Raya and Hubaux [26] identified several security requirements for VANETs as follows:

123

1190

C.-L. Chen et al.

1. Non-repudiation Non-repudiation: To preclude the sender or receiver from repudiating the transmitted message, the communication process needs to access the participator’s identity and signature as supporting evidence. For non-repudiation issues, the system should be able to protect secret information from being tampered with by malicious attackers. Raya and Hubaux proposed VANET network security under a systematic and quantitative channel, in [8,14,27,30,34], thereby establishing a good basis for the PKI environment. 2. Integrity The transmission of messages must ensure integrity, preclude service interruption and pass the verification procedure. Therefore, the transmitted messages should not suffer from modifying, replaying, or fabrication. If the protocol cannot secure data integrity during the process of the communication, then communication data is meaningless, and may even cause serious injury to the server, user or service provider. As a result, the protocols must ensure that data cannot be tampered with or destroyed artificially or non-artificially during the communication process [35]. 3. Confidentiality The message sent from the user will not be revealed to any non-authorized user. Therefore, communication privacy must be protected; detailed descriptions are given in [9,14,23,24, 27]. 4. Mutual authentication In order to ensure reliable communication, the RSU and vehicle only respond to messages which have passed the verification procedure. Mutual authentication is very important in the VANET field [1,4,6,19]. The server must ensure the user is legitimate in order to protect the interests of legal users. All users must pass the verification to ensure the user is lawful. 5. Session key security During the communication process, if an attacker obtains the session key by eavesdropping or stealing the communication parameters, the communication message could be easily decrypted, copied or tampered with [20,21,35]. 6. Known-key security If the session key is not updated, when an attacker obtains the session key, whether forward or backward, the cipher text will be easily decrypted, compromising the communication information [20,21,33]. 7. Known attacks • Man-in-the-middle attack: For man-in-the-middle attacks, the attacker might intercept the communication message, modify the message and send it to the receiver. If a man-in-the-middle attack occurs, the receiver or sender might obtain the wrong message from the attacker [20,33]. • Replay attack: In a replay attack, the attacker intercepts the communication message and sends it repeatedly to the RTA or ambulance. The RTA and ambulance may become busy in computing the receiving messages and an attack may pass the authentication process and log into the system [20,33,35].

123


1191

4 Proposed Scheme In this section, we describe our proposed scheme in detail. We have distinguished three phases: the registration phase, the event reporting and authentication phase and the communication phase. The communication phase has three scenarios: hospital to event scene, event scene to hospital and RTA to hospital. Our proposed scheme has four cardinal roles or components: 1. Road-side Transportation Authority (RTA) is an entity that receives event messages and issues the session key and planning path. 2. The hospital is in charge of reporting the event message and requesting the current session key from the RTA. 3. Road-side unit (RSU) is a receiver at an accurately-known fixed location which is used to derive correct information for nearby portable receivers. Some intersection is deployed the RSU, some intersection is not deployed. The aim of developing RSU is to ensure the transmission security. 4. The ambulance is in charge of carrying patients from the accident scene to the hospital. The flow chart of our scheme is illustrated in Fig. 2: 1. Hospital Ambulance or RTA RSU: The hospital and the RTA are in charge of managing the ambulance. The RTA distributes the session key to the RSU and issues frequent updates via a secure channel. 2. Hospital −→ RTA: The hospital registers with the RTA and requests the session key between the hospital and the RTA.

Hospital

2 3 4 10

RTA

9 8 7 6

15

1

6 7 8 9 RSU

Ambulance Secure channel

Insecure

Fig. 2 The system flow chart

123

1192

C.-L. Chen et al.

3. Hospital −→ RTA: When the hospital receives the event report, it reports the event message to the RTA and requests the current session key between the ambulance and the RTA. 4. RTA −→ Hospital: The RTA receives the message, generates the session key between the ambulance and the RTA and sends the session key to the hospital. 5. Hospital −→ Ambulance: The hospital sends the session key from the RTA to the ambulance. After that, the ambulance can go to the accident scene. 6. Ambulance −→ RSU −→ RTA: The ambulance reports the current location and requests the planning path to the RTA via RSU. 7. RTA −→ RSU −→ Ambulance: The RTA receives the messages, generates the optimal path with the shortest time consumption according to the message and sends the results to the ambulance via the RSU. 8. Ambulance −→ RSU −→ RTA: After the ambulance arrives at the event scene, ambulance emergency personnel observe the injury level of the patient and send the information to the RTA via the RSU. 9. RTA −→ RSU −→ Ambulance: After receiving the message, the RTA determines the hospital according to the injury level, type or other information and planning path and sends the result to the ambulance. 10. RTA −→ Hospital: At the same time, the RTA sends the injury level and other relevant information to the hospital. Thus, the hospital can immediately start its preparations. Our proposed scheme is divided into three phases: the registration phase, the event reporting and authentication phase and the communication phase. The following notations are used throughout this study: IDV Pr k X , Puk X S K X −Y Pi S Pr k X (M) V Puk X (M) Ci E X (·), D X (·) d, n, r, u, w, z Mi M ACi Ti LT IL ?

A≤B ?

A= B h(·) ⊕ −→

X ’s identity private and public RSA key pair of X session key between by X and Y ith ambulance’s pseudo identity use X ’s private key Pr k X to sign message M use X ’s public key Puk X to verify message M ith cipher text symmetric encryption or decryption algorithm, respectively random numbers ith communication message ith message authentication code ith timestamp life-time of the session key between the hospital and the RTA injury level of the patient determine whether A is less than or equal to B determine whether A is equal to B one-way hash function exclusive-or operation insecure channel secure channel

4.1 Registration Phase In this phase, in order to access the local VANET system, the hospital must register with the RTA to obtain the RTA’s signature and the session key S K H −RT A . Later, the hospital

123


1193

Hospital IDlist = ( IDA1 ,ID A2 ,ID A3

RTA ID Ai )

( IDH , IDlist )

Secure Socket Layer (SSL) channel Generates life time LT S RTA = S Prk RTA ( IDH , IDRTA , LT ) ( S RTA , SK H − RTA )

SK H − RTA = h( IDH ⊕ Prk RTA ⊕ LT )

Secure Socket Layer (SSL) channel Stores S RTA and SK H-RTA into database Fig. 3 The overview of registration phase

and the RTA encrypt messages with the session key S K H −RT A to protect the transmitted messages. Therefore, the hospital and the RTA need to regularly synchronize and update the session key and signature. This phase is based on a secure channel to complete the registration procedures. An overview of the registration phase is illustrated in Fig. 3: Step 1: Hospital RTA: ID H , IDlist The hospital generates the hospital’s identity (ID H ) and the ambulance’s identity (ID Ai ). After that, the hospital generates the ambulance’s identity list (I Dlist ) as follows: IDlist = (ID A1 , ID A2 , ID A3 , . . . , ID Ai )

(1)

and then sends (ID H , IDlist ) to the RTA. Step 2: RTA Hospital: (S RT A , S K H −RT A ) After receiving (ID H , IDlist ), the RTA generates life-time LT. LT is the effective deadline of the signature S RT A and session key S K H −RT A . The RTA signs (ID H , ID RT A , LT) with the RTA’s private key (Pr k RT A ) as follows: SRTA = SPrkRTA (ID H , IDRTA , LT)

(2)

The RTA computes the session key (SKH-RTA ) as follows: S K H −RT A = h(ID H ⊕ Pr k RT A ⊕ LT)

(3)

The RTA sends (S RT A , S K H −RT A ) to the hospital. Step 3: Upon receiving the signature SRTA and session key SK H-RTA , the hospital stores them in the database. 4.2 Event Reporting and Authentication Phase In this phase, when someone (for example, a witness or the patient) reports the event to the hospital, the hospital needs to report the event to the RTA and request the session key between the ambulance and RTA. The scenario for the event reporting and authentication phase is illustrated in Fig. 4: Step 1: Hospital −→ RTA: (C1 , S H , T1 )

123

1194

C.-L. Chen et al.

RTA

Hospital C 1 = E SK H − RTA ( M 1 , r , ID A i , ID H , T1 , S RTA ) S H = S Prk H ( M 1 , S RTA )

(C1 , S H , T1 ) TRTA − T1?≤ ΔT

( M 1 , r , ID Ai , IDH , T1 , S RTA ) = DSK H −RTA (C1 )

( M 1 , S RTA )? VPuk H ( S H ) = Pi = h(r ⊕ ID Ai ) Generate a random number n SK A− RTA = h( Pi ⊕ n) C2 = h( SK A− RTA ) C3 = E SK H −RTA ( SK A− RTA , Pi , C2 , T2 )

(C3 , T2 ) TH − T2?≤ ΔT ( SK A− RTA , Pi , C2 ) = DSK H −RTA (C3 )

Ambulance

C2' = h( SK A− RTA ) ( SK A− RTA , Pi )

?

C2' = C2

Secure channel

Stores SK A− RTA , Pi in TRH

Fig. 4 The scenario of event reporting and authentication phase

First, the hospital generates event message M1 , random number r, ith ambulance identity ID Ai , hospital identity ID H and event reporting time T1 ; then it encrypts (M1 , r, ID Ai , ID H , T1 ) with S K H −RT A as follows: C1 = E S K H −RT A (M1 , r, ID Ai , ID H , T1 , S RT A )

(4)

M1 includes the event location and event reporting time. After the encryption, the hospital signs the event message M1 and the RTA signature as follows: S H = S Pr k H (M1 , S RT A )

(5)

Then the hospital sends the (C1 , S H , T1 ) to the RTA. Step 2: RTA −→ Hospital: (C3 , T2 ) After receiving the information from the hospital, the RTA verifies T1 as follows: ?

TRT A − T1 ≤T

(6)

If the verification holds, the RTA uses the session key SK H-RTA to decrypt C1 and obtains (M1 , r, ID Ai , ID H , T1 , S RT A ) as follows: (M1 , r, ID Ai , ID H , T1 , S RT A ) = D S K H −RT A (C1 )

(7)

Then, the RTA uses the hospital’s public key Puk H to verify the signature as follows: ?

(M1 , SRTA ) = V Puk H (S H )

123

(8)


1195

If the above equality holds, the RTA verifies ID Ai if it exists in IDlist . If it is true, the RTA computes the ambulance’s pseudo identity as follows: Pi = h(r ⊕ ID Ai )

(9)

Then, the RTA generates random number n and computes the session key between the ambulance and the RTA as follows: S K A−RT A = h(Pi ⊕ n)

(10)

After that, the RTA computes C2 as follows: C2 = h(S K A−RT A )

(11)

The RTA encrypts S K A−RT A , Pi and timestamp T2 as follows: C3 = E S K H −RT A (S K A−RT A , Pi , C2 , T2 )

(12)

Then the RTA sends C3 and timestamp T2 to the hospital. Step 3: Hospital Ambulance: (S K A−RT A , Pi ) After receiving the information, the hospital verifies T2 as follows: ?

TH − T2 ≤ T

(13)

If the verification holds, the hospital decrypts C3 with S K H −RT A as follows: (S K A−RT A , Pi , C2 ) = D S K H −RT A (C3 )

(14)

Then, the hospital computes C2 as follows: C2 = h(S K A−RT A )

(15)

The hospital verifies C2 as follows: C2 = C2 ?

(16)

After that, the hospital sends (S K A−RT A , Pi ) to the ambulance. Step 4: Upon receiving the session key and pseudo identity, the ambulance stores it in the tamper-resistant hardware(TRH). 4.3 Communication Phase: Hospital to Event Scene In this phase, the RTA and the ambulance use the session key to encrypt the event data and the optimal path planning tables. The scenario is shown in Fig. 5: Step 1: Ambulance −→ RSU −→ RTA: C4 , M AC1 , Pi , T3 First, the ambulance generates a random number z and encrypts the event-related messages M2 , pseudo identity Pi , random number z and timestamp T3 with S K A-RTA as follows: C4 = E S K A−RT A (M2 , Pi , z, T3 )

(17)

123

1196

C.-L. Chen et al.

Ambulance

RTA

RSU

Generates a random number z C 4 = E SK A−RTA ( M 2 , Pi , z , T3 ) MAC1 = h( M 2 , Pi , z , T3 )

(C4 , MAC1 , Pi , T3 )

(C4 , MAC1 , Pi , T3 ) TRTA − T3?≤ ΔT

( M 2 , Pi , z, T3 ) = DSK A−RTA (C4 ) MAC1' = h( M 2 , Pi , z, w, T3 ) ? MAC1' = MAC1

Generates random number w C5 = ESK A−RTA ( M 3 , IDRTA , w, T4 ) MAC2 = h( M 3 , IDRTA , w, T4 ) (C5 , MAC2 , T4 )

(C5 , MAC2 , T4 ) T Ai − T4 ?≤ Δ T

( M 3 , ID RTA , w , T4 ) = D MAC 2' = h ( M 3 , ID RTA , w , T4 ) ? MAC 2' = MAC 2 SK A− RTA (C 5 )

Fig. 5 The scenario of communication phase-hospital to event scene

and then computes the message authentication code M AC1 as follows: MAC1 = h(M2 , Pi , z, T3 )

(18)

M2 includes the event location, event reporting time, and the ambulance’s current location, direction and speed. After the encryption, the ambulance sends (C4 , M AC1 , Pi , T3 ) to the RTA through the nearby RSU. Step 2: RTA −→ RSU −→ All vehicles: C5 , M AC2 , T4 After receiving the information, the RTA verifies T3 as follows: ?

TRT A − T3 ≤ T

(19)

If the verification holds, the RTA decrypts C4 with S K A−RT A as follows: (M2 , Pi , z, T3 ) = D S K A−RT A (C4 )

(20)

Then, the RTA computes M AC1 and verifies whether M AC1 is equal to M AC1 : MAC1 = h(M2 , Pi , z, T3 )

(21)

? MAC1 =

(22)

M AC1

After verification, the RTA generates the optimization path message M3 according to the receiving message. After that, the RTA uses S K A−RT A to encrypt the optimization path message M3 , random number w and timestamp T4 as follows: C5 = E S K A−RT A (M3 , ID RT A , w, T4 )

123

(23)


1197

After encryption, the RTA computes the message authentication code M AC2 as follows: M AC2 = h(M3 , ID RT A , w, T4 )

(24)

Then, RTA broadcasts C5 and M AC2 to all vehicles through the RSU. Step 3: After receiving the information, the ambulance verifies T4 as follows: ?

T Ai − T4 ≤ T

(25)

If it holds, the ambulance decrypts C5 with S K A−RT A as follows: (M3 , ID RT A , w, T4 ) = D S K A−RT A (C5 )

(26)

Then, the ambulance computes M AC2 and verifies whether M AC2 is equal to M AC2 : M AC2 = h(M3 , ID RT A , w, T4 )

(27)

? M AC2 =

(28)

M AC2

If the above equality holds, the ambulance can confirm that M3 is trustworthy. Then, the ambulance emergency personnel can determine the path to the event location as quickly as possible. 4.4 Communication Phase: Event Scene to Hospital In this phase, after the arrival of the event scene message, the ambulance emergency personnel request the optimization planning path with the shortest time-consumption to the hospital. The overview of the communication phase- event scene to the hospital is described in Fig. 6: Step 1: Ambulance −→ RSU −→ RTA: (C6 , M AC3 , Pi , T5 ) First, the ambulance generates a random number u and injury level IL. After that, the ambulance encrypts the related messages M4 of the patient, pseudo identity Pi , random number u, injury level IL and timestamp T5 with S K A−RT A as follows: C6 = E S K A−RT A (M4 , Pi , u, I L , T5 )

(29)

MAC3 = h(M4 , Pi , z, I L , T5 )

(30)

M4 includes the patient’s identity, event location and event reporting time. The choice of hospital to which the patient will be sent is determined by the patient’s injury level IL. After the encryption, the ambulance sends (C6 , M AC3 , Pi , T5 ) to the RTA through the RSU. Step 2: RTA −→ RSU −→ All vehicles: (C7 , MAC4 , T6 ) After receiving the information, the RTA verifies T5 as follows: ?

TRT A − T5 ≤ T

(31)

If the verification holds, the RTA decrypts C6 with S K A−RT A as follows: (M4 , Pi , u, I L , T5 ) = D S K A−RT A (C6 )

(32)

123

1198

C.-L. Chen et al.

Ambulance Generates a random number u C6 = ESK A−RTA ( M 4 , Pi , u , IL, T5 )

RSU

RTA

MAC3 = h( M 4 , Pi , z , IL, T5 ) (C6 , MAC3 , Pi , T5 )

(C6 , MAC3 , Pi , T5 ) TRTA − T5?≤ ΔT

( M 4 , Pi , u , IL , T5 ) = DSK A− RTA (C 6 ) MAC 3' = h ( M 4 , Pi , u , IL , T5 ) ? MAC 3' = MAC 3

Generates random number d C 7 = E SK A− RTA ( M 5 , ID RTA , d , T6 ) MAC 4 = h ( M 5 , ID RTA , d , T6 )

(C7 , MAC4 , T6 )

(C7 , MAC4 , T6 )

TAi − T6?≤ ΔT

( M 5 , IDRTA , d , T6 ) = DSK A−RTA (C7 ) MAC 4' = h( M 5 , IDRTA , d , T6 ) ? MAC 4' = MAC 4

Fig. 6 The overview of communication phase-event scene to hospital

Then, the RTA computes M AC3 and verifies whether M AC3 is equal to M AC3 as follows: M AC3 = h(M4 , Pi , u, I L , T5 )

(33)

? M AC3 =

(34)

M AC3

After verification, the RTA will suggest a hospital according to the event message M4 and injury level IL. The RTA plans the path of the event scene to the hospital and generates the optimization path message M5 , random number d, timestamp T6 and uses S K A−RT A to encrypt them as follows: C7 = E S K A−RT A (M5 , ID RT A , d, T6 )

(35)

After encryption, the RTA computes the message authentication code M AC4 as follows: M AC4 = h(M5 , ID RT A , d, T6 )

(36)

Then, the RTA broadcasts C7 and M AC4 to all vehicles through the RSU. Step 3: After receiving the information, the ambulance verifies T6 as follows: ?

T Ai − T6 ≤ T

(37)

If the verification holds, the ambulance decrypts C7 with S K A−RT A as follows: (M5 , ID RT A , d, T6 ) = D S K A−RT A (C7 )

123

(38)


1199

Hospital

RTA C8 = E SK H −RTA ( M 4 , IL, S RTA , T7 )

(C8 , T7 ) TH − T7 ?≤ ΔT

( M 4 , IL, S RTA , T7 ) = DSK H −RTA (C8 )

( IDH , IDRTA , LT )? VPuk RTA ( S RTA ) =

Fig. 7 The scenario of communication phase- RTA to hospital

Then, the ambulance computes M AC4 and verifies whether or not M AC4 is equal to M AC4 : M AC4 = h(M5 , ID RT A , d, T6 )

(39)

? M AC4 =

(40)

M AC4

If the above equality holds, the ambulance confirms that M5 is trustworthy. Then, the ambulance emergency personnel can determine the path to the hospital as quickly as possible. 4.5 Communication Phase: RTA to Hospital In this phase, the RTA reports the related event messages regarding the hospital to which the patient will be sent. The scenario of the communication phase—RTA to the hospital is described in Fig. 7: Step 1: RTA −→ Hospital: (C8 , T7 ) After sending the response message to the ambulance, the RTA encrypts event message M4 , injury level IL, RTA signature S RT A and timestamp T7 , and sends them to the hospital where the ambulance is taking the patient as follows: C8 = E S K H −RT A (M4 , IL, S RT A , T7 )

(41)

After encryption, the RTA sends the cipher text C8 and time stamp T7 to the hospital. Step 2: After receiving the information (C8 , T7 ), the hospital verifies T7 as follows: ?

TH − T7 ≤ T

(42)

If the verification holds, the ambulance decrypts C8 with S K H −RT A as follows: (M4 , I L , S RT A , T7 ) = D S K H −RT A (C8 )

(43)

After that, the hospital verifies the RTA signture SRTA as follows: ?

(ID H , ID RT A , LT) = V Puk RT A (SRTA )

(44)

If the above equality holds, the hospital confirms that M4 is trustworthy. Then, emergency personnel at the hospital start immediate preparations for receiving the patient.

123

1200 Table 1 Non-repudiation proof during the communication

C.-L. Chen et al. Issuer

Verification

Receiver

Hospital

(M1 , S RT A ) = V Puk H (S H )

RTA

RTA

(I D H , I D RT A , LT) = V Puk RT A (S RT A )

Hospital

?

?

5 Security and Performance Analysis In this section, security issues and performance are discussed. As the following descriptions show, the proposed scheme not only achieves non-repudiation, availability, integrity, confidentiality and mutual authentication, but it also ensures session key and known-key security and resists replay and man-in-the-middle attacks. 5.1 Non-repudiation Issue According to the non-repudiation issue, the hospital registers with the RTA and obtains the RTA signature S RT A . When the event happens, the hospital signs S RT A and sends it to the RTA. The verification equations are shown in Table 1. From the above equations, the RTA and hospital obtain the necessary evidence from each other. Hence, our scheme achieves the requirement of non-repudiation. 5.2 Availability Issue VANET includes security (for example, personal privacy records) and non-security messages (for example, advertisements). In general, a security message is more important than a non-security message. Since the transmission probability of non-security messages is greater than that of security messages, and in order to improve the message exchange rate and optimize as much as possible, we used symmetrical encryption to enhance efficiency. 5.3 Integrity Issue In the communication phase, integrity is necessary. Due to the encryption by the session key of the transmitted messages between sender and receiver, the attacker has to obtain the session key to decrypt and obtain the messages as only the cipher text can be intercepted. The proposed scheme uses the message authentication code (MAC) to ensure that the messages are not modified. As a result, our scheme ensures integrity of information. 5.4 Confidentiality Issue In our scheme, the ambulance’s real identity is only shown on a secure channel during the registration phase. The event reporting and authentication phase and the communication phase use the ambulance’s pseudo identity (Pi ) for verification. Therefore, our scheme achieves the property of confidentiality. 5.5 Mutual Authentication In our scheme, each party must pass the signature verification and the message authentication code verification to authenticate its legality. Therefore, our scheme satisfies the mutual authentication requirement. The verifications are illustrated in Table 2.

123


1201

Table 2 Mutual authentication proof during the communication Phase

Sender

Authentication

Event reporting and authentication phase

Hospital

T RT A − T1 ≤ T

?

(M1 , S RT A ) = V Puk H (S H ) ?

TH − T2 ≤ T

Hospital

RTA

? C2 = C2

Hospital ?

Ambulance

T RT A − T3 ≤ T

RTA

Ambulance

M AC1 = M AC1

RTA

?

?

T Ai − T4 ≤ T

Ambulance

Ambulance

? M AC2 = M AC2 ? T RT Ai − T5 ≤ T

RTA

Ambulance

M AC3 = M AC3

RTA

RTA

RTA RTA Communication phase— RTA to hospital

RTA

RTA

RTA

Communication phase— event scene to hospital

RTA

?

Hospital

Communication phase— hospital to event scene

Verifier

RTA RTA

Ambulance

?

?

T Ai − T6 ≤ T

Ambulance

? M AC3 = M AC3 ? TH − T7 ≤ T

Ambulance Hospital ?

(I D H , I D RT A , L T ) = V Puk RT A (S RT A )

Hospital

In the event reporting and authentication phase, the hospital must sign the event message M1 and RTA signature and send it to the RTA. The RTA verifies the signature S H to ensure that the hospital is registered. The proposed scheme uses the timestamp mechanism to prevent replay attacks. Moreover, when the RTA sends cipher text C3 , which includes the session key, the ambulance’s pseudo identity Pi and C2 to the hospital, the hospital verifies C2 to ensure that the information from the RTA is secure. In the communication phase, the ambulance and the RTA generate the message authentication codes (M AC1 and M AC2 ) for each communication; thus, the RTA and the ambulance can authenticate each other. 5.6 Session Key Security To achieve the session key security, the proposed scheme combines the secret parameters Pr k RT A , Pi , r and n from the RTA and the hospital as follows: S K H −RT A = h(ID H ⊕ Pr k RT A ⊕ LT) (3) Pi = h(r ⊕ I D Ai )

(9)

S K A−RT A = h(Pi ⊕ n)

(10)

The session key of the hospital and the RTA includes the RTA’s private key Pr k RT A and lifetime LT, while the session key of the ambulance and the RTA includes the random number n from the RTA. Moreover, pseudo identity Pi includes random number r from the hospital. Because the above parameters are not revealed, the proposed scheme achieves session key security.

123

1202

C.-L. Chen et al.

5.7 Known-Key Security To protect known-key security, the session key is generated by the hash function which combines the random number, life-time LT and pseudo identity Pi as follows: S K H-RTA = h(ID H ⊕ Pr kRTA ⊕ LT)

(3)

Pi = h(r ⊕ ID Ai )

(9)

S K A-RTA = h(Pi ⊕ n)

(10)

In the proposed scheme, the session key needs to be updated dynamically. The session key of the hospital and the RTA combines the RTA’s private key and life-time LT. The RTA’s private key is secure. Meanwhile, the life-time is updated regularly. As a result, even if attackers obtain the current session key, they will not be able to figure out the forward session key. The session key of the ambulance and the RTA combines two random parameters (Pi and n) from the hospital and the RTA, respectively. The pseudo identity Pi combines the random number r from the hospital and the ambulance’s real identity I D Ai . Therefore, each ambulance has a different pseudo identity for each assignment. The session key of the ambulance and the RTA combines the ambulance’s pseudo identity and random number n from the RTA. Therefore, even if attackers steal the current session key S K A−RT A = h(Pi ⊕ n) of the ambulance and the RTA, they will not be able to decrypt the forward or backward cipher text since the session key S K A−RT A is updated for each mission. As a result, the proposed scheme achieves known-key security. 5.8 Known Attacks • Man-in-the-middle attack To prevent man-in-the-middle attacks, the proposed scheme uses the related session key to encrypt the communication message as follows: C1 = E S K H −RT A (M1 , r, ID Ai , ID H , T1 , S RT A )

(4)

C3 = E S K H −RT A (S K A−RT A , Pi , C2 , T2 )

(12)

C4 = E S K A−RT A (M2 , Pi , z, T3 )

(17)

C5 = E S K A−RT A (M3 , ID RT A , w, T4 )

(23)

Moreover, the session keys are different for each communication. In other words, even if an attacker intercepts the message, he/she cannot decrypt the cipher text or tamper with the message. • Replay attack To prevent replay attacks, the proposed scheme employs the timestamp. When the receiver obtains the communication message, the receiver verifies the timestamp as follows: ?

TRT A − T1 = T ?

TH − T2 = T ?

TRT A − T3 ≤ T ?

T Ai − T4 ≤ T

123

(6) (13) (19) (25)


1203

Table 3 Comparisons of computation cost Phase

Our scheme

Li et al.’s scheme [19]

Jiang and Wang’s scheme [12]

Authentication phase

4Tsym + 1TS + 3Th + 5Tv

4Tasy + 3Th

Communication phase

10Tsym + 8Th + 10Tv

6Tasy + 6Th

2Tasy + 10Tsym + 2TS + (6 + n)Th + 2Tv N/A

Total

14Tsym + 1TS + 11Th + 15Tv

10Tasy + 9Th

2Tasy + 10Tsym + 2TS + (6 + n)Th + 2Tv

Tasy : the time for an asymmetric encryption or decryption operation, Tsym : the time for a symmetric encryption or decryption operation, TS : the time for signing a signature, Th : the time for executing a one-way hash function, Tv : the time for verification, n: the length of the hash chain

?

TRT A − T5 ≤ T ?

T Ai − T6 ≤ T ?

TH − T7 ≤ T

(31) (37) (42)

If the above verifications do not hold, the receiver will terminate the session. Therefore, the replay attack will be detected. 5.9 Performance Analysis In this section, the performance of the proposed scheme has been evaluated. The proposed scheme used symmetric encryption, message authentication code and digital signature. Symmetric encryption and decryption is at least 100 times faster than asymmetric encryption and decryption in software, and an exponential operation is approximately equal to 60 symmetric encryptions and decryptions [18,29]. In Tables 3 and 4, we have compared Li et al. and Jiang and Wang’s schemes in computation cost and security parameter respectively. Our scheme focuses on the emergency event process and builds a secure ambulance communication. The proposed scheme has higher computation costs, but it can satisfy the security requirements especially on non-reputation issue and defend against known attacks. In our protocol, in order to reduce the computation cost, we mostly use the symmetric key and the hash function to design our scheme in authentication phase and communication phase. This viewpoint is similar to the related works. Our proposed scheme also incorporated the session key update phase, which was an improvement over the other schemes. We also computed the communication cost of the proposed scheme on DSRC [10]. The communication cost of the proposed scheme is shown in Table 5. In Table 5, we show the proposed scheme implemented in a DSRC system. We assumed the DSRC’s data transmission rate was 6–27 Mbps. As a result, we computed the communication cost of the proposed scheme in 6 and 27 Mbps, respectively. The transmission time of our proposed scheme was less than 1ms. As a result, the implementation of the proposed scheme on a DSRC system would be feasible.

123

1204

C.-L. Chen et al.

Table 4 Comparisons of the security parameter Security issue

Our scheme

Li et al.’s scheme [19]

Jiang and Wang’s scheme [12]

Non-repudiation

Yes

No

No

Availability

Yes

Yes

Yes

Integrity

Yes

Yes

Yes

Mutual authentication

Yes

Yes

Yes

Session key security

Yes

Yes

Yes

Known-key security

Yes

Yes

Yes

Known attacks

Yes

NA

Partial

Table 5 Communication cost of our scheme Our scheme 2TS K + 1TS + 2Tts = 1560 bits 5TS K + 6Th + 5Tts = 2320 bits 7TS K + 1TS + 6Th + 7Tts = 3880 bits TS K : the time for symmetric encryption and decryption operation (256 bits), TS : the time of transmitting a signature (1,024 bits), Th : the time of transmitting a one-way hash function (160 bits), Tts : the time of transmitting a timestamp (16 bits)

5.10 Simulation Results We adopted the well-known network simulator, NS-2.34 [3], that was patched with the GPSR implementation code [16] to perform simulations for the proposed secure ambulance communication protocol for VANET. The parameters used for these simulations are listed in Table 6. As shown in Fig. 8, the experiment area was 4,200 m × 4,200 m square as derived from a street map of downtown Taipei, Taiwan, with a street layout consisting of twenty-five intersections and forty road segments. In this area, one RTA and seven hospitals, including three medical centers and four regional hospitals, were used for the simulation. We assumed each intersection was equipped with a fixed RSU to forward packets in VANET. Each RSU and vehicle followed the IEEE 802.11 MAC protocol with Distributed Coordination Function (DCF) RTS/CTS enabled and the TwoRayGround physical propagation model [28] with a maximal transmission range of 250 m. The vehicle distribution followed the realistic vehicle density statistics from the traffic database of the Traffic Engineering Office, Taipei City Government [32], resulting in a total 1,028 vehicles in this area. Traffic statistics in the database during the period from 08:00 to 09:00, as summarized in Table 7 for Intersection SI081A, consisted of the measured incoming and outgoing traffic information of four road segments from the East, South, West and North, respectively. When a vehicle approached this intersection, it could turn left, right or go straight to the other three road segments. As shown in Fig. 9, the number of total outgoing vehicles, i.e., 872, on the road segment heading East was equal to the sum of the number of incoming vehicles going straight from the West, i.e., 755, that turned right from the South, i.e., 117, and that turned left from North, i.e., 0. Assuming the number of total outgoing vehicles, the maximal velocity limit and the period duration for traffic statistics of road segment sleaving intersection i at p p period p are denoted as Ni,s , Vi,s and T p , respectively, we can formulate the average interp vehicle distance, i.e., Di,s , on road segment s leaving intersection i at period p with Eq. 45

123

A Secure Ambulance Communication Protocol for VANET Table 6 NS2 Simulation parameters

Parameter

1205 Value

Simulation time per round

150 s

Simulation area

4,200 m × 4,200 m

Number of vehicles

1,028

Number of background CBR source-destination pairs Transmission range

2, 4, 6, 8,10

Vehicle velocity

10 m/s

Background CBR rate

10 packets per second

MAC protocol

IEEE 802.11 DCF RTS/CTS

250 m

Physical propagation

TwoRayGround

Data packet size

512 bytes

Fig. 8 The network topology and hospital locations in the simulation

in order to assign initial locations of all vehicles in the 4,200 m × 4,200 m area for the NS2 simulation. For example, the inter-vehicle distance on the road segment toward the East in Fig. 9 was calculated as 1/872 × 50 × 103 ∼ = 57.3 m, if the maximal velocity limit of this

123

1206

C.-L. Chen et al.

Table 7 Traffic statistics of an example intersection (SI081A) Time period

Incoming road segment

Left turn vehicle

Going straight vehicle

Right turn vehicle

(a) Incoming traffic of Intersection SI081A 08:00 to 09:00

East

0

302

100

South

100

727

117

West

681

755

0

0

0

0

North Time period

Outgoing road segment

Vehicle

(b) Outgoing traffic of Intersection SI081A 08:00 to 09:00

East South

872 0

West

402

North

1508

road segment was 50 km/h. p

Di,s =

Tp p p × Vi,s Ni,s

(45)

In the 150-s simulation, we conducted a near-realistic scenario that contained background CBR flows transmitted with the UDP transport protocol between different source-destination vehicle pairs which were uniformly chosen from all vehicles in this area. All background CBR flows started their transmissions at second 25 till the end of the simulation with a packet size of 512 bytes and 10 packets per second, which introduced transmission rates of 40 kbps. For evaluating the performance of our proposed secure ambulance communication protocol accompanied with the aforementioned CBR/UDP background traffic, we adopted three well-known ad hoc routing protocols, i.e., reactive-based Ad-hoc On-demand Distance Vector (AODV) [22], Dynamic Source Routing (DSR) [13] and geographical-based Greedy Perimeter Stateless Routing (GPSR) [15], to forward background traffic packets and those generated by our proposed protocol. Further, we also observed the influence of two transport protocols, i.e., TCP and UDP, on the performance of our secure ambulance protocol. We assumed that the car accidents occurred in the middle of the road segments, which were uniformly distributed among all 40 road segments in the area. For evaluating the performance results of our proposed protocol under an intense and frequent accident scenario, we randomly distributed 50 accidents into the simulation period between second 50 and 100 after the simulation began. In the following, we have compared the average values of three performance metrics for the communication phase, i.e., Steps 6–10 as described in Sect. 4, of our proposed Secure Ambulance Communication protocol with 20 rounds of the 150-s simulation. • Average Session Successful Ratio (ASSR) If a message of any preceding step in the communication phase of our proposed protocol was lost on its way to its destination node, none of the corresponding ones of the following steps would be issued, which in turn would result in a failed session in our simulation. Hence, a successful session has been defined as one in which all of the steps from Step 6 to 10 were

123


1207

Fig. 9 The number of measured vehicles on each road segment of Intersection SI081A during 08:00 to 09:00

successful. Therefore, the average session successful ratio is equal to the quotient of dividing the number of successful sessions (SS) by the number of total sessions (TS) executed in the simulation, which is formulated as Eq. 46: ASS R =

SS TS

(46)

• Average Session Delay (ASD) A session delay is defined here as the duration from the time when the ambulance issues the message of Step 6 to when a successful session is completed. Because the RTA simultaneously issues the message of Steps 9 and 10 to the hospital and the ambulance, respectively, a successful session ends at the time when the ambulance receives the message of Step 9 or when the hospital receives that of Step 10, depending on which value is larger. Hence, the average session delay is equal to the quotient of dividing the sum of the session delays (S Di ) of every successful session i (for 1 ≤ i ≤ SS, i ∈ N) by the number of successful sessions (SS) executed in the simulation, which is formulated as Eq. 47: SS S Di AS D = i=1 (47) SS • Average Session Hop Count (ASHC) The average session hop count is defined here as the quotient of dividing the sum of session hop counts (S H Ci , for 1 ≤ i ≤ SS, i ∈ N) of every successful session i by the number of successful sessions (SS) executed in the simulation, which is formulated as Eq. 48:

123

1208

C.-L. Chen et al.

(a) UDP

(b) TCP

Fig. 10 Average Session Successful Ratio (ASSR) versus the number of Background CBR Traffic Pairs

(b) TCP

(a) UDP

Fig. 11 Average Session Delay (ASD) versus the number of Background CBR Traffic Pairs

SS

S H Ci (48) SS Figures 10, 11, and 12 show the Average Session Successful Ratio (ASSR), Average Session Delay (ASD), and Average Session Hop Count (ASHC) of our proposed protocol with combinations of three well-known routing protocols, i.e., AODV, DSR, and GPSR, and two transport protocols, i.e., TCP and UDP, with respect to the number of background CBR traffic pairs. As the number of background CBR traffic pairs increased, the ASSR of our proposed secure ambulance communication protocol with each routing protocol decreased accordingly, whether TCP or UDP was adopted as the transport protocol, as shown in Fig. 10a, b. Because DSR is a source routing protocol that introduces longer routing headers and packet sizes to carry routing information on each message in the session and every packet of the background flow, more session messages with DSR, especially those having longer hop counts, suffered higher contention and collision probabilities with other messages or background packets. As a result, corresponding ASSR and ASHC values of DSR lagged behind those of GPSR and AODV, as shown in Figs. 10 and 12. However, differences in their ASSR values diminished due to higher packet contention and collision probabilities as the number of background pairs increased. On the other hand, GPSR combines the greedy routing mode with the perimeter mode to escape the local minimum where the greedy mode fails. Hence, it suffered longer AS D =

123

i=1


(a) UDP

1209

(b) TCP

Fig. 12 Average Session Hop Count (ASHC) versus the number of Background CBR Traffic Pairs

paths, i.e., hop counts, with higher delays and contentions as the number of background pairs became larger, which in turn degraded its ASSR. Consequently, as shown in Figs. 11 and 12, ASD and ASHC values of our proposed protocol with GPSR were the highest of all three routing protocols, especially when the background traffic was heavier. Finally, AODV reactively discovers and maintains hop-by-hop routing information on each node when needed. Because our proposed protocol conveyed session messages 6 and 7 between the initial location of the ambulance and the RTA, and messages 8 and 9 between the accident location and the RTA, it performed the AODV route discovery process only twice, instead of maintaining routes continuously on the ambulance’s path to the accident location, which benefitted its performance significantly. Therefore, AODV was the most appropriate routing protocol for our proposed protocol in order to achieve the highest ASSR and lowest ASD, as shown in Figs. 10 and 11. Due to high contention and collision probabilities with background flows, as Fig. 10a illustrates, the ASSR values of our proposed protocol under combinations of the three routing protocols and UDP degraded dramatically to 20 % as the number of background flows increased to 10. Oppositely, if TCP was adopted as the transport protocol to support endto-end reliability for the session messages of the communication phase, the ASSR values of our proposed protocol with these three routing protocols significantly increased to 80 % in this case, as shown in Fig. 10b, with the cost of larger ASD values, which were almost two times those with UDP. As shown in Fig. 11b, our proposed protocol with TCP took no more than 25 s to convey 5 session control messages in the worst case, which was acceptable for dispatching the emergency vehicle. In short, with these simulation results based on realistic vehicle density statistics and a Taipei city road map, we have argued that our secure ambulance communication protocol would be effective in real VANET scenarios.

6 Conclusions In recent years, a secure VANET system protocol has been frequently proposed. In this paper, we have proposed a secure ambulance communication protocol for VANET. The ambulance needs the optimization path to the event location as soon as possible. The ambulance emergency personal can select a path to the event location as quickly as possible, while reporting

123

1210

C.-L. Chen et al.

the situation of the event scene to the RTA to reduce the time consumed travelling from the accident scene to the hospital and thus enhancing the probability of the patient’s survival. In order to ensure that the optimal path of the shortest time-consumption will not be revealed, we used symmetric encryption, message authentication code and digital signature to achieve the following security requirements: • • • • • • • •

Non-repudiation issue Availability issue Integrity issue Confidentiality issue Mutual authentication issue Session key security issue Known-key security issue Known attacks

Furthermore, we also conducted NS2 simulations, which were based on realistic vehicle density statistics and the downtown city road map of Taipei, Taiwan, to evaluate three performance metrics of the communication phase in our proposed secure ambulance communication protocol under all combinations of three well-known VANET routing protocols and two transport ones. According to the averaged simulation results of these three performance metrics, i.e., Average Session Successful Ratio, Average Session Delay and Average Session Hop Count, the proposed scheme improved the time-consuming process of transferring control messages from ambulances to accident scenes or hospitals via VANET. Consequently, we hope this secure ambulance communication protocol will be effective, not only in dispatching emergency vehicles, but also in enhancing the traffic flow of real VANET scenarios.

References 1. Armknecht, F., Festag, A., Westhoff, D., & Zeng, K. (2007, March). Cross-layer privacy enhancement and non-repudiation in vehicular communication. In 4th Workshop on mobile ad-hoc networks (WMAN) 2007,Bern, Switzerland 2. Bouassida, M.-S., Chrisment, I., & Festor, O. (2008). Group key management in MANETs. International Journal of Network Security, 6(1), 67–69. 3. Browse nsnam Files on SourceForge.net, http://sourceforge.net/projects/nsnam/files/, access available on 3 April 2013. 4. Choi, J., & Jung, S. (2009). A security framework with strong non-repudiation and privacy in VANETs. In 6th IEEE consumer communications and networking conference (pp. 835–839), 10–13 Jan. 2009. 5. Das, K. (2008). An identity-based random key pre-distribution scheme for direct key establishment to prevent attacks in wireless sensor networks. International Journal of Network Security, 6(2), 134–144. 6. Duri, S., Gruteser, M., Liu, X., Moskowitz, P., Perez, R., Singh, M., & Tang, J.-M. Framework for security and privacy in automotive telematics. In Proceedings of the 2nd international workshop on mobile commerce (pp. 25–32). 7. Electronic Toll Collection, http://www.gsa.gov/portal/content/104326, access available on 3 April 2013. 8. ElZarki, M., Mehrotra, S., Tsudik, G., & Venkatasubramanian, N. (2002). Security issues in a future vehicular network. In European Wireless’02 conference. 9. Harney, H., & Muckenhirn, C. (1997). Group key management protocol (GKMP). (RFC 2094). 10. IEEE dedicated short range communication standard (DSRC), http://grouper.ieee.org/groups, access available on 3 April 2013. 11. Jiang, D., Birmingham, A. L., & Delgrossi, L. (2008). IEEE 802.11p: towards an international standard for wireless access in vehicular environments. In Proceedings of IEEE vehicular technology conference (pp. 2036–2040). 12. Jiang, N., & Wang, J. (2008). Anonymous authentication protocol for multi-services in wireless environments. The Journal of China Universities of Posts and Telecommunications, 15(4), 69–74.

123


1211

13. Johnson, D.-B., Hu, Y., Maltz, D.-A. (2007). The dynamic source routing protocol (DSR) for mobile ad hoc networks for IPv4. IETF RFC 4728. 14. Jungels, D., Raya, M., Papadimitratos, P., Aad, I., & Hubaux, J.-P. Certificate revocation in vehicular ad hoc networks. Technical LCAReport-2006-006. 15. Karp, B., & Kung, H. (2000). GPSR: greedy perimeter stateless routing for wireless networks. In Proceedings of the 6th ACM annual international conference on Mobile computing and networking (MobiCom), Boston, Massachusetts, United States (pp. 243–254). 16. Ke Liu’s NS2 Code and Q&A, http://www.cs.binghamton.edu/~kliu/research/ns2code/index.html#gpsr, access available on 3 April 2013. 17. Kenney, J. B. (2011). Dedicated short-range communications (DSRC) standards in the United States. Proceedings of the IEEE, 99(7), 1162–1182. 18. Lee, J.-S., & Chang, C.-C. (2007). Secure communications for cluster-based ad hoc networks using node identities. Journal of Network and Computer Applications, 30(4), 1377–1396. 19. Li, C.-T., Hwang, M.-S., & Chu, Y.-P. (2008). A secure and efficient communication scheme with authenticated key establishment and privacy preserving for vehicular ad hoc networks. Computer Communications, 31(12), 2803–2814. 20. Li, W., Wen, Q., Su, Q., & Jin, Z. (2012). An efficient and secure mobile payment protocol for restricted connectivity scenarios in vehicular ad hoc network. Computer Communication, 35(2), 188–195. 21. Mershad, K., & Artail, H. (2013). A framework for secure and efficient data acquisition in vehicular ad hoc networks. IEEE Transactions on Vehicular Technology, 62(2), 536–551. 22. Perkins, C., & Royer, E. (1999). Ad-hoc on-demand distance vector routing. In Proceedings of the second IEEE workshop on mobile computing sytems and applications (pp. 90–100). 23. Perrig, A., Canetti, R., Tygar, J.-D., & Song, D. (2002). The TESLA broadcast authentication protocol. UC Berkeley and IBM Research, 5(2), 2–13. 24. Plößl, K., & Federrath, H. (2008). A privacy aware and efficient security infrastructure for vehicular ad hoc networks. Computer Standards & Interfaces, 30(6), 390–397. 25. Raghunathan, S., Mikler, A.-R., & Cozzolino, C. (2005). Secure agent computation: X.509 Proxy Certificates in a multi-lingual agent framework. Journal of Systems and Software, 75(1–2), 123–137. 26. Raya, M., & Hubaux, J.-P. (2005). Security aspects of inter-vehicle communications. In Proceedings of the 5th Swiss transport research conference, Monte Verità / Ascona (pp. 1–14), 9–11 March, 2005. 27. Raya, M., & Hubaux, J.-P. (2005). The security of vehicular ad hoc networks. In Proceedings of SASN’05 (pp. 11–21). 28. Schmitz, A., Wenig, M. (2006). The effect of the radio wave propagation model in mobile ad hoc networks. In The 9th ACM international symposium on modeling analysis and simulation of wireless and mobile systems, Spain (pp. 61–67). 29. Schneier, B. (1996). Applied cryptography protocols algorithms and source code in C (2nd ed.). New York: Wiley. 30. Stallings, W. (2005). Cryptography and network security (4th ed.). Englewood Cliffs: Prentice-Hall. 31. The American Society for Testing and Materials (ASTM), http://www.astm.org/, access available on 3 April 2013. 32. Traffic flow statistics, traffic engineering office Taipei City government, http://www.bote.taipei.gov.tw/ ct.asp?xItem=660485&CtNode=20205&mp=117031, access available on 3 April 2013. 33. Wasef, A., & Shen, X. (2013). EMAP: expedite message authentication protocol for vehicular ad hoc networks. IEEE Transactions on Mobile Computing, 12(1), 78–89. 34. Yang, X., Liu, J., Zhao, F., & Vaidya, N. (2004). A vehicle-to-vehicle communication protocol for cooperative collision warning. In Annual international conference on mobile and ubiquitous systems: networking and services (MobiQuitous) (pp. 114–123). 35. Zhang, L., Wu, Q., Solanas, A., & Domingo-Ferrer, J. (2010). A scalable robust authentication protocol for secure vehicular communications. IEEE Transactions on Vehicular Technology, 59(4), 1606–1617.

123

1212

C.-L. Chen et al.

Author Biographies Chin-Ling Chen was born in Taiwan in 1961. He received a B.S. degree in Computer Science and Engineering from Feng Cha University in 1991; the M.S. degree and Ph.D. in Applied Mathematics at National Chung Hsing University, Taichung, Taiwan, in 1999 and 2005, respectively. He is a member of the Chinese Association for Information Security. From 1979 to 2005, he was a senior engineer at Chunghwa Telecom Co., Ltd. He is currently a professor of the Department of Computer Science and Information Engineering at Chaoyang University of Technology, Taiwan. From 2011, he is an Editorial Board member of International Journal of Advances in Internet of Things and Modern Internet of Things. His research interests include cryptography, network security and electronic commerce. Dr. Chen had published over 50 articles on the above research fields in SCI/SSCI international journals.

Ing-Chau Chang received his B.S. degree in Department of Computer and Information Science from National Chiao Tung University, Hsinchu, Taiwan, R.O.C., in 1990 and the M.S. and Ph.D. degrees in Institute of Computer Science and Information Engineering from National Taiwan University, Taipei, Taiwan, R.O.C., in 1992 and 1997, respectively. He is currently an associate professor in the Department of Computer Science and Information Engineering, National Changhua University of Education, Changhua, Taiwan, R.O.C. His current research topics include wireless networks, multimedia network protocols, and multimedia systems. He is a member of the Institute of Electrical and Electronics Engineers (IEEE).

Chun-Hsin Chang was born in 1984. He received a B.S degree in the Department of Computer Science and Information Engineering from Diwan University, Tainan Taiwan in 1995. He received his Masters degree in Department of Computer Science and Information Engineering at Chaoyang University of Technology, Taichung, Taiwan. His research interests include VANETs, information security and cryptology.

123


1213

Yuan-Fen Wang received her B.S. degree in the Department of Information from Hsing-Kuo University, Tainan, Taiwan in 2007 and M.S. degree in Department of Computer Science and Information Engineering at National Changhua University of Education, Changhua, Taiwan in 2011. Her research interests include wireless ad hoc networks and vehicular networks.

123