Short-lived Key Management for Secure ...

4 downloads 1564 Views 2MB Size Report
with a central certification authority might be problematic. In this paper, we ... application to a VANET communication scenario. .... distribution model (e.g., the PUs periodically disseminate it without any explicit .... of c with the key ki: MAC(ki,m).
Short-lived Key Management for Secure Communications in VANETs Stefano Busanelli, Gianluigi Ferrari, and Luca Veltri Wireless Ad hoc and Sensor Networks (WASN) Laboratory Department of Information Engineering, University of Parma, Italy Phone: +39-0521905768, Fax: +39-0521905758 E-mail: {stefano.busanelli,gianluigi.ferrari,luca.veltri}@unipr.it

Abstract—Vehicular Ad-hoc NETworks (VANETs) are witnessing an ever increasing interest. Security is a key aspect to pave the road to commercial deployments, as malicious attacks may increase the risk of accidents. Key management in VANETs poses further problems, as connectivity is limited and communication with a central certification authority might be problematic. In this paper, we propose a novel approach to key management for securing VANET communications. In particular, a general framework for key group multicast is proposed, with specific application to a VANET communication scenario.

I. I NTRODUCTION Nowadays, most of the vehicles available on the market possess sensorial, cognitive, and communication skills. In particular, leveraging on Inter-Vehicular Communications (IVCs)—a set of technologies that provides vehicles with networking capabilities—vehicles can create decentralized and self-organized vehicular networks, commonly denoted as Vehicular Ad-hoc NETworks (VANETs). VANETs may involve the use of either network interfaces mounted on the vehicles, typically denoted as On-Board Units (OBUs), and/or fixed network nodes, usually referred as Road Side Units (RSUs). IVCs can be used by a plethora of services with different requirements, ranging from safety-critical applications [1] to bandwidth consuming infotainment applications [2]. The needs of such a large spectrum of applications cannot be satisfied by a single technology and, hence, a complete IVC system has to rely on multiple technologies. For example, an existing Wide Area Network (WAN) (e.g., a cellular network) could provide continuous Internet connectivity to the vehicles, while Dedicated Short Range Communications (DSRCs) technologies could provide a “proximity” connectivity with the surrounding vehicles and/or RSUs, leading, respectively, to the so-called Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communications. While WANs usually exploit consolidated technologies, DSRCs introduce a new communication paradigm, based on dedicated technologies and protocol stacks. The de facto international DSRC standard is the WAVE protocol, composed by the IEEE 802.11p [3] and the IEEE 1609 protocol stacks [4]. The IEEE 802.11p standard is focused on the physical and medium access control layers, while the IEEE 1609 standard defines higher layer services, such as system architecture, security, resource management, and the communication

model [4]. In particular, the IEEE 1609.2 standard provides state-of-the-art security services architecture [5] and, for this reason, has gained worldwide consensus. For example, it has also been considered in the European projects coordinated by the Car-2-Car Communications Consortium (C2C-CC) [6]. In this work, we propose a novel approach to secure data exchanges in a VANET when data is disseminated amongst a larger number of users by means of multihop broadcast V2V communications. Security is provided in terms of authentication, integrity protection, and confidentiality services. In particular, the main contribution of this work consists of an innovative key management mechanism, that can be used for establishing a set of time-varying group-keys shared by all the authorized application users. The group-keys are derived from a couple of independent hash chains. A hash chain is a widelyused cryptographic primitive, introduced by Lamport [7] and firstly employed in the S/KEY system [8] for generating onetime passwords. Basically, a hash chain is a sequence of values that are generated by consecutive applications of a cryptographic hash function (for example, MD5 [9] or SHA1 [10]) to a single (secret) key. Since a hash function is a oneway function, the hash chains are also denoted in the literature as “one-way chains” [11]. In recent years, hash chain-based mechanisms have found a fertile application ground in VANETs. For example, they are used in [12], where the authors solve the problem of assigning a set of group-keys to the vehicles located in a small spatial region in the proximity of a RSU. In particular, in [12] the keys associated to consecutive road segments are related by a hash chain relationship. Hash chains have been also used for implementing efficient broadcast authentication mechanisms [13]. For example, the TESLA broadcast authentication mechanism [11], that has been successfully proposed both for VANETs [14] and for wireless sensor networks (with the name of µ-TESLA) [15], makes use of a common secret key generated by means of a hash chain. More recently, the Novel and Efficient one-way Hash chain-based Certificate Management (NEHCM) scheme [16] and the Message Authentication ACceleration (MAAC) protocol [17] exploit hash chains in order to simplify the certificate revocation process and, thus, accelerate message authentication. The structure of this paper is the following. In Section II, the key aspects of the information dissemination application

Service Provider

Secondary Users

Unauthorized Users

Secure V2I Link

Primary User

Unsecure V2V Link

Fig. 1. A graphical representation of the data-flow of the considered application.

considered in this work are described. In Section III, the security architecture is presented. In Section IV, a new technique for generating a series of short-lived group-shared secret keys for confidential V2V communications is proposed. Finally, concluding remarks are given in Section V. II. A N A PPLICATION FOR I NFORMATION D ISSEMINATION IN VANET S In this work, we consider the perspective of a service provider interested in offering a service (partially) based on VANET communications. In particular, the considered service is quite similar to that proposed within the X-NETAD project [18]. In a few words, the target application consists in disseminating information owned by a limited number of privileged users to a larger number of unprivileged users, by means of multihop broadcast V2V communications, as shown in Figure 1. The application requires the presence of dedicated (or preexisting) VANETs and is only based on V2V communications (e.g., the presence of RSUs is not necessary). Regardless of the nature of the VANETs, we assume that the vehicles are equipped with OBUs compliant with the IEEE 802.11p standard and adhering to the IEEE 1609 protocol suite. In particular, the OBUs implement all the security services defined in the IEEE 1609.2 standard. The application can be installed on the on-board computer of a vehicle or it can be executed on a smart-phone or other after-market equipments (e.g., GPS navigators). The application should be able to send and receive packets through the OBU by means of a local connection (e.g., Bluetooth or a wired communication bus). We consider a very simple Service Level Agreement (SLA) between the service provider and the users, which foresees three distinct categories of users: (i) Primary Users (PUs); (ii) Secondary Users (SUs); (iii) Unauthorized Users (UUs). The PUs are privileged users that periodically retrieve the information of interest, from the service provider, through Internet connection provided by a third-party WAN (e.g., cellular networks). The SUs obtain information from the PUs via V2V communications according to a push content distribution model (e.g., the PUs periodically disseminate it without any explicit query from the SUs), but they cannot receive the information directly from the service provider. Finally, the UUs are unauthorized users (e.g., users without

a valid account) must not have access to the information exchanged between PUs and SUs. Without loss of generality, it can be assumed that the subscriptions have limited durations and, hence, have to be periodically renewed. Moreover, since a user could issue (or cancel) a new subscription at any time, its status could unpredictably change over time. In practice, the distinction among the three different roles defined in the SLA is implemented through an access control service, e.g., a service restricting access to resources reserved to privileged entities. In particular, a confidentiality service is used to prevent UUs to have access to the reserved contents. Once the confidentiality service has been established, the distinction between PUs and SUs can be easily managed by the service provider in a centralized manner. The confidentiality service can be determined by encrypting the message with: a group-shared secret key; a receiver-shared secret key (through symmetric cryptography): or a receiver public key (using asymmetric cryptography). In the first case, it is sufficient that the sender encrypts and multicasts only one copy of the message. Conversely, in the other cases, multiple copies of the message should be sent, each encrypted with a different receiver-shared or public key. For this reason, the problem of providing message confidentiality can be mapped into the problem of sharing a common group key between all the participants, under the assumption that a node can freely join or leave this group (for example, for commercial or administrative reasons). Coherently with these considerations, the information exchanged in a VANET will always be encrypted via symmetric cryptography: and all the authorized users will share a common secret key (e.g., a group-shared key). The problem of establishing a common group key will be addressed in detail in Section IV. III. G ENERAL S ECURITY A RCHITECTURE Generally speaking, a VANET should provide several distinct security services, which can be summarized as follows [19]. • • • • • •

Confidentiality: keeping secret the information from UUs. Access control: restricting the access to reserved resources for PUs and SUs. Integrity: ensuring that the transmitted information cannot be modified by UUs. Authentication: certifying that the origin of a message is correctly identified. Identification: establishing the identity of a user. Non-repudiation: preventing the sender of a message from denying having created that message.

In the multihop communication scenario presented in Section II, the vehicles route messages trough the entire network by broadcasting them to all neighbors within their coverage area. In order to protect messages against eavesdropping, modification, and/or fake message forging by unauthorized malicious nodes, message authentication and confidentiality should be properly implemented before sending messages to the neighbors.

Unique ID Long-term public key

Long-term certificate

Data packet

Short-term certificate 1

Short-term PK1

Encrypted Payload: c || MAC(c, ki ) || Sig(SK i , e)

Short-term certificate n

Short-term PKn

Cert(PKi ) (optional)

CA

Keys Manager

Secure V2V communications Fig. 3.

Service Provider

ka

ka+1

kb-1

kb

Short-term symmetric keys

Fig. 2.

Security architecture of the considered application.

As anticipated in Section I, each vehicle supports the IEEE 1609.2 protocol suite. In particular, the IEEE 1609.2 standard defines the following security functionalities [5]: •

• •

where c=Enc(ke, m)

digital signatures using Elliptic Curve Cryptography (ECC), specifically Elliptic Curve Digital Signature Standard (ECDSA), by using the Fp curves defined by the NIST [20]; asymmetric encryption with ECC, specifically Elliptic Curve Integrated Encryption Scheme (ECIES) [21], [22]; purely symmetric scheme: authenticated encryption, specifically counter mode encryption, and CBC-MAC with AES (AES-CCM) [23].

Therefore, the IEEE 1609.2 standard defines primitives sufficient for providing data authentication, non-repudiation, data integrity, and confidentiality. However, the IEEE 1609.2 standard does not address several critical questions, namely: (i) privacy; (ii) key management; (iii) identity management. In order to address these issues, several security architectures have been proposed in the literature. In this work, we have considered a general architecture largely based on that introduced in [24]. In particular, the node architecture is shown in Figure 2. Coherently with the main goal of this work, we will not detail the characteristics of the security infrastructure, but we will only sketch it. First of all, a Public Key Infrastructure (PKI), constituted by several Certification Authorities (CAs), is established. The vehicles communicate with the CAs through either cellularbased or RSU-based communications. Each vehicle has a unique IDentification (ID), a pair of long-term private-public keys, and a long-term certificate issued by a CA upon node registration. Actually, the long-term credentials are not directly used, but they are needed to issue second-level short-term credentials, denoted as “pseudonyms”, which are actually used for securing V2V communications. The goal of using pseudonyms is twofold: (i) to reduce the risk of compromising the long-term credentials; (ii) to increase the privacy of the vehicle. However, it is important to remark that since shortterm certificates need to be issued from CAs, then pseudonyms can be used only if Internet accesses are frequently available

Structure of the packet with emphasis on its encrypted payload.

to the vehicles. To summarize, with respect to a legacy IEEE 1609.2 system, the proposed architecture provides (i) a higher level of privacy and (ii) key and identity management systems. Since it can be assumed that, at any given time, all the authorized nodes in the network share a common secret key k (on the basis of the considerations carried out in Section II), it is now possible to define the operations performed by a PU that sends an encrypted packet. 1) To generate two sub-keys ki and ke from the common secret key k. 2) To encrypt the message (denoted as m) with ke : c = Enc(ke , m). 3) To compute the Message Authentication Code (MAC) of c with the key ki : MAC(ki , m). 4) To compute the signature of c with the private key Ski : Sig(Ski , c). 5) To compose the packet as follows: c||MAC(ki, c)||Sig(Ski , c) 6) If required, to attach the certificate Cert(PKi ) and, finally, to send the message. The structure of the packet built according to these operations is shown in Figure 3. Once the encrypted message has been correctly received, a user should perform the following operations. 1) To obtain the public key PKi from Cert(PKi ) (if it is attached). 2) To generate two sub-keys ki and ke from the common secret key k. 3) To verify the integrity of the message, by computing the MAC of c with the key ki , and compare it with the received MAC. 4) To verify the signature of c with the public key PKi (if known). If user does not know the public key it can also decide not to verify the signature at all. 5) To finally decrypt the message c with ke , after having verified the authenticity and the integrity of the packet: m = Dec(ke , c). IV. P ER - GROUP C ONFIDENTIALITY The problem of securely distributing a common secret key among the authorized users can easily be addressed by the PUs, since they have secure links towards the service provider. However, it is not an easy task to be addressed for the SUs. In fact, according to the considered dissemination paradigm, the SUs do not necessarily have an Internet access, and they

