Download to read offline
![MODULES 1. System Initialization. 2. User Registration. 3. KDC setup. 4. Attribute generation. 5. Sign. 6. Verify. Modules Description 1. System Initialization Select a prime q, and groups G1 and G2, which are of order q. We define the mapping ˆe : G1 ×G1 → G2. Let g1, g2 be generators of G1 and hj be generators of G2, for j ∈ [tmax], for arbitrary tmax. Let H be a hash function. Let A0 = ha0 0 , where a0 ∈ Z∗ q is chosen at random. (TSig,TV er) mean TSig is the private key with which a message is signed and TV er is the public key used for verification. The secret key for the trustee is TSK = (a0, TSig) and public key is TPK = (G1,G2,H, g1,A0, h0, h1, . . . , htmax, g2, TV er). 2. User Registration For a user with identity Uu the KDC draws at random Kbase ∈ G. Let K0 = K1/a0 base . The following token γ is output γ = (u,Kbase,K0, ρ), where ρ is signature on u||Kbase using the signing key TSig. 3. KDC setup We emphasize that clouds should take a decentralized approach while distributing secret keys and attributes to users. It is also quite natural for clouds to have many KDCs in different locations in the world. The architecture is decentralized, meaning that there can be several KDCs for key management.](https://image.slidesharecdn.com/decentralizedaccesscontrolwithanonymousauthenticationofdatastoredinclouds-140814070813-phpapp02/75/Decentralized-access-control-with-anonymous-authentication-of-data-stored-in-clouds-3-2048.jpg)
![4. Attribute generation The token verification algorithm verifies the signature contained in γ using the signature verification key TV er in TPK. This algorithm extracts Kbase from γ using (a, b) from ASK[i] and computes Kx = K1/(a+bx) base , x ∈ J[i, u]. The key Kx can be checked for consistency using algorithm ABS.KeyCheck(TPK,APK[i], γ,Kx), which checks ˆe(Kx,AijBx ij) = ˆe(Kbase, hj), for all x ∈ J[i, u] and j ∈ [tmax]. 5. Sign The access policy decides who can access the data stored in the cloud. The creator decides on a claim policy Y, to prove her authenticity and signs the message under this claim. The ciphertext C with signature is c, and is sent to the cloud. The cloud verifies the signature and stores the ciphertext C. When a reader wants to read, the cloud sends C. If the user has attributes matching with access policy, it can decrypt and get back original message. 6. Verify The verification process to the cloud, it relieves the individual users from time consuming verifications. When a reader wants to read some data stored in the cloud, it tries to decrypt it using the secret keys it receives from the KDCs. System Configuration:- H/W System Configuration:- Processor - Pentium –III Speed - 1.1 Ghz RAM - 256 MB (min) Hard Disk - 20 GB Floppy Drive - 1.44 MB Key Board - Standard Windows Keyboard Mouse - Two or Three Button Mouse Monitor - SVGA](https://image.slidesharecdn.com/decentralizedaccesscontrolwithanonymousauthenticationofdatastoredinclouds-140814070813-phpapp02/75/Decentralized-access-control-with-anonymous-authentication-of-data-stored-in-clouds-4-2048.jpg)
Uploaded byVasanth Mca
Decentralized access control with anonymous authentication of data stored in clouds
The document proposes a decentralized access control scheme for secure data storage in clouds that supports anonymous authentication. The scheme allows a cloud to verify the authenticity of a user without knowing their identity when storing data. It also provides access control so that only valid users can decrypt stored information. Key distribution is done in a decentralized manner through multiple key distribution centers. The scheme prevents replay attacks and supports user registration, credential verification, and revocation while providing anonymous authentication and access control for data in the cloud.
Decentralized access control with anonymous authentication of data stored in clouds
- 1. DECENTRALIZED ACCESS CONTROLWITH ANONYMOUS AUTHENTICATION OF DATA STORED IN CLOUDS ABSTRACT We propose a new decentralized access control scheme for secure data storage in clouds, that supports anonymous authentication. In the proposed scheme, the cloud verifies the authenticity of the ser without knowing the user’s identity before storing data. Our scheme also has the added feature of access control in which only valid users are able to decrypt the stored information. The scheme prevents replay attacks and supports creation, modification, and reading data stored in the cloud. We also address user revocation. Moreover, our authentication and access control scheme is decentralized and robust, unlike other access control schemes designed for clouds which are centralized. The communication, computation, and storage overheads are comparable to centralized approaches. Existing System Existing work on access control in cloud are centralized in nature. Except and , all other schemes use attribute based encryption (ABE). The scheme in uses a symmetric key approach and does not support authentication. The schemes do not support authentication as well. Earlier work by Zhao et al. provides privacy preserving authenticated access control in cloud. However, the authors take a centralized approach where a single key distribution center (KDC) distributes secret keys and attributes to all users. Unfortunately, a single KDC is not only a single point of failure but difficult to maintain because of the large number of users that are supported in a cloud environment. We, therefore, emphasize that clouds should take a decentralized approach while distributing secret keys and attributes to users. It is also quite natural for clouds to have many KDCs in different locations in the world. Disadvantage: A single KDC is not only a single point of failure but difficult to maintain because of the large number of users that are supported in a cloud environment
- 2. Proposed System: proposed adecentralized approach, their technique does not authenticate users, who want to remain anonymous while accessing the cloud. In an earlier work, Ruj et al. proposed a distributed access control mechanism in clouds. However, the scheme did not provide user authentication. The other drawback was that a user can create and store a file and other users can only read the file. Write access was not permitted to users other than the creator. In the preliminary version of this paper, we extend our previous work with added features which enables to authenticate the validity of the message without revealing the identity of the user who has stored information in the cloud. In this version we also address user revocation. We use attribute based signature scheme to achieve authenticity and privacy. Advantages: we extend our previous work with added features which enables to authenticate the validity of the message without revealing the identity of the user who has stored information in the cloud. Architecture:
- 3. MODULES 1. System Initialization. 2.User Registration. 3. KDC setup. 4. Attribute generation. 5. Sign. 6. Verify. Modules Description 1. System Initialization Select a prime q, and groups G1 and G2, which are of order q. We define the mapping ˆe : G1 ×G1 → G2. Let g1, g2 be generators of G1 and hj be generators of G2, for j ∈ [tmax], for arbitrary tmax. Let H be a hash function. Let A0 = ha0 0 , where a0 ∈ Z∗ q is chosen at random. (TSig,TV er) mean TSig is the private key with which a message is signed and TV er is the public key used for verification. The secret key for the trustee is TSK = (a0, TSig) and public key is TPK = (G1,G2,H, g1,A0, h0, h1, . . . , htmax, g2, TV er). 2. User Registration For a user with identity Uu the KDC draws at random Kbase ∈ G. Let K0 = K1/a0 base . The following token γ is output γ = (u,Kbase,K0, ρ), where ρ is signature on u||Kbase using the signing key TSig. 3. KDC setup We emphasize that clouds should take a decentralized approach while distributing secret keys and attributes to users. It is also quite natural for clouds to have many KDCs in different locations in the world. The architecture is decentralized, meaning that there can be several KDCs for key management.
- 4. 4. Attribute generation Thetoken verification algorithm verifies the signature contained in γ using the signature verification key TV er in TPK. This algorithm extracts Kbase from γ using (a, b) from ASK[i] and computes Kx = K1/(a+bx) base , x ∈ J[i, u]. The key Kx can be checked for consistency using algorithm ABS.KeyCheck(TPK,APK[i], γ,Kx), which checks ˆe(Kx,AijBx ij) = ˆe(Kbase, hj), for all x ∈ J[i, u] and j ∈ [tmax]. 5. Sign The access policy decides who can access the data stored in the cloud. The creator decides on a claim policy Y, to prove her authenticity and signs the message under this claim. The ciphertext C with signature is c, and is sent to the cloud. The cloud verifies the signature and stores the ciphertext C. When a reader wants to read, the cloud sends C. If the user has attributes matching with access policy, it can decrypt and get back original message. 6. Verify The verification process to the cloud, it relieves the individual users from time consuming verifications. When a reader wants to read some data stored in the cloud, it tries to decrypt it using the secret keys it receives from the KDCs. System Configuration:- H/W System Configuration:- Processor - Pentium –III Speed - 1.1 Ghz RAM - 256 MB (min) Hard Disk - 20 GB Floppy Drive - 1.44 MB Key Board - Standard Windows Keyboard Mouse - Two or Three Button Mouse Monitor - SVGA
- 5. S/W System Configuration:- Operating System :Windows95/98/2000/XP Application Server : Tomcat5.0/6.X Front End : HTML, Java, Jsp Scripts : JavaScript. Server side Script : Java Server Pages. Database : Mysql Database Connectivity : JDBC. CONCLUSION We have presented a decentralized access control technique with anonymous authentication, which provides user revocation and prevents replay attacks. The cloud does not know the identity of the user who stores information, but only verifies the user’s credentials. Key distribution is done in a decentralized way. One limitation is that the cloud knows the access policy for each record stored in the cloud.
- 6. S/W System Configuration:- Operating System :Windows95/98/2000/XP Application Server : Tomcat5.0/6.X Front End : HTML, Java, Jsp Scripts : JavaScript. Server side Script : Java Server Pages. Database : Mysql Database Connectivity : JDBC. CONCLUSION We have presented a decentralized access control technique with anonymous authentication, which provides user revocation and prevents replay attacks. The cloud does not know the identity of the user who stores information, but only verifies the user’s credentials. Key distribution is done in a decentralized way. One limitation is that the cloud knows the access policy for each record stored in the cloud.