Enhancing role-based trust management with a reputation system for MANETs

A typical organization may have many resources, and entities which want to access those resources. For example, in a military setting, there may be resources, such as battle plans, communication systems, surveillance equipment, and weapons systems that may need to be accessed by different personnel at different times. Not all the personnel are granted full access rights to every resource, and so there must be a trust management system (TMS) in place to perform access control. However, it is cumbersome to enforce access rights based merely on an entity's username. Every resource would need to have a database of usernames that are allowed to access it, along with authentication mechanisms to verify the authenticity of usernames provided by users. Making changes to a person's access rights would be a daunting task as every resource that the person accesses would need to have its database updated. Furthermore, having separate databases and authentication mechanisms for each resource makes an attacker's task easier by providing him or her with more potential points of entry.

In response to overcoming some of the challenges in access control, Li et al. introduced role-based trust management (RBTM) [1]. In essence, RBTM combines the merits of some earlier studies by merging the concept of Roles from RBAC (role based access control) [2] with trust management [3], so that entities are granted access to resources based on their "roles." In Section II, we give more background information about RBTM and discuss its merits. However, one of the drawbacks of RBTM is that if an entity is compromised and behaves badly, RBTM cannot distinguish it from the other entities with the same role, and keep granting access to compromised nodes.

To address this problem, we can use reputation systems (RSs) that grant access to entities based on their past behavior [4]. This form of trust management is based on the "reputation" of a node as judged by other entities in the system. Reputation is the opinion of one entity about another [5]. This model is inspired by PGP's (pretty good privacy's) web of trust model [6]. In this model a member node can vouch for a client node that wants access to a resource. The model is based on prior information about the client node [7–9]. A node builds its reputation by previous positive experiences with other nodes. What constitutes a "positive experience" is left to the discretion of the node that vouches for it. In essence, RSs try to predict the future behavior of a node by analyzing its past behavior. Good behavior results in escalation of access rights, whereas bad behavior results in the reduction of rights. However, since there is no notion of roles in RSs, it cannot be readily used for the organizations consisting of designated roles, such as the military, or corporations.

Clearly, a possible combination of these two approaches will be more suitable to manage and control access rights in practical systems. In this article, we specifically investigate how to combine RBTM and RS in the context of closed mobile ad hoc networks (MANETs).^a A typical MANET may have several resources, such as printers, file servers, databases, web servers, etc. In addition, many nodes may provide different services as part of a larger service-oriented architecture (SOA) [10] approach. In SOA, large applications are modularized into smaller services which run on heterogeneous devices. It especially makes sense to use SOA in MANETs so that large, computationally expensive applications can be implemented on resource-constrained devices in a distributed fashion. However, from a security standpoint, we need a mechanism to regulate access to these resources and services so that we can guard them against insiders or outsiders who would misuse these resources or launch attacks against them. Often, different mechanisms are needed to defend the underlying network against the insiders or outsiders. In this article, we focus on defending against insiders by combining RBTM and RS. Defending against outsiders has been extensively investigated in our related study [11] and references therein.

In the context of MANETs, researchers also considered monitoring-based TM to deal with attacks against insiders. In this approach, each node's wireless traffic is monitored by its neighbors, and conclusions are drawn based on its behavior [12, 13]. Many monitoring-based systems have been proposed in the literature [14–18], and the principle behind their operation is that traffic from a node is classified as legitimate or illegitimate by its neighbors. Examples of illegitimate traffic include known attack signatures, viruses, and worms, or anomalous behavior. A node that is behaving well and communicating mostly legitimate traffic is deemed to be trustworthy. Such a node accumulates "good credit" points through its good behavior and slowly gains access to increasingly sensitive resources. This model has a very fast response time. A misbehaving node can quickly be detected, and its traffic can rapidly be blocked. This is because all the information gathering and decision making is done within a node's one-hop neighborhood. Any detected malicious traffic cannot pass beyond this one-hop neighborhood. However, the most serious disadvantage of using monitoring-based TMSs is that they have been shown to raise too many false positives because of noise. According to [19], traditional, simulated noise models do not mimic the behavior of observed noise patterns in an actual setting, leading to optimistic results in simulations. In experiments done on MANET test beds, it was shown that monitoring-based systems do not work well as they raise too many false alarms [20]. Therefore, in our research, we do not consider using monitoring-based systems. Instead we focus on reputation and role-based systems.