Service Provider

Local Group III

Local Group II

Local Group I

Fig. 4.

a node joins the system and has to remain for n intervals of time, it will receive by the system a set of n different keys, shared with all nodes that will belong to the system during the same period of time. Then, the problem becomes how to create and distribute such keys, without having to explicitly generate and send them to the nodes, and without requesting the nodes to explicitly store such a large amount of keys, with lack of communication and storing resources. The problem can be formalized as follows. Problem: How to obtain h keys {Ka , Ka+1 , . . . , Kb } out of . properly generated n keys {K0 , K1 , . . . , Kn−1 } (with b = a + h − 1, ∀n, a, h | n, a, h ≥ 0, a < n, h < n − a), without explicitly listing all h keys. Solution: We consider the two sequences {xi } and {yi } defined as . x0 = x xi

General view of the data dissemination application.

get in contact with the service provider only at the time of the subscription (or renewal). A typical scenario is shown in Figure 4. Under these conditions, there are two different ways for distributing the secret keys to the SUs. • The keys are distributed from the service provider at the time of the users’ subscription renewals. According to this “global” solution, all the authorized users share the same key independently of their positions. • The keys are distributed from each PU to the users in its proximity. According to this “local” solution, the authorized users have different keys depending on their positions. With the latter (local solution), the SUs associated with different PUs have different shared keys and, therefore, would not be able to communicate together, thus avoiding the roaming of the messages between SUs associated with different PUs. For this reason, in this work we have considered the first centralized solution, since it reduces the burden for the PUs and simplifies the roaming of the messages. Hence, in this section we focus on the problem of distributing a common group at the moment of the subscription or renewal of the service. We assume that a node may join or leave the system in different moments which, for the sake of simplicity, can be distributed according to a daily granularity. We assume that a node may join the system anytime, scheduling at that moment also the instant when it will leave the system, with the possibility to extend this duration or rejoin later at any time. A. Problem Formulation Under the above assumptions, all nodes obtain, by an administrative authority, at the moment of joining the system, a set of group keys, each of them valid for a precise interval of time that separate two different events (join or leave). For example, one could consider such intervals equally distributed and coinciding simply with a day or a week or a month. If

