Policy Management for Secure Data Access ... - Semantic Scholar

Policy Management for Secure Data Access Control in Vehicular Networks Dijiang Huang, Wei-Tek Tsai, Yi-hsin Tseng Arizona State University

Abstract The state-of-the-art research in vehicular network security does not address the need for low latency message access control in vehicular applications with tight connection time and message delay requirements. In existing security solutions, the major limitation is that no trust establishment mechanisms that adapt to rapidly changing scenarios and highly mobile environments (mainly because of key management delay, processing overhead, and changing communication peers). To address this issue, we present a policy management framework for secure data access control in vehicular networks. Our solution address two interrelated research areas to achieve efficiency and scalability for data access control and policy management in highly dynamic vehicular networks. The main contributions are in two-fold: (a) Efficient key management and group-based policy enforcement using attribute-based cryptography; and (b) Dynamic security policy management framework and methodology to manage credentials based on role, time, location and other situation dependent attributes. Our solution utilizes efficient attribute-based cryptography algorithm to achieve unprecedented speedups in message processing time to meet the real-time requirement. To demonstrate the effectiveness of our proposed solution, a systematic and comprehensive evaluation is produced to valid our proposed solution.

Key Words: Vehicular Networks, Data Access Control, Security Policy Management.

1

Introduction

Vehicular Networks (VNETs) will enable vehicle-to-vehicle and vehicle-to-roadside communications and are expected to greatly enhance driving safety and improve roadway system efficiency. In many VNET applications, reporting a road situation requires a mechanism for distributing related information to desired vehicles in an efficient manner. In general, communications in VNETs can be classified as Vehicle-to-Vehicle (V2V) communication and Vehicle-to-Infrastructure (V2I) communication, where the infrastructure includes fixed Road Side Units (RSUs) and communication backbone, such as Internet. Before VNET applications can be deployed, many security and privacy requirements [1] have to be addressed.

1

Previous work has been focussed on addressing various security and privacy requirements, such as identity trust (i.e., authentication), data trust (i.e., data integrity and truthfulness), privacy (anonymity and location hiding), and key management [2, 3, 4, 5]. Very few existing solutions address how to specify and control secure access data policies in vehicular networks. To address this limitation, we present a systematic approach to manage the data access policies in a highly dynamic and ephemeral communication environment. Our goal is to build a new secure data access control policy management architecture deliver timely and customized trust support to a broad range of vehicular applications. To achieve our research goal, we investigate into a systematic approach that integrates data access control and policy management using attribute-based cryptography. Using attribute-based solution, we can integrate the policy management and key management effectively. Using attribute-based cryptography, a set of descriptive terms is used as a security policy. Moreover, this set of descriptive terms also serves as the public key to secure the ciphertext. The policy terms can be either static or dynamic. By dynamic, we mean that the road-side conditions can be changed, such as road name, direction, speed limits, etc., which can be considered as terms to describe a policy. When the attributes (or public keys) are dynamic, their corresponding private keys need to be allocated to each vehicle in a timely fashion. Thus an efficient key management solution is required. The main contributions of this article are to address the following two research issues: (a) Using attribute-based cryptography to achieve efficient key management and group-based policy enforcement; and (b) Establishing a dynamic security policy management framework by incorporating a decentralized policy enhancement approach to manage credentials based on role, time, location and other situation dependent attributes. To address the first research issue, we propose a Policy Group based Data Access (PGDA) model to address the efficiency issues incurred by using public-key-based solutions through establishing secure communication groups among vehicles. In PGDA, any vehicle can form a group with its neighboring vehicles. Particularly, PGDA effectively enables all vehicles in the group to share a group key by just broadcasting one message. When a vehicle has to send a message to its desired group members, it creates an encrypted message using a policy tree (PT ) and then broadcasts it. Group members who receive this encrypted broadcasted message can decrypt it if they satisfy the policies enforced by the PT . These policies are usually defined over a set of descriptive attributes. A PT is basically an access tree structure combined by multiple attributes and logical gates, which form one or multiple data access policies. The attributes are used to identify a group of entities who share a set of common attributes. Compared to traditional PKI-based solutions, the message encryption is performed using a group key rather than an individual public key, thus the communication cost is low. Moreover, using PGDA, vehicles can form a group without relying on a centralized group manager to construct the communication groups. To address the second research issue, we present a scalable policy management framework in a decentralized fashion. For each vehicle, it needs to pre-install a set of secrets from a Global Trusted Agent (GTA, i.e., a trusted authority – TA) with respect to its corresponding attributes, such as types of cars, ownership (e.g., company or private owner), licensing state, etc. The GTA can be a vehicular registration authority such as Motor Vehicle Division (MVD) or other trusted 2

organization such as a police department, etc. During the communication phase on-road, a vehicle initiates a group communication by deriving a set of attributes from a Local Trust agent (LTA), e.g., an RSU, to form a data access policy tree. Vehicles owning the specified attributes can decrypt the messages enforced by the attributes. We note that every vehicle can initiate a communication group. The set of attributes are considered as a set of policies enforced for such a group communication. The rest of this paper is organized as follows: Section 2 highlights the related research of this work. In Section 3 details the system assumptions, communication models, and attack model. In Section 4, we present the formation of policy group and its operations. The decentralized policy management framework is presented in Section 5. The Security analysis is presented in Section 6 and performances evaluations are presented in Section 7. Finally, we conclude our work and point the future research directions in Section 8.

2

Related Work

Secure VNET communication protocols have been extensively studied in recent years [6, 7, 8, 9, 10]. From the architectural design aspect, the published work mainly uses traditional shared and public key management solutions addressing entitylevel trust with prime concerns on authentication and message integrity [3, 11]. Trust of the reported data has also been studied [12, 13]. One issue unique of VNETs is vehicle trust based on position verification [14]. Most of the security work published so far fails to develop a real time, low latency trust evaluation and key access control strategy. The policy-based data access control is motivated by the capability of using Identity-Based Encryption (IBE) [15]. Attribute-based encryption [16] extends IBE by incorporating multiple IDs (a.k.a., attributes or descriptive policies) using secret sharing scheme [17]. J. Bethencourt et al. [18] proposed the ciphertext policy attribute-based encryption, where encrypter specifies an access control policy to confine who can decrypt the ciphertext. Our solution is based on ciphertext policy-attribute based encryption (CP-ABE) to address the data access policies in a highly dynamic VNET environment. The detailed description of CP-ABE is presented in Appendix A. In [19, 20], the authors present a basic idea of using ABE schemes to construct a communication group for vehicular networks. A VNET requires a flexible policy-based system that allows dynamic revision and enforcement of the policy possibly at runtime while the application is still running. In the past decade, a number of policy enforcement solutions have been proposed [21, 22, 23, 24, 25, 26, 27]. Recently, security policies have been used in mobile ad hoc networks [28, 29, 30, 31]. However, none of existing solutions address how to handle secure data access policy management in VNETs.

3

System and Models

In this Section, we present the overview of the communication model and attack model.

3

3.1

Communication Model