Using reputation or role-based TM in MANETs presents a new set of challenges. This has to do with factors such as there is no online central authority, many nodes are limited in their computational resources, nodes may go offline at any time necessitating redundancy, and nodes are not guaranteed to be completely trustworthy [21]. To address some of the challenges associated with MANETs, we first start with RBTM. We then enhance RBTM with the RS that we proposed in our related study [22]. As a result, we create a new hybrid trust management system (HTMS) that can effectively defend against insider attacks by taking the advantages of both RBTM and RSs.

The motivation of HTMS is derived from "real life." For example, a soldier with a long history of working with the army is more reliable than a brand new soldier even though both have the same role. HTMS takes into account the role of an entity, as well as its historical behavior and experiences in order to decide which access rights to be granted to an entity. This approach has the advantages of not granting complete access to a new role, but gradually transferring more rights as the entity becomes more experienced. The process is automatic and it grants rights in small steps, making the access control fine grained. On the other hand, if an entity is deemed to misbehave and abuse its rights, then its rights are reduced even though it still belongs to the same role. In addition, the system stores a history of past transactions and their feedbacks so that administrators/supervisors can review the performance of any entity, and promote/demote it.

The rest of this article is organized as follows. In Section II, we first discuss some background material about RBTMs. In Section III, we address some of challenges in utilizing RBTMs in MANETs. We then describe the proposed HTMS and discuss its merits in Section IV. We evaluate HTMS and present our findings in Section V. Finally, we conclude this article and give some directions for future studies in Section VI.

As mentioned in previous section, RBTM [23] combines the concept of Roles from RBAC [2] with Trust Management [3, 24, 25]. RBTM assigns "roles" to entities/nodes and allows them to access resources based on their roles [26]. In essence, roles serve to characterize entities and represent their arbitrary attributes, such as student, faculty, or staff [27]. In a commercial organization, some personnel might belong to the role "manager," some might belong to "clerical staff," "executive," and so on. All users belonging to a given role are granted certain access rights using policy statements called "credentials." For example, all executives might have complete access to a file server, while all clerks might have "read-only" access. Each credential is issued by an "issuer" to grant access rights to a "subject." The issuer also digitally signs the credential to avoid counterfeiting, possibly using X.509 style certificates [28].

and grant access to Alice. The police department can similarly reconstruct its credential chain and allow Alice to purchase a parking permit. In this way, every enrolled student can enjoy the same access rights easily, without the need for ES to send an updated list of students every semester to every single department at the university.

The rights granted to entities are directly related to the job they need to perform. This follows the real world example where employees/students have access rights based on their job title. The main advantage of RBTM is that it avoids requiring different passwords for each entity or resource. Instead, any entity validates itself to other entities simply by presenting to them its signed credential that assigns to it a given role. The kinds of access rights granted to a given role are fixed beforehand. However, roles may be dynamically assigned to individual entities, and so for instance, an external auditor might temporarily be assigned a "manager" role for a fixed period of time. The main disadvantage of RBTM is that it treats all entities within a role equally. Common observation tells us that not all managers can be equally trusted; for example: some are most trustworthy then others based on their past experience and duration of employment with the firm. It would not be practical to assign such fine-tuned roles as "managers with 10 years experience," "managers with 5 years experience," etc. because then each role would contain very few entities, perhaps even just one entity. To overcome this problem, we propose to use a RS along with RBTM, as discussed in detail later.

The proposed HTMS tries to take the advantages of both the Role based and Reputation-based TMSs by enhancing RBTM with RS. In HTMS, each entity is assigned a role beforehand by an administrative authority. However, all entities belonging to the same role do not necessarily have the same access rights. Within each role, a range of access rights is defined from a minimum privilege level, to a maximum privilege level. For instance, minimum privilege level access could mean that a soldier can only receive communications. Soldiers with higher privilege levels could receive as well as send communications, whereas soldiers with maximum privilege levels could access battle plans.