yn − 1 yi

= H(xi−1 ) = H i (x)

i>0

. = y = H(yi+1 ) = H n−i−1 (y)

i ≤ n−1

where H(·) is a cryptographic one-way function. For example, any hash function, such as SHA1 or MD5, can be used. Both sequences xi and yi are completely generated, respectively, by the two initial values x = x0 and y = yn−1 that are the values of the sequences xi and yi in the extremes of the interval (at 0 and n − 1, respectively). We define Ki as follows: . Ki = H(xi kyi )  = H H i (x)kH n−i−1 (y) i ∈ {0, 1, . . . , n}. The sequence {Ki } can be always determined by the pair of extremes (x, y). Note that, in order to minimize the required values, both x and y can be derived from a single value z as x

= x0 = H(z)

y

= yn−1 = H( f (z))

where f (z) is any function of z. For example, one can set f (z) = z + 1 and y = H(z + 1). If a restricted set of h keys {Ka , Ka+1 , . . . , Kb } is required . (with b = a + h − 1), such a set is uniquely determined by the pair of extremes (xa , yb ). The key Ki can be simply calculated from xa and yb as   Ki = H H i−a (xa )kH b−i (yb ) . Note that the values xa and yb cannot reveal any other key outside the interval [a, b], i.e., it is impossible to obtain any other key Ki with i < a or i > b. As stated above, the entire interval of n keys is determined by the two extreme values x0 = x and yn−1 = y, or by a value z used to derive these two values. If the number of keys is too large to consider that all keys are generated from a single pair of values of x and y (or, equivalently, by z)—e.g., because the number of times that the function H(·) has to be called