The communication model includes two networks: vehicular network and social network over the existing Internet. The vehicular network model comprises physical network components such as: on-road units, off-road units, and the interfacing layer. The on-line trusted authority, usually managed by a local transportation department office, uses Internet based security services through RSUs, e.g., WiFi radio [32] and Dedicated Short-Range Communications (DSRC) radio with associated protocol suites [33], or cellular networks for establishing trust. This approach will maximally enable the flexibility and robustness to build up trust among vehicles. Off-road units consist of trusted authorities (TA) which can provide identity-based public key certificate services for users to derive their private keys and identity certificates. Further, we assume that the global trusted agent (GTA) issues long-term cryptographic credentials in advance, and local trusted agents (LTAs) are connected to RSUs. These servers can be viewed as part of the infrastructure support. The Motor Vehicle Division (MVD) or other Government organization runs the GTA, while LTAs are hosted in roadside units and, in some cases, even vehicles. Some cryptographic credentials can be established off-line with long lived validity; others, more dynamic credentials are obtained as the car joins the VNET and travels through the urban grid (e.g., via periodic location registration [34]).

Pre-authentication The communication in VNETs is a two-step procedure. The first step is mandatory for all vehicles entering a particular road segment monitored by an RSU, say Rl . When a vehicle i enters the controlled area of Rl , the vehicle performs preauthentication with the Rl . During the pre-authentication phase, vehicle i exchanges its identity certificate (Certi ) with Rl . To better preserve vehicles privacy, a vehicle can use a pseudo-identity certificate issued from a trusted authority. There are a number of schemes in literature [1, 35], which proposed solutions for achieving vehicles privacy through pseudo-identity certificates. Thus, we assume that the vehicles i uses pseudonym identity certificate Certi for pre-authentication.

Communication Model for Policy Management Framework After the pre-authentication procedure, the next step is the secure communication phase involving secure data access policy management. We use LTAs and GTA to manage the data access control policies. Particularly, an LTA manage all the vehicles within its communication range. Existing RSUs use Dedicated Short-Range Communications (DSRC) radio with associated protocol suites [33], an DSRC transceiver can cover a road segment about 2000 meters (with 1000-meter coverage radius). One LTA can cover an area managed by multiple RSUs, where the number of RSUs depends on the capability of LTA processing vehicles’ requests.

In general, the global policy may not be changed frequently, thus the

GTA may not be always online.

4

3.2

Attack Model

In our presented system, the GTA (i.e., the MVD) is responsible to distribute static attributes and corresponding secrets to vehicles and LTAs (i.e., RSUs) are responsible to distribute dynamic attributes and corresponding secrets to vehicles. We assume that the GTA and LTA are always trusted. A trusted entity is immune to all types of attacks and it cannot be compromised. External malicious attackers can try to impersonate the GTA and LTAs. They can compromise the hardware of vehicles and then derive the pre-installed secret keys. Their goal is to compromise the pre-installed secrets and then disturb secure group communications and access the protected data. However, we assume that cryptographic keys are protected by tamper-proof devices for trusted entities, thus external adversaries cannot derive their secret keys. Collusion can happen among attackers, but not between trusted entities. In a summary, an adversary can deploy the following attacks: • Collusion attacks: vehicles collude to derive arbitrarily selected static attributes and corresponding private keys. • Impersonation attacks: a vehicle impersonates LTAs and other vehicles. • Unauthorized data access attacks: a vehicle can decrypt a message enforced by a policy tree, in which it cannot satisfy the logic operations to the root of the policy tree. The security analysis of our scheme against these attacks is provided in Section 6.

4

PGDA: Constructing Data Accessing Policy Groups for Vehicular Networks

In general, vehicles’ roles, or passengers’ roles, or roadside devices’ roles may determine the types of road information that can be accessed by them. Thus VNETs need to confine the data access for designated groups of vehicles. These groups can be classified based on their functions or roles (e.g., police vehicles, ambulances, private cars, vehicles, commercial vehicles), or network applications (e.g., special functions or particular networking applications). In addition, especially for safety related applications, instantaneous environmental data like location and time should be associated. In this section, we present how to incorporate static roles and dynamic on-road situations, such as location, times, regulations, and events as constraints to build secure data access policies1 .

4.1

Policy Group

Considering a road situation example: a taxi driver wants to inform his fellow drivers in the same company about the business opportunities restricted within a road segment and in a certain time frame. In this situation, security policies such as data privacy and origin integrity are required to ensure the business secret. With SAT, the driver can broadcast the 1 In

Appendix B, we present how to combine static attributes and dynamic attributes using ABE solutions.

5

following message, where the real message M is encrypted by a key s, and signed by a symmetric group key, shared by all drivers belonging to companyA:

Ms = T{companyA ∧ taxi ∧ W ashington Street∧ 10am−11am∧ north−bound} (s)||Es (M )||sigcompanyA ,

(1)

Here the most important feature is the generation of the key s and the associated encryption/decription methods. This example indicates a situation-based key s, which has to use a set of descriptive attributes in the form of (companyA ∧ taxi ∧ Washington Street ...), combined by the logic operator ∧. T forms a tree rooted by the operator ∧. The tree specifies the security policy for the access permission issued to the message M . The descriptive attributes and their combination patten are essential to obtain the key s for encryption and decryption. For this example, all these attributes companyA, taxi, Washington Street, 10am-11am and North-bound must be “True” to access the data encrypting key (DEK) s, and then to decrypt the message Ms . This capability is enabled by using attribute-based encryption (ABE) [18]. Cryptography method backing up the data access tree T , is for each attribute to be considered as a public key component. Thus, the tree T is a set of public key components and the operators. It is sent within the message Ms . The associated private key components should be distributed to each vehicle in companyA in a private way. These public/private key components include both static portion, which are not changed, e.g., companyA and taxi, and dynamic portion, which are changed according to the road situations, e.g., Washington Street, 10am-11am and North-bound. The static attributes and corresponding keys are preinstalled by the GTA; and the dynamic attributes and corresponding keys are distributed through LTAs. Whoever receives this message Ms will try to calculate the key s using its stored private keys. As a result, only the vehicles having the right set of the private keys can legitimately recover the DEK s. Note that, more than one vehicle can use this tree to access M . In this example, the vehicles satisfying the access tree T form a policy group GT . We also call an access tree as a policy tree. As we pointed out earlier, many VNET applications, especially many life-critical safety messages and urban emergent events are intended for groups of vehicles. The approach of attribute-based encryption and situation awareness in data access that is illustrated here presents an efficient construction for secure data access for groups of vehicles. The formation of secure groups is different from traditional methods in that no group establishment phase is required. This property is extremely useful and scalable in a highly dynamic VNET. Moreover, it is very flexible to construct a policy tree according to different data access control requirements. In Table 1, we present a classification of static and dynamic attributes. Their notations and meanings are self-explained.

4.2

Construct policy trees including static and dynamic attributes