where Node ID is the ID of the node, and Role is the role title, such as private, major, colonel, or general, and is only meant for human consumption.

MinPL and MaxPL are the numbers between 0 and 1, and where MinPL ≤ MaxPL, respectively, denote the minimum and maximum privilege levels of a given role. Expiration time is the time when the certificate becomes invalid and must be renewed.

This certificate is signed by the administrator and given to the user, say John, who is assigned a role of major. All the majors have the same maximum and minimum privilege levels. John can carry this certificate on a smart card, or this certificate can be linked to John's login credentials so that it becomes active whenever John logs in to a machine. That machine then becomes a node with the Node ID given by John's certificate. In this way, the certificate is not linked with any particular machine, rather with the user himself who is free to switch machines in the network.

A. Determining the Exact Privilege Level

As mentioned before, the exact privilege level of a node at a given point of time is determined by its reputation score, which is computed based on the feedbacks obtained from other nodes through the underlying RS. In general, we can summarize existing RSs [33–38] within the general framework shown in Figure 1. According to this framework, each node that interacts with another node stores some feedback about the interaction. The interaction is either classified as legitimate or suspicious (or some value in between). If, for instance, the interaction consisted of downloading a file, the client could determine if the downloaded file was indeed the one requested, or it was a Trojan or a worm. Based on the feedback of various nodes, a new node can decide whether to transact with a given node or not, even though they may never have interacted before. The underlying principle is that a node that has behaved well in the past is likely to behave well in the future, and so it gets high reputation score. On the other hand, a node that has misbehaved in the past is likely to misbehave in the future, and so it gets low reputation score. For example, eBay utilizes this form of RS where previous buyers leave feedback about the seller so that prospective buyers can decide whether to buy from the seller or not [39].

HTMS can actually use any RS [4, 34, 35, 37]. However, we chose to use our previously proposed Machine Learning-based RS [22, 40] for our experiments. The reasons for this choice are mentioned in Section V. In any case, whichever RS the network administrator decides to use, the only requirement is that the RS outputs a reputation score between 0 and 1, with 0 being the least reputable. The RS needs to guard against the possibility of malicious nodes giving incorrect feedback to malign another node. In case the node has no history, the RS outputs a preset default score, for example, 0.5.

Suppose a client wants to interact with a server. In HTMS, the server needs to first obtain the reputation score of the client. Accordingly, the server broadcasts a feedback request throughout the network. Any node that has transacted with the client before responds to the request and sends back encrypted and digitally signed feedbacks to the server. The server decrypts and verifies the signature of the feedback, and then computes a reputation score using any RS implementation. Once the reputation score is obtained, the final privilege level is computed using the following equation:

$PL=\left(MaxPL-MinPL\right)*RScore+MinPL$

(1)

where PL is the current privilege level, MaxPL and MinPL are the maximum and minimum privilege levels respectively in the given role certificate. RScore is the reputation score, as outputed by the RS. Equation 1 simply normalizes the privilege level between the minimum and maximum levels. An RScore of 0 yields the minimum privilege level, whereas an RScore of 1 yields the maximum privilege level. A server will grant access to the requested service if PL ≥ MinPL for that service.

To simulate the behavior of an actual node that may have been compromised, we use a randomly generated behavior (i.e., Proportion of Good Transactions) curve that fluctuates slowly over time, as illustrated by a dashed blue line in Figure 2.

Privilege levels are defined on a scale from 0 to 1, where 0 represents no access rights to any resource on the network, and 1 represents complete access to all available resources. In our simulation, the system administrator has assigned to node X a certain role, with a maximum privilege level of 0.8 and a minimum privilege level of 0.2. Other roles may have other corresponding minimum and maximum levels assigned by the administrator. The actual privilege level of node X depends on its behavior at any given point in time. In the ideal case, we would like the privilege level at any given time to be proportional to the behavior of the node at that time. If the behavior (i.e., Proportion of Good Transactions) is 1, then the privilege level should be maximum (i.e., 0.8). If the behavior is 0, then the privilege level should be minimum (i.e., 0.2). If the behavior is between 0 and 1, the privilege level will be computed using Equation 1. Hence, it will be any value between 0.2 and 0.8. Under no circumstances will the privilege level be higher than 0.8, or lower than 0.2. The ideal curve for the simulated behavior is illustrated by a solid red line in Figure 2.