becomes too large (since xi = H i (x) and yi = H n−i−1 (y))—the key space can be divided into sub-intervals, each of which has size n and is uniquely determined by the corresponding generating value z. If we consider m of these sub-intervals and we indicate with z j the corresponding generating value (with j ∈ {0, 1, . . . , m − 1}), then z j and the corresponding entire set of Kij can be calculated as follows: z j = H(u j kv j ) where uj vj

. = H(u j−1 ) = H j (u0 ) . = H(v j+1 ) = H m− j−1 (vm−1 )

and xij

= H i (x0j ) = H i (H(z j )) = H i+1 (z j )

yij

j = H n−i−1 (yn−1 ) = H n−i−1 (H(z j + 1)) = H n−i (z j + 1)   = H xij kyij

Kij

where Kij is the i-key of the j-interval. Given two initial values us and yt , each key calculation requires at most 1 + (n) + 1 + (m − 1) = m + n + 1 iteration steps of function H(·). B. Application Example: Broadcasting in VANETs We want to generate one key per day for VANET users, starting form January 1, 2011 to December 31, 2110; this corresponds to daily keys for 100 years starting from January 1, 2011. In this case, using the above notation, we can set n = 366 (i.e., the maximum number of days in a year) and m = 100 (i.e., the hypothetical lifetime of the application). Therefore, in order to generate all keys the VANET Key Distribution Center just needs to generate and secretly maintain the two values u0 (that is u(year2011) ) and vm−1 (that is v(year2110) ): all keys can be derived using the scheme presented in Subsection IV-A. If a vehicle needs to join the system from (for example) October 2, 2011 to October 1, 2031 (i.e., 20 years from October 2, 2011), all keys are uniquely determined and given to the user through the following six values:   x(2.10.2011) y(31.12.2011)  u(year2012) v(year2030)  x(1.1.2031) y(1.10.2031) where u, v, x, and y have the same meaning as in Subsection IV-A. No more keys outside the selected sub-interval are revealed from such a 6-tuple. The maximum number of iterations of H(·) required for a key is 467. However, one can observe that the same value of z j is used for all keys of the same year. This means that, given z j , the maximum number of iterations is n + 1 = 367, while the maximum number of iterations for the calculation of z j is 1 + (m − 1) = m = 100.