Formally, logical operations for combining attributes include AN D, OR, numerical relations and k-out-of-n relations, represented as: logical operator LO = {LOi |∧, ∨, , ≥, k out of n}. An example of T{(A1 ∧ A2 )∨ A3 } (s) indicates AN D and OR logic operations among three attributes {A1 , A2 , A3 }. This access policy in fact describes the following 6

Table 1: Vehicular network polices Static Attributes (SA) – ASA (x) Vehicle Attributes (VA) Vehicle Category (VC) Vehicle Application Or Service (VS) Network Category (NC)

Road Attributes (RA) –ARA (y)

Dynamic Attributes (DA) Environment Attributes (EA) – AEA (z)

Road Direction (RD) Road Intersection (RI) Road Name (RN) Road Segment Number (RS) City Name (EC) State Name (ES)

Emergency Event (EE) Hi Security (HS) Time Stamp (TS) Date (ED) Privacy Protection (PP) Network Situation (NS)

if-statement: if (own(A1 ) ∧ own(A2 )) ∨ own(A3 ),

then decrypt DEK s.

It says that only if a vehicle owns attributes A1 and A2 , or A3 , can it decrypt the DEK s. In an access tree T the attributes are leaves and the logic operators are internal nodes. low

s EA

Priority

T2

s RA

LO 2 A RA (y)...

LO 1

Encryption

... A EA (z)

Decryption

LO 3

T3

s SA

T1 high

A SA (x) ... Policy tree based on attributes

Figure 1: Policy Tree Examples based on Attributes Several representative attributes and classifications for VNETs are given in Table 1. ASA (x), ARA (y), and AEA (z) represent static attributes, road attributes, and environment attributes, respectively. Variables x, y, z represent corresponding static and dynamic attribute values. A general policy tree (T = {Ti }) corresponding to the classifications is constructed and shown in Figure 1. The lower level trees usually have higher priorities and are processed first. The T is enforced through a bottom-up approach, i.e., only if a vehicle (or a user) possesses adequate number of attributes and fulfills logic operators to a certain level (i.e., a logical operator associated with a DEK sSA , sRA , and sEA ), can it access the encrypted data; and the set of vehicles that can access the data form a policy group GT . However, vehicular networks can involve complex composition of applications and situations; there can be many static and dynamic attributes and corresponding public and private key components. The private key components of static and dynamic attributes are derived from different administrative domains (e.g., GTA and LTAs). All these call for an effective architectural solution to combine static and dynamic attributes without exposing the secrets to different domain administrators. In a recent work [20], we presented a solution that considers the attributes that are generated from the same management domain. However, the attack model presented in [20] is not realistic, where all RSUs are trusted. There 7

are two critical issues of [20] need to be addressed: (a) how to construct a workable policy tree by integrating static and dynamic attributes, and (b) how to prevent RSUs and vehicles from colluding to generate valid static attributes and corresponding private keys. In this paper, the presented protocol construction is mainly to address these issues.

5

Security Policy Management in VNETs

Our policy enforcement architecture with distributed agents is shown in Figure 4. This framework has a hierarchical structure with trusted global and local policy enforcement agents (i.e., GTA and LTA, respectively) to help vehicles to generate policy enforcement trees. A high-level policy agent issues global policies to LTAs. The GTA is responsible to issue private keys for vehicles and users; it usually generates private key components for static attributes. Thus, the GTA issues policy updates less frequently than LTAs. Upon accepting the global policy update, each LTA that manages a particular geographical area should verify and update its policy database to ensure compliance. In turn, each vehicle is required to comply with policies enforced by LTAs. Furthermore, the GTA and LTAs can be connected to VNETs through RSI, which includes LTAs, Internet, and telecommunication networks. We must note that the process of policy management should be performed before vehicle starting their secure communication, which is discussed in previous section. Vehicles need to send their policy request before entering the policy enforcement zone. In Section 7.2, we evaluate the required time before they entering the policy enforcement zone.

5.1

Policy Management Architecture

The hierarchical structure is a key for a scalable solution as loads within a region will be mostly handled by distributed regional or local trusted agents. Here, we consider the regional agents are basically delegations of the GTA, which are highly trusted entities. Global, regional and local trusted agents also synchronize with each other either periodically or in needed basis to ensure dynamic policy updates and consistency. Figure 2 highlights the function blocks within an LTA, where multiple islands of grouped meta-policies and policies used to describe the constraints of attributes given in Table 1. Dynamic Attribute-based Policy Specification: The framework uses meta-policies to simplify the creation of new policies or updates of existing policies with constraint analysis and dependency analysis. The GTA, LTAs, as well as individual vehicles, have their own meta-policies. For constructing the 3-level policy tree in Figure 1 used by a vehicle, its local policy agent (with location proximity) will coordinate various activities including: requests received from individual vehicles; global policies enforced by the GTA; and local road situations monitored by LTAs. Furthermore, each vehicle can append its own policy enforcement sub-trees at different priority levels to enable additional self-defined policies. Policies can be specified using various policy languages such as WS-Policy, PSM-P [27] or Boolean expressions with predicate logic and/or temporal logic, such as Linear Temporal Logic (LTL) [36], or a combination of them. Dynamic Policy Registration and Deregistration: Each vehicle can register its desired policy (by sending a policy request) when entering an enforcement zone. The policy will be verified by the local agent first. Each policy engine, 8

Real-time Data Current Traffic Condition

Current Weather Condition

Current Road Condition

Current Event

Partitioned Blackboard Data Structure

Global

Regional

Local

Personal

Shared Area

Synchronization

Prioritization

Resolution

Knowledge Sources Global

Regional

Local

Personal

Company

Special

Organization

Personal

Roles Metapolicy

Figure 2: Policy enforcement architecture. whether global or local, will follow a policy enforcement architecture as shown in Figure 2. Note that this architecture is a modified Blackboard architecture [37], which has a number of islands of grouped firing rules (policies), and a working area where the data are stored and updated. The Blackboard architecture has three components: 1) software modules: this is where policies are stored. In this project, not only policies are stored, but also meta-policies; 2) blackboard: this is the place where shared data are stored; 3) the control shell: this is the place where synchronization, prioritization, and resolution mechanisms shown in Figure 4. The data will be updated whenever there is a change in the system, and a firing rule (policy) will be activated whenever the pre-conditions of a firing rule are satisfied by the road situations. If multiple policies can be activated, there will be coordination effort by synchronization, prioritization and/or resolution. The consistency checking can be performed using our proposed completeness and consistency algorithms for Boolean expressions [38]. As policies are not functional specification but constraints on functionality, policies need to be evaluated with functional code and also dynamically to see the impact on performance and system behavior [27]. Meta-policies can play a significant role as they can constraint the kind of permissible policies. Thus, evaluation will be based on meta-policies with representative policies to ensure that policies are complete, consistent, and provide the right assurance of trust. This architecture is particularly suited to dynamic VNETs where attribute-based policies can be naturally grouped in islands for easy management, and current data stored and updated in the working area provide the current status of the VNET.

9

5.2

Policy of Motor Vehicle Division, Arizona Department of Transportation

