FMIPv6 based Secure Binding Update Authentication in Wireless Vehicular Networks

Song-Hee Lee* and Jin-Young Choi Korea university {shlee,choi}@formal.korea.ac.kr Abstract

In this paper, we propose a secure binding update authentication scheme in FMIPv6 for wireless vehicular networks. The scheme guarantees mutual authentication, secrecy, and integrity based on preauthentication. We analyze the security of the binding update authentication scheme and the security requirements using AVISPA Tool that supports a rigorous analysis of security.

Nam-Sup Park LG electronics Inc nspark@lge.com

In this paper, we propose a secure binding update authentication scheme using a security association between AR and MN. The scheme provides not only mutual authentication between MN and ARs, but also guarantees secrecy between ARs. Therefore, this scheme is safe against certain attacks such as DoS and redirection. In addition, integrity is maintained in the messages exchanged. We analyze the security of our protocol using AVISPA Tool. The rest of this paper is organized as follows. In Section 2, previous work related to our scheme is introduced. A new secure binding update authentication scheme is proposed in Section 3. We analyze a correctness proof of our protocol using AVISPA Tool, and present a security analysis, in Section 4 and Section 5, respectively. Finally, the conclusions are given in Section 6.

1. Introduction
Pervasive computing has emerged as a new computing and communication environment with the aim of providing services anytime and anywhere for anyone. Vehicular networks may be one of the currently emerging research areas in pervasive computing. Vehicular networks have received attention for their potential in traffic efficiency, road safety, infotainment, Internet access, and pervasive sensing applications [1]. Especially, the new emerging infotainment applications demand vehicular networks to support multimedia and real-time services [2]. Therefore, provisioning of seamless mobility is essential for next generation vehicular networks. As one of the network layer mobility solutions, Fast Handover for Mobile IPv6 [3] (FMIPv6) reduces the handover latency resulting from Mobile IPv6 procedure, via movement detection and a new Care of Address (NCoA) configuration, using the information in advance. Mobile Node (MN) can perform a binding update and receive data destined to MN as soon as a new link to a New Access Router (NAR) is established. However, without corresponding verification of FBU, an adversary can redirect a victim node's traffic, or cause a DoS (Denial of Service) attack. To avoid these attacks, the FMIPv6 signaling messages between MN and Access Router (AR) must be secured to ensure FMIPv6 support for a legitimate MN that has been authorized to obtain such services.
*This work was supported by the Engineering Research Center of Excellence Program of Korea Ministry of Education, Science and Technology(MEST) / Korea Science and Engineering Foundation(KOSEF), grant number R11-2008007-03002-0

2. Related work
There are several existing handover authentication schemes [4, 7] that provide a shared handover key for securing FMIP between MN and AR. In [4], the proposed mechanism utilizes SEND [5] and an additional public/private key pair, the CGA (Cryptographically Generated Addresses) [6] public key pair, to encrypt/decrypt a shared handover key sent from AR to MN. However, the CGA protocol does not recommend using the CGA public key for encrypting the handover key due to potential vulnerabilities such as the Sybil and DoS attacks [6]. In [7], the secure handover scheme establishes handover keys using shared keys. The scheme generates HIK (Handover Integrity) using HMK (Handover Master Key) shared between MN and HKS (Handover Key Server) after the bootstrapping authentication. The HKS-based scheme has a good security feature, but incurs from authentication traffic and RTT (Round Trip Time) latency. These latency problems are unsuitable for realtime services such as infotainment application in vehicular networks.

978-1-4244-2966-0/09/$25.00 2009 IEEE

In order to solve the aforementioned problems in the existing schemes, our scheme focuses on high security via mutual authentications between MN and AAA server, and reduction of authentication traffic and the RRT latency via pre-authentication.

3.1. Bootstrapping Phase

The bootstrapping phase involves two processes. First, MN and AAA server perform an initial full EAP authentication in which a master key (MK) is established between them. EAP authentication can satisfy the mandatory criteria listed in [8] such as mutual authentication support and protection against the man-in-the-middle attack. In the second process the server generates a unique Handover Encryption Key (HEK), which binds the Link-layer address of MN and a new AR, and delivers it to the corresponding AR as shown in Figure 1. HEK is generated as follows:
HEK = KDF ( MK , ID AR || ID MN )