V. C ONCLUDING R EMARKS In this paper, we have presented an innovative scheme for generating a series of short-lived secret keys, shared by all the subscribers of a service, regardless of their geographic positions, of their connectivity capabilities, and of the starting and ending times of their subscription periods. The proposed algorithm is based on a couple of hash-chains, generated by repeatedly applying a hashing algorithm (e.g., MD5 or SHA1) to a master key. The obtained secret keys are used in a symmetric cryptographic algorithm to offer group-level confidentiality and group-level integrity services, required to avoid the access to reserved information from UUs. The proposed scheme can be easily integrated with the system architecture of state-of-the-art VANET-based communication systems. In particular, by combining the proposed algorithm and the most common security services offered by traditional VANET communication systems, it is possible to provide group-level confidentiality and integrity, together with per-user authentication and non-repudiation. ACKNOWLEDGMENTS This work is carried out under the one-year project “CrossNetwork Effective Traffic Alerts Dissemination” (X-NETAD, Eureka Label E! 6252 [18]), sponsored by the Ministry of Foreign Affairs (Italy) and The Israeli Industry Center for R&D (Israel) under the “Israel-Italy Joint Innovation Program for Industrial, Scientific and Technological Cooperation in R&D.” The authors would also like to thank Alice Michelotti (University of Parma) for support and help. R EFERENCES [1] R. Chen, W.-L. Jin, and A. Regan, “Broadcasting safety information in vehicular networks: issues and approaches,” IEEE Network, vol. 24, no. 1, pp. 20 –25, January 2010. [2] M. Gerla and L. Kleinrock, “Vehicular networks and the future of the mobile Internet,” Computer Networks, vol. 55, no. 2, pp. 457–469, 2011. [3] “IEEE Standard for Information technology–Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Wireless Access in Vehicular Environments,” IEEE Std 802.11p-2010 (Amendment to IEEE Std 802.112007), pp. 1–51, July 2010. [4] Insitute of Electrical and Electronics Engineers, “IEEE 1609-2006. IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE),” 2006. [5] ——, “IEEE 1609.2-2006. IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) - Security Services for Applications and Management Messages,” 2006. [6] “Car-to-Car Communication Consortium.” [Online]. Available: http: //www.car-2-car.org/ [7] L. Lamport, “Password authentication with insecure communication,” Communications of the ACM, vol. 24, no. 11, pp. 770–772, 1981. [8] N. Haller, “RFC 1760 the S/KEY one-time password system,” The Internet Engineering Task Force (IETF), 2005. [9] R. Rivest, “RFC 1321: The MD5 message-digest algorithm,” The Internet Engineering Task Force (IETF), 1992. [10] Federal Information Processing Standards Publication, “FIPS 1803. Secure Hash Standard (SHS),” 2008. [Online]. Available: http: //csrc.nist.gov/groups/ST/toolkit/secure hashing.html [11] A. Perrig, R. Canetti, J. Tygar, and D. Song, “The TESLA broadcast authentication protocol,” RSA CryptoBytes, vol. 5, no. 2, pp. 2–13, Summer/Fall 2002. [12] M. Verma and D. Huang, “SeGCom: secure group communication in VANETs,” in Proc. IEEE Intl. Conf. on Consumer Comm. and Networking (CCNC), Las Vegas, NV, USA, January 2009, pp. 1–5.