This project uses policies enforced by Arizona State Motor Vehicle Division (MVD) for illustration as shown in Figure 3. The top element of the ontology is ”MVD Policies.” The ”MVD Policies” comprises of policies from eight sub-domain categories ”Road Related”, ”Human Related”, ”Registration Related”, ”Location”, ”Time”, ”Security” and ”Category”. For example, the ”Human Related” sub-domain contains all of the policies related to human, e.g., right-of-way policies, entering and crossing traffic policies, whereas the ”Registration Related” related to driver license and vehicle registration. The following diagram shows the ontology for registration-related policies. Registration Related

Classes of Licenses

Road Test

Qualification & Valid Period

Selling Vehicle

Inspection Program

Requirements

Figure 3: Ontology for Registration Related Policy. We present an example of licensing policy in Table 2. Table 2: Policy for Classes of Licenses Classes of Licenses Graduated License

Motorcycle License Instruction Permit

5.3

Policy A graduated driver license is issued to an applicant who is at least 16, but less than 18, years of age and valid to operate any vehicle that does not require a motorcycle or commercial license. A motorcycle license or endorsement is required to drive a motorcycle or motordriven cycle. You must be at least 16 to apply for a motorcycle license. If you are at least 15 years and 7 months of age you may be issued a graduated and/or a motorcycle instruction permit. You must be at least 18 for an operator permit.

Dynamic Policy Registration and Deregistration

Each vehicle can register its desired policy (by sending a policy request) when entering an enforcement zone. The policy will be verified by the local agent first. Each policy engine, whether global or local, will follow a modified Blackboard architecture [37], which has a number of islands of grouped firing rules (policies), and a working area where the data are stored and updated. The data will be constantly updated, and a firing rule will be activated whenever the pre-conditions of a firing rule are satisfied by the road situations. This architecture is particularly suited to dynamic VNETs where attributebased policies can be naturally grouped in islands for easy management, and current data stored and updated in the working area provide the current status of the VNET. The consistency checking can be performed using our proposed completeness and consistency algorithms for Boolean expressions [38]. As policies are not functional specification but constraints on functionality, policies need to be evaluated with functional code and also dynamically to see the impact on performance and system behavior [27]. Meta-policies can play a significant role as they can constraint the kind of permissible policies. Thus, evaluation will be based on meta-

10

policies with representative policies to ensure that policies are complete, consistent, and provide the right assurance of trust.

6

Security Assessment

In this section, we first present the security strength of policy group formation schemes presented in Section 4. We will show that, based on the protocol construction, a vehicle cannot derive valid private key components for dynamic attributes without LTAs’ help. In the following security analysis, we analyze the security features of PGDA under colluding attacks, impersonation attacks, and reply attacks based on the attack model presented in Section 3.2.

6.1

Colluding Attacks

Vehicles cannot collude to derive valid static attributes and corresponding private keys. This is because they do not possess the secret information α, β, and ri (see Appendix A). In order to generate valid private keys for static attributes, attackers ′ must have the private value ri (or g ri ) to generate valid private key components Di,j and Di,j presented in Protocol 2

presented in Appendix A. The proof of this security property can be found in [18]. For dynamic attributes, each vehicle uses two sets of parameters: one for static attributes and one for dynamic attributes. The selection of system parameters ⟨α, β⟩ and ⟨α′ , β ′ ⟩ makes the proposed solution against colluding attacks. However, by ′

sharing private information, LTAs and vehicles can only derive g ri that can be used to derive valid dynamic attributes (j) ′ and corresponding private key components Di,j and Di,j . This colluding attack is only restricted by the colluding entities

and it does not affect other non-colluding vehicles. This is because each non-colluding vehicle has a unique ri selected by the MVD, which cannot be compromised through colluding attacks.

6.2

Impersonation and Illegal Decryption Attacks

Impersonation attacks do not work in our presented protocols. This is because the pre-authentication procedure, presented in Section 3.1, utilizes public key schemes to prevent vehicles from impersonating LTAs, and vice versa. In our presented system model, we assume that the vehicular communication system uses identity-based signature solutions, such as BLS [39]. Additionally, a vehicle impersonating other vehicles is difficult because it does not possess required private keys for others’ identities to produce valid BLS signatures. Similarly an LTA cannot impersonate a vehicle and generate a valid signature. Based on the construction of Protocol 4 presented in Appendix A, a vehicle cannot decrypt a ciphertext without satisfying the policy tree. This is because the private keys of dynamic attributes are eventually computed by vehicles using the tree combination scheme presented in Appendix B. Moreover, malicious vehicles do not have the private key component Di′ = (α′ + ri′ )/β ′ , which makes it is impossible for them to execute the Protocol 4.

11

7

Performance Assessment

The performance assessment includes two portions: (a) the policy tree generation using PGDA, and (b) secure policy management. The performance evaluation of PGDA presents a comparative study based on several solutions addressing the communication and computation efficiency incurred by group based key management during the communication in VNETs. The performance evaluation of secure policy management shows the capacity of the security policy management system responding the vehicles’ requests, which are usually happened before the vehicles starting the group communication. We describe each of them in the following subsections.

7.1

Delay and Communication Performance Evaluation of using PGDA

We evaluate the scheme on the basis of the average latency observed by the message sender to form the policy group, the time taken by the message sender to update the group key on member(s) addition/deletion or location change, the time taken to perform encryption and decryption of a message, and the running time of signature generation and verification. We also analyze the effect of traffic density on the road, which is very important especially when group communication in involved. This is because during group communication all messages are broadcasted. It is possible that a vehicle may receive multiple messages originated from different group members. If the number of neighboring vehicle increases, the number of messages received by a vehicle during a specific time interval may increase. As the vehicle’s computation power is limited, increasing number of messages will increase the time required by the vehicle to process all received messages. Therefore, it becomes essential to consider a number of messages along with traffic density for detailed evaluation of the system performance. To demonstrate the efficiency of PGDA, we compare it with CARAVAN [40] and Mix-Zones [5] (referred to as MZ in the following context). Particularly, we compare PGDA with CARAVAN and MZ for latency measurement and key update. PGDA cryptographic algorithms are implemented in C++. For the elliptical-curve and pairing operations, we used Pairing-Based Cryptography (PBC) Library [41]. We also used the Crypto++ 5.4 Library [42] for routines such as the SHA-256 hash function. For ECC and also for pairing we used the Type-A curve defined in the PBC library with the default parameters [41]. Our performance evaluation is done on a 2 GHz PC with 2 GB memory. The results of each evaluation are averaged over 1000 randomized simulation runs. For PKI, we chose 1024-bit keys, and for ECC, we chose 160-bit keys to ensure the same level of security. The communication model of PGDA is simulated using NS-2 [43]. In order to replicate real-world road environments and vehicle traffic, the mobility model tool introduce in [44] was used. This tool uses the publicly available TIGER (Topologically Integrated Geographical Encoding and Referencing) database from the U.S. Census Bureau. The road system in our evaluation simulation is in Tempe area, Arizona, USA. Each vehicle is positioned randomly on the map and is driving at the speed limit that ranges from 20 - 75 miles/hr for different streets. The simulation area is 1000m × 1000m

