50120130406006

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &
ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME

TECHNOLOGY (IJCET)

ISSN 0976 – 6367(Print)
ISSN 0976 – 6375(Online)
Volume 4, Issue 6, November - December (2013), pp. 62-69
© IAEME: www.iaeme.com/ijcet.asp
Journal Impact Factor (2013): 6.1302 (Calculated by GISI)
www.jifactor.com

IJCET
©IAEME

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- 431606, 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


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


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 E-mail and collaboration Software.
64


•

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


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


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 SA, KDC, the expiration time and it is tgs cloud
service name, all encrypted using the secret key of the principal KA. 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 SA, KDC, the expiration time and the name of the cloud
customer, all encrypted using the secret key for the KDC KKDC. 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 SA,
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 SA, 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


these items encrypted using the key SA, KDC shared between the cloud customer and the KDC,
known only to the cloud customer.
• The server ticket that contains the same session key SA , 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 KB, 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 SA , 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 SA,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 KB, 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 SA,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 SA,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 – {SA, KDC, expiration time, tgs cloud service name …}. KA + {SA, KDC, expiration
time, cloud customer name …}. KKDC.
(B) Ticket Granting Sever Exchange: to obtain Server Granting Ticket
3. TGS_REQ – {timestamp, checksum …}.SA, KDC + { SA,KDC, expiration time , cloud customer
name, …}. KKDC. + cloud service name + expiration time
4. TGS_REP – {SA,B , cloud service name, expiration time, …}.SA, KDC + {SA, B ,cloud customer
name, expiration time,…}. KB
(C) Customer/Server Authentication Exchange: to obtain Cloud Service
5. CS_REQ – {timestamp, checksum …}.SA,B + {SA,B , cloud customer name, expiration time,
…}. KB
6. CS_REP – {timestamp}.SA,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


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:
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf 800-145 , 2011
[2]. N.
Gohrin
“Amazon’s
S3
down
for
several
hours,”
online
at
http://www.pcworld.com/businesscenter/article/ 142549 /amazons s3 down for several
hours.html , 2008.
[3]. S.P.Miller, B.C.Neuman, J.I.Schiller, and J.H.Saltzer. ”Kerberos Authentication and
authorization System.”SectionE.2.1,
http://web.mit.edu/Saltzer/www/publications/athenaplan/e.2.1.pdf. October 1998.
[4]. William Stallings, “Cryptography and Network Security”, Fifth edition, URL:”
http://mrajacse.files.wordpress.com/2012/1/cryptographynetworksecurity5thedition.pdf”
2011.
[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 2010.
[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:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf . 2009.
[7]. S. M. Bellovin and M. Merritt. “Limitations of the Kerberos Authentication System”.
UsenixConference.URL:http://academiccommons.columbia.edu/download/fedora_content/do
wnload/ac:127107/CONTENT/kerblimit.usenix.pdf . January 1991.
[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. 248 - 253, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.
[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. 70 - 76, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.
[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. 178 - 181, ISSN Print: 0976 – 6367, ISSN Online:
0976 – 6375.
[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. 23 - 30, ISSN Print: 0976 – 6405, ISSN Online:
0976 – 6413.
[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. 258 - 265, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.

69

50120130406006

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 50120130406006

Similar a 50120130406006 (20)

Más de IAEME Publication

Más de IAEME Publication (20)

Último

Último (20)

50120130406006