International Journal of Computer Engineering and Technology (IJCET), ISSN (Print), INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &

Transcription

1 INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING & TECHNOLOGY (IJCET) ISSN (Print) ISSN (Online) Volume 4, Issue 6, November - December (2013), pp IAEME: Journal Impact Factor (2013): (Calculated by GISI) IJCET I A E M E A PROPOSED MODEL FOR DATA STORAGE SECURITY IN CLOUD COMPUTING USING KERBEROS AUTHENTICATION SERVICE 1 Yaser Fuad Al-Dubai and 2 Dr. Khamitkar S.D School of Computational Sciences Swami Ramanand Teerth Marathwada University, Nanded , MS, India. ABSTRACT The companies computing look forward to the adoption of minimum resources for their application either by introducing a new concept of cloud computing in their environment. Cloud computing improved the performance with minimal resources and administrative support, with a shared network, the value of resources, bandwidth, software and hardware effectively in terms of cost and service are limited dealings cloud provider. This is what makes many of the advantages and disadvantages for customers to manage data in the cloud service provider. One is the management of data and programs may not be worthy of full confidence in cloud computing and therefore the security is an important aspect of quality of service. The purpose of this paper is to focus on the security management of cloud computing data used in cloud computing via proposed model for data storage security in cloud computing using Kerberos authentication service. I believe this is a background paper proved the next opportunity of growth of cloud computing security. Keywords: Cloud Service Provider, Authentication Service, Ticket Granting Cloud Service, Key Distribution Centre. 1. INTRODUCTION As we know, the cloud computing developed significantly to achieve prosperity for the human and with the thrive in breakthrough malicious program in cloud security becomes even more important. Many trends open up the era of cloud computing, which is Internet base Develop and use the computer technology [1]. The ever not expensive and more powerful processors, along with software as a service SaaS computing architecture, the data center conversion to the pools of the computing service on a massive scale. For example, Amazon simple storage Service and Amazon Elastic Compute Cloud are well known Examples [2]. In this paper, first we have identified, and 62

2 presented the customers, their attributes, and duties. Secondly, we have introduced an application program as a Third Party Auditor (TPA). Third, we studied the Kerberos impact in cloud computing server. Finally, we examined the cloud server provider. Kerberos Uses strong encryption a ticket granting algorithm to authenticate users on the network. Also since many customers are interested in Kerberos, it has the ability to distribute session keys to process the data encryption across a network. Customers who want to connect to the cloud, at the first it should make his/her profile and the customer s identity in the third party. The information will be saved from all customers, such as customer s identity and password hashed in a large database for more security. After the registration in the third party, it should obtain a password and customer s identity. In the next step, and it should be connected to the Kerberos and do this process [3,4]. Send a requesting ticket to granting the ticket from Authentication Service (AS). AS verifies customer s access right in the database and creates a Ticket Granting Ticket (TGT) and the session key. Result is encrypted using key derived from customer s password. Customer sends the request cloud service granting ticket to Ticket Granting Service (TGS). The TGS Send ticket session key to the customer. (It is a one executable for each type of service). The workstation sends ticket and authenticator to the cloud server provider (CSP). Server checks for a match ticket authentication, and then grants access to the service. This article tried to assume each customer to connect and utilize the cloud server must create a profile and apply some private information for more data base security.the rest of this article is organized as the following: Section 2 discusses the benefits of using Kerberos in the cloud computing, section 3 discusses the problem statement challenges and issues, section 4 discusses data storage security in cloud computing using Kerberos authentication service model. 2. BENEFITS OF USING KERBEROS IN THE CLOUD COMPUTING Kerberos is used widely in the non secure network connections, especially on cloud servers. It s was developed to establish new connections between customer and cloud servers on the Internet more secure. Kerberos is a "network authentication protocol" that allows the nodes to connection points of the various cloud networks, and to communicate with each other [1,6] Cloud Customer Password Protection The primary innovation is that the Kerberos protocol when they want to sent the cloud customer password does not need to be sent over a network, either in plain text or under encryption. Protocol relies instead on the secret keys that are sent in encryption that cannot be intercepted. If network security is breached it is still not possible for trespassers on the interpretation of the content of the communication network. Authentication and remain a safe target cloud customer services. Authenticate The Customer/Cloud Server Within Kerberos, the customer and the server must validate each other. Communication breaks down if each side is not able to authenticate the peer. Customer/Cloud Server Certificate Ticket In addition to mutual authentication tickets issued from the cloud server to the customer and vice versa are temporary and include information for validity to authentication and limitation. The implementation period may be modified by the customer by design, but the maximum is generally low enough to ensure that replay attacks and brute force attacks is not feasible. By ensuring that the 63