12

controlled by a single LTA.

7.1.1

Encryption and Decryption Overhead 10.352

Decrypt Encrpt

10.35

Time (sec)

10.348 10.346 10.344 10.342 10.34 10

20

30

40 50 60 70 Number of attributes

80

90

100

Figure 4: Encryption and decryption overhead of PGDA. Figure 4 shows the encryption and decryption time with increased number of attributes. The majority of time consumed in both encryption and decryption protocol is the result of two point multiplication (about 1.52ms) and one pairing operation (about 7.3ms). It can be seen in the Figure 4 that the running time of encryption and decryption operations are increased with the increasing of the number of attributes.

Average message delay

Average message delay (sec)

7.1.2

0.25 0.2 0.15 0.1 0.05 0 100 100

60

90 80 70

40

Number of attributes

60 50 40

20 30 20 0

10

Number of vehicles

Figure 5: Affect of cryptographic operations on message delay. Figure 5 shows the average message delay of the system with the increases of the number of vehicles and the number of attributes.

From the figure, we can see that the average message delay increases with the number of attributes used

in the policy tree. Moreover, another impact factor is the number of vehicles, in which more vehicles will cause long transmission delay.

13

1.2

CARAVAN MZ

Time (sec)

1

PGDA-100 PGDA-50

0.8

PGDA-10

0.6 0.4 0.2 0 1

2

3

4

5

6

7

8

9

10

Number of vehicles

Figure 6: Comparison of time taken for group key updates. 7.1.3

Comparisons of group key updates latency

Figure 6 draws the comparison of group key updates latencies between CARAVAN, MZ, and PGDA schemes. IN CARAVAN or MZ, if the location changes or a new vehicle joins in, the group key must be updated, where the GL uses the public key of each vehicle to encrypt the updated group key and send them to the respective vehicles. In our evaluation setup, this process takes 0.057 seconds for one-group-member key update. For MZ, this process is followed by additional acknowledgement process time (0.028 seconds). As in both schemes, this procedure is repeated for all group members, the time taken to update key of n vehicles is 0.057n seconds in CARAVAN and 0.085n seconds for MZ. In PGDA, as each vehicle generates their keys, the key updates procedure is efficient. However, the time taken to generate keys in PGDA depends upon the number of attributes for which the keys have to be generated. In Figure 6, we plot the time taken by the vehicle to update keys when the number of attributes in a PT is 10, 50, or 100. it can be seen the PGDA is very efficient compared to CARAVAN and MZ solutions.

7.2

Delay and Communication Performance Evaluation of the Policy Management System

In this subsection, we present the capacity of the policy management system to respond to the vehicles’ request. As we described in Section 5, vehicles need to derive an appropriate policy tree to enforce the data access policies. This is usually done by sending a policy request message to LTAs. Once an LTA received a request, it needs to check if the request can be satisfied by checking its policy database and suggest the best policy tree to the vehicle. In our experiments, we establish a policy management system to handle vehicles’ requests. The experiment is run on a policy processing server based on Windows XP operating system with AMD 2.1GHz CPU. The global policy set is based on Arizona State MVD’s public policies. For the local policies, we consider the following four attributes: location, time, direction, road name. The simulated policy enforced zone is defined as following: a road is a 2000 meters two-lane road segment (controlled by one DSRC enabled RSU), and there is two-way traffic. The segment set in the experiment is 3.5 meters and the average vehicle length is 1 segment. If the condition of the traffic is heavy, it means the distance between each vehicle is equal or

14

less than 1 segment. If it is moderate traffic, it means the distance between each vehicle is between 1 segment and up to 3 segments. If there is light traffic, it means the distance between each vehicle is larger than 3 segments. To demonstrate the impact of policy management system on the system execution time, we present the delay evaluations on a sequence of vehicles’ operations: registrations, update location, update policy, and deregistration, which are described as follows: Event Registration Update location Update policy Deregistration

Event description A new vehicle enters the enforced zone and sends a request for registering. A vehicle sends its location updating periodically. An LTA updates the policy tree with the vehicle. A vehicle which leaves the enforced zone will be deregistered.

The policy requests are simulated by using Poisson Arrival Process for each vehicle in the system:

P =

(λt)n −λt e , n!

where n is the number of vehicles in the policy enforcement zone during time t, λ is the average arriving rate or policy. We simulate the average message arriving rates as 7.5, 10, 15, 20, and 30 per second. The parameters used in the experiment are: the number of requests (including location updates) fired by a vehicle p and total number of vehicles in a specific policy enforcement zone v. Note that the presented system running time is the sum of the delay incurred due to communication and system handling time (the vehicle processing time incurred during the secure communication has been described in previous subsection). We test the system handling time by different conditions in the following three scenarios: (a) dense road traffic, frequent transmissions (228 - 457 vehicles, 15 messages/vehicle), (b) moderate road traffic, moderate transmissions (114 - 228 vehicles, 8 messages/vehicle), and (c) light road traffic, less transmissions (< 114 vehicles, 4 messages/vehicle). In Figure 7, the quantitative analysis of the system delay is presented. Note that the system handling time is not a single run of the experiment in 45 seconds. It is a statistical result which is the average value of 10 samples instead.

Running Time (sec)

Running time with the increased number of policies and vehicles 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

v = 100 v = 150 v = 200 v = 250 v = 300 v = 350 v = 400 v = 450

p = 2 p = 3 p = 4 p = 5 p = 6 p = 7 p = 8 p = 9 p = 10 p = 11 p = 12 p = 13 p = 14 p = 15

Figure 7: Running time increases as more vehicles enter the enforced zone.

15

In the figure, it shows that if each vehicle sends 15 requests to the LTA in 45 seconds and there are 100 vehicles send requests to the LTA, the processing time to generate required policy tree is about 3 seconds. On another extreme, the processing time is about 13 seconds when 450 vehicles send 15 requests for each of them. This figure does not show the system delay in various road conditions. To demonstrate different road conditions, we plot the follow results shown in Fig. 8. Execution Time under Moderate Condition

Execution Time under Stressed Condition

4.5

16

4

14 # of Reqs: 14

10

Time (sec)

Time (sec)

3.5

# of Reqs: 15

12

# of Reqs: 13

8

# of Reqs: 12

6

# of Reqs: 11 # of Reqs: 10

4

3

# of Reqs: 8

2.5

# of Reqs: 7

2

# of Reqs: 6

1.5

# of Reqs: 5

1

# of Reqs: 9

2

0.5 0

0

114

228 248 268 288 308 328 348 368 388 408 428 448 457

124

134

154

164

174

184

194

204

214

228

Number of vehicles

Number of vehicles

Execution Time under Relax Condition 1.2 1 Time (sec)

0.8

# of Reqs: 4 # of Reqs: 3 # of Reqs: 2 # of Reqs: 1

0.6 0.4 0.2 0 0

14

24

34

44 54 64 74 Number of vehicles

84

94

104

114