The efficacy of a Trust Management (TM) mechanism will be measured by how well it can mimic the ideal curve as closely as possible. The ideal curve, therefore, represents the yardstick against which a TM implementation can be compared. Of course, in this simulation setup, we know the exact behavior of a node; but in an actual setting, we would need to estimate it using the feedbacks obtained from other nodes through the underlying RS.

We generated the training data using simulations on a different behavior curve. The proportion of malicious nodes in the network was varied in different simulations to obtain different training sets. A malicious node is defined as a node that lies and gives incorrect feedback about a node in an attempt to either decrease its reputation, or to increase it if the node is another colluding malicious node. The training sets were then used to train the SVM.

The test sets were generated using the behavior curve illustrated in Figure 2. Feedbacks were taken from the nodes in the network that had transacted with node X. The proportion of malicious nodes in the network was varied between 0% and 70%, so that the feedbacks were not always reliable. Each training and test instance consists of feedbacks obtained over the previous 7 days (i.e., one week). Accordingly, the privilege levels are automatically updated every 7 days so that a given privilege level is valid for one week.

In the first set of experiments, we used a training set consisting of 0% malicious nodes to train the SVM. Then, we tested this model against five different test sets consisting of 0-70% malicious nodes. The output of the model for each test set over time is plotted in Figure 3. The figure shows that the model closely mimics the ideal curve when the proportion of malicious nodes in the test set is also 0%, same as in the training set. For other proportions, the output deviates from the ideal curve, becoming almost a horizontal line at 50%. It becomes a mirror image of the ideal curve above 50%, increasing when the ideal curve decreases and vice versa. This is because after 50%, a majority of the nodes lie about the feedback, giving good feedback when the node is bad, and bad feedback when the node is good. This malicious majority overwhelms the feedback from the minority legitimate nodes, leading the SVM to reverse its output. At 50%, neither malicious nor legitimate nodes can overwhelm each other, and so the SVM produces a constant output of approximately 0.5.

We quantified the deviations of the test curves from the ideal curve by measuring the average overestimation of the curve, when the system grants more privilege than it should have, and underestimations of the curve, when the system grants fewer privileges than it should have. The daily averages of the over-and under-estimations are plotted in Figure 4. The sum of over-and under-estimation gives the overall average discrepancy from the ideal curve. As expected, the smallest discrepancy occurs when the percentage of malicious nodes in the test set is 0%, the same as in the training set. At 0%, the discrepancy is only about 0.008, which means that on average the system is off from the ideal privilege level by ±0.004. However, the discrepancy can be as high as 0.27, when 70% of the nodes are malicious.

We hypothesized that the discrepancy for a given test set would be minimized when the percentage of malicious nodes in the test set would be the same as in the training set. To test this hypothesis, we conducted further experiments, this time using different percentages of malicious nodes in the training sets. For the second set of experiments, we used 30% malicious nodes in the training set and repeated the experiments with the same test sets as before. The results are shown in Figures 5 and 6. Then, we repeated the experiments with 70% malicious nodes in the training set. The results are shown in Figures 7 and 8. The results support our hypothesis that the discrepancy is minimized when the percentage of malicious nodes in the test set is the same as in the training set.

A. Estimating Percentage of Malicious Nodes

Based on our results, we can conclude that to minimize the discrepancy, we need to train the SVM model using a training set that has approximately the same percentage of malicious nodes as the test set. Unfortunately, in a real-world setting, we do not know what the percentage of malicious nodes actually is, and it may vary with time. To overcome this problem, we propose generating several SVM models using different percentages of malicious nodes, for example, 0%, 10%, 20%, and so on. Then, we need to estimate the percentage of malicious nodes in the network, so that we can apply the appropriate model.

Estimation of the percentage of malicious nodes can be done by sampling. To begin with, a node uses a default SVM model, for instance, the one with 10% malicious nodes. Using this model, the node classifies other nodes that try to transact with it as legitimate or malicious and stores this sample. If the node ends up transacting with other nodes, then the outcomes of those transactions are also used for estimating the proportion of malicious nodes. When a sample of a certain size has been gathered in this way, the proportion of legitimate versus malicious nodes is estimated, and the SVM model corresponding to that estimate is used for future classifications. In this way, the proportion estimation is done dynamically, and may vary with time. We actually show next that a sample size of about 20-25 is sufficient for estimating the percentage of malicious nodes in a large network and selecting an SVM model with reasonable accuracy. However, even if we cannot accurately estimate this percentage, HTMS still performs better than just using RBTM which simply makes nodes have maximum privilege all the time.

To show the effectiveness of sampling method, we conducted some experiments to determine what a good sample size would be to estimate the percentage of malicious nodes. We ran simulations with various proportions of malicious nodes in the network. Then we randomly sampled the nodes and determined which of them were malicious. Based on the proportion of malicious nodes in our random sample, we estimated the actual proportion in the entire network. Let A _prop denote the actual proportion of malicious nodes, and E _prop denote the estimated proportion of malicious nodes. Then, we can compute the absolute estimation error as Error = E _prop - A _prop .

Figure 9 shows the Error against various sample sizes. The results show that the error is erratic and unstable until a sample size of about 20. After 20 samples, a fairly good estimate of the actual proportion can be obtained. We therefore recommend that nodes should obtain a sample of at least 20 before adjusting their thresholds.

In this article, we proposed a new HTMS that combines RBTM with RSs. At any given point of time, the privilege level of a node is determined not only by its role in the system, but also by its reputation score. The advantages of HTMS are that it allows automatic, fine-grained access control to network resources based on a node's behavior. If a privileged node becomes compromised and conducts several malicious or risky transactions, then its privilege level is quickly reduced to limit its access to resources and minimize the damage it can further inflict. This is accomplished by utilizing a global picture that is constructed by obtaining feedbacks from many sources on the network in order to determine access rights. If a node behaves well and conducts legitimate transactions, then more privileges are granted to it, providing an incentive to users to behave well. Such fine-grained access control and dynamically assigning privilege levels would be very difficult to accomplish manually.

Other advantages of the system are that it models real-world scenarios where experience and good behavior are rewarded with higher privileges, whereas novices and unreliable entities are only given limited rights. Furthermore, the system is decentralized and prevents a single node from damaging the reputation of others. It also keeps historical records of every node's behavior, making it easy for system administrators to monitor their behavior and promote or demote a node's role.

We evaluated the performance of a particular implementation of HTMS on a simulated network, using our previously proposed SVM-based RS [22]. We determined the ideal response that the system should have and compared the actual response with the ideal as a benchmark. The results show that the actual response is very close to the ideal response if the percentages of malicious nodes in the training and test sets are the same. Since we do not know this percentage in an actual network, we recommended using sampling to estimate this percentage and then using this estimate to determine which SVM model to use for generating maximum accuracy. Even if the estimate is not accurate, HTMS still performs better than just RBTM by itself, since RBTM would simply allow maximum privileges to the node all the time.

In future, we aim to devise better estimation mechanisms that can more accurately determine the percentage of malicious nodes in the network. We also aim to construct better SVM models that are more resilient to changes in the percentage of malicious nodes, and give us better results. This may be accomplished by trying different SVM kernels and varying its parameters.

^aMANETs can be classified as open or closed. In an open MANET, anyone is free to enter or leave the network (e.g., in airports and university campuses), whereas in a closed MANET, only designated nodes are allowed to access the network (e.g., in a military setting). In general, it is more difficult to provide security in an open MANETs since there is no restriction on who may access the network. Fortunately, the security requirements of such networks are also not very demanding since users expect public networks to be insecure. By contrast, closed networks may have very strict security requirements, such as in the military or in the police department.