3. Proposed Protocol
In this section, we introduce the proposed secure binding update authentication scheme in FMIPv6. The details of the protocol are depicted in figure 1. The secure handover authentication scheme consists of a bootstrapping phase, for pre-authentication, and a handover authentication phase using a handover authentication key (HAK). Our scheme is described with the notation summarized in Table 1.
Table 1 Notation Description Identity of participant MN Nonce of participant MN Master Key between MN and AAA server Handover Encryption Key between MN and Nth Access Router Handover Key between MN and Nth Access Router Encryption of message M with key HEK. One-way hash function Concatenation operator

(1)

Notation IDMN NMN MK HEKN HKN {M}_HEK H ||

KDF, Key Derivation Function, is a function which derives a secret key from a secret value or other known information such as a password or passphrase. Key derivation functions internally often use a cryptographic hash function [9]. IDAR is the global IP address of AR, with respect to MN. IDMN is the linklayer address of the MN that is sent by the MN in preauthentication.

3.2. Handover Authentication Phase

After a Layer 2 trigger, handover is initiated between MN and Previous AR (PAR). MN transmits an RtSolPr (Router Solicitation for Proxy) message including AP-ID to the PAR currently connected. Upon receipt of the RtSolPr message, PAR transmits a PrRtAdv (Proxy Router Advertisement) message including the information of a new AR (NAR) such as the link-layer address of the NAR, or a network prefix of the subnet, of the NAR to MN. When a PrRtAdv message is received, MN generates NCoA, which is an adaptable address at the subnet via the network prefix of the subnet included in the PrRtAdv message. Both the RtSolPr and PrRtAdv messages use the Link-Layer Address (LLA) option enabling the exchange of two messages (Msg1-Msg2). For generation of a handover key (HK), two messages (Msg1-Msg2) are exchanged between MN and NAR. Msg1 is used for Handover Key request (HKReq) and Msg2 is used for Handover Key Response (HKRes). Each nonce in the messages is exchanged securely due to the one-way property of the hash function. The messages are as follows:
Msg 1 .HK Re q = HKreq _ MAC , HEK ( ID MN , ID PAR , ID NAR , Nonce MN )

Figure 1 Secure binding update protocol

(2)

Msg2.HK Re s = HKres_ MAC, HEK(IDMN , IDPAR, IDNAR, Nonce , Nonce ) MN NAR

(3)

perform protocol falsification and bounded verification via infinite numbers of sessions.

Where HKreq_MAC is the value of H(HEK, IDMN ||IDPAR||IDNAR||NonceMN) and HKres_MAC is the value of H(HEK,IDMN ||IDPAR ||IDNAR||NonceMN,|| NonceNAR ) MN derives HEK via Eq. (1). After the exchange of the two messages, MN and NAR generate a handover key, HK, for handover authentication. HK is generated as follows:
HK = PRF ( HEK , IDNAR || IDMN || NonceMN || NonceNAR )

4.1. Security Requirements

In this section, we consider reasonable security requirements for the participants involved. Security is essential to the handover procedure. It is generally accepted that, in order to be considered secure, a handover procedure must satisfy the following fundamental security requirements [14]: integrity, confidentiality (forward/backward secrecy), and authentication. The following security properties are highlighted in our scheme: Mutual Authentication: MN and NAR are authenticated mutually via HK. Secrecy: Msg1 and Msg2 exchanged between MN and NAR are kept secret from an adversary. HK is only shared between MN and NAR. Neighbor ARs can not derive HK. Moreover, the key is kept secret from the adversary. Integrity: Msg1 and Msg2 exchanged between MN and NAR cannot be altered by an adversary.

(4)

HK is derived using the pseudo-random function (PRF), HEK, and concatenation of the addresses of NAR and the mentioned MN, and the nonces of MN and NAR. PRF is a pseudo-random number function that produces a sequence of values based on a seed and the current state. Given identical seeds, PRF always outputs an identical sequence of values [9]. Next, MN transmits a Fast Binding Update (FBU) message including NCoA to PAR via Msg3. Msg3 contains FBU_MAC as well as the FBU message. FBU_MAC is the value of H(HKN,NCoA||NonceNAR). HI_MAC is forwarded to NAR with HI (Handover Initiate) via Msg4. HI_MAC is the value of H(HKN, NCoA||NonceMN). When the message is received, NAR generates HK using Eq. (4), and verifies that what is received is equal to what is generated. If verification is successful, then NAR transmits a Handover Acknowledge (Hack) message and assumes that HKN is shared and Handover is secure. When a Hack message is received, PAR transmits an FBack message to notify the result to MN and NAR. Then, the packet sent to MN is forwarded to NAR.

4.2. HLPSL Specification