Figure 8: System delay of policy tree generation with three traffic and requests settings: Stressed, Moderate, and Relaxed.

Fig. 8 shows the system delay with three different settings as described in the above. The diagrams show that the system execution time under stressed, moderate, or relaxed road condition in the defined zone. The maximum number of vehicles could have a capacity of 457 vehicles which means the distance between each vehicle is approximate to 0 (bumper-to-bumper). The data point shows that the system will take 13.94 seconds for processing all of the vehicles in the zone and each of them sends 15 requests within 45 seconds. The fastest time in this zone would be 4.26 seconds for handling 228 vehicles with 9 requests per vehicle. Considering the normal distribution of the vehicle number, the average processing time under stressed condition will be around 8.54 seconds. Similarly, we can derive the system delay for moderate and relax scenarios. The above results showed us the minimal travel time before vehicles entering zone and sending their policy tree generation requests. For example, if the system is highly congested, before entering a zone controlled by an LTA, a vehicle is expected to send its requests 8.54 seconds in advance. In a real system, this requirement is not critical since vehicles can use RSI backbone to transmit requests to remote locations in advance.

16

8

Conclusion and Future Work

In this paper, we first present a novel policy-based group communication scheme using attribute-based cryptography to form on-demand dynamic vehicular groups. Then we present a policy management frame to help vehicles to generate policy trees for data access control. Our research shows that the groups can be formed dynamically with little communication and group management overhead. Additionally, our solution incorporates data access control naturally and it is scalable to handle large number of requests. The evaluation results prove that our scheme is efficient, applicable, and effective when applied to vehicular networks. Next, we will investigate the predictive capability of the policy management framework to handle dynamics of vehicular networks. Additionally, in our current solution, we do not consider that LTAs work together to reduce the amount of information to process. Our future research will also investigate the collaborations among LTAs to improve the performance of the policy management framework.

References [1] Hubaux, J., Capkun, S., Luo, S.: The security and privacy of smart vehicles. Security & Privacy Magazine, IEEE 2(3) (2004) 49–55 [2] Gerlach, M., Festag, A., Leinmuller, T., Goldacker, G., Harsch, C.: Security architecture for vehicular communication. In: Proceedings of the 5th International Workshop on Intelligent Transportation (WIT), March. (2007) [3] Papadimitratos, P., Buttyan, L., Hubaux, J.P., Kargl, F., Kung, A., Raya, M.: Architecture for Secure and Private Vehicular Communications. In: Proccedings of the 7th International Conference on ITS Telecommunications. (2007) [4] Doetzer, F.: Privacy issues in vehicular ad hoc networks. In: Proceedings of Workshop on Privacy Enhancing Technologies, Cavtat, Croatia, Springer (2005) [5] Freudiger, J., Raya, M., F´elegyh´azi, M., Papadimitratos, P., Hubaux, J.: Mix-Zones for Location Privacy in Vehicular Networks. In: Proceedings of WiN-ITS. (2007) [6] Calandriello, G., Hubaux, J., Lioy, A.: Efficient and robust pseudonymous authentication in VANET. In: Proceedings of the fourth ACM international workshop on Vehicular ad hoc networks, ACM Press New York, NY, USA (2007) 19–28 [7] Raya, M., Hubaux, J.: Securing vehicular ad hoc networks. Journal of Computer Security 15(1) (2007) 39–68 [8] Zhang, C., Lin, X., Lu, R., Ho., P.H.: RAISE: An Efficient RSU-aided Message Authentication Scheme in Vehicular Communication Networks. In: Proceedings of IEEE International Conference on Communications (ICC). (2008)

17

[9] Zhu, H., Lin, X., Lu, R., Ho, P.H., Shen, X.: AEMA: An Aggregated Emergency Message Authentication Scheme for Enhancing the Security of Vehicular Ad Hoc Networks. In: Proceedings of IEEE International Conference on Communications (ICC). (2008) [10] Hur, J., Park, C., Yoon, H.: An Efficient Pre-authentication Scheme for IEEE 802.11-Based Vehicular Networks. (2007) [11] Gerlach, M., FOKUS, F.: Trust for Vehicular Applications. In: Proceedings of the Eighth International Symposium on Autonomous Decentralized Systems (ISADS). (2007) 295–304 [12] Raya, M., Papadimitratos, P., Aad, I., Jungels, D., Hubaux, J.: Eviction of Misbehaving and Faulty Nodes in Vehicular Networks. Selected Areas in Communications, IEEE Journal on 25(8) (2007) 1557–1568 [13] Raya, M., Papadimitratos, P., Gligor, V., Hubaux, J., EPFL, S.: On Data-Centric Trust Establishment in Ephemeral Ad Hoc Networks. In: Proceedings of IEEE Infocom. (2008) [14] Yan, G., Choudhary, G., Weigle, M., Olariu, S.: Providing VANET Security Through Active Position Detection. In: Proceedings of VANET’07. (2007) [15] Boneh, D., Franklin, M.: Identity-based encryption from the weil pairing. SIAM Journal of Computing 32(2) (2003) 586–615 [16] Goyal, V., Pandey, O., Sahai, A., Waters, B.: Attribute-based encryption for fine-grained access control of encrypted data. In: Proceedings of the 13th ACM conference on Computer and communications security, ACM Press New York, NY, USA (2006) 89–98 [17] Shamir, A.: How to Share a Secret. Communications of the ACM 22(11) (1979) 612–613 [18] Bethencourt, J., Sahai, A., Waters, B.: Ciphertext-policy attribute-based encryption. In: Proceedings of the 28th IEEE Symposium on Security and Privacy (Oakland). (2007) [19] Hong, X., Huang, D., Gerla, M., Cao, Z.: Sat: Building new trust architecture for vehicular networks. In: Proceedings of the 3rd ACM International Workshop on Mobility in the Evolving Internet Architecture (MobiArch). (2008) [20] Huang, D., Verma, M.: ASPE: Attribute Based Secure Policy Enforcement for Data Access Control in Vehicular Ad Hoc Networks. Ad Hoc Networks Journal (Special Issue of Privacy & Security in WSNs) (2009) [21] Burns, J., Cheng, A., Gurung, P., Rajagopalan, S., Rao, P., Rosenbluth, D., Surendran, A., Martin Jr, D.: Automatic management of network security policy. In: DARPA Information Survivability Conference and Exposition (DISCEX). Volume 2. (2001)

18

[22] Dulay, N.D.N.: The Ponder Policy Specification Language. In: Lecture Notes in Computer Science, Springer-Verlag (2001) 18–38 [23] Hoagland, J., Pandey, R., Levitt, K.: Security Policy Specification Using a Graphical Approach. Technical Report cs/9809124 (1998) [24] Mukhi, N., Plebani, P.: Supporting policy-driven behaviors in web services: experiences and issues. In: Proceedings of the 2nd international conference on Service oriented computing, ACM New York, NY, USA (2004) 322–328 [25] Paul, R.: DoD towards software services. In: 10th IEEE International Workshop on Object-Oriented Real-Time Dependable Systems (WORDS). (2005) 3–6 [26] Tsai, W., Wei, X., Paul, R., Chung, J., Huang, Q., Chen, Y.: Service-oriented system engineering (SOSE) and its applications to embedded system development. Service Oriented Computing and Applications 1(1) (2007) 3–17 [27] Tsai, W., Zhou, X., Wei, X.: A policy enforcement framework for verification and control of service collaboration. Information Systems and E-Business Management 6(1) (2008) 83–107 [28] Chadha, R., Cheng, H., Cheng, Y., Chiang, J., Ghetie, A., Levin, G., Tanna, H.: Policy-Based Mobile Ad Hoc Network Management. POLICY (2004) [29] Chiang, C., Chadha, R., Cheng, Y., Levin, G., Li, S., Poylisher, A., Technologies, T.: A Novel Software Agent Framwork with Embeded Policy Control. In: MILCOM. Volume 5. (2005) 2863 [30] Chiang, C., Demers, S., Gopalarishnan, P., Kant, L., Poylisher, A., Cheng, Y., Chadha, R., Levin, G., Li, S., Ling, Y., et al.: Performance Analysis of Drama: A Distributed Policy-Based System for Manet Management. In: Military Communications Conference (MILCOM). (2006) 1–8 [31] Singh, J., Vargas, L., Bacon, J., Moody, K.: Policy-Based Information Sharing in Publish/Subscribe Middleware. In: Policies for Distributed Systems and Networks, 2008. POLICY 2008. IEEE Workshop on. (2008) 137–144 [32] Anastasi, G., Borgia, E., Conti, M., Gregori, E.: Wi-Fi in Ad Hoc Mode: A Measurement Study. In: Proceedings of IEEE Annual Copnference on Pervasive Computing and Communications (PERCOM). (2004) 145–154 [33] Cseh, C.: Architecture of the dedicated short-range communications (DSRC) protocol. IEEE Vehicular Technology Conference (VTC) 3 (May 1998) 2095–2099 vol.3 [34] Liu, J., Hong, X., Zheng, Q., Tang, L.: Privacy-Preserving Quick Authentication in Fast Roaming Networks. In: Proceedings of IEEE Conference on Local Computer Networks (LCN), Workshop on Network Security, Tampa, FL, Nov. 14-17,. (2006)

19

[35] Papadimitratos, P., Kung, A., Hubaux, J., Kargl, F.: Privacy and Identity Management for Vehicular Communication Systems: a Position Paper. In: Proceedings of Workshop on Standards for Privacy in User-Centric Identity Management, Zurich, Switzerland, July. (2006) [36] Holzmann, G.: The model checker SPIN. IEEE Transactions on Software Engineering 23(5) (1997) 279–295 [37] Nii, H.P. and Stanford Univ. CA Knowledge Systems Lab: Blackboard Systems. Department of Computer Science, Stanford University (1986) [38] Tsai, W., Wei, X., Chen, Y., Paul, R.: A Robust Testing Framework for Verifying Web Services by Completeness and Consistency Analysis. In: IEEE International Workshop on Service-Oriented System Engineering (SOSE). 159–166 [39] Boneh, D., Lynn, B., Shacham, H.: Short Signatures from the Weil Pairing. In: Proceedings of the Asiacrypt 2001, volume 2248 of LNCS. (2001) 514–532 [40] Sampigethaya, K., Huang, L., Li, M., Poovendran, R., Matsuura, K., Sezaki, K.: CARAVAN: providing location privacy for VANET. In: Proceedings of Embedded Security in Cars (ESCAR). (2005) [41] : Pairing-based cryptography library. http://crypto.stanford.edu/pbc/ [42] : Crpto++ library 5.5.2: A free C++ class library of cryptographic schemes. http://www.cryptopp.com/ [43] NS-2: http://www.isi.edu/nsnam/ns/ [44] Saha, A., Johnson, D.: Modeling mobility for vehicular ad-hoc networks. In: Proceedings of the 1st ACM international workshop on Vehicular ad hoc networks, ACM New York, NY, USA (2004) 91–92

Appendix A

CP-ABE Decrypt Protocol

The cryptographic construction of PGDA is based on CP-ABE. PGDA proposes extensions of CP-ABE for vehicular networks and the system is initialized by using a set of publicly known parameters for vehicle i:

paramsi = ⟨e, G0 , G1 , g, p, h, ζ, H, Sis , SKsi , Certi ⟩.

The paramsi can be stored in vehicle i by the GTA at the time of registration. We use i to represent a unique vehicle ID. The detailed explanation of params is given in Table 3. The Protocol 4 presents a sketch of Decrypt protocol presented in [18]. To complete the presentation of our solutions, we present the CP-ABE Decrypt protocol in details. For correctness and security proof of CP-ABE scheme, interested readers should refer to [18]. 20

Notation e g p h ζ H Sis SKsi Certi

Table 3: Publicly Known System Parameters for Vehicle i. Description e : G0 × G0 → G1 is a mapping from additive group G0 to multiplicative group G1 . g ∈ E(F∗p ) is the generator of G0 . order of the multiplicative group G1 . h = g β where β ∈ Zp for static attributes ζ = e(g, g)α where α ∈ Zp for static attributes H : {0, 1}n → {0, 1}n is a one-way function. the set of static attributes pre-assigned to vehicle i. the set of secret keys pre-assigned to vehicle i. a certificate generated by the TA to prove the vehicle i.

We first define a function DecryptN ode(CT , SK, x) that takes as input a ciphertext CT , a private key SK, which is associated with a set S of attributes, and a node x from the attribute tree T . If j is the attribute value of the node x and x is a leaf node, then we can compute the following formulas for vehicle i: DecryptN ode(CT , SK, x) =

e(Di , Cx ) e(Di′ , Cx′ )

=

e(g ri · H(j)rj , g qx (0) ) e(g rj , H(j)qx (0) )

=

e(g ri , g qx (0) ) · e(H(j)rj , g qx (0) ) e(g rj , H(j)qx (0) )

= e(g, g)ri qx (0)

We now consider the recursive case when x is a non-leaf node. The algorithm DecryptN ode(CT , SK, x) then proceeds as follows: For all nodes z that are children of x, it calls DecryptN ode(CT , SK, z) and stores the output as Fz . Let Sx be an arbitrary kx -sized set of child nodes z such that Fz ̸= ⊥. If no such set exists then the node was not satisfied and the function returns ⊥. Otherwise, compute

Fx =

∏

∆j,S ′ (0)

Fz

x

,

z∈Sx

=

∏

(e(g, g)ri qz (0) )∆j,Sx′ (0) ,

z∈Sx

=

∏

(e(g, g)rqparent(z)(index(z)) )∆j,Sx′ (0) ,

z∈Sx

=

∏

e(g, g)ri qx (j)·∆j,Sx′ (0) ,

z∈Sx

= e(g, g)ri qx (0) , (using polynomial interpolation) where j = index(z) and Sx′ = {index(z) : z ∈ Sx }. We define the Lagrange coefficient ∆i,S for i ∈ Zp and a set S, of