3 age is lower than any theory possible encryption cracking time, it remains completely secure connection. Durability and Reuse Authentication using the Kerberos protocol is durable and reusable. Once it has customer authentication using the protocol, authentication is reusable for the lifetime of the ticket. In other words, it is possible to remain authentication through Kerberos protocol without the need to re-enter your customer name and password over the network even expired authentication. Session Key Generation Cloud Service Because the model uses Kerberos dual key encryption methodology, cloud service session key, which also produces provides a special connection between the customer and the cloud service that is completely safe. This special connection secret " can be used as the encryption key for the customer to provide cloud service, which adds extra security for communications on the menu for Kerberos. Open Internet Standards The Kerberos protocol depends entirely on open internet standards, and is not limited to proprietary codes or authentication mechanisms. This allows developers rely on any number of applications free and open signal through public means. In addition, cheap commercial applications can be purchased or developed independently. 3. PROBLEM STATEMENT System Model In the cloud computing when we want to store the data we face some problems in the cloud computing network and service provider configuration which allows customers to remotely unauthorized access to: Steal confidential documents. To modify the system configuration. Acquisition of information about the cloud service provider that will allow them to break into the system. Making the machine unusable temporarily by launch denial of service attacks. We suggest cloud security model using Kerberos authentication protocol to avoid this problems [3,5]. A representation of network architecture for cloud data storage from the Kerberos AS is illustrated in figure1. Seven different network entities can be identified as follows: Customer : customer who should in the first refer to creating a third party and the account in third party database and get password, session key want to store the data in cloud and rely on the cloud for data computation consist of both individual Consumer and organize consume. Cloud Service Provider: CSP offering cloud solutions such as Google Applications that are delivered electronically via the internet. Unlike managed services provider cloud service providers do not sell or install everything they offer is stored online in the internet and can be accessed securely from anywhere. There are many benefit to working with cloud service like Sherpa when you switching your old and collaboration Software. 64

4 Kerberos Process: Kerberos is an authentication mechanism that provides a secure means for network authentication customers. It prevents transmission of clear text passwords via the network by encrypting authentication messages between customers and servers. In addition, Kerberos provides a system for authorization in the form of administering tokens, or credentials [9]. In another definition for Kerberos is an authentication protocol for trusted hosts on untrusted networks. Authentication Service: AS is that knows the password for all customers and stores these in a centralized database. In addition AS shares a unique secret key with each server. Tickets Granting Service: TGS supply and issue tickets to the customer who is authentication to AS. Database: the database is a container the entries information relevant with customer and services. The database is shared between third party and Kerberos. We indicate to an entry by using the principal even if often the term principal is used as a synonym for entry. Each entry contains the following Information: The principal to which the entry is associated. The maximum validity during a ticket associated to the principal. The encryption key. The maximum time a ticket associated to the principal may be renewed. The attributes or flags characterizing the behavior of the tickets. The password expiration date. An expiration date of the principal, after which no tickets will be issued. Third Party: The third party who has defines the correctness, expertise, and capabilities to access and utilize the cloud service Provider. Fig. 1: Cloud Data Storage Architecture 65