HLPSL is a role-based language, meaning that we specify the actions of each kind of participant in a module. Hence, HLPSL creates a role for each participant in the protocol, modeling protocol steps as transitions in a role, and then models the desired security properties of the protocol. In this section, we do not describe the HLPSL semantics in detail (for more information on HLPSL refer to [11]), we merely highlight various elements important for our model.

4. Formal Verification using AVISPA

In order to analyze the security of the proposed scheme, we used the Automatic Validation of Internet Protocols and Application (AVISPA) Tool [10], which is a push-button tool for analyzing security-sensitive protocols and applications, assuming of perfect cryptography and the Dolev-Yao intruder model. AVISPA uses High Level Protocol Specification Language (HLPSL) [11], which is a modular and expressive formal language for specifying protocols and associated security properties. It integrates different back-end tools that implement a variety of automatic analysis techniques. For our formal analysis, we employed OFMC [12] and CL-AtSe [13], which are the two mature back-ends of the tool. They both

Figure 2 Abstracted scenario

For the specification of our scheme, we abstracted the details of the proposed secure binding update authentication scheme as shown in Figure 2. We assumed that pre-authentication has already occurred.
Msg1.MNNAR : HKreq[HKreq_MAC.{IDMN.IDNAR, IDPAR.NMN}_HEK] % where HK_MAC = H(IDMN.IDNAR, IDPAR.NMN) )

Msg2.NARMN :HKres[HKres_MAC.{ IDMN.IDNAR, IDPAR.NMN .NNAR }_HEK] % where HKres_MAC=H(IDMN.IDNAR, IDPAR.NMN .NNAR) Msg3. MNPAR :FBU, FBU_MAC % where FBU_MAC = PRF(HK, NCoA, NNAR) and Msg4.PARNAR:HI, HI_MAC %where HI_MAC =PRF(HK, NCoA, NMN)

guarantees integrity. The last two goals mean that MN and NAR are authenticated mutually. Therefore, the handover between MN and NAR is authenticated securely.
goal % the HEK(sec_hek_mn and sec_hek_ar) is secret % between the MN and the NAR secrecy_of sec_hek_MN, sec_hek_ar % the HK(sec_hk_mn and sec_hk_ar) is secret % between the MN and the NAR secrecy_of sec_hk_MN, sec_hk_ar % authentication and integrity of the HEK_mac1 in Figure 3 authentication_on nmn % authentication and integrity of HEK_mac2 in Figure 3 authentication_on nar % the MN authenticates the NAR authentication_on hk1 % the NAR authenticates the MN authentication_on hk2 end goal

Figure 3 Sequence of the abstracted scenario

Figure 3 shows the sequences of events represented in HLPSL. The sequences are represented with a general notation. The HLPSL specification uses participants to enact each role, and also specifies how many concurrent sessions of the protocol are running. Figure 4 shows the HLPSL code specifying an intruders initial knowledge, and the concurrent sessions. Overall, four sessions of the protocol were modeled and checked concurrently, to ensure that the goal of Figure 5 is realized. In Figure 4, the first two identical sessions are useful for finding replay attacks.
role environment() def= intruder_knowledge={mn,ar,kdf,prf,i} composition session(mn,ar,f1,f2,f3,kdf,prf) /\session(mn,ar,f1,f2,f3,kdf,prf) /\session(i,ar,f1,f2,f3,kdf,prf) /\ session(mn,i,f1,f2,f3,kdf,prf) end role

Figure 5 HLPSL specification of goal

4.3. Verification Results

To verify a protocol specification modeled in HLPSL, we employed On-the-Fly Model-Checker (OFMC)[12] and CL-based Model-Checker (CLAtSe)[13], which are the two back-ends of AVSPA Tool, for complete automated analysis. OFMC builds the infinite tree defined by the protocol analysis problem in a demand-driven manner. It can be employed not only for efficient falsification of protocols, but also for verification for a bounded number of sessions without bounding the messages an intruder can generate. CL-AtSe [13] provides a translation from any security protocol specification into a set of constraints which can be effectively used to find attacks on protocols. These tools employ the standard Dolve-Yao intruder model. The results of OFMC and CL-AtSe are shown in Figure 6 and Figure 7 respectively. The results show that the security goals after validation are realized and that the protocol had no attack found over a bounded number of sessions. Besides, OFMC was successfully run with the anti-replay option, which means that even if an intruder witnesses multiple instances of the scheme, the intruder cannot replay or forge messages or threaten the aforementioned security goals.

Figure 4 HLPSL specification of role environment

We specified the following goals: secrecy of HEK and HK between MN and NAR; authentication and integrity of messages exchanged; and mutual authentication between MN and NAR; Figure 5 shows the security related goal in the HLPSL specification. For secrecy, the goal facts assert which values should be kept secret between participants. For instance, the first phrase in Figure 5, secrecy_of sec_hek_mn, sec_hek_ar, means that sec_hek_mn and sec_hek_ar are secret. Here, sec_hek_mn is HEK of MN and sec_hek_ar is HEK of NAR. Therefore, HEK is shared and kept secret between MN and NAR. The second phrase means that HAK is shared and kept secret between MN and NAR. For authentication, the goal facts are used to check that a participant correctly believes that its intended peer is present in the current session, has reached a certain state, and agrees on a certain value, which typically is fresh. In Figure 6, the third phrase, authentication_on n_mn, means that n_mn is authenticated by NAR. Here, n_mn is the nonce of MN. The nonce is encrypted by HEK and sent to NAR with the hashed value of the nonce of MN. The encrypted and hashed values are used for authentication and integrity. The fourth phrase means that the nonce of NAR is authenticated by MN, and

6. Conclusion
In this paper, we proposed a secure binding update authentication scheme based on pre-authentication. The scheme guarantees mutual authentication, secrecy, and integrity between MN and ARs. In addition, our scheme reduces the authentication latency due to preauthentication between MN and an authentication server. This scheme is suitable for vehicular networks, since these networks provide a prediction path to anticipate a vehicles route and prepare it for known hazards.
Figure 6 Result of OFMC

7. References
[1] N. Ravi and L. Iftode, A Note on Pervasive Computing, In Proc. CMPPC07, 2007 [2] Q. Mussabbir, W. Yao, Z. Niu, and X. Fu, Optimized FMIPv6 Using IEEE 802.21 MIH Services in Vehicular Networks, IEEE Transactions on Vehicular Technology, Vol. 56, No. 6, Nov. 2007. [3] R. Koodli, Mobile IPv6 Fast Handovers, RFC4068, April 2008. [4] J. Kempf and R. Koodli, Distributing a symmetric FMIPv6 handover key using SEND, RFC5269, Nov 2007 [5] J. Arkko, J. Kempf, B. Zill, and P. Nikander, SEcure Neighbor Discovery (SEND), RFC3971, March 2005 [6] T. Aura, Cryptographically Generated Addresses (CGA), RFC 3972, March 2005. [7] V. Narayanan, N. Venkitaraman, H. Tschofeng, G. Giaretta, and J. Bournelle, Establishing handover keys using shared keys, IETF draft-vidya-mipshop-handover-keys-aaa04, March 2007. [8] D. Stanley, J. Walker, and B. Aboba, Extensible authentication protocol (EAP) method requirements for wireless LANs, RFC 4017; March 2005 [9] Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996. [10] L. Vigan, Automated Security Protocol Analysis with the AVISPA Tool. In Proc. MFPS'05, ENTCS 155:61-86, Elsevier 2005 [11] Y. Chevalier, L. Compagna, J. Cuellar, P. Hankes Drielsma, J. Mantovani, S. Modersheim, and L. Vigneron, A High Level Protocol Specification Language for Industrial Security-Sensitive Protocols. In Proc. SAPS04, Austrian Computer. Society, 2004. [12] D. Basin, S. Modersheim, L. Vigano, An On-The-Fly Model-Checker for Security Protocol Analysis, In Proc. of ESORICS'03, LNCS 2808, pp. 253-270, 2003. [13] P. Ammirati and G. Delzanno, Constraint-based Automatic Verification of Time Dependent Security Properties, In Proc. SPV03, 2003. [14] H.Wang and A.R. Prasad, Fast Authentication for Interdomain Handover, In Proc. ICT 2004, LNCS 3124, pp.973982, August 2004.

Figure 7 Result of CL-AtSe

5. Security Analysis
Table 2 shows the comparison of the existing schemes and our scheme. Our scheme is more secure and efficient than the existing schemes. In [4], there is no additional latency with an authentication server, but potential attacks such as Sybil and Dos have been found. In [7], certain attacks such as replay, MITM, DoS have not been found, but there is an RRT latency and authentication traffic with an authentication sever. Our scheme is safe against known attacks and more efficient than [7] because the number of messages exchanged with the authentication server during handover is less than that of [7].
Table 2 Comparison of the existing schemes and our scheme
Kempf et al [4] Known attacks Crypto Algorithm # of Msgs exchanged with server during handover Potential Sybil and DoS attacks RSA, Hash Narayanan et al [7] Safe Symmetric key, Hash Two Our scheme Safe Symmetric key, Hash None

None