21

Table 4: CP-ABE Protocols Protocol 1 Setup 1. Construct bilinear map e : G0 × G0 → G1 of prime order p with a generator g; 2. Choose random numbers α, β ∈ Zp; 3. Calculate the system public key PK = ⟨e, G0 , G1 , H, g, h = g β , ζ = e(g, g)α ⟩ and private master key MK = ⟨β, g α ⟩, where H : {0, 1}∗ → G0 .

Protocol 2 KeyGen(MK, S) For user i = 1, . . . , n: 1. Choose random numbers ri and rj ∈ Zp ∀j ∈ attribute set S; ′ 2. Calculate SKi = ⟨Di = g (α+ri )/β ; ∀j ∈ S : Di,j = g ri H(j)rj ; Di,j = g rj ⟩.

Protocol 3 Encrypt(PK, k, PT ) 1. Create access tree PT ; 2. Choose polynomial qx (0) ∀x ∈ PT ; 3. Starting from root R of PT , choose DEK k ∈ Zp and set qR (0) = s where R is the root of PT ; 4. S is the set of leave nodes of PT , calculates cipher text CT e = kζ s ; C = hs ; ∀j ∈ S : Cj = g qj (0) ; ∀j ∈ S : Cj′ = H(j)qj (0) ⟩; CT = ⟨PT ; C Protocol 4 Decrypt(CT , SK) e(Di,x , Cx ) 1. DecryptN ode(CT , SK, x)= = e(g, g)ri qx (0) , ∀x ∈ PT ; ′ e(Di,x , Cx′ ) 2. Using a recursive procedure and DecryptCiphter method (2), compute the DEK DecryptCipher(CT , SK, R) = e Ce(g, g)ri s = k. e(C, Di ) For detailed descriptions on generations of private keys SK, ciphertext CT , and function DecryptN ode, please refer to [18].

elements in Zp :

∏

∆i,S (x) =

(j∈S,j̸=i)

x−j . i−j

The decryption algorithm begins by calling the DecryptN ode function on the root node R of the tree T . If the tree is satisfied by S we set ζ = DecryptN ode(CT , SK, R) = e(g, g)ri qR (0) = e(g, g)ri s . The algorithm decrypts by computing: e · DecryptN ode(CT , SK, R) C e(C, Di ) αs k · e(g, g) e(g, g)ri s = e(hs , g (α+ri )/β ) k · e(g, g)αs e(g, g)ri s = e(g βs , g (α+ri )/β )

DecryptCipher(CT , SK, R) =

= k.

22

(2)

B

Integration of Policy Trees

The detailed ABE key generation, encryption and decryption algorithms are described in Appendix A. Here, we just preset how to use them at the functional level to describe our solutions. Using dynamic and static attributes, a vehicle can construct versatile policies. kd kd

ks Combined nodes

d tree

ks

S tree

LO

s

S tree

d tree

d tree

S tree

(a)

(c)

(b)

s

d

d s PT (d)

Integration with multiple policy trees

Figure 9: Integration of multiple trees. In Figure 9, we present the ways to combine static and dynamic attributes, where s tree and d tree represent policy trees formed by static and dynamic attributes, respectively. Combining two trees side-by-side is shown in Figure 9(a). Using XOR operator, we can derive the DEK k = kd ⊕ ks . In Figure 9(b)-(c), we present two ways to combine two trees in a top-down fashion. The intersection of two trees is a combined node by integrate a leaf node in the upper tree and the root of the lower tree. In Figure 9(d), we present an example of combining multiple static and dynamic trees. The critical issue of combining multiple trees in a top-down fashion is how to form a combined node from two set of attributes used for different system parameters. In Figure 10, we present a method to make a combined node from two policy trees: PT 1

PT1

LO

Ĉj = gqj(0)

Combined node

j

Masking node k’ qj(0)

Ĉ’j = H(j)

k’

k’

LO

PT2 k’=DecryptCipher(CT,SK)

Figure 10: Integration a policy tree to a node. and PT 2 , where the notations are presented in Table 3 of Appendix A. The ciphertexts produced by PT 1 and PT 2 is

23

presented as follows:

e = kζ s ; C = hs ; ∀j ∈ S1 : CT 1 = ⟨PT 1 ; C

   Cj = g qj (0) , Cj′ = H(j)qj (0) ⟩,

j is not combined;

  Cˆj = g qj (0) ⊕ k ′ , Cˆj′ = H(j)qj (0) ⊕ k ′ ⟩,

j is combined.

CT 1 is created by checking if a node in PT 1 is a combined node. If a node is not a combined node, then the ciphertext component is computed using the normal procedure specified in the Encrypt protocol. If a node is a combined node, then the Encrypt protocol needs to use a masking value k ′ (a.k.a., one-time pad) randomly selected to encrypt the ciphertext components Cj and Cj′ . Once CT 1 is computed, the Encrypt protocol needs to use the masking value k ′ as the encrypted message to construct CT 2 using a different set of public parameters following the procedure of Encrypt protocol: e = k ′ ζ s ; C = hs ; ∀j ∈ S2 : Cj = g qj (0) ; ∀j ∈ S2 : Cj′ = H(j)qj (0) ⟩. CT 2 = ⟨PT 2 ; C ′

′

Combining CT 1 and CT 2 , we have the integrated ciphertext: CT = ⟨CT 1 , CT 2 ⟩.

The decryption procedure is straightforward. A ciphertext receiver first needs to use the Decrypt protocol to decrypt the masking value k ′ in CT 2 ; and then it performs the following bit-wise XOR operations Cj = Cˆj ⊕ k ′ and Cj′ = Cˆj′ ⊕ k ′ to recover the masked values Cj and Cj′ in CT 1 . Finally, the receiver can use Decrypt protocol again to decrypt the DEK encrypted in CT 1 . We must note that the system parameters used in two decryption procedures are different. When there are multiple combined nodes, the above described decryption procedure will be repeated until a message receiver can successfully reach the root and derive the DEK.

Dijiang Huang received his B.S. degree from Beijing University of Posts & Telecommunications, China 1995. He received his M.S., and Ph.D. degrees from the University of Missouri-Kansas City, in 2001 and 2004, respectively. He is an Assistant Professor in the School of Computing Informatics and Decision Systems Engineering (SCIDSE) at the Arizona State University. His current research interests are computer networking, security, and privacy. He is a recipient of Office of Naval Research (ONR) Young Investigator Award 2010.

24

Wei-Tek Tsai received his S.B. in Computer Science and Engineering from MIT, Cambridge, MA 1979. He received his M.S. and Ph.D. in Computer Science from University of California at Berkeley, in 1982 and 1985, respectively. He is a Professor of Computer Science and Engineering in the School of Computing, Informatics, and Decision Systems Engineering, Arizona State University, Tempe, AZ. His research interests are software engineering, service-oriented computing, education, testing, and simulation. Yi-hsin Tseng received her M.S in Computer Science and Engineering from Arizona State University, USA 2009. Her research interests are software engineering and service-oriented computing.

25