5 4. DATA STORAGE SECURITY IN CLOUD COMPUTING USING KERBEROS AUTHENTICATION SERVICE MODEL The basic approach for cloud computing with Kerberos authentication is as follows: a cloud customer should supply a ticket. A ticket for a cloud service is a series of bits with the attribute that it has been enciphered using the private key for that cloud service. That private key is known only to the cloud service itself and to Kerberos. The cloud service can be confident that any information that exists within the ticket originated from Kerberos. Kerberos will have placed the identity of the cloud customer inside the ticket so the cloud service that receives a ticket has a Kerberos authenticated opinion of the identity of the cloud customer. To help ensure that one customer does not steal and reuse another customer s tickets, the cloud customer accompanies the ticket with an authenticator [3,4]. (In addition, tickets expire after a specified lifetime, which is usually within a few hours.) The cloud customer gets a ticket by sending a message to Kerberos naming the principal identifier of the desired cloud service, the principal identifier of the (alleged) cloud customer and the reference to the current time of day. Anyone can send such a message or intercept its response that response however is usable only to the cloud customer named in the original request because Kerberos seals the response by enciphering it in the private key of that cloud customer. The response contains three parts: the ticket (which itself is further sealed in the private key of the cloud service) a newly minted key for use in this cloud customer, server session, and a timestamp issued by the Kerberos server. The cloud customer will be able to unseal this message, obtain the ticket and session key and verify that the timestamp is current (thereby preventing replays of old responses). No other customer without the named cloud customer s private key can correctly decrypt the reply to produce the sealed tickets and corresponding session key. Once a cloud customer gets a ticket and sends it to a cloud service and the cloud service has identified the cloud customer further use of the fact of authentication is specific to the protocol of the cloud service. One application maybe use the session key (Kerberos seals a copy in the ticket) for secure end to end encryption, while at the other extreme, another application maybe throw everything but the source network address away and assume that all further requests coming on the connection from this particular network address are from the same cloud customer. The authenticator mentioned above is a simple mechanism designed to discourage tries at unauthorized reuse ("replay") of tickets by someone who notices a ticket sending by on the network and makes a copy. The authenticator contain of among other things the cloud customer s principal identifier, network address, and the current time of day all sealed with the key that Kerberos minted for this session. After the cloud service decrypts the ticket it uses the session key found in that ticket to decrypt the authenticator. If the principal ID of the authenticator matches the one in the ticket the network address in the authenticator is the same as the one that sent the packet and the time in the authenticator is within the last few minutes the authenticator is probably not a response and the cloud service accepts the associated ticket. That is because authenticators expire in a short time that all the cloud customers and servers in a Kerberos realm need to have their clocks loosely synchronized. If a private key has been compromised another party may successfully pose as the principal until the private key is changed and all tickets previously issued under it expire. If a session key is breakthrough another party may successfully pose as the principal until the previously issued tickets expire. One more mechanism rounds out the complete Kerberos process. If a cloud customer uses several cloud services a distinct ticket is needed for each. Not all the cloud services to be used may be known at the beginning of a login session but that is when the user provides the password used as a private key to decrypt tickets. To avoid storing the private key in the workstation memory for the entire duration of the session, at login time the user obtains a single ticket, useful only for a service provided by Kerberos itself, the ticket-granting cloud service. Whenever the cloud customer goes 66