[13] J. Y. Kim, H. K. Choi, and J. A. Copeland, “An efficient authentication scheme for security and privacy preservation in V2I communications,” in Proc. IEEE Vehicular Technology Conf. Fall (VTC-Fall), Ottawa, Canada, September 2010, pp. 1–6. [14] Y. Hu and K. Laberteaux, “Strong VANET security on a budget,” in Proc. ISITS Conf. on Embedded Security in Cars (escar). Berlin, Germany: ISITS, November 2006. [15] D. Liu and P. Ning, “Multilevel µTESLA: Broadcast authentication for distributed sensor networks,” ACM Trans. Embed. Comput. Syst., vol. 3, no. 4, pp. 800–836, November 2004. [16] Y. Sun, R. Lu, X. Lin, J. Su, and X. Shen, “NEHCM: A novel and efficient hash-chain based certificate management scheme for vehicular communications,” in Proc. ICST Intl. Conf on Commun. and Networking in China (CHINACOM), Beijing, China, August 2010, pp. 1–5. [17] A. Wasef and X. Shen, “MAAC: message authentication acceleration protocol for vehicular ad hoc networks,” in Proc. IEEE Global Telecommun. Conf. (GLOBECOM), Honolulu, HA, USA, 2009, pp. 1–6. [18] “Eureka project 6252 X-NETAD,” http://www.eurekanetwork.org/project//id/6252. [19] A. Weimerskirch, J. J. Haas, Y.-C. Hu, and K. P. Laberteaux, “Data security in vehicular communication networks,” in VANET Vehicular Applications and Inter-Networking Technologies, H. Hartenstein and K. Laberteaux, Eds. Wiley Press, 2010, ch. 9, pp. 299–365. [20] Federal Information Processing Standards Publication, “FIPS 1863. Digital Signature Standard (DSS),” 2009. [Online]. Available: http://csrc.nist.gov/ [21] Insitute of Electrical and Electronics Engineers, “IEEE 1363-2000. IEEE Standard Specifications for Password-Based Public-Key Cryptographic Techniques,” 2000. [22] International Organization for Standardization, “ISO/IEC 18033-2:2006 Information technology – Security techniques – Encryption algorithms – Part 2: Asymmetric ciphers,” 2006. [23] National Institute of Standards and Technology (NIST), “NIST Special Publication 800-38c: Recommendation for block cipher modes of operation: The CCM mode for authentication and confidentiality,” March 2004. [Online]. Available: http://csrc.nist.gov/publications/ nistpubs/800-38C/SP800-38C updated-July20 2007.pdf [24] P. Papadimitratos, L. Buttyan, T. Holczer, E. Schoch, J. Freudiger, M. Raya, Z. Ma, F. Kargl, A. Kung, and J. Hubaux, “Secure vehicular communication systems: design and architecture,” IEEE Commun. Mag., vol. 46, no. 11, pp. 100–109, November 2008.