Integrating a High-Reliability Multicriteria Trust Evaluation Model with Task Role-Based Access Control for Cloud Services

Abstract

Cloud data storage is revolutionary because it eliminates the need for additional hardware, which is often costly, inconvenient, and requires additional space. Cloud data storage allows data owners to store large amounts of data in a flexible way and at low cost. The number of online cloud storage services and their consumers has therefore increased dramatically. However, ensuring the privacy and security of data on a digital platform is often a challenge. A cryptographic task-role-based access control (T-RBAC) approach can be used to protect data privacy. This approach ensures the accessibility of data for authorized consumers and keeps it safe from unauthorized consumers. However, this type of cryptographic approach does not address the issue of trust. In this paper, we propose a comprehensive trust model integrated with a cryptographic T-RBAC to enhance the privacy and security of data stored in cloud storage systems, and suggests that trust models involve inheritance and hierarchy in the roles and tasks of trustworthiness evaluation, where this study aims to identify the most feasible solution for the trust issue in T-RBAC approaches. Risk evaluations regarding other possible flaws of the design are also performed. The proposed design can decrease risk by providing high security for cloud storage systems and improve the quality of decisions of cloud operators and data owners.

1. Introduction

Cloud computing technology is an internet-based computing modality that offers on-demand resources, online storage, and access to resources that are not located on local servers. The use of online cloud computing services has increased with the development of internet technology [1,2,3]. Cloud computing is a diverse utility that involves clients who are both insiders and outsiders, as well as servers for storage, internet systems, and cloud providers [4]. This computing platform has gained dominance in the business sector as a result of its minimal operational and maintenance costs. Service providers use cloud computing to provide their customers with reliable, quick, and flexible services [5]. While offering these services to cloud consumers, service providers need to prioritize the security and privacy of cloud data. Privacy and security have always been a challenge for digitally available data as most of the data is offered in the public domain. To curb this situation, we need to use a cryptographic approach, T-RBAC, to provide protection for the privacy of data available on digital platforms of cloud computing. T-RBAC enables authorized consumers to access data but denies unauthorized users the opportunity to reach the data. Nonetheless, such a cryptographic approach is not capable of addressing issues pertaining to trust. In this paper, we propose a comprehensive trust model integrated with a cryptographic T-RBAC to enhance the privacy and security of data stored in cloud storage systems, and suggest that trust models involve inheritance and hierarchy in the roles and tasks of trustworthiness evaluation, where this study aims to identify the most feasible solution for the trust issue in T-RBAC approaches. The proposed design can decrease risk by providing high security for cloud storage systems and improve the quality of the decisions of cloud operators and data owners.

Different providers of cloud services may offer a wide range of cloud services, which may include IaaS, PaaS, SaaS, either singly or as a combination of all of them in a public domain by use of the internet. The providers of cloud services can make advertisements for their cloud services by using the internet, e.g., via search engines. Other consumers of such cloud services, on the other hand, may use the available cloud services to host their own services, which is common for new startups with limited funding. A cloud service provider may give feedback or make inquiries concerning the trust values of cloud consumers by invoking a management trust service which is constituted of many distributed nodes. The nodes of a trust management system (TMS) expose interfaces to receive feedback or inquiries concerning trust results from the consumers in a decentralized manner [6,7,8]. The TMS discovers the available cloud services via the internet and allows consumers to access the new cloud service’s trust by searching. The TMS may also market the trust to consumers as a service through the internet.

1.1. Cloud Access Control Systems

Security is crucial to cloud services primarily because these services are mostly offered in the public domain [9,10]. Public platforms are accessible to a variety of users, both insiders and outsiders; hence, the security of such services needs to be maintained. In some cases, the owners of the data stored in the cloud require a high level of privacy from the public and the cloud providers themselves. To offer privacy and security in such a situation, access controls are used [11,12,13]. Several factors must be considered when selecting an appropriate access control model; these include cost-effectiveness, affordability, security, efficiency in curbing misconduct, and the trust built as a result of using the model. Trust is a critical element to secure cloud computing services [14,15]. The authors in [1] define trust as “an implicit property that exists in the background rather than being an explicit property, which is well-defined and quantifiable”. These models include attribute-based access control (ABAC), role-based access control (RBAC), discretion access control (DAC), and mandatory access control (MAC) [16,17,18]. Integrating trust with cryptographic task-role-based access control (T-RBAC) to secure data stored in the cloud, on the other hand, is more convenient and enhances cloud users’ interaction in the roles and tasks associated with the owners’ data. There is also a need for a control method that will develop trust regarding the tasks carried out by individual users. In this research, we propose a design that allows a trust model to be integrated with a cloud storage system that uses a cryptographic T-RBAC approach.

Several studies have been performed regarding access control policies and system designs deemed suitable for the implementation of cloud computing frameworks. In this study, we introduce the T-RBAC as a new access control model integrated with a comprehensive trust model by applying different criteria to provide high security for cloud storage systems while taking flexibility into consideration. T-RBAC functions in such a way that all users in the system are assigned to one role or different roles, and each role has many tasks within an enterprise setting. Although T-RBAC provides a complex security mechanism that supports the security structure of a network with physical servers, it is not suitable for distributed environments. To improve security in cloud computing environments, it is imperative to employ trust models to enhance the privacy and security of the data stored in cloud storage systems.

In cloud computing, many existing access control models have trust-based systems, but these trust models do not offer precise trust value computations because they may be exposed to some security threats. Thus, an accurate trust-based T-RBAC model is proposed to resolve this vulnerability [19]. The T-RBAC model is based on the RBAC model, but the T-RBAC model takes the idea of tasks into consideration, thereby providing more security and flexibility than the RBAC model [20,21]. Therefore, we propose a trust model that uses the T-RBAC model to manage access to cloud storage. T-RBAC supports dynamic real-time security management and applies the concept of access control over tasks, which are the minimum units for cloud computing activities.

In Figure 1, the permissions in the RBAC model are given to the role, and the permissions of these roles are assigned to specific consumers [22,23,24]. Figure 2 shows task-based access control (TBAC), where the permissions are assigned to tasks, and the tasks are assigned to specific consumers [20]. Because of this, the TBAC model creates a direct relationship between the consumer and the task, which makes maintenance management more complex. In Figure 3, the permissions in the T-RBAC model are assigned either to roles or tasks [20,25]. If permissions are assigned to tasks, then tasks are assigned to roles, and so a consumer can obtain permission to access the cloud storage through either roles or tasks. Therefore, tasks are the minimum units in our architecture. In our trust model, the roles represent the consumers’ roles for all consumers that are given permission to access the service data and a task represents one operation of the service data.

1.2. System Motivations

Figure 4 demonstrates a trust-based T-RBAC model in the cloud environment. A T-RBAC model has four main parties. The first are the data owners who have a tendency to share and store their information or resources within the cloud. Then, there are the users who need to use the shared resources of the owners. The third party refers to the roles that provide access levels to the registered cloud users, and the fourth are the tasks that are allocated for each role. Three possible models emanate from the integration of the trust model with the T-RBAC model in the enhancement of the cloud computing storage system: recommender owner-role, consumer-role, and consumer-task based T-RBACs. The data owners can evaluate the trust value of the roles and tasks, which in turn evaluates the user’s trustworthiness in the three models.

The T-RBAC system model works as follows. First, resources/services are shared by the owners, i.e., the service providers (SPs), with the roles or tasks based on roles’ and tasks’ trust level and reputation. The registered users in each role receive access to the shared resources/services when their trust level is more than the minimum trust acceptance level of the roles, while the registered users in tasks receive access to the shared services or resources when their trust level is more than the minimum trust acceptance level of the tasks. It is clear that the reputation of the role or task that has been registered by the user will change with modifications in the trust level of users, which will consequently alter the users’ privileges. There are five kinds of trust in this system: the owner’s trust in the recommendations of the other owners; the owner’s trust in the functionality of the tasks; the owner’s trust regarding the functionality of the roles; the role’s trust regarding the users’ functionalities; and task’s trust in the users’ functionality. The motivation behind choosing this T-RBAC approach is as follows:

• It provides the highest degree of flexibility, which is the basis for interactions in the cloud environment, by enhancing cloud users’ interaction in the roles and tasks associated with the owners’ data.
• It develops trust regarding the tasks carried out by individual users.
• Many existing access control models have trust-based systems, but these trust models do not offer precise trust value computations because they may be exposed to some security threats. Thus, an accurate trust-based T-RBAC model is proposed to resolve this vulnerability.
• T-RBAC supports dynamic real-time security management and applies the concept of access control over tasks, which are the minimum units for cloud computing activities.

1.3. Problem Statement

Issues of authorization or authorized access to computers or computing devices owned by organizations, whether profit or nonprofit, are serious concerns that can also occur in open environment systems such as a cloud computing system [26,27]. Hence, access controls are commonly used in server applications for cloud computing platforms [28,29]. However, all previous studies have found that access controls are not reliable overall for distributed systems, the primary reason being that the population of consumers is dynamic and complex and their identities are not established in advance [30,31]. With such concerns, integrated trust models with access control models are the best option for decentralized systems with complex consumer bases [23]. This particular model is the result of many attempts made by trust model developers to design new trust models that can resolve the most complicated and advanced authorization issues. However, many access controls that are integrated with trust models that have been already proposed [5,32,33] are defenseless against some attacks. In light of this, we will use a T-RBAC model as a new access control model for a cloud storage system. However, despite T-RBAC’s status as a new access control in cloud computing, we must take the evolution of security threats over time into consideration.

1.4. Contribution

This research focuses on the T-RBAC model and its application to access control to provide secure cloud data storage. The main contribution is that T-RBAC uses cryptography to ensure the safety of data within a cloud storage system. There already exist several studies of trust management systems with the RBAC model, but we are introducing the task-role-based access control or T-RBAC as new access control integrated with a comprehensive trust model by applying different criteria to provide flexibility and high security for cloud storage systems. This research proposes the use of tasks and roles together with cryptography to provide better protection for the stored data.

The trust in a consumer depends on the historical behavior of the tasks and the roles. Therefore, in this research, the impacts of task hierarchy and inheritance on the trust in the task and consumer are evaluated. Additionally, we identify the criteria that need to be applied when using trust-based systems and suggest an acceptable comprehensive trust-based T-RBAC model that provides privacy and security of data storage in cloud systems to fulfill the desired security requirements, and that provides an efficient and reliable architecture. Finally, we used T-RBAC to simplify security management on a large scale. Tasks are used to give consumers permission to access an available resource, assigned according to the tasks performed by the consumer. The T-RBAC model is suitable for distributed computing activities with multiple access points and controls and lays the foundation for active security models. Active security models are models that approach security modeling from the perspective of tasks; these tasks provide an active work mechanism and security management as the task proceeds to completion. To make this effective, we propose a trust model that accomplishes the following:

• Protects cloud data from various attacks such as on/off attacks, collusion attacks, and sybil attacks.
• Upholds the utmost privacy of the cloud consumers’ data, as their use of the cloud services may involve highly sensitive data.
• Offers comprehensive solutions to make consumers’ trust values very precise by applying the interaction importance criterion.
• Assures trust management service availability owing to cloud services’ dynamic nature.
• Applies several criteria to ensure accurate assessment and data protection.

1.5. Organization

The rest of this paper is organized as follows. In Section 2, we review related works. In Section 3, we present the design and methodology as a solution to protect cloud storage from any attack. In Section 4, we present the design of our approach. In Section 5, we present the simulation results for our system. Finally, the conclusion of this work is presented in Section 6.

2. Related Works

By utilizing a cryptographic RBAC model with a trust model in cloud systems, the owner of the data can provide specific consumers with permission to access the data, where only the consumer who is allowed to access the role can decode the information (Zhou, Vijay, and Hitchens, [5]). The consumer should have a high trust value in various roles to allow the service provider to decide the trustworthiness of a consumer role in the trust model and give permission for future data access, enabling the owners of the data to utilize the trust evaluations to decide whether the data should be stored in the cloud for a specific consumer role. Another concept employed in that study is that the proposed trust models consider the roles of hierarchy and legacy in the evaluation of the trustworthiness of the consumer’s role. The authors proposed the RBAC model integrated with the trust model, and show two probable models for trust in cloud storage, Role–User and Owner–Role RBACs, to enhance data security in cloud computing. In these two models, service providers (SPs) can evaluate the trust value of roles, and the roles evaluate the trust in the user. In any case, there are some security challenges with these two models: they are defenseless against collusion attacks and on/off attacks. To improve the quality and proficiency of cloud-based frameworks, the authors of another study advanced “Trust RBAC,” a new trust-based RBAC prototype [31]. As opposed to [5], the authors proposed a trust model that can protect the cloud system from an on/off attack, but which is still vulnerable to some security threats such as collusion attacks. In 2009, Hasan et al. [34] proposed a new solution to remove the element of subjectivity from trust recommendations. In 2011, Tan et al. [12] put forward an innovative trust model based on the RBAC model to secure cloud-based storage, but careful evaluation of their system shows that it is unable to satisfy pertinent security problems. In 2012, Barsoum and Hasan [13] introduced a storage model for the cloud environment with several features. A crucial highlight of their trust model is the ability to empower common trust for both proprietors and cloud service providers. In 2013, Noor et al. [35] built a new system to detect collusion attacks and sybil attacks in cloud computing systems. In 2018, Mahdi et al. [32] proposed a trust model based on RBAC that provides different criteria but that is still defenseless against sybil attacks.

In a 2020 study [36], the authors proposed a QoS-based model for trust evaluation of cloud service providers by calculating accumulative trust value. However, the authors did not focus on how to avoid all reputation attacks. In another study in 2021 [37] the author proposes a new trust model integrated with the access control model based on privacy and permission, which aims to protect user privacy and solve the privacy disclosure problem in cloud environment, but which is still defenseless against some attacks.

3. Design and Methodology

This section examines the trust- and reputation-based model’s ability to meet the requirements of an exact trust model system to defeat the previously mentioned security problems. We will propose strategies that must be taken into consideration when designing a trust evaluation process. We will seek to determine the best possible answer to the problem of trust in T-RBAC. In the investigation, it was determined that the proposed trust models provide hierarchy and inheritance in the assessment of trustworthiness, which is the basis of our plan for the proposed trust-based distributed storage framework. The plan permits trust prototypes to be coordinated into a framework that utilizes a cryptographic T-RBAC approach. There are two kinds of trust: interaction trust $\left(IT\right)$, which we could also call consumer trust, which refers to a service provider’s trust in consumers’ use of their service, and recommendation trust $\left(RT\right)$, which refers to the service provider’s trust in other service providers’ recommendations.

3.1. Interaction Trust

Interaction trust $\left(IT\right)$ represents the point of view of the service providers toward consumers depending on their own interaction experiences.

3.1.1. Interaction Importance

To make the interaction value very accurate, SPs’ interactions are distinguished based on their sensitivity and importance. Interaction importance $\left(II\right)$ is the most required element in the procedure of evaluating trust. Our trust evaluation model has a favorable interaction importance structure since it enables a service provider to give a recommendation to other service providers based on the trust value information of their consumers as a percentage [32]. To calculate interaction trust $\left(IT\right)$, most researchers have utilized likely prototype models. Among those that utilize aggregate negative and positive feedback to evaluate interaction trust $\left(IT\right)$, such as [38,39], the beta distribution function stands out. It includes α and β in evaluating trust interactions. All of the existing prototypes that utilize a beta distribution function to calculate the value of the consumer trust increment α by 1 if there is any positive feedback and β by 1 if there is any negative feedback. However, this methodology is not precise, as it does not account for the importance of interactions. Accordingly, to address these cases, we will propose a novel methodology that calculates $IT$ based on precise feedback by taking interaction importance into consideration. In our proposed TMS, feedback (F) regarding an interaction is expressed as a number. In other words, as an ordered feedback set from 1 to n, 1 represents “untrusted” and $n$ represents “highly trusted.” In other words, a feedback set contains $n$ satisfaction levels that a service provider decides for any interaction feedback. The $n$ rate is a whole number controlled by the administrator of the system depending on the complexity of the trust value. This approach registers $IT$ as well as incorporating an SP’s interaction importance $\left(II\right)$ in the process of trust evaluation. The posited $IT$ model is given as follows.

$$IT\left(CR\right)={\displaystyle \sum }_{i=1}^{n-1}\frac{{\alpha }_i^t\left(CR\right)+P_{CR}}{\left({\alpha }_i^t\left(CR\right)+P_{CR}\right)+\left({\beta }_i^t\left(CR\right)+N_{CR}\right)}$$

(1)

$${\displaystyle \sum }_{i=1}^n{\alpha }_i^t\left(CR\right)=\begin{array}{c}\\ {CR}_1\\ {CR}_2\\ \begin{array}{c}⋮\\ {CR}_n\end{array}\end{array}\begin{array}{c}\begin{array}{ccc}{\alpha }_1^t& {\alpha }_2^t& \begin{array}{cc}\cdots & \begin{array}{cc}{\alpha }_{n-1}^t& {\alpha }_n^t\end{array}\end{array}\end{array}\\ \left(\begin{array}{cc}{V}_{1,1}& V_{1,2}\\ V_{2,1}& V_{2,2}\\ \begin{array}{c}⋮\\ V_{n,1}\end{array}& \begin{array}{c}⋮\\ V_{n,2}\end{array}\end{array}\begin{array}{cc}\cdots & V_{1,n-1}\\ \cdots & V_{2,n-1}\\ \begin{array}{c}\ddots \\ \cdots \end{array}& \begin{array}{c}⋮\\ V_{n,n-1}\end{array}\end{array}\begin{array}{c}{V}_{1,n}\\ V_{2,n}\\ \begin{array}{c}⋮\\ V_{n,n}\end{array}\end{array}\right)\end{array}$$

$${\displaystyle \sum }_{i=1}^n{\beta }_i^t\left(CR\right)=\begin{array}{c}\\ {CR}_1\\ {CR}_2\\ \begin{array}{c}⋮\\ {CR}_n\end{array}\end{array}\begin{array}{c}\begin{array}{ccc}{\beta }_1^t& {\beta }_2^t& \begin{array}{cc}\cdots & \begin{array}{cc}{\beta }_{n-1}^t& {\beta }_n^t\end{array}\end{array}\end{array}\\ \left(\begin{array}{cc}{V}_{1,1}& V_{1,2}\\ V_{2,1}& V_{2,2}\\ \begin{array}{c}⋮\\ V_{n,1}\end{array}& \begin{array}{c}⋮\\ V_{n,2}\end{array}\end{array}\begin{array}{cc}\cdots & V_{1,n-1}\\ \cdots & V_{2,n-1}\\ \begin{array}{c}\ddots \\ \cdots \end{array}& \begin{array}{c}⋮\\ V_{n,n-1}\end{array}\end{array}\begin{array}{c}{V}_{1,n}\\ V_{2,n}\\ \begin{array}{c}⋮\\ V_{n,n}\end{array}\end{array}\right)\end{array}$$