6 back to Kerberos for an additional service specific ticket, the response is actually enciphered in the session key of the ticket granting cloud service. Thus the private key is needed only for the initial ticket and the workstation software can immediately destroy its copy of that private key after being used once. Authentication Scenario The first step of the Key Distribution Centre is the AS. Cloud customer (principal) initially requests a ticket to the KDC by giving it is name, an expiration time until when the authentication will remain valid, the cloud service required (tgs) and some other information, is not mentioned here for clarity[6,7]. The KDC if found the cloud customer in it is database, replies with two steps: Cloud customer ticket contains a session key S A, KDC, the expiration time and it is tgs cloud service name, all encrypted using the secret key of the principal K A. The expiration time usually working day or eight hours, gives a period of time during which the tickets will be valid. Granting ticket contains the session key S A, KDC, the expiration time and the name of the cloud customer, all encrypted using the secret key for the KDC K KDC. This is what is known as a TGT. The principal unable to decrypt the TGT, and will be used later to request tickets for the other cloud services. As it is encrypted the cloud customer cannot read the data inside. If tries to modify it, the KDC will not be able to decrypt it and it will be refused. Ticket Granting Cloud Service (TGCS) Scenario The second step of the KDC is the distribution of tickets it called the TGCS. Once authenticated the cloud customer who requests a specific application such as telnet or FTP first asks the KDC. It does not query the cloud service directly. This request to the KDC it contains several fields: An Authenticator consist of: a timestamp and checksum encrypted with the session key S A, KDC, which was obtained earlier in the KDC, shared between the cloud customer and the KDC. This proves the identity of the cloud customer since he is the only one to know this session key. The checksum proves the authentication message has not been modified during the transiting. The timestamp confirms the message is recent, and is used to prevent "reply" attacks, since anyone can Interception of data across the network and use it at a later time. Typically, the KDC must responds within five minutes for a message to be accepted. This is why it is important to have a good time synchronization across your network where is implemented the Kerberos AS to the cloud computing. Consider the use of Protocol such as NTP (Network Time Protocol) to keep it accurate. TGT received during the authentication exchange with the KDC. It is used by the KDC to verify the cloud customer s name. If the cloud customer name present in the TGT does not match with related the session key and this means the cloud customer has been impersonated and the KDC is unable to decrypt the authenticator. Also the KDC verifies the validly by checking the expiration time of the authentication. The Cloud Service name to which the cloud customer wants to establish a connection. An expiration time for the TGT. The KDC responses to the cloud customer (principal) with two tickets: The cloud customer ticket contains a new session key S A, B that the cloud customer and the cloud service will be used to verify each other s identity and to encrypt their sessions.the ticket also encloses the cloud service name and the expiration time of the new ticket. All of 67

7 these items encrypted using the key S A, KDC shared between the cloud customer and the KDC, known only to the cloud customer. The server ticket that contains the same session key S A, B as mentioned above, the cloud customer's name and time of the expiration of the ticket. The server ticket being encrypted with the cloud service s secret key K B, only known to the server. It is then under the responsibility of the cloud customer to send a server ticket to the cloud service. Therefore, in order for the cloud customer to request access to the cloud service, you must first decrypt the cloud customer ticket and extract the session key S A, B. Once extracted, the cloud customer uses this key to encrypt his authenticator, and consists of a timestamp and. Thus the cloud customer sends this encrypted authenticator and the server ticket to the cloud service. Note that the cloud service does not have the session key S A,B yet. It will get it only if it is able to decrypt the ticket accompanying authenticator, which is the server ticket. It has been sent by the KDC to the cloud customer, encrypted with the cloud service secret key K B, and now are forwarded by the cloud customer to the Cloud Service. As it is encrypted no one except the cloud service is able to see what has this ticket contains, not even the cloud customer. This is how the cloud service receives the session key S A,B to verify the cloud customer s identity and to share with it. It also verifies the validity of the ticket by checking the expiration time enclosed in the server ticket. Optionally, the cloud service replies to the cloud customer with a timestamp encrypted with their session key S A,B. This is how the cloud customer verifies and validates the identity of the server; since the cloud customer and the server are the only one to know this session key. Again, the timestamp is used to prove the message is recent, and that it is not previous packet being sent again. The table1 shows how to implement this scenario [4]. (A) AS Exchange: to obtain TGT 1. AS_REQ {cloud customer name, expiration time, tgs cloud service name, } 2. AS_REP {S A, KDC, expiration time, tgs cloud service name }. K A + {S A, KDC, expiration time, cloud customer name }. K KDC. (B) Ticket Granting Sever Exchange: to obtain Server Granting Ticket 3. TGS_REQ {timestamp, checksum }.S A, KDC + { S A,KDC, expiration time, cloud customer name, }. K KDC. + cloud service name + expiration time 4. TGS_REP {S A,B, cloud service name, expiration time, }.S A, KDC + {S A, B,cloud customer name, expiration time, }. K B (C) Customer/Server Authentication Exchange: to obtain Cloud Service 5. CS_REQ {timestamp, checksum }.S A,B + {S A,B, cloud customer name, expiration time, }. K B 6. CS_REP {timestamp}.s A,B Table1. Summary of Kerberos Message Exchange in Cloud Service CONCLUSION In this paper we proposed model for data storage security in cloud computing using Kerberos also we present the problem of data security which effected on cloud data storage, which is essentially a distributed storage system. To ensure the accuracy of customer s data in cloud data storage and accuracy of customers who can access cloud server, we proposed flexible and an effective distributed system with dynamic data support including Kerberos authentication service. Kerberos provides a centralize Authentication Server whose function is to authenticate customer to cloud server and vice versa. Any customer to be access the cloud server first must make customer ID 68

8 and password then it can use the cloud server with an increase in qualifying. As we know the unique attribute of the network is security. As we know in unprotected network environment the customer can be able to apply in any cloud server to service but the process for Kerberos with make use of RSA or DES instead of elaborate protocol can provide the authentication service. In my opinion this model is novel model in era of cloud data storage domain. REFERENCES [1]. Mell P. and Grance T. The NIST Definition of Cloud Computing URL: , 2011 [2]. N. Gohrin Amazon s S3 down for several hours, online at /amazons s3 down for several hours.html, [3]. S.P.Miller, B.C.Neuman, J.I.Schiller, and J.H.Saltzer. Kerberos Authentication and authorization System. SectionE.2.1, October [4]. William Stallings, Cryptography and Network Security, Fifth edition, URL: [5]. C. Wang, Q. Wang, K. Ren, and W. Lou, Privacy-preserving public auditing for storage security in cloud computing, in Proc. of IEEE INFOCOM 10, March [6]. Armbrust M., Fox A., Griffith R., Joseph A.D., Katz R.H., Kon-winski A., Lee G., P Above the Clouds: A Berkeley View of Cloud Computing URL: [7]. S. M. Bellovin and M. Merritt. Limitations of the Kerberos Authentication System. UsenixConference.URL: wnload/ac:127107/content/kerblimit.usenix.pdf. January [8]. Er. Abhijeet, Mr. Praveen Tripathi, Er.Anuja Priyam and Er.Vivek Kumar, Implementation of Public Key Cryptography in Kerberos with Prevention of Security Attacks, International Journal of Computer Engineering & Technology (IJCET), Volume 4, Issue 3, 2013, pp , ISSN Print: , ISSN Online: [9]. Sujay Pawar and Prof. Mrs. U. M. Patil, A Survey on Secured Data Outsourcing in Cloud Computing, International Journal of Computer Engineering & Technology (IJCET), Volume 4, Issue 3, 2013, pp , ISSN Print: , ISSN Online: [10]. Abhishek Pandey, R.M.Tugnayat and A.K.Tiwari, Data Security Framework for Cloud Computing Networks, International Journal of Computer Engineering & Technology (IJCET), Volume 4, Issue 1, 2013, pp , ISSN Print: , ISSN Online: [11]. A.Madhuri and T.V.Nagaraju, Reliable Security in Cloud Computing Environment International Journal of Information Technology and Management Information Systems (IJITMIS), Volume 4, Issue 2, 2013, pp , ISSN Print: , ISSN Online: [12]. Gurudatt Kulkarni, Jayant Gambhir and Amruta Dongare, Security in Cloud Computing, International Journal of Computer Engineering & Technology (IJCET), Volume 3, Issue 1, 2012, pp , ISSN Print: , ISSN Online: