Towards New Data Access Control Technique Based on Multi Agent System Architecture for Cloud Computing Amir Mohamed Talib, Rodziah Atan, Rusli Abdullah, and Masrah Azrifah Azmi Murad Faculty of Computer Science & IT, Information System Department, University Putra Malaysia, 43400 UPM, Serdang, Selangor, Malaysia
[email protected], (rodziah,rusli,masrah)@fsktm.upm.edu.my
Abstract. With the rise of the era of “cloud computing”, concerns about “Security” continue to increase. Cloud computing environments impose new challenges on access control techniques due to the growing scale and dynamicity of hosts within the cloud infrastructure; we proposed Multi-Agent System (MAS) architecture. This architecture consists of two agents: Cloud Service Provider Agent (CSPA) and Cloud Data Confidentiality Agent (CDConA). CSPA provides a graphical interface to the cloud user that facilitates the access to the services offered by the system. CDConA provides each cloud user by definition and enforcement expressive and flexible access structure as a logic formula over cloud data file attributes. This new access control is named as FormulaBased Cloud Data Access Control (FCDAC). A prototype of our proposed FCDAC will be designed using Prometheus Methodology and implemented using the Java Agent Development Framework Security (JADE-S). Keywords: Cloud Computing, Cloud Data Storage, Cloud Service Provider, Cloud Data Access Control, Multi-Agent System and Confidentiality.
1 Introduction Cloud computing describes applications that are extended to be accessible through the Internet. These cloud applications use large data centers or cloud data storage (CDS) and powerful servers that host Web applications and Web services. Anyone with a suitable Internet connection and a standard browser can access a cloud application. Cloud computing consists of multiple cloud computing service providers (CSPs). In terms of software and hardware, a cloud system is composed of many types of computers, storage devices, communications equipment, and software systems running on such devices. Cloud storage is composed of thousands of storage devices clustered by network, distributed file systems and other storage middleware to provide cloud storage service for cloud users. The typical structure of cloud storage includes storage resource pool, distributed file system, service level agreements (SLAs), and service interfaces, etc. Globally, they can be divided by physical and logical functions boundaries and V. Snasel, J. Platos, and E. El-Qawasmeh (Eds.): ICDIPC 2011, Part II, CCIS 189, pp. 268–279, 2011. © Springer-Verlag Berlin Heidelberg 2011
Towards New Data Access Control Technique
269
relationships to provide more compatibilities and interactions. Cloud storage is tending to combined with cloud security, which will provide more robust security [1]. Cloud Data access control issue is mainly related to security policies provided to the users while accessing the data. In a typical scenario, a small business organization can use a cloud provided by some other provider for carrying out its business processes. This organization will have its own security policies based on which each employee can have access to a particular set of data. The security policies may entitle some considerations wherein some of the employees are not given access to certain amount of data. These security policies must be adhered by the cloud to avoid intrusion of data by unauthorized users [2, 3, 4]. Access control regulates accesses to resources by principals. It is one of the most important aspects of the security of a system. A protection state or policy contains all information needed by a reference monitor to enforce access control. The syntax used to represent a policy is called an access control model. In FCDAC, principals are called cloud users. Cloud users get permissions to access resources via membership in roles. We present a new way to realize FCDAC in JADE-S. Our approach focuses not only of providing a cloud user by a user name and password but by define and enforce expressive and flexible access structure for each cloud user as a logic formula over cloud data file attributes. A multi-agent system (MAS) consists of a number of agents interacting with each other, usually through exchanging messages across a network. The agents in such a system must be able to interact in order to achieve their design objectives, through cooperating, negotiating and coordinating with other agents. The agents may exhibit selfish or benevolent behavior. Selfish agents ask for help from other agents if they are overloaded and never offer help. For example, agents serving VIP (Very Important Person) cloud users for CSP service never help other agents for the same service. Benevolent agents always provide help to other agents because they consider system benefit is the priority. For example, agents serving normal cloud users for CSP service are always ready to help other agents to complete their tasks. The main contribution of this paper is to introduce the first provably-secure and practical FCDAC that provide access structure of each cloud user by defining it as a logic formula over cloud data file attribute. In this paper, in section 2 we present a discussion of the related works. Section 3 provides an overview of our research methodology. Section 4 describes our proposed MAS architecture. In, section 5 presents some concluding remarks.
2 Related Works Many existing works close to our work can be found in the areas of “access control of outsourced data” Kallahalla et al [5] proposed Plutus as a cryptographic file system to secure file storage on untrusted servers, Goh et al [6] proposed SiRiUS which is layered over existing file systems such as NFS but provides end-to-end security, Ateniese et al [7] proposed a secure distributed storage scheme based on proxy reencryption. Specifically, the data owner encrypts blocks of content with symmetric content keys. In [8], Vimercati et al proposed a solution for securing data storage on
270
A. Mohamed Talib et al.
untrusted servers based on key derivation methods [9]. In this proposed scheme, each file is encrypted with a symmetric key and each user is assigned a secret key. KAoS uses DAML as the basis for representing and reasoning about policies within Web Services, Grid Computing, and multi-agent system platforms [10]. KAoS also exploits ontology for representing and reasoning about domains describing organizations of human, agent, and other computational actors [11]. Rei is a deontic logic based policy language that is grounded in a semantic representation of policies in RDF-S [12]. However, developers of KAoS augured that the pure OWL based method has difficulty in definition of some types of policy [11]. An access control system is typically described in three ways: access control policies, access control models and access control mechanisms [13]. Policy defines the high level rules according to which access control must be regulated. Model provides a formal representation of the ACPs. Mechanism defines the low level functions that implement the controls imposed by the policy and formally stated in the model. Access Control Policies can be generally divided into three main policy categories: Discretionary Access Control (DAC), Mandatory Access Control (MAC), and RoleBased Access Control (RBAC). Early DAC models, such as the access control matrix model [14] and the HRU (Harrison–Ruzzo–Ullman) model [15], provide a basic framework for describing DAC policy. In these models, it is the users’ discretion to pass their privileges on to other users, leaving DAC policies vulnerable to Trojan Horse attacks [13]. The lattice-based multilevel security policy [16], policies represented by the Bell–LaPadula model [17].
3 Research Methodology This research shall be carried out in five steps that defined as A Secure System Development Life Cycle (SecSDLC) as illustrated in Fig. 1. [18]:
Phase 1: Investigation Phase 2: Analysis Phase 3: Design Phase 4: Implementation Phase 5: Testing & Validation
Fig. 1. Secure System Development Life Cycle (SecSDLC)
Towards New Data Access Control Technique
271
3.1 Secure System Development Life Cycle (SecSDLC) Phases 3.1.1 Phase 1 - Investigation This phase defined the processes and goals, and documents them in the program security policies and its attributes. Table 1 shows the investigation phase that proposed data security policies, attributes and its definition. Table 1. Investigation Phase DATA SECURITY POLICY Confidentiality
DATA SECURITY POLICY ATTRIBUTES
DESCRIPTION
Formula-Based Cloud Data Access Control (FCDAC).
Ensuring that data is not disclosed to unauthorized persons.
The definitional borders of cloud computing are much debated today. Cloud computing involves the sharing or storage by cloud users of their own information on remote servers owned or operated by others and accesses through the Internet or other connections. Cloud computing services exist in many variations, including data storage sites, video sites, tax preparation sites, personal health record websites and many more. The entire contents of a cloud user’s storage device may be stored with a single CSP or with many CSPs. Some of the findings related to the confidentiality issues are: • • • • • • • •
Cloud computing has significant implications for the privacy of personal information as well as for the confidentiality of business and governmental information. A cloud user’s confidentiality risks vary significantly with the terms of service and privacy policy established by the CSP. For some types of information and some categories of cloud computing users, confidentiality rights, obligations, and status may change when a cloud user discloses information to a CSP. Disclosure and remote storage may have adverse consequences for the legal status of protections for personal or business information. The location of information in the cloud may have significant effects on the privacy and confidentiality protections of information and on the privacy obligations of those who process or store the information. Information in the cloud may have more than one legal location at the same time with differing legal consequences. Laws could oblige a cloud CSP to examine cloud user records for evidence of criminal activity and other matters. Legal uncertainties make it difficult to assess the status of information in the cloud as well as the privacy and confidentiality protections available to cloud users.
272
A. Mohamed Talib et al.
3.1.2 Phase 2 - Analysis In this phase, our system requirements, components and performance will be analysis using adversary model [19, 3]. We will also evaluate the performance of our secure MAS architecture via implementation of the proposed agents type (Agent Agency). The results of this analysis will be described based on Cloud Data Security Adversary Analysis Approach that considers two types of adversary with different levels of capability as illustrated in Fig. 2.
Fig. 2. Cloud Data Security Adversary Analysis Approach
¾ Weak Adversary: The adversary is interested in corrupting the user’s CDS stored on individual servers. Once a server is comprised, an adversary can pollute the original CDS by modifying or introducing its own fraudulent cloud data to prevent the original cloud data from being retrieved by the cloud user. ¾ Strong Adversary: This is the worst case scenario, in which we assume that the adversary can compromise all the cloud servers so that it can intentionally modify the CDS as long as they are internally consistent. In fact, this is equivalent to the case where all servers are colluding together to hide a cloud data loss or corruption incident. 3.1.3 Phase 3 - Design To ensure the security for CDS under the aforementioned secure MAS architecture, we aim to design efficient mechanisms for confidentially of cloud user’s data and achieve the following goal: 9 Confidentially: to define and enforce expressive and flexible access structure for each cloud user by defines a logic formula over cloud data file attributes.
Towards New Data Access Control Technique
273
MAS design shall be specified to determine the types of agents, events, protocols and agent capabilities, using the Prometheus methodology [20]. The sections below go through each of Prometheus’ three phases in more detail and will discuss the notations used by the methodology as well as some specific techniques. The Prometheus methodology consists of three phases: System Specification: where the system is specified using goals (see Fig. 3.) and scenarios; the system’s interface to its environment is described in terms of actions, percepts and external data; and functionalities are defined. Architectural design: where agent types are identified; the system’s overall structure is captured in a system overview diagram; and scenarios are developed into interaction protocols. Detailed design: where the details of each agent’s internals are developed and defined in terms of capabilities, data, events and plans; process diagrams are used as a stepping stone between interaction protocols and plans. Each of these phases includes models that focus on the dynamics of the system, (graphical) models that focus on the structure of the system or its components, and textual descriptor forms that provide the details for individual entities.
Fig. 3. Design Goals
3.1.4 Phase 4 - Implementation Our system architecture will be developed using FIPA compliant JADE-S agent framework version 2. JADE (Java Agent DEvelopment framework) is a FIPA compliant software framework fully implemented in the Java programming language, which simplifies
274
A. Mohamed Talib et al.
the implementation of MASs. The platform can be seen as a middleware (Fig. 4) providing a set of useful tools that support the debugging and deployment phase [21, 22, 24]. JADE-S is formed by the combination of the standard version of JADE with the JADE security plug-in [23]. JADE-S includes security features such as user/agent authentication, authorization and secure communication between agents into the same platform. With more details: •
•
•
• • •
Authentication: a user must be authenticated by providing a username and password, to be able to own or perform actions on a component of the platform. Only authenticated users can own AMS, DF, containers and other agents; Authorization: JADE-S uses the concept of Principal as an abstraction for a user account, an agent or a container. A Principal must be authorized by the Java Security Manager. The Security Manager allows or denies the action according to the JADE platform's policy; Permissions and Policies: Permission is an object that describes the possibility of performing an action on a certain resource such as a piece of code, but also executes that code. A policy specifies which permissions are available for various principals; Certificates and Certification Authority: the Certification Authority (CA) is the entity that signs all the certificates for the whole platform, using a public/private key pair (PKI infrastructure). Delegation: this mechanism allows the “lending” of permissions to an agent. Besides the identity certificate, an agent can also own other certificates given to it by other agents; Secure Communication: communication between agents on different containers/hosts, are performed using the Secure Socket Layer (SSL) protocol. This enables a solid protection against malicious attempts of packet sniffing.
Fig. 4. Software architecture of one JADE agent platform ([21])
Towards New Data Access Control Technique
275
3.1.5 Phase 5 - Testing and Validation To test and validate our system, we have asked a permission of the Cloud Service Provider (CSP) of Malaysian Institute of Microelectronic Systems (MIMOS) to allow us to test and validate our secure MAS architecture in their cloud computing platform. In order to test and validate our MAS architecture against the scale of the CDS system, we will measure the times required for the agents to travel around different number of cloud users before and after implementing our MAS technique based on the linearly over the Round Trip Time (RTT) for each agent.
4 Proposed MAS Architecture The MAS architecture consists of two agents: Cloud Service Provider Agent (CSPA) and Cloud Data Confidentiality Agent (CDConA). CSPA interact with the cloud users to fulfill their interests. CDConA provides a Cloud Service Provider (CSP) by definition and enforcement expressive and flexible access structure for each cloud user. 4.1 Cloud Service Provider Agent (CSPA) Is the users’ intelligent interface to the system and allow the cloud users to interact with the security service environment. The CSPA provides graphical interfaces to the cloud user for interactions between the system and the cloud user. CSPA act in the system under the behaviour of CSP. It is the only agent that can execute outside the main container of the platform and make remote requests through cloud server. CSPA has the following responsibilities as stated in Table 2. Table 2. Responsibilities of CSPA. Agent Name
Cloud Service Agent (CSPA)
Provider
¾
Responsibilities Provide the security service task according to the authorized service level agreements (SLAs) and the original message content sent by the CDConA.
¾
Receive the security reports and/or alarms from the rest of other agents to respect.
¾
Monitor specific activities concerning a part of the CDS or a particular cloud user.
¾
Translate the attack in terms of goals.
¾
Display the security policies specified by the CSP and the rest of the agents.
¾
Designing user interfaces that prevent the input of invalid cloud data.
¾
Creating security reports/ alarm systems.
276
A. Mohamed Talib et al.
4.2 Cloud Data Confidentiality Agent (CDConA) This agent facilitates the security policy of Confidentiality for CDS. Main responsibility of this agent is to provide a CDS by new access control rather than the existing access control lists of identification, authorization and authentication. This agent provides a CSP to define and enforce expressive and flexible access structure for each cloud user. Specifically, the access structure of each cloud user is defined as a logic formula over cloud data file attributes, and is able to represent any desired cloud data file set. This new access control is named as Formula-Based Cloud Data Access Control (FCDAC). This agent is also notifies CSPA in case of any fail caused of the techniques above by sending security reports and/or alarms. There are two different types of CDConA agents, namely: Cloud Data Flexible Confidentiality Agent (CDFConA) and Cloud Data Expressive Confidentiality Agent (CDEConA). The CDFConA acts as a dispatching center, with the following advantages. Firstly, the CDFConA is the unique access point where authorization agents can contact the CDConA. Secondly, CDFConA acts as the exclusive resource access entry. This makes the SPAs are only able to access the cloud data file via CDFConA. CDFConA provides cloud users with different security services, such as symmetric encryption/decryption and PKI encryption/decryption. CDFConA is divided into two types of agent based on the exhibited behavior. The first is CDFConA-VIP, which has selfish behavior and only serves for VIP (Very Important Person) cloud users. The second is NOT-VIP CDFConA, which has cooperative behavior and serves for both VIP cloud users and normal cloud users. For example, if CDFConA-VIP agent is overloaded, it sends help request to the first available NOT-VIP CDFConA agent. If this NOT-VIP CDFConA agent is unable to provide the help to CDFConA-VIP agent, the CDFConA-VIP sends the same help request to the next available NOT-VIP CDFConA agent. CDFConA-VIP agents keep sending the same request for help until one of the NOT-VIP CDFConA accepts or it is not overloaded. NOT-VIP CDFConA agents also take the same action as CDFConA-VIP when they are overloaded. However, NOT-VIP CDFConA agent only has knowledge about other NOT-VIP CDFConA agents, but not CDFConA-VIP agents. 4.2.1 Cloud Data Flexible Confidentiality Agent (CDFConA) The architecture of CDFConA consists of five modules, as shown in Fig. 5. Cloud Communication Module provides the agent with the capability to exchange information with other agents, including the CDEConA and CSPA. Cloud Register Module facilitates the registration function for CDConA. Cloud Request Management Module allows the agent to act as the request-dispatching center. Cloud Resource Management Module manages the usage of the cloud resources. Cloud Reasoning Module is the brain of the CDConA. When the request management module and resource management module receive requests, they pass those requests to reasoning module by utilizing the information obtained from the knowledge base and the Confidentiality policy rule.
Towards New Data Access Control Technique
Existing cloud authorization
CDEConA
CSPA
Cloud Communication Module
Existing cloud authentication
277
Cloud Request Management Module Confidentiality Policy Rules Cloud Reasoning Module
Cloud Resource Management Module
Knowledge Base
Cloud Register Module
Fig. 5. CDFConA Architecture
4.2.2 Cloud Data Expressive Confidentiality Agent (CDEConA) The architecture of the CDEConA consists of two modules, as shown in Fig. 6. Cloud Communication Module provides the agent with the capability to exchange information with CSPA and CDFConA. Cloud Cooperation Module provides the agent with the following mechanisms. If the CDEConA is registered as CDFConA-VIP it asks for help when it is overloaded. If the CDEConA is registered as NOT-VIP CDFConA, it always offers help to other CDEConAs when it is not overloaded. Existing cloud authorization
CDFConA
CSPA
Cloud Communication Module
Existing cloud authentication
Confidentiality Policy Rules Cloud Cooperation Module Knowledge Base
Fig. 6. CDEConA Architecture
5 Conclusions This paper proposed a multi agent system for secure cloud data storage. The architecture consists of two types of agents: Cloud Service Provider Agent (CSPA) and Cloud Data Confidentiality Agent (CDConA). CSPA provides a graphical interface to the
278
A. Mohamed Talib et al.
cloud user that facilitates the access to the services offered by the system. CDConA provides each cloud user by definition and enforcement expressive and flexible access structure as a logic formula over cloud data file attributes. Formula-Based Cloud Data Access Control (FCDAC) is proposed to meet the need of access control in the era of cloud computing by providing enforcement expressive and flexible access structure as a logic formula over cloud data file attributes.
References 1. Zeng, W., Zhao, Y., Ou, K., Song, W.: Research on Cloud Storage Architecture and Key Technologies, pp. 1044–1048. ACM, New York (2009) 2. Blaze, M., Feigenbaum, J.: The Role of Trust Management in Distributed Systems Security. In: Ryan, M. (ed.) Secure Internet Programming. LNCS, vol. 1603, pp. 185–210. Springer, Heidelberg (1999) 3. Bowers, K.D., Juels, A., Oprea, A.: HAIL: A High-Availability and Integrity Layer for Cloud Storage. In: Cryptology ePrint Archive, pp. 1–8 (2008), http://eprint.iacr.org/ 4. Kormann, D., Rubin, A.: Risks of the Passport Single Sign on Protocol. Computer Networks 33(1-6), 51–58 (2000) 5. Kallahalla, M., Riedel, E., Swaminathan, R., Wang, Q., Fu, K.: Plutus: Scalable Secure File Sharing on Untrusted Storage, pp. 29–42. USENIX Association (2003) 6. Goh, E.J., Shacham, H., Modadugu, N., Boneh, D.: SiRiUS: Securing Remote Untrusted Storage, pp. 131–145. Citeseer (2003) 7. Ateniese, G., Fu, K., Green, M., Hohenberger, S.: Improved Proxy Re-encryption Schemes With Applications to Secure Distributed Storage. ACM Transactions on Information and System Security (TISSEC) 9(1), 1–30 (2006) 8. Di Vimercati, S.D.C., Foresti, S., Jajodia, S., Paraboschi, S., Samarati, P.: Overencryption: Management of Access Control Evolution on Outsourced Data. In: VLDB Endowment, pp. 123–134 (2007) 9. Atallah, M.J., Blanton, M., Fazio, N., Frikken, K.B.: Dynamic and Efficient Key Management for Access Hierarchies. ACM Transactions on Information and System Security (TISSEC) 12(3), 1–43 (2009) 10. Johnson, M., Chang, P., Jeffers, R., Bradshaw, J.M., Soo, V.W., Breedy, M.R., Bunch, L., Kulkarni, S., Lott, J., Suri, N.: KAoS Semantic Policy and Domain Services: An Application of DAML to Web Services-Based Grid Architectures, pp. 32–41. Citeseer (2003) 11. Tonti, G., Bradshaw, J.M., Jeffers, R., Montanari, R., Suri, N., Uszok, A.: Semantic web languages for policy representation and reasoning: A comparison of kAoS, rei, and ponder. In: Fensel, D., Sycara, K., Mylopoulos, J. (eds.) ISWC 2003. LNCS, vol. 2870, pp. 419– 437. Springer, Heidelberg (2003) 12. Kagal, L.: Rei: A Policy Language for the Me-centric Project. HP Labs, accessible online, pp. 1-23 (2002), http://www.hpl.hp.com/techreports.html 13. Samarati, P., de Vimercati, S.: Access Control: Policies, Models, and Mechanisms. In: Foundations of Security Analysis and Design, pp. 137–196 (2001) 14. Lampson, B.W.: Protection. ACM SIGOPS Operating Systems Review 8(1), 18–24 (1974) 15. Harrison, M.A., Ruzzo, W.L., Ullman, J.D.: Protection in Operating Systems. Communications of the ACM 19, 461–471 (1976) 16. Denning, D.E.: A Lattice Model of Secure Information Flow. Communications of the ACM 19(5), 236–243 (1976)
Towards New Data Access Control Technique
279
17. Bell, D.E., Lapadula, L.J., Mitre, M.A.: orp Bedford. Secure Computer Systems: Mathematical Foundations 1(M74-244), 1–42 (1973) 18. Whitman, M.E., Mattord, H.J.: Management of Information Security, pp. 1–18. Course Technology Press, Boston (2004) 19. Wang, C., Wang, Q., Ren, K., Lou, W.: Ensuring Data Storage Security in Cloud Computing, pp. 1–9. IEEE, Los Alamitos (2009) 20. Padgham, L., Winikoff, M.: Developing Intelligent Agent Systems: A Practical Guide, pp. 1–240. Wiley, Chichester (2004); ISBN: 978-0-470-86120-2 21. Fabio, B., Agostino, P., Giovanni, R.: JADE—A FIPA-Compliant Agent Framework CSELT Internal Technical Report. Part of this report has been also published in Proceedings of PAAM 1999, pp. 97–108 (1999) 22. Bellifemine, F.L., Poggi, A., Rimassa, G.: Developing multi-agent systems with JADE. In: Castelfranchi, C., Lespérance, Y. (eds.) ATAL 2000. LNCS (LNAI), vol. 1986, p. 89. Springer, Heidelberg (2001) 23. Agostino, P., Rimassa, G., Tomaiuolo, M.: Multi-User and Security Support for MultiAgent Systems. In: Proceedings of WOA Workshop, Modena, Italy, pp. 1–7 (2001) 24. Bellifemine, F., Poggi, A., Rimassa, G.: Developing Multi-Agent Systems with a FIPACompliant Agent Framework. Software—Practice and Experience (31), 103–128 (2001)