$$P_{CR}=\frac{{\alpha }_n^t\left(CR\right)\times II}{NF}$$

$$N_{CR}=\frac{{\beta }_n^t\left(CR\right)\times II}{NF}$$

where t represents time, ${\alpha }^t$ represents positive feedback given for a specific consumer role $\left(CR\right)$, ${\beta }^t$ represents negative feedback given for a specific consumer role $\left(CR\right)$, $P$ represents the value of new positive feedback, $N$ represents the value of new negative feedback, $II$ represents the value of interaction importance, and $NF$ represents the number of feedback inputs.

3.1.2. On/off Attack

In many cases, malicious consumers can increase their trust value if they act well in unimportant interactions, after which they can use this trust value to act maliciously in important interactions. This is known as an on/off attack. To avoid the dangers of on/off attacks $\left(O^2\right)$, we need an on/off attack penalty $(P^{O^2})$, where $P^{O^2}$ is set from 1 to n, such that 1 represents no danger from this role and n represents high danger. We need to apply a new procedure to allow the trust model to calculate $P^{O^2}$ for any specific consumer, where $P{C}^{O^2}$ is > 0.5, which represents the curve of a minimum of high interactions.

$$\{\begin{array}{cc}if II\ge P{C}^{O^2} and {\alpha }_n^t<II\hfill & \hfill then P^{O^2}=II\times 2\\ else\hfill & \hfill P^{O^2}=1\end{array}$$

$$IT\left(CR\right)={\displaystyle \sum }_{i=1}^{n-1}\frac{{\alpha }_i^t\left(CR\right)+P_{CR}}{\left({\alpha }_i^t\left(CR\right)+P_{CR}\right)+\left({\beta }_i^t\left(CR\right)+N_{CR}\times P^{O^2}\right)}$$

(2)

3.1.3. Trust Decline

In some cases, the functionality of the system depends on the trust in users in one another. Therefore, if a system flaw in the trust management system drives its users to doubt one another, all system functions will break down. A gradual decline in trust can happen if data incidents caused by the malignant actions of different users are leaked, in which case doubt is cast on every user in the system. In this way, vindictive users can incapacitate the entire trust model. To defeat this problem, rather than placing all clients in doubt, we need a way to diminish malignant users’ influence immediately. To alleviate the dangers of trust decline $\left(TD\right)$ we need a penalty of trust decline $(P^{TD})$, where $P^{TD}$ is set from 1 to $n$, to such that 1 represents no danger from this role and n represents high danger, $P{C}^{TD}$ represents the curve of a penalty of trust decline and $L^{II}$ is an integer greater than one, represents the limit of low interaction.

$$IT\left(CR\right)={\displaystyle \sum }_{i=1}^{n-1}\frac{{\alpha }_i^t\left(CR\right)+P_{CR}}{\left({\alpha }_i^t\left(CR\right)+P_{CR}\right)+\left({\beta }_i^t\left(CR\right)+N_{CR}\times P^{O^2}\times P^{TD}\right)}$$

(3)

$$\{\begin{array}{cc}if {\alpha }_n^t<II\hfill & \hfill then P^{TD}=P{C}^{TD}\\ else\hfill & \hfill P^{TD}=1\end{array}$$

$$P{C}^{TD}={{\displaystyle \sum }}_{P^{TD}>L^{II}}{P}^{TD}$$

3.1.4. Task Trust

The owners of the resources can give permissions for consumers’ roles and tasks, and if there is a leak of data that can stop the role or task, each task represents one operation in any cloud computing service. In order to have a more flexible system that is not interrupted, the system identifies the tasks in which data leaks have occurred and then messages the owners to prevent the users of a role from accessing these tasks. Therefore, if a user of a role has caused a data leak involving one task, then the trust model will send feedback to the other owners to stop this task from accessing the resources. The trust in the task can be calculated as Equation (4).

$$IT\left(T\right)={\displaystyle \sum }_{i=1}^{n-1}\frac{{\alpha }_i^t\left(T\right)\times P_T}{\left({\alpha }_i^t\left(T\right)+P_T\right)+\left({\beta }_i^t\left(T\right)+N_T\right)}$$

(4)

$${\displaystyle \sum }_{i=1}^n{\alpha }_i^t\left(T\right)=\begin{array}{c}\\ T_1\\ T_2\\ \begin{array}{c}⋮\\ T_n\end{array}\end{array}\begin{array}{c}\begin{array}{ccc}{\alpha }_1^t& {\alpha }_2^t& \begin{array}{cc}\cdots & \begin{array}{cc}{\alpha }_{n-1}^t& {\alpha }_n^t\end{array}\end{array}\end{array}\\ \left(\begin{array}{cc}{V}_{1,1}& V_{1,2}\\ V_{2,1}& V_{2,2}\\ \begin{array}{c}⋮\\ V_{n,1}\end{array}& \begin{array}{c}⋮\\ V_{n,2}\end{array}\end{array}\begin{array}{cc}\cdots & V_{1,n-1}\\ \cdots & V_{2,n-1}\\ \begin{array}{c}\ddots \\ \cdots \end{array}& \begin{array}{c}⋮\\ V_{n,n-1}\end{array}\end{array}\begin{array}{c}{V}_{1,n}\\ V_{2,n}\\ \begin{array}{c}⋮\\ V_{n,n}\end{array}\end{array}\right)\end{array}$$

$${\displaystyle \sum }_{i=1}^n{\beta }_i^t\left(T\right)=\begin{array}{c}\\ T_1\\ T_2\\ \begin{array}{c}⋮\\ T_n\end{array}\end{array}\begin{array}{c}\begin{array}{ccc}{\beta }_1^t& {\beta }_2^t& \begin{array}{cc}\cdots & \begin{array}{cc}{\beta }_{n-1}^t& {\beta }_n^t\end{array}\end{array}\end{array}\\ \left(\begin{array}{cc}{V}_{1,1}& V_{1,2}\\ V_{2,1}& V_{2,2}\\ \begin{array}{c}⋮\\ V_{n,1}\end{array}& \begin{array}{c}⋮\\ V_{n,2}\end{array}\end{array}\begin{array}{cc}\cdots & V_{1,n-1}\\ \cdots & V_{2,n-1}\\ \begin{array}{c}\ddots \\ \cdots \end{array}& \begin{array}{c}⋮\\ V_{n,n-1}\end{array}\end{array}\begin{array}{c}{V}_{1,n}\\ V_{2,n}\\ \begin{array}{c}⋮\\ V_{n,n}\end{array}\end{array}\right)\end{array}$$

$$P_T=\frac{{\alpha }_n^t\left(T\right)\times II}{NF}$$

$$N_T=\frac{{\beta }_n^t\left(T\right)\times II}{NF}$$

where $t$ represents time, ${\alpha }^t$ represents positive feedback given for a specific consumer task $\left(T\right)$, ${\beta }^t$ represents negative feedback given for a specific consumer task $\left(T\right)$, P represents the value of new positive feedback, $N$ represents the value of new negative feedback, $\mathrm{II}$ represents the value of interaction importance, and $\mathrm{NF}$ represents the number of feedback inputs.

3.1.5. Inheritance Interaction Trust

Inheritance interaction trust $\left(IIT\right)$ represents credence that arises due to a history of interaction between certain roles that possess inheritance relations with a consumer role. Firstly, we delve into the specific inheritance trust in which only the descendant roles’ interaction history is considered. Once the owner senses a data leak through a subrole of the role, the owner’s feedback needs to be applied to that subrule and also influence R’s trust (since role users equally access the owner’s data allotted to the subrole, and are thus suspicious of triggering a fruitless interaction). Hence, while examining the role’s trust, the interaction history belonging to its subroles is considered.

Assuming that consumer role $CR$ bears $n$ instant descendant roles, we shall have $\left\{C{R}_1,C{R}_2,\dots ,C{R}_m\right\}$, and if there are different consumer tasks $T$ assigned to this role, we shall have $\left\{T_1,T_2,\dots ,T_n\right\}$. The trust value can be elucidated as $IIT\left(CR\right)$, which represents the inheritance interaction trust value of the role. Further, the aggregate count of the roles inherited from the consumer role $\left(CR\right)$ can be elucidated as $NCSR$ and the tasks inherited from the consumer role $\left(CR\right)$ can be elucidated as $NT$. $I{S}^{CSR}$ represents the percentage impact size of the subroles on the trust value, $I{S}^T$ represents the percentage impact size of the consumer tasks on the trust value, and $I{S}^{CR}$ represents the percentage impact size of the roles on the trust value, with all impact size factors determined by the cloud administrator. Then, the inheritance trust estimate arising out of tasks of roles can be calculated as Equation (5).

$$IIT\left(CR\right)=IR\times I{S}^{CSR}+\frac{{{\displaystyle \sum }}_{i=1}^{n}IT\left(T\right)}{NT}\times I{S}^T+IT\left(CR\right)\times I{S}^{CR}$$

(5)

If the role inherits one or more subroles, then $IR$ will be the average of the trust values of all subroles, but if there is no subrole for this role, the $IR$ will be equal to the trust value of the consumer role.

$$\{\begin{array}{cc}if NCSR\ge 1\hfill & \hfill then IR=\frac{{{\displaystyle \sum }}_{i=1}^{n}IT\left(CS{R}_i\right)}{NCSR}\\ else\hfill & \hfill IR=IT\left(CR\right)\end{array}$$

We can examine the example of the role hierarchy detailed in Figure 5. The example should exhibit how the role hierarchy impacts the roles’ trust values.

As shown in Figure 5, $CR1$ inherits from both $CR2$ and $CR3$ and $T1$ and $T2$ are assigned to $CR1$. For simplification, let us assume that values of $IT\left(CR1\right)=80\%$, $IT\left(CR2\right)=80\%$, and $IT\left(CR3\right)=60\%$; $IT\left(T1\right)=20\%$ and $IT\left(T2\right)=60\%$; and the impact size factors are $\left(I{S}^{CSR}=0.1,I{S}^T=0.2,I{S}^{CR}=0.7\right)$. This yields:

$$IIT\left(CR1\right)=\frac{0.8+0.6}{2}\times 0.1+\frac{0.6+0.2}{2}\times 0.2+0.8\times 0.7=77\%$$

where in calculating the trust value of $CR4$, it does not inherit from any subrole. Let us further assume values of $IT\left(CR4\right)=90\%$, $IT\left(T2\right)=60\%$, and $IT\left(T5\right)=80\%$. This yields:

$$IIT\left(CR4\right)=0.9\times 0.1+\frac{0.6+0.8}{2}\times 0.2+0.9\times 0.7=86\%$$

3.1.6. Nonsymmetry

For each interaction, there is unilateral trust; for instance, if node A trusts node B, this does not necessarily mean that node B trusts node A. The owner obtains the role interaction’s history $H\left(CR\right)$ and the history of the task interaction $H\left(C{T}_R\right)$ from the central repository where the history of the interaction is derived from the owner feedback of a role or task. The individual trust value or the interaction history of the role R or task T is computed as:

$$\begin{array}{c}{H}_F\left(CR\right)=\left(H_1^{CR},H_2^{CR},\dots ,H_n^{CR}\right)\\ H_F\left(T_R\right)=\left(H_1^{T_R},H_2^{T_R},\dots ,H_n^{T_R}\right)\\ H_i^{CR}=\left(I{D}_i,T\left(V\right)\right)\end{array}$$

The algorithm of interaction trust (IT) is calculated as follows (Algorithm 1):

Algorithm 1: Interaction Trust Algorithm
	$\hspace{1em}\mathit{Input}: F,II;$
	$\hspace{1em}\mathit{Onput}: Consumer Trust Value;$
1:	$\hspace{1em}\mathit{procedure} Interaction Trust$
2:	$\hspace{1em}{\alpha }_n^t\left(CR\right)=F$
3:	$\hspace{1em}{\beta }_n^t\left(CR\right)=F-1$
4:	$\hspace{1em}{P}_{CR} \leftarrow \left({\alpha }_n^t\left(CR\right)\times II\right)/NF$
5:	$\hspace{1em}{N}_{CR}\leftarrow \left({\beta }_n^t\left(CR\right)\times II\right)/NF$
6:	$\hspace{1em} \mathit{if} II\ge P{C}^{O^2}\mathit{and} {\alpha }_n^t<II \mathit{then} P^{O^2}=II\times DR$
7:	$\hspace{1em} \mathit{else} P^{O^2}=1$
8:	$\hspace{1em} \mathit{end} \mathit{if}$
9:	$\hspace{1em} \mathit{if} {\alpha }_n^t<II \mathit{then} P^{TD}=P{C}^{TD}$
10:	$\hspace{1em} \mathit{else} P^{TD}=1$
11:	$\hspace{1em} \mathit{end} \mathit{if}$
12:	$\hspace{1em} \mathit{for} i=1, i\le n - 1$
13:	$\hspace{1em} IT\left(CR\right)\leftarrow \left({\alpha }_i^t\left(CR\right)+P_{CR}\right)/\left(\left({\alpha }_i^t\left(CR\right)+P_{CR}\right)+\left({\beta }_i^t\left(CR\right)+N_{CR}\times P^{O^2}\right)\right)$
14:	$\hspace{1em} \mathit{end} \mathit{for}$
15:	$\hspace{1em}\mathit{end} \mathit{procedure}$
16:	$\hspace{1em}\mathit{procedure} Task Trust$
17:	$\hspace{1em}{\alpha }_n^t\left(T\right)=F$
18:	$\hspace{1em}{\beta }_n^t\left(T\right)=F-1$
19:	$\hspace{1em}{P}_T \leftarrow \left({\alpha }_n^t\left(T\right)\times II\right)/NF$
20:	$\hspace{1em}{N}_T\leftarrow \left({\beta }_n^t\left(T\right)\times II\right)/NF$
21:	$\hspace{1em} \mathit{for} i=1, i\le n - 1$
22:	$\hspace{1em} IT\left(T\right)\leftarrow \left({\alpha }_i^t\left(T\right)+P_T\right)/\left(\left({\alpha }_i^t\left(T\right)+P_T\right)+\left({\beta }_i^t\left(CR\right)+N_T\right)\right)$
23:	$\hspace{1em} \mathit{end} \mathit{for}$
24:	$\hspace{1em}\mathit{end} \mathit{procedure}$
25:	$\hspace{1em}\mathit{procedure} Inheritance Interaction Trust$
26:	$\hspace{1em} \mathit{for} i=1 \mathit{to} n$
27:	$\hspace{1em} \mathit{if}NCSR\ge 1thenIR=IT\left(CS{R}_i\right)/NCSR$
28:	$\hspace{1em} \mathit{else} IR=IT\left(CR\right)$
29:	$\hspace{1em} \mathit{end} \mathit{if}$
30:	$\hspace{1em} \mathit{end} \mathit{for}$
31:	$\hspace{1em} \mathit{for} i=1 \mathit{to} n$
32:	$\hspace{1em} IIT\left(CR\right)\leftarrow \left(IR\times I{S}^{CSR}\right)+\left(IT\left(T\right)/NT\times I{S}^T\right)+\left(IT\left(CR\right)\times I{S}^{CR}\right)$
33:	$\hspace{1em} \mathit{end} \mathit{for}$
34:	$\hspace{1em}\mathit{end} \mathit{procedure}$

3.2. Recommendation Trust

If there is insufficient proof or information to calculate interaction trust about specific consumer, a service provider needs to evaluate recommendation trust $\left(RT\right)$. $RT$ refers to a service provider’s trust in a consumer by accepting the recommendations of other service providers that have already interacted with that consumer. Recommender importance, subjectivity, collusion attack, and sybil attack are problems that ought to be considered in a recommendation trust evaluation. To deal with these, some critical issues should be connected in the recommendation trust evaluation.

3.2.1. Collusion Attack

TMSs can also be compromised via collusion attacks. Collusion implies a group of users cooperating to decrease or increase the trust value of any consumer in the system [32,40]. In other words, a collusion attack happens when a group of users collaborate with one another to destroy another person’s reputation or raise their own position by giving false recommendations [41]. If more than 50% of users in a trust model system are malicious, such attacks will be ineffective. In any case, however, collusion attacks threaten the accuracy of recommendation trust $\left(RT\right)$. To reduce the danger of this attack, Mahdi et al. [32] proposed a solution that includes the minimum number of recommenders that should contribute to the computation of recommendation trust. An RBAC system will readily adjoin virtual recommenders to the compilation process of the recommendation trust, but there remains the danger of coming under attack.

There are two kinds of collusion attacks. In a self-promoting attack, a group of users cooperate to increase the trust value of any consumer in the system. In a slandering attack, a group of users cooperate to decrease the trust value of any consumer in the system. In order to avoid this type of attack, we need to calculate three criteria, each with several factors. The first criterion, malicious recommendation detection $\left(MRD\right)$, assesses the probability of a suspicious group being a collusion group. To detect these groups, we need to calculate the time range of feedback given to detect all suspicious feedback, which will be very small for those that set out to attack a suspicious consumer. After that, the trust model will compute the second criterion, which is malicious recommenders’ behavior $\left(MRB\right)$, to measure the similarity of all recommenders’ behavior, which will be high when malicious recommenders attack any consumer. The malicious recommendations detection $\left(MRD\right)$ is calculated as follows.

$$\{\begin{array}{c}\mathit{for}i=1\mathit{to}n-1\\ \{\begin{array}{c}\mathit{if}T{\left(F_n,CR\right)}^{FS}-T{\left(F_i,CR\right)}^{FS}\le TR\mathit{and}V{\left(F_n,CR\right)}^{FS}-V{\left(F_i,CR\right)}^{FS}\le VR\\ \mathit{then}\mathit{move}{\left(F_i,CR\right)}^{FS}\mathit{from}FS\mathit{to}SS\\ \mathit{end}\mathit{if}\end{array}\\ \mathit{end}\mathit{for}\end{array}$$

$$\{\begin{array}{c}\mathit{for}i=1\mathit{to}n\\ \{\begin{array}{c}\mathit{if}T{\left(F_n,CR\right)}^{FS}-T{\left(F_i,CR\right)}^{SS}\le TR\mathit{and}V{\left(F_n,CR\right)}^{FS}-V{\left(F_i,CR\right)}^{SS}\le VR\\ \mathit{then}\mathit{move}{\left(F_n,CR\right)}^{FS}\mathit{from}FS\mathit{to}SS\\ \mathit{end}\mathit{if}\end{array}\\ \mathit{end}\mathit{for}\end{array}$$

$$\mathit{where}\{\begin{array}{c}TR=T{\left(F_n,CR\right)}^{FS}\times TC-T{\left(F_n,CR\right)}^{FS}\\ VR=V{\left(F_n,CR\right)}^{FS}\times VC\pm V{\left(F_n,CR\right)}^{FS}\end{array}$$

(6)

The trust model will compare the time of the last feedback $T{\left(F_n,CR\right)}^{FS}$ given to a specific consumer in a feedback set (FS) with the times of all $T{\left(F_i,CR\right)}^{FS}$ except the last feedback, and the value of that the last feedback $V{\left(F_n,CR\right)}^{FS}$ given to a specific consumer in a feedback set $\left(FS\right)$ with the value of all $V{\left(F_i,CR\right)}^{FS}$ except the last feedback. Then, the trust model will compare between the time of the last feedback $T{\left(F_n,CR\right)}^{FS}$ given to a specific consumer in a feedback set $\left(FS\right)$ and the times of all $T{\left(F_i,CR\right)}^{SS}$ for a specific consumer in a suspected set $\left(SS\right)$, and between the value of the last feedback $V{\left(F_n,CR\right)}^{FS}$ that is given to a specific consumer in feedback set $\left(FS\right)$ and the value of all $V{\left(F_i,CR\right)}^{SS}$ for a specific consumer in $SS$. In this way, if any two feedback items in $FS$ have the same time and value ranges, the trust model will move these feedback items to the suspected set $\left(SS\right)$. $VC$ and $TC$ are two parameters to determine the time and value ranges of feedback.

The third criterion is collusion attack frequency $\left(CAF\right)$, which detects malicious recommendations for each recommender with feedback in the suspected set $SS=\left\{S{F}_1,S{F}_2,\dots ,S{F}_n\right\}$, where the strength of the attacks is measured in terms of frequency of attack. Thus, we have Equation (7):

$$CAF\left(S{R}_i,CR\right)=\frac{FN\left(S{R}_i,CR\right)}{FN\left(SS,CR\right)}$$

(7)

$$\{\begin{array}{cc}if CAF\left(S{R}_i,CR\right)\ge FL\hfill & \hfill \mathit{then} \mathit{move} SF\left(SR,CR\right)to CS\\ \mathit{else}\hfill & \hfill \mathit{move} SF\left(SR,CR\right)to FS\\ \mathit{end}\mathit{if}\hfill & \end{array}$$

where $CAF\left(S{R}_i,CR\right)$ is equal to the number of feedback items given from a specific recommender to a specific consumer in the suspected set $\left(SS\right)$ divided by number of all feedback items that are given to the same consumer in the suspected set $\left(SS\right)$. If $CAF\left(S{R}_i,CR\right)$ is greater than or equal to the feedback limit $\left(FL\right)$, then the trust model will move the suspected feedback $SF\left(SR,CR\right)$ to the collusion set $\left(CS\right)$, or else the trust model will move this feedback to the feedback set $\left(FS\right)$. Based on these three criteria, the trust model can either detect or ignore potential collusion feedback. The algorithm of collusion attack is calculated as follows (Algorithm 2):

Algorithm 2: Collusion Attack Algorithm
	$\hspace{1em}\mathit{Input}: FS;$
	$\hspace{1em}\mathit{Output}: SS,CS;$
1:	$\hspace{1em}\mathit{procedure} collusion attack$
2:	$\hspace{1em}TR=T{\left(F_n,CR\right)}^{FS}\times TC-T{\left(F_n,CR\right)}^{FS}$
3:	$\hspace{1em}VR=V{\left(F_n,CR\right)}^{FS}\times VC\pm V{\left(F_n,CR\right)}^{FS}$
4:	$\hspace{1em} \mathit{for} i=1 \mathit{to} n-1$
5:	$\hspace{1em} \mathit{if} T{\left(F_n,CR\right)}^{FS}-T{\left(F_i,CR\right)}^{FS}\le TR \mathit{and} V{\left(F_n,CR\right)}^{FS}-V{\left(F_i,CR\right)}^{FS}\le VR$ $$\mathit{then} \mathit{move} {\left(F_i,CR\right)}^{FS} \mathit{from} FS \mathit{to} SS$$
6:	$\hspace{1em} \mathit{endif}$
7:	$\hspace{1em} \mathit{endfor}$
8:	$\hspace{1em}\mathit{for} i=1 \mathit{to} n$
9:	$\hspace{1em} \mathit{if} T{\left(F_n,CR\right)}^{FS}-T{\left(F_i,CR\right)}^{SS}\le TR \mathit{and} V{\left(F_n,CR\right)}^{FS}-V{\left(F_i,CR\right)}^{SS}\le VR$ $$\mathit{then} \mathit{move} {\left(F_n,CR\right)}^{FS} \mathit{from} FS \mathit{to} SS$$
10:	$\hspace{1em} \mathit{endif}$
11:	$\hspace{1em} \mathit{endfor}$
12:	$\hspace{1em} \mathit{for} i=1 \mathit{to} n$
13:	$\hspace{1em} CAF\left(S{R}_i,CR\right)\leftarrow FN\left(S{R}_i,CR\right)/FN\left(SS,CR\right)$
14:	$\hspace{1em} \mathit{if} CAF\left(S{R}_i,CR\right)\ge FL \mathit{then} \mathit{move} SF\left(S{R}_i,CR\right) \mathit{to} CS$
15:	$\hspace{1em} \mathit{else}$
16:	$\hspace{1em} \mathit{move} SF\left(S{R}_i,CR\right) \mathit{to} FS$
17:	$\hspace{1em} \mathit{endif}$
18:	$\hspace{1em} \mathit{endfor}$
24:	$\hspace{1em}\mathit{end} \mathit{procedure}$

3.2.2. Sybil Attack

A sybil attack is a strategic attack done by a user creating more than one account in the trust management system. The attacker utilizes these fake accounts to decrease or increase the trust value of any user in the system [35]. In the case of malicious activities, a satisfactory solution for this attack is by applying multi-identity detection $(M_{id})$ and sybil attack detection.

To avoid this attack, we can compare the attributes of users’ credentials values in the Trust Identity Registry. $R$ represents the identity records as a list of all users’ primary identities $UP=\left\{P{I}_1,P{I}_2,\dots ,P{I}_m\right\}$ and users’ credentials $UC=\left\{C{A}_1,C{A}_2,\dots ,C{A}_n\right\}$, where the matrix $UP\times UC$ represents the users’ credentials matrix $UM$, which contains all user credentials CA registered in the trust model. The trust model will classify patterns in users’ anonymous credentials.

To calculate the value of multi-identity detection $(M_{id})$, we need to divide the appearance times (Q) of each credential attribute value (CA) by the number of identity records (R_id), where the frequency of any credential attribute value $\left(CA\right)$ is represented as similar credentials attribute value spread into different identity records. $M_{id}$ is calculated as Equation (8).

$$M_{id}={\displaystyle {\displaystyle \sum }_{t=1}^{t=n}}\left({\displaystyle {\displaystyle \sum }_{CA=1}^{CA=n}}\frac{Q\left(C{A}_n\right)}{R_{id}}\right)$$

(8)

We need to apply a new procedure to allow the trust model to ignore fake trust results for a specific consumer role $\left(CR\right)$. $RT\left(first\left(t\right)\right)$ represents the recommendation trust model for a specific consumer at a previous time. $RT\left(last\left(t\right)\right)$ represents the recommendation trust model for the same consumer at the last time the trust results were calculated without considering the proposed method. $RL$ represents the maximum number of records that have same credential attribute. $RT\left(CR,first\left(t\right),last\left(t\right)\right)$ is the factor that represents the change rate of the trust result, calculated as Equation (9).

$$\begin{array}{c}RT\left(CR,first\left(t\right),last\left(t\right)\right)=\\ \{\begin{array}{c}if M_{id}\ge RL then RT\left(first\left(t\right)\right)=RT\left(last\left(t\right)\right)\\ else RT\left(first\left(t\right)\right)=RT\left(last\left(t\right)\right)\end{array}\end{array}$$

(9)

The time factor should be used to detect the sybil attacks $SA$, where any change in the recommender’s behavior in a short small time RB_(t) indicates this attack. $\left|N_{id}\left(t\right)\right|$ represents the number of identities for all recommenders who have evaluated a specific consumer in a short time $\left[first\left(t\right),last\left(t\right)\right]$. We need to measure the periodic and occasional percentage of all changes in the number of identities among the entire behavior of identities (the entire recognized identities for all recommenders that provided feedback to a specific consumer). The $SA$ attacks factor $SA\left[first\left(t\right),last\left(t\right)\right]$ of a specified consumer in a small time is calculated as Equation (10):

$$C\left(t\right)=\lfloor N_{id}\left(F\left(t\right)\right)\times SC\rfloor$$

$${\displaystyle \sum }_{t=1}^{t=n}\left(\begin{array}{c}\begin{array}{c}\mathit{if} N_{id}\left(L\left(t\right)\right)>N_{id}\left(F\left(t\right)\right)+C\left(t\right) \mathit{then} \\ SA\left(F\left(t\right),L\left(t\right)\right)=\frac{N_{id}\left(L\left(t\right)\right)-N_{id}\left(F\left(t\right)\right)+C\left(t\right)}{\left|N_{id}\left(F\left(t\right)\right)\right|}\end{array}\\ \mathit{else} \mathit{do} \mathit{nothing} \end{array}\right)$$

(10)

where $C\left(t\right)$ represents the identities curve in a specific time, and the sybil attack curve is represented as SC, which means the allowable percentage of new identities between two specified times $N_{id}\left(F\left(t\right)\right)$ and $N_{id}\left(L\left(t\right)\right)$. The algorithm of the sybil attack is calculated as follows (Algorithm 3):

Algorithm 3: Sybil Attacks Algorithm
	$\hspace{1em}\mathit{Input}: RL,W^{EX},W^L ;$
	$\hspace{1em}\mathit{Output}: RT;$
1:	$\hspace{1em}\mathit{procedure} Sybl Sttack$
2:	$\hspace{1em}\mathit{for} t=1 to n$
3:	$\hspace{1em} \mathit{for} CA=1 to n$
4:	$\hspace{1em} M_{id}\leftarrow Q\left(C{A}_n\right)/R_{id}$
5:	$\hspace{1em} \mathit{if} M_{id}\ge RL \mathit{then} RT\left(F\left(t\right)\right)=RT\left(F\left(t\right)\right)$
6:	$\hspace{1em} \mathit{else}$
7:	$\hspace{1em} RT\left(F\left(t\right)\right)=RT\left(L\left(t\right)\right)$
8:	$\hspace{1em} \mathit{end}\mathit{if}$
9:	$\hspace{1em} \mathit{end}\mathit{for}$
10:	$\hspace{1em} \mathit{end}\mathit{for}$
11:	$\hspace{1em}C\left(t\right)= \lfloor N_{id}\left(F\left(t\right)\right)\times SC\rfloor$
12:	$\hspace{1em}\mathit{for} t=1 to n$
13:	$\hspace{1em} \mathit{if} N_{id}\left(L\left(t\right)\right)>N_{id}\left(F\left(t\right)\right)+C\left(t\right)$ $$\mathit{then} SA\left(F\left(t\right),L\left(t\right)\right)=\left(N_{id}\left(L\left(t\right)\right)-N_{id}\left(F\left(t\right)\right)+C\left(t\right)\right)/\left|N_{id}\left(F\left(t\right)\right)\right|$$
14:	$\hspace{1em} \mathit{end}\mathit{if}$
15:	$\hspace{1em} \mathit{end}\mathit{for}$
16:	$\hspace{1em}\mathit{end} \mathit{procedure}$

3.2.3. Recommender Importance

Finally, we have a recommender importance, which recognizes the particular importance of some service providers in their fields of interaction and their trustworthiness as recommenders. This gives different weights to recommendations. Although most people care more about their own opinions, data owners might trust the recommendations of more experienced recommenders than themselves. Therefore, we need to add a weight function (W^EX) multiplied by a number of exchange transactions (EX_i) that a recommender has had with a specific consumer, and which is dependent on the experience of recommender interactions $W\left(R_i,CR\right)$. There are an additional two factors that should be utilized. The time factor $\left(t\right)$ is a variable used in applying the impact of the elapsed time. $last\left(t\right)$ represents the last time that the recommender transacted with the intended consumer multiplied by a weight function $\left(W^L\right)$. $RT\left(CR\right)$ represents the trust value of a specific consumer role, where $F\left(R_i,CR\right)$ is the feedback values that are provided from trust recommenders. The value of recommendation trust is calculated as Equation (11).

$$W\left(R_i,CR\right)={\displaystyle \sum }_{i=1}^n\frac{\left(E{X}_i\times W^{EX}+L_i\left(𝓉\right)\times W^L\right)}{100}$$

$$\mathit{where}{W}^{EX}+W^L=100$$

$$\{\begin{array}{c}\mathit{if} W\left(R_i,CR\right)\ge II \mathit{then} RT\left(CR,F\left(t\right),L\left(t\right)\right)=\frac{{{\displaystyle \sum }}_1^{n}F\left(R_i,CR\right)}{N^R}\\ \mathit{else} \mathit{donothing}\end{array}$$

(11)

3.2.4. Subjectivity

In some cases, we have more than one value of trust in the same consumer. When recommenders have different opinions and experiences, a “subjectivity” problem is often encountered in a trust management system. This refers to inaccurate user ratings, reviews, opinions, and subjective inputs to the designed trust criteria. Certain parts of TMSs are dependent on people’s thinking, and those parts are related to users’ behavior through people’s judgments, evaluations, or are influenced by their personal feelings, beliefs, and emotions that are not precise [32,42]. The basis of this trust diversity can simply be interpreted as how much a person deals with trust criteria. This can differ from user to user depending on the users’ understanding, psychological condition, and knowledge of trust. We need to build a dynamic system that can take these criteria into consideration. Trust is a subjective concept that can cause serious problems, as the varying opinions of the users influence the precision of the interaction trust evaluation. Therefore, service providers need to view service providers’ functional trust in specific consumers in accordance with their own perspectives. We need to use some parts of the solutions introduced in [34], which, in evaluating the tendency of other service providers to trust, consider user trust as an estimate rather than a value.

A straightforward execution of the computation seeks to give trust in the form of a percentile. A percentile estimate designates a recommender perception about a specific consumer in conjunction with others that have already been evaluated by the recommender. Accordingly, the $SP$ aims to alter consumer trust as well as create the SP’s interaction-based functional trust about a specific consumer according to its perception. $I_R$ represents a combination of interaction trust evaluation of recommender $\left(R\right)$ to all consumers role $CR$, which it has transacted. As such, $I_R={{\displaystyle \sum }}_1^{n}IT(R,CRs)$ represents the disposition of the recommender (R) to the collection of trust. The estimates accompanying the SP’s interactional trust collection is classified in an ascending sequence:

$$P=\frac{100\times FI}{N_R^{CR}+1}$$

where P is the consumer trust’s percentile in the classified combination of I_R, $FIisfirst\left(IT\left(CR\right),I_R\right),$ which refers to the index of the first trust value in the collection of $I_R$, and $N_R^{CR}$ is the number of all consumers that have transacted with SP’s recommender R.

$$\begin{array}{c}A=\lfloor \frac{P\times \left(N_R^{CR}+1\right)}{100}\rfloor \\ B=\frac{P\times \left(N_R^{CR}+1\right)}{100}-A\end{array}$$

$N_R^{CR}$ is number of all consumers that have transacted with SP’s recommender $\left(R\right)$, the parameter $A$ is an integer, and $B$ is a fraction ≥ 0 and < 1. $S$ represents the interaction trust from service providers to consumers depending on $SP$ behavior. $I_{SP}\left[i\right]$ which represent $i^{th}$ in $I_{SP}$.

$$S{\left(R,CR\right)}^{SP}=I_{SP}\left[i\right]+B\times \left(I_{SP}\left[i+1\right]-I_{SP}\left[i\right]\right)$$

(12)

$$\{\begin{array}{lll}if 0<A<N^{CR}& then& i=A\\ elseif A=0& then& i=1\\ elseif A=N^{CR}& then& i=N^{CR}\end{array}$$

To eliminate the challenge of subjectivity from the posited trust model, $S{\left(R_i,CR\right)}^{SP}$ shall be substituted for the $F\left(R_i,CR\right)$.

$$W\left(R_i,CR\right)={\displaystyle \sum }_{i=1}^n\frac{\left(E{X}_i\times W^{EX}+L_i\left(𝓉\right)\times W^L\right)}{100}$$

$$where W^{EX}+W^L=100$$

$$\{\begin{array}{c}\mathit{if} W\left(R_i,CR\right)\ge II \mathit{then} RT\left(CR,F\left(t\right),L\left(t\right)\right)=\frac{{{\displaystyle \sum }}_1^{n}S{\left(R_i,CR\right)}^{SP}}{N^R}\\ \mathit{else} \mathit{donothing}\end{array}$$

(13)

The algorithm of subjectivity and recommender importance is calculated as follows (Algorithm 4):

Algorithm 4: Subjectivity and Recommender Importance Algorithm
	$\hspace{1em}\mathit{Input}: W^{EX}, W^L;$
	$\hspace{1em}\mathit{Output}: Rt(CR,F(t),L(t\left)\right);$
1:	$\hspace{1em}\mathit{procedure} Subjectivity$
2:	$\hspace{1em}P\leftarrow \left(100\times FI\right)/(N_R^{CR}+1)$
3:	$\hspace{1em}A\leftarrow \lfloor \left(P\times \left(N_R^{CR}+1\right)\right)/100\rfloor$
4:	$\hspace{1em}B\leftarrow \left(P\times \left(N_R^{CR}+1\right)\right)/100-A$
5:	$\hspace{1em}\mathit{if} 0<A<N^{CR} \mathit{then} i=A$
6:	$\hspace{1em} \mathit{elseif} A=0 \mathit{then} i=1$
7:	$\hspace{1em} \mathit{elseif} A=N^{CR} \mathit{then} i=N^{CR}$
8:	$\hspace{1em} S{\left(R,CR\right)}^{SP}\leftarrow I_{SP}\left[i\right]+B\times \left(I_{SP}\left[i+1\right]-I_{SP}\left[i\right]\right)$
9:	$\hspace{1em} \mathit{endelseif}$
10:	$\hspace{1em} \mathit{endelseif}$
11:	$\hspace{1em} \mathit{endif}$
12:	$\hspace{1em}\mathit{end} \mathit{procedure}$
13:	$\hspace{1em}\mathit{procedure} Recommender Importance$
14:	$\hspace{1em}\mathit{for} t=1 \mathit{to} n$
15:	$\hspace{1em} W\left(R_i,CR\right)\leftarrow \left(\left(E{X}_i\times W^{EX}+L_i(-)\times W^L\right)/100\right)$
16:	$\hspace{1em} \mathit{for} t=1 to n$
17:	$\hspace{1em} \mathit{if}W\left(R_i,CR\right)\ge II \mathit{then} RT\left(CR,F\left(t\right),L\left(t\right)\right)=S{\left(R_i,CR\right)}^{SP}/N^R$
18:	$\hspace{1em} \mathit{endif}$
19:	$\hspace{1em} \mathit{endfor}$
20:	$\hspace{1em}\mathit{endfor}$
21:	$\hspace{1em}\mathit{end} \mathit{procedure}$

3.3. The Proposed Joint Trust Model

To calculate the joint trust value for a specific consumer, we must coordinate the proposed inheritance interaction trust model and recommendation trust model by applying the importance of these trust models. Service providers might consider their interaction trust values as more important than the recommendation values of other service providers. In this way, we need to add two parameters $W^{IIT}$ and $W^{RT}$ to manage the importance of interaction trust as well as trusted recommendations associated with the consolidated trust model, where $W^{IIT}$ represents the specific importance of the inheritance interaction trust model and $W^{RT}$ represents the specific importance of the recommendation trust model. The joint trust value for a specific consumer is calculated as Equation (14):

$$\mathit{Trust}\left(\mathit{C}\mathit{R}\right)=\left(IIT\times W^{IIT}\right)+\left(RT\times W^{RT}\right)$$

(14)

4. The Approach

This section illuminates the goals, architecture, and general functionality of the suggested system.

4.1. Objectives

The objectives of this study are to first conduct research and then design, implement, and monitor an access control application to validate the research hypothesis. The following are the main research aims and objectives:

• To offer a comprehensive study on cloud computing, investigate its characteristics, and specify the design requirements for an access control solution that will be tailor-made for those characteristics.
• To design an effective and reliable architecture based on a T-RBAC access control that will improve the security of stored data in cloud storage systems.
• Introduce task-role-based access control (T-RBAC) as a new access control model integrated with a comprehensive trust model by applying a range of criteria to provide high security for cloud storage systems, while taking flexibility into consideration.
• Reduce the number of untrusted consumers with T-RBAC, and thus achieve a safer nonstop work environment.
• Build a flexible architecture based on T-RBAC wherein the owners of the resources in the system can give permission for roles or tasks, and if there is a data leak, the system will stop the task or role.
• Our trust model design involves hierarchy and inheritance in the evaluation of the trustworthiness of roles and tasks.
• The trust model provides solutions for different attacks, such as on/off attacks, collusion attacks, and sybil attacks.
• To provide high security by accounting for a wide range of criteria such as interaction importance, trust decline, task trust, conditional transfer, and subjectivity.

4.2. Proposed Framework Architecture

This section provides an analysis of the different components of the trust model and the role it plays in ensuring that the system works effectively. TMS will be the component of the proposed design that evaluates the extent to which providers of the cloud services are willing to trust the consumers of the cloud services. The trust management system is composed of various subsections entitled with different tasks, all of which are aimed at ensuring the security and the privacy of the data present in the cloud storage systems. Figure 6 illustrates the proposed system architecture.

As identified in the above diagram, the trust model is composed of all the entities in the cryptographic T-RBAC system. The administrator serves as a certificate generator for the system and provides all the necessary access credentials to the consumer. Additionally, it is the role of the administrator to provide the hierarchical structure of the system. Lastly, the administrator comes up with parameters that present the position of a role in the system. The generated hierarchical roles are stored in the cloud and are available to anyone who needs them. The roles define the consumers’ memberships and serve as intermediaries between the tasks and the owners. Each role contains role parameters that define the membership of the user. The tasks are the units that link the roles and the consumers. Each task has a unique task criterion that elucidates the smallest entity based on user membership. The owners consist of the groups that own the data and seek to keep their encrypted data in the cloud for easy access by consumers. They have the responsibility for determining who can access their data using the task/role-based policies. The owner of the data can also be a user, but for an owner–user to access the information stored in the system, they must first request it of the cloud, and then the data is decrypted for them. Consumers or service users are secondary units that require accessing shared services or resources. The suggested trust model comprises five parts. The details of these parts are as follows.

Trust Management System (TMS): The Trust Management System is an additional layer of the trust model aimed at making the whole system work effectively. It is made up of different components, as discussed below.

Central Repository: This can be considered as a store of interactions. It is mainly used to store all interaction histories and trust records generated when roles and the tasks interact, which are later utilized by the Trust Decision Engine to evaluate the trust values of roles and tasks. All elements that are not in TMS are not allowed to access the central repository.

Role Behavior Analyzer: This entity is responsible for analyzing roles and functions concerning minimum trust level regulations upon accessing shared resources. It evaluates rules determined within the trust level according to the feedback from service providers and stores computed trust values in the central repository. This entity is connected to the roles entity to collect information about roles when a report on a data leak is generated. The role behavior analyzer needs to specify the identifying user and track the activities performed. It can easily track attackers or unauthorized consumers and issues proof of any data leakage. It will also update registered and recognized consumers’ accounts and determine if a consumer account has been involved in the incident.

Task Behavior Analyzer: This is responsible for analyzing tasks and functions concerning minimum trust level regulations upon accessing shared resources. It evaluates tasks determined within the trust level according to the feedback from the owners through a computed trust value, and stores this value in the central repository. It listens to channels to collect information, including reports from the tasks regarding the leakage of data and reports from the role behavior analyzer to identify consumers’ histories in regard to the stored data. The task behavior analyzer needs to specify consumers to identify and track the tasks performed. It can easily track attackers or unauthorized consumers and issues proof of any data leakage. It will also update registered and recognized consumers’ accounts and determine if a consumer account has been involved in the incident.

Feedback Collector: This refers to an agent that regulates the feedback from the owners to the central repository, and automatically allocates it. The feedback on roles and tasks, on the other hand, represents the trustworthiness of a consumer. The collected feedback is transmitted to the central repository for future reference. For security reasons, the feedback collector protects the integrity of the feedback on tasks and roles. The role of this component is to ensure that those who upload feedback into the system are authorized to do so. The component has the ability to identify invalid feedback and discard it from the system. Additionally, the role feedback collector collects information about data assignments for roles and tasks, after which the feedback collector updates the central repository on what has been assigned.

Trust Decision Engine: This has an evaluation role in determining the trust value of roles and tasks for the owners of the data, and for the roles and tasks entities. It collects all information about the interaction histories from the central repository as well as the outputs of the trust values of particular consumers and makes a decision for the system to respond with.

4.3. Proposed Method

• The administrator starts the system and specifies the hierarchy of roles and tasks in the system. Channel 1 facilitates the uploading of the system’s generated parameters for the roles and tasks to the cloud.
• When a consumer needs access to data in the cloud, they first send an access request via Channel 2, according to their roles and tasks.
• If the request is accepted, the Roles entity relies on Channel 5 to relay the accepted request to the Tasks entity. Then, the cloud will respond by providing a user with a normal cryptographic T-RBAC plan.
• The owner can only give an encryption and uploading go-ahead via Channel 3 if they believe that the role or task can be trusted. In this process, the owner also makes the feedback collector aware of the identity of the consumers.
• In case an owner identifies leakage of their resources due to an untrusted consumer, they provide feedback about this role or task to the feedback collector via channel 14.
• If the feedback is provided by an authorized owner, the collector will forward this feedback to the central repository via Channel 11 to store each trust record and interaction history generated when the roles and tasks interacted.
• The central repository then stores those interaction histories, which are later utilized by the Trust Decision Engine to evaluate the trust value of the roles and tasks through Channel 10.
• The roles entity can accept trust evaluations about the roles from the trust management system at any time, after which the trust management system responds with the information from the trust decision engine via Channel 13.
• After receiving the information from the trust decision engine, the roles entity updates the role variables that determine a consumer’s role membership in the cloud. The memberships of any malicious consumers are revoked.
• In the event of an owner providing negative feedback about a role because of resource leakage, the roles entity sends the information about the leakage to the role behavior analyzer via Channel 4.
• The tasks entity takes the trust evaluation about the tasks from the trust management system at any time, after which the trust management system responds with the information from the trust decision engine via Channel 12.
• After receving the information from the trust decision engine, the tasks section updates the task parameters that determine the consumer’s task membership. The membership of any malicious consumers are revoked.
• In the event of negative feedback by an owner about a task due to resource leakage, the tasks entity sends information about the leakage to the task behavior analyzer via Channel 7.
• The analyzers then update the trust records of the roles and tasks in the central repository via Channels 6 and 8.
• When an owner needs their data to be uploaded and encrypted in the cloud, they request a trust evaluation, which is the role of the trust management system. When the query is posted to the trust management system, the system responds to the owners via Channel 9.
• The trust decision engine gives the owners the trust evaluation results for the roles and tasks. Depending on those results, the data owners can decide to whether to give consumers permission to access their resources.

4.4. Application Scenario

Real-world sensitive cloud applications are those that regulate access to the personal health records (PHRs) and electronic health records (EHRs) in e-health systems. An example of this is the “MyPHRmachines” system which was developed at the Eindhoven University. This system is an integration of PHR system and cloud technology and makes it possible to share selected health information of patients with a physician. It has been asserted that the physicians or other parties do not have to worry about incorrect storage because shared data is stored for a specified time period.

Using the above observation, we were able to apply our trust-based T-RBAC model for sharing medical data in an e-health application. For instance, consider an application scenario where personal health records are shared by a patient with a hospital department so as to acquire treatment services from the physicians of that department. Here, the patient can be considered as the data owner, the hospital department functions as a role, the health records of patients are considered as tasks, the physician signifies the users, and the head of the hospital is the administrator.

Here, we assume that the T-RBAC system is used by the application to regulate access to personal health data. Hence, when a conventional T-RBAC system is used, the health information of the patient can be exposed by a malicious physician. Revealing this private medical information to the public serves as a serious threat, particularly for prominent individuals. The real identity of the users and owners should be kept confidential as it is an issue of privacy. A pseudonym-based identity could be an appropriate solution to deal with this. However, this paper concentrates on using the trust factor to improve a T-RBAC model in the cloud environment so as to decrease the security risks and deal with issues pertaining to the trust individuals have on one another in this kind of open environment. We will now describe how the trust model put forward can be used in this scenario to decrease the threat of the personal medical records of patients being accessed illegally. We first assume that personal medical data is shared by a patient with a hospital department with the intention of acquiring treatment. The patient first examines the trust level of that particular department by considering their treatment history, if there is any, with this department and also by taking the views of other patients. Hence, the decision to share personal medical data is made by the patient on the basis of the sensitivity of their medical data, condition and the least trust value required so as to trust that hospital department (HD). After this, the HD, depending on its own reputation, hires physicians whose trust level is more than the minimum trust level required by the HD. There may also be multiple immediate successors of every HD, who serve as the hospital subdepartments (HSD) that can receive access to the medical data of the patient. All these physicians and HSDs are considered by the HD as the users. If the trust level of these users is less than the trust requirement of the HD, then their access rights will be immediately withdrawn. In addition, an entity’s trust in an entity will decrease if leaked data is accessed by the entity as determined by its access time. There will be leakage of a patient’s medical data when malicious physicians, HDs or HSDs disclose this data to an unauthorized entity. This example makes it evident that it is possible to effectively use our trust model for safe storage of data on the cloud.

5. Simulation Results

We built a C#.net Windows Forms application to compare our architecture with several related works. Our trust model can find malicious consumers by applying different criteria. In this section, we will highlight the simulation results of the criteria that we have applied to block all security threats and raise the accuracy of the results.

In Figure 7a, we can see the impact of new feedback values in the interaction trust value $IT$ for malicious consumers in red and trusted consumers in blue. As we see in Figure 7a, this impacts the penalties on the results of malicious consumers more than it raises the results of trust for good consumers; the reason behind this is that we need to stop malicious behaviors in the cloud environment. In Figure 7b, the interaction trust value IT is affected by the number of feedback items $NF$ for each trust value. The greater the number of consumer interactions the less impact on trust results there will be, so a trusted consumer must have a lot of trusted interactions to maintain his trust value.

There are two penalties in this system. First, we identified two conditions for identifying on/off attacks: when the interaction importance $II\ge 0.7$ and when SP’s feedback $F$ is less than the interaction importance $II$. With these two conditions, the trust value is calculated with the penalty of an on/off attack $P^{O^2}$. The second penalty is the trust decline penalty P^TD which applies under the condition when the $SP$ feedback is less than the interaction importance $II$. Figure 8 shows the impact of the penalty of on/off attacks and resulting trust decline in the interaction trust values.

Figure 9 shows the impact of new feedback on the interaction trust in trusted consumers, where the system will compute the interaction trust for trusted consumers by applying different criteria to make the result of trust value very accurate.

Figure 10 shows the impact of new feedback on the interaction trust in malicious consumers, where the system will compute the interaction trust for malicious consumers by applying the penalties of on/off attack p^O2 and of the trust decline p^TD.

In Figure 11, in order to compare interaction trust $IT\left(CR\right)$ with inheritance interaction trust $IIT\left(CR\right)$, the trust value of the subroles $IR$ and the trust value of tasks $IT\left(T\right)$ will affect the trust value of the consumer role. After each interaction, the trust model will recalculate the trust value of each role inherited from subroles in the same enterprise.

The trust model will alter consumer trust $IT\left(R_i,CR\right)$ according to $SP$ perception $S{\left(R,CR\right)}^{SP}$. Figure 12 shows the differences between $SP$ feedback $I_{SP}$ and recommender feedback $I_R$ and the impact of these values in $IT\left(R_i,CR\right)$ and $S{\left(R,CR\right)}^{SP}$. With these criteria, our model will remove the subjectivity and offer accurate results.

To detect collusion attacks, the trust model will analyze different criteria that affect the trust value of any consumer. One of these criteria is the collusion attack frequency $\left(CAF\right)$, where the value of the feedback frequency is directly proportional to the collusion feedback and inversely proportional to the credibility of the aggregated feedback. The value of the feedback frequency depends on the number of feedback items that have been provided by any recommender and the number of feedback items in the suspected set $\left(SS\right)$.

Let us assume

Table 1. Collusion attacks frequency.

$FN\left(S{R}_i,CR\right)$	6	21	32	12	36	1	18
$FN\left(SS,CR\right)$	126	126	126	126	126	126	126
$CAF\left(S{R}_i,CR\right)$	0.05	0.17	0.25	0.10	0.29	0.01	0.14

is the frequency of seven suspected recommenders, and the feedback limit $\left(FL\right)=7\%$, The trust model will move the feedback of any suspected recommenders who have a feedback frequency greater than the feedback limit $\left(FL\right)$ to the collusion set $\left(CS\right)$, or else the trust model will move the feedback to the feedback set $\left(FS\right)$. As we see in Figure 13, there are five suspected recommenders who have feedback frequency greater than the feedback limit $\left(FL\right)$.

Finally, in order to calculate the joint trust value for specific CR, as we see in Figure 14, we have to coordinate the proposed Interaction Trust Model and Recommendation Trust Model to give the two values as one trust value $Trust\left(CR\right)$, where this value is affected by two parameters $W^{IIT}and{W}^{RT}$ to manage the importance of interaction trust as well as recommendation trust.

6. Comparison of Security and Accuracy

Every model of trust management service is endangered by some security threats. These threats may either elevate the reputation of a certain unit with malicious intentions or entirely ruin it. In order to build a robust, secure, and accurate trust model system, we focus on all reputation attacks of cloud computing by applying different criteria to avoid these attacks.

Table 2. Comparison of security and accuracy.

Addressed Metrics	[13]	[31]	[32]	[43]	[44]	OURS
Interaction importance	🗴	🗴	🗸	🗴	🗴	🗸
On/off attack	🗸	🗸	🗸	🗴	🗴	🗸
Trust decline	🗴	🗴	🗸	🗸	🗴	🗸
Recommender importance	🗴	🗴	🗸	🗴	🗴	🗸
Collusion attack	🗸	🗴	🗸	🗸	🗸	🗸
Collusion attack frequency	🗴	🗴	🗴	🗴	🗸	🗸
Subjectivity	🗴	🗴	🗴	🗴	🗴	🗸
Sybil attack	🗸	🗴	🗸	🗸	🗴	🗸

shows the comparison between our proposed TMS and those given in related works.

7. Future Work

The issue of cloud service trust has attracted many researchers, but there are still many concerns that must be addressed. In future work, we will introduce additional criteria that increase the security of the trust model. In addition, we will seek other types of reputation attacks that threaten the security of the cloud computing environment and propose solutions to avoid these attacks.

8. Conclusions

In this paper, we have shown how a secure and flexible trust-based cloud storage system can be built wherein the owners of the resources in the system can give permission for roles and tasks, and if there is a data leak, the system will stop the task or role. We proposed a design that can decrease risk by providing high security for cloud storage systems by introducing the T-RBAC as a new model of access control integrated with a comprehensive trust model, which improves the quality of the decisions made by the cloud operators and the data owners. It was determined that trust models should involve inheritance and hierarchy in the trustworthiness evaluation of roles and tasks; this is the basis of our design for the proposed trust model based on cloud storage system. This design allows the trust model to be integrated with a system based on a cryptographic T-RBAC approach to reduce the number of untrusted consumers with T-RBAC, and thus achieve a safer nonstop work environment. Finally, in our trust model we proposed solutions for different attacks, such as on/off attacks, collusion attacks and sybil attacks. Additionally, we applied different criteria in this trust model, such as interaction importance, trust decline, task trust, conditional transfer, and subjectivity, to provide